こんにちは！トラストバンクプロダクト開発グループマネージャーの ohataです
年末も近づいてきたので、振り返りも兼ねてJOINしてからの開発組織に変革について書いていきたと思います。
「プロジェクト開発視点」と「価値を創る視点」の違い
タイトルの定義について、自分の考えを整理しておきます
プロジェクト開発視点
- 目的：決められた要件を、決められた期日までに実装・リリースすること
- 成果指標：リリースした機能の数、消化した人月、予定通りに完了したかどうか
- 開発スタイル：必要な時に必要な人をアサインし、プロジェクト単位で開発を進める
- 良いと思うところ：スタートアップなど[まず作らなきゃ始まらない！]場合などマッチする
価値を創る視点
- 目的：事業・市場、ユーザー、運用を意識して、戦略的なエンジニアリングを行う
- 成果指標：ユーザーへの価値提供スピード、品質、改善、運用のしやすさ
- 開発スタイル：継続的にプロダクトを担当するチームが、主体的に開発・運用する
- 良いと思うところ：運用面や継続活動のフェーズに向いている
JOINしてからの活動年表
2023年11月にJOINしたので2年が過ぎました。
組織の変革を時系列にまとめてみました。
当時の開発状況と課題
入社後すぐに全社員エンジニアと1on1をしました。コミュニケーションを取るの事が目的だったのですが、現状組織の課題や状態を多くの方が教えてくれました。課題の中で開発メンバーがプロジェクト管理に時間が割かれているという話を聞きました。そのためエンジニアリング活動に割く時間が限られてしまい多くの方が悩んでいました。プロジェクト主体で施策が実行されて効率的なチームの場合、技術的負債や[ビルドトラップ]の懸念もあると思い、まずはJOINしたての視点を活かして現状把握に注力するようにしました。
アサイン制の課題
当時の開発体制は、業務委託の方を中心としたアサイン制でした。必要な時に必要な人をプロジェクトに割り当てる。機能開発を推進していく意味では非常に効率的に見えました。
一方で継続的に運用を行うにはかなり運用しずらい体制だと感じました。アサイン制の問題は、短期的な効率と長期的な価値が相反することにあります。
期間限定のアサインでは「作って終わり」になりがちです。運用のことを考えたり、将来の改修に備えてコードを整えたりするインセンティブが働きません。目の前の機能を予定通りリリースすることが最優先になり、リリース後の改善を行い成長させていくというマインドが欠落します。プロダクトを継続的に改善していくには、[リリースが終わり]ではなく[リリースが始まり]と言うマインドでいないとユーザーの反応を見ながら改善が追えなくなり [仕様だから]と言う言葉でコミュニケーションが終わってしまいます。本来は[仕様だけど、反応悪いから見直す必要ありそう]と言うマインドになるべきです。また、知識の属人化による弊害もあります。ある機能を作った人が去った後、別の人がその箇所を触ろうとすると、理解するだけで膨大な時間がかかります。キャッチアップコストが開発速度の低下につながります。
こうした環境では、新しい挑戦よりも既存の設計で何とかしようという守りのマインドが支配的になります。「価値を生み出す」ことではなく「機能をリリースする」ことが目的化していく。これがビルドトラップのリスクだと考えています。
JOINした状況では何名かのエンジニアが草の根活動的に頑張ってくれていましたが、組織として持続可能な状態になっていないように感じました。
組織のケイパビリティを十分に活かせない
技術的負債がもたらす最も深刻な問題は、エンジニアと事業側の間に生まれる認識のズレです。例えば綺麗に設計されていれば1ヶ月で終わる開発があるとします。しかし負債が積まれたコードでは、過去にコピペで作られた箇所が多く、似たようなコードが散在している。1箇所を変えると他の箇所にも影響が及び、テスト範囲が膨れ上がる。結果として、見積もりは3ヶ月になります。
事業側から見れば「なぜこんな簡単そうな機能に3ヶ月もかかるのか」という疑問が生まれます。エンジニアから見れば「影響範囲を理解していない」という不満が募ります。相互理解が得られないまま、コミュニケーションが良くない方向に流れていきます。技術的負債はシステムのメンテナンス性や不具合発生率を中心に語られることが多いですが、一番の課題は組織のケイパビリティがコミュニケーションの壁によって最大化されない。事だと思っています。 厄介なのがこの問題が開発フローだけではわからず、全体視点で見ないと見えにくい点です。エンジニアは「技術的負債」という言葉で説明しようとしますが、それが具体的に何を意味し、どれほどのインパクトがあるのか、事業側には伝わりにくいのです。せっかく良い仲間が集まっている組織でもコミュニケーションの壁により、各自のケイパビリティをいかせていないのは非常に勿体無いと思います。
課題を解決するのではなく目指す組織から考える
課題にフォーカスして解決していくのもアプローチとして考えましたが、局所的な解決にフォーカスしてしまうと別のところでも問題が発生する可能性も高いと感じました。アサイン制から変えていくには、リソース効率からフロー効率に変えていく必要があると感じました。大きなマインドチェンジが必要であるなら新しい方針で進めた方が最終的に早いと感じ[目指す組織]からブレイクダウンしていく事にしました。
そのため、方針を明確に打ち出して理解をしてもらってから進めるようにしました。
活動基本方針の策定
まずは自分の意思表示も含めて、活動基本方針を策定しました
改善のHowを自分達で作るのは時間も手間もかかり理想で終わってしまう可能性もある。 今は業界が成熟されてきて有識者・経験者の知恵がフレームワーク化されてきているので、一般的なノウハウを取り入れアクションを優先する。
- 世に広まっている知識・経験を身につけることで、全員のスキルアップの一助になる
- コミュニケーションコストの削減 ( [ググってみます] という言葉で内容が理解できる状態)
ハレーションが一番怖いところではありますが、説明より実感しないとわからない部分はあるので、弊社の行動指針の[Try, Try, Try]でアクションを優先する方針をとりました。 自分達でHowを模索する際に、一般的なフレームワークや他社を参考にするとは思うので、How考察よりアクションが大事という判断です。 また、定量的に判断できるように、開発生産性の可視化にも注力しました
フロー効率を実現するための開発体制の変更 (Agileチーム化, Scrumイベントの導入)
フロー効率を実現するために、Agile開発を導入しました。チームで動く事により、[誰がどれだけ作れたか？]ではなく[何をどれだけ作れたか]にフォーカスしたいからです。この考えはScrumとの相性が良かったので、Scrumイベント採用する事にしました。 Scrumを取り入れた事により、Retrospectiveなどで改善をチーム内で行う事により誰かが複数のチームを管理するということがなくなりました。 以前は、リーダーが事業側と要件を詰め、それをチームに展開するスタイルでした。しかし今は、要件の詰めにはなるべくチーム全員で参加するようにしています。これによりシフトレフトの動きも加速し、全員が同じ情報を共有することができるようになりました。要件を詰めるとことから参加する事により開発時のコミュニケーションコストを削減するようにしています。そして、リーダーが御用聞きにならないことで、チームで成果を意識しながら、自分もエンジニアリングに携われる。このバランスが取れることで、キャリアのミスマッチも起きにくくなっていると感じています。
チャプター、ギルドという自律の仕組み (Spotifyモデル)
取り入れた「仕組み」の中で、特に効果が大きかったのがSpotifyモデルのチャプターとギルドの概念でした。同じ技術領域のメンバーが集まるコミュニティに名称をつけることで組織として[チャプター活動を推進します]といった場合にみんなに意味が通じるようになりました。
特にフロントエンドチャプターでは、チームを越えてFEエンジニアが集まり、今後のFE技術の方向性や、現在抱えている技術的負債の解消について議論し、自主的に活動してくれています。
また負債や業務改善にモチベーションのあるメンバーでギルド活動も活発になりました。ギルド活動によって、多くの改善が実務にインストールされました
- 業務改善ギルド (お問い合わせの効率化)
- ログ改善ギルド (不要なログ整理により、監視効率の向上)
- AI推進ギルド(FAITH)・・・生成AI推進ギルド
トップダウンで「これをやろう！」というコミュニケーションではなく、モチベーション駆動の活動が自然発生するようになったことは、組織として大きな進化だと感じています。
仲間を集める ── 採用への注力
チーム制を推進していくために大きな壁となっていたのは社内エンジニアが少ないことでした。弊社の場合は業務委託の方も非常に協力的で、ドメイン知識もあり大変助けられています。しかし社内のビジョンや組織改善を行うと言う面では採用の強化に注力していく必要があると感じていました。何より自分が一緒に作り上げていく仲間が増えた方が楽しく取り組めるという想いがあったからです。
採用に懸けた時間
振り返ってみると、入社してからの半年は半分近くを採用に費やしていたかもしれません。人事も積極的に協力していただいたので非常に前向きに活動に取り組む事ができ、2年間で300件以上のカジュアル面談、面接を行う事ができ多くの方にお会いすることができました。
16名の仲間が新たにJOIN！
採用に関してはチーム全体で動けたように感じています。人事の方が各フェーズで候補者のフィードバックを細かく整理してくれるので、カジュアル面談の資料を更新したり、説明順の検討や会うための事前準備(全体を説明すべきか、深ぼった話に時間を使うか)を丁寧に行うことができました。採用活動の結果、新たに16名の方がJOINしてくれました。非常にありがたい事ですが人数が増えただけでなく、同じ価値観を共有できるメンバーが集まってくれた事が本当によかったと思っています。「技術向上や関心」に重きを置く方は多いですが、プラスして「プロダクトを良くする。地域の力になる」と言うマインドを持っている方が多く入社してくれました。新しい仲間もそうですが、既存メンバーの方が面接対応、丁寧なオンボーディングやサポートしれくれた事が本当に心強かったです。
データドリブンな改善 ──「価値」を可視化する (FourKeys)
なぜ可視化が必要だったのか
エンジニアとしても開発効率がよくなった、悪くなったというのが定性的にしか語ることができず、改善する際に指標も持ちにくかったことがあります。この状態では、継続的な改善は難しく、客観的に状態を把握し、次のアクションを判断できる仕組みが必要でした。 エンジニア組織としてどういう状態が正しいのか、自分たちの行動がどのような効果を生み出したのかを可視化するようにしました。プロジェクト数などを指標として用いることはできますが、難易度の違いや開発以外の影響を受けることが多いため、まずは開発観点の指標を見る事にしました。
FourKeysの導入
ここも既存フレームワークにのっとりDevOpsで定義されているハイパフォーマーチームを目標にFourKeysを導入する事にしました。計測の仕組みを作るより改善に重きをおきたいので、計測にはFindy Team+を活用する事にしました。
指標の位置付け
FourKeysの役割は「数字を上げる」ではなく「現在のチームの状態」として位置づけました。当然数値目標も設定しましたが、FourKeysの直接的な数字ではなくもう一つブレイクダウンした数字を細かく追うようにしています。FindyTeam+では[サイクルタイム分析]という開発フローにフォーカスした指標を見れるので主体は[サイクルタイム分析]を見ています。
数字を見るマインドについて
数字を見出すとハックする人もいるのでは？と考えられますが、数字を見る文化がなかったところからするとハックするほど数字を見てくれるなら良いかなと個人的には思っています。これは[数字見ましょう！]よりエンジニアとして意識高く数字を見る原動力にもなるかなとか思っています。また詳細数字を追うようにしているので、局所的なハックをしても全体のどこかの数字が悪化するので、自然とハックはなくなると思います。今まで目標値というものがなかったこともあり、特にハックしようというような事はチームで起きておらず、常に原因を考えられるとても良い文化ができました✨
数字を追うのではなく、改善指標として利用する
可視化を導入して最も良かったのは、チームの振り返り（レトロスペクティブ）の質が上がったことです。 以前は感覚的な議論で終わっていました。「レビューが遅い気がする」「いや、そうでもないと思う。開発の時間が確保できていて良い」。今は、実際の数字を見ながら「今週のレビュー待ち時間、平均で○時間かかってるね」「先週より増えてるのはなぜだろう」。客観的なデータがあることで、建設的な議論ができるようになりました。ここで活きてくるのが、活動基本方針です。「リソース効率ではなく、フロー効率を重視する」という方針を掲げていたからこそ、この議論がスムーズに進みます。
※ 主要プロダクトチームの変化
レビュー速度を改善するだけでも、価値を届ける速度を上げることができる
体制変更と可視化によるマインドチェンジ
要件を整理したときに、「一番早く価値を届けられるとしたら、今の優先順位はこれで合ってる？」という考え方が徐々に浸透してきました。 レビューが終わればリリースできる状態なら、自分のタスクを止めてでもレビューを優先した方が、価値を届けるまでの時間は短くなります。後でまとめてレビューしようとすると、コンテキストを思い出すのに時間がかかり、フィードバックの質も下がり、結果的にゴール達成が遠のきます。PRが大きいと、レビューするためにまとまった時間を確保する必要があり、すぐには着手できません。であれば、小さなPRを意識した方がいいのではないか。このように、「価値を届ける」を基準に考えると、すべての行動が論理的につながってきます。そして面白いことに、価値を意識した事で、FourKeysやサイクルタイム分析の数値も自然と改善されました。数字を追いかけるのではなく、価値を意識する。その結果を数字で確認する。レトロで「印象に残っているけど、今回だけだったね」「良いと思ってたけど、この辺も改善できそう」といった気づきが生まれ、チームとして次のアクションを決められる。この好循環が回り始めてきました。
事業成長速度に対し、「単なる追従」から「成長を加速させるレバレッジ」へ
チームが自律的にコミット力を発揮して、チャプター・ギルド活動など有志の活動も当たり前になってきました。またデータ駆動のプロセス改善も当たり前になってきたので、ここから大きく次のステージに進めることができるようになってきました。
事業側とのコミュニケーション
今までリファクタやリアーキテキチャについて定性的な話が多かったのですが、今後の開発効率や品質などを数字で示すことができるようになったため、一定のリソースを割くことにも合意が取れるようになりました。役割が異なる部署にもロジカルに説明できる基盤が整ってきたことは非常に大きな成果だと思っています。
技術スタックの全面刷新
サービス立ち上げから13年経過し、保守性や開発体験の面で課題が顕在化していました。モダンな技術を採用できない環境は競争的にも大きなマイナスになります。しかし、技術スタックの刷新は大きなリスクを伴います。組織が不安定な状態では、とても踏み切れる状況にはありませんでした。計画的に、段階的に、技術スタックの刷新を進められるようになりました。
既にこちらの記事で @dest12217 さんが書いて入れているようにアーキテクチャの見直しに大きく踏み出すことができています。
新アーキテクチャに移行しているチームと移行していないチームではPR数が2倍近く違うという数字的根拠も出ています。つまり事業計画や戦略をより意識することのより、先行して新アーキテクチャに移行し、施策が走った時には最速で勝ちを提供できるようなアプローチができるようになります。これを「戦略的エンジニアリング」と位置付けています。
戦略的な会話が生まれるようになった
- 「A機能は3ヶ月後に大きな改修が入りそうだから、今のうちにコードを整理しておこう」
- 「B機能はすぐに改善が入る予定だから、リファクタリングは改善後にした方が効率的だね」
おわりに
今は戦略的なリアーキテクチャに取り組み始めたばかりですが、色々なところで改善活動が進んでいて自分としては大きな学びになっています。 弊社でも生成AIの活用を推進しており、今後大きく開発組織のアプローチが変わるかもしれません。今を正解と思わず、常に市場の動きをキャッチアップして今の活動を止めないように頑張りたいと思います。
