クラウドワークス エンジニアブログ

日本最大級のクラウドソーシング「クラウドワークス」の開発の裏側をお届けするエンジニアブログ

クラウドワークスのアプリ開発チームでQAを導入した話

こんにちは、アプリチームの @tkoshida です。

昨年末より弊社ではQA(品質保証)担当の方(以降、QAさん)をチームに迎え入れたので、弊社アプリチームのQAさんがいる状態でのチーム開発の取り組みを紹介してみたいと思います。

f:id:tkoshida:20190801165146p:plain

続きを読む

スクラムマスター2年生のスクラム観

こんにちは、 @yizknn です。 2018年1月にLSMスクラムマスター認定を受けまして、スクラムの手法で強いチームを作ろうと日々もがき続けています。

今回はこれまで3つのチームでスクラムした中で出来上がってきたスクラム観について語りたいと思います。 あくまで1人のスクラムマスターとしての意見であり、団体としての総意ではないことをここにご了承ください。

アジャイルスクラムの用語は流行り廃りやチーム内の造語で置き換えがよく発生します。 この記事では意味がズレないように、スクラムガイドの用語を使用します。 スクラムガイドは日本語訳のpdfも配布されています。 https://www.scrumguides.org/index.html

スクラムとは

f:id:yizknn:20190717183103p:plain スクラムの概要を1分で理解できるイラスト【2018版】 | Ryuzee.comより

スクラム(名詞):複雑で変化の激しい問題に対応するためのフレームワークであり、可能な限り価 値の高いプロダクトを生産的かつ創造的に届けるためのものである。

表現が少し濃いですが、私は「共通のゴールに到達するため、開発チームが一体となって働くこと」がスクラムだと考えています。 1人よりもチームで強くなることで生産性が上がり、楽しく仕事が進められるようになるという理想の職場環境です。 仕事が順調に進むとモチベーションを高く維持できるので、会社で働くことが楽しくなってくるでしょう。

なぜスクラムを取り入れたいのか

不確定要素の多い開発の場合、「素早く価値を提供する」ことが求められます。 その価値が目論見通りの価値になるか分からないので、素早く提供して反応を見ながら訂正していくのです。 スクラムフレームワークの定義が整っていて、すぐに手法を実践できるため、試しながら効果を実感できます。 共通言語として用語へのイメージも固定されるので、学習コストも低くなります。

気になったら試しに始めて、組織的に取り組むとなったらスケールを広げられるのも魅力です。 スクラムは明確な改善意識を育てる手段でもあるので、指摘を受けて襟を正すのではなく、自立して問題に立ち向かえるようになります。

プロダクトバックログは開発の外を意識する

「顧客にどんな価値を提供できるか」を主題にすると上手く機能しました。

1つの製品または機能に対する要求をユーザーストーリーに分割して、優先順位を付ける方法がシンプルで運用しやすいと感じました。 例えば、「庭で気軽に遊びたいので家の木を使った遊具で遊べる」のようなタイトルです。 顧客は何が得られるのか、実装されると何が嬉しいのか、実装の目的を明確にすると実現方法を想像しやすくなります。 タイトルに全て詰め込むと長くなってしまうので、補足事項として背景や何が目的なのかは別に文章化しておきましょう。 例えば、気軽に遊ぶというのは安いものでいいのか、運用するのが楽なものがいいのか、などの設計で重要なことを明確にします。

ここでは実装方法は問わずに価値を主題にすることで、プロダクトオーナーとチームメンバーで話が通しやすくします。 プロダクトバックログを管理して完了を宣言するプロダクトオーナーが、ビジネスサイドとして価値があるか判断しやすくなれば齟齬も生まれにくくなります。 有名な画像にもあるように、顧客の要望とその要望に対応する価値は一致しないことが多いです。 本当に必要なものを考えるためには、なぜそれが必要なのかを知る必要があるのです

f:id:yizknn:20190718105014j:plain Project Cartoon: Japanese

