だまし絵を描かないための要件定義のセオリー
読んだ目的
日々の業務の中で以下のようなことが知りたくなり、読み始めました。
- 要件定義の目的
- 進め方
- ポイント
- 今のプロジェクトでの進め方の改善点
本書をおすすめする人
以下のような人が読むと、要件定義とはどんな工程を経てどんな成果物を出すのか掴めて、自分が今のプロジェクトでどう振る舞うべきかがわかると思います。
- 今のプロジェクトで要件定義の工程を見てはいるものの、積極的に意見が出せていない
- 要件定義の工程において上司やPMが何をやっているかがいまいちよくわかっていない
感想
章ごとの内容, 印象に残った箇所の要約と感想です。
序章 なぜいま「要件定義」なのか?
主な内容
- 要件定義とはどんな工程であり、何をするべきではないのか？
- 本書において要件定義で目指すもの
印象に残った箇所
要件定義の成果物はユーザが理解できてかつ詳細設計に使えるもの
上流工程とは、システムのプロと業務のプロの間で相互翻訳を行い、システムの構想を練り上げること
「要件は詳細設計に用いるもの」という認識しか無かったので、要件定義は顧客と開発者の両方の視点で行うべきだと考えが変わりました。
要求は本当に欲しい物、要件は本当にいるもの
顧客の要求はなるべく多くを実現すべきだと考えていたので、要求が膨らみすぎないように、本当に必要で情報システムで実現すべきもののみを要件として整理すべきだと考えが変わりました。
第1章 情報システムにおける要件定義
主な内容
- 要件定義の目的とポイント
- 以下の開発手法、システムのタイプに応じて要件定義がどう変わるか
- ウォーターフォールとアジャイル
- エンタープライズ系とコンシューマ向け
印象に残った箇所
要求のトレーサビリティ
「要求→要件→設計→実装の流れを後から終えるようにトレーサビリティを確保しておく」という考え方です。
今のプロジェクトでの経験1からかなり必要性を感じたため、これは肝に銘じておきたいと思います！
ウォーターフォールにおいても、手戻り無しに仕様を確定することは不可能
仕様は遡って修正できるレベルでとどめておく
アジャイルにおいては仕様を反復してブラッシュアップすることもあると知っていましたが、ウォーターフォールにおいてもその必要があることは衝撃的でした。
要件定義を行う際は、ある程度の手戻りを許容して、仕様を固めすぎないことを意識して行いたいと思います。
第2章 要件定義の基本方針
主な内容
- 最近の要件定義におけるポイント
- データマネジメントの重要性
- UXと要件定義の関わり
- アジャイルと要件定義の関わり
印象に残った箇所
システムの価値はそれが生み出すデータの価値
システムの価値の指標として、読み込み速度や応答速度などの性能をつい意識してしまいます。
しかし、最もそのシステムの価値に寄与するのは扱うデータの価値だという当たり前の事実から目をそらさずに、要件定義段階からデータマネジメントを考慮することが需要だと思いました。
また、データマネジメントの知識体系である DMBOK についても学んでみたいと思いました。
UXはシステムの利用前後のユーザ体験を含んでおり、UIを包括した概念。
UX はシステムを利用している瞬間のものだと思っていました。
ユーザがシステムを利用するきっかけや利用後に生活がどう変化するか？まで要件定義段階で考えてなければいけないことがわかりました。
第3章 要件定義の前にやっておくべきこと
主な内容
- 現状分析の方法（AsIsモデルの作成）
- 要求定義の方法（ToBeモデルの作成）
- 要求のブレイクダウン
印象に残った箇所
現状分析ではコード体系が最重要で一番時間をかけるべき
コード体系には取引先などのビジネスロジックが隠れている
現状分析においては、システム構成などが最も重要なのかと思っていました。
要求の明確化においては、ビジネス→業務→システムと段階に分けて要求をブレイクダウンする。
その際に、システム要求までブレイクダウンできないものはシステムで解決すべきではない課題として、業務またはビジネス要件にスライドする。
要求が全て要件になるわけではないことはわかっていましたが、具体的にどのようなものがそれに当たるのか理解していませんでした。
第4章 要件定義でやるべきこと
主な内容
- 以下の要件定義の成果物の作成方法とポイント
- 新しいToBeモデル
- システム全体図
- 業務フロー図、業務プロセス図
- UIプロトタイプ、画面遷移図
- 概念データモデルと論理データモデル
- CRUDマトリクス
印象に残った箇所
業務要求としての「現行通り」はビジネス要求との整合性が取れない可能性があるので危険
業務部門と経営層の思惑が異なり、経営層は現行どおりが良くないと思っている場合もあるので、思考停止して現行どおりにするのではなくプロセスや機能の見直しが必要
「現行通り」は仕様をそのまま流用すれば良いので考える必要がなくて安心だと思っていましたが、甘かったです
要求を要件化した後は、要件の詳細を詰めずに要件化された事項の大枠・範囲を掴む。
システム全体図という、現時点での制約と機能を入れ込んだ、大枠を見通すための図を作成する
要件化した後は記憶が新しいうちに詳細を詰めるべきだと思っていました。
業務フロー図はトップダウンで作成した骨組み。要件は現場の要求を元にボトムアップで作成する
システム開発の基本原則：「トップダウンで骨組み、ボトムアップで肉付け」
要件定義は全ての工程を全体の構成を見ながらすべてトップダウンで行うものだと思っていました。
UX から業務フロー、プロセスも明確になる
具体的には、システム使用前後のUXに対してそれを埋めるように業務フロー、プロセスを考えられる
コンシューマ向けの場合はプロモーションも業務フローの一つ
UXは業務フローを考えた後で補足的に考えるものだと思っていましたが、実現したいUXから逆算するものなんですね…！
業務フローの明確化のためには、主体性を持って動くことが必要
具体的にはフローの分岐点や抜け漏れの有無がわかるまで食い下がる
曖昧な返事をされたら回答を持っている人を挙げてもらう
個人的にこういった部分が苦手分野なので頑張って改善していきたいです
業務プロセスを整理すると、以下のようなものがある
- 同じようなプロセス
- 統合したものの、異なる部分が顕著になったプロセス
これらは分割・統合して整理するべきだが、熟考すべき。
なぜなら経営層や開発者からみると分割・統合すべきでも現場のユーザには必要であり、それが組織の強みになる場合があるから
無駄なプロセスはできるだけ排除すべきなのかなと考えていましたが、それが組織およびシステムの強みになるとは思っていませんでした…！
データモデルはER図に加えて以下の2つの書類が必要
- 用語集：一般的な用語の辞書
- データ項目辞書：エンティティの項目の辞書
今のプロジェクトでも用語の使い方の曖昧さが問題になったりしたので、要件定義の段階からしっかり決めておいて、開発者や顧客の間で共通認識をもっておかなくてはと思いました。
第5章 非機能要件の定義
主な内容
- 非機能要件を決める方法
- 信頼性（障害耐性など）
- 使いやすさ（ユーザビリティ）
- 性能（読み込み速度など）
- 保守性（コードのよみやすさなど）
- その他（移行要件など）
印象に残った箇所
非機能要件の決定においては、機能よりもBCPやセキュリティなどの「企業が社会的責任を全うするための要件」を最優先で決める
システムの社会的責任についてはあまり考える機会がありませんでしたが、システムが会社業務を効率化するものだと考えると当然だなと感じました。
システム開発の分野は成熟してきており、機能要件での差別化は見込めない。
よって、ユーザビリティやセキュリティを始めとする、非機能要件が他社のサービスとの差別化につながる
直感には反していますが、エンタープライズ系においては特にそうなのかなと感じました。
今のプロジェクトもエンタープライズ系なのですが。やはり既存システムと被る機能が多いです。
非機能要件も状況に応じて5W2Hで表されるので、プロセスモデル（業務フロー図）をユーザに見せながら決めると良い
非機能要件で何を決めればよいのかわかっていませんでしたが、プロセスモデルと同様の方法でできるとは意外でした。
UX の観点からすると、UIには「同一性」ではなく「一貫性」が必要
同じような機能は同じようなUIになっており同じように操作できる
UIを考える際に、つい「他の画面と同じようなスタイルを当てれば統一感が出る」と考えがちでした。
これだけでは不十分なので、非機能要件の段階でUI設計をブラッシュアップすべきだとわかりました。
第6章 アーキテクチャの整備
主な内容
- 要件定義における２種類のアーキテクチャの決定方法
- システムアーキテクチャ（システム構成、インフラ関連のこと）
- アプリケーションアーキテクチャ（開発言語、コーディング規約など）
印象に残った箇所
アーキテクチャをどこまで決めるかは、要件が求めるレベルによって異なる
（要件定義の時点で方向性までで止めておくのか、厳格に決定するのか？）
必要以上に明確にせず、後で変更可能なだけのバッファを取っておくと良い
アーキテクチャは最初に厳格に決めないと後で開発の際に困ると思っていたのですが、その前の要件定義段階においてはある程度余裕を持つのもありみたいです。
第7章 妥当性確認/合意形成
主な内容
- 要件定義の妥当性の確認方法
- システム要件
- 要求のブレイクダウン
- 要求→要件の変換
- 要件のブレイクダウン
- 成果物
- 未決事項
- 要件定義の合意形成の方法
印象に残った箇所
合意形成の際は、要件のレベルごとに対応するステークホルダーと内容を合意する
内容は以下の通り
- ビジネス
- ビジネス→業務、システムにブレイクダウンできない要件
- ビジネス要求→ビジネス要件に変換できないもの
- 業務
- 業務→システムにブレイクダウンできない要件
- 業務要求→業務要件に変換できないもの
- システム
- システム要求→システム要件に変換できないもの
「何をやりたいか？」はすでに要求で出ているので、主に 何をやらないか？ について合意を得ることがわかりました。
人は「真実」のフィルタを通して「事実」を見る
例：アメリカ人の4/10が創造論を信じている
ステークホルダーごとに真実のフィルターは異なり、事実の認識も異なるので合意形成は難しい。
抽象的な話ですが、程度の差はあれど見ている物は立場によってそれぞれ異なるということは肝に銘じておくようにします
-
実装において細かい仕様を詰める必要が合った際に「このIssueはどの要件/要求から派生したものだっけ？」と途方に暮れたことがありました。
↩