「在庫あり」は、誰にとっての事実か

架空事例：機材レンタル会社「青葉機材」の要求調査を扱う。業務上の判断、数値、発言は説明用の設定であり、実在企業の調査結果やIPAの問題文ではない。

全員が同じことを言っている

三つの倉庫に、同じ質問をした。「在庫があるか、どのように確認していますか」。答えは、どこも同じだった。管理システムの在庫画面を見ている。画面の名前も、使っているソフトウェアも一致している。情報システム部門は、業務が共通化されていると考えた。

ところが、営業が受け取った回答は違っていた。第一倉庫の「在庫あり」は、点検を終え、すぐに出せるという意味だった。第二倉庫では、今日中に返却される予定の機材を含んでいた。第三倉庫では、棚にあるものの、翌日の別の予約に割り当てた機材も台数に含まれていた。

同じ言葉を使っていても、同じ事実を答えているとは限らない。

要求調査で集まるのは、まず発言や文書や観測値である。それらが相互に一致するか、同じ定義を使っているかを確かめて初めて、設計の前提にできる。シラバス5-1が要求するのは、関係者の要望を集めることだけではなく、ニーズ、前提条件、制約条件を分類し、業務をモデル化する能力である。「ヒアリング済み」は、その作業を終えたことの証明にはならない。1

質問を揃える価値と、質問からこぼれる情報

事前に質問項目と順序を定める構造化インタビューは、拠点間で回答を比較する目的に適している。例えば「受付後に誰が確認するか」「回答までに何回画面を開くか」を同じ形式で尋ねれば、比較に必要な軸を揃えやすい。既存コンプリートテキスト第3章では、その強みと、想定外の話題を深掘りしにくい制約を対比している。2

問題は、質問項目を揃えたことで、業務の意味まで揃ったとみなすことである。「在庫画面を使う」という回答では、何を読み、何を除外し、何を人が補っているかは分からない。選択肢を「システム」「紙」「電話」に限定すれば、「システムの台数を見た後に電話で点検状態を聞く」という組合せが回答から落ちることもある。

そこで、共通の質問を残しながら、回答に応じて追問する。「直近で貸出しを断った一件を、受付から順に説明してください」。第一倉庫の担当者は、在庫画面だけでなく、点検担当の手元の一覧を見せた。画面上は一台ある。しかし、その機材には不具合があり、修理の判断を待っていた。

この聞き方なら、「通常どうすべきか」という説明と、「実際にその一件で何が起きたか」を分けられる。英国政府のユーザー調査手引きも、インタビューを実例に基づいて進め、中立的な問いと追問を使う方法を示している。ここから借りるのは調査の進め方であり、英国のサービス設計手続を日本の試験要件として扱うわけではない。3

半構造化なら常に優れ、構造化なら劣るという関係ではない。拠点差を同じ尺度で比較したい段階と、初めて現れた問題を探索する段階では、必要な自由度が違う。調査手法は、確認したい未知に合わせて選ぶ。

見ていたはずの操作にも、判断は隠れる

調査担当者は、第二倉庫で一件の受付を観察した。担当者は画面の機材一覧を開き、数量を読み、営業へ回答した。操作は簡潔で、紙も電話も使っていなかった。これなら画面の数値で自動判定できそうに見える。

ただし、担当者は画面に表示された全台数を数えていなかった。

常連の工事会社から戻る予定の一台を、頭の中で除いていたのである。その会社は使用を延長することがあり、その日の返却も確定していない。担当者は過去の経験と、朝に受けた連絡を知っていた。観察したクリックだけでは、この判断は見えない。

行動を観察することと、判断の根拠を理解することも別である。静かに見ていれば通常の作業に近い姿を把握しやすいが、なぜその行を飛ばしたか分からない。逐一説明してもらえば理由は分かりやすいが、説明そのものが作業の流れを変える。このトレードオフは、GOV.UKの観察調査の手引きでも区別されている。4

青葉機材では、まず一件の処理を見届け、その後で機材一覧を使って判断を振り返ることにした。「この一台を含めなかったのは、どの条件によるものですか」。回答を、担当者の気分として処理せず、返却予定の確定度という業務上の情報へ分解する。