スプリントバックログは開発の作業を意識する

「価値を生むために何をするのか」を主題にすると上手く機能しました。

ユーザーストーリーを実際の作業に落とし込んで、1日で終わるようなサイズに分割します。 この1日の匙加減は適当でよく、MTGが特に多くなければ長くても3~5時間程度で終わる量を想定するとタスクが終わりやすかったです。 それ以上の大きさになるようであれば、レビューの難易度やタスクの属人化を考慮してペアプログラミングやモブプログラミングで片付けたいです。

タスクはなるべく翌日に持ち込まないようにして、タスクの属人化とモチベーションの低下を防ぎましょう。 意味のあるコードとして無理にまとめようとすると、リファクタリングなど修正範囲が膨らむ事になり、時間が掛かると中途半端にマージして別のリファクタリングを挟む事になります。 そうなると、1つのタスクに縛られ過ぎて仕事が進んだ心地になりません。 同じような結果になるのであれば、どこまで進んで何が障害になるのか分かるような区切りにして、着実に進んでいる実感を得られた方が良いと感じました。

スプリントプランニングでゴールを決める

次に何が完成したら目的達成となるかを主題にすると上手く進むと感じました。

プロダクトバックログを上から眺めて、完了させたいユーザーストーリーをスプリントバックログに移します。 そのユーザーストーリーたちの完了条件を決めて、全て終わらせたらゴールすることを確認しましょう。

可能であれば作業期間となるスプリントの日数も決めない方が良いかもしれません。 目指すゴールに辿り着いた時がスプリントの終わりとなった方が、次々と加速して前進していくように感じれます。 ゴールを追い抜いた後はボーナスステージではあるのですが、明確な目的が消えてしまうので実の所モチベーションが上がらないことが多いです。

見積もりの手順が抜けていますが、見積もりはしない方が良いと考えています。

見積もりは作業の目安にしてやり過ぎない

まず、ソフトウェア開発は不確定要素が多く、作業時間を予測して管理することに向いていません。 再現性が低く、異なる状況に対応する必要があるからです。

見積もりの精度は作業が進行するにつれて上がるため、最初からスケジュールを定めて引こうとしてもうまくいきません。 もし見積もりが正しく働いていると感じているなら、それは見積もりを正しく見せるために動いていて危険な状態かもしれません。 パーキンソンの法則である「仕事の量は完成のために与えられた時間をすべて満たすまで膨張する」になっていたり、ベロシティが人事評価に繋がるようになって実際以上の成果を作るようになってしまうことがあるのです。

何より見積もりには膨大な時間が掛かります。 不確定要素が多い時に抜けが無いように時間を掛けても、いずれ何かしら忘れていたことが発見されて再見積もり、スケジュールとズレてくると再見積もり、と際限がありません。 それだけの時間を消費して敏捷さを損なっている状態でアジャイル開発だと言えるでしょうか。

www.industriallogic.com 2012年の古い記事ですが、既にモダンアジャイルの提唱者も見積もりを辞めるべきと書いています。 Regional Scrum Gathering Tokyo 2019では、Chris Lucian氏が何年も見積もりの無い状態「No Estimate」で仕事をしていて、とても良くチームが機能していると話してくれました。 何年も前からアジャイル開発者の中には見積もりは必ずしも良い手法ではないと気付いて実施していない人たちがいました。 ビジネスサイドからすればリリースのスケジュールが引けないので頭の痛い問題ではありますが、より良いものを早く提供していれば約束が無くても顧客の信頼を勝ち得ることは成功者が証明しています。

個人的には見積もりは作業の大きさが分かる目安にして、個人でやれるか協力してやるのかを決めるくらいにした方が効率も上がるので好みです。 ただし、お互いに信頼があり技術力も高まっている「強いチーム」でなくても実践できるかはまだ試せていませんので、実戦経験などある方がいましたら教えてください。

デイリースクラムをチームの成長に繋げる

