システム開発プロジェクトにおける不確実性の高い要求への対応について
AI生成の参考答案（架空）
問題・答案ともに独自教材です。実際のIPA過去問・公式解答ではありません。年度・季節は教材の整理用ラベルです。論述構成を学ぶために過去問AIが生成した架空の参考例で、合格を保証するものではありません。論述の骨格・業種事例の参考としてご活用ください。
問題概要
近年のシステム開発プロジェクトでは、ビジネス環境の急速な変化や、生成AIを始めとする新技術の急速な進展により、プロジェクト開始時点では要求仕様の全貌を確定できないケースが増えている。
全文を表示
業種を選択してください
製造業の参考答案例
約 1,879 字序論（設問ア）
私が担当したのは、自動車部品メーカA社のMES刷新とAI予知保全を組み合わせたスマート工場化である。私はSIerのPMとして、期間16か月、当初予算8.4億円、ピーク38名のプロジェクトを統括した。 不確実な要求は二つあった。第一は設備異常の定義である。プレス機や加工機の正常・異常の境界を熟練工が経験で判断しており、設備ごとに学習データ量も異なった。全体の約30％は十分な履歴がなく、同じ検知精度を約束できなかった。第二は並行するEV部品ライン新設への対応だった。設備仕様の確定予定が本稼働の3か月前で、接続対象や収集項目が追加される可能性があった。 前者は技術検証と現場の判断基準、後者はA社の設備投資判断に起因する。私は固定済みのMES機能と探索が必要な部分を分け、未確定事項の責任者、決定期限、計画への影響を管理する方針を立てた。
本論（設問イ）
私は最初に要求を確定度で分けた。MESの標準機能は受入条件を定めて計画を固定し、AIの異常定義とEVライン接続は段階的に確定する対象とした。要求一覧に決定責任者、必要な証拠、決定期限、未決時の代替策を記入し、単に未定という状態が続かないようにした。 AI部分は、モデルを作れば完成という契約にせず、検証期間と作業量の上限を定めた探索工程を設けた。A社の生産技術、品質保証、熟練工3名と週次で検証する。誤検知と見逃しを分け、設備種別ごとに評価する理由は、一部の大量データで全体の良い数字を作っても現場で使えないからである。波形を表示する試作で判断根拠を共有し、現場の説明と食い違う事例はラベルを再確認した。AIの判定だけで設備を自動停止する範囲は初期対象から外した。 私は追加データ整理、検証、現場合意の作業を見積もり、全体工数の12％を対応余力として当初計画に含めた。使用時は理由と残量を記録し、余力があるから変更を無承認で受け入れるとはしなかった。基準済みの範囲内の調整はPM権限、機能や契約額の変更はA社責任者の承認と区別した。月次で残作業見積りと残余力を比較し、超過が見込まれれば対象設備の段階導入を提案することにした。 EVラインは経営企画、生産管理、設備担当との月次会議で仕様確定日を確認した。機能単位の追加注文で金額と納期を合意し、確定済みMESへの変更波及を評価してから着手する。契約形態を分けても結合試験の責任が空白にならないよう、共通の試験計画と受入責任者を定めた。 進捗は確定済み作業の工程表に加え、設備追加が少ない場合、予定どおりの場合、多い場合の完成見込みを示した。毎月どの前提が変わったかを報告し、単に悲観的な日付を示すのでなく、設備仕様の確定期限と判断が遅れた場合の影響を説明した。モデル検証と設備仕様確定を別の管理対象としたことで、技術者の努力だけでは解決できない経営判断の遅れを早く議題にできた。 追加の課題は、保全作業で設備の条件が変わり、評価済みモデルの前提が失われることである。私は設備変更の連絡先と再評価の責任者を計画に追加し、未評価の条件では人手の点検を続けるよう現場と合意した。
結論（設問ウ）
実行中、AIのF1スコアは検証対象設備で0.78となり、目標0.75を超えた。私は平均値だけで受入れず、設備別の見逃しと誤通知、評価データの期間を確認した。現場レビューで判断が割れた事例を蓄積したことが、追加作業の優先順位付けに役立った。ただし新設設備まで同じ精度を保証したという評価はしなかった。 EVラインの追加は、当初想定した対応規模より約25％増えた。私は余力の使用分と範囲追加の費用を分け、追加注文を承認してもらった。最終費用は当初8.4億円より5.8％、約4,872万円増え、納期遅延はなかった。これは当初予算内の達成ではなく、追加範囲と増額を合意して納期を維持した結果である。残余力と完成見込みを並べた報告は、承認判断に有効だった。 改善点は説明可能性の受入条件だった。早期の試作には波形表示があったが、運転中にどのセンサの変化を点検すべきかまで案内する機能は定義していなかった。そのため本稼働後に追加要望となった。判断根拠を全く考慮しなかったのではなく、開発者向けの確認画面と保全担当者向けの実作業支援の差を見落としたのである。 今後は検知から保全作業の判断までを現場と試し、精度、説明、対応時間を別の受入条件にする。また余力を一律の割合で置くだけでなく、未確定設備数やデータ不足量から見積りを更新する。変更を受け入れた件数だけで成功とせず、誰がどの条件で承認し、残るリスクを引き受けたかまで記録する。
試験制度・公式過去問の確認: IPA 情報処理技術者試験
建設業の参考答案例
約 1,887 字序論（設問ア）
私が担当したのは、全国120以上の現場を持つゼネコンC社の建設DX基盤構築である。私はSIerのPMとして、期間15か月、当初予算7.6億円、ピーク32名でBIM／CIMと施工データ、労務集計の統合を進めた。 不確実な要求の第一は施工機械との接続だった。現場ごとに機種やファームウェアが異なり、APIの利用条件と出力形式も確認が必要で、必要なアダプタを開始時に確定できなかった。第二は労務集計である。本社、現場、下請企業で打刻や休憩の記録方法が異なり、集計ルールとデータ提供責任の合意に時間を要すると見込んだ。 機器側の不確実性は製品と調達計画、労務側は各雇用主の管理責任と現場運用の違いに由来する。私は法的要件を現場所長の裁量で変更するのではなく、人事部が確認する共通要件と現場ごとの記録方法を分けて合意する必要があると判断した。
本論（設問イ）
私は機器対応と労務要件合意を別の管理線にした。確定済みのBIM／CIM連携は成果物と受入条件を定め、機器接続は実機確認を終えてから仕様を固める。労務は人事部、現場代表、下請企業の窓口を明確にし、記録の作成・訂正・承認を誰が行うかを要求一覧へ追加した。 機器については未確定の最大20機種を想定し、1機種当たり20人日の調査・接続・試験を見込んで400人日の余力を確保した。これは単価の仮置きであり、複雑な機種も常に20人日で終わるとは約束しない。実機調査の結果を次の見積りに反映し、残機種の対応見込みを毎月更新する。予備工数を当初予算に含めた部分と、範囲拡大に伴う追加費用を分けて報告した。 優先機種は機種数だけで選ばず、稼働台数と対象現場数、データ利用価値、接続実績で比較した。土木、建築、調達部の隔週会議で決め、APIが未公開の機種は当面の手動入力を代替策にする。対応カバレッジは対象現場の稼働台数に対する対応済み機械の割合と定義し、機種数と混同しないようにした。これにより少数でも利用台数の多い機種へ先に投資できる。 契約は中核機能の確定範囲と、機器ごとの探索作業を分けた。探索作業は期間・工数上限を設け、継続可否をレビューする。アダプタを追加するときは接続試験と運用費を含めて承認し、契約を柔軟にしただけで納期や品質が保証されるとは考えなかった。結合試験と総合受入れは私が一つの工程表で管理した。 労務集計では本社人事部と現場代表、労働組合の会議を設け、移動・待機・休憩を含む代表日の記録から必要項目を洗い出した。適法性の判断は人事部が確認し、画面設定で基準を緩めない。所長は記録方法の差を説明し、訂正履歴を残す運用に合意する。下請企業の従業員についても元請が雇用主に代わって一律に承認する形は避けた。 私は機器仕様の確定と現場合意の期限を経営会議へ報告した。遅れが出た際は担当者を増やすだけでなく、対応機種の段階化や先行現場の絞込みを選択肢として示した。 残るリスクは、接続可能な機種数を増やしても重要な施工現場が対象外になることである。私は稼働台数と現場の重要度を分けて対応表に記録し、未対応現場への暫定手順を受入判定時に確認した。
結論（設問ウ）
機器対応は14機種となり、対象現場の稼働台数ベースのカバレッジは87％に達した。当初の10機種、同75％という目標を上回ったが、14を10で割った値をカバレッジとはしていない。私は未対応の13％を残課題として示し、利用頻度と接続難易度で次期対応を決めた。労務集計は半年で52現場へ展開し、目標40現場を超えた。 一方、追加機種と現場説明会の増加で、最終費用は当初7.6億円を7.2％、約5,472万円超過した。私は当初予算内の余力を使った作業と、追加承認を得た範囲を分けて管理した。納期は維持できたが、当初予算を守ったとは評価しない。追加説明会を含めて収まったのは増額承認後の予算であり、基準を変えたことを経営報告に明記した。 有効だった点は、技術進捗と労務要件の合意を別に可視化したことである。機器開発が進んでも現場が利用できない状況を早く検知し、展開順を変えられた。集計工数の削減も、システムだけでなく記録・承認手順の統一と合わせて評価した。 改善点は下請企業の利用環境の調査不足だった。端末の保有状況、回線、説明の受け手が現場ごとに異なり、導入支援が想定を超えた。今後は要件定義時に下請を含む利用者一覧と環境調査を行い、貸与端末や代替入力の費用を計画に含める。説明会の開催回数だけで定着を測らず、初回入力、訂正、承認まで実施できた割合を確認する。未確定事項には判断期限と代替策を付け、単なる進捗遅れとして扱わない。
試験制度・公式過去問の確認: IPA 情報処理技術者試験
金融業の参考答案例
約 1,866 字序論（設問ア）
私が担当したのは、地方銀行E行の法人融資業務刷新である。私はSIerのPMとして期間18か月、当初予算9.2億円、ピーク45名で、紙の稟議をワークフローとAI分析支援へ移す計画を統括した。 第一の不確実性は、AIの結果を支店長や審査役にどの粒度で示せば判断に使えるかである。モデルの統計的性能と、担当者が根拠を理解して責任を持って判断できることは同じではなく、実際の案件による検証が必要だった。第二は、E行が並行して進める融資審査方針の改訂である。事業性評価で必要となる非財務情報と承認経路の最終決定が中盤になる予定で、システムへの影響が未確定だった。 私は前者を技術と現場受容性、後者を行内方針決定に由来するものとして管理した。特定の実在する金融庁ガイドラインの改訂を本事例の前提にはせず、行内の決定責任者と期限を明確にした。
本論（設問イ）
私はワークフローの確定機能と、AI表示・審査方針の未確定部分を分けた。前者は成果物と受入条件を定め、後者は期限付きの検証工程を設ける。AIモデルの検証期間を4か月、表示の見直しを最大120人日として計画し、審査方針の変更には業務設計280人日、システム改修150人日を上限見積りとして置いた。数字は無条件に消費できる予算ではなく、前提と対象範囲を付けて承認した。 私は予備費の使用権限を三段階にした。既に承認した要求内の表示調整はPMが記録して執行する。承認経路や機能の追加は変更審査会へ上げ、範囲、追加額、納期を合意する。予備費や権限上限を超える場合は経営判断を得る。これにより小さな調整のたびに調達をやり直す負担を減らしながら、余力があれば変更承認不要という運用を避けた。 AIの提示方法は審査部、営業統括、支店長代表3名と隔週でレビューした。初期案は説明が多すぎたため、主要因子の要約と詳細参照を分けた。私は同じ案件を、説明が多い画面と少ない画面で確認してもらい、判断時間、重要なリスクの見落とし、根拠の理解を比較した。AIの数値を正解として示さず、最終判断者と判断理由を記録する機能も受入対象にした。統計指標だけで画面を完成扱いにしないためである。 行内方針の改訂は審査企画とコンプライアンス部門との月次会議で追跡した。改訂案ごとに必要項目、保存する根拠、承認者への影響を整理する。未決の段階では変更しやすい設定部分と、確定後に作る部分を分けた。改訂が遅れた場合は旧方針での先行稼働が認められるか、責任者が判断する期限を置いた。規制に関わる適否はPMが推測して決めず、担当部門の確認事項とした。 契約でも確定基盤と探索作業の範囲を分け、探索には期間と工数上限を設けた。変更合意書には総合試験と教育への影響も含める。私は月次報告に基準計画、残予備費、改訂決定状況、完成見込みを並べ、納期を守るために何を保留するかまで選択肢として示した。 追加の課題は、審査方針の変更後も旧方針の画面や手順が残ることである。私は貸出審査の業務責任者に有効日を決めてもらい、変更後の稟議を使った受入試験を完了条件とした。
結論（設問ウ）
AIの検証ではAUC0.82となり、稟議の平均リードタイムは14営業日から6営業日へ短縮した。私は画面変更の前後で判断時間と重要項目の見落としを確認し、モデルの数値だけを成功根拠とはしなかった。要約と詳細表示を分ける反復レビューは、審査部と営業部の対立を具体的な検証へ変える上で有効だった。 審査方針の改訂は想定範囲に収まり、準備した設計余力で対応した。一方、別の受入改善を含む追加範囲で費用は当初9.2億円から4.6％、4,232万円増えた。私は予備費内で吸収した改訂対応と、正式に増額承認した作業を分けて報告した。納期遅延はなかったが、当初予算内とは表現しなかった。変更の権限と手続を先に決めたことで、費用の混同を防げた。 改善点は支店長の判断主体性だった。操作試験では説明を理解できても、実運用ではスコアに引きずられるとの声があった。判断理由を記録する機能だけでは、独立した検討を促す効果が十分でなかった。私は案件の重要な事実を先に確認し、その後でAIの示唆と比較する教育を追加した。AIと異なる判断も不適切と決めつけない評価方針を責任者と確認した。 今後は受入試験へ、誤った予測や学習範囲外の案件を含め、担当者が限界を認識して判断できるかを加える。また方針決定の遅れを早く検知するため、決定期限だけでなく未合意の論点を報告する。変更を吸収できる工数と、変更してよい権限を区別し、担当者の理解まで含めて計画する。
試験制度・公式過去問の確認: IPA 情報処理技術者試験
流通・小売の参考答案例
約 1,878 字序論（設問ア）
私が担当したのは、食品スーパーG社のPOS／EC統合基盤刷新である。G社は240店舗を持ち、私はSIerのPMとして期間14か月、当初予算6.8億円、ピーク28名で計画を統括した。 第一の不確実性は新しい店舗受取業務である。EC部門は店舗在庫を広く開放したい一方、店舗部門は店頭欠品、鮮度管理、ピッキング負荷を懸念し、在庫引当範囲に合意できていなかった。第二は負荷想定である。EC需要が増え続け、ピーク要求数の見込みが四半期ごとに上方修正されていた。 前者は部門ごとに異なる業務目標と店舗条件、後者は新サービスへの需要予測の難しさが原因だった。私は確定済みの顧客・商品情報連携と、試行しながら決める店舗受取を分け、運用案の検証と負荷想定の更新を計画に組み込む方針とした。
本論（設問イ）
私は店舗受取の運用設計に最大180人日、インフラ拡張に最大2,400万円の余力を計画した。算定の前提を運用案の見直し回数と負荷上限で示し、使用条件、承認者、残量の報告方法を契約別紙に定めた。余力を超える変更は追加承認を得る。需要に応じてクラウドを増やせても費用が無制限に許されるわけではないため、予算と処理能力の双方に判断基準を設けた。 店舗受取では、全在庫を開放する案、EC専用在庫を確保する案、両者を組み合わせる案を検証した。店舗運営、EC、物流、情報システムの週次会議に現場代表を加え、欠品率、ピッキング時間、廃棄、受取待ち時間を共通指標にした。規模や立地の異なる3店舗へ別々の方式を置くだけでは店舗差と方式差が混ざる。そこで各店舗で対象商品と期間をそろえ、方式を入れ替えて試し、販促や人員差も記録した。単純な売上の大小だけで採用案を決めないためである。 私は試行結果を業務側と振り返り、専用在庫に加えて一部の店頭在庫を開放する案を選んだ。生鮮品の状態確認と欠品時の顧客連絡を担当者の手順へ組み込み、システムで判断できない条件を明示した。確定した部分から開発し、毎回の試行で変わる画面は短いサイクルで改善する。準委任契約を使う部分にも、レビュー日、成果物、受入責任を置いた。 負荷対応はアクセス数だけでなく注文確定数、在庫引当、決済の処理量を測った。月次会議で最新ログと販促計画を確認し、増設の準備期限と費用を更新する。自動増設の立上がり時間やサービスの上限も試験し、基盤だけ増やして在庫管理や決済先が詰まる事態を防いだ。上限に達する場合は受付制限や販促調整を含む判断をG社責任者へ上げる。 中核のPOS／EC連携は確定要件を固定し、店舗受取の変動が決済や顧客識別へ波及する変更は別途審査する。私は業務案の合意状況と負荷見込みを工程表へ並べ、開発完了だけでなく現場運用の準備が整ったかを展開条件にした。追加要望の優先順位は顧客価値と現場負荷の両面で決め、納期直前の無条件な取り込みを避けた。 例外的な返品と店舗受取の重複は売上整合性のリスクだった。私は商品、店舗、注文状態の組合せを試験一覧へ加え、通常販売の成功だけでPOSとECの統合を受け入れないと業務側へ説明した。
結論（設問ウ）
試行の結果、店舗受取はハイブリッド型へ合意でき、本稼働後3か月の月間注文は想定7,500件に対して10,500件となった。比率は1.4倍である。私は店舗条件を記録して方式を入れ替えた結果を確認し、売上増だけでなく欠品とピッキング負荷が許容範囲かを評価した。部門の主張を実測へ置き換える方法は有効だった。 ピーク要求数は毎秒500件から1,100件へ2.2倍になった。負荷試験と段階増設で対応し、設定した判定時間内で注文を処理できた。最終費用は当初6.8億円より8.4％、約5,712万円増え、納期遅延はなかった。私は当初余力の消費と追加範囲の承認額を分け、需要増を受け入れた代わりに費用が増えたことを明示した。 改善点はピッキング画面の決定が遅れたことである。棚番の見やすさと複数注文のまとめ取りに追加要望があり、約2週間、800万円の作業が発生した。この800万円は前述の総増額に含まれ、別に加算する費用ではない。店長中心のレビューでは、実際に作業するパート職員の操作と兼務の負担を十分に拾えていなかった。 今後は店舗規模に加え、専任・兼任、勤務時間帯を考慮して試行者を選ぶ。操作を説明して意見を聞くだけでなく、繁忙時に棚から引渡しまで実行してもらう。工数余力も画面改修と現場教育を分けて管理し、どちらが不足しているかを可視化する。クラウドの伸縮性だけに頼らず、業務側の処理能力と承認済み予算を含めて受入れ可能な需要を判断する。
試験制度・公式過去問の確認: IPA 情報処理技術者試験
通信業の参考答案例
約 1,877 字序論（設問ア）
私が担当したのは、通信事業者I社の5G SAコアとOSSの刷新である。私はSIerのPMとして、期間20か月、当初予算13億円、ピーク52名で進めた。 不確実な要求の第一は法人向けスライスの適用範囲である。製造、医療、自治体向けサービスの事業計画が並行検討され、必要数、品質条件、課金方法が中盤まで流動的だった。第二は新しい標準機能の採用範囲である。標準化された機能でも、選定機器の実装時期と接続試験の完了時期が確定していなかった。 前者は事業判断、後者は製品実装と実機検証に由来する。私は規格の公開を機器の完成と同一視せず、実装確認済みの機能で提供する初期範囲と、検証後に追加する範囲を分ける方針を立てた。契約済みの品質条件を、機能が間に合わないことを理由に一方的に下げることは認めなかった。
本論（設問イ）
私は要求ごとに事業上の必要時期、利用する機器機能、実装状況、検証結果を整理した。機器ベンダのロードマップは確約と見なさず、提供版と試験環境の入手日を確認する。標準仕様の確定、製品への実装、混在構成での検証を別のマイルストーンにした。これにより仕様名だけで完了率が上がる報告を避けた。 初期計画にはスライス追加8件分、1件30人日の計240人日を対応余力として含めた。対象は設定と試験の標準的な追加であり、特殊な品質要求や新機器導入は別見積りとした。私は使用理由、実工数、残数を月次で報告し、追加範囲が余力を超える前に事業責任者へ段階化か増額かの判断を求める。予備費は費用の出所であって、変更承認の代わりではない。 開発計画は、実装確認済み機能による先行提供と、未検証機能の後続追加に分けた。初期提供で満たす品質と対象顧客を明記し、未確定機能を売り約束しないよう営業と共有する。新機能が遅れた場合も顧客との約束を維持できる代替構成を検証し、無理なら提供時期を正式に調整する。二つの案を並行して無制限に作るのでなく、切替判断期限と後続案の調査工数上限を置いた。 契約では中核機能と探索的な追加機能を分けた。後者は月次の成果確認と工数精算の条件を設け、未実装で待機する期間まで成果が出た扱いにしない。複数ベンダの結合試験と障害時の切分けは、私が共通計画と責任分界表にまとめた。各契約が完了しても全体が動かない事態を防ぐためである。 隔週の事業・ネットワーク合同会議で、スライス追加の収益見込み、実現性、期限を比較して優先順位を決めた。技術WGは機能を未着手、実装済み、単体検証済み、総合検証済みに分け、判断の証拠を添付した。私は運用担当も試験に参加させ、品質測定、通知、復旧、課金連携を初期の受入条件にした。 経営報告には基準日程とともに、未決機能を採用した場合の追加費用と完成見込みを示した。先行提供の納期を守るために延期した機能も明示し、全要求を当初どおり実現したようには報告しなかった。 通信設備への設定反映が遅れることも課題だった。私は開通受付からネットワーク側の反映完了までを追跡する試験を追加し、契約上の開始日と実際の提供状態がずれた場合の担当者を定めた。
結論（設問ウ）
先行提供では製造業、医療機関、自治体向けに各2件、計6件のスライスを商用化した。私は合意した測定区間と負荷条件で受入試験を確認し、未検証の新機能まで品質を保証したとは評価しなかった。実装済み機能で先行し、残りを後続計画へ移す構成は、製品実装の遅れを全体停止にしない上で有効だった。 最終費用は当初13億円から9.2％、1億1,960万円増えた。当初計画内の240人日を使っただけで予算が増えたのではなく、標準的な追加範囲を超える機能と試験が増額対象となり、変更承認を得た。納期遅延がなかったのは合意済みの先行提供範囲についてであり、後続機能の延期と費用増を併記して報告した。 改善点は運用監視の粒度だった。受入試験で確認した契約品質は満たしたが、運用中の短時間の劣化を調査するには、既存監視の集計間隔が粗かった。品質が適切に測定できていなかったのにSLAを満たしたとするのではなく、受入測定と継続的な障害分析の違いを説明した。運用担当は参加していたが、日々の切分け作業まで試していなかった。 今後はサービス運用の一日を想定し、短時間の劣化、通知過多、複数顧客への波及を含む訓練を行う。運用基盤の改修も新機能の採用判断に含め、実装済みという一項目だけで導入を決めない。また機器ベンダの予定変更を月次報告まで待たず共有する条件を契約で定め、事業側が顧客への説明を準備できる期間を確保する。変更の通知先と判断者も一覧で維持する。
試験制度・公式過去問の確認: IPA 情報処理技術者試験
公共・自治体の参考答案例
約 1,937 字序論（設問ア）
私が担当したのは、人口約60万人のK市における住民記録、税務、福祉等20業務のシステム標準化対応である。私はSIerのPMとして、期間22か月、当初予算11億円、ピーク48名で計画を統括した。市が定めた移行目標に向けて、基幹業務と独自業務を整理する必要があった。 第一の不確実性は標準仕様の改訂内容と時期であり、改修と再試験の範囲を開始時に確定できなかった。第二は独自の給付や支援業務の扱いである。標準機能で対応するか、別の仕組みに残すか、制度を見直すかで所管課の合意ができていなかった。 前者は外部仕様の更新、後者は市の政策判断と住民サービス継続責任に由来する。私は技術チームだけで制度の継続・廃止を決めず、所管課と決定権者の判断を工程へ組み込む方針とした。2025年度末を法律本文が定める一律の法定期限とは説明せず、本事例では市の計画上の目標を管理基準とした。
本論（設問イ）
私は標準仕様対応と独自業務移行を分けて管理した。標準業務でも仕様が変わり得るため、採用版、差分、影響する機能、試験を一覧にする。確定済みの部分だけを基準計画にし、改訂情報の確認責任と対応判断の期限をK市と合意した。 工数は過去案件を参考に、内部見積り上の小改訂45人日、中改訂120人日、大改訂300人日と区分した。これは公式資料が定める単価ではない。小6回と中2回を想定し、6×45＋2×120＝510人日の改訂対応枠を置いた。大改訂はこの枠に入れていないため、発生時は追加判断が必要と明示した。実際の影響分析で見積りを更新し、回数が少なくても工数が少ないとは限らないことを説明した。 独自業務は対象を洗い出し、標準機能で対応、別機能で継続、制度見直しを検討するものに分類した。所管課と情報政策課の会議で開発・運用費、住民影響、仕様適合性を比較する。私はシステム費用だけで廃止を推薦せず、対象住民と代替手続、必要な議会等の手続を所管課に確認してもらった。最終判断は副市長を議長とする会議で行う。 契約では確定済み標準機能の受入条件と、追加変更の見積り・承認手順を分けた。改訂対応はあらかじめ工数算定の考え方を合意しておくが、単価が決まれば自動発注できるとはしない。対象範囲、総合試験、移行、教育への影響を確認して追加注文する。独自機能も標準業務の必須部分を勝手に改変せず、接続仕様に適合する別機能として検証した。 私は月次の合同会議で新旧仕様の差分と残工数を報告した。工程表には開発の進捗だけでなく、所管課の制度判断、住民周知、データ移行判定を並べた。判断が遅れた場合は暫定継続に必要な費用と、先行できる範囲を示し、技術者の追加投入だけで解決しようとしなかった。 受入れは画面が動くことだけでなく、移行した件数と金額、権限、年度切替を確認した。制度の変更日とシステムの切替日を整合させ、旧制度の未処理案件を誰が引き継ぐかも決める。これらを独立した完了条件とした理由は、システムが完成しても住民への給付や課税を止めてはならないからである。 住民の申請を移行中に二重処理するリスクにも対応した。私は自治体の窓口担当者と旧新システムの受付境界を決め、申請番号による突合結果と審査中案件の引継ぎ確認を移行判定の証拠とした。
結論（設問ウ）
期間中に内部区分で小改訂5回、中改訂1回が生じ、実工数は480人日だった。510人日の枠内に収まったが、単価で計算した5×45＋120＝345人日より多い。私は差の135人日が連携と回帰試験に必要だったことを確認し、回数だけで残余力を推計する方法を改善した。差分ごとの影響分析を続けたことが、早期判断に有効だった。 独自業務は7業務を標準で対応、3業務を別機能で継続、1業務を制度見直しとする合意を得た。最終費用は当初11億円より6.8％、7,480万円増えた。標準仕様改訂は枠内であっても、独自業務の追加等を含むプロジェクト全体は増額しており、両者を分けて報告した。システム移行は市の目標日までに完了したが、これを一律の法定期限達成とは表現しなかった。 改善点は見直した給付制度の周知だった。住民が代替サービスを理解する期間を不足して見積もり、周知を3か月延ばす必要があった。私はシステム移行と制度終了を分け、承認された期間は旧業務を継続できる暫定運用を用意した。技術的な完了だけで住民対応まで完了したとは判定しなかった。 今後は所管課と広報担当を要件定義から参加させ、案内作成、議会等の説明、問合せ対応、未処理案件の解消を工程化する。改訂枠も一律単価だけでなく、連携数と試験範囲を加えて見積もる。制度判断と技術判断の責任を分けた上で、その依存関係を一つの計画に示すことが、同種案件で再利用すべき工夫だと評価した。
試験制度・公式過去問の確認: IPA 情報処理技術者試験
医療・ヘルスケアの参考答案例
約 1,912 字序論（設問ア）
私が担当したのは、450床、職員約1,600名のM病院の電子カルテ移行である。保守ベンダの撤退を受け、2023年4月から24か月、当初予算18億円、ピーク45名で刷新する計画を私がPMとして統括した。 不確実な要求は三つあった。第一は医師の記録負担を減らす音声入力や問診支援で、現場観察を通じて必要な機能が明らかになる。病院は平均月82時間の時間外労働を45時間以下にする院内目標を持っていたが、どの機能が有効かは未確定だった。第二は診療報酬改定に伴う院内の対応方針で、算定要件を確認してから機能と運用を決める必要があった。第三は外部の医療情報共有サービスとの接続仕様と利用開始時期だった。 私は既存カルテの置換を必須の基準範囲とし、業務改善、制度対応、外部接続を別の未確定事項として管理した。院内の45時間目標を医師全員に適用する法的上限とは扱わず、労務上の適否は労務部門が別途確認する前提とした。
本論（設問イ）
私は必須の電子カルテ置換と未確定部分を分け、各要求に決定責任者、確定期限、受入条件を付けた。既存機能は移行データ、患者照合、処方、会計の受入試験を計画し、頻繁に要件が変わる業務支援は短い試行を繰り返す。ただし開発サイクルが短くても診療環境へ毎回投入せず、試行と本番承認を分離した。 予算18億円の18％である3.24億円を未確定部分への対応枠とした。内訳は制度対応8％の1.44億円、業務改善7％の1.26億円、外部接続3％の0.54億円で、合計が一致することを計画書で確認した。枠は支出義務ではなく上限であり、病院長、事務局長、診療部長、看護部長、私の委員会で効果と要件確度を確認して執行する。緊急判断が四半期会議まで止まらないよう臨時承認の条件も定めた。 制度対応は医事課が正式な要件と適用日を確認し、機能と運用の対応表を作る。告示や資料の公開日と、実際に算定できる日を混同しない。外部接続は仕様版と試験環境の提供日を追跡し、間に合わなければ本体移行と切り離す判断期限を置いた。仕様待ちの作業に人員を固定せず、確定した試験や移行へ振り向ける計画とした。 業務改善は医師、看護師、事務が実際の記録手順を試し、入力時間と修正負担を測る。音声やAIの結果は未確認として表示し、医師の確認前に確定しない。試行は診療判断に影響しない環境から始め、安全管理委員会の承認後に限定導入する。誤記録が見つかった場合の訂正、切戻し、未処理患者の引継ぎまで試験する理由は、画面が動くだけでは安全な運用を確認できないからである。 私はベンダ要員の経験不足にも対応し、経験者と未経験者を組ませてレビューと振り返りを行った。ただし研修受講者数を習熟の証拠とせず、試験計画と変更影響評価を自力で作れるか確認した。処方など安全性の高い機能は、変動頻度だけで開発方式を決めず、医療者と影響度を審査する。月次で残作業、残予算、未決仕様を並べて報告し、病院の判断が必要な事項を明確にした。 診療情報の移行漏れは運用開始後に発見しにくい課題だった。私は患者単位の件数だけでなく、処方や検査の関連付けを確認する試験を設け、診療担当者が不一致の扱いを判断してから切替えを承認した。
結論（設問ウ）
必須範囲の電子カルテ移行は2025年3月末に完了した。私は稼働日だけでなく、データ照合、処方・会計の確認、障害時の代替手順を満たしたことを受入記録で確認した。業務支援の導入後、医師の月間時間外労働は平均82時間から46時間へ約44％減ったが、院内目標45時間以下には1時間届かなかった。改善は認めつつ目標未達として追加対策を報告した。 対応枠3.24億円のうち、制度対応1.44億円と業務改善1.26億円を執行し、外部接続0.54億円は仕様待ちのため未執行となった。執行額は2.70億円、執行率は約83％である。私は未使用額を成果物完成の証拠とせず、外部接続が今回未完了であることと、次期の予算・契約を改めて承認する必要を明記した。18億円の3％を3,400万円とするような計算の混同も避けた。 有効だったのは、必須移行と外部依存を分けたことだった。外部仕様の待ちがカルテ全体の延期へ波及せず、医療者との限定試行で誤転記や操作負担を早期に発見できた。一方、診療報酬の収益効果は算定対象と期間の確認が必要で、接続機能を作っただけで増収が確定したとは評価しなかった。 今後は外部依存の提供予定と代替手段を計画初期から確認し、延期判断を早める。業務改善も平均値だけでなく診療科別の追加確認時間を測る。開発方式は要求変動、安全影響、業務責任の三面から合同レビューで決め、単なる点数計算で医療者の判断を省略しない。
試験制度・公式過去問の確認: IPA 情報処理技術者試験
IT・情報サービス業の参考答案例
約 1,882 字序論（設問ア）
私が担当したのは、コンタクトセンタ向けSaaSを提供するN社の生成AI支援機能開発である。約450社が利用する既存基盤へ応答提案、通話要約、FAQ作成支援を追加し、期間16か月、当初予算7.5億円、ピーク28名で私がPMを担った。 不確実性は三つあった。第一はモデルの性能、速度、価格が短期間で変わることである。第二は顧客ごとの要求差で、99％以上の正確性を求める顧客、個人情報の外部送信を認めない顧客など、単一の提供方式では合意できなかった。第三はAI利用に関わる規制や契約条件の確認であり、適用範囲を用途と地域ごとに判断する必要があった。 私は既存SaaSの安定運用を維持しながら、顧客が承認した範囲だけに段階導入する方針とした。技術選定を遅らせるだけでは品質も納期も決まらないため、比較の指標と最終判断期限を計画へ置いた。
本論（設問イ）
私は技術、顧客要求、法務確認を別の管理表にし、四半期ごとに計画を更新した。モデルを切り替えやすい接続層は先に作るが、実装と試験の時間を残して選定を終える期限を定めた。モデル名の新しさではなく、同じ実際の問合せで正確性、応答時間、トークン数、拒否すべき入力への挙動を比較する。検証データは開発時に調整したデータと分け、結果を業務担当者が確認した。 顧客は先行検証に参加する層、標準版を待つ層、既存運用を継続する層に分けた。ただし層別化を品質要求の一方的な引下げには使わない。99％を求めた顧客には、対象業務、誤りの定義、有人確認、未達時の扱いを説明し、変更合意が得られなければ新機能を提供しない。標準版は合意した評価問題で98％以上とする顧客に限定した。人が回答を確認して送信する支援機能とし、AIの文を自動で顧客へ返さない。 外部送信禁止の顧客は許可された専用環境のモデルだけを利用し、複雑な質問でも外部APIへ転送しない。処理不能なら有人対応へ戻す。外部APIを許可する顧客も、契約した情報範囲と保存条件を接続層で制御する。法務は利用地域と用途別に適用事項を確認し、複数規制に共通する項目だけで全義務を満たしたとは判定しない。確認未了の顧客への提供を止めるゲートを設けた。 推論費が見積りの2.3倍になったため、私は実ログから質問長、検索文書量、応答長、再試行を分けて再見積りした。定型回答には確認済みFAQを優先し、モデル呼出しは必要な範囲に絞る。キャッシュはテナント、権限、文書版をキーに含め、別顧客の回答を再利用しない。類似していても契約条件や個人情報が違う質問を同じ回答へ寄せない試験を行った。 私はコスト改善と品質試験を同じ変更審査で扱い、安価なモデルへ替えるだけでリリースしないようにした。参照元表示も根拠の所在を示す機能であり、回答の正しさや因果的な説明を保証するものではない。先行顧客の誤回答を分類し、根拠不足時の回答保留と担当者への引継ぎを改善した。 テナントごとに異なるAPI利用方法が残ることも課題だった。私は主要な利用経路の互換性試験を受入条件に加え、未対応の顧客には移行期限と代替手順を合意してからリリース対象へ含めた。
結論（設問ウ）
標準版は合意した検証集合で正確性98.4％、応答時間1.2秒、顧客平均の推論費月3.2万円となり、対象顧客と合意した98％、1.5秒以下、4万円以下を満たした。99％を要求する顧客へ達成済みとして提供せず、追加検証か要求変更の正式合意まで対象外とした。私は評価集合と利用範囲を結果報告に添え、全ての実会話で98.4％正しいという保証にはしなかった。 先行40社ではNPSが24から47へ上がり、月次解約率は1.4％から0.8％へ低下した。ただし営業施策なども同時に動いており、全てをAI機能の効果と断定しなかった。外部送信禁止の顧客では外部APIへ要求が出ないこと、権限変更後に古いキャッシュが返らないことを確認した。法令への適合も技術側だけで結論を出さず、用途別の法務レビューを完了条件にした。 改善点は費用見積りだった。利用件数だけでなく入力長、検索文書数、再試行による変動が大きく、平均係数では見込めなかった。今後は利用場面別の実ログから分布を作り、通常時と上振れ時を計算する。予算超過時の呼出し制限や有人対応も顧客と合意する。 また新モデルの登場に合わせて全てを更新すると、再試験の負担が増す。今後は明確な品質改善か費用効果がある変更だけを候補とし、同じ検証集合で比較して承認する。モデルの更新可能性を持たせることと、無条件に最新化することを区別し、顧客要求、情報の扱い、品質、費用を一緒に審査する。
試験制度・公式過去問の確認: IPA 情報処理技術者試験