段階 01
最初の会話で本当の課題を見つける必要がある
最初から長いワークショップをするのではなく、案件の形を見極めることが重要です。
なぜ必要か
良い協業フローは、開発前の隠れた前提を減らします
多くの交付問題は、開発開始前の曖昧さから始まります。
段階 02
期待が膨らむ前に範囲を絞る
最初の業務チェーンが見えるほど、案件は地に足がつきます。
段階 03
初版完成前から導入を考える
教育、切替、責任はリリース後ではなく前から扱うべきです。
段階 04
後続改善の居場所を残す
次フェーズの扱いが初版中に考えられている案件は健康です。
早めに揃えること
初期に揃えるべきなのは、範囲、責任、進行リズムです
この三つが明確なほど、案件は後からも扱いやすくなります。
重点 01
初期フェーズに入れるものを決める
初版で何を本当に支えるか、何を後回しにするかを整理します。
重点 02
誰が参加し、誰が決めるかを明確にする
協業時の役割明確さは、完成後のシステム設計と同じくらい重要です。
重点 03
時期圧力を明確にする
重要日程、提携要請、体制能力は初期範囲に強く影響します。
重点 04
レビューと改善の扱い方を決める
後続課題や追加要望をどう扱うかを先に決めると安定します。
典型的な流れ
協業フローは通常この四段階で進みます
形は変わっても、基本ロジックは多くの交付案件で共通です。
初回会話
課題、現在段階、方向の明確さを把握します。
範囲と構造の整理
最初のチェーン、責任、依存関係、時期を実務的な案に絞ります。
初版の立上げ
実装、確認、切替、教育を一つのチェーンとして進めます。
レビューと後続改善
反応と新要望を、より制御された形で次フェーズへ入れます。