デイリースクラムとは、開発チームのための 15 分間のタイムボックスのイベントである。

スクラム会議の目的は、進捗の障害と解決策をチームで話し合い共有することです。 自分のタスクの進捗を報告するのではなく、なぜ遅れているのか、早く進んでいるなら何を前倒しにできそうかを話し合う場になると、チーム全体の進捗が良くなるので成長に繋がると感じました。

スクラムでは輪になって順番に報告していくスタイルを提案していますが、話すのが苦手な人にも順番が必ず回るという利点もありつつ、自分の番以外には興味を失って黙り込む欠点もあります。 かんばんスタイルでタスクを管理している場合は、人ではなくステータスを順に見てタスクを移動させられるか話し合う方が活気付いて良かったです。 特に物理的なかんばんボードがあるなら、止まっているタスクがあるとみんなが注目してタスクをどうするか話し合いやすいのです。 順番に話していくと人に注目しがちなので、ともすれば個人に責任や問題が転嫁しない工夫が必要です。

スクラムの定義では15分とされていますが、30分程度まで伸ばして振り返りの要素を入れてあると良いように感じています。 スプリントレトロスペクティブまで待つのではなく、改善できることは早く見つけて忘れずに対応するためです。

スプリントレビュー

スクラムでは、チームが一丸になってスプリント毎に設定したゴールを目指します。 そのゴールに辿り着いたかを関係者にお披露目するのがこのレビューです。

スプリントレビューを開催しないスクラムチームの多くは、タスクを消化することがモチベーションに繋がってしまい、個々人のタスク消化に執着することが多いように感じています。 チームが提供できた価値を正しく評価されることが、モチベーションやチームの一体感を育てる最も良い方法だと考えています。

そのため、場合によっては他部門や別チームの人も呼んで盛大にお祝いした方が良いでしょう。 お互いにリラックスした状態で仕事が出来れば、より良い発想や協力関係になっていくからです。 良い議論をするためには、遠慮なく意見を言い合える関係性が不可欠です。

ドーナツとコーヒーを用意して集まるだけでも雰囲気が良くなるかもしれません。

スプリントレトロスペクティブは小まめかつやり過ぎない

スプリントレトロスペクティブは用語が長いので、以下から「振り返り」と呼びます。 短い時間でも1日に1回振り返りをする方が、もっと長い間隔で開催するより効果的だと感じました。 1週間に1回の振り返りでは直近または個々の記憶に残る出来事に引っ張られてしまいます。 チームに関わる問題を意識的に思い出すことは難しく、記憶に残るきっかけも異なるので大事な改善要素が消えていきます。

毎日KPTを書き溜めてチームの振り返りで発表する方法は、気に掛かる点を忘れないという点では有効でしたが、週末に大量のTRYが出ても実践できずに捨ててしまう結果になりました。 中には実施しなくて良いこともあるので、TRYがあれば良いというものでもないですが、無かったことにはせずにTRYの駐車場を作る方が良かったですね。 あとから見回して必要なくなったら取り除けば良いのです。

振り返りはチームが成長する時間です。小まめに丁寧な手入れを続ければ、チームは強くなっていくでしょう。 ただし後から話した方がいいことは後回しにして、話し合いに疲れないくらいの適度な量に調整しておきましょう。 もう疲れたよと誰かが言ったら笑って止められるくらいが丁度いいです。

最後に

スクラムは初めてアジャイル開発する時に強力な助けとなります。 しかし、全員がスクラムしたいという意識が揃わないと上手く回らず、スクラムは合わないとなってしまうことも多いです。 結局のところ、スクラムは開発運用の助けであってチームの関係性を変えるものではないので、コミュニケーションは別枠で考えて大事にしていく必要があります。 そうした問題を乗り越えたチームで働いてみたくて今日もスクラムしています。

クラウドワークスではチームと共に成長したいエンジニアを募集しています。

www.wantedly.com

新卒エンジニアによる配属後2ヶ月の振り返りと、成長するために必要そうなこと。

