「LeanとDevOpsの科学」から見えたチーム・組織が成長するためのヒント　#PERSOL CAREER Advent Calendar2025

この記事はアドベントカレンダー 23日目の記事です。

はじめに
LeanとDevOpsの科学を読んだきっかけ
DORA Core Model（ケイパビリティ、パフォーマンス、アウトカム）
開発組織のパフォーマンス向上と組織文化のモデル化
デリバリライフサイクルとソフトウェア管理のプラクティス
変革型リーダーシップとマネジメントの役割
まとめ

はじめに

こんにちは！doda サイト開発の川又です。
主務はアジャイルCoEチームで、ITコンサルタントとして継続開発チームの開発生産性、品質向上に尽力しています。
アジャイルCoEチームとは、dodaサイトの継続開発に対して組織とシステムのアジリティをあげ、変化に強い組織/文化を作るために「できることは何でもやる」チームであり、以下の憲章のもと日々活動を行っています。

昨年は「開発生産性を上げるには」というテーマで書きましたが、ソフトウェア開発におけるこの1年はAIの台頭もあり私たちを取り巻く開発環境が目まぐるしく変化しました。また、自身の立場や視座の変化などもありチームだけではなく組織にも意識が向くようになりました。

そこで、私たちの活動をより効率的・効果的にすべく「LeanとDevOpsの科学」という書籍をもとに輪読会を行いました。今回はここから得た知見をもとにチーム・組織が成長するためのヒントをアウトプットしようと思います。
みなさんの開発チーム・組織において何か一つでもヒントになれば幸いです。

LeanとDevOpsの科学を読んだきっかけ

そもそもこの書籍を読んだきっかけですが、Four Keysを用いたチームの開発生産性向上の活動に停滞を感じ、様々なインプットを行っていたところ以下の記事にたどり着きました。

このときは書籍ではなく「Four Keysだけじゃ絶対もったいなくなる」というワードに目を引かれていましたが、記事を読んでみるとなるほど、実はチームの生産性を計るためにはFour Keysだけに捉われていると視野が狭くなってしまうのでは？と思い始めてきました。

ここでKent Beck氏の言葉を引用しましょう

指標を目標にすると、良い指標ではなくなってしまう

これは「グッドハートの法則」と呼ばれており、今まさにdodaサイト開発チームが陥っている状態なのでは、と感じました。
3年ほど前に導入された「Four Keysでチーム状態を定量的に観測する」活動で、まずはチームの生産性や定量的な状態を可視化し傾向分析を行う土壌は整いました。
しかし、先ほど説明したとおり各スクラムチームにおける定量評価を加速させ、チームに定着させるための活動が停滞し、何とも言えない違和感を抱いたため、自分の違和感の原因を探るため読んでみることにしました。

DORA Core Model（ケイパビリティ、パフォーマンス、アウトカム）

結論を話すと、「DORA Core Model」と呼ばれる指標を見れば今私たち（開発チームを支援するチーム）が何をすべきか、がはっきりと分かりました。
（DORAやDORA Core Modelの説明を置いておくので気になる方は読んでみてください）

DORA
長年にわたりソフトウェアデリバリーの現在地を説明するだけでなく、組織がテクノロジーやツールの絶え間ない変化にどう対応すべきか、をデータに基づき私たちの意思決定を支援している。
DORA Core Model
チーム、組織がどのように振舞うことが適切か、を可視化したモデル図
いまや業界標準となり、多くの組織が開発パフォーマンスを測定、改善するための指針となっている。

赤枠で囲っている部分が先ほど話したFour Keysにあたります。
ケイパビリティ→パフォーマンス→アウトカムと左から右に小さな矢印が書いてありますが、

①ケイパビリティをもとにチームの改善活動を行うことでパフォーマンスに影響を与え
②パフォーマンスを示すFour Keysが、組織のパフォーマンス、つまりアウトカムに影響を与える
ことを意味します。

この部分は実は本書の最後、付録部分に記載があるのですが、この書籍の内容を総括して体系的に可視化した非常に分かりやすいモデルです。（常にバージョンアップがなされており、書籍よりDORA公式サイトの方が最新のためこちらを載せています）

