最近は人事のほうにも片足突っ込んでおりエキサイティングな日々を送っております飯田です。
今回は現在のcrowdworks.jpのエンジニアリング戦略についてお伝えできればと思います。
状況の整理
crowdworks.jpはサービスインから7年が経過し、モノリシックなRailsアプリケーションのコードは30万行を超える規模感に成長しています。
一方で、コード行数の増加量はここ最近の傾向としては鈍化しており、ファイル変更数の推移も低下の傾向となっています。以前から巨大なクラスの変更が難しいという課題はありましたが、最近の傾向からは日常的な施策としても大きな打ち手を打ちづらくなって来ているという課題が顕著になってきました。
ここ最近は何を進めるにしても事前にそれなりの規模のリファクタリングを行なっているチームが増えてきているように感じています。 現在短期施策を担うチームはプロダクトオーナーがチームにコミットしていて、組織的プロダクトマネジメントも機能する体制にはなりましたが、施策をシャープにできてもリリースが追いつかなければ事業の持続性は作れません。
また、フロントエンドに関してもここ数年大きな進化を遂げられていない課題感があります。crowdworks.jpのフロントエンドはRailsと密結合になっており、サーバーサイドのデータをViewで受け渡しする実装が画面単位でもグローバルでも様々なアプローチで実装されていました。詳細は、元クラウドワークス社員で現在副業としてフロントエンド開発を強力に支援してくれている @suusan2go の記事が詳しいですが*1、フロントエンドもなかなかに技術的負債がたまり開発速度が低下した結果、レガシーで無秩序なUIが増えてデザイナー・エンジニア双方での懸念が高まりました。
インフラレイヤーに関してはSREのチームメンバーが主体となって開発を進めていて、現在の大きなテーマとしては本番環境のDocker化です。動かすアプリケーションの規模感に準じてインフラも複雑になりがちで、例えばログの出力であったり、メール送信の処理であったり、コンテナに移し替えるにあたりアプリケーションの広範囲に渡って設定の変更が必要になります。SREのメンバーはアプリケーションにも強いメンバーが多く、アプリケーション側の修正までチーム完結で動けますが、トイルなどの課題も多い中で地道に前に進んでいる状況です。
これまでの中長期戦略の反省
現状を踏まえ直近優先的に手を打つべき課題を整理すると、アプリケーションの中長期の開発のための検討をできる体制を作ることが重要そうだという判断になりました。
現在は予算達成のためのいろいろな施策も各チームでリファクタリングを挟みながら前に進められていますが、これまでは「気づいた人が改善する」に頼ってしまうところが大きく、ベストエフォート任せで持続性が維持できていなかったところがあります。このまま全体感を持たずに前に進んでいけばいずれどこかで本当に身動きがとれなくなってしまうと考えています。
ちなみに、これまでアプリケーションの中長期視点の開発の検討が行われなかったかと言えばそうではなく、たとえばCW Rails Wayという細かな設計ガイドラインをまとめたドキュメントが作られたこともありました。
しかしながら、こういったドキュメントのメンテナンスや布教を続けることは簡単ではなく、オーナーシップやナレッジの積み重ねなどが人に依存してしまうことで持続性が保てなくなりがちです。持続性を作り出すには人に依存しない仕組みを考える必要があります。*2
また、使っている言語、フレームワーク、ライブラリ、ミドルウェアのバージョンアップについても必要になってから動くのではなく日常的な活動として根付かせる必要があると考えています。これまではそういった活動は人に依存する形になっており、プロダクトマネジメントとしても計画的に織り込むことができていなかった反省があります。
中長期の技術的投資のための専任チームの発足
これまでの反省を踏まえ、今期は新たに2つの中長期ミッションを担うチームを発足しました。
- デザインシステムの導入とRailsのフロントエンドの持続的開発を目指すフロントエンドチーム
- 低凝集で密結合な実装を高凝集で疎結合な実装に変えていき、大規模Railsアプリケーションの持続的開発を目指すリファクタリングチーム
二つのチームの背景で共通していることは、 「チーム化することでミッションを明確にして集中できる環境を作り、ナレッジの蓄積と進化を持続的にするため」 です。
扱うものがプロダクト全体に関わる大きなテーマであるのに別のチームに属しながら空いた時間でベストエフォートで進めるやり方では成果は出しづらく、評価も難しいものとなります。
今回マネジメントとして意思決定した観点は、 「熱意のある人が熱意を注ぎたいものをミッションとして掲げ、それに集中できる状態を作ること」 です。そうすることで、一過性のものではなく組織全体まで浸透しきるか、チーム内で引き継がれて活動が継続するような状態までやりきれることを期待しています。
フロントエンドチーム(チーム名: トリュフ)
フロントエンドチームは2018年10月から活動していて、当初Team Rebuild Frontendと呼ばれており、頭文字のTRFから転じて現在はトリュフというチーム名に落ち着いています。
このチームは、「正しいデザインの共通認識をエンジニアとデザイナーで持つことができ、正しいデザインをすばやくプロダクトに反映できる環境をつくる。」というミッションを掲げています。
具体的に取り組んでいることは、
の2点です。
エンジニアとデザイナーの間の存在としてイチからデザインシステムを検討していくことは非常にチャレンジングな仕事ですが、フロントエンドのインフラを作るべく果敢にトライを進めています。
メンバーのみーた(@earlgrayMK)が書いてくれたブログはこちら。
実際にチームメンバーの話を聞いてみたいという方はこちらからエントリーください。
リファクタリングチーム(チーム名: バグハンター)
リファクタリングチームは2019年4月から発足したチームです。チーム名はチームリーダーである @MinoDriven の作ったバグをテーマにしたゲームに由来しています。僕は勝手に「全てのバグを生まれる前から消し去るチーム」と呼んでいますw
このチームは、「リファクタリングして開発生産性を向上し、「持続可能な成長」への道筋を作る」ことをミッションとしています。
解決しようとしている課題は、
- 開発生産性
- コードを変更するにあたり、コードの分析コストと変更検討コストが大きく、生産性に課題。
- リファクタリングにより理解容易性向上、影響範囲局所化等を狙い、開発生産性を高める。
- エンジニアの技術力
- 粗悪な設計は質の高い設計導入を阻む。
- エンジニアが粗悪な設計を真似、学習する可能性があり、スキル低下の要因に。
- リファクタリングにより質の高い設計の導入を容易にし、またお手本となるコードによりエンジニアのスキル向上を狙う。
- crowdworks.jpの信頼性
- バグを埋め込みやすい構造。重大インシデント化した場合crowdworks.jpの信頼性を毀損。
- バグを埋め込みにくい構造へ昇華させ、弊社の持続可能成長性を向上させる。
になります。
戦略的にはドメイン駆動設計をベースに、コンテキスト境界の分析や、ドメインオブジェクトの抽出をトライし始めている状況です。
チームのメトリクスとしては、Code Climateを利用しTechnical Debt(技術的負債)をKPIとして追ってみることを決めています。
実際にチームメンバーの話を聞いてみたいという方はこちらからエントリーください。
継続的バーションアップの浸透
バージョンアップの対応は、その対象について深い知識が求められ属人化しやすい仕事のひとつだと思っています。 これまでも施策が優先されがちで、後手後手対応で対応が膨らむといったケースはたくさんありました。
しかしながら30万行を超えるコードベースになるともはや誰かが頑張ればどうにかなるというレベルはとっくに超えているため、プロダクトマネジメント的にもバージョンアップが後手に回ることのリスクはなんなのかといった意識レベルでの向上や、普段から使っているフレームワークのIssueやPull Requestを読むなどの動向を把握し、それを取り込んでいく活動が必要になってきます。
最近はDependabotが導入されるなど少しずつ改善活動が進んでいます。
今後の組織戦略
改めて、crowdworks.jpの短期、中期、長期観点で担うミッション別に組織構成を整理すると以下のような構成を目指していこうと考えています。
| 現在のチーム | ミッション | 人数比 | |
|---|---|---|---|
| 短期 | マッチング改善、決済周りの改善などUXに関わる複数のチーム | 半年〜1年でその期の予算や法律的な期限にコミットする | 3 |
| 中期 | フロントエンドチーム、リファクタリングチーム | 1年〜2年で次の期以降の開発・事業の持続性を高める | 2 |
| 長期 | SREチーム | 2年〜3年で次の期以降の開発・事業の持続性を高める | 1 |
※なお、上記に加え新しい事業創出のトライとして新規事業検討のチームも存在します。
crowdworks.jpに関わるエンジニアは現在25名ほどとなっていますが、今後事業・プロダクトを次のフェーズに持っていくためにエンジニアリング体制の増強を考えています。
大きな打ち手を打つためには大きな投資が必要になるわけですが、目下の予算の達成もマストとなるためバランスとしては上記のようなイメージが良いかなと考えています。
エンジニアの役割定義
今回、エンジニアの役割定義についてもアップデートを行いました。クラウドワークスにおける役割定義とは、エンジニアのキャリア設計の軸のガイドラインとなるドキュメントのことを指しています。（外向けに公開するのはおそらく初）
この表は給与レンジと連動した等級の概念と各専門分野での期待される役割のマトリックスとなります。
これまでは、この役割定義の運用はどれかひとつの道を選ぶというニュアンスでコミュニケーションをしていましたが、今回どれかひとつではなく複合的な組み合わせで考えられるガイドラインという位置付けに変更しました。*3
背景として、実際技術の深掘りに長けていながら組織のマネジメントに関わる人もいるし、デザインに関心をもってサービス開発を進めている人もおり、実態としてグラデーションで仕事をするケースのほうが多く、むしろ、自らの領域を固定化せずに幅広く仕事をすることを推奨しているということもあり実態に合わせる形としました。
また、今回大きなポイントとして、UXLeadというデザイナーとエンジニアの中間に位置するキャリア軸を新設しました。これはフロントエンドチームの発足に伴い、組織的にデザイナーとエンジニアの架け橋となる存在のアイデンティティを作り出していきたいという意思を反映した形になります。
また、これまではキャリア軸として技術系のTechLeadと組織系のManagerが2大イメージとして強いところが否めませんでした。しかしながら、どちらの志向性もしっくりこないがサービスが好きで深いドメイン知識を持つ人や、サポートと連動した迅速な改善が得意な人は、キャリアとしての軸がうまく示せていない課題があったため、プロダクト開発・サービス開発における突き詰め方をServiceLeadとして再定義しました。
現在の人事評価のベースはMBOで特に目新しいことはないですが、組織構成とキャリア軸は実態に合わせて整理を行いました。人事制度的にはより本質を向いてそれぞれの仕事やスキルがうまく評価されるよう今後もフレキシブルにアップデートしていきます。
今期エンジニアリング部の目標
以上を総括する形になりますが、今期はシステムと組織の持続性を高めていくために部としては以下のような目標を設定しています。
- 「実感できる持続的なシステム」
- システムの持続性を測る指標が複数の観点で得られていること
- 指標をもとに改善活動に着手できていること
- 「組織のスケールと持続性向上」
- ボトルネックが解消されスケールする状態であること
- オンボーディングコストを下げ採用しやすい状態にすること
- 誰かに勧められる組織にすること
この目標は私がオーナーシップを持ち各チーム・各メンバーと対話をしながら推進していく形になります。
個人的なこと
5月1日より執行役員となり1ヶ月が経ちました。まだ体に馴染んでおらずどんな責務を果たせばよいのかをぐるぐる考えている日々です。
いくつか明確になってきていることは、
- 事業と組織と技術の解像度を高め、適切な戦略を言語化し、明確な期待として伝えていく
- 全社での全体最適を考え事業が持続的となるようなエンジニアリングを考える
- 長期思考で大きな意思決定を行い発信する
- 社外にプロダクト、組織、技術の強みを発信する
くらいでしょうか。
特に、メッセージとして伝えていくことの重要さと自分自身そこが不足していることに気づいてしまい苦境に立たされています。。
また、長期的視点で戦略を作り込むこともまだまだやれておらず、目の前のことで忙殺されているところがあるのですが、自分の存在を価値に変えられるとしたら、思考をメッセージに変えていくしかないのかな、と今は思っています。
今回エンジニアリング戦略をエンジニアブログで書こうと考えたのは思考の整理の時間を強制的に作ることと、それを発信することで社内外へのメッセージになるかなと考えたからです。また、ある種のプレスリリース感もあるので、次回はもっと良い取り組みを発信したり、質を高めたいという欲求が働いて良いプレッシャーになるかなと思っています。
