最近ネットを見ていると要件定義入門的な記事が目についたので思ったことを書いてみる記事。ITシステム開発における要件定義に関するあれこれ。
【2023/10/10追記】続編の記事を書きました。実践要件定義入門 - 勘と経験と読経
目次
要件定義に関するおすすめ書籍
この後に何度も引用することになると思うので、最初に要件定義のおすすめ書籍を紹介しておく。と言っても紹介するのは1つだけだ。
便宜的にAmazonのリンクを置いておくが、本書のPDF版は無料でダウンロードできる。
本書をおすすめする理由はいくつかある
- 単著ではない
- エンジニア向けではなく、（一応）ユーザー企業向けに書かれており、わかりやすい
- 2019年の発行ということで、十分に新しい
- 無料
本書を読んでわからないことがあったら、本書で紹介されている参考情報などから広げていけば良いだろう。というわけで、まずはこの本を手に取っておこう。
さて、ここからが本題だ。
その要件定義は必要か
あなたが何らかのソフトウェアもしくはシステムを必要としていて、なんとなく要件定義をしようとしているのであればちょっと待って欲しい。その要件定義は本当に必要だろうか。
なぜ要件定義をしようとするのか。
要件は決められるのか
要件定義をするということは、字面通りに要件を定義するということだ。でも、ちょっと待ってほしい。あなたが作りたいソフトウェアの要件を今決めることはできるのだろうか。特に一般利用者向けのソフトウェアやウェブサイト、モバイルアプリケーションではざっくりとしたゴールは決められるが、細かい要件はまだ決められないという場合がある。
この場合は、要件定義とは異なるアプローチを取ることもできる。このあたりから始めるのがよさそう。
作りたいもの（プロダクト）のミッション、ビジョンから初めて実現手段まで落とし込んでいく。そういうアプローチが必要な場合もある。そういったものに対して従来型の要件定義を実施してしまうと、早い段階で実現手段を固めてしまうことによって失敗してしまうこともあるのだ。こちらでは、不確実性が高い場合の要件定義アプローチの限界を提示しつつ、仮説検証型アジャイル開発アプローチを提言している。
要件定義をすることがルールで定められているから要件定義をする必要がある
社内ルールでプロセスが標準化されていて、要件定義をすることが必須という場合はある。
でもちょっと待て。とりあえず以前に完了したプロジェクトの要件定義を取り寄せるべきだ。あと、そのプロジェクトが成功したのかどうかも確認しよう（うまくいっていない事もある）。それを見て同じような事をやるべきか判断しよう。何か違うと思った場合は要件定義に入る前に、もうすこし自由度の高い「企画」とか「事前検討」で内容を煮詰めたほうがいい。
どうしてこのような事を言うのかというと、標準化ルールがアップデートされておらず古い場合があるからだ。ゼロ年代前後にソフトウェア開発の失敗が続き、作業プロセスの標準化がブームになったことがあった。その時に制定されたルールがそのままという場合がある。一方でビジネスやソフトウェアを取り巻く環境は常に変化をしている。特に業務の電子化（紙でやっていた仕事をコンピュータに入力できるようにする）だけを想定した古いルールをそのまま適用するのは危ない。ルールだからという理由で思考停止して要件定義をするのは避けよう。
要件定義は、決められた目次やテンプレートに沿って穴埋めのように行う作業ではない。
要件は定義できるのか
冒頭で「要件を決められるのか」という質問をしたのだけれども、あらためて問いたいのは要件がどこにあるのか、である。
要件を定義することは、どこかにある要件を取り出して明文化（文書化）するということである。
- 要件はわたしの頭の中にある：問題ない。通ってよろしい
- 要件は大まかには決まっているが、細かいところは担当者間で相談しながら決める：問題ない。通ってよし
- 要件は業務マニュアルに書かれているはずだ：ちょっと待て。お前はこっちの部屋に来い
- 要件は現行システムの中にある：お前はあっちの部屋だ。つべこべ言うな
現行の業務マニュアルをベースに要件定義をするつもりのあなたへ
要件定義では現在の業務（As-Is業務フロー）をベースにシステム化後の新業務を定義していくことになる。そのベースとして現行の業務マニュアルやフロー図があるのであれば、だいぶ心強い。
ただし、現行の業務マニュアルがきちんと整備されていれば、である。その点は大丈夫だろうか。
- 現行の業務マニュアルは正しいか
- 漏れているマニュアル外の業務はないか
このあたりを押さえておかないと、だいぶ厳しいことになる。現行業務をキレイにすることとシステム化の要件定義を同時並行でやるのは割と地獄だ。先に現行業務を整備しておこう。
IPAの要件定義ガイドだと、4.1.1 現状の把握(BR.1.1) あたりにより実践的なアドバイスが書かれている。
現行システムをベースに要件定義をするつもりのあなたへ
現行システムが魔窟の状態の場合、新システムも当然の如くに魔窟になる。ゴミ屋敷の引越しをイメージすると良い。掃除をせずに業者を使って引越しをしようとすると、ゴミも全部引っ越すことになるので、ものすごく高くつく。まずは掃除をしよう。ここで言う掃除とは
- 不要な機能・帳票・インターフェースの廃止
- ドキュメント等の更新
などである。
なお現行システムを元にシステムを構築することを「再構築」と呼ぶ。この種のプロジェクトについては前述の要件定義ガイドとは別に公開されている以下の文書も読むと良い。便宜的にAmazonのリンクを置いておくが、本書のPDF版も無料でダウンロードできる。
また、上記サイトに掲載されている「デジタル変革に向けたITモダナイゼーション企画のポイント集」も重要だ。あわせてチェックしておこう。
外部業者を呼ぶ前に考えるべき事
どこから外注するかを考える
要件定義とひとことで言っても、大きく分けると前半戦と後半戦に分けられる。呼び方はいろいろあるのだけれども、ここでは「ビジネス要求定義」「システム化要求定義」と呼ぼう。
要件定義は大変なので、外部業者に委託したい気持ちはよくわかる。しかしちょっと待ってほしい。前半「ビジネス要求定義」は外注しにくいのだ。ここではIPAのユーザーのための要求定義ガイド第2版を基準として説明するが、前半戦で考えるのはたとえばこんな内容だ。
- ビジネス要求の獲得（現状把握、問題や課題の抽出、ゴールの定義、達成手段の整理）
- ビジネス要求の分析（体系化、優先順位付け）
- ビジネス要求の文書化
これを外部から来た人がやれるだろうか。文書化くらいは手伝ってもらえるかもしれないが、それ以外は自分たちでやるしかないのだ。
要件定義の作業期間を見積もる
ところで要件定義をやるとしたら、どれくらいの期間でやるべきなのだろうか。
もちろん、やってみなければわからないが、それでもたたき台としての計画は必要だろう。
ソフトウェア開発プロジェクトの統計情報は例えばIPAなどでも公開されているが、IPAのデータだと要件定義などの上流工程に関する情報があまり充実していない（これはベンダー向けに情報を公開しているからだと思われる）。そこで役に立つのが、一般社団法人 日本情報システム・ユーザー協会（JUAS）のソフトウェアメトリック調査だ。
たとえば2020年版のメトリック調査を見ると、世間のソフトウェア開発プロジェクトがどの程度の期間、工数で要件定義を実施しているかがわかる。
プロジェクトごとの工期合計に対する、要件定義工期、設計～統合（結合）テスト工期、ユーザー総合テスト工期の内訳比率をみると、22.9：59.3：17.8≒2：6：2 となる
JUAS ソフトウェアメトリックス調査2020システム開発・保守調査 報告書、4.2 工期の評価 より
他の文献ではどうだろうか。要件定義に関する名著である「ソフトウェア要求 第3版」を見ると、偶然ではあるが同じような期間比が書かれている（ただし本書は訳書であり前提とするプロセスは日本の標準的なものとは異なる）。
電気通信および銀行業界の15のプロジェクトを調査した結果によると、最も成功したプロジェクトでは、要求の引き出し、モデリング、妥当性確認、および検証に、リソースの28％を使用していた（HofmannandLehner2001）。プロジェクトの平均では、工数の15.7％とスケジュールの38.6％を、要求工学に費やしていた。（中略）私たちは、プロジェクト全体の作業工数の約15％を、要求の作業に割り当てるべきであると考えている。この数値は、この節で前述した調査結果の割合と一致している。つまり、プロジェクトの全体工数の見積もりが1,000時間なら、要求開発の見積もりは150時間になる。もちろん、要求をもっとよく理解した後で、プロジェクト全体の見積もりが変わる可能性もある。
ソフトウェア要求 第3版、19.1 要求の工数見積り
個人的には、JUAS報告にある全体期間の20%を要件定義に充てるのが良いと考えている。