もっとも、暗黙の判断を見つけたからといって、すべてをシステム化するとは限らない。返却予定の確定度を客観的に更新できなければ、根拠の薄い数値を表示して営業に過信させることになる。情報を持てない場合には、未確定であることを表示し、確認が必要な依頼として扱う案もある。要求獲得は、熟練者の判断を無条件に自動化する作業ではない。

ログが答えられる問い、答えられない問い

発言が曖昧なのでログを調べる、という方針は有用である。だが、ログにも記録されている範囲がある。

現行システムに残るのは、予約レコードの登録時刻と更新時刻だった。電話を受けた時刻は記録されていない。その二つの時刻の差を「顧客の待ち時間」として集計すると、予約登録前の倉庫確認待ちが丸ごと抜ける。ログの精度が高くても、測っている区間が違えば、問いへの答えにはならない。

また、登録件数が少ない担当者が、仕事をしていないとも限らない。難しい依頼に対応し、結果として貸出しを断った件数は、予約ログには残らないからである。記録された成功例だけから、業務全体を推定するのは危うい。

この事例では、受付記録、予約ログ、担当者の説明を一件の受付番号で突き合わせる。開始と終了の定義が揃っていない過去データについては、その制約を記したうえで参考値にとどめる。不足する記録を、もっともらしい推定値で埋めない。新しい測定を行うなら、収集目的に必要な項目だけを決める。

複数の情報源を使う目的は、三つあれば正しいと多数決することではない。情報源ごとに見える範囲と偏りが異なるため、同じ事象のどこを観測しているかを照合するのである。意見が食い違ったときこそ、業務の前提が見つかる。

利用者一覧にいない人が、要件を持っている

営業と倉庫の意見が揃ったところで、情報システム部門は要求の取りまとめに入った。そこへ、夜間の運用担当者から質問が来た。「予約の連携が止まったら、誰に連絡すればよいのですか」。

運用担当者は予約画面を毎日使う人ではない。しかし、夜間に不整合が発生すれば復旧を担当する。通知先や再処理の判断を要件に含めなければ、営業と倉庫が満足する画面だけ完成し、止まったときに誰も扱えないシステムになる。

利用者は利害関係者の一部であって、すべてではない。シラバス5-1は利用者だけでなく、運用要員の能力や運用特性、組織や社会から課される条件も扱う。1 NASAのハンドブックも、顧客・利用者以外に、保守や教育などライフサイクルを支える関係者を含めて期待を調べる考え方を示している。5

青葉機材では、組織図に丸を付けるのではなく、予約の開始、変更、取消し、障害時の復旧、旧システムの終了を順にたどる。その場面で情報を渡す人、判断する人、結果を受け取る人を確認する。そうすると、日常の利用頻度は低くても、業務を成立させるために必要な関係者が見えてくる。

一人の担当者が複数の役割を担っていてもよい。営業所長が営業担当として予約を登録し、別の場面で例外貸出しを承認することもある。人物名だけで整理すると、この役割の違いが消える。誰であるかに加え、その場面でどの責任を担うかを記録する。

事実、仮定、制約、決定を混ぜない

「返却予定の機材は必ず翌朝使える」という文が、要件メモに書かれていた。担当者の説明を要約したものである。しかし、修理が必要な場合には成立しない。これは確認済みの事実ではなく、検証が必要な仮定だった。

「点検が終わるまで貸し出さない」は、青葉機材が採用している業務ルールである。「点検状態を在庫画面に表示する」は、そのルールに従って判断するための実現案になる。「既存の点検システムを当年度は更新しない」は、今回のプロジェクトで合意した制約である。同じメモに混在していても、扱い方は違う。

記録	未確定のまま進めた場合の危険	必要な確認
担当者が毎朝、点検状態を更新しているという説明	実際には更新できない日や対象がある	更新記録と運用を確かめる
返却予定を貸出し可能数に含められるという仮定	未返却や点検未了でも約束してしまう	成立する条件と例外を調べる
当年度は点検システムを更新しないという制約	不可能な連携変更を計画してしまう	制約の決定者、範囲、有効期間を確認する
標準依頼は営業で判断するという決定	権限移譲の条件が部署ごとに変わる	対象条件、例外、承認者を文書化する

