この記事はSchoo Advent Calendar 2025の24日目の記事です！
こんにちは、株式会社SchooのEM（エンジニアリングマネージャー）のヤマダです。
この記事では、私がこの約1年間で、考え、悩み、実行してきた、組織の生産性の改善についてのお話を少しだけしたいと思います。
Laboratory #105
本題に入る前に、SchooにはMission/Visionと併せてとても大事にしているPhilosophy（哲学）があります。それが「Laboratory #105」という、まだ世の中にない価値を発明し続ける研究所であるべきという、Schooの根幹の精神を表現しているものになります。
ここで重要なポイントは、決して個人ではなく、チームとして、組織として、Schooとして行動することでより速くよりすばらしい発明ができるということです。この精神を踏まえた上で、以降の生産性の話を読んでくださるとありがたいです。
課題
あるチームで「開発生産性があまり高くないように感じる」という、なんとなくの課題感がありました。ただし、何が課題なのか、本当にまだまだ改善の余地があるのか、曖昧で漠然としていました。
そこで、まずは客観的にチームの課題感を分析してみることにしました。すると、次のような状態が見えてきました。
同時にかなり多くの開発物（タスク）が進行している
そして、この状態が要因となり次のような問題が連鎖的に発生しており、多くの無駄や非効率性が発生していることがわかってきました。
- 1つの開発物を個人で担当しているものが多く、お互いがやっていることが把握できておらず属人化していて、サポート/レビューがスムーズにできていない
- 1人で複数のタスクを抱えていることも多く、スイッチングコストが多く生じている
- デイリーMTGなどでの議題が多いなど、必要なコミュニケーションコストが多くなる
- 複数の開発物のコードが混在しQAやリリース作業が複雑になっている
なぜ、このような状態になってしまっていたかというと、根本原因はこちらだと考えました。
開発物（タスク）に優先度をつけられていない
この優先度をつけるというアクション、当たり前に聞こえるかもしれないですが、様々な理由でちゃんと実施できていない組織も多いのではと思います。
このチームに関しては、とても多くのステークホルダーがいて、担当アプリケーションも複数あり、実際に優先度をつける・開発物を絞るということの難易度がかなり高い状況でした。その結果、頑張って無理に複数をこなそうとしてしまっており、その結果逆に非効率性が生じてしまっていたのです。
対策
そこで、難易度が高い中でもこのような対策を試みました。
- 開発物（タスク）の優先度を明確にし、その上で速く完了するべきタスクから順に可能な限り複数人で分担して進める
- 要件把握や基本設計は、メンバー全員で行い事前の認識を揃え、後の手戻りやフォローコストを減らす
- 開発が完了したものから適宜リリースしていき、チームの脳内メモリをクリアにする
つまり、「チーム」として同時に抱えるトピック/タスクを極力少なくし、協力してシンプルかつスピーディに開発・デリバリーしていくことを意識しました。
ここで、上記の1つ目の効果を、価値（利益）創出の観点でも例を交えて少しわかりやすく説明してみようと思います。例えば、それぞれ実現すれば月に300万円、200万円、100万円の利益を生み出す3つの施策①~③があり、それぞれの開発には同じく12人月かかるとします。チームに3人のエンジニアがいた場合、どう開発すれば利益を最大化できるか、複数のパターンを並べて見てみます。
同じ36人月というコストをかけて開発し、すべて1年で開発が完了しているにも関わらず、1年経過時に生み出している価値（利益）には大きな差が産まれています。さらに実際には、前述した連鎖的に発生する問題が原因で、コストも増加してしまうことが多いと考えています。
対策を試みた結果、徐々に開発効率性に改善が見られてきて、効果が出ていることが実感できました。
せっかくチームで開発しているのであれば、メンバーで協力してお互いに長所を活かし不足を補い、全員の力を最大限に引き出すことがとても大事です。
Schooには「Laboratory #105」という精神があり、互いに尊重するカルチャー（土台）があるからこそ、この効果はより大きいと感じています。
発想のスケーリング
ここまで、1つのチームの話をしてきたのですが、実はここでは終わりません。
Schooというサービスは、複数のアプリケーションで運用しているのですが、私がマネージメントしていた組織（以下、ユニットと呼ぶ）ではそのアプリケーションごとにチームを分けて開発していました。
そんな中、ユニット全体の開発生産性をもっと上げたいと考えていたある日、前述したチームでの課題感は、ユニット全体でも同じようなことが言えるのではとふと気づきました。
- Schooというサービスは合わせて1つなのに、チームが分かれていることでサービスとして優先して創出するべき重要な価値を総合的にちゃんと考えられていない
- 1つ1つの新機能のリリースをもっと速くしたい
- レイヤー間・チーム間でのコミュニケーションコストも多くかかっている
- アプリケーション単体で完結できない施策もあり、結局リソースの貸し借りが発生している
そこで、Schooというサービスに関連する開発をしている複数のチームを、思い切ってすべて統合し1つの組織にする決断をしました。
価値のあると判断した施策に最大最適なリソースを投入し集中開発して、組織としてとにかく1つ1つを早く提供することで、会社/ユーザーにもたらす総利益を最大化していく、これを全メンバーで実行していきたいと思っています。
組織やサービスの規模が大きくなると、レイヤーやチームが増えるのは必然だしメリットもたくさんあります。もちろん我々も、正しいと思ってこれまでの体制を築いてきました。ただ、フェーズや状況によって最適な状態は常に変化します。そのたびに、思い切って見直すことはとても重要だと考えています。
まだまだ新しい組織体制は始まったばかりでどのくらい効果が出るかは未知数な部分はあり、逆に発生する課題感も多くあると思いますが、何事も挑戦することが大事なので、この決断を全員で正解にしていきたいと思ってます。
評価
開発生産性の改善を行なっていく上で、定性的（感覚値）ではなく、定量的に評価していくことがとても重要です。
そこで、我々もDORAメトリクスを導入しており、今後の継続的な更なる改善に活用していくつもりです。
DORAメトリクスとは、Googleの「DevOps Research and Assessment (DORA)」チームが、6年以上の調査を経て特定した、「ソフトウェア開発チームのパフォーマンス」を測定するための以下の4つの主要な指標のことです。
| 指標 | 意味・目的 |
|---|---|
| ① デプロイ頻度(Deployment Frequency) | 本番環境へコードをデプロイ（リリース）する頻度であり、デリバリースピードを測る |
| ② 変更リードタイム(Lead Time for Changes) | コード変更を加えてから本番環境に反映されるまでの時間であり、開発の効率性を測る |
| ③ 変更失敗率(Change Failure Rate) | デプロイ後に問題が発生する割合であり、リリースの品質を評価する |
| ④ サービス復旧時間(Mean Time to Recovery) | 障害が発生してから復旧するまでの平均時間であり、システムの回復力を測る |
ちなみに、今回ご紹介した生産性改善の施策の結果は、この中の主に②変更リードタイム(Lead Time for Changes)に数値として現れると考えています。
最初あまり知見がない状態でこの指標を見た時は「これだけで生産性を評価できるわけがない」と思ってしまっていました。でも開発生産性について色々な角度から考えて向き合ってきた今は、この指標が本質的でどれだけよくできているか、少しは理解できた気がしています。Schooでのこの指標の推移や活用事例について、いつかまたご紹介できればと思います。
さいごに
今回は、開発生産性の改善というミッションに対して、組織の体制や運用面でのアプローチを試みました。
ただしそれだけではなく、開発フローやCI/CDの改善、AIの有効利用、監視ツールの活用、個人スキルの向上といった、様々なアプローチを行うことが重要であり、Schooもいろいろな挑戦をしています。
Schooのプロダクト開発組織として、サービス・事業の成長をより加速させられるために、これからも互いを尊重し、学び、変化させていきたいと思います。
Schooでは一緒に働く仲間を募集しています！