はじめに

こんにちは
今年の4月に入社した欧州サッカーが大好きな19卒エンジニアの伊達(@b0ntenmaru)です。

大学時代は体育会系の部活で汗を流しながら、独学でプログラミングを勉強してサービスを作ったりしていました。

今年のクラウドワークスの新卒エンジニアは自分一人で、周りのエンジニアはほぼ中途で入社された方という環境で、その中で日々課題ドリブンで成長するために試行錯誤しています。 今回は新人の自分が配属後2ヶ月を振り返りつつ、その中で感じた新人エンジニアが成長するために必要そうなことを書いて行きたいと思います。

配属後2ヶ月で何をやったか

クラウドワークスでは 4月1日 の入社式から2週間の新卒研修を経て、各部署に配属されるのですが、同期の中で唯一エンジニアの自分はエンジニアリング部の玉露チームに配属されました。

玉露チーム

玉露チームはクラウドワークスのマッチング UX をよりよく改善するためのチームで、現在はワーカーがやりたいお仕事をすばやく見つけられるようにお仕事検索画面の再設計を行なっており、最近のリリースではお仕事検索機能に新しい絞り込み検索機能を追加し、それを Vue.js で実装しました。

crowdworks.jp

ちなみに玉露の由来は、過去に存在した玉露チームの前身であるまっちゃ(抹茶)チームからきていて、抹茶よりカフェインの量が多い(進化?)玉露という名前になったそうです。 自分が入社する以前にはなりますが、玉露チームの施策については是非こちらもご覧ください。

qiita.com

qiita.com

機能開発からリリースまでの流れは以下の図のようになっていますが、実装に関しては基本的にモブプログラミング(「以下、「モブプロ」と略します)*1での実装で、その後タスクによっては個人での実装に入っていく、という流れになっています。

※ POとはプロダクトオーナーの略で、スクラム開発における、チームが生み出す成果物の方向性を決める「舵取り役」にあたります。

モブプログラミングとは?

モブプログラミングとは3人以上(2人はペアプログラミング)で1つのプログラムを書く手法のことで、1人がコードを書き、他の人はそれを見ながら意見を言って、プログラムを作っていきます。コードを書く人をドライバー、意見を言う人をナビゲーターと言います。
つまりみんなであーでもない、こーでもない、と言いながらその内の一人がコードを書いていくということですね。 新人の自分からすれば先輩エンジニアのコーディングをみるだけで勉強になりますが、チームで課題に直面するので、その課題を解決するための知見を共有できたりします。

2ヶ月間での失敗

玉露はチームとしての評判もよく、社内 MVP になったりするほどいいチームで、配属後もすぐに馴染むことができ、意見や質問をしやすい環境でした。

ですが最初は技術の話になったりすると周りのエンジニアが何を言っているのか理解できなかったり、自分のタスクだけ時間がかかったり、モブプロではわからないことを教えていただいてもなかなか理解できず、せっかく教えていただいているのに理解できないことに加えて、自分が教えていただいている時間が長くなったことでコードを書く時間がなくなってしまうこともありました。

これらの体験からチームに貢献できていないという気持ちが強くなり、一人で考え込む時間が多くなりました。

そこから「こんなことを聞いていいんだろうか」「相手の時間を奪ってしまうし、もっと調べた方がいいか」とどんどん一人で解決しようと迷走してしまったり、 モブプロ中は後で自分で調べると決め、理解が曖昧なままその場では質問しないということをしてしまいました。

その結果、個人に振られたタスクはリリースには間に合わず、モブプロは実装がどのようになっているか曖昧なまま進んで行きました。

相談してみた

わからないこととの付き合い方に悩んでいる時期に、メンター(@t0yohei)・チームの先輩エンジニア(@mayoxtuna)・マネージャー(@ysk_118)に自分が思っていることを 1 on 1 や slack で相談したところ、

  • 「最初は分からない事が沢山あって当然だから沢山聞いていいよ」
  • 「分からないことを追求することで、チームは学びを共有できる」
  • 「技術に関しては知ってるか知らないかってだけでわからないこととどう付き合うか大事、てか俺もわからんことあるよ」