この表は本書の記録例であり、規格が定める分類表ではない。重要なのは、未確認事項が確定要件へ紛れ込まないことである。仮定には確認対象と期限を持たせ、満たされなかったときに影響する要求も分かるようにする。確認が終わらないまま数値や機能を約束すれば、その不確実性は後工程へ移るだけになる。

合意は、全員の希望を足すことではない

営業は、返却予定まで含めて予約を受けたい。倉庫は、点検済みの実機だけを使いたい。二つをそのまま「必須要件」にすると、同じ時点の同じ依頼に対して異なる回答を要求することになる。

対立を解く手掛かりは、希望の背後にある目的である。営業は受注機会を逃したくない。倉庫は貸出し不能の約束を避けたい。そこで、予約の確定と、回答期限付きの確認依頼を別の業務状態にする案を検討する。点検済み機材だけで条件を満たす依頼は確定できる。返却予定に依存する依頼は、顧客へ確約せず確認中として扱う。

この案にも代償がある。確認中の依頼を放置しない仕組みと担当が必要になる。成立しなかったときの連絡も必要だ。対立を消したように見えて、運用側へ負担を押し付けていないかを確認する。

採否を決めるのは、発言の多い人でも、システムを作れる人でもない。事業上の判断権限を持つ関係者が、残るリスクと負担を理解したうえで決める。調査担当者の役割は、その判断に必要な条件と選択肢を明らかにすることである。

「在庫あり」という言葉が一つだったとき、合意は簡単に見えた。言葉を分解すると、違いが増え、決めることも増えた。それは調査が失敗したからではない。今まで人が埋めていた前提が、設計できる形で現れたのである。

知識を答案へ戻す

午前Ⅱの判別軸。 構造化インタビューは比較軸を揃える技法であり、未知の要求を漏れなく発見する保証ではない。現場観察は行動を把握する手段だが、観察だけで判断理由がすべて分かるわけではない。技法の名前ではなく、何を知るために採用するかを対応させる。

午後Ⅰへの接続。 問題文で部署ごとに同じ用語を使っていても、その定義、更新主体、利用時点を確認する。「在庫を一元化する」という一般論より、「点検未了の機材を貸出し可能数から除外して、営業の誤確約を防ぐ」という対象と理由のある記述の方が、本事例の問題に対応している。実際の試験では、その根拠が問題文に存在する範囲で答える。

午後Ⅱへの接続。 「関係者と十分に話し合った」ではなく、どの不一致を何で確かめ、誰とどの条件を合意したかを書く。本事例なら、返却予定の扱いが倉庫ごとに違うことを具体的な受付記録で確認し、確定予約と確認中の依頼を分けた判断が論述の核になる。これは独自の説明例であり、公式の採点基準ではない。

立ち止まって考える：三人が同じ回答なら、要件として確定してよいか

人数だけでは確定できない。同じ手順書を読み上げている場合も、同じ言葉を違う意味で使っている場合もある。何を観測した説明か、成立条件は何か、意思決定権限のある関係者がそのルールを採用するのかを分けて確認する。事実の一致と、将来の業務への合意は別である。

出典と照合範囲

[1] IPA「SAシラバス Ver.5.2」：5-1〜5-3、7-1。利害関係者、業務要件、組織要件とシステム要件の対象範囲を照合した。機材貸出しの判断ルールは本書の架空設定。公式PDF

[2] コンプリートテキスト『午前Ⅱ 技術知識の地図』第3章：構造化・半構造化インタビュー、現場観察の基本説明を出発点にして、発言・行動・記録の食い違いを本章独自の事例で展開した。対応章へのリンクはこの章の末尾にある。

[3] GOV.UK Service Manual, Using in-depth interviews：実例、中立的な質問、追問、調査ガイドの利用という方法上の観点を参照した。青葉機材の質問や発言は本書独自のもの。原文

[4] GOV.UK Service Manual, Contextual research and observation：無言での観察、適宜の質問、逐次説明の違いを参照した。観察した行動と判断理由を分ける事例は本書の作例。原文

[5] NASA Systems Engineering Handbook, 4.1 Stakeholder Expectations Definition：ライフサイクルを支える関係者と期待を含める考え方を参照。NASA固有の役職や承認手続は一般化していない。原文