ソフトウェア開発の要件定義をやるにあたって、読んでおいた方が良いIPAのドキュメントを紹介します。
IPAとは、Wikipedia 先生によるとこんな団体です。
独立行政法人情報処理推進機構（じょうほうしょりすいしんきこう、英: Information-technology Promotion Agency, Japan、略称：IPA）は、日本におけるIT国家戦略を技術面、人材面から支えるために設立された、経済産業省所管の中期目標管理法人たる独立行政法人である。
情報処理試験をやってる団体というと一番ピンと来るかもしれません。
ソフトウェア開発の標準化とかをやっているため「IPAのドキュメントにこう書いてあります！」って言うと根拠としては割と強めになります。
そのため、良いドキュメントが多いんですが、公式サイトでは新着順に分類されているため検索がしづらいんです。。（こんな感じ）
なので、おすすめをピックアップしてみました。
おすすめドキュメント4選
① 家づくりで理解する要求明確化の勘どころ
家づくりで理解する要求明確化の勘どころ ～システム構築を成功させる要件定義のポイント～
マイホーム購入を例に要件定義のポイントをわかりやすく解説しています。
ソフトウェア開発初心者でもとっつきやすい内容になっています。
概要はこちら（引用）。
- 初期要求（ニーズ）を明確にする
- どのようなシステムを作るかの前にどのような業務にするかを検討する
- 現行業務やシステムを把握し、To-Be の変化を明確にする
- ステークホルダを洗い出す
- ステークホルダ要求を明確にする
- 非機能要求など、その他の要求を明確にする
- 要求を目的展開する ～要求の妥当性を検証～
- 目的から手段を検討する ～要求の充分性を検証～
- 要求の価値／効果を判断し、要求を絞り込む
- 制約・前提条件を明確にする
- 制約条件や前提条件を考慮した現実案を検討する
- 要求の優先順位付けを行う
- To-Be 業務での変化と価値をまとめる
- ステークホルダと合意形成する
- 要件（仕様）として定義する
② デジタル変革に向けたITモダナイゼーション企画のポイント集
デジタル変革に向けたITモダナイゼーション企画のポイント集～注意すべき7つの落とし穴とその対策～
まずモダナイゼーションとは、、
企業の情報システムで稼働しているソフトウェアやハードウェアなどを、稼働中の資産を活かしながら最新の製品や設計で置き換えること。特に、稼働後数十年経っていることも珍しくないメインフレームを中心とする基幹システムを刷新することを意味する場合が多い。
既存システムを置き換えるような開発の要件定義で陥りやすいポイントをわかりやすく説明しています。
7つの落とし穴はこちら（引用）。
- 「再構築だから」と企画・要件定義フェーズを軽視していませんか？
- 「今と同じ」という要件定義になっていませんか？
- 現行システムの調査が「表面的」になっていませんか？
- 業務部門はメンバの一員として上流工程から参加していますか？
- 現行システムが動いているから、品質保証を簡単に考えていませんか？
- 担保すべき「業務継続性」は明確になっていますか？
- モダナイゼーションのリスクを甘く見ていませんか？
③ 非機能要求グレード
非機能要件に記載すべき内容がまとまっています。
非機能要件は、
- 「可用性」
- 「性能・拡張性」
- 「運用・保守性」
- 「移行性」
- 「セキュリティ」
- 「システム環境・エコロジー」
の6つの大項目に分類されますが、「06_活用シート.xls」で詳細な項目が一覧化されているため、チェックリストとして使用するのがおすすめ。
④ 超上流から攻めるIT化の事例集
作成すべきドキュメントのサンプル集になります。
実際にどのようなドキュメントを作成すればよいのかはここを参照すればOK！
もちろん全て作成するのではなく、開発によって作成すべきドキュメントの精査は必要です。
（全部作ったらめっちゃ多くなる。。）
さいごに
もともとある観点やフレームワークを使うことで作業効率や精度が上がるので、こういったものはどんどん取り入れていくべきです。
但し、実際のプロジェクトでは思った通りに行かないことも多いので、そこはエンジニアの腕の見せどころ！笑
ではでは。