導入

ユーザーのための要件定義ガイド

情報技術者試験を主催するIPAが公開している要件定義についての資料。

「ユーザーのための」とあるようにシステム開発を依頼する側に必要な視点だが、ユーザーはそもそもそういう考えに至らない可能性も高いので開発者側も知っておく方が良い。

図など込みで7章に分けて500ぺージ近い資料があるので1章ずつすごく雑に要約していく。

本題

はじめに

ITシステムを作る上で経営層が上流工程に関わることが大事。

ざっくり2分野

・基幹業務に関わる
「守りの分野」…レガシー化して面倒

・AIなど新技術
「攻めの分野」…開発中に新しい要求が増えやすいパターンに陥る

レガシー化したシステムを再構築

DXを進めるうえで既存のシステムが足かせになりうる

本書は、『システム再構築を成功に導くユーザガイド』と合わせて以下2点に強く関連する内容
「デジタル時代に対応した新たなビジネスモデルの構築」
「DX 実現を困難にしている既存 IT システムの再構築」

1章　背景

システム開発の現状

ITシステムの変遷は下のような流れ
導入 → 置き換え → 効率化 → 競争力強化

今は「競争力強化ステージ」

「デジタル時代に対応した新たなビジネス・モデルの構築と価値の創造」
「DX 実現を困難にしている既存 IT システムの再構築」
をする必要がある

既存システムの現状

8割強の企業が老朽化したシステムを抱えていると言われている。
既存システムの中身はブラックボックスになりがち。

運用保守に資金と人材が割かれる

開発の実態

納期遅延・品質満足度が低い
2018年度、500人月以上の大規模システム開発で
43.9% が「予定より遅延した」
23.8% は経営者がシステム品質に不満を持っている

工期遅延の理由

アンケート結果：50%以上が要件定義の問題。

IPA「要件定義は発注者の責任である」
経済産業省「要件定義は準委任契約にすることと述べられて
いる。」

請負契約と準委任契約の違いとは

ユーザーはベンダに丸投げしないでね、ということ

今あるシステム理解して再構築が大変
局所的に入れた連携の取れていないもの(個別サイロ型システム)まで統合しようとすると大変

・構造的な問題
日本は予算が低めで外部のSEに委託
アメリカは予算をしっかり割いて社内にもSEがいる

DXに見える今後求められるシステム開発

インターネットの発展でサービスの対象者が大幅に増える
データ量も膨大になる(ビッグデータ)

「デジタル時代に対応した新たなビジネスモデルの構築」は特に重要
機能の差別化はすぐ陳腐化するからUI,UXが大事
ビジネス価値の創出のために、どのようなデータをどのように活用するか
単に集めただけだと意味がない("沼")

リーンスタートアップ、アジャイル開発

要件定義が変化する可能性もあるので、開発の仕方も大事

☆要件定義は普遍
ここまでをまとめたものは既存の要件定義で重要なものと同一

・お客様が本当に欲しい価値は何なのか
・お客様のエクスペリエンスとは何なのか
・ビジネスにどういう価値を作るのか
・ビジネス・モデルを変えるために、データをどのように活用すれば良いのか
・デジタル技術を用いて、どのように価値創出に貢献できるのか

☆ブラックボックス化した既存システムの刷新が大変
自社の情報資産を正確に把握できていないことが一因。
評価するための項目は以下

・既存システムの調査・分析
・情報資産の仕分（機能分割・刷新、機能追加、機能縮小・廃棄、現状維持（塩漬け）な
ど）
・再構築目的やビジネスリスクの明確化
・再構築手法の選択、再構築リスクの明確化
・現行業務知識不足への対応
・品質保証（業務継続性の担

要件定義をめぐる環境の変化

要件定義に求められる 3 つのこと

【請負】瑕疵担保責任の改正
【請負】プロジェクトがとん挫した場合でも報酬請求が可能に
【準委任】成果完成型の準委任契約が認められた

「瑕疵」＝プログラムのバグ
「契約の内容に適合しない仕事の目的物」に変わった
やりたい事できてるならいいよね？ということ

バグがあってもいいではなく「目的」の部分をはっきりさせておきましょう

いざ要件定義を終えてみると当初の狙いが達成できていない要件定義になっていることがある。
経営層や業務部門との合意形成や積極的な経営層、業務部門の参画などが要件定義には求められる。

要求仕様の決定や漏れが一番多い。
手戻り負荷は、発覚が遅ければ遅いほど指数的に大きくなると言われている。

パラダイムシフト

昨今は、クラウドやマイクロサービスなどの普及により、システム構築はサービスを組み
合わせて作るものになってきている。

重要度が上がる非機能要求

デザインとかセキュリティとか
機能による差別化が難しくなってきたことが理由

IPA は「非機能要求グレード」を公開している

ますます難しくなってきている要件定義

1章の総括
再構築って大変
現状の可視化と理解、変える/変えないの判断を工夫しよう

その機能本当に必要？
分からないことがあるからアジャイル開発とかを前提に見極めるための仕組みを考えよう

アイデア創出
ビジネスモデルの話、UXなどの非機能要求

かなり雑にまとめると
「ベンダーにお任せじゃなくてユーザーも考えましょう」