なんと言っても①が私の違和感を取り除く最大にしてシンプルな内容でした。
要するにケイパビリティ、つまりチームの開発活動において改善できる機能、ポイント（例えばCI/CD、テスト自動化、オブザーバビリティ、変更承認の効率化など）を探してアクションし、その結果をFour Keysで観測するということです。
うまくいってもいかなくても、その要因を分析し次の一手に繋げることが重要です。

ケイパビリティ：各開発チームの領域（頑張って改善活動を行う）
パフォーマンス：アジャイルCoEチームの領域（改善の状況を観測し支援する）
アウトカム：マネジメント、経営層の領域（成果を観測し経営判断を行う）

そして、Four Keysが良化すると②のようにおのずと組織のパフォーマンス、アウトカムが向上することが期待されます。
私の考えでは、各ゾーンを以下のように棲み分けることでチームの成果に効き、評価しやすい文化醸成が生まれると思っているため、今後各チームやマネジメント層と会話しながら啓蒙・浸透させていきたいと考えています。

開発組織のパフォーマンス向上と組織文化のモデル化

ではここから本書の内容に入っていきます。

①業務を加速させるために必要なのは「成熟度モデル」ではなく「ケイパビリティモデル」
これは昔私も同じ過ちを犯していました。いわゆるCMMIの成熟度モデルをもとにチームの成熟度を当てはめ、レベル感と現在地を把握しながら目標のレベルを目指していくというものです。
過ちというのは言い過ぎかもしれませんが、グッドハートの法則よろしく、成熟度モデルは達したら終了になりがちなのです。組織が一定の成熟状態に「到達」することに焦点を当てており、「所定のレベルに達したら終了」のスタンスを取っています。
それと比較しケイパビリティ（モデル）は、「テクノロジーやビジネスをめぐる状況は絶えず変化する」という前提のもと、継続的改善の重要性を説いています。

②Four Keysの採用理由
本書では、基本的に調査や論文に基づいて行った分析結果をもとに考察が記載されており、私たちが受け入れて活用しているFour Keysも組織の成長度合いを図る指標として科学的根拠のある数値となっています。ポイントとなるのは以下でしょうか。

パフォーマンス改善、安定性、品質向上にトレードオフの関係はない
ハイ、ミドル、ローパフォーマー各々で観測を行い傾向分析を行っている
チーム状況を客観的に判断し他組織・チームと比較できる

その他色々書かれていましたが、一番刺さったのは
「”忙しいが価値のない、見せかけの作業”を重ねて大量の仕事をこなした者を報奨するやり方はやめるべきだ」
です。少し暴論ですがFour Keysの登場によってこなしたタスクの質と量はより定量的に観測されることになりました。（価値があるか？はアウトカムまで見ないと断定はできないですが）

デリバリライフサイクルとソフトウェア管理のプラクティス

リーンマネジメントは一般的に以下と定義されています。

リーンマネジメント

進行中の作業WIP（Work in Progress）の制限

ワークフローの可視化

負担の低い変更承認プロセス

「リーン生産方式」というワードはトヨタ自動車が生産性を上げた方式で知られていますが、ここではマネジメントが語られています。
リーンマネジメントはリーン生産方式（トヨタ式生産方式）のエッセンスを製造業以外の分野にも展開したもので、ポイントは”ゴール起点で品質を最大化するための活動”です。
ここで個人的に重要だと感じたのは「負担の軽い（ライトウェイト）変更承認プロセス」です。
本書では、変更承認プロセスがソフトウェアデリバリのパフォーマンスに与える影響を調査すべく、チームの変更承認プロセスを質問しています。

本番障害に対する変更については必ずチーム外の人や組織の承認を得なければならない

DBの変更などハイリスクな変更に関してのみ承認を得なければならない

変更の管理はピアレビューだけで済ませている

変更承認プロセスはない

感覚的には1,2の回答したチームがソフトウェアデリバリのパフォーマンスが良さそうですが、結果は3,4と回答したチームのパフォーマンスが良かったのです。
深掘りすると、例えばFour Keysの「平均修復時間」においては1,2のように承認プロセスが堅牢だと、本番環境のシステム稼働の安定性は向上せず、むしろ障害が発生した際の作業に遅れが生じパフォーマンスは低下します。
しかしここで言いたいのは「変更プロセスを排斥せよ」ではなく、

