「要件定義」
システム開発において、よく聞く言葉です。
あなたは、要件定義の目的とやることをきちんと説明できますか？
分かっていそうで分からない「要件定義」。
まずはその全体の流れを学んでいきましょう！
- この記事のまとめ
- 要件定義の目的はシンプル。だが、いざやると難しい
- 要件定義で最低限やること
- 要件定義はとても奥深い
- 顧客業務とシステムをいかにシンプルに設計できるかが腕の見せどころ
この記事のまとめ
この記事を読むことで、以下のことがふんわりと理解できます。
- 要件定義とは、顧客と開発者の橋渡し的業務であること
- 要件定義で最低限やることは、
- システム全体像の作成
- 業務フロー図の作成
- 外部設計書の作成
- 要件定義で必要なスキルは、ファシリテーション能力と引き算思考
では、早速掘り下げていきましょう。
要件定義の目的はシンプル。だが、いざやると難しい
要件定義の目的は単純明快で、
顧客の要望を取りまとめ、後工程の（内部）設計、開発を進めるためのドキュメント（類）を作成すること
となります。
一見して簡単な話ではありますが、
実はこれ、顧客と開発者の２者から合意を取り付けねばならないという話で、
大抵一筋縄ではいきません。
要件定義は、顧客と開発者（設計者）を繋ぐための、橋渡し的な中間業務であり、
あなたが勝手に完了を判断して良いものではないのです。
顧客側からは、要求の網羅性、運用の合理性を求められ、
設計者側からは、仕様の矛盾点や技術、工数面での実現性について調整を求められます。
上記両者の妥協点を見つけ、合意に至って初めて、「要件定義を完了した」、と言うことができるのです。
まとまったシステム開発の要件定義は、プロジェクト全体のコスト、期間の1/3程度をかけるのが一般的で、
プロジェクトの成果物の成否を分ける、非常に重要なパートとなります。
要件定義で最低限やること
要件定義で最低限やることは、以下の3点です。
- システム全体像の作成
- 業務フロー図の作成
- 外部設計書の作成
※実際もっと沢山あるんですが、まずはこれだけ押さえましょう
１．システム全体像
この資料は、開発対象のシステムを中心とし、周辺のシステムとの関係を地図のように表現した資料です。
これは開発対象のシステム、ならびにその周辺システムの繋がりの理解と、
開発を担当する範囲（スコープといいます）を定義するのに役立ちます。
大抵の場合、顧客要求を基にこの資料が想定で最初に描かれ、これを礎にして話が進んでいきます。
２．業務フロー図
この資料は、開発対象のシステムを利用した運用の全てを、フローチャートで表現する資料です。
要件定義の最初の山場であり、
プロジェクトの成果物の品質と、顧客がシステムを使って得られるベネフィットに多大な影響をもたらします。
この資料でも開発する範囲を定義し、徐々にスコープを狭めていきます。
イメージは以下のような感じです。
A4横バージョンの例（簡易なときに使います）
縦書きバージョンの例（詳細を描きたいときに使います）
※Googleの画像検索結果に飛びます
３．外部設計書
この資料は、開発対象のシステムの画面（ユーザーインターフェース）の作りを表現する資料です。
要件定義の二つ目の山場で、２の業務フロー図と同様に、プロジェクトの成果物の品質に大きく関わってきます。
ページの構成（サイトマップ）や、画面内の要素の配置、機能性、入力許容文字（数）などを定義します。
外部設計書の作成は、「基本設計」のパートではないかという意見もあると思いますが、
ここも仕様の検討時に紛糾しやすい領域なので、要件定義担当者が処理することが業務効率上望ましいと私は考えています。
※丁度良いサンプルが無かったので、追って追加します。
要件定義はとても奥深い
要件定義でやることや作る資料を、前章で書いたように数行の文章で説明することは容易です。
しかし、冒頭で書いた通り、
要件定義は、顧客と開発者（設計者）を繋ぐための橋渡し的な中間業務であり、
必ず「合意」で終わる必要があります。
したがって、フォーマットを埋めればOKという類の仕事ではありません。
また、「プロジェクト」と呼ばれるものは、その都度テーマ（目的）とステークホルダーが入れ替わるものです。
従って、定義する要件や、作成する要件定義書類の表現方法も、プロジェクトごとに微妙に変わっていきます。
つまり、そのプロジェクトに携わるステークホルダーの人々と、テーマに合わせた「要件定義の進め方」をおこない、
「合意できる要件定義書」を作らねばなりません。
その点が、要件定義が難しく、奥の深い部分になります。
これは極論ですが、
合意さえできて、成果物に齟齬が起きなければ、要件定義で作る資料は何でもOK、ということも言えます。
基本的なセオリーに沿うべきではありますが、こういう柔軟な思考を持っておくと、
要件定義が多少やり易く（楽に）なると思います。
顧客業務とシステムをいかにシンプルに設計できるかが腕の見せどころ
優秀な要件定義担当者は、顧客要望や開発者の要望をそのまま仕様に落とすことはしません。
相手が何故それを必要とするのか、その真意や背景を聞き、中長期目線で考え、最適解を提案します。
その一番の理由は、業務運用も含めたシステム全体を、できるだけシンプルに設計することにあります。
優秀な要件定義担当者は、顧客の業務課題の解決策を考える際、下記の順番で仕様を検討します。
- 現在ある機能や運用の何かを無くすことで解決できないか
- 現在ある機能や運用を微調整することで解決できないか
- できるだけシンプルな機能追加で解決できないか
複雑な機能や分岐処理、裏側の処理を多く持つシステムは、
その分だけ、そのシステムの一般利用者から見えないブラックボックスが増えるため、
運用導入のハードルが上がるとともに、システムに不具合が混入する確率が上がります。
そうすると、顧客側の業務運用と、システムの運用保守の両面でコストが上がるため、
結果、顧客のビジネスにとってネガティブな影響を及ぼします。
時と場合によりますが、全体のコストカットを目的に、顧客側の業務フローの見直しを提案することもあります。
全体の設計をシンプルにできると、プロジェクトのQCDにもポジティブに働きます。
要件定義の担当者に必要なスキルを取りまとめると、主に以下の２点でしょうか。
- ステークホルダーから意見（真意や背景）を引き出す「ファシリテーション能力」
- いかに低コストで顧客課題を解決できるかの「引き算思考」
まとめ
いかがでしたでしょうか。
改めて、当記事の内容のまとめです。
- 要件定義とは、顧客と開発者の橋渡し的業務であること
- 要件定義で最低限やることは、
- システム全体像の作成
- 業務フロー図の作成
- 外部設計書の作成
- 要件定義で必要なスキルは、ファシリテーション能力と引き算思考
ここからは、「最低限やること」で書いた作業内容を、具体的に学んでいきましょう。
（鋭意作成中…）
当記事があなたのシステム開発ライフの一助になれば幸いです。
当記事のステップアップ図書
はじめよう! 要件定義
私が最初に要件定義を勉強した本です。
「要件定義」が何をすることなのか、親切丁寧に書かれています。
要件定義は色々な本で知識を得ると良いテーマですが、最初の１冊にお勧めです。
はじめよう! プロセス設計
要件定義の２つ目の成果物、業務フローの作り方を丁寧に解説した本です。
上で紹介した「はじめよう！要件定義」と同じ著者の書籍です。
こちらも併せて読んでみると良いでしょう。
外資系コンサルが教えるプロジェクトマネジメント
人間模様を軸にした、プロジェクトマネジメントの教本で、
目指すべきプロジェクト運営が分かりやすくまとめられています。
是非読んでみてください。
当記事の関連記事
このブログは、日本のプロジェクトマネージャーの仕事のレベルを底上げし、
本人とそのチームの人々の人生を幸福にすることを目的に、プロジェクトマネージャーの仕事に関する記事を書いています。
私自身も道半ばゆえ、至らぬ点も多々あるかと思いますが、記事の感想やリクエストをいただければ
できるだけ記事にしてお応えしますので、皆様の忌憚のないご意見をいただけますと幸いです。
コメント