と言われ、それまでしていた周囲への遠慮などは不要なものだと気づきます。

まとめ

振り返ると、性格的に気軽に聞くということが苦手だったり、学習の仕方だったり、いろいろ要因はありそうですが、それらの根底にあるのは 考えこんでしまい、自分をさらけ出していなかったことでした

なのでこれらを踏まえて、新人が成長していくために必要そうな最初のステップは、悩みすぎず、わからないことをオープンにすることだと思っていて、そこから自分で少しずつできることの幅を広げていけばいいと思っています。

現在試行錯誤している最中ではありますが、1週間前わからなかったことがわかるようになったりするなど、小さな成功体験を積み重ねることができている気がしていますし、これを実行して成長していける環境がクラウドワークスにはあると配属後2ヶ月経って実感しています。

おわりに

いかがでしたでしょうか。まだ自分自身毎日試行錯誤している段階(ブログを書くこともTry)ですが、自分と同じ境遇の方の参考になればと思います。

twitter.com

We're Hiring !

クラウドソーシングのクラウドワークスでは成長し続けていたいエンジニアを募集しています www.wantedly.com

*1:モブプログラミングについてはこちらも是非ご覧くださいengineer.crowdworks.jp

engineer.crowdworks.jp

Gemの更新時に、依存関係でアプリケーションが死んだ際のデバック記録

はじめに

みなさんこんにちは、クラウドワークスのじゅんてつです。

ここしばらく何かしらの更新(gem、rubyrails)をしています。そんな中、rubyの更新をしてたらgemの依存関係で大変な目にあったので事例を紹介しようかと思います。

何があったのか

非同期メール送信処理の例外通知がすべての始まりでした・・・

アプリケーション上で例外が発生するとdelayed_jobにrollbar通知の処理を引き渡していたんですが(仕様)、gem ojとrollbarのバージョンの組み合わせに問題があり(原因)、rollbarの通知でojを呼び出す処理が無限ループを引き起こし(事象)、delayed_jobのプロセスを落としてしまう事象がありました。

Gem補足

delayed_job: メール送信やバッチ処理をバックグラウンドで非同期的に実行するためのgemです。 rollbar: 例外が発生するとリアルタイムに報告をあげてくれる、運用のためのgemです。 oj(Optimized JSON): JSONパーサー

対応のサマリ

この問題はojを3系に上げることで回避できました。

Ruby2.3のEOL対応としてRuby2.4への更新をしていたところ、ojを2.18以上に更新する必要がありました。ojを更新が原因で、delayed_jobのプロセスを落としてしまうことがデバッグして分かりました。

なぜoj最新版の3系ではなく2.18だったのか?

  • rollbar 2.15.0
  • delayed_job 4.0.6
  • oj 2.12.2
    • update to 2.18.6
  • 内製gem

当時は上記のバージョンで稼働していました。この状態から bundle update oj を実行すると内製のgemの依存関係に引きずられて2系の最新2.18.5に更新される状態でした。

spec.add_runtime_dependency "oj", "~> 2.12"

oj 2.18からRuby2.4に対応していたので要件は満たしていましたし、内製のgemを一緒に更新すると話がややこしくなるためまずは2.18に更新することにしました。

どんなエラー通知が飛んできたのか

ojを更新して間もなく、Datadogから「delayed_jobのプロセスが既定値の8件以下ですよ」という通知がslackに届きました。確認してみるとたしかにオンライン用に動いているはずのプロセスがすべて落ちていました。(2件ほど動いているのはバッチ処理用)

通知などのバックグラウンド処理が止まったままはまずいので、詳しい調査よりdelayed_jobのプロセスを回復させることを優先。ほぼ間違いなくoj更新が原因なのでリバート。

プロセスが落ちる原因はrollbarなのでは?

