2024年11月15日、ファインディ株式会社が主催するイベント「開発生産性Kaigi スタートアップが目指す、開発と事業成長の接続〜価値創造への挑戦〜」が開催されました。

本記事では、PharmaX株式会社でエンジニアリングマネージャーを務める古家 大さんによるセッション「開発チームから始める『学習する組織』に成長するための取り組み」の内容をお届けします。

■登壇者プロフィール 古家 大(@enzerubank) PharmaX株式会社 エンジニアリングマネージャー

ニフティ株式会社に新卒入社後、バックエンドエンジニアとして開発を担当し、ベトナムのオフショア開発組織の立ち上げを経験。 オフショア開発組織の国内チーム統合とリプレースまでリードエンジニアとして主導。2016年よりフリーランスに転向。多くの企業でエンジニアとして豊富な経験を積んだ後、PharmaX株式会社に入社し、 データ分析基盤の構築や薬局DXを支援するサービスのフロントエンド開発のリードエンジニアを務めつつ、アジャイルの推進活動を行う。 2023年からエンジニアリングマネージャーに就任。「一人一人のモチベーションを引き出し、エンジニアとしての成長と事業の成長を両立すること」を目指し、エンジニアが成長する機会を創出できるような最高のプロダクト・組織を生み出すことに日々向き合っている。

既存事業の組織改善として、“学習する組織”を目指す

古家：「開発チームから始める『学習する組織』に成長するための取り組み」というタイトルで発表させていただきます。古家 大と申します。PharmaXに入って3年ほどになり、昨年からEMを担当しています。

PharmaXは、「かかりつけの先生がそばにいる安心を」というビジョンを掲げ、toCの医療サービスをつくっているスタートアップです。かかりつけ医療ブランドYOJOの1つのプロダクトとして、オンラインYOJO薬局を開発・運営しています。

今PharmaXでは事業横断のEMとして、エンジニア組織全体の成果最大化にコミットしています。今日は、既存事業の組織改善に取り組んできた話をします。伝えたいことは、学習する組織の考え方はとても良いものだということ。今回は開発チームの事例ですが、他のチームでも使えますし、個人の思考ツールとしても非常に便利だと思っています。

古家：私がチームに入った当時は、別のチームで新規事業を検討しているときで、プロダクトオーナーが忙しく、チームのなかにあまりいない状況でした。かつ、チームはまだ自律できておらず、チームとして今後何をやっていけばいいのか、方針が見えていませんでした。

もともと理想としては、高速に仮説検証を回せるプロダクトチームを目指していたのですが、現実とのギャップが激しいので、まずは開発チーム単体で良い状態にするところから目指していくことにしました。

開発チームの定義は、よくあるクロスファンクショナルチームではなく、完全にファンクショナルチームにしています。これは、まずチームづくりの難易度を下げるために、意図的にエンジニアのみに絞りました。のちのち9人以下のクロスファンクショナルチームをつくりたかったので、一旦エンジニアのみで5人以下の構成にしました。

古家：チームが良い状態とは、事業と人に関する成果を両立させていることだと定義しました。事業成果を出しながら、組織の持続可能性を高めているチームが良いチームだと、私は考えています。

事業成果を出しつつ、走りながらチームを変えていきたいと考えていました。そこで学習についていろいろ調べていたところ、最終的に『学習する組織』という本に行き当たりました。

『学習する組織』での学習の定義は、「望んでいる結果を出す能力を伸ばすこと」とされています。自分の欲しい結果は、開発チームを良い状態にすることだったので、このために必要な能力を学習していきたいと考えました。

この学習を継続的に実現している組織が、学習する組織です。まさに自分が求めていた組織の形はこれだと感じ、この組織論を実践していこうと決めました。

“学習する組織”の5つの学習領域と取り組んできたこと

古家：学習する組織を実践していくなかで、学ぶべき領域は5つあります。1つ目は、「共有ビジョン」。チームの目的や目指すべき理想像のことですね。まずは、このビジョンを立てるために動きました。最初にやったのは、自分たち開発チームが組織のなかで置かれている状況を理解することです。

開発生産性の図で表すと、自分たちはレベル1の生産性をアウトプットする存在です。開発の指標はさまざまありますが、プロダクト組織から見たときに興味があるのは、工数だけだよねということを認識しました。

ベロシティ、Four Keys、プルリク数といったものは、土台としてはすごく重要ではあるのですが、外部から見たときはあまり興味がないものだということを、はっきりさせた形になります。

結局、施策はリリースしないと上手くいくかわからないので、開発チームの役割はどこまでいっても工数を短縮して試行回数を増やすことでしかないと、改めてチームの目的に設定しました。

古家：次は、「システム思考」ですね。これは、システムのように複数の項目の相互関連性を考えていくことです。これに関してはまず、開発生産性を高めていくために、DORA Core Modelという理論の図を理解することから始めました。

この図は、開発パフォーマンスとFour Keysには、非常に強い相関があることを示しています。そして、Four Keysだけでなく、技術的ケイパビリティもセットで高めていくことが必要だということがわかります。

