TOC（制約条件の理論）とは、ワークフローのなかで最も生産性の低いボトルネックを特定し、その強化・改善をはかることで、フロー全体の生産能力を高める手法です。
経営活動における意思決定プロセスやプロジェクト管理など、ワークフローが存在する業務なら、どの範囲にでも応用できます。
そのため、「システム開発の領域にTOCを導入したい」と考えている方も多いでしょう。
システム開発にも要件定義や設計、開発といったワークフローが存在するため、ボトルネックの改善により、納期短縮や生産性の向上につながります。
本記事では、TOCをシステム開発に活用する方法や手順を具体的に解説します。
TOCとは？
TOCは、イスラエルの物理学者であるエリヤフ・ゴールドラット氏によって生み出された理論です。
TOC（Theory of Constraints）は「制約条件の理論」と呼ばれ、ワークフローの制約（ボトルネック）を改善し、全体の生産性を向上させるマネジメント手法です。
ボトルネックとは、ワークフローの中で生産性が最も低い工程を指します。
このボトルネックに対してリソースを集中的に投入し生産力を強化することによって、ワークフロー全体の生産性を向上させるのがTOCの目的です。
そのため、企業経営にTOCを導入すれば、無駄なコストや労力をかけずに、プロセスの進行を妨げる原因を改善できます。
TOCはシステム開発にも活用できる
本来、TOCは主に製造業界で活用されてきましたが、システム開発にも適用できます。
なぜなら、システム開発には「要件定義・設計・開発・テスト」という一定のワークフローが存在するからです。
ワークフローのなかには必ずボトルネック（最も生産性の低い箇所）が存在するため、TOCの活用によってシステム開発フロー全体の生産性向上、あるいは納期短縮につながります。
例えば、システム開発のなかでも特に開発工程に最も時間がかかる場合、「プログラム設計・プログラミング・コーディング」のように、開発工程をさらに細分化します。
細分化した工程のなかで最も工数が必要な箇所がボトルネックにあたるため、増員やツールの導入などにより、その箇所の生産能力を強化するのがポイントです。
全工程のなかで1つの箇所の生産性が向上すると、今度は別の工程が新たなボトルネックとなります。
そこで、新たに生まれたボトルネックを同じ要領で強化することで、徐々にワークフロー全体の生産性が向上する仕組みです。
このようにTOCをシステム開発に活用すれば、ボトルネックの改善を通じてスケジュールの効率化・生産力の向上・納期遅れの防止といった効果が期待できるでしょう。
システム開発環境で起こりうる問題点
この章では、システム開発環境で起こりうる5つの問題点を解説します。
- 計画通りに進まない
- 長時間労働が慢性化する
- 顧客やチームメンバーとの認識のズレが発生する
- 開発費が膨らむ
- 新しい技術を取り入れる余裕がない
これらの問題点は、いずれもTOCにおけるボトルネックになり得るものですが、TOCの理論に則って改善できれば、開発プロセスのさらなる効率化や遅延解消が期待できます。
計画通りに進まない
システム開発現場では、計画通りに進まないことが往々にして起こります。
理由としては、見積もりの精度が甘すぎることや、見積もりの際には無かった仕様の追加や変更が加わることなどです。
例えば、システムのバックアップを取るという仕様が途中から追加された場合を考えてみましょう。
この場合、バックアップ先のサーバーやNASの調達、構築などの当初考慮に入れていなかった作業が発生します。
このような作業が立て続けに発生すると、現場の進捗が計画より大きくずれてしまいます。
長時間労働が慢性化する
システム開発現場では修正やトラブル対応の多さ、人手不足は長時間労働の原因になります。
また、日本ではシステム開発を多重下請けされるケースが多く、ピラミッド構造ができあがるため、改善を求めにくいのが現状です。
そのため、長時間労働が問題視されず見過ごされていることも少なくありません。
このような長時間労働は過剰な負担を生み出し、貴重な人的リソースを消耗させます。
その結果、生産力を低下させるだけでなく、プロジェクトの遅延を招く可能性が高くなります。
顧客やチームメンバーとの認識のズレが発生する
他の仕事でも見られる現象ですが、システム開発現場でも顧客やチームメンバーとの認識の齟齬が発生します。
その理由のひとつが慢性的なコミュニケーション不足の問題です。
例えば、顧客とシステムの要件定義のすり合わせをしたにもかかわらず、エンジニアが仕様通りにシステムを作ってくれないようなケースが考えられます。
認識の齟齬は顧客の信頼を失うきっかけになるので、日ごろから綿密なコミュニケーションを実施することを心がけましょう。
開発費が膨らむ
システム開発では、当初の予定より開発費が膨らむ事態も想定されます。
原因としては、以下が例として挙げられます。
- 見積もりの精度が低く、計画作成時には予想できなかった作業が発生した
- 思わぬタイミングで欠員が発生した
- コミュニケーショントラブルによる手戻りで作業量が増加した
例えば、導入環境のヒアリング不足により、作成したシステムが導入できないことが判明した場合、大きな手戻りや新しいソフト・ハードを用意する必要が出てきます。
その結果、人件費や物販購入の費用がかさみ、開発費の増加を招いてしまうかもしれません。
新しい技術を取り入れる余裕がない
新しい技術の活用でパフォーマンスが向上するのは明白なのにもかかわらず、余裕がなく導入できないケースも、よくある課題のひとつです。
新技術の導入は新技術に沿ったセキュリティの強化も必要になり、また今までとは違うノウハウも要求されるため、多額の費用と時間を要します。
そのため、新技術の導入は多額の費用と時間を用意できる余裕がないと実現が難しくなります。
TOCをシステム開発に活用する手順
TOCをシステム開発に導入する手順は次の通りです。
- 制約を特定する
- 制約を最大活用する方針を決める
- 制約以外のすべてをステップ2の決定に従属させる
- 制約を強化する
- 制約が解消したら惰性に気を付けてステップ①に戻る
ステップ①制約を特定する
組織を全体的に見渡して、パフォーマンス向上の障害、つまり制約が何なのかを見つけます。
制約とは、目的達成に向かううえで存在する数々の「好ましくない事実」を引き起こしている根本的な原因です。
例えば、システム開発においてバッチファイルを使用すれば数秒で終わる作業を、1日かけて手作業で対応しているようなケースは、ワークフローのなかで無駄な作業だといえるでしょう。
そういった無駄と思われる作業を制約として特定します。
ステップ②制約を最大活用する方針を決める
このステップでは、見つかった制約部分の工程にあるリソースを最大限活用します。
制約となっている工程のパフォーマンスが業務全体のパフォーマンスを決めており、仕事の運用や作業方針を改善すれば、業務全体のパフォーマンスが向上が見込めるでしょう。
例えば、システム開発における設計でよく発生するのが、特定の有識者にタスクが集中し、そのリソースが制約となりタスクの停滞が発生するケースです。
「その特定リソースの負荷を下げよう」という方針を立てることがこのステップに該当します。
ステップ③制約以外のすべてをステップ2の決定に従属させる
制約となっている工程以外も、制約部分のパフォーマンスに合わせて処理します。
なぜなら、制約以外の部分は過剰に成果物を生産しているケースが多いからです。
例えば、ステップ2を実践する際、多岐にわたるタスクの担当者をほかのメンバーに任せられないか検討し、制約以外のリソースにタスクを割り当てれば、制約の負荷が下がる可能性が生まれます。
この一連の作業がステップ③に該当します。
ステップ③を実践し、過剰な成果物やリソースを減らせば、コスト削減が実現可能です。
ステップ④制約を強化する
ステップ②とステップ③を実行し改善したとしてもまだパフォーマンスの制約である事には変わらず、更なるパフォーマンス向上のために費用をかけた対策を実施します。
例えば、特定のリソースと同じ役割をできるような教育費、単純に人数を増やすための追加の人件費などがそれに該当します。
ステップ⑤制約が解消したら惰性に気を付けてステップ①に戻る
引き続き新しい制約の改善を目指して、ステップ①から④で紹介した制約の特定から強化までの流れを再度繰り返します。
この際に、チーム全体に惰性的な雰囲気があると、今まで進めてきた改善が崩壊するので注意が必要です。
TOCをシステム開発に活用した事例
ここでは、システム開発の遅延ゼロを達成した、昭和電線ケーブルシステム株式会社のTOC導入例をご紹介します。
昭和電線ケーブルシステム株式会社では、システム開発の慢性的な遅れが発生していました。
当時の常務取締役も、「開発テーマの進捗が見えない、見えないので適切な手が打てない」と、何をすれば改善するのか見当もつかない状況でした。
そこで、昭和電線ケーブル株式会社様はTOCを利用し、遅れの原因にスケジュール要因が多く存在することを発見します。
そして、そのスケジュール要因を取り除くことで、技術的には一切改善を加えなくとも遅延ゼロを達成しました。
TOCの活用事例はこちらのページでも取り上げていますので、興味のある方はぜひ参考にしてみてください。
関連ページ：事例紹介｜ビーイングコンサルティング
システム開発にはCCPMも活用できる
TOCのように、システム開発に導入できるプロジェクト管理手法にCCPMがあります。
CCPMとは、各工程のバッファを最適化し、プロジェクト全体の納期短縮を実現する手法です。
CCPMを実施する際は、まず各工程に設定したバッファを遅延しないギリギリの工数まで取り除き、その合計期間をプロジェクト全体のバッファとして別に確保します。
例えば、工程Aのバッファが10日、工程Bのバッファが5日だとすると、それぞれで取り除いた合計15日間がプロジェクト全体のバッファとして確保されることになります。
あえて各工程の余裕日数を省くことで、「まだ期間に余裕があるから大丈夫」というプロジェクトメンバー間の緩慢な雰囲気を引き締めたり、余分なマルチタスクの発生を回避したりするのに効果的です。
また、不測のトラブルでタスクに遅れが発生しそうな場合は、プロジェクト全体のバッファを取り崩し、該当する工程に振り分けられます。
このように、CCPMはバッファの浪費を防ぎ、余裕日数を最適化して納期の短縮を目指す点が特徴です。
TOCとは異なる観点の管理手法ですが、CCPMもシステム開発のプロセスを効率化し、納期遅れを防ぐ効果が期待できます。
また、作業の優先順位やプロジェクト全体の進捗を把握したいときにも役立ちます。
CCPMについて詳しく知りたい方は、以下の記事をご覧ください。
関連記事：CCPMのプロジェクト管理手法｜従来のデメリットを解決
まとめ：TOCをシステム開発に活用しスムーズなプロジェクト運営を
今回の記事の内容を以下にまとめました。
- TOCは制約にフォーカスしてパフォーマンス改善を図る理論
- TOCはシステム開発にも有用
- TOCで、システム開発現場の問題の多くが解消される
- TOCでは5ステップでシステム開発の工程を改善させる
TOCを利用することで、今まで計画通りいかなかったシステム開発がスムーズに進みます。
ビーイングコンサルティングでは、TOCやCCPMを使用したチーム運営のコンサルティングを実施しています。
TOCやCCPMを組織に定着させる方法について、こちらの資料で詳しく解説しています。
資料は無料でダウンロードできますので、この機会にぜひ内容をご覧ください。