サーバのログを漁ったり、原因の切り分けをしたり、長い長い調査の末に「プロセスが落ちる原因はrollbarなのでは?」という仮説にたどり着きました。アプリケーション例外の発生はサーバログに残っているのに、その通知をするrollbarが動いておらず、その例外発生の時間を境にdelayed_jobのプロセスが落ちていたからです。

rollbarが非常に怪しいことがわかりましたが「どうしてdelayed_jobのプロセスが死ぬのか」を突き止める必要がありました。

まずは検証

rollbarの例外通知が有効化されているステージング環境で検証をしてみたところ、確かにrollbarが通知するタイミングで落ちていることが分かりました。ローカルの開発環境では通知の必要がないため無効化されていたため、有効化してデバッグできるようにしました。

動作確認すると、事象が再現。delayed_jobのプロセスが落ちました。

どうしてdelayed_jobのプロセスが死ぬのか(原因調査)

本当にrollbarなのか、実際に何が起こっているのかを確認するため bundle install されたgemに binding.pry を仕込んで動作させてみました。

Frame number: 0/77

From: /usr/local/bundle/gems/multi_json-1.13.1/lib/multi_json/adapter.rb @ line 26 MultiJson::Adapter.dump:

    24:       def dump(object, options = {})
    25:           binding.pry
 => 26:        instance.dump(object, cached_dump_options(options))
    27:       end

[1] pry(MultiJson::Adapters::Oj)> continue

Frame number: 0/78

From: /usr/local/bundle/gems/multi_json-1.13.1/lib/multi_json/adapters/oj.rb @ line 39 MultiJson::Adapters::Oj#dump:

    37:       def dump(object, options = {})
    38:     binding.pry
 => 39:  options.merge!(:indent => 2) if options[:pretty]
    40:         options[:indent] = options[:indent].to_i if options[:indent]
    41:         ::Oj.dump(object, options)
    42:       end

