システム開発の発注側は誰が答える？一つの質問で役割を分ける

一つの質問を、事実・方針・技術条件へ分ける

同じ「営業時間外はどうするか」という質問にも、違う種類の答えが含まれています。現在の仕事を説明する答え、新しく提供するサービスを決める答え、実現方法を確認する答えです。先に種類を分けると、社内の誰へ何を頼むかが具体的になります。

• 事実を確かめる。いまの受付手順、現在案内している問い合わせ先、参照する資料を、仕事を知る人へ聞きます。現状の説明だけで、新しい提供方針が承認されたとは扱いません。
• 方針を判断する。今後受け付ける範囲や、利用者へ何を約束するかを、権限のある人へ相談します。「対応したい」という希望と、実際に提供できる条件をそろえた判断を分けます。
• 技術条件を確かめる。既存台帳とのつながりや、画面で実現する方法をIT担当と開発会社へ確認します。技術的に作れるという回答は、そのサービスを会社が提供すると決めた回答とは別です。

発注側は、システムを使う会社として必要な仕事と判断を整理する側です。開発側は、その条件を理解し、設計・実装の方法や影響を提案する側です。詳しい整理を支援してもらう場合も、何を支援してもらい、どの内容を自社で判断するかを相談します。役職の略語を先に当てはめるより、一つの質問に必要な仕事から役割を決めましょう。

IPAの要件定義の解説も、業務の要求とシステムの要求を整理し、関係者の合意につなげる考え方を示しています。ここでは、その考え方を「質問のどの部分を誰に確かめるか」へ具体化します。

営業時間外の案内を、社内でどう確かめるか

最初に扱うのは、営業時間外の緊急修理依頼です。確認したい問いは「営業時間外に緊急の修理依頼が届いたとき、画面には何を案内し、誰が決めるか」。修理が完了するまでの手順を作る話ではなく、この質問に対する発注側の回答をどう整えるかを見ます。

受付担当には、今の手順を示してもらう

受付担当が示すのは、現在の受付手順と問い合わせ先です。「現在は何を見て案内し、案内できないときは誰へ確認するか」を、その手順や資料に沿って説明してもらいます。この例には、実際の受付時間、連絡先、案内文の原文まではありません。一般的な営業時間や電話番号で埋めず、自社の資料を確かめる仕事として残します。

受付担当から聞くときは、いつの手順か、対象はどの依頼か、説明した人が確認できる範囲はどこまでかを添えます。「今はこう案内している」という説明を、新システムでも必ず同じ文言を使う承認へ読み替えないためです。

IT担当は、接続の疑問と業務の判断を混ぜない

この条件では「既存受付台帳との接続条件は未確認」という状態です。台帳が存在することと、新しい受付画面から必要な情報を読み書きできることは別に確かめます。IT担当は、何の情報をどちらへ渡したいか、既存の管理者へ何を聞く必要があるかを整理し、開発会社に確認を頼む範囲へつなげます。

質問のまとめ役については、発注側IT連絡担当が質問をまとめる想定です。窓口を一つにしても、業務の方針までIT担当が単独で決めるという意味にはなりません。自分で答えられる技術上の条件、他の人へ確認する条件、まだ調査していない点を分けます。

業務責任者へは、提供範囲と案内の判断を求める

業務責任者へ相談するのは、提供する受付範囲と案内文の承認です。ただし、役割候補が書かれたことで、その人の承認権限が確認できたわけではありません。この例では、両条件とも、最終的に承認する人の確認は済んでいません。会社の責任者へ、誰がどこまで決められるかを確かめます。

判断を頼む際は、「画面をどうするか」だけにせず、利用者がその案内を読んで何を期待するか、社内で誰が対応できるか、現在の手順との差は何かを示します。判断者が不在なら、代理として決めてよい人と範囲を確認します。返答を急ぐ事情だけで、連絡役が代わりに承認したことにはしません。

図で確かめる問い：同じ緊急依頼の質問に、受付の事実、接続の条件、提供方針の判断は、どの順でそろう必要があるでしょうか。

原寸画像を開く

