ザ・ゴールから学んだボトルネック解消プロセス

事業ディレクションという役割も担いながら、8年くらいプロジェクトマネジメントしています。

今回は、プロジェクトマネジメントではないですが、プロダクト全体の成果を最大化する取り組み手法の１つを紹介です。

「ボトルネックを特定したプロセス改善」になります。

えっ、当たり前じゃん！と思われますが、言葉にすると非常にシンプルで、汎用性が高いものになります。

なので、これを正しくできるととても強力なツールになります。

ちなみに、今年度取り組んだ結果、年間のシステム開発案件のリリース量が約3.6倍になり、とてもいい成果につながっているなと思っています。

ボトルネックとはなにか？

ボトルネックとは、全体のプロセスの中で最も効率の悪いプロセスを指します。

最も効率の悪いプロセスが全体の成果を決めている、ということになるので、ボトルネックを特定し、改善することは非常に有益です。

ボトルネックのイメージを図示してみます。

例えば、5つの処理があり、同一期間内のそれぞれの処理量が記載された数字だったとします。

このプロセスが終わった後、処理が終わる個数はいくつでしょうか？

答えば、10個です。

中央の赤背景の処理がボトルネックになっており、組織全体の成果を決定しています。

次に、プロダクト企画→システム開発→リリースという流れに当てはめて、

ボトルネックである開発が全体の成果を決めますので、一定期間にリリースできる案件量は10個となります。

もっとプロダクト価値を高めたい、と思ったら、リリースできる案件量を増やすということは１つの解決手段になります。

そのため、プロセス改善をしてもっと成果を最大化したい！と思ったら、上記プロセスを改善し、世の中にたくさん価値を届けられる状態にする必要があります。

プロセス改善方法を間違うと成果は増えない

プロセス改善をする際に「間違ってはいないが全体の成果が増えない」取り組みがあります。

それは、上記プロセスの１つ１つの担当者がそれぞれに改善していく方法です。

例えば、個別に取り組んだ結果、下記のような改善が見られたとします。

要求整理プロセスで改善した結果、15案件から18案件に処理量が増えました。

また、テストプロセスで改善した結果、20案件から22案件に処理量が増えました。

では、全体のリリース案件数はどうなったでしょうか？

答えは、10です。

これが、「間違ってはいないが全体の成果が増えない」取り組みになります。

なぜ間違っていないのか？という意味では、

・個別にプロセスを最適化することで業務が楽になり他のことができる

・コスト削減につながる土台を作れる

・各組織のミッション・成果がわかりやすく評価しやすい

などのメリットはあるからです。

それでも成果＝プロダクトの価値を高めるための価値を最大化するという点では、効果的ではないのは事実です。

つまり、ボトルネックを特定し「正しく」プロセスを改善することが必要になります。

今回であれば、ボトルネックである「開発プロセス」を改善する必要があるのです。

つまり、ボトルネック以外に向き合っても時間もパワーも無駄になる可能性が高いので、ボトルネック以外の解消はやらない、と決めてもいいと個人的には思っています。

ボトルネックになっている課題をちゃんと見つけて改善する

開発プロセスを改善する場合に、てっとり早そうに感じるのが人を増やすことです。

10しかないなら15にするために人を追加すればいいじゃん！というのはごもっともです。

ただ、結局なぜそこがボトルネックなのかがわからないままなので、人を増やしても思ったように成果は増えません。

仮に人を追加してみても、

・新規参画者の立ち上げに少ない開発メンバーの稼働が使われる

・人を増やした分、案件を増やしたが、より大規模に混乱するだけ

のような状態になり、悪化する可能性が高いです。

そのため、なぜ開発チームが10個しか案件をさばけないのか？を正しく特定する必要があります。

例えば、

・フロントエンドエンジニアとサーバーサイドエンジニアのコミュニケーションがうまく行かず手戻りが多い

・案件ではなく、問い合わせ対応や障害対応に時間がかかりすぎている

・システム要求整理ができておらず、開発工程でQAが多発する

・企画フェーズで何をやるべきか？が固まっておらずミスコミュニケーションが多発する

・実は1つ前のリリースサイクルのテスト工程とスケジュール並走しており、1つ前の案件の対応に時間がかかっている

など、様々な状況が想定されます。

これを１つ１つ定性・定量的に検証し、特定していかなければなりません。

ちなみに我々の組織の課題は、

案件ではなく、問い合わせ対応や障害対応に時間がかかりすぎている

でした。

実際に問い合わせや障害が発生していないことも多かったのですが、仮に発生した場合にも挽回ができるスケジュールや稼働のバッファを積んでおく、という前提で開発をしていたため、処理量が大きく下がっていました。

※スケジュールで1.2倍のバッファ、稼働は0.7稼働程度で見積もっていたので、*0.8*0.7=0.56となり、約2倍の納期で開発をしていました。

そのため、障害対応や問い合わせ対応を専門で行うチームと案件推進を専門で行うチームに分割しそれぞれのタスクに集中できる環境を作りました。

人を追加せず、役割を変更することで対応することからスタートしました。

更に、１つの案件サイズが大きすぎることが開発に時間がかかる大きな要因の１つになっていたので、小さく分割してリリースすることも実施しました。

これはボトルネックである開発プロセスのリリースを最大限活用するために、ボトルネック以外（非ボトルネック）のプロセスを変更したことになります。

これにより開発プロセスの生産性を改善することができました。

これにより、例えば、開発プロセスの処理量が18に増えたとしましょう。

全体のリリース案件量はいくつになったでしょうか？

答えは、13です。

今度はボトルネックが変化し、企画が全体の成果を決定しています。

この改善の面白いところは、１つボトルネックを改善すると、次のボトルネックが見えてくることです。

ボトルネックである１つのプロセスの改善に集中し生産性を上げた後、また次の１つのプロセスを見つけて改善する、ことを繰り返していきます。

まとめ

今回はボトルネックを特定して正しく改善することで全体の成果を改善することができることをご紹介いたしました。

・ボトルネックは最も効率が悪いプロセスであり、全体の成果を決定している

・ボトルネックを解消する場合には、必ずその状態になっている原因を特定する必要がある

・ボトルネックを解消したら、次のボトルネックが見えてくるので油断せず次の改善をしていく

という内容でした。

ザ・ゴールという本に紹介されている制約理論（TOC）というものになります。

とてもおもしろくて関連書籍ほとんど読みました笑

漫画版でも十分に理解できると思いますので、興味ある方はぜひ〜！

ザ・ゴール　コミック版