TOCを活動の中心に据える ～SW開発現場や個人の活動に役立つ考え方と事例の紹介～

TOCセミナー長崎vol.3（https://peatix.com/event/4761675）での発表内容
TOCを活動の中心に据える　～SW開発現場や個人の活動に役立つ考え方と事例の紹介～
＜概要＞
最近は当たり前のようにTOCの考え方が取り込まれた動き方・考え方をしていると感じてます。
今回は特にソフトウェア開発現場や個人の活動を対象として、TOCをどのように役立てているか、どのような考え方が身に付いているのか、という点を紹介します。皆様の身近な活動を少し良くするヒントになれば幸いです。

Transcript

1. 1 2026/02/02 TOCセミナー長崎 vol.3 TOCセミナー長崎 vol.3 TOCを活動の中心に据える ～SW開発現場や個人の活動に役立つ 考え方と事例の紹介～ ＠NoriyukiMizuno 水野のりゆき TOC/TOCfE北海道 TOCfE関西分科会
2. 2 2026/02/02 TOCセミナー長崎 vol.3 参考：TOCセミナー長崎の状況 過去、TOCセミナーが2024/04、2025/11に開催 第一部 TOC先導者による「放課後セミナー」 第二部 TOC実践者による「事例・活動共有」 ※第二部にコッソリ参加 【百聞は一見にしかず】心理的安全性と成果を 両立させるWA(和)のプロジェクトマネジメント ～プロジェクト推進のDX～
3. 3 2026/02/02 TOCセミナー長崎 vol.3 エリヤフ・ゴールドラット博士が考案した一連の体系。 制約理論（Theory of Constraints） ザ・ゴール（生産技術）からはじまり、各業界のビジネスに 対して効果の出る手法から、考える力を強化するための 思考方法（TOC思考プロセス）まで多数提案されている 最近は漫画版が出ている状況 TOCって？
4. 4 2026/02/02 TOCセミナー長崎 vol.3 どちらさま？ 今日はただのTOCマニアとしてお話します。
5. 5 2026/02/02 TOCセミナー長崎 vol.3 時系列ベース：TOC関連の活動 2010 CCPM TOCfE ザ・ゴールを読む 全体最適のプロジェクトマネジメントを読む 2011 2012 TOC/TOCfE関西（TOCfE関西分科会）が発足、イベントが多数発生 大和ハウスさん（松山さん）のCCPM事例を聞く イベントにてTOCfEを知る、勉強会でツールを学ぶ 業務にてCCPMを試行錯誤する →まあまあ成果が出る ｜－ SQiP2013（ソフトウェア品質シンポジウム）で発表 ｜－ SQiP2014でも発表 CCPM折り紙ワークショップを作成 2013 2014 （個人でクリティカルシンキングを学習） TOCfE国際認定プログラム（京都）に参加 TOCfE関西のイベントで参加者と学ぶ（講師実施等） TOC/TOCfE北海道を立上げ、各種イベントの開催を実施 今まで学んだ体系＋αを整理（以下例） ・プロジェクトマネジメントの概要と CCPMによる工期短縮の仕組み ・提案を検証する技術（マフィアオファー（URO）活用技術） 2016 TOCfEファシリテータへ 北海道で各ツールの紹介・ワークショップ TOCfE国際認定プログラム北海道（2018） 企画・運営、講師担当 SaPIDTOC～未来予想型チーム運営ワークショップ作成 2018 第11回教育のためのTOCシンポジウム（2022）発表 2024- TOC/TOCfE北海道イベント再開 2022-26 2024 CCPM折り紙ワークショップ ベトナム開催 （別活動） 書籍翻訳・出版 2024、2026 TOCセミナー長崎 vol.1、vol3
6. 6 2026/02/02 TOCセミナー長崎 vol.3 自己紹介 水野昇幸（みずののりゆき） ・Twitter（X）：@NoriyukiMizuno ソフトウェアエンジニアリング関連 ・（監訳/共訳）実践ソフトウェアエンジニアリング（第9版）、オーム社、2021 ・8th長崎QDG（2025）：ビジネスと現場活動をつなぐソフトウェアエンジニアリング ・WACATE2024 Summer：モデリングのそだてかた ・ソフトウェア品質シンポジウム2022：演習で学ぶ実践ソフトウェアエンジニアリング ・JaSST22東京：（パネル）ソフトウェア開発にかかわる全てのエンジニアの一般教養 「ソフトウェアエンジニアリング体系」における品質技術 保有資格とか ・経営学修士（MBA）＠グロービス経営大学院（2025卒業） ・簿記3級、2級、JTSQB-FL/ALTM/ALTA、情報処理エンベデッド/プロマネ ・TOC-CCPMスペシャリスト（インプリメンター資格） 国際NPO TOC for Education, Inc 認定「ファシリテータトレーニング」 「思考及びコミュニケーションツールトレーニング」修了 コミュニティ系 ・TOC/TOCfE北海道、TEF道、JaSST北海道実行委員 ・ETロボコン実行委員など
7. 7 2026/02/02 TOCセミナー長崎 vol.3 自己紹介 TOC（制約理論：Theory of Constraints）関連発表 ・TOCセミナー長崎（2024）：仕事でもコミュニティでも役立つTOC 約15年の活動から ・第11回教育のためのTOCシンポジウム（2022）： 500ページ超（原書650ページ超）の訳書の出版へ向けてATTで考えて活動したお話し ～TOCfEとソフトウェア開発技術の組合せ活用 ・JaSST’18東京：SaPIDTOC～未来予想型チーム運営ワークショップ（チュートリアル） ・SQiP2014：CCPMの考え方を活用したテストフェーズにおける課題解決 ～課題発見、解決までのケーススタディ～ ・SQiP2013：システムテスト実施フェーズにおけるボトルネック/クリティカルチェーンを 特定した残日数管理マネジメントとその効果 TOC関連の講演資料・ワークショップ ・プロジェクトマネジメントの概要とCCPMによる工期短縮の仕組み ・提案を検証する技術（TOC マフィアオファー（URO）活用技術） ・SaPIDTOC～未来予想型チーム運営ワークショップ ・CCPM折り紙ワークショップ ※2014年から12回くらい実施、300名以上が受講 ・CCPMカレーワークショップ ・SaPIDTOC～未来予想型チーム運営ワークショップ TOCおよびTOCfEイベント企画・運営 ・TOC/TOCfE北海道立上げ（2016） ・TOCfE国際認定プログラム北海道開催（2018）
8. 8 2026/02/02 TOCセミナー長崎 vol.3 自己紹介 ソフトウェアテスト/テスト自動化関連（海外） ・（共著）InSTA2019＠西安：Coexistence of test execution efficiency and test ・（共著）InSTA2018＠Sweden：Proposal for Enhancing UTP2 with Test Aspects ・（共著）InSTA2017＠東京：Test Conglomeration - Proposal for Test Design Notation like Class Diagram ・（共著）6WCSQ＠ロンドン（2014）：Stepwise Test Design Method ソフトウェアテスト/テスト自動化関連（国内） ・JaSST’25関西：変化する開発、進化する体系 時代に適応するソフトウェアエンジニアの知識と考え方 ・JaSST’21東京： （チュートリアル）価値につながる要件・仕様からテストを考える ・ET⁻WEST2018：なぜ組込みシステムにおけるテストは難しいのか ～ 2つのテストアーキテクチャによってテストを組立てる ～ ・JaSST’17関西：納得できるテストをつくるアプローチ ・テストカタマリーの紹介/活用したテスト設計プロセス案 テスト設計コンテスト関連 ・ 優勝：2017年 STUDIO IBURI ・準優勝：2012年 あまがさきてすとくらぶ 要件定義関連 ・DevSumi関西2020：伝統的食品工場エンジニアリング会社が挑むDXへの ビジネスアイデアをRDRAによる要件定義でプロダクト開発へつなぐ～Side：要件定義 ・RDRA+プロトタイピングおよび仕様化時に役立つ技術、事例紹介
9. 9 2026/02/02 TOCセミナー長崎 vol.3 自己紹介 ※業務関連 ▪過去 ・某電機メーカーで宇宙・防衛系の システム設計・プロマネなど 開発～保守まで全工程に対応 ・大規模プロジェクトでの開発 ▪現在（2016～） ・流しのソフトウェアエンジニア（フリーランス） ソフトウェア開発のなんでも支援 ※PjM/PdM、要件定義、実装/インフラ、テスト、保守 ・支援企業は車・食品・旅行業など ・現状は企業内スタートアップ的な プロダクト開発を支援中（2019～）
10. 10 2026/02/02 TOCセミナー長崎 vol.3 とはいえ… いきおいで池田さんとイベント確定しちゃいました。 とはいえ… 最近TOCって 使ってたっけ？ 当たり前になりすぎて、普段から使っていることに気が付かない 考え方が普段の仕事のスタイルに取り込まれている状態
11. 11 2026/02/02 TOCセミナー長崎 vol.3 あらためて概要 タイトル： TOCを活動の中心に据える ～SW開発現場や個人の活動に役立つ考え方と事例の紹介 アブストラクト： 約15年ほど前にTOCを学び、様々な活動に適用してきました。最近は当たり前のように TOCの考え方が取り込まれた動き方・考え方をしていると感じてます。 今回は特にソフトウェア開発現場や個人の活動を対象として、TOCをどのように役立てて いるか、どのような考え方が身に付いているのか、という点を紹介します。皆様の身近な 活動を少し良くするヒントになれば幸いです。 原理・原則 実践 × 原理・原則を活用した実践事例について紹介してみます
12. 12 2026/02/02 TOCセミナー長崎 vol.3 TOCの知見紹介：ざっくり 制約理論（Theory of Constraints）の個人的な解釈 「The Goal」として定めた指標を高めるために、 全体の流れ（Flow）においてボトルネックとなる “制約”に集中して活用・改善を行うことで、 飛躍的な成果を達成する。 ※このFlowはサプライチェーンの時も、開発プロセスの時もあるかも。 ボトルネック（制約）が生産性を決める 「The Goal」に向けて 「Flow（流れ）」を改善するのだ
13. 13 2026/02/02 TOCセミナー長崎 vol.3 TOCの知見紹介：ざっくり 制約理論（Theory of Constraints）の個人的な解釈 →成果に直結する要素：制約 ※優先改善対象となる 制約 システム ※システム内の要素は関連性が存在 制約 成果
14. 14 2026/02/02 TOCセミナー長崎 vol.3 TOCの知見紹介：ざっくり 制約理論：制約の５つの集中ステップ 1.制約を見つける IDENTIFY the system’s constraint. 2.システムの制約を徹底活用する方法を決める Decide how to EXPLOIT the system’s constraint. <make full use of and derive benefit from (a resource).> 3.前の意思決定にその他すべてを従属させる SUBORDINATE everything else to the above decisions. 4.システムの制約の能力を高める ELEVATE the system’s constraint. 5.警告！ 惰性がシステムの制約とならないようにすること この制約が制約でなくなったら、ステップ１に戻る WARNING!!!!! Do not allow INERTIA to become the system’s constraint. When a constraint is broken, go back to Step 1.
15. 15 2026/02/02 TOCセミナー長崎 vol.3 TOCの知見紹介：ざっくり 制約は業種によりカタチを変える：生産/工場 1本のラインならシンプルとなります。 1日のS2の生産量は…？ 制約！ 4個 2個 4個 5個 2個
16. 16 2026/02/02 TOCセミナー長崎 vol.3 TOCの知見紹介：ざっくり 制約は業種によりカタチを変える：生産/工場 S2だけではなく、S1/DSといった製品もある場合…？ ※実際はずっと複雑 4個 2個 4個 5個 S2 5個 4個 6個 S1 4個 3個 4個 DS 5個 0～3個 3～4個 1～2個
17. 17 2026/02/02 TOCセミナー長崎 vol.3 TOCの知見紹介：ざっくり 生産数はある意味「作業時間」とみなすことも可能 1日8時間作業で換算すると以下の通り 2hr/個 4hr/個 2hr/個 1.6hr/個
18. 18 2026/02/02 TOCセミナー長崎 vol.3 TOCの知見紹介：ざっくり 複数の生産“数”ではなく1個を作るまでで考えると？ ※正確にはリードタイム/サイクルタイム/タクトタイムとかあり複雑… 2hr/個 4hr/個 2hr/個 1.6hr/個 9.6hr/個（サイクルタイム）
19. 19 2026/02/02 TOCセミナー長崎 vol.3 TOCの知見紹介：ざっくり 制約は業種によりカタチを変える：プロジェクト/一点物 →「1つのモノ」を完了させるまでの“時間”が重要 20日 40日 20日 16日 制約！ 完了までに一番時間のかかるタスク列
20. 20 2026/02/02 TOCセミナー長崎 vol.3 TOCの知見紹介：ざっくり 制約は業種によりカタチを変える：小売 →顧客の求める製品を提供可能な在庫確保が難しい 倉庫・棚に製品を置ける量・スペースが制約
21. 21 2026/02/02 TOCセミナー長崎 vol.3 TOCの知見紹介：ざっくり 営業/提案向け、考える力/問題解決力向上も存在 考える力 問題解決 TOC思考プロセス TOCfE (TOC for Education) ブランチ クラウド アンビシャス ターゲットツリー DBR （工場生産） CCPM （プロジェクト） マフィアオファー （営業/提案） … 小売 2016くらいに雑多にまとめた内容
22. 22 2026/02/02 TOCセミナー長崎 vol.3 TOCの知見紹介：ざっくりまとめ （個人的解釈） 制約を意識して活動をすることで、労力→成果直結へ 制約 システム 制約 成果
23. 23 2026/02/02 TOCセミナー長崎 vol.3 TOC、簡単ですね！ 制約を見つけて解決する、だけです！簡単ですね！ 本当ですか？ ・ものごとはそもそもシンプルである Inherent Simplicity ・どんな対立も解消できる Every Conflict can be Removed ・人はそもそも善良である People are Good ・決して"知っている"といわない Never Say "I Know" TOCの4本柱 参考：https://japan-toc-association.org/blog/elischragenheimblog_post45_istocanideologyorapragmaticapproach_discussingthepillarsoftoc/
24. 24 2026/02/02 TOCセミナー長崎 vol.3 知見と事例紹介の結び付け 現実には「簡単」ではない部分が多数あります ※本当に簡単なら、多くの人がやってますね 本発表ではTOCの知見（原理・原則）と具体例（実践） を結び付けて紹介します まず、CCPM（Critical Chain Project Management）を 中心にCCPMの知見と具体的な事例での活用を紹介します ※紹介したひな形含め、希望あれば提供もできます 発表中なり質疑なりで意見をいただければと
25. 25 2026/02/02 TOCセミナー長崎 vol.3 CCPM超ざっくり紹介 プロジェクト/一品物に関するTOCの手法となります。 制約は「完了までに一番時間のかかるタスク列」 20日 40日 20日 16日 制約！ 完了までに一番時間のかかるタスク列
26. 26 2026/02/02 TOCセミナー長崎 vol.3 知見：CCPMの成果が出る仕組み CCPMはロジカルに成果の出る仕組みが仕込まれてます ①クリティカルチェーン（＝制約）を明確にする クリティカルチェーンにはリソース制約を考慮する ＜以下、制約を徹底活用するための方法＞ ②効果的に進めるためバッドマルチタスクを廃する ③(学生症候群/パーキンソンの法則（早期完了の未報告） をなくす) ④不確実性をバッファで対処、バッファにて進捗モニタ ※カッコ項目は今回の事例紹介には直結しない内容です 以下スライドからの引用です。詳しく知りたい方はこちらもどうぞ https://speakerdeck.com/mizunori/puroziekutomanezimentonogai-yao-toccpmniyorugong- qi-duan-suo-noshi-zu-miwoxue-bou-2023ban
27. 27 2026/02/02 TOCセミナー長崎 vol.3 開発におけるプロジェクト期間を決めるのは？ ⇒ 一番長いタスク列：クリティカルパス プロジェクト期間 要件定義 外部設計A 外部設計B 内部設計A-1 内部設計A-2 コーディング・単テ コーディング・単テ 結合/システムテスト 内部設計B コーディング・単テ ここの遅れの解決を 優先すべき？ 知見①：クリティカルチェーンを明確にする
28. 28 2026/02/02 TOCセミナー長崎 vol.3 プロマネ体系では、クリティカルパスを決めるために 「タスク前後依存性」は明確に述べられています。しかし・・・？ PERT図/アローダイヤグラムによる検討例⇒スケジュール化 の例 基本設計 10日 詳細設計 4日 ｺｰﾃﾞｨﾝｸﾞ 4日 単体ﾃｽﾄ 4日 ｺｰﾃﾞｨﾝｸﾞ 6日 単体ﾃｽﾄ 5日 ｺｰﾃﾞｨﾝｸﾞ 3日 単体ﾃｽﾄ 3日 詳細設計 6日 詳細設計 3日 結合ﾃｽﾄ 6日 知見①：クリティカルチェーンにリソース制約を考慮
29. 29 2026/02/02 TOCセミナー長崎 vol.3 この予定で 終わりそうな 気もしますが… プロマネ体系では、クリティカルパスを決めるために 「タスク前後依存性」は明確に述べられています。しかし・・・？ PERT図/アローダイヤグラムによる検討例⇒スケジュール化 の例 タスク 担当 計画 基本設計 モジュールA 詳細設計、コーディング、単体テスト モジュールB 詳細設計、コーディング、単体テスト モジュールC 詳細設計、コーディング、単体テスト 結合テスト 10 4 4 4 6 5 6 3 3 6 3 基本設計 10日 詳細設計 4日 ｺｰﾃﾞｨﾝｸﾞ 4日 単体ﾃｽﾄ 4日 ｺｰﾃﾞｨﾝｸﾞ 6日 単体ﾃｽﾄ 5日 ｺｰﾃﾞｨﾝｸﾞ 3日 単体ﾃｽﾄ 3日 詳細設計 6日 詳細設計 3日 結合ﾃｽﾄ 6日 知見①：クリティカルチェーンにリソース制約を考慮
30. 30 2026/02/02 TOCセミナー長崎 vol.3 プロマネ体系では、クリティカルパスを決めるために 「タスク前後依存性」は明確に述べられています。しかし・・・？ PERT図/アローダイヤグラムによる検討例⇒スケジュール化 の例 タスク 担当 計画 基本設計 赤 モジュールA 詳細設計、コーディング、単体テスト 赤 モジュールB 詳細設計、コーディング、単体テスト 黄 モジュールC 詳細設計、コーディング、単体テスト 赤 結合テスト 赤 10 4 4 4 6 5 6 3 3 6 3 基本設計 10日 詳細設計 4日 ｺｰﾃﾞｨﾝｸﾞ 4日 単体ﾃｽﾄ 4日 ｺｰﾃﾞｨﾝｸﾞ 6日 単体ﾃｽﾄ 5日 ｺｰﾃﾞｨﾝｸﾞ 3日 単体ﾃｽﾄ 3日 詳細設計 6日 詳細設計 3日 結合ﾃｽﾄ 6日 担当者を 明確にして みますと…？ 知見①：クリティカルチェーンにリソース制約を考慮
31. 31 2026/02/02 TOCセミナー長崎 vol.3 プロマネ体系では、クリティカルパスを決めるために 「タスク前後依存性」は明確に述べられています。しかし・・・？ PERT図/アローダイヤグラムによる検討例⇒スケジュール化 の例 タスク 担当 計画 基本設計 赤 モジュールA 詳細設計、コーディング、単体テスト 赤 モジュールB 詳細設計、コーディング、単体テスト 黄 モジュールC 詳細設計、コーディング、単体テスト 赤 結合テスト 赤 10 4 4 4 6 5 6 3 3 6 3 基本設計 10日 詳細設計 4日 ｺｰﾃﾞｨﾝｸﾞ 4日 単体ﾃｽﾄ 4日 ｺｰﾃﾞｨﾝｸﾞ 6日 単体ﾃｽﾄ 5日 ｺｰﾃﾞｨﾝｸﾞ 3日 単体ﾃｽﾄ 3日 詳細設計 6日 詳細設計 3日 結合ﾃｽﾄ 6日 33日⇒37日となる。 約11％増 担当者のリソース制約 昔のPMBOKベースの活動で ハマりやすい部分です 知見①：クリティカルチェーンにリソース制約を考慮
32. 32 2026/02/02 TOCセミナー長崎 vol.3 例：家庭料理 料理をする人は自然とリソース制約を考えてます まあ、1時間ちょいくらい？ 買い物 野菜・肉を切る 炒める・煮る ルーで味付け ご飯をとぐ ご飯を炊く time 包丁 コンロ 炊飯器
33. 33 2026/02/02 TOCセミナー長崎 vol.3 例：家庭料理 料理をする人は自然とリソース制約を考えてます 炊飯器がない、コンロが1つしかないと… 1.5～2時間くらいになっちゃいそう？ ルーで味付け 買い物 野菜・肉を切る 炒める・煮る ご飯をとぐ ご飯を炊く time 包丁 コンロ
34. 34 2026/02/02 TOCセミナー長崎 vol.3 例：家庭料理 仕方ないのでサ◦ウのごはんをレンチン！ クリティカルチェーンは変化させることも可能です 1時間を切ることもできるかも？（レンジは必要） 買い物 野菜・肉を切る 炒める・煮る ルーで味付け time 包丁 コンロ レンジ レンチン
35. 35 2026/02/02 TOCセミナー長崎 vol.3 事例：テスト時のリソース制約 ソフトウェアテストの現場でのリソース制約の事例。 5-10名程度のチーム、1か月～数か月程度の活動に適用 計画から遅れ気味の状況で支援して、まあリカバリー →繰り返し適用でポイント把握・適用範囲を理解 ・遅れ20％くらいならカバーできることも ・（ウォーターフォール開発の）テストフェーズであれば使いやすい
36. 36 2026/02/02 TOCセミナー長崎 vol.3 事例：テスト時のリソース制約 ソフトウェア テストの 現場事例 参考：https://www.juse.jp/sqip/library/shousai/?id=151 データ 準備 テスト 実施 （ボトルネック使用） 結果 整理 データ 準備 改善前 データ 準備 テスト 実施 （ボトルネック使用） 結果 整理 改善後 データ 準備 テスト 実施 （ボトルネック使用） 結果 整理 データ 準備 テスト 実施 （ボトルネック使用） データ 準備 チームA チームB チームA テスト 実施 （ボトルネック使用） ボトルネック使用はテスト実施時のみ 前後の作業も試験装置前で行っていた。 2チームでボトルネックを 最大活用するように並列作業化
37. 37 2026/02/02 TOCセミナー長崎 vol.3 知見：CCPMの成果が出る仕組み CCPMはロジカルに成果の出る仕組みが仕込まれてます ①クリティカルチェーン（＝制約）を明確にする クリティカルチェーンにはリソース制約を考慮する ＜以下、制約を徹底活用するための方法＞ ②効果的に進めるためバッドマルチタスクを廃する ③(学生症候群/パーキンソンの法則（早期完了の未報告） をなくす) ④不確実性をバッファで対処、バッファにて進捗モニタ ※カッコ項目は今回の事例紹介には直結しない内容です 以下スライドからの引用です。詳しく知りたい方はこちらもどうぞ https://speakerdeck.com/mizunori/puroziekutomanezimentonogai-yao-toccpmniyorugong- qi-duan-suo-noshi-zu-miwoxue-bou-2023ban
38. 38 2026/02/02 TOCセミナー長崎 vol.3 知見②：バッドマルチタスクを廃する プロジェクト① 60％？ プロジェクト② 40％？ 急ぎで お願いします！ 大至急で 対応下さいッ！ 「バッド」マルチタスクなので効率の落ちない方もいます とはいえ、お仕事あるあるとして… 複数から同時に依頼された仕事を進める際には スイッチングコストが発生しやすい状況となります 仕事を 切り替えつつ 双方進める
39. 39 2026/02/02 TOCセミナー長崎 vol.3 知見②：バッドマルチタスクを廃する 切り替えのコストが発生することで、当然チェーンが伸びます 参考：オリジナルはプロジェクト単位の検収（売上）までの時間を重要視 プロジェクトA プロジェクトB プロジェクトA プロジェクトB 切り替えのコスト ※プロジェクトが多く、 切り替えも多いほど チェーンは伸びる傾向
40. 40 2026/02/02 TOCセミナー長崎 vol.3 知見②：バッドマルチタスクを廃する 参考：オリジナルはプロジェクト単位の検収（売上）までの時間を重要視 あわせて、「同時並行が増えすぎない流入（受注）量の制御」を提案 納期遵守失敗 例：同時の流入量を「２」に制限
41. 41 2026/02/02 TOCセミナー長崎 vol.3 事例（応用）：複数業務の扱い バッドマルチタスクの軽減の方法（個人のやり方） マルチタスクは兎も角として、「マルチプロジェクト」 の単位を多少コントロールすることは可能です 複数プロジェクトを受け持つ際、「曜日」単位で分ける ※XX%とかで謎な割り振る企業文化でも交渉しやすい 「半日単位」とかもあります。が、実担当ではイマイチな感触 月曜 火曜 水曜 木曜 金曜 プロジェクト A プロジェクト B プロジェクト B プロジェクト A プロジェクト C
42. 42 2026/02/02 TOCセミナー長崎 vol.3 知見：CCPMの成果が出る仕組み CCPMはロジカルに成果の出る仕組みが仕込まれてます ①クリティカルチェーン（＝制約）を明確にする クリティカルチェーンにはリソース制約を考慮する ＜以下、制約を徹底活用するための方法＞ ②効果的に進めるためバッドマルチタスクを廃する ③(学生症候群/パーキンソンの法則（早期完了の未報告） をなくす) ④不確実性をバッファで対処、バッファにて進捗モニタ ※カッコ項目は今回の事例紹介には直結しない内容です 以下スライドからの引用です。詳しく知りたい方はこちらもどうぞ https://speakerdeck.com/mizunori/puroziekutomanezimentonogai-yao-toccpmniyorugong- qi-duan-suo-noshi-zu-miwoxue-bou-2023ban
43. 43 2026/02/02 TOCセミナー長崎 vol.3 ちょっとゆっくり やってもいいかな… 見込み 2日 個別バッファ 2日 他プロジェクトの依頼 を1.5日分やろうっと 残り期間 作業せず 実作業期間：2.5日 終了間際に 想定外が… 作業せず 割込み 想定外 予定超過！ ほぼ完了 残り期間 2日で大体出来たかな… 気になる部分作りこもう 予定通り完了しました！ ほぼ完了 作り込み 開始 知見③：（学生症候群・パーキンソンの法則をなくす）
44. 44 2026/02/02 TOCセミナー長崎 vol.3 知見：CCPMの成果が出る仕組み CCPMはロジカルに成果の出る仕組みが仕込まれてます ①クリティカルチェーン（＝制約）を明確にする クリティカルチェーンにはリソース制約を考慮する ＜以下、制約を徹底活用するための方法＞ ②効果的に進めるためバッドマルチタスクを廃する ③(学生症候群/パーキンソンの法則（早期完了の未報告） をなくす) ④不確実性をバッファで対処、バッファにて進捗モニタ ※カッコ項目は今回の事例紹介には直結しない内容です 以下スライドからの引用です。詳しく知りたい方はこちらもどうぞ https://speakerdeck.com/mizunori/puroziekutomanezimentonogai-yao-toccpmniyorugong- qi-duan-suo-noshi-zu-miwoxue-bou-2023ban
45. 45 2026/02/02 TOCセミナー長崎 vol.3 50％は早めに 終わっている 見込み 2日 早く終わる？ 2日 見込み 2日 早く終わる？ 2日 見込み 2日 見込み 2日 ＋ バッファ 2日 バッファ 2日 バッファとして まとめる 遅れるのはわずか これが分かって解決 できると良い 知見④：不確実性をバッファで対処、進捗をモニタ タスク見積りと終了時間は統計的に以下図に近似するらしいです ※人や業務特性により異なり、全員には当てはまらないかもですが 一部がものすごく時間がかかるのであれば、 他を手早く終わるようにして、余分をうまく活用してはどうか？
46. 46 2026/02/02 TOCセミナー長崎 vol.3 プロジェクトの期間を決めるのがクリティカルパス さらに「リソース制約」が明確であれば残り時間がわかる ⇒リソース制約を考慮した最も長いクリティカルパスを最短へ 「クリティカルチェーン」と呼び、進捗管理の対象にしてみる これが遅れると全体バッファを使用して検知。問題を解決する タスク 担当 計画 基本設計 赤 モジュールA 詳細設計、… 赤 モジュールB 詳細設計、… 黄 モジュールC 詳細設計、… 赤 結合テスト 赤 全体バッファ 10 4 4 4 4 5 4 3 3 6 3 １８ FB クリティカルチェーン （今回は赤のタスク列） を明確に決める。 バッファを まとめて 最後に配置 知見④：不確実性をバッファで対処、進捗をモニタ
47. 47 2026/02/02 TOCセミナー長崎 vol.3 CCPMの紹介：実際のやり方 CCPMの手順・概念的紹介 0 20 40 60 80 100 0 20 40 60 80 100 バッファ消費率[%] プロジェクトの進捗率[%] バッファ消費率 タスク1 タスク2 タスク3 バッファ ギリギリ スケジュール +バッファ タスク1 タスク2 タスク3 バッファ バッファ 消費
48. 48 2026/02/02 TOCセミナー長崎 vol.3 CCPMの紹介：実際のやり方 CCPMの手順・概念的紹介 タスク1 タスク2 タスク3 元の計画
49. 49 2026/02/02 TOCセミナー長崎 vol.3 CCPMの紹介：実際のやり方 CCPMの手順・概念的紹介 タスク1 タスク2 タスク3 ギリギリ スケジュール 個別バッファが 無くなるくらい 予定を短縮 ※短縮割合・方法は色々
50. 50 2026/02/02 TOCセミナー長崎 vol.3 CCPMの紹介：実際のやり方 CCPMの手順・概念的紹介 タスク1 タスク2 タスク3 バッファ ギリギリ スケジュール +バッファ 減らした分の 何割かを全体の バッファとして設定 ※バッファ量も任意、 減らした分の半分が多い
51. 51 2026/02/02 TOCセミナー長崎 vol.3 CCPMの紹介：実際のやり方 CCPMの手順・概念的紹介 タスク1 タスク2 タスク3 バッファ ギリギリ スケジュール +バッファ タスク1 タスク2 タスク3 バッファ 当然遅れるので、 遅れた分は 全体バッファ消費 ここで遅れても怒らない
52. 52 2026/02/02 TOCセミナー長崎 vol.3 CCPMの紹介：実際のやり方 CCPMの手順・概念的紹介 0 20 40 60 80 100 0 20 40 60 80 100 バッファ消費率[%] プロジェクトの進捗率[%] バッファ消費率 タスク1 タスク2 タスク3 バッファ タスク1 タスク2 タスク3 バッファ バッファ 消費 全体の進捗と バッファ消費を プロット 見積りの統計変動は全体 バッファで吸収します。 あわせて問題を検知！
53. 53 2026/02/02 TOCセミナー長崎 vol.3 CCPMの紹介：実際のやり方 CCPMの手順・概念的紹介 0 20 40 60 80 100 0 20 40 60 80 100 バッファ消費率[%] プロジェクトの進捗率[%] バッファ消費率 タスク1 タスク2 タスク3 バッファ ギリギリ スケジュール +バッファ タスク1 タスク2 タスク3 バッファ バッファ 消費 プロジェクトの進捗率[%] バッファ消費率[%] 50 50 100 100 プロジェクトの進捗率[%] バッファ消費率[%] 50 50 100 100 進捗25％ バッファ消費80％ ⇒やべえ！ 進捗70％ バッファ消費20％ ⇒余裕♪ バッファ 進捗 残タスク バッ ファ 進捗 残タスク
54. 54 2026/02/02 TOCセミナー長崎 vol.3 事例：バッファ管理グラフの活用 情報処理試験（テスト）の事例となります。 ※完全に個人の活動
55. 55 2026/02/02 TOCセミナー長崎 vol.3 事例紹介（さらに応用） 以降、CCPMより広げた「制約」をとらえる考え方での 事例、考え方をまとめてみます。 制約 システム 制約 成果
56. 56 2026/02/02 TOCセミナー長崎 vol.3 応用事例：システム性能評価 システムの将来の利用者増を想定し、同時利用の限界調査を実施 （常時利用は問題なく、一時的にアクセスが増えるケースを想定） どこを改善するとよいか？ アクセス対象：重めのデータ ※負荷なしでも1秒かかる プログラムで該当データアクセス 同時に10人/20人/30人並列を模擬 →30並列で9～10秒 Appサーバ （BackEnd） DB
57. 57 2026/02/02 TOCセミナー長崎 vol.3 応用事例：システム性能評価 システムの将来の利用者増を想定し、同時利用の限界調査を実施 （常時利用は問題なく、一時的にアクセスが増えるケースを想定） どこを改善するとよいか？→リソース状態から制約を推測 Appサーバ （BackEnd） DB アクセス中の メモリ・CPUに 変化は少ない 特にCPUに スパイクあり 制約！
58. 58 2026/02/02 TOCセミナー長崎 vol.3 応用事例：システム性能評価 システムの将来の利用者増を想定し、同時利用の限界調査を実施 （常時利用は問題なく、一時的にアクセスが増えるケースを想定） →制約と予想されるDBの性能向上をして評価 プログラムで該当データアクセス 同時に10人/20人/30人並列を模擬 →30並列で9～10秒→5～6秒まで改善 Appサーバ （BackEnd） DB 制約！
59. 59 2026/02/02 TOCセミナー長崎 vol.3 応用事例：生成AIの活用に対する意見 生成AIがすごい！生産性10倍！とか聞くのですが…？ 自分の普段行っているプロセスベースで考えてみました バックログ （仕様） 設計 実装 仕様作成 テスト デプロイ ※バックログ単位で 反復的に開発している前提 妥当性確認
60. 60 2026/02/02 TOCセミナー長崎 vol.3 応用事例：生成AIの活用に対する意見 プロセスを詳細化してみると、「実現性調査」が多くを占めます →実現性調査を生成AIで複数案提示・試行できるだけで効果あり ※実際は他の工数も存在、コード生成だけ早くても… バックログ （仕様） 設計 実装 仕様作成 テスト デプロイ ※バックログ単位で 反復的に開発している前提 実現性 調査・試行 デモ版 作成 実装 仕上げ たまにリファクタリング込み 妥当性確認 60(～80) 20 20 100 この辺を大幅改善で 非常に効果あり 40 30 10 20 生成AIの提案
61. 61 2026/02/02 TOCセミナー長崎 vol.3 応用事例：生成AIの活用に対する意見 少しだけ視野を広くして見てみると…？ 手戻りがちらほら発生している状況だったりしていました バックログ （仕様） 設計 実装 仕様作成 テスト デプロイ ※バックログ単位で 反復的に開発している前提 実現性 調査・試行 デモ版 作成 実装 仕上げ たまにリファクタリング込み 妥当性確認 手戻り・追加の発生： ３～５回に１回程度 生成AIの提案
62. 62 2026/02/02 TOCセミナー長崎 vol.3 応用事例：生成AIの活用に対する意見 手戻りがちらほら発生している状況だったりしていました →Vibe Codingによる早期の妥当性確認が効果的ともいえます ※DeNAは全社的にプロトタイピングを取り入れたとのこと バックログ （仕様） 設計 実装 仕様作成 テスト デプロイ ※バックログ単位で 反復的に開発している前提 実現性 調査・試行 デモ版 作成 実装 仕上げ たまにリファクタリング込み 妥当性確認 プロトタイプ 妥当性確認 Vibe Coding 生成AIの提案 手戻り・追加の発生： ３～５回に１回程度
63. 63 2026/02/02 TOCセミナー長崎 vol.3 応用事例：生成AIの活用に対する意見 さらに視野を広げてみると… プロトタイプは営業にも活用はできそう（活用してます） バックログ （仕様） 設計 実装 仕様作成 テスト デプロイ ※バックログ単位で 反復的に開発している前提 実現性 調査・試行 デモ版 作成 実装 仕上げ たまにリファクタリング込み 妥当性確認 手戻り・追加の発生： ３～５回に１回程度 顧客 （候補含む） 提供・運用 顧客の 要望 （課題解決へ） 要件定義 営業に活用 プロトタイプ 妥当性確認 Vibe Coding 将来の 売上源泉 生成AIの提案
64. 64 2026/02/02 TOCセミナー長崎 vol.3 応用事例：生成AIの活用に対する意見 さらに視野を広げてみると… 「学習」にも効果的→範囲を広げて提案＆教育へ（将来の制約？） バックログ （仕様） 設計 実装 仕様作成 テスト デプロイ ※バックログ単位で 反復的に開発している前提 実現性 調査・試行 デモ版 作成 実装 仕上げ たまにリファクタリング込み 妥当性確認 顧客 （候補含む） 提供・運用 顧客の 要望 （課題解決へ） 要件定義 営業に活用 プロトタイプ 妥当性確認 Vibe Coding 将来の 売上源泉 生成AIの提案 Learning! 手戻り・追加の発生： ３～５回に１回程度 教育
65. 65 2026/02/02 TOCセミナー長崎 vol.3 応用事例：生成AIの活用に対する意見 とはいえ… 技術の変化で圧倒的なビジネスにつながる要素が 発生する可能性があります （成長する）技術がどんな制約を取り払うか？は 考えておくとよいでしょう バックログ （仕様） 設計 実装 仕様作成 テスト デプロイ 実現性 調査・試行 デモ版 作成 実装 仕上げ たまにリファクタリング込み 妥当性確認 顧客 （候補含む） 提供・運用 顧客の 要望 （課題解決へ） 要件定義 営業に活用 プロトタイプ 妥当性確認 Vibe Coding 生成AIの提案 Learning! 手戻り・追加の発生： ３～５回に１回程度 教育 圧倒的な技術により、 既存のやり方・ルールを 変えたほうが良いケース
66. 66 2026/02/02 TOCセミナー長崎 vol.3 制約の5つの集中ステップ 制約理論：制約の５つの集中ステップ 1.制約を見つける IDENTIFY the system’s constraint. 2.システムの制約を徹底活用する方法を決める Decide how to EXPLOIT the system’s constraint. <make full use of and derive benefit from (a resource).> 3.前の意思決定にその他すべてを従属させる SUBORDINATE everything else to the above decisions. 4.システムの制約の能力を高める ELEVATE the system’s constraint. 5.警告！ 惰性がシステムの制約とならないようにすること この制約が制約でなくなったら、ステップ１に戻る WARNING!!!!! Do not allow INERTIA to become the system’s constraint. When a constraint is broken, go back to Step 1. 「制約を見つける」ことが一番難しい ※ステップ1つで簡単に言いやがってと思うやつ
67. 67 2026/02/02 TOCセミナー長崎 vol.3 関連で役立つ知識 「制約」を徹底活用・改善する考え方 プロセスの知識 （ソフトウェア開発で特に重要） 思考力 ・論理的/構造的思考 ・問題解決 制約を見つける バックログ （仕様） 設計 実装 仕様作成 テスト デプロイ 実現性 調査・試行 デモ版 作成 実装 仕上げ たまにリファクタリング込み 妥当性確認 顧客 （候補含む） 提供・運用 顧客の 要望 （課題解決へ） 要件定義 営業に活用 プロトタイプ 妥当性確認 Vibe Coding 生成AIの提案 Learning! 手戻り・追加の発生： ３～５回に１回程度 教育
68. 68 2026/02/02 TOCセミナー長崎 vol.3 うまくいかないこともある 手法は特定の条件・状況で最も効果が出るよう作られてます よくできた手法は適用範囲も広いですが、 「効果が出る条件」も明示してます 条件と適合しない場合、うまくいかない ケースも当然発生します 例：スクラムとCCPMのどちらを使うか？ （特に組織内に適用したいような方は） 手法の適用条件、手法の得意な部分・苦手な部分を認識し、 適用条件が揃っているか確認する手続き・チェックシート等や 苦手な部分を補完する方法なども手元に準備する必要があります。
69. 69 2026/02/02 TOCセミナー長崎 vol.3 ということで 最近TOCって 使ってたっけ？ 普段から使っていることに気が付かない 考え方が普段の仕事のスタイルに取り込まれている状態
70. 70 2026/02/02 TOCセミナー長崎 vol.3 ということで タイトル： TOCを活動の中心に据える ～SW開発現場や個人の活動に役立つ考え方と事例の紹介 アブストラクト： 約15年ほど前にTOCを学び、様々な活動に適用してきました。最近は当たり前のように TOCの考え方が取り込まれた動き方・考え方をしていると感じてます。 今回は特にソフトウェア開発現場や個人の活動を対象として、TOCをどのように役立てて いるか、どのような考え方が身に付いているのか、という点を紹介します。皆様の身近な 活動を少し良くするヒントになれば幸いです。 原理・原則 実践 × 原理・原則を活用した実践事例について紹介してみました
71. 71 2026/02/02 TOCセミナー長崎 vol.3 本日できるとよかったこと 「やってみよう、もうちょい学んでみよう！」 という気持ちになってもらえればと ・（明日から）小さく試してもらう ・興味を持ってさらに学んでもらう、役立ててもらう この後の時間も含めて、原理・原則を活用した実践へ 「場」を活用してください！
72. 72 2026/02/02 TOCセミナー長崎 vol.3 参考文献 ＜TOC関連＞ ・TOC全般 ：ザ・ゴールシリーズ＆マンガ版 ・CCPM関連 ：最短で達成する 全体最適のプロジェクトマネジメント ＜思考力関連＞ ・考え方を付ける3つの道具 ※TOC関連（TOCfE）でもあります ・ロジカル・シンキング―論理的な思考と構成のスキル ・考える技術・書く技術―問題解決力を伸ばすピラミッド原則 ＜ソフトウェアプロセス関連＞ ・PFD(Process Flow Diagram)の書き方 https://www.affordd.jp/koha_hp/process/PFDform3.pdf ・実践ソフトウェアエンジニアリング（第9版） ※ソフトウェア開発全般の書籍だがプロセス知識（第１部に記載）が充実