図の受け渡しは、相談する順序の案です。受付から説明を得ても、方針の承認や接続の実現性まで確認したことにはなりません。読んだ後は、今の質問で誰の何の回答が足りないかを一つ選び、その確認先へ戻します。

答えられる部分と、保留する部分を一緒に返す

必要な回答が全部そろわなくても、分かる部分と未確認を区別して連絡できます。開発会社へ期待する役割は「決まった条件を受けて技術上の実現方法と影響を提示」することです。条件を確認できていない部分は、完成した仕様として渡すのではなく、調査や提案を頼みたい点として示します。

例えば、次のように質問の対象と残る確認を分けて伝えます。これは返し方の例で、この架空会社が実際に回答・発注した記録ではありません。

対象は、営業時間外に届く緊急修理依頼の画面案内です。現在の受付手順と問い合わせ先は、受付担当が説明する範囲です。営業時間外に提供する範囲と画面文言は、承認された内容をまだ確認できていません。既存受付台帳との接続条件も未確認です。

方針を決めるために必要な技術上の条件と、案によって変わる影響を教えてください。確認できていない案内文や接続条件は、確定した指示として扱わず、確認が必要な部分として分けてください。

この返し方では、受付担当が示す現状、会社として決める方針、開発会社へ尋ねる技術条件を、別の文にしています。各文について、誰の回答を受けたのか、何の資料に基づくのか、承認が必要な部分はどこかを確かめます。窓口から送ったという事実だけで、文中のすべてを確定扱いにしません。

両条件でまだ分からないのは、営業時間外の提供方針、画面文言、既存システムの制約、見積り、契約上の役割分担、実際の結果です。これらは両条件とも未確認です。未確認の欄を、対応しない、無料、担当がいない、作業済みという意味へ置き換えず、次に求める回答と結びます。

既存資料を開発会社へ示す場合は、自社の資料の扱いに従って、示せる範囲を選びます。ここで必要なのは回答条件の共有であり、実際の顧客名や連絡先を載せたデータを、そのまま質問の例として送ることではありません。

食い違った話は、原因に合う相手へ戻す

意見が一致しないときは、誰の役職が上かだけで答えをまとめず、何が違うのかを分けます。現在の事実が食い違う場合と、これからの提供方針に意見がある場合では、確認する相手と必要な答えが変わります。

現在の手順の説明が違うなら、同じ条件へ戻る

受付担当ごとに説明が違う場合は、対象の依頼、参照する手順の版、時間帯や担当範囲が同じかを確かめます。別の条件を話しているのか、資料が更新されていないのか、まだ分からない点を示して現場へ戻します。連絡役が両者の説明を平均した新ルールを作らないようにします。

今後のサービスに意見が分かれるなら、判断者へ渡す

現状が分かっていても、今後どこまで受付対応するかは別の判断です。希望する案内と、それを提供するために必要な人・仕事・確認条件を並べ、権限のある人へ決めてもらいます。受付担当の希望や、開発会社が作れるという説明だけで、提供方針を了承済みにしません。

技術上の制約が分かったなら、影響する方針へ返す

開発会社から接続条件や実現方法の回答が来たら、その前提と調査できた範囲をIT担当が確認します。案内や業務の担当が変わるなら、技術回答をそのまま決定にせず、業務責任者へ選択肢と影響を返します。見積りや日程も、その案と同じ範囲かを確認してから判断に使います。

この段階で止めるのは、答えが足りない部分の確定です。現状資料を集める、質問を整理する、判断に必要な提案を求めるなど、進められる仕事まで一律に止める必要はありません。何を保留し、何を続けるかを窓口から同じ内容で伝えます。

通常の依頼でも、回答する役割を確かめる

もう一つの条件は、通常の修理依頼です。問いは「通常の依頼に対する案内文と受付先を誰が確認するか」。営業時間外の例を直した後の成功例ではなく、別の仕事条件として比べます。

受付担当が示す範囲は、現在の通常受付の手順です。IT担当については「既存台帳の参照先は未確認」という前提を残します。業務責任者へ相談するのは、通常受付案内の掲載条件です。普段の依頼だからといって、現在の手順を画面へ載せる判断まで自動的に済むわけではありません。