古家：次に、技術的ケイパビリティを高めていくために現状の分析を行いました。現状を見ると、特にコード品質が低いことと自動テストがないことが工数に大きな影響を与えていると、エンジニア同士で議論して認識を合わせていきました。

この議論の結果をもとに、特に強化したい技術的ケイパビリティは、コード保守性、疎結合アーキテクチャ、テスト自動化の3つであると特定して、これを伸ばせばパフォーマンスが上がるはずだということが、チームとして見えてきました。

古家：次は、「自己マスタリー」ですね。これは個々のメンバーが自己研鑽を続け、成長していくことを指します。各々の自己マスタリーを高めていくために、目標設定について考えました。まず考えたのが、会社から求められている成果であるパフォーマンス目標と、その成果を出すために必要な能力を高めるマスタリー目標で分ける方針です。

パフォーマンスとしては、工数を短縮化していかなければならないので、レベル1生産性のFour Keysの目標値を決め、それを達成することをチームのパフォーマンス目標にしました。そして、Four Keysに影響を与える要素を高めることを、個人のパフォーマンス目標に設定し、それを達成することを目指していきました。

古家：マスタリー目標は、自分の能力を高めるためのものですが、目的はチームのパフォーマンスを高めることなので、その紐づけを要素分解し、予実が乖離するタスクに必要な能力を伸ばすと決めました。マスタリー目標の運用としては、1on1で目標設定と振り返りを実施して学習するループを回しています。

ただ、これをやってみたところ、1on1は目標の進捗確認以外にも話すことがいろいろとあるので、ループを回すにはスピードが遅いという気づきが最近ありました。なので、スクラムイベントのレトロで振り返りをして、スプリントゴールに入れるといったやり方のほうがいいかなと考えていて、次はそうしようと思っています。

古家：自己マスタリーを高めるための支援は、チームとしてさまざま行っています。月1で技術系のLT会を実施して、知識共有の場を設けたりしています。振り返りと改善に関しては、現状1on1とレトロのKPTしかできていないので要改善かなと思っています。

他社さんでいろいろな振り返りを試している事例がありますが、それはこの自己マスタリー向上に効いてくる活動だと思っているので、弊社でもいろんな種類の振り返りをやっていきたいと思っています。

古家：次は、「メンタルモデル」ですね。これは個人やチームが持つ世界に対しての捉え方のことです。デバッグ1つをとっても、シニアとジュニアで捉え方が違ったりしていて面白いです。これに関しては、チームのなかで良いメンタルモデルを同期するために、いろいろ試しました。

まず、チームに関わるプロセスやアーキテクチャの意思決定はADRで行い、チームで議論して決めるようにしました。それから、設計資料に関してはDesign Docsを別途用意してもらい、それをチームでレビューするようにして、設計の考え方をみんなに同期できるプロセスを整備していきました。

また、スクラム勉強会を定期的に開催して、完成の定義やストーリーポイントの基準など、チームのパフォーマンスに大きく影響を与えるルールを明確化し、みんなで同期しています。完成の定義は結構厳しいクオリティのものができて、最初は大変だったのですが、これによってかなりコード品質は上がってきています。

古家：最後は、「チーム学習」です。チーム学習はビジョンに向けて、個人だけではなく、チームとして対話して成長することです。チーム学習では、スクラムの3つの柱が機能するように意識していきました。透明性、検査、適応の3つですね。

一番大事なのは透明性で、あらゆるスクラム活動のデータを可視化して、活動が健全に行われているかを常に見られるようにしました。単にデリバリーの状況だけではなく、技術的負債やバグの状況も把握できるようにしています。随時起票もしているので増えているように見えますが、コツコツと直すことができていて徐々に減っています。

データをもとに適応した例はさまざまあるのですが、工数を短縮して試行回数を増やすというビジョンに向けて、できる改善をいろいろと回しています。

道が見えないときこそ“学習する組織”が良い道しるべに

古家：このように、開発チームを良い状態にするためにいろいろと取り組んできました。結果として、事業の成果としてはプロダクトロードマップの遅れは基本的になくなり、開発生産性は「Findy Team+ Award」で受賞できる水準になりました。

人の成果としても、開発チームは自律して動けるようになって、自分はもうほぼ口を出していない状態になっています。良い状態にはかなり近づきましたが、まだまだ伸びしろはあるかなという状況です。

古家：道が見えないときこそ、学習する組織や個人を目指していくことは、良い道しるべになると思っています。私のように1人目EMとして入って、会社に前例がなくて何をやったらいいのかわからないというときの、思考ツールとしても有用だと思います。ぜひ思考ツールの1つとして、試してみてもらえると嬉しいです。

今回やってみて感じたことは、学習は一度やったら終わりではないということ。大事なのはビジョンに近づいているかということで、何度も振り返ることが重要です。スタートアップだと、フェーズによっては短期的なパフォーマンスに集中しなければならないときもありますが、そんなときも学習の火を消さないように、しっかりビジョンに向かい続けることがとても大事だと思います。

ご清聴ありがとうございました。弊社は積極採用中ですので、ぜひカジュアル面談からでもよろしくお願いします。