ペアプログラミングやチーム内のコードレビューなどライトウェイトな変更承認プロセスを実現
望ましくない変更を検知・排除するデプロイメントパイプラインを併用する

これらを取り入れることで真に価値ある変更承認プロセスを実現し、よりリーンな開発を実現できるのだと考えます。

変革型リーダーシップとマネジメントの役割

ここまでは定量的な分析から仮説検証を行い、試行錯誤の結果汎用化されたモデルやプラクティスの話を整理しました。
これをチームや組織に落として変革していくためには、組織の未来を考えこれらの知見を伝搬しながら導いていくリーダーシップを取れる人材が必要となってきます。
本書では変革的リーダーシップを以下のように定義しています。

変革型リーダーシップ

ビジョン形成力

心に響くコミュニケーション

知的刺激

支援的リーダーシップ

個人に対する評価

皆さんはこれを見て何を感じたでしょうか？
私は「ビジョン形成力」にハッとさせられ、ここまで考え抜けてのリーダーシップなのだと感じました。このワードだけ他の4つと比べてもいい意味で異質な印象を受けます。
ちなみにビジョン形成力はさらにこのようにブレイクダウンされています。

ビジョン形成力

チームが進む方向を明確に把握している

チームが5年後にどうあってほしいかを明確に意識している

組織が進む方向を明確に意識している

把握や意識など抽象度が高めな定義ではありますが、いわゆるマネジメントに求められる内容だと私は理解しました。
リーダーシップとしてこの領域まで求められるのはなぜか、を深掘りすると近年はVUCA（変動性・不確実性・複雑性・曖昧性）と呼ばれ、組織やチームをマネジメントするための難易度が格段に上がっていると言われます。
このような中、チームや組織が進む方向や未来を考え抜きメンバーが同じベクトルで進んでいくためにはビジョン形成力が必要なのだと捉えました。

図のように変革型リーダーの影響は技術的実務、プロダクト維持などチーム業務のサポートに現れます。リーダーシップのプラス（もしくはマイナス）の影響はソフトウェアデリバリだけでなく、組織全体のパフォーマンスにまで及んでいると捉えることができそうです。
また、有能な変革型リーダーを要するチームのパフォーマンスを調査し、調査対象の全チーム（変革型リーダーがいないチームを含む）と比較したところ、ハイパフォーマーになる確率は同等かそれ以下であることが分かりました。
本研究からリーダー単独ではDevOpsによって高い成果を上げることはできないことが裏付けられています。
このことから、変革型リーダーシップを発揮できる人材がいかにメンバーの実務にこのエッセンスを注入できるかがポイントになってきそうです。

まとめ

最後にまとめです。

「科学的根拠に基づくDevOps・リーンの実践」を重視し、現場の課題や改善活動に直結する知見が多い

要所で「あっこれは今のサイト開発でも同じ状況だな」と開発現場における課題感と重なる部分が多く実践的な気付きの示唆が多く隠されていたと感じました。
できている点、まだできていない点含め開発環境の現在地を把握することができ、アジャイルCoEとしての振る舞い方の参考になりました。

組織文化やリーダーシップ、継続的改善の重要性が繰り返し強調されていた

また、Four Keysなどの定量的な指標はもちろん、それをもと各人が真のリーダーシップを発揮したり、それを支えるための組織文化が醸成されている必要があると感じました。
チームの成長と組織の成長は相関性があり、一方の成長がもう一方にも寄与していると考えます。チームが抱える目先の課題は、もしかしたら組織の仕組みや文化を変えることで解決するかも？と言った視座の転換が解決のヒントになるかもしれません。

今後に向けて

私自身このLeanやDevOpsを100%理解しきれたわけではありませんが自身の引き出しは増えたと感じています。
このアウトプットをきっかけに、得た学びをチーム・組織に還元しより高品質なプロダクトをよりスピーディーにリリースできる基盤を実現していきたいと思っています。

ここまで読んでいただきありがとうございました！