開発会社の役割の案は「確認済みの条件で画面案を提示」することです。質問をまとめる役は、こちらも発注側IT連絡担当が質問をまとめる想定です。受付・IT・判断者・開発会社の人数を固定するものではなく、同じ人が兼ねる場合も、どの内容をどの立場で確認したかを分けて残します。

二条件で共通するのは、質問をまとめる役を想定しても、最終承認者や方針、技術条件が確認済みになるわけではないことです。一方、受付へ聞く手順、参照する台帳の条件、判断してほしい案内の範囲は、対象の仕事に合わせて変わります。共通の役割名だけを写さず、今の質問で必要な回答を確かめましょう。

業務の説明を聞き取る準備が必要な場合は、利用者ヒアリングで一件の仕事をたどる方法へ戻れます。聞き取りの内容と、会社として提供する方針の判断は、別の記録としてつなげます。

質問が変わったら、影響する回答だけ見直す

開発会社の質問や社内の回答が変わったら、誰が最初に受けたかだけで振り分けず、どの文の前提が変わったかを見ます。以前に確認できた事実まで、理由なく全部聞き直す必要はありません。変わった部分が、ほかの回答に影響するかを確かめます。

• 現在の受付手順が変わった場合：受付担当へ対象と変更点を確かめ、案内の前提に使っていた文を見直します。新しい手順があることと、新しい画面案内の承認は分けます。
• 接続の前提が変わった場合：IT担当と開発会社へ、対象の台帳や調査条件を確かめます。案内の仕方や人の仕事に影響するなら、その部分を業務責任者へ戻します。
• 提供する範囲を変える場合：権限のある人へ、案内文と必要な運用を合わせて判断してもらいます。その決定を使う画面案、技術提案、外部へ返す説明を同じ内容へそろえます。

回答には、対象の質問、参照した資料の版、事実を確認した人、判断した人、まだ残る条件を結びます。以前の回答を消して経緯を見失うより、何が変わり、どの回答に置き換わったかを分かるようにします。承認者が未確認の段階では、承認日や承認済みの印を先に入れません。

依頼から提案比較まで全体の順番を整えたい場合は、開発の発注準備の進め方で確認できます。この一問の整理だけで、依頼資料全体や契約、発注手続きが完了したことにはなりません。

同じ質問を読み返し、担当と未確認を確かめる

連絡役が回答をまとめたら、受付担当、IT担当、判断する人が、同じ質問と回答を読み返します。確認するのは肩書が埋まったかではなく、誰が何を説明・判断でき、どの部分を開発会社へ渡せるかです。

1. 受付の事実を説明できるか。対象の依頼と手順、参照資料が分かり、将来の希望と混ざっていないかを確かめます。
2. 判断する範囲が分かるか。提供する範囲、案内文、必要な運用のうち、誰の判断が必要で、まだ何が決まっていないかを確かめます。
3. 技術上の問いが具体的か。未確認の接続条件と、開発会社へ求める調査・提案が分かるかを確かめます。
4. 確定と保留を読み分けられるか。開発会社が、回答のどの部分を前提にでき、どの部分は決定待ちなのかを説明できるか確かめます。

読み合わせで違いが出たら、該当する文と、その確認を担当する人へ戻します。回答を送れたことは、相手の理解や開発・修理対応の完了を確認した結果ではありません。作る条件がそろった後の納品と確かめ方は、発注前に検収条件をそろえる方法で別に整理します。

まとめ：窓口を決め、判断まで一人へ押し付けない

発注側の役割を決める出発点は、一つの業務質問を分けることです。受付担当は現在の手順を示し、IT担当は技術条件と未確認を整理し、権限のある人が提供方針を判断する。連絡役は、それぞれの答えと保留を一つの説明へまとめます。

この架空例では、営業時間外と通常の修理依頼を別の条件として扱いました。担当候補を置いても、方針や画面文言、接続条件、見積り、契約上の役割、実際の結果は未確認です。確認できた範囲を越えて答えず、変わった質問の部分だけを必要な相手へ戻します。