[1] pry(#<MultiJson::Adapters::Oj>)> continue

Frame number: 0/38

From: /usr/local/bundle/gems/multi_json-1.13.1/lib/multi_json/adapter.rb @ line 26 MultiJson::Adapter.dump:

    24:       def dump(object, options = {})
    25:           binding.pry
 => 26:        instance.dump(object, cached_dump_options(options))
    27:       end

[1] pry(MultiJson::Adapters::Oj)> continue

Frame number: 0/39

From: /usr/local/bundle/gems/multi_json-1.13.1/lib/multi_json/adapters/oj.rb @ line 39 MultiJson::Adapters::Oj#dump:

    37:       def dump(object, options = {})
    38:     binding.pry
 => 39:  options.merge!(:indent => 2) if options[:pretty]
    40:         options[:indent] = options[:indent].to_i if options[:indent]
    41:         ::Oj.dump(object, options)
    42:       end

[1] pry(#<MultiJson::Adapters::Oj>)> continue
rake aborted!
NoMemoryError: Too deeply nested.
/usr/local/bundle/gems/multi_json-1.13.1/lib/multi_json/adapters/oj.rb:41:in `dump'
/usr/local/bundle/gems/multi_json-1.13.1/lib/multi_json/adapters/oj.rb:41:in `dump'
/usr/local/bundle/gems/multi_json-1.13.1/lib/multi_json/adapter.rb:26:in `dump'
/usr/local/bundle/gems/multi_json-1.13.1/lib/multi_json.rb:139:in `dump'
/usr/local/bundle/bundler/gems/rollbar-gem-e3a35525d1b1/lib/rollbar/json.rb:18:in `block in dump'
/usr/local/bundle/gems/multi_json-1.13.1/lib/multi_json.rb:147:in `with_adapter'

原因はrollbarで、multi_jsonからのoj呼び出しがループしていました。 rollbarとojのバージョンの組み合わせに問題があったという結論。 内製gemの依存関係を解消したうえで、oj 3系で試してみたところループが解消され一件落着となりました。

まとめ

普段はgemにpryを仕込んだりしないんですが、今回はRubyのEOL対応の兼ね合いで踏み込んだデバッグをしました。依存関係で古いバージョンで固定されていたため難儀していた印象が強かったです。日頃から依存関係を解消したうえでキャッチアップしていくことが大事だと思いました。

おまけ

gem更新が滞っていた課題から、弊社ではDependabotを導入しました。自動でgemの更新を検知してくれてPRまで作ってくれるようになり、Gemfileが放置されにくい運用になりました。

slackにも更新があったことが通知されるため、いまでは日々gemが更新されています。まだ導入していないみなさんも、一度試してみてはいかがでしょうか。

We're Hiring !

クラウドソーシングのクラウドワークスでは成長し続けていたエンジニアを募集しています www.wantedly.com

crowdworks.jpのエンジニアリング戦略(2019年6月現在)

f:id:yo-iida:20190612101305p:plain:w600

最近は人事のほうにも片足突っ込んでおりエキサイティングな日々を送っております飯田です。

今回は現在のcrowdworks.jpのエンジニアリング戦略についてお伝えできればと思います。

  • 状況の整理
  • これまでの中長期戦略の反省
  • 中長期の技術的投資のための専任チームの発足
    • フロントエンドチーム(チーム名: トリュフ)
    • リファクタリングチーム(チーム名: バグハンター)
  • 継続的バーションアップの浸透
  • 今後の組織戦略
    • エンジニアの役割定義
    • 今期エンジニアリング部の目標
  • 個人的なこと
  • We Are Hiring

状況の整理

crowdworks.jpはサービスインから7年が経過し、モノリシックなRailsアプリケーションのコードは30万行を超える規模感に成長しています。

f:id:yo-iida:20190611210040p:plain:w600

一方で、コード行数の増加量はここ最近の傾向としては鈍化しており、ファイル変更数の推移も低下の傾向となっています。以前から巨大なクラスの変更が難しいという課題はありましたが、最近の傾向からは日常的な施策としても大きな打ち手を打ちづらくなって来ているという課題が顕著になってきました。

f:id:yo-iida:20190611210036p:plain:w600

ここ最近は何を進めるにしても事前にそれなりの規模のリファクタリングを行なっているチームが増えてきているように感じています。 現在短期施策を担うチームはプロダクトオーナーがチームにコミットしていて、組織的プロダクトマネジメントも機能する体制にはなりましたが、施策をシャープにできてもリリースが追いつかなければ事業の持続性は作れません。

また、フロントエンドに関してもここ数年大きな進化を遂げられていない課題感があります。crowdworks.jpのフロントエンドはRailsと密結合になっており、サーバーサイドのデータをViewで受け渡しする実装が画面単位でもグローバルでも様々なアプローチで実装されていました。詳細は、元クラウドワークス社員で現在副業としてフロントエンド開発を強力に支援してくれている @suusan2go の記事が詳しいですが*1、フロントエンドもなかなかに技術的負債がたまり開発速度が低下した結果、レガシーで無秩序なUIが増えてデザイナー・エンジニア双方での懸念が高まりました。

engineer.crowdworks.jp

インフラレイヤーに関してはSREのチームメンバーが主体となって開発を進めていて、現在の大きなテーマとしては本番環境のDocker化です。動かすアプリケーションの規模感に準じてインフラも複雑になりがちで、例えばログの出力であったり、メール送信の処理であったり、コンテナに移し替えるにあたりアプリケーションの広範囲に渡って設定の変更が必要になります。SREのメンバーはアプリケーションにも強いメンバーが多く、アプリケーション側の修正までチーム完結で動けますが、トイルなどの課題も多い中で地道に前に進んでいる状況です。

*1:@suusan2goことスズケンさんは退職されてからも難易度の高い技術課題に取り組んでくれており本当に有難い限りです。

続きを読む

© 2016 CrowdWorks, Inc., All rights reserved.