「あと1ヶ月で終わります」を3回聞いた
先代から会社を継いで、基幹システムの入れ替えや新しい受発注システムの構築を発注したことがある後継社長なら、一度はこの感覚を味わっているはずです。開発会社の担当者から「あと1ヶ月で終わります」と言われ、1ヶ月後にもう一度同じ台詞を聞き、さらにもう一度聞く。気づけば当初の予定から半年以上遅れているのに、誰も「なぜ遅れたのか」を数字で説明してくれない。
これは特殊なケースではありません。IT関連の調査機関やユーザー企業団体が繰り返し行っているシステム開発プロジェクトの実態調査では、予算超過・納期遅延を経験したプロジェクトが半数近くに上るという報告が繰り返し出ています。つまり、遅延は「運が悪かった特殊な失敗」ではなく、発注側が構造を理解していないと高い確率で踏む地雷だということです。
先代の時代、システムといえば電話一本で御用聞きに来てくれる地元の業者に「まあまあ、いつもの感じでよろしく」と任せておけば、多少遅れても大きな問題にはならないことが多かったかもしれません。取引先も限られ、業務のスピード自体もそこまで速くなかったからです。しかし今は違います。システムが止まれば受発注が止まり、システムが遅れれば競合に商機を奪われます。納期・スケジュールの見方を知らないまま開発会社に任せきりにすることは、経営リスクそのものです。
この記事では、なぜ開発プロジェクトは遅れるのか、その構造的な原因を分解し、承継社長が発注者としてどこを見て、いつ、何を質問すればよいのかを具体的にお伝えします。専門用語が分からなくても構いません。むしろ「専門用語が分からないなりに、何を聞けば防御できるか」に焦点を当てています。開発会社への相談の前提となる社内の決めごとについては、刷新を開発会社に相談する前に、決めておきたい3つのことを先に読んでおくと理解が深まる。
なぜ開発の納期は「約束通りに終わらない」のか
遅延の8割は「着手前」に仕込まれている
多くの後継社長は、遅延の原因を「開発会社の実装が遅い」「エンジニアの数が足りない」といった、開発の後半フェーズに探そうとします。もちろんそれも原因の一つですが、経験上、遅延の大半は着手前――つまり要件を固める段階――にすでに仕込まれています。
具体的には次の3つです。
- 要件が曖昧なまま見積もりと契約が結ばれている
- 「決める人」が社内で明確になっていない
- スケジュールが「希望日から逆算」で作られている
この3つが揃うと、どんなに優秀な開発チームでも遅延は避けられません。逆に言えば、この3つさえ発注者側でコントロールできれば、遅延のリスクは大幅に下げられます。順番に見ていきましょう。
原因1: 要件が曖昧なまま契約が結ばれている
システム開発の見積もりは、家のリフォームに似ています。「キッチンをきれいにしたい」という要望だけで見積もりを取ると、業者によって金額もスケジュールも大きくばらつきます。壁の位置を変えるのか、配管はそのままか、素材のグレードはどうするか――これらが決まって初めて、正確な見積もりと工期が出せます。
システム開発も同じで、発注前に「何を作るのか」「何を作らないのか」の境界線を文書化しておく必要があります。この境界線を明文化した書類のことを、業界ではSOW（作業範囲記述書）と呼びます。SOWに「在庫管理機能は含むが、発注先へのFAX自動送信機能は次フェーズとする」のように具体的な線引きが書かれていれば、後から「それも含まれると思っていました」という認識のズレによる手戻り、つまりスケジュール遅延を防げます。
多くの中小企業の発注現場では、このSOWに相当する書類が存在しないか、あっても1ページの箇条書き程度で済まされています。その状態で「じゃあ4ヶ月でお願いします」と契約すると、開発が進むにつれて「これも当然入っていると思っていた」という追加要望が次々に出てきて、当初の4ヶ月はあっという間に崩れます。
チェックポイント: 契約前に、開発会社から「今回作るものリスト」と「今回は作らないものリスト」の両方を書面でもらっていますか。片方だけしかない場合、それは要件がまだ固まっていない証拠です。
原因2: 「決める人」が社内で明確になっていない
先代の時代から続く企業でよくあるのが、意思決定の権限が分散している、あるいは誰にあるのか外部から見えにくいという状態です。開発会社が画面デザインの確認を求めても、現場担当者は「部長に聞かないと」と言い、部長は「社長に確認してから」と言い、社長は「現場が使うものだから現場で決めて」と言う。この堂々巡りが1回起きるだけで、平気で1〜2週間のロスが発生します。
これが月に2〜3回起きれば、それだけで1ヶ月以上の遅延要因になります。しかも厄介なのは、この種の遅延は開発会社の進捗報告書には「お客様確認待ち」としか書かれず、誰の責任か曖昧なまま流れてしまうことです。
承継社長として最初にやるべきことは、プロジェクトが始まる前に「この案件について最終的に決める人は自分(または特定の役員)である」と社内外に宣言することです。現場の意見は聞くべきですが、意思決定のボトルネックを作らないことが、納期を守る上で最も費用対効果の高い行動です。
原因3: スケジュールが「希望日から逆算」で作られている
「来年度の決算処理に間に合わせたいので、3月末までにお願いします」という発注の仕方は非常によくあります。しかし、これは順番が逆です。本来スケジュールは「この機能を作るにはこれだけの工程と時間が必要」という積み上げから決まるべきものです。
希望日から逆算して作られたスケジュールは、最初から無理のある前提の上に成り立っています。開発会社が「頑張ればできます」と答えてしまうケースも多く、これは決して開発会社だけが悪いわけではなく、無理な希望日を口にした発注者側にも責任があります。
このような逆算スケジュールで進むプロジェクトほど、終盤になって「テストの時間が足りない」「動作確認が不十分なまま公開する」という事態に陥りやすく、結果的に公開後に不具合が頻発し、余計な手直し工数がかかって、トータルで見れば当初の積み上げスケジュールより時間がかかることも珍しくありません。
スケジュール表の正しい見方――WBS・マイルストーン・バッファ
WBSとは「作業を分解した一覧表」
開発会社から提示されるスケジュール表には、専門用語で「WBS(Work Breakdown Structure、作業分解構成図)」と呼ばれる形式のものがあります。難しそうに聞こえますが、実態は「やることリストを細かく分解して、それぞれに担当者と期限をつけた表」です。
WBSを見るときのポイントは、粒度です。「システム開発:4ヶ月」という1行しか書かれていないスケジュール表は、実質的にスケジュール表として機能していません。少なくとも次の単位まで分解されているかを確認してください。
- 要件を固める工程(何を作るか決める期間)
- 画面や機能の設計をする工程
- 実際にコードを書く工程(機能ごとに分かれているとなお良い)
- 動作確認・テストをする工程
- 本番環境に反映して最終確認する工程
これらが1行にまとめられている場合、「今どこまで進んでいて、あとどれくらいかかるのか」を発注者が把握する手段がありません。遅延が起きても気づいた時には手遅れ、という事態を招きます。
マイルストーンは「途中経過を確認する日」
マイルストーンとは、プロジェクトの途中に置かれた「節目の日」のことです。たとえば「要件を固め終わる日」「画面デザインが確定する日」「テスト用の環境で一通り動く状態になる日」といった具合です。
良いスケジュール表には、最終納品日だけでなく、こうした中間のマイルストーンが複数設定されています。逆に、最終納品日しか書かれていないスケジュールは危険信号です。なぜなら、途中経過を確認するタイミングがないため、遅延に気づくのが最終盤になり、そこから挽回する時間が残っていないからです。
承継社長が発注者としてやるべきことは、マイルストーンごとに「この時点で何がどう見える状態になっているべきか」を開発会社に確認し、実際にその日が来たら必ず自分の目で確認することです。「順調に進んでいます」という口頭報告だけを信じず、実際に画面を触らせてもらう、動くものを見せてもらう習慣をつけてください。
バッファ(予備日数)がゼロのスケジュールは危険
もう一つ確認すべきなのが、スケジュールに「バッファ」――つまり予備日数――が組み込まれているかどうかです。担当者の急な体調不良、想定外の技術的な問題、確認作業の遅れなど、開発プロジェクトには必ず何らかの想定外が発生します。
各工程がぴったり必要日数だけで組まれていて、どこにも余裕がないスケジュールは、一つでも問題が起きた瞬間に総崩れになります。経験則として、全体の工期の1〜2割程度のバッファが確保されているスケジュールの方が、結果的に納期を守れる確率が高くなります。
開発会社に「このスケジュールにバッファはどれくらい入っていますか」とストレートに聞いてみてください。もし「入っていません、目一杯詰めています」という回答であれば、それは黄色信号だと捉えるべきです。
「クリティカルパス」という考え方も知っておくと役立つ
もう一つ、押さえておくと便利な考え方が「クリティカルパス」です。これは、プロジェクト全体の中で「これが遅れると、他の何を早く進めても全体の完成が必ず遅れる」という、いわば一本道の工程の連なりを指します。
たとえば、データベースの設計が終わらなければ画面の実装に着手できず、画面の実装が終わらなければテストができない、というように、工程同士に「これが終わらないと次に進めない」という依存関係がある場合、その一連の流れがクリティカルパスになります。逆に、クリティカルパス上にない作業(たとえば管理者向けの簡単な設定画面など)は、多少遅れても全体の納期には直接影響しません。
発注者としては、進捗報告を受けたときに「それはクリティカルパス上の作業ですか」と一言聞くだけで、その遅れが本当に危険なものなのか、それほど心配しなくていいものなのかを見分けやすくなります。すべての遅れを同じ重みで心配する必要はなく、クリティカルパス上の遅れにこそ注意を集中させるという発想を持つと、限られた時間の中で的確にプロジェクトを見守ることができます。
遅延の予兆を見抜く7つのサイン
現場を実際に見ていなくても、進捗報告のやり取りの中で気づける遅延の予兆があります。以下のいずれかに心当たりがあれば、早めに開発会社と率直な話し合いの場を持つことをおすすめします。
サイン1: 進捗報告が「%表示」だけで具体性がない
「進捗は60%です」という報告だけで、何が完了して何が残っているのかの説明がない場合、要注意です。60%という数字は誰かの主観的な感覚であることが多く、実際に動くものを見せてもらわないと、本当の進捗は分かりません。
サイン2: 質問への回答が遅くなる、または曖昧になる
順調なプロジェクトほど、開発会社からの質問や確認事項への回答は具体的でスピーディーです。逆に、内部で問題を抱えているプロジェクトほど、回答が「検討中です」「確認して折り返します」で止まりがちになります。
サイン3: 「仕様変更」という言葉が頻発する
途中から「仕様変更」という単語が頻繁に出てくる場合、そもそも最初の要件定義が甘かった可能性が高いです。多少の変更は仕方ありませんが、毎週のように仕様変更の話が出るようであれば、根本的に要件が固まっていなかったと考えるべきです。
サイン4: 担当者が途中で交代する
開発会社側の担当エンジニアやプロジェクトマネージャーが交代すると、それまでの経緯や細かい判断の背景が引き継がれず、実質的にプロジェクトが振り出しに戻ることがあります。担当者交代の連絡があったら、必ず引き継ぎ内容を確認してください。
サイン5: 見せてもらえるものが「資料」ばかりで「動くもの」がない
開発が進んでいるはずの時期になっても、パワーポイントの資料や設計書ばかりが提示され、実際に画面が動く状態のものを見せてもらえない場合、実装そのものが遅れている可能性があります。
サイン6: テスト期間が当初計画より大幅に短縮される
スケジュールの遅れを吸収するために、最後のテスト期間を削って帳尻を合わせようとする動きが出ることがあります。これは非常に危険な兆候です。テストが不十分なまま公開されたシステムは、公開後に不具合が頻発し、結局は追加の手直し費用と時間がかかります。
サイン7: 「検収」の基準が事前に共有されていない
プロジェクトの最終段階で、発注者が成果物を確認して合格を出す工程を検収と呼びます。この検収の合格基準――つまり「何を確認すればOKとするのか」のチェックリスト――が、プロジェクトの終盤になっても共有されていない場合、最後の最後で「思っていたものと違う」という揉め事が起き、さらなる遅延につながります。検収基準は、できればプロジェクトの早い段階、遅くとも開発の中盤までには文書として共有してもらうべきものです。
「定例会議」の設計が遅延防止の要になる
週次か隔週かは規模で決める
遅延を防ぐ上で最も実務的な武器は、定期的な進捗確認の場、いわゆる定例会議です。開発期間が3ヶ月未満の比較的小規模な案件であれば週次、半年を超えるような大規模案件でも最低でも隔週での実施が望ましいでしょう。月1回の定例では、問題が起きてから気づくまでのタイムラグが大きすぎて、挽回のための時間を十分に確保できません。
先代の時代の商習慣では、「進捗はまとめて月末に報告」というスタイルも珍しくなかったかもしれません。しかし、システム開発においては、問題の芽は日々小さく発生し、放置すると急速に大きくなる性質があります。小さいうちに摘み取るためには、頻度の高い確認が不可欠です。
定例会議で必ず確認すべき3つの質問
定例会議の場で、専門用語が分からなくても必ず聞くべき質問を3つに絞るとすれば、次の通りです。
- 「前回の定例から今回までに、完了した作業は何ですか」 — 抽象的な進捗率ではなく、具体的な成果物や完了したタスクを聞きます。
- 「今、何か困っていることや、判断待ちになっていることはありますか」 — 開発会社側が言い出しにくい問題を、発注者側から積極的に引き出す質問です。
- 「次回の定例までに、こちらが確認・判断すべきことは何ですか」 — 発注者側のボトルネックを未然に防ぐための質問です。
この3つを毎回聞くだけで、進捗の実態と、次に自分が何をすべきかが明確になります。逆にこの3つに対して曖昧な回答しか返ってこない場合、プロジェクトのどこかに問題が隠れている可能性が高いと考えてください。
議事録は「誰が」「いつまでに」を明記して残す
定例会議で決まったことは、必ず議事録として残してください。特に重要なのは、「誰が」「いつまでに」何をするのかを明記することです。「検討する」「対応する」といった曖昧な表現で終わらせず、担当者名と期限をセットで記録する習慣をつけることで、後から「言った・言わない」の水掛け論を避けられますし、次の定例で前回の宿題が片付いているかを機械的にチェックできるようになります。
議事録は開発会社に作成してもらう場合が多いですが、発注者側でも簡単なメモを残しておくことを強くおすすめします。開発会社が作成する議事録は、無意識のうちに自社に都合の良い書き方になっていることもあり、発注者側の記録と突き合わせることで認識のズレに早く気づけます。
契約段階で遅延リスクを減らす方法
請負契約と準委任契約の違いを知っておく
システム開発の契約形態には大きく分けて2種類があり、それぞれ遅延時の考え方が異なります。完成品の納品を約束する契約形態を請負契約と呼び、この場合は基本的に「完成させること」自体が契約上の義務になります。一方、稼働した時間や作業内容に対して対価を払う準委任契約もあり、この場合は「完成」そのものは契約上の直接的な義務ではなく、誠実に作業を行うことが義務になります。両者の違いをより体系的に整理したい場合は、請負契約と準委任契約、何がどう違うのかを参照してほしい。
どちらの契約形態を選ぶかによって、遅延が起きたときの法的な位置づけや、発注者・開発会社それぞれの責任の重さが変わってきます。契約書にどちらの形態で書かれているのかを理解しないまま「とりあえずハンコを押した」という状態は避けてください。契約形態がどちらであっても、遅延が起きたときにどちらの責任でどう対応するのかを事前に取り決めておくことが重要です。
要件定義書は「発注者が読んで理解できる言葉」で
開発の初期段階で作られる、システムに必要な機能や条件をまとめた文書を要件定義と呼びます。この文書が専門用語だらけで、発注者である社長や現場担当者が読んでも意味が分からない状態のまま「これで進めます」とサインをしてしまうケースが後を絶ちません。
意味の分からない文書に承認のハンコを押すことは、後々「言った・言わない」のトラブルの温床になります。少なくとも、自社の業務に関わる部分については、開発会社に「専門用語を使わずに、うちの業務の言葉で説明してください」と要求する権利が発注者にはあります。理解できない文書への承認は、実質的に承認になっていないと考えてください。
大きく作って一度に公開するのではなく、小さく試してから広げる
全部の機能を一度に作り切ってから公開しようとすると、当然ながら開発期間は長くなり、途中で方向性がずれていても気づくタイミングがありません。特に承継社長が新しいことに挑戦する場合、まず現場で本当に必要な範囲だけを先に作って動かし、実際に使ってみた上で必要な機能を追加していくという進め方が、結果的にスケジュールの見通しを立てやすくなります。
いきなり大規模なシステムを一括発注すると、要件の見落としに気づいたときの手戻りが大きくなり、遅延も大規模化します。小さく作って試してから広げるという順番は、遅延リスクを下げる実務的な工夫の一つです。飲食チェーンの予約管理システムを例にすると、全店舗・全機能を一度に作り込もうとすると要件確定だけで数ヶ月かかることがありますが、まず1店舗分・予約受付機能だけに絞って先行稼働させれば、実際の利用データを見ながら次の機能の優先順位を判断でき、結果として全体のスケジュールが読みやすくなります。
遅延がもたらす「見えにくいコスト」を数字で把握しておく
納期遅延の話をすると、多くの経営者は「多少遅れても、最終的にできあがればいい」と考えがちです。しかし、遅延には目に見えにくいコストが伴います。たとえば新しい受発注システムの稼働が2ヶ月遅れれば、その間は旧来の非効率な業務フローを2ヶ月分余分に続けることになり、そこに投じられる人件費や機会損失は決して小さくありません。
また、開発会社側の体制にも影響が及びます。当初4ヶ月の契約で確保していたエンジニアの稼働枠が、遅延によって別の新規案件のスケジュールと重なってしまうと、片方の稼働を薄くせざるを得なくなり、遅延がさらなる遅延を呼ぶという悪循環に陥ることもあります。遅延を「多少のこと」と軽視せず、月単位の遅れが自社の経営数値にどう跳ね返るかを、発注段階でざっくりとでも試算しておくことをおすすめします。
具体例で見る「よくある遅延パターン」とその防ぎ方
パターンA: 受発注システムの入れ替えで、既存業務フローの洗い出しが後回しになったケース
ある卸売業の後継社長は、先代が使い続けていたFAXと電話ベースの受発注業務を、Webシステムに切り替えるプロジェクトを開発会社に発注しました。当初のスケジュールは4ヶ月。しかし実際には7ヶ月かかりました。
原因を振り返ると、契約前のヒアリングで「現在の受発注業務がどう流れているか」を細かく洗い出す作業が不十分だったことが分かりました。開発会社は一般的な受発注システムのイメージで見積もりとスケジュールを組んでいましたが、実際には得意先ごとに異なる納品条件や、先代の代から続く特殊な値引きルールなど、口頭でしか伝わっていない業務ルールが山ほどあり、開発が進むたびに「実はこういう例外がある」という話が出てきて、そのたびに設計をやり直すことになりました。
教訓: 業務システムの発注前には、現在の業務フローを紙に書き出す作業を発注者側で行い、それを開発会社と共有することが遅延防止の第一歩です。この作業を開発会社に丸投げすると、表面的な部分しか拾えず、後から例外ルールが次々と発覚します。
パターンB: 経営陣の最終確認が遅れて公開が2ヶ月延びたケース
ある製造業の後継社長は、新しい在庫管理システムの画面デザインについて、開発会社から複数回にわたって確認依頼を受けていましたが、日々の業務に追われて確認を後回しにし続けました。結果として、画面デザインの最終確定が当初予定より1ヶ月半遅れ、その後の実装スケジュール全体が玉突きで遅れ、最終的な公開日は2ヶ月延びました。
教訓: 発注者側の確認作業も、プロジェクトのスケジュールを構成する重要な一工程です。「開発会社の仕事を待っている時間」だと思っていても、実際には自分の確認待ちで止まっていることがよくあります。確認依頼が来たら、いつまでに回答するかを自分自身のスケジュールに組み込んでください。
パターンC: 追加要望を無償の「ついで」だと思っていたケース
ある小売業の後継社長は、開発中に「ついでにこの機能も入れてほしい」という追加要望を何度か出しました。開発会社は都度対応しましたが、その分の工数が当初の見積もりに含まれていなかったため、他の作業を圧迫し、結果的に全体のスケジュールが後ろ倒しになりました。
教訓: 「ちょっとした追加」のつもりでも、開発側にとっては新たな設計・実装・確認作業が発生します。追加要望を出す際は、必ず「これによってスケジュールにどう影響するか」を開発会社に確認する習慣をつけてください。無償でついでにやってもらえるという期待は、多くの場合誤解です。
承継社長のための「納期防衛」チェックリスト
以下は、プロジェクトの各段階で確認すべき項目をまとめたものです。印刷して手元に置き、定例会議のたびに見返すことをおすすめします。
契約前
- [ ] 「作るものリスト」と「作らないものリスト」が両方とも書面で示されているか
- [ ] 自社の業務フローを紙に書き出し、開発会社に共有したか
- [ ] 社内で「最終的に決める人」が誰かを明確にし、関係者に周知したか
- [ ] 希望する納期は「積み上げ」で妥当性が確認されたものか、それとも単なる希望日か
- [ ] 契約形態(完成責任を負う形か、稼働に対して支払う形か)を理解した上でサインしているか
スケジュール確認時
- [ ] スケジュール表は最低5段階以上(要件・設計・実装・テスト・最終確認)に分解されているか
- [ ] 最終納品日以外に、中間のマイルストーンが複数設定されているか
- [ ] スケジュールに1〜2割程度のバッファ(予備日数)が組み込まれているか
- [ ] マイルストーンごとに「何が見える状態になっているべきか」が事前に共有されているか
進行中
- [ ] 進捗報告は「%」だけでなく、具体的に何が完了したかの説明を伴っているか
- [ ] 定期的に、実際に動く画面や機能を見せてもらう機会を設けているか
- [ ] 開発会社からの確認依頼に、自分自身が期限内に回答できているか
- [ ] 追加要望を出す前に、スケジュールへの影響を必ず確認しているか
- [ ] 担当者交代があった場合、引き継ぎ内容を確認しているか
終盤
- [ ] 検収の合格基準(何を確認すればOKとするか)が事前に文書化され、共有されているか
- [ ] テスト期間が当初計画より削られていないか
- [ ] 本番公開前に、実際の業務データに近い形でのテストが行われているか
- [ ] 公開後の不具合対応の窓口と対応時間が明確になっているか
遅延が発生してしまったときの対応
どれだけ注意していても、遅延が完全にゼロになるとは限りません。遅延が発生してしまった場合、承継社長が取るべき対応は次の通りです。
まず原因を数字と事実で特定する
「なんとなく遅れている」という感覚論ではなく、WBSのどの工程が、当初予定から何日遅れているのかを具体的に確認してください。原因が発注者側(確認の遅れ、追加要望など)にあるのか、開発会社側(技術的な問題、人員不足など)にあるのかを、感情的にならずに事実ベースで整理することが第一歩です。
「挽回策」を具体的に確認する
「頑張ります」「気合を入れ直します」という精神論の回答ではなく、「どの工程に人員を追加するのか」「どの機能の優先順位を下げて後回しにするのか」といった、具体的な挽回策を開発会社に求めてください。挽回策が具体性を欠く場合、遅延はさらに拡大する可能性が高いです。
「今の延長線上で本当に間に合うのか」を疑う
一度遅延が発生したプロジェクトは、その後も同じペースで遅延を積み重ねる傾向があります。「あと1ヶ月で終わります」という報告を鵜呑みにせず、これまでの遅延実績から逆算して、現実的な着地点を自分なりに見積もっておくことをおすすめします。
必要であれば範囲を見直す勇気を持つ
どうしても間に合わない場合、無理に全機能を詰め込んで質の低いものを急いで公開するよりも、優先順位の低い機能を次フェーズに回して、まず必要最小限の機能で公開するという判断も選択肢に入れるべきです。全部か無かの発想ではなく、段階的な公開という柔軟性を持つことが、結果的に事業へのダメージを最小限に抑えます。
開発会社を変更・追加する判断はいつすべきか
「見切りをつける」ラインをあらかじめ決めておく
先代からの付き合いがある取引先や、契約時には信頼して選んだ開発会社であっても、あまりに遅延が続く場合には、体制の見直しを検討せざるを得ない局面があります。難しいのは、どのタイミングで見切りをつけるべきかの判断です。
一つの目安として、当初のスケジュールに対して「工期の3割以上の遅延が発生し、かつ具体的な挽回策が2回以上の定例会議で提示されない」場合は、体制の見直しを検討する段階だと考えてください。感覚的に「なんとなく不安だから変える」という判断は、かえって混乱を招きます。逆に、明確な基準を事前に決めておけば、いざというときに冷静な判断ができます。ここまでのような遅延の予兆に加えて、そもそもの見積もりや進捗報告の姿勢に危険なサインがなかったか振り返りたい場合は、危険な開発会社のサイン10選、承継社長が見極めるポイントもあわせて確認してほしい。
体制見直しは「全部やり直し」ではない選択肢もある
体制を見直すといっても、必ずしも契約を解除して別の会社に一から発注し直す必要はありません。次のような段階的な選択肢もあります。
- 開発会社内で担当者やプロジェクトマネージャーを交代してもらう
- 一部の機能だけを別の会社や個人のエンジニアに切り出して並行して進めてもらう
- 残りの範囲を縮小し、まず必要最小限の部分だけを先に完成させてもらう
- 進捗管理の専門家(第三者のプロジェクトマネジメント支援)に途中から入ってもらう
いきなり全部をやり直すという極端な判断の前に、こうした中間的な選択肢があることを知っておくと、いざというときに冷静に検討できます。
契約解除を検討する場合は専門家に相談する
契約を解除する、あるいは損害賠償を求めるといった話に発展する場合は、必ず弁護士など専門家に相談してください。契約形態や、これまでのやり取りの記録(議事録やメールのやり取り)によって、法的に取れる対応は大きく変わります。感情的な対立のまま自己判断で動くと、かえって不利な立場に置かれることもあります。日頃から議事録や確認事項のやり取りを記録として残しておくことが、いざというときの自社の立場を守ることにもつながります。
よくある質問(FAQ)
Q1. 開発会社に「遅れている理由を教えてほしい」と聞くのは失礼にあたりませんか。
失礼にはあたりません。むしろ発注者として当然の権利であり、健全なプロジェクト運営に必要な行為です。誠実な開発会社であれば、遅延の原因と挽回策を具体的に説明してくれるはずです。逆に、理由をはぐらかしたり、精神論でごまかそうとする対応が続く場合は、開発会社との相性やコミュニケーション体制そのものを見直す必要があるかもしれません。定期的な進捗確認は、信頼関係を壊す行為ではなく、信頼関係を築くための行為だと捉えてください。
Q2. スケジュール表を見ても専門用語が多くて理解できません。どうすればいいですか。
まず、開発会社に「専門用語を使わずに説明してほしい」と率直に伝えてください。良い開発会社であれば、発注者の理解度に合わせて説明の仕方を変えてくれます。それでも理解が難しい場合は、少なくとも「今月中に何が完成する予定か」「次に自分が確認・承認すべきことは何か」の2点だけは、毎回のミーティングで必ず確認する習慣をつけてください。全体の技術的な詳細を理解できなくても、この2点さえ押さえていれば、進捗の異常には気づけます。
Q3. 先代の時代からの取引先だから、多少遅れても強く言えません。どうすればいいでしょうか。
長年の関係性を大切にする気持ちは理解できますが、遅延によるビジネス上の損失(売上機会の喪失、他部門への影響、追加コストなど)は、関係性とは別に発生する現実の問題です。感情的に強く言う必要はありませんが、「事実として何日遅れていて、それによって会社にどのような影響が出るか」を淡々と伝えることは、関係性を壊す行為ではなく、むしろ長期的に良い関係を続けるために必要なコミュニケーションです。遠慮して黙っていると、同じパターンの遅延が今後も繰り返される可能性が高くなります。
Q4. 複数の開発会社から見積もりを取る際、スケジュールの妥当性はどう比較すればいいですか。
各社の見積もりの中に含まれるスケジュール表を並べて、工程がどれだけ細かく分解されているか、バッファが組み込まれているか、マイルストーンが複数設定されているかを比較してください。金額の安さだけで選ぶと、スケジュールに無理のある(バッファのない)計画を提示してきた会社を選んでしまうリスクがあります。可能であれば、提案依頼書、つまり自社の要望条件をまとめた文書を各社に配布した上で見積もりを依頼すると、条件を揃えた比較がしやすくなります。金額とスケジュールの妥当性の両方を見て、総合的に判断することをおすすめします。
業種別に見る「遅延しやすいポイント」の違い
事業承継後にシステム開発を発注する業種は多岐にわたりますが、業種によって遅延の起きやすいポイントには一定の傾向があります。自社の業種に近いパターンを知っておくと、事前の備えがしやすくなります。
卸売・小売業:マスタデータの整理不足
商品マスタ、取引先マスタ、価格マスタなど、長年の運用の中で重複や表記ゆれが積み重なったデータを、新システムに移行する際に整理し直す作業は、想像以上に時間がかかります。「システムを作る作業」と「既存データを整理する作業」は別物であり、後者を軽視した見積もりを立てると、データ移行の段階で大幅な遅延が発生しがちです。発注前に、自社のマスタデータがどれくらい荒れているかを開発会社に正直に伝えておくことが重要です。
製造業:現場の例外ルールの多さ
製造業では、生産ラインや工程ごとに、文書化されていない独自の運用ルールが積み重なっていることが多く見られます。図面通りに動かない現場の慣習、特定の熟練社員だけが知っている手順などが、要件定義の段階で漏れやすく、開発が進んでから「実はこの工程だけ特殊な処理が必要だった」という発覚が相次ぎ、遅延の火種になります。現場のベテラン社員を要件定義の打ち合わせに同席させることが、この種の遅延を防ぐ最も効果的な方法の一つです。
建設・工事業:関係者間の承認フローの複雑さ
元請け・下請け・施主など、複数の関係者が絡む業務フローをシステム化する場合、誰がどの段階で何を承認するのかという業務フロー自体が複雑で、要件定義に想定以上の時間がかかる傾向があります。関係者が多い業界ほど、社内合意形成に時間がかかることを見込んで、最初のスケジュールに余裕を持たせておくべきです。
サービス業・店舗運営業:繁忙期をまたぐスケジュールのリスク
飲食業や小売店舗など、季節や曜日によって繁忙期がはっきりしている業種では、繁忙期に現場担当者が確認作業に時間を割けず、そこでスケジュールが止まってしまうケースが頻発します。年末年始やお盆、決算期などの繁忙期をあらかじめ開発会社に伝え、その期間は確認作業のペースが落ちることを織り込んだスケジュールを組んでもらうことをおすすめします。製造業であれば、生産ラインを止めない時期選びそのものが刷新スケジュールの前提になる。詳しくは製造業の刷新は生産ラインを止めない時期選びから始めるを参照してほしい。
承継社長だからこそ持っておきたい視点
先代の時代のシステム発注は、良くも悪くも「お任せ」で成立していた面があります。長年の付き合いによる信頼関係があり、多少のスケジュールのブレも許容される時代背景もありました。しかし、事業環境の変化のスピードが増した今、システムの遅延は競合との差を広げる直接的な要因になり得ます。
承継社長にとって重要なのは、開発の専門知識を身につけることではありません。専門知識は開発会社に任せればよいのです。承継社長が身につけるべきは、「何を確認すればリスクに気づけるか」という、発注者としての勘所です。この記事で紹介したWBSの見方、マイルストーンの考え方、遅延の予兆となる7つのサイン、そして定例会議での3つの質問は、いずれも専門知識がなくても実践できるものばかりです。
先代から受け継いだ会社の看板を守りながら、次の時代に合わせてシステムを更新していく。そのプロセスの中で、納期を守れる発注者になることは、社内外からの信頼を積み重ねる第一歩でもあります。開発会社に「この社長は、きちんと見るべきところを見ている」と思わせることができれば、開発会社側の緊張感も自然と高まり、結果的にプロジェクト全体の質とスピードが上がっていきます。
まとめ:納期は「監視」するものではなく「一緒に作る」もの
開発の遅延について、発注者である承継社長ができることは「早く終わらせてください」とプレッシャーをかけることだけではありません。むしろ、遅延の多くは着手前の要件の詰め方、社内の意思決定体制、スケジュールの組み方という、発注者側にもコントロールできる部分に原因があります。
先代から受け継いだ会社を次の世代につなげていく立場として、システム開発を「専門的でよく分からないから任せておくもの」ではなく、「自社の経営判断の一部として関与するもの」と捉え直すことが、納期を守り、無駄なコストと時間のロスを防ぐ最も確実な方法です。
この記事で紹介したチェックリストとサインの見分け方を手元に置き、次回のプロジェクトでは「あと1ヶ月で終わります」を3回聞くのではなく、最初のスケジュール表を見た時点で、遅延のリスクに気づける発注者になってください。それが、承継社長にしかできない、次の世代への責任の果たし方の一つです。
