■
週末なのでポエム的なものを。
調理する、つまり料理を作ることをシステム開発のプロセスやプロジェクトマネジメントに例えて解説するケースをよく見かけるし、もしかしたら以前に書いていたかもしれない。検索するとどちらかと言えば懐疑的に書いているかもしれない。
少し前に研修を設計していると書いた。講座の狙いを考えると受講目的を実現する方法の実現が難しい。難しいというのは思いつくやり方では、前提知識のハードルを無意識に置いていることを気づいているからだ。
それで料理とシステム開発とプロジェクトマネジメントであるが、もし具体的な事例として取り込むなら、例と関連づけはこんな感じだろう。
料理とプロダクトマネジメント
レシピどおりに作る場合と創作とは同じものではない。
手順、分量、道具、調理時間を厳密に決め、それ以外認めない場合はエンジニアリングであり、ルーチンワークである。
創作するとは別物。
創作は既存の手法、確立された手順、分量、道具のパラメータを変える。継続的イノベーションである。
創作から手順、分量、道具、調理時間を試行錯誤した後、パラメータを確定したらルーチンワークになる。
言われて作る、指示されて作るときはイライラしやすい。特に『なんでもいい』というケースは、プロダクトの選定から始まり、作って見ないと要求と答え合わせできないのでフラストが起きやすい。
料理は小さく（少量）作ることはできても、時間の短縮はできない。これを忘れてはいけない。
逆に大きく作るも道具のキャパシティの上限から制約される。型のサイズ、数量を揃えることは先行投資と維持保管するコストを増やす。オーブンをいくつも揃えることも現実的ではない。オーブンの内側のサイズを超えるサイズの料理はできない。
制約を知ること。
料理とプロジェクトマネジメント
- 何を作るか（プロジェクトの目的）
- いつまでに作るか（納期）
- 材料、道具は何か（リソース）
- 食材や道具にかけられる費用はいくらか（C）
- 作る料理の味（Q）、出来上がりの時間（D）、材料や人件費の費用（C）、スケジュール（S）の目標は何か
- QCDSが守れないとどうなるか（リスク）
- スケジュール（工程）を作成したか（計画）
- スケジュールどおりに作成しているか（予実）
- 出来上がった料理の味、分量は計画どおりか（評価）
- 得られた経験は何か（プラクティス）
調理とシステム開発手法
料理ではなく、調理。
- 何を作るか（仕様）
- 料理の味は設定できているか（完了基準）
- 盛り付けの要求はあるか（定性的品質）
- どのように作れば良いか手順を知っているか（手順の確立）
- どのような道具で作れば良いか（生産性向上ツールの選定）
- 料理を分解できるか（WBSの作成）
- 手順ごとの部品の作成（プログラムモジュールの作成）
- 全ての部品の統合（ビルド）
- 味見の結果はどうか（機能テスト）
- 盛り付けはイメージどおりか（非機能テスト）
- 食べた人の評価はどうか（UAT）
調理とツール＆テクニック
例えば時間短縮、品質の確保の観点で道具を使うことは生産性向上、歩留まりに貢献する。
調理とマインドセット
料理を調理した後のレスポンスは『美味しい』か『無言』である。調理をすることにおいて、そのマインドを外に置くことは調理人のマインドを揺さぶり、料理のできかがりに影響する。
