前書き
※この記事は、FLINTERS10周年記念として「133日間ブログを書き続けるチャレンジ」の32日目記事です。あと101日です。
IPAから「ユーザのための要件定義ガイド 第2版（以下、要件定義ガイド）」というドキュメントが公開されている。一部で評判が良いみたいなのだが、いざPDFを開いてみると500ページもあって一瞬で億劫になった。無意識のうちにcmd + wに指が伸びていた。たぶん同じような人は多いと思う。
なので、私が代わりに読んでみて簡単なサマリーを作ってみたい。要件定義ガイドが気になるという方がいれば、PDFを開く前にこの記事を読んでもらって、サクッとどんなことが書いてあるのか把握してもらうと便利なのではないか。
※本記事の図表・文章の引用元はすべて要件定義ガイドから。
※PM向けに書いてます。
結局何が書いてあるのか？
それで、最初に結論を言ってしまうのだけど、要件定義ガイドから私が読み取ったポイントはこんな感じだった。
- P60〜71に要件定義でよく起こる問題・解決策がまとめられている。自分のプロジェクトで起きている問題と照らし合わせて該当部分から読み進めるのが良さそう
- 全部を読む必要はなく、困ったことがあったときに該当する箇所だけ読んで、他の手段がないか探したりとか、何か指針づくりに活かせるアイデアを探そうとか、そういうことに使う感じ
- ある意味、「ユーザーストーリー」について深く掘り下げた解説書である
- 要件定義におけるドキュメントの逆引き集としても使えそう
上の中にピンと来た項目があったら興味を持つ可能性が高いので、このブログを読むよりも実際にPDFを開いてもらったほうがいいかも。
ひととおり読んでみた感想としては、ボリュームの割に意外と気楽に読めるということ。「プロジェクトでよくある問題→解決策」という構成でひたすら綴られているので、「こういうの、あるあるだなぁ」って感じで読んでいくと楽しめると思う。
序盤はお硬い内容が多めなので、とりあえずちょっと読んでみたいという人は中盤から目を通していくのがおすすめ。
目次
まず内容に入る前に、本書の目次を羅列しておく。
が、500ページもあるのでひとまず章だけ。さらりと目を通して、おおよそのイメージをつけてもらえれば。
- 第1章 背景
- 第2章 要件定義の問題認識
- 第3章 要件定義の全体像
- 第4章 ビジネス要求定義(BR)における問題と解決の勘どころ
- 第5章 システム化要求定義(SR)における問題と解決の勘どころ
- 第6章 要件定義マネジメント(RM)における問題と解決の勘どころ
- 第7章 要件定義の主要ドキュメント作成(DD)の勘どころ
- おわりに&付録
PMとして特に大事そうなのは第4章、第6章あたりか。
以降、各章の内容をざっくりまとめていく。
第1章 背景
ITシステムはこう変わってきたよね、という変遷についての話。1990年代からの移り変わりがまとめられている。
あまりこのあたりを知らない人にとっては面白いかもしれないが、ベテラン勢はどこかで目にしたことがあるはずなので読み飛ばしてもいいと思う。
軽く内容を紹介すると、500人月以上の開発プロジェクトだと納期遅延や品質満足度の低さが目立つプロジェクトが多いらしい（2018年度）とか、その原因の50％以上が要件定義に関わるとか。国内IT投資の割合の低さにも触れられており、しかも年々その差が拡大し続けているとか。
いろいろな背景情報を紹介しながら、「既存の要件定義のやり方ではうまくいかない時代」と主張している。特に以下3点ではより工夫が必要になるとのこと。
- 再構築時の要件定義
- 本当に役立つ要求がわからない
- アイデア創出
なお、この章の前に「はじめに」があるが、前段の前段という感じなので割愛する。
第2章 要件定義の問題認識
システム部門中心の体制ではダメだとか、経営層の参画が必要だとか、非機能要求が重要になっているとか、要件定義に十分な工期を割り当てるべきとか、日頃システム開発に四苦八苦しているPMなら「だよね」と思うぐらいのありきたりの内容かなと思った。だが、それくらい巷でもやはり出来ていないということなのだろう。
個人的には、こういった内容はおっしゃるとおりと思いつつ、ではIPAのドキュメントを経営層や業務部門の人が目にする機会があるのだろうか、とも考えてしまう。
とは言え、何もしないと何も起こらないのは道理で、開発側から何らかのアプローチをしていく必要があるだろう。そういう意味で、本章で紹介されている「超上流フェーズを進めるにあたっての勘どころ」はぜひユーザーサイドにも認識してほしい内容だなと思った。プロジェクトの発足当初に提示したり、読み合わせしたりしてもいいかもしれない。
ちょっと紹介したい（P45）。
- 原理原則[1] ユーザとベンダの想いは相反する
- 原理原則[2] 取り決めは合意と承認によって成り立つ
- 原理原則[3] プロジェクトの成否を左右する要件確定の先送りは厳禁である
- 原理原則[4] ステークホルダ間の合意を得ないまま、次工程に入らない
- 原理原則[5] 多段階の見積りは双方のリスクを低減する
- 原理原則[6] システム化実現の費用はソフトウェア開発だけではない
- 原理原則[7] ライフサイクルコストを重視する
- 原理原則[8] システム化方針・狙いの周知徹底が成功の鍵となる
- 原理原則[9] 要件定義は発注者の責任である
- 原理原則[10] 要件定義書はバイブルであり、事あらばここへ立ち返るもの
- 原理原則[11] 優れた要件定義書とはシステム開発を精緻にあらわしたもの
- 原理原則[12] 表現されない要件はシステムとして実現されない
- 原理原則[13] 数値化されない要件は人によって基準が異なる
- 原理原則[14] 「今と同じ」という要件定義はあり得ない
- 原理原則[15] 要件定義は「使える」業務システムを定義すること
- 原理原則[16] 機能要求は膨張する。コスト、納期が抑制する
- 原理原則[17] 要件定義は説明責任を伴う
ちなみに、要件定義・設計〜統合テスト・ユーザー総合テストと工程を3つに分けると、だいたい工期は2・6・2という比率になるそうだ。自分の関わるプロジェクトで要件定義の工期が全体の20％未満だったら黄色信号かもしれない（10ヶ月のプロジェクトなら要件定義が2ヶ月未満）。
ただ、新規開発か再開発か、大規模か小規模かといった差はもちろんある。意外だったのは、500人月以上の大規模な再開発プロジェクトのケースがもっとも要件定義にかける工期が少ない（4.9%）ことだ。これは、大規模再開発なのでユーザー総合テストに工数を大きく割いていて、全体からすると要件定義の工数が小さく見えるということかもしれない。
あと、この章では「問題カテゴリマップ」という要件定義でよく起こりがちな問題をマッピングした図が登場している。自分が関わるプロジェクトの課題と照らし合わせ、そこに関わる内容と具体的な解決策を確認するのが本書の読み方としてベストかと思う。
このマップは要件定義ガイドの中心的な存在であり、以降ではこのマップについて掘り下げられていく。
第3章 要件定義の全体像
前章で登場した「問題カテゴリマップ」は以下に大別されている。
- BR. ビジネス要求定義：「経営レベルの要求」に基づいて「業務の観点からの要求（ビジネス要求）」を獲得し、整理・優先度付け・具体化・文書化する部分の問題点
- SR. システム化要求定義：ビジネス要求を機能要件・非機能要件の観点で仕様化し、妥当性確認を行う工程の問題点
- RM. 要求定義マネジメント：要件定義開始にあたっての準備、要件定義プロジェクトの計画、要件定義活動の監視・コントロール、終結作業を行う部分の問題点
- DD. 文書記述：各ドキュメントの記載項目、サンプル、留意事項など
本章では、この全体像について解説している。P84にそれぞれで利用するドキュメント名が記載されているので、自信のないドキュメントや初見のドキュメントがあれば、該当ページで確認するという活用法がありそう。
なお、「経営レベルの要求」→「ビジネス要求」→「システム化要求」とブレークダウンしている例があり、普段何となくやっているところがうまく言語化されていて個人的に参考になった（P87）。
第4章 ビジネス要求定義(BR)における問題と解決の勘どころ
第4章はP89から始まる。つまり、まだ全体の1/5にも達していないということだ。ここからがようやく本論という感じだろう。
第4章以降では「問題カテゴリマップ」で取り上げた問題の対処法について具体的に解説していく流れ。詳しい内容は実際に読んでもらったほうがいいので、本記事では個人的に気になった対処法・キーワードを紹介していくことにする。
現行業務を再学習する
既存システムのリプレースだとドキュメントがまとめられていなかったり、随分前に更新が止まっていたりして、この方法に頼ることが少なくないのではないだろうか。実際に直近のプロジェクトでもやったことがある。
ここの部分は少ししかページが割かれておらずやや物足りなかったが、次に紹介されていた「実態と照らし合わせて確認する」も再学習に使えそうだ。
リッチピクチャ
一枚のドキュメントにステークホルダーのニーズや対立関係をまとめるらしい。面白そうなアイデアだが、これを実際にステークホルダーに提示するのはかなり難しそう。逆にそれがうまくやれるのなら、かなり開発がスムーズになりそうな気がする。
業務フローと要求を紐づけする
簡単なのにやったことがあまりなかったのでどこかで取り入れたいと思った。
優先順位の判断基準
MoSCow分析で6つの指標を出すというやり方が提示されている。簡単なのですぐ使えそうだし、業務部門側もとっつきやすそうだ。6つの指標とは、有効性、必要性、緊急性、費用、実現性、新たな問題のこと。
第5章 システム化要求定義(SR)における問題と解決の勘どころ
ここからは「SR. システム化要求定義」について。
正確な日本語表現をする
日本語文章術について、かなり具体的な注意点が羅列されている。どれも基本的な内容ではあるが、実際のプロジェクトでこれらが遵守できていないドキュメントはよく見るはずだ。単文/重文/複文の使い分けや箇条書き・表・図の活用、助詞の使い方、口頭言語は使わないなど。「形容詞や副詞を使用した場合は補足説明が必要」という注意点もあった。
この部分だけ国語の教科書みたいだが、実践的だし、こういう細かいことで認識を揃えることができる。新人向けの学習教材としても使えるかもしれない。
インスペクション
「レビュー」の部分で「インスペクション」の有効性や方法について大きくページを割いている。第三者から客観性、論理性、具体性、実現正などについて評価を受け、回答する中で思い込みを排し、欠陥を取り除くことを目指すとのこと。
有効な取り込みと思いつつ、MTGベースで進めるとプロジェクトに与える負荷が高いのではと思ったが、本書でも「インスペクションでは記録役、進行・まとめ役の負担もかなり高いため、これら2つの役も兼任を避けるべき」と言及されていた。
「検出と除去（対策）は分離して行う」あたりも重要そう。
ここでコラムとして紹介されている2つの事例は（できるかどうかはおいておいて）かなり実践的・具体的だ。この事例の中で「レビュープロセス成熟度」という4段階のレベルが出てくるが、私が関わってきたプロジェクトはどれも1〜2ぐらいという所感。これ以上を目指すには、組織全体で取り組む必要がある。
第6章 要件定義マネジメント(RM)における問題と解決の勘どころ
実はこの第6章が大ボリュームで、P189〜361まである。つまり要件定義ガイドは、要件定義フェーズの中でも「どうマネジメントするか」を重視しており、そこに多くのボリュームを割いているわけだ。
「RM. 要件定義マネジメント」には4つのサブプロセスがある。
- RM1. 立ち上げ
- RM2. 計画立案
- RM3. 監視・コントロール
- RM4. 終結
この章で語られてる内容はいずれもごもっとも（例えば「企画の目的とプロジェクト目標を共有し、目的意識を醸成する」など）なのだが、個人的な意見として、このあたりはクライアントに尋ねても曖昧なことが多い。あるいは1人のプロダクトオーナー的な存在の頭の中にあり、担当者レベルでは不明瞭なことが少なくない。もし教えてもらっても矛盾が含まれることもある。
なので、本章の内容はけっこう難しい。抽象度もそれまでの章に比べて上がっているし、実践するのも大変そう。
この章で挙げられている項目は非常に多く、下手をすると長大な工程になってしまい、スケジュールやコストの増大につながってしまいそうだ（ひいては関係者のモチベーション低下にも・・・）。そのため、要件定義を開始する前にどこまでやるか、リスクはどのあたりか握っておくことが大事ではと思った。
その中でも個人的に大切かなと思ったポイントは以下のとおりだ。
システム構築投資を回収するのは業務部門の役目であることを明示する
重要な主張だと思う。これを認識してもらうことで、業務部門から利用頻度を無視した要求がどんどん出てくるのを避けられる。
ただ、ROIも自分たちで判断せよと言ったところで、「じゃあコストを見積もってくれ」と言われて不毛な見積もり作業が大量に発生することも予想される。ひとつひとつの要求に対して厳密にROIを出すとかそういうふうに理解してもらうのではなく、こういう観点を持ったうえで要求を出してほしい、そうすれば各要求の精度も変わってくるよね、という文脈になるのかなと感じた。
コラムでは「アプリケーションオーナー制度」という事例が出てくるのだが、本ポイントの実践例としてこのような態勢が正しいのだろうと感じた。
前後のプロセスを確認し、要件定義のプロセスと必要な成果物、 記載レベルを定義する
いろいろなプロジェクトに関わってきた中で、要件定義のプロセスはちゃんと規定されることが少なく、流れのまま進むことが多いと感じている。で、途中で漏れや検討不足な部分が判明しててんやわんや・・・というのがよくある失敗パターンなのだけれど、本来は要件定義も実装などと同じようにしっかりとした計画を持って進めるべきではないかと思っていた。
この項目ではそのことを説いていて、要件定義におけるプロセスの重要性を主張している。あとに出てくる「合意形成プロセスを意識して計画を立案する」「成果物作成の担当を決める」という勘どころも同じ意味と理解した。
アジャイルを採用した場合、このあたりのことがすっ飛ばされてとりあえず作ってみようということになりやすい印象なので、個人的には「どこまで厳密に要件定義の計画を練るか」「アジャイルとはどう整合させるか」「エンジニアにどこまでドキュメンテーションを負ってもらうのか」あたりが気になる。
スケジュール作成
前の項目とも関係するが、要件定義のスケジュールをきちんと作成するのは難しいと思っており、以下の文章には完全に同意だ（P225）。
要件定義工程の特徴として、主要なWBSの作業量と所要期間との関連性が弱いタスクが多いことである(すなわち、作業工数や投入人員を増やしても所要期間が短くなりにくいタスクが多い)。そのためどうしても、ここまでにこのWBSは終えておく必要がある、あるいは、ここまでに終っているべきという観点で、スケジュールを引きがちである。
この問題に対して要件定義ガイドで挙げられているポイントとしては、「作業工数、所要期間が見積れるものは、できるだけそれを活かす」「手戻りや大きなスケジュール遅れに対する遅延対策を、あらかじめ計画しておく」など。やはり経験が必要になる部分のようだ。どういう人材をこの部分に充てられるかで大きく成功率が変わると想像する。
プロジェクトに必要な大切を構築する
この解説の部分では「ビジネスアナリスト」という職種が挙げられているのだが、私も日頃プロジェクトに従事するうえで業務とシステムの橋渡しをするそのポジションこそが重要と感じることが多い。この役目が果たせられる人がいて、かつリソースを大きく割いてくれるのであれば、プロジェクトはスムーズに進行しやすいと思う。
国内ではあまり聞かないが、海外では割りとよく見られる役割だ。なんとなく国内の業務プロセスの方が複雑怪奇なイメージなので、日本にこそ必要なポジションなのでは？
チームの発達段階を理解し、メンバーに働きかける
よく知られた「タックマンモデル」が挙げられている。タックマンモデル自体は知っている方も多いと思う。だが、実際に渦中にいるときにはあまり意識していなかったりする。
メンバー同士の不和や「なんかもやっとする」みたいな現象が増えてきたら、一度メンバー全員でこのモデルを確認して、「自分たちは今ここだよね」と認識するだけでも意識が変わりそうだ。
第7章 要件定義の主要ドキュメント作成(DD)の勘どころ
本章では様々なドキュメント例を紹介している。この章だけでも100ページ以上あるが、知っているドキュメントも多いはずなので、未知のものだけ読めばいいはず。ドキュメントのサンプルとして参照するといいのではないだろうか。
非機能要求をまとめるのが苦手なので、個人的にはそのあたりのドキュメントを参考にしたい。
まとめ
最後に「おわりに＆付録」という章もあるが、ここは割愛しておく。
実際に要件定義ガイドを読んでみた感想としては、500ページもあるものの自分に関係のある部分だけ読めばよかったりするので、意外とそこまでボリューミーとは感じなかった。それよりも時節出てくる「解決したい問題」という“あるある集”みたいなのが本当によくあるパターンだったので、読みながら頷きまくってしまう。チームで読んだら盛り上がりそうな予感がした。
記事では私の興味領域に刺さったものだけ取り上げたので内容がやや偏っているが、本書では見積もりや品質、調達なども取り上げられており、かなり幅広い内容だ。プロジェクトで困ったときのアイデア集として活用していこうと思う。
