「発注したら終わり」ではない、が「口を出し続ける」でもない
外注先を決め、プロジェクトが動き始めると、承継社長の関わり方に迷いが生まれます。せっかく専門の開発会社に頼んだのだから細部まで任せたい気持ちがある一方、先代の代から使われてきた業務が絡む刷新だけに、現場の実情を知らない外注先に丸投げしていいのか不安も残ります。
実際には、「丸投げ」と「過干渉」のどちらも刷新を失敗させる典型パターンです。丸投げ発注が失敗する理由と、承継社長が果たすべき発注者の役割にあるとおり、発注者にしか決められない判断は必ず存在し、それを放棄するとプロジェクトは迷走します。逆に、開発会社の判断すべき領域にまで社長が細かく口を出すと、現場は疲弊し、専門性を活かせないまま進行が遅れます。この記事では、フェーズごとにどこまで関与すべきかを時系列で整理します。
要件定義〜発注段階: 社長主導が原則
プロジェクトの立ち上がり、つまり「何を・なぜ刷新するか」を固める段階は、承継社長自身が主導すべき局面です。この段階を外注先に丸投げすると、自社の業務の実情を知らない相手が要件を作ることになり、後から「思っていたものと違う」というズレの原因になります。
- 解決したい業務課題を自分の言葉で説明できるようにしておく
- 現場のヒアリングには可能な限り同席するか、結果を必ず自分の目で確認する
- 予算感・納期の希望は曖昧にせず、最初にはっきり伝える
この段階で丸投げしないための資料の作り方は、要件定義、開発会社に伝わる資料の作り方を参考にしてください。ここで手を抜くと、後の工程でどれだけ良い開発会社に当たっても、ズレを取り戻すのは難しくなります。
開発〜実装段階: 定例確認に絞り、細部は任せる
要件が固まり、実際の開発が始まったら、社長の関与の仕方は変わります。この段階で毎週のように進捗を細かく問い詰めたり、実装方法にまで口を出したりすると、開発会社側の作業効率を落とし、本来の専門性を発揮させられなくなります。
代わりに意識したいのは、次のような「定例での確認」に絞ることです。
- 合意した進捗マイルストーンごとに、実際に動くものを見せてもらう
- 仕様変更が必要になった場合は、追加費用の扱いを都度明確にする
- 現場担当者からの疑問や不満が出ていないか、定期的に吸い上げる
仕様変更が発生したときにもめないための手順は仕様変更を伝えるとき、追加費用でもめないための手順にまとめています。開発の中身そのものより、意思決定と費用の透明性を保つことに社長の関与を絞るのが、この段階での適切な距離感です。
検収〜納品段階: 社長が主体的に確認すべき局面が戻る
開発が完了に近づくと、社長の主体的な関与が再び必要になります。ここで丸投げしてしまうと、実際に現場で使われないシステムがそのまま「完成」として引き渡されるリスクがあります。
- 発注時に決めた要件が満たされているか、検収の基準に沿って確認する
- 実際の業務データを使って、現場担当者に試用してもらう
- 不具合や使い勝手の問題は、検収前にリストアップして開発会社に伝える
この段階の確認ポイントは検収で見るべきポイントと不具合対応の依頼方法で詳しく扱っています。検収は形式的な手続きではなく、丸投げにしないための最後の関門だと捉えてください。
運用開始後: 役割分担を明確にして距離を取る
納品・検収が終わり運用フェーズに入ったら、社内と開発会社の役割分担を明確にし、社長は日常運用から距離を取ってよい段階になります。ここでまだ細部に関与し続けると、今度は社内の担当者が育たず、いつまでも社長がボトルネックになってしまいます。
運用フェーズでの適切な体制の分け方は運用フェーズの体制。承継後の社内と開発会社の役割分担を参照してください。ここまで来て初めて、社長は次の刷新テーマの検討に頭を切り替えられます。
良い発注者であり続けるための習慣
フェーズによって関与の濃淡を変えることに加え、プロジェクト全体を通じて意識しておきたい習慣もあります。感情的な対立を避けつつ、必要な指摘はきちんと伝える姿勢です。承継社長が良い発注者になるための7つの習慣には、丸投げにも過干渉にも傾かないための具体的な心構えがまとめられています。
まとめ: 関与の量ではなく、関与するポイントを変える
社内主導で進めるか外注に任せきりにするかは、二者択一ではありません。要件定義と検収では社長が主体的に関与し、開発の実作業段階では定例確認に絞って任せる——この濃淡をフェーズごとに切り替えることが、丸投げと過干渉のどちらの失敗も避ける現実的な進め方です。
刷新実行フェーズはまだ最初の1件で終わりではなく、今後も似たような発注判断を繰り返すことになります。今回のプロジェクトでどこまで関与すべきだったかを振り返っておくと、次の刷新をより効率よく進める判断材料になります。