リードタイムを短くせよ。具体と理論と統計-その２
はじめに
hi-outcomeの中森です。
前回の記事で、封筒の実験、ジャグリングの実験、キングマンの公式、統計的側面を通してバッチサイズを小さくし、稼働率を抑えることがリードタイムの短縮につながり、組織全体のパフォーマンス(収益性・市場占有率・生産性)の予測要因になることを説明してきました。
今回は、歴史の視点からリードタイムの短縮がリーンの本質であることについてアジャイル・リーン生産方式・DevOpsの文脈からお話をしていきたいと思います。
余談：なぜ歴史の話もするの？(興味がなければ読み飛ばしてください)
前回、実験・理論・統計などあらゆる側面で説明をしてきました。
そこに、今回は歴史の観点も加えようとしているわけです。
なぜ、このように多角的な視点から議論を展開しているかというと、原理・原則を腹落ちさせて理解することによってカイゼン活動の失敗をなくせると筆者が考えているからです。
筆者は「勝ちに不思議の勝ちあり。負けに不思議の負けなし」という言葉が好きです。
これは「勝利は偶然や幸運によってもたらされることがある一方で、敗北に不思議や偶然の要素はなく、誤りや不注意、準備不足などの明確な理由があって負けるべくして負ける」という意味の諺です。
プログラミングのレベルにおいても、エンジニアリングプロセスのカイゼンにおいても、うまくいかない時には決定的にうまくいかない理由があります。
私自身、原理・原則に基づかないカイゼン活動が提案され失敗に終わるのを幾度も目にしてきました。
その度に関係者として、時には当事者として非常に歯がゆい思いをしてきました。原理・原則が腹落ちしてさえいれば、このような悲劇は少しでも少なくできたのではないか？
未来において、このような悲劇がそもそも起こらないようにできないだろうか？
そういった背景から、原理・原則を少しでも腹落ちできるように多角的な視点から議論を展開させていただいております。
さて、余談が長くなったので本題に移りましょう。
アジャイル開発の登場
ところで、ソフトウェアの価値とはなんでしょうか？
それは名前の通りで、ソフトであることです。
つまり、簡単に変更ができることがソフトウェアの価値そのものなのです。
裏を返せば、変更が極めて困難になってしまったソフトウェアは変更の困難さに応じた価値しかないのです。
だからこそ、我々エンジニアは時間が経ったとしても簡単に変更ができる状況をできる限り維持し続けなければなりません。
しかし、その変化というのは、当然不確実で予期できないわけです。
だから、変化を予測するのではなく、変化することを受け入れ柔軟に変更可能なようにソフトウェアを保つためのプラクティスが生まれてきました。
変化は予測できないが変化に備えるという思想がアジャイルであり、その実践的な方法論としてのXPが登場したのです。
つまり、将来は予測できないからこそ、テストを書き、リファクタリングを行い、デザインパターンなどの変更に強い構造に持ち込むことで変化に備えようとしたのです。
アジャイルのリーンとしての側面
これらアジャイルを現代的な視点で眺めると後述のリーンの側面を強く持っていました。
リーンの思想を誤解を恐れず一言でまとめると持続的にリードタイムを短い状態に保つということだと筆者は理解しています。
例えば、XPのペアプログラミングやモブプログラミングという手法は結果として、リードタイムを短くする手法だったと捉え直すことができます。
チームで扱うタスクを少なくし、開発とレビューを常時行うことで、1個流しが促進され、リードタイムが短くなるというわけです。
他にも自動テスト、それをさらに推し進めたTDDもそうです。
テストが落ちるということを異常と定義し、テストが通っている限りはプログラムは正しく動作していると仮定します。
こうすることで、エンジニア自身が高速にフィードバックを得ることを可能にし速く安全に作業を進めることを可能にしました。
結果、持続可能な形でリードタイムを短くすることを可能になったというわけです。
これはリーン生産方式の源流となったトヨタのニンベンのついた自働化と捉えることもできるでしょう。
参考："トヨタ生産方式" 豊田章男の解釈"にて、前社長の章男氏がトヨタ生産方式についてリードタイムの観点から説明されております。
リーンとリードタイムが密接に結びついていることを非常に納得感のある形で説明をされているので、是非ともお読みいただきたいです。
これらアジャイル・XPのプラクティスは、経営上の何をどうやって作るかという問い、中でもどうやって(How)の部分に答えようとしたと捉えることができます。
そして、90年代00年代のアジャイルムーブメントと並行して、何を作ることに価値があるのかを効果的に探索する方法論が編み出されていきました。
それが、リーンの文脈です。
リーン生産方式
リーンの文脈でも不確実性と変化というのが、大きなテーマになっています。
リーンが前提とする世界
顧客にとっての本当の価値がわからない不確実な状況、顧客にとっての価値は絶えず変化している状況を前提として、効果的かつ継続的に顧客に価値を与えるビジネス側のプラクティスとして顧客開発の文脈を背景に生まれきました。
リーンの様々なプラクティス
その集大成として2011年にエリック・リースによって書かれた『リーンスタートアップ』があります。
ここでは、最小限のコストで仮説検証を行う様々なプラクティスが紹介されました。
代表的なものとして、MVP（Minimum Viable Product）があります。
MVP（Minimum Viable Product）
顧客にとって価値あると考える最小限の機能を持った製品を素早く開発し市場に投入することで、ユーザーからのフィードバックを収集し、製品を改善していくという手法です。
これも、バッチサイズを小さくし、リードタイム短く製品をリリースするという視点に立っています。
また、仮説検証を効果的に行うには、複数の機能を同時にリリースしてはうまく検証が行えません。つまり、WIPを制限してできる限り一個流しで仮説検証を行うことを目指します。
リーンとは？
リーン思想はトヨタ生産方式に起源を持ち、顧客が真に求める価値を迅速かつ持続可能に提供するための方法論として説明できます。
この思想は、顧客のニーズを的確に把握するための仮説検証プロセスを高速化し、リードタイムを短縮することを重視します。リードタイムが短ければ、仮説検証の回数を増やすことができるからです。
このリーン思想は、経営戦略として「何(What)を」創り出すかに焦点を当てたアプローチとして捉えることができます。
DevOps運動の始まり
アジャイルやXPが経営上のHowに答えようとしました。
リーンが経営上のWhatに答えようとしました。
誰もがピースは完全に揃ったかと思いました。
しかし、事態はそう上手くいきませんでした。
リーンスタートアップが出版された2011年当時のソフトウェア産業には大きな課題がありました。
それは、顧客にとっての価値が何かを最小限のコストで探索・検証するための効果的なプラクティスを実行できるだけの環境を整えきれていなかったのです。
次に、世界はDevとOpsの分断に行き当たったのです。
DevとOpsの分断
つまり、機能を小さな単位でイテレーティブにデプロイしていきたい開発組織(dev)とシステムをできるだけ安定的に運用していきたい運用組織(ops)で利害の対立が起きていたのです。
デプロイを境に開発と運用で利益相反が起き、大きな溝が生まれ問題が顕在化していったのです。
GoogleのSREチームが、自社のおよそ70%のサービス障害は、稼働中のシステム変更が原因であることを突き止めたという事例が示すように、デプロイ周りに非常に大きな緊張関係があったわけです。
そもそもMVPを使って高速に仮説検証を行うためには、製品のリリースが必須です。
つまり、デプロイをより簡単により安全に行えるようにすることが時代背景的に求められたのでした。
そうしたビジネス側の要請に応えるように、思想面ではDevOps運動が盛り上がり、技術面では、Docker・DataDog・CircleCI・Jenkins・New Relicが誕生しました。またAWSを筆頭としたクラウドサービスもDevOpsを支える様々な機能をリリースをしていきました。
こうした2010年代のDevOpsの盛り上がりによって、DevとOpsが分断を乗り越え、アジャイルが編み出したHowのソリューションたちとリーンが生み出したWhatのソリューションたちが手を結ぶことができる時代が到来したのです。
つまり、ビジネス側とエンジニアリングが手を合わせ高速に仮説検証できる環境が整ったのです。
そして2020年代の今、アジャイルやリーンの手法が統計的にもソフトウェア企業の業績の予測要因になりうることが、State of DevOpsレポートから我々は知っています。
まとめ
アジャイルもリーンもバッチサイズを小さくし、リードタイムを短くすることで、効果的に仮説検証のループを回していくことを目指した点で通底しているのです。
そして、DevOpsの知見がそれを技術面で強力にサポートしているのです。
そしてそれらプラクティスとその実践が企業の業績にも結びついていることを我々は学びました。
バッチサイズを小さく、フローを早く流す
ここまで、実験・理論・統計・歴史面からリードタイムを持続的に短くすることがいかに重要かを見てきました。
では、我々エンジニアリングの側で何をすることが必要なのでしょうか？
一言でまとめると、開発フローを速く流すための組織・文化・技術に投資する。ただそれだけです。
簡単とは言いません。ただ、この原理原則を理解し徹底的にリソースを投入してください。
※今回はエンジニアリングの目線でのプラクティスについて強く言及させていただきます。
経営視点ならびに経営とエンジニアリングをつなぐ視点については別の記事で言及させてください。
STEP1. プロセスの見える化
そのためには、まずは自社のエンジニアリング組織が速くフローを流せているかを知る必要があります。
ただその前にまずはプロセスを見える化しましょう。
ここでいうプロセスとは、要求が入ってきてから、機能開発に入り、本番環境にデプロイをするまでに何を行なっているのかに加えてステークホルダーを可視化することを指しています。
なぜプロセスの見える化が必要なのか
プロセスの見える化をすることで、エンジニアリング組織で変えられる部分と変えにくい部分が見えてきます。
まずは、エンジニアリング組織で変えられる部分を変えていくというのが実績づくりとしてもやりやすいと思います。
QA組織とエンジニア組織で分断があるのなら、まずはQAにボールが渡されるまでのプロセスのカイゼンに注力しましょう。
その後、プロセスをより速く流せるようにステークホルダーの協力を得ていくことになった際に、ステークホルダーに現状のプロセスを見せることでより改善活動がやりやすくなるという側面もあります。
STEP2-1. リードタイムを計測する
次にリードタイムを計測しましょう。
特に、First Commitからデプロイまでを計測した変更のリードタイムを計測することが開発組織にとって重要です。
ある程度エンジニアリングに閉じたリードタイムを計測することでアクションに繋げやすいです。
また、リードタイムの計測・改善が理論・統計の観点から非常に重要であることはここまで説明してきた通りなので、ご理解いただけるかと思います。
STEP2-2. WIPを可視化する
リードタイムを計測するのと並行して、WIPを見える化することも非常に効果的です。
WIPが多いと稼働率が高くなっていることが予測できます。
稼働率の高さはリードタイムの長期化に直結するというキングマンの公式を思い出してください。
できるだけWIPを減らし、作業を一個流しにすることで小さく速く仮説検証のサイクルを回すことを目指します。
STEP3. ボトルネックの特定
変更のリードタイム全体を計測した後に、待ちになっている箇所や過負荷になっている箇所を特定します。
待ちを特定する
待ちとは例えば以下のようなものです。
レビュー依頼からレビュー着手までの時間
QA依頼からQA着手までの時間
QA完了から本番デプロイまでの時間
次にこの待ちがなぜ長いのかを分析します。
例えば、エンジニアが多くの機能開発を同時並行的に行なっている、つまり稼働率が高いが故にレビューがボトルネックになっている場合などで待ちが発生している場合は、WIP制限をするなどして稼働率が高くならないようにします。
※キングマンの公式を思い出してください。稼働率が高くなるに従って、急激にスループット時間が長くなっていきます。
過負荷を特定する
過負荷になっている箇所は以下の2つであることが多いです。
待ち時間の前後
ステークホルダーのいずれかで高稼働になっているために、タスクに着手できず待ちが長くなることが多いです。
作業時間がそもそも長い箇所
開発の文脈であれば、実装の難易度が高い、調査コストが高い、仕事量が多いなどの理由で過負荷になっている可能性が考えられます。
QAの文脈であれば、過剰な品質基準を求められている、エンジニアと協業ができておらずテスト項目の重複が多い、テストの自動化が進んでいないなどが理由で過負荷になっている可能性が考えられます。
いずれの場合でも、過負荷は危険信号なので解決が必要です。
例えば、テスト項目の整理に協力する、テストの自動化の支援をするなどしてフローが速く流れるための技術に積極的に投資をしていくなどの解決策を講じましょう。
僭越ながら、私がテスト自動化によるQAフェーズの改善によって変更のリードタイムを1/7にした事例がございますので、興味があればチームの開発速度を7倍にした話もご覧ください。
何より重要なのは、どこがボトルネックになっているかを特定する。フローが速く流れないのであれば、そこを改善するためにひたすら打ち手を打っていくという姿勢です。銀の弾丸はありません。
最終的にはデプロイまでのフローが速く流れるようにすることをエンジニアリングの対象とするようにカイゼンの枠をどんどんと広げていきましょう。
時には、リードタイムの改善が開発プロセスの改善や技術面の支援だけにとどまらないことがあるかもしれません。
場合によっては組織をフローに沿って作り変えていくことが必要になるかもしれません。
※いきなりやると失敗のリスクが高いので、まずはエンジニアリング組織で小さく速くフローを流せるようになってから着手することをオススメします。
組織もフローに合わせる
本記事では、詳細には触れませんが『チーム・トポロジー』が提唱するストリームアラインドチームやNetflixのフルサイクルチームはまさにフローを速く流すために組織を組成していくことを目指したものです。
従来のようにバックエンドチーム・フロントエンドチーム・QAチーム・企画チーム・カスタマーサクセスチームが独立して存在させるのではなく、価値を検証する最小限のプロダクトをイテレーティブに高速にリリースするためのチームを作るのです。
つまり、組織図が先にあってそこにフローを合わせるのではなく、フローに合わせて組織を組成するという考え方です。
そして、フローが持続的に早く流れるようにチームの目標を設定します。
これは、かつてDevとOpsの分断があった時に、DevとOpsに共通の目標(例:SLO)を設定させることで分断を解消しようとした話に通ずるものがあります。
ただしここでお断りさせていただくと、いきなりチームトポロジーのようなことはしないほうがいいです。
変更のリードタイムが短く、1個流しでの開発がある程度できるようになったその先でチーム組成に目を向けましょう。
多くの会社組織では部門・部署の壁を超えた経営の話になりがちなので、経営層・他部署にリードタイムを短くすることがいかに大切かを実験・理論・統計・歴史などあらゆる側面で納得してもらう地道な努力とエンジニアリング組織でのカイゼン活動を先にすることをオススメします。
本記事のまとめ
本記事では、実験・理論・統計・歴史の観点からリードタイムを持続的に短くすることに投資することが必要だということを説明してきました。
また、リードタイムという観点に立った場合にエンジニアリングの側でできることをまとめました。
本記事が、皆様のエンジニアリングを少しでも楽しく豊かなものになるきっかけになれば幸いです。
おわりに
私たち「HiOutcome」は、開発チームの規模が10-100名の企業を中心に、開発支援を行っています。
支援内容は、リーン開発の推進から、開発効率の向上、事業成長への貢献まで、幅広く対応しております。
開発にお悩みの方がいましたら、是非お気軽にお問い合わせください。
開発スピード向上サービス: https://corp.hi-outcome.com/
開発の予測精度向上サービス: https://corp.hi-outcome.com/inspection