MENU

問い合わせ


    社内の確認が遅れて開発を止めてしまう…回答待ちを減らす6つの工夫と、決裁者を巻き込む進め方

    システム開発の途中で、開発会社から「確認をお願いします」と届いたメールを、社内の確認待ちのまま何日も寝かせてしまう。気づけば「あのメール、まだ返していなかった」と青くなる。窓口担当者の方から、よく聞く悩みです。

    「社内の確認に時間がかかり、開発会社への回答が遅れて開発を止めてしまっている気がする」

    先に結論をお伝えします。回答が遅れる原因の多くは、担当者の頑張り不足ではなく、「誰が決めるか」と「いつまでに決めるか」が事前に決まっていないことです。この2つを最初に決め、確認の依頼を「選ぶだけ」の形に整えれば、回答待ちはかなり減らせます。

    この記事では、窓口担当者が一人で抱え込まずに、決裁者や現場を巻き込みながら回答を早くする6つの工夫を、そのまま使えるチェックリストと開発会社への質問例とあわせて解説します。

    目次

    社内の回答が遅れると、なぜ開発が止まるのか

    まず、回答の遅れが開発にどう響くのかを押さえておきましょう。理由が分かると、社内の関係者にも「急いでほしい理由」を説明しやすくなります。

    開発会社の作業は「確認待ち」で順番が詰まる

    開発会社は、発注者の回答をもとに次の作業へ進みます。画面の仕様が決まらなければ、その画面に関わる作業は止まります。止まっている間、担当のエンジニアは別の案件に移ることが多く、回答が来た時点ですぐ元の作業に戻れるとは限りません。

    つまり、回答の遅れは「その日数分だけ後ろにずれる」だけでなく、再開までの段取りのやり直しという見えにくいコストを生みやすいのです。

    遅れが続くと、納期や費用の話に発展しやすい

    回答待ちが重なると、開発会社から「このままだと納期に間に合いません」と相談されることがあります。契約や体制によっては、待機した期間の作業費や、スケジュール再調整の費用が話題になる場合もあります。個別の契約上の扱いは、契約書の内容や専門家への確認が必要です。

    発注者側の責務は、公的な資料でも整理されている

    システム開発では、開発会社だけでなく発注者側にも担う役割があります。IPAは、ユーザ企業とITベンダが各開発段階で担うべき責務を整理し、契約書のひな型とあわせて公開しています。

    📰 出典:IPA(情報処理推進機構)「情報システム・モデル取引・契約書」

    このページでは、情報システム開発におけるユーザ企業とITベンダの取引構造を透明化するため、それぞれが各開発段階で担うべき責務を解説していると説明されています。「確認・判断・資料の提供」は、発注者が担う代表的な役割です。

    ただし、回答が遅れるのは担当者の怠慢とは限りません。窓口の方に判断の権限がなく、決裁者にたどり着くまでに時間がかかる、という構造の問題であることがほとんどです。

    回答待ちを減らす6つの工夫

    工夫1:最初に「決める人」と「代理で決められる範囲」を書き出す

    プロジェクトの開始時に、次の3点を1枚にまとめておきます。

    決めておくこと例
    最終的に決める人事業部長、社長など
    窓口担当者が即答してよい範囲文言の修正、色や並び順など軽微なもの
    必ず決裁者の承認が要るもの機能の追加・削除、金額や納期が変わるもの

    「どこまでなら自分の判断で答えてよいか」が決まっているだけで、窓口担当者が決裁者に確認に走る回数が大きく減ります。

    工夫2:回答期限を、依頼を受けた時点で開発会社と合意する

    「確認をお願いします」というメールには、期限が書かれていないことがあります。依頼が来たら、次のように返信していつまでに回答するかを先に約束します。

    • 「◯日(◯曜)までに回答します。決裁者の確認が必要な内容なので、少しお時間をください」

    回答が間に合いそうにないときは、期限の前日までに「◯日になりそうです」と途中経過を連絡しましょう。遅れること自体より、連絡がないまま止まることのほうが、開発会社は困ります。

    工夫3:確認依頼を「選ぶだけ」の形に整えて決裁者へ回す

    開発会社からの質問をそのまま決裁者に転送すると、読み解くところから始まってしまい、返事が遅れます。窓口担当者が、次の形に整えてから回すのがおすすめです。

    • 何を決めてほしいか(1行)
    • 選択肢(A案・B案、できれば2〜3個まで)
    • 開発会社のおすすめと、その理由
    • 選んだ場合の費用・納期への影響
    • 回答がほしい日

    決裁者は「A案でいい」と返すだけで済みます。分からない点は、開発会社に「決裁者向けに、選択肢と影響を1枚で説明してもらえますか」と頼むのも有効です。

    工夫4:決裁者に定例会へ出てもらう、または確認の枠を作る

    毎回個別に確認を取るのではなく、決裁者が参加できる短い時間をあらかじめ確保する方法があります。

    • 定例会の最後の15分だけ、決裁者が参加して決定事項を確認する
    • 週1回、決裁者が確認依頼をまとめて見る時間(30分程度)を設ける
    • 決裁者が出張・休暇のときの代理者を決めておく

    決裁者が忙しい場合は、「決めていただきたいことは今週◯件、いずれも選ぶだけです」と件数と手間を先に伝えると、時間を取ってもらいやすくなります。

    工夫5:現場の確認が要るものは、早めに「宿題」として出しておく

    実際に使う現場の担当者に確認が必要な内容(帳票の項目、業務の例外ケースなど)は、決裁者より時間がかかることがあります。開発会社に「今後の確認予定」を共有してもらい、現場に聞くものは数日前から声をかけておくと、回答待ちが短くなります。

    工夫6:回答待ちの一覧を作り、見える化する

    「いま誰の回答待ちか」を一覧にしておくと、遅れの原因が個人の問題ではなく仕組みの問題として見えるようになります。

    確認事項依頼日回答期限回答者状態
    ログイン画面の文言10/110/4窓口担当回答済み
    請求書の項目追加10/210/8事業部長待ち

    開発会社と同じ一覧を共有すると、お互いに「何が止まっているか」を同じ目で見られます。

    やりがちな失敗

    • 窓口担当者がひとりで判断を抱え込む:判断できないものを持ち続けるほど、遅れが長引きます。早めに決裁者へ回しましょう
    • 決裁者に「全部見てください」と丸ごと転送する:選択肢が整理されていないと、決裁者も判断に時間がかかります
    • 「急ぎではない」と思って期限を確認しない:開発会社にとっては、その回答が次の作業の入り口になっていることがあります
    • 遅れていることを開発会社に言い出せない:連絡があれば、開発会社は先に進められる作業を前倒しするなど、調整できる場合があります

    発注者がやることチェックリスト

    • ☐ プロジェクトの最終決裁者と、窓口担当者が即答してよい範囲を決めた
    • ☐ 決裁者が不在のときの代理者を決めた
    • ☐ 確認依頼が来たら、回答期限を開発会社と約束するルールにした
    • ☐ 決裁者向けに「何を決めるか・選択肢・影響・期限」の型を作った
    • ☐ 決裁者が参加する確認の時間(定例会の一部など)を確保した
    • ☐ 現場に確認するものを、数日前から知らせるようにした
    • ☐ 回答待ちの一覧を作り、開発会社と共有した
    • ☐ 遅れそうなときは、期限の前日までに途中経過を連絡することにした

    開発会社への質問例

    そのまま打ち合わせで使える一文です。

    • 「今後、こちらの確認が必要になりそうな項目を、時期と一緒に一覧にしていただけますか?」
    • 「決裁者に判断してもらいたい内容は、選択肢と費用・納期への影響を1枚にまとめていただけますか?」
    • 「回答が◯日遅れると、スケジュールや費用にどんな影響が出ますか?」
    • 「こちらの回答待ちで止まっている作業と、先に進められる作業を教えてください」
    • 「確認の依頼は、メールではなく共有の一覧(チケットなど)にまとめてもらうことはできますか?」

    まとめ

    社内の確認が遅れて開発が止まる原因は、多くの場合、担当者の努力ではなく「誰が決めるか」「いつまでに決めるか」が決まっていないことです。

    • 最初に決裁者と、窓口が即答してよい範囲を決める
    • 依頼を受けたら、回答期限を約束する
    • 決裁者には「選ぶだけ」の形で回す
    • 回答待ちの一覧を作って共有する

    この4つだけでも、回答待ちの日数は変わります。「止めてしまっているかも」と感じたら、まず今日、回答待ちの一覧を作るところから始めてみてください。進め方に迷ったときは、開発会社に「確認が必要な項目の予定を出してほしい」と相談するのも一つの方法です。

    あわせて読みたい関連記事

    システム制作・運用・保守のお問い合わせはこちら


      よかったらシェアしてね!
      • URLをコピーしました!
      • URLをコピーしました!

      この記事を書いた人

      株式会社THIRD HERO代表取締役 朝野貴朗
      Webシステム開発を中心に、toC向けサービスサイトの運営、ツール開発などを行ってまいりました。

      目次