エンジニアの制約を超えて - 開発価値の最大化と制約理論
制約理論やTOCという単語を聞いたことはあるでしょうか？
筆者のキャリアの大半はプロダクト開発に従事しており、その中で「これエンジニアの仕事なのだろうか」「これ実装する意味あるんだろうか」「求められることとやるべきだと思うことが異なる」など、よくある（？）悩みに直面したことがあります。スクラム開発やかんばん方式などを経験しプロダクト開発におけるプラクティスが少しずつ見えてきて、制約理論によってより原則に近い部分が言語化・理解できた気がしています。現在では制約理論は僕のプロダクト開発における最も重要な価値観の1つであり、もっと多くのエンジニアに知ってほしいと思っている理論です。
本稿はエンジニアという名前の制約を超えて、プロダクト開発価値を最大化するために制約理論を知ってもらおうという記事です。
会社にとってのTHE GOAL
制約理論は「THE GOAL - 企業の究極の目的とは何か」という本で提唱されたマネジメント理論です。制約理論とは何かを解説する前に、まず会社の目標(=THE GOAL)について考えてみます。「商品を売ること」「社会に貢献すること」など、人によって答えは様々かもしれませんが、THE GOALにおいてはキャッシュフロー、つまりお金を儲けることを目標と置いています。
当然ですが儲かれば何をしてもいいわけではないので、筆者なりにより厳密に定義するならば、ユーザーに価値を提供し、対価としてお金を儲けることこそが会社の目標であると言えるかと思います。当たり前の話だと思う方もいらっしゃるかもしれませんが、プロダクト開発でもこの目標が「プロジェクトを終わらすこと」「リリースすること」などに置き変わってしまっていることはよくある話なので、齟齬がないよう改めてこれを目標として意識しましょう。
価値とは何か
「ユーザーに価値を提供し、対価としてお金を儲けること」を目標とした時に、ここで言う価値とは何なのかもう少し細分化してみましょう。価値をユーザーにとっての品質観点から分析する、狩野モデルを参考に考えてみます。
狩野モデルでは品質をいくつかに分類しますが、ここでは代表的な以下の3つに絞って考えてみます。
- 魅力品質: 高いと満足になるが、低くても不満足にはならない。検索サイトのレコメンド機能など。
- 一次元的品質: 高いと満足になり、低いと不満足になる。ストレージにおける容量など。
- 当たり前品質: 高くても満足にはならないが、低いと不満足になる。サイトパフォーマンスなど。
ユーザーが価値を感じるには上記品質のどれかを満たすのではなく、全てにおいてバランス良く品質を提供する必要があります。
狩野モデルの分類はユーザーにとっての品質であり、いわゆる外部品質の分類です。一方で開発チームにとっての品質、例えば保守性などの品質は内部品質と呼ばれます。詳しくは後述しますが、外部品質は内部品質によって支えられています。
エンジニアリングのKPI
さて、お金が儲かることが最大目標とはいいつつ、そのために開発チームが営業活動も頑張れるようになればいいのかというと、もちろんそうではありません。開発チームが会社の目標のためにやれることはプロダクト価値の提供、つまりプロダクトを高い品質で迅速に提供することです。このことからプロダクト価値のKPIは大きく外部品質とスピードの2つに分けられます。この2つは単なる兄弟関係ではなく、外部品質を作り込むのには時間がいるため外部品質はスピードにも依存しています。
スピードはそれだけでプロダクト価値を向上し、かつ外部品質を作り込む時間をもたらす最も重要なKPIです。開発スピードを早くするには、どうすればいいでしょうか？
ここでよくある勘違いが、内部品質をトレードオフすることです。具体的には、下記などが考えられます。
- ユニットテストの実装工数を減らそう
- リファクタした方がよさそうだけど後にしよう
- レビュー工数を減らすためにレビュアーを減らそう
これらで内部品質をトレードオフすると結果、スピードが低下します。内部品質はトレードオフするのではなく、高く維持することでスピードを得ることができるのです。この辺はt-wadaさんの質とスピードを読むとよくわかります。
スピードが内部品質に依存していることはわかりましたが、内部品質の向上以外にマイクロKPIはないのでしょうか？スピードを左右するもう1つのマイクロKPIがボトルネックです。内部品質が一定の場合、スピードはボトルネックの影響を大きく受けます。
このボトルネック≒制約に注目し最適化を目指すのが制約理論（TOC:Theory Of Constraints）です。
制約理論
制約理論は「どんなシステムであれ、常に、ごく少数（たぶん唯一）の要素または因子によって、そのパフォーマンスが制限されている」（参考:TOC協会）という仮定の下提唱された理論です。
例として、車業界で考えてみましょう。昨今の半導体不足の影響で新車の納車にかかる時間や納車の総量というのは、全体的に凹んでいる状態が長く続いています。これは現在、半導体の生産量が納車の総量を制限していることを表しており、ボトルネックなのです。仮にボトルネックである半導体の生産量が倍になれば、納車できる車の数は倍になるかもしれません。
このように、全体のアウトプットを制限しているボトルネックを見つけ、最適化を行うことこそが唯一アウトプットのパフォーマンスを改善する方法であるというのが、制約理論です。
ボトルネックと最適化
制約理論における最適化は以下のようなステップに分かれます。
- ボトルネックを探す
- ボトルネックを最適化する
開発フローにおけるボトルネックはケースバイケースで、必ずしも決まったところにあるわけではありませんが、筆者の経験からよくあるボトルネックとその改善例をいくつかあげてみたいと思います。
例1 要件定義がボトルネックの場合
開発プロジェクトの初期においては、要件定義がボトルネックになることがあります。開発メンバーのアサインや技術選定・各種環境構築などが終わったが、開発着手できるほどまだ要件が決まっておらずエンジニアが暇を持て余してしまうことはよくある話だと思います。
ボトルネックに対する最適化は、大きく以下の2種類が挙げられます。
- ボトルネックを最適化する
- ボトルネックに合わせて全体を最適化する
「ボトルネックを最適化する」とは、要件定義がボトルネックの場合に当てはめると、要件定義を早く終わらせるためにエンジニアが開発論点の多い要件定義を巻き取ることなどが挙げられます。「それはエンジニアの仕事なのだろうか」と疑問に思う方もいるかもしれませんが、時にエンジニアという枠を超えてボトルネックの最適化に取り組むことが開発価値の最大化への大きな一歩だと筆者は考えています。
もう1つの「ボトルネックに合わせて全体を最適化する」というのはもう少しシンプルで、この場合要件が確定した部分から実装着手することが案として挙げられます。これは実装上手戻りが発生するリスクを抱えることになりますが、制約理論ではボトルネック以外に対する最適化の努力は無駄か状況を悪化させると言われています。具体的には、できるだけ手戻りがないように要件がFixするのを待つなど開発工数を最適化しようとした結果、プロジェクトの提供時期が遅れてしまうなどが考えられます。要件定義がボトルネックの場合、手戻りありきで進めることが結果的にスピードを向上させることがあります。
この例のポイントです。
- 時にエンジニアの枠を超えてボトルネックに取り組むことも重要
- ボトルネック以外の工程の最適化は無駄になる可能性がある
例2 レビューやテストがボトルネックの場合
要件定義後の実装フェーズにおいてよくあるボトルネックがレビューです。複数人の開発チームでリーダーや古参メンバーが必須レビュアーを担っていることはよくあるケースです。レビューがボトルネックである場合、どういった最適化が可能なのでしょう？
ここで注目したいのが、チームで持っているタスクの優先順位です。開発メンバー全員が優先度が高いタスクだけを持ってるとは限りません。時期によって優先度が高いタスク自体が少なかったり、古参なメンバーが優先度の高いタスクを持って他メンバーは優先度が中〜低のものを担当してることはよくあることでしょう。最適化として考えられるのはこの優先度の低いタスクを一旦停止し、優先度の高いタスクを分割し人員を割り当てるなどすることで、そもそも優先度の低いレビューを発生させないという案です。アジャイル開発ではWIP制限と呼ばれています。メンバー1人1人に実装案件を渡し、並列に実装を進めることは効率的に見えて、実はボトルネックに負荷を強めているだけな可能性があるのです。
並行タスクを減らすのは初め、勇気のいる決断になることでしょう。多くの人が直感的に並行タスクが多いことこそが最も効率的と考えるからです。しかし、これもTHE GOALで否定されている内容に近いものです。
「ゴロー、面白いことを教えてあげよう。従業員が手を休めることなく常に作業している工場は非常に非効率なんだ。」
これは示唆に富んでおり、人の手を埋めること（≒リソース効率）が目標に対し必ずしも効率的とは限らないということです。リソース効率とフロー効率を知ってると、よりしっくり来るかもしれません。
他にも、リーン開発の本質では並行タスクが多いことはタスク切り替えの無駄として紹介されています。
もしレビューがボトルネックで悩んでいるなら勇気を出して、優先度の低いタスクを止めてみましょう。
この例のポイントです。
- 人の手を埋めること（≒リソース効率の追求）がボトルネックを強めてしまうことがある
- レビュアーや開発チーム全体がいかに優先度が高いタスクにフォーカスできるかが重要
例3 バグ修正がボトルネックの場合
最後はバグが頻発してボトルネックになる場合です。これはそもそもそうならないように、バグ発生率が低くなるよう内部品質を高めるしかない話ではありますが、現実にはスケジュールを急かされて内部品質に目を瞑り、結果バグ対応で後半パンクしたような経験がある方も多いのではないでしょうか？
これに対する最適化はシンプルですが難しく、内部品質の問題を先延ばしにしないことの徹底です。問題の先延ばしは目の前のスケジュールを解決するかもしれませんが、全体のスケジュールで見るとバグ対応が大きな割合を占めて結果大幅に遅延を発生させたりします。これは局所最適と全体最適の関係にも似ています。個人的には「今やっておかないと辛いけどやる時間がない」って思ったものは大抵、すぐやった方が結果全体が早いということの方が多かったと感じています。
再掲になりますが、この例についてより詳しく分析・理解したいなら質とスピードを読むことをお勧めします。
この例のポイントです。
- 目の前のスケジュールを守ることより、全体のスケジュールを守るために内部品質を維持することが重要
ボトルネックは悪なのか
ここまで例でボトルネックの探し方と最適化を考えてきましたが、実際に開発現場でボトルネックを探す時には大きく2つの点に注意する必要があります。
1つは「ボトルネック」という単語のイメージです。ボトルネックという単語はネガティブなイメージを持たれやすい単語であり、「あなたの工程がボトルネックですね」と言われると、気分を害される場合があります。制約理論においてボトルネックとは駆逐すべき対象ではなくただの現実であり、必ずしも悪ではありません。ボトルネックの定義を議論の前に揃えてから会話することをお勧めします。
もう1つの注意点としては、ボトルネックに対する最適化案のアンチパターンとして、無理にボトルネックを解消しようとすることが挙げられます。例えば前述のレビューの例で言えば、以下はアンチパターンと考えられます。
- レビューがボトルネックだからスキップしてしまおう
- レビュアーを減らそう
- レビュアーとしてアサインできる人を増やそう
レビューに求められるスキルセットややり方は人によってさまざまなため、これらの打ち手は元々暗黙的にレビューで担っていた内部品質を保てなくなり、結果スピードを悪化させる可能性があります。こういった場合ボトルネックは解消するのではなく、ボトルネックに合わせて全体を最適化することこそが重要です。
ボトルネックは移りゆく
前述の例でもわかるように、開発フェーズによってボトルネックはうつろいゆくものです。TOC協会の説明にも「制約が新しいところに移ると、システムはそれまでと全く別ものになる」と説明されています。
ボトルネックが移った時に古い方針そのものがボトルネックになることもあります。要件定義から開発実装へボトルネックが移ったのにエンジニアが要件定義を手伝っていたら、当然非効率になります。
ボトルネックは移ろいゆくものであることに注意しましょう。
まとめ
最後にまとめです。
- 会社の目標は「ユーザーに価値を提供し、対価としてお金を儲けること」
- 開発チームの追うべきKPIは外部品質とスピード
- 外部品質はスピードに依存し、スピードは内部品質とボトルネックに依存する
- 内部品質を高く保ち、かつボトルネックに合わせて最適化する（制約理論）ことで、スピードが改善する
本稿が少しでも制約理論の理解に繋がれば幸いです。興味を持った方は、コミック版が非常にわかりやすく読みやすいのでぜひ手にとっていただくことをお勧めします。
Discussion