関係者と決裁の地図

止まる場所は決まっている

開発の遅れを振り返ると、コードを書いている時間よりも、確認と承認を待っている時間のほうが長いことがよくあります。原稿がまだ来ない、デザインの最終判断が出ない、社外の協力先の返事が届かない。いずれも技術の問題ではありません。この資料は、待ち時間の発生場所を着手前に地図にしておくためのものです。所要は30分程度です。

ステップ1: 関係者をすべて書き出す

プロジェクトに関わる人を、社内外を問わず書き出します。会議に出る人だけでなく、「その人の承認が無いと進まない」人、「後で文句を言いそうな人」も含めます。後者を最初から巻き込んでおくことが、終盤の手戻りを防ぎます。人数が多い場合は部署や組織の単位でまとめても構いませんが、最終的に名前が入らない欄は空白と同じだと考えてください。

• 社内: 決裁者、事業担当、実務担当、情報システム、経理、法務
• 現場: 実際にそのシステムを日々使う人
• 社外: 開発パートナー、デザイン、既存システムの保守会社、外部の顧問
• 顧客側: 導入先の担当者（BtoBの場合）

ステップ2: 役割を4つに分ける

書き出した関係者を、決める人・実行する人・意見を求める人・知らせる人の4つに分けます。重要なのは、1つの判断について「決める人」を1人にすることです。複数いると、意見が割れたときに止まります。合議で決める場合でも、最終的に決を採る人を明示してください。意見を聞く人を増やしすぎると、それだけで日程が延びます。

ステップ3: 判断ごとに担当を割り当てる

役割は人ではなく、判断の種類ごとに決めます。同じ人がある判断では決める人でも、別の判断では意見を聞く人になります。開発プロジェクトで発生しやすい判断を並べ、それぞれに決める人を書き込んでください。ここで「誰か分からない」と出てきた行が、将来止まる場所です。着手前に埋めておけば、その一行を埋めるのに1日で済みます。

• 作る範囲を確定する判断
• デザインの最終確認
• 掲載する文章・写真の確定
• 外部サービスの利用と、その費用の承認
• 個人情報の扱いに関する判断
• リリースするかどうかの最終判断
• 追加費用が発生する変更の承認

ステップ4: 確認にかかる日数を書く

それぞれの判断について、依頼してから返事が返るまでの現実的な日数を書きます。理想ではなく実績で書いてください。決裁が週1回の会議でしか行われないなら、最大で1週間です。社外の関係者が絡む判断は、さらに時間がかかります。この日数の合計が、計画に織り込むべき待ち時間です。開発期間の見積りに、この待ち時間が入っているかを確認してください。

• 通常どれくらいで返事が返るか（実績で）
• 決裁の会議が定例なら、その頻度と締め切り
• 決める人が不在のときの代理は誰か
• 急ぐ場合に短縮できる手段はあるか

ステップ5: 窓口を1本にする

開発パートナーへの連絡経路が複数あると、指示が食い違います。社内の誰が窓口になるかを1人決め、その人を通す運用にしてください。ただし窓口の人が全部を判断する必要はありません。窓口は伝言と交通整理を担い、判断はステップ3で決めた人が行う、という分け方にします。窓口が不在になる期間も、あらかじめ共有しておきます。

• 社内の窓口（氏名・連絡手段・反応できる時間帯）
• 開発側の窓口（氏名・連絡手段）
• 急ぎのときの連絡方法と、その基準
• 窓口が不在になる期間と、その間の代理

ステップ6: 自社側の宿題を可視化する

開発が止まる原因のうち、発注側の作業が遅れているケースは相当な割合を占めます。原稿、写真、既存データの書き出し、社内規程の確認、テストへの協力。これらを一覧にし、締め切りと担当を入れてください。開発の工程表に自社側の作業が1行も載っていないなら、その工程表は現実を映していません。自社の作業にも、本業と並行する人の時間がかかります。

• 用意する原稿・画像・データと、その締め切り・担当
• 既存システムからの情報提供（担当部署の協力が必要なもの）
• テストに協力する人と、その時間の確保
• リリース時の社内周知・利用者への案内の準備

書き終えたら

完成した地図は、開発パートナーにも共有してください。相手は「この件は誰に聞けばよいか」が分かり、確認待ちの時間を見込んだ提案ができます。プロジェクトの途中で人が入れ替わったときは、その都度更新します。なお、契約や個人情報の扱いに関する判断については、社内で決める人を決めたうえで、必要に応じて外部の専門家の確認も受けてください。本資料は一般的な情報であり、個別の事案は専門家にご確認ください。