ごきげんよう、Zei(ゼイ)です。
個人開発をするにあたって、「個人開発ではありながらも、しっかりとシステム開発のプロセスを踏んで形にしていこう」と決意しました。
今回は、システム開発9つの工程の一番目【要求定義】を詳しく学んでいこうと思います。
以前の決意した記事↓
【超個人的なWEBアプリを作りたい】
システム開発の工程全体を説明している記事↓
【システム開発の流れと開発手法を知ろう】
システム開発を開発者へ依頼する際に、何をする必要があるかを紹介します。
システム開発を依頼したい方におススメです。
システム開発一番はじめの工程【要求定義】
要求定義とは、非技術者の依頼者が、そのシステム開発の目的やそのシステムに何を求めているのかを明確にしていく作業。
依頼者が作りたいシステムのイメージを開発者に伝える。
⇓
開発者はそのイメージを形にするために、依頼者からの要求を整理する。
⇓
開発者は必要な機能や、性能などの非機能を具体的に定義していく。
品質の良いシステムを構築するためには、依頼者は開発者任せでも、開発者も一方的に依頼者の要求を聞くのではなく、双方が協力して行う共同作業という理解が重要。
そもそも、要求とは
辞書にて『要求』をひいてみると
① 強く請い求めること。当然のこととして強い態度で相手に求めること。
② 必要とすること。ほしく思うこと。
③ 人間の行動の基礎にある動因。願望として自覚されたものだけでなく、
意識されない深層の動因もこれに含まれる。欲求。
④ 法律で、相手方にある行為を求めること。「請求」よりもやや広い意味で使われる。引用：精選版 日本国語大辞典
とにかく『欲しい』・『必要』を相手に求めている。
そして表面に表現できない深層の欲求もあるようだ。
システム開発にて必要な要求
システム開発の要求にて、絶対に明確にする必要があるのが、『目的』と『何がしたいか』。
システム化する目的(Why)
『欲しいから作ってほしい。』が開発者への依頼のきっかけだが、
システム化に至った背景やシステム化する目的の『なぜ(Why)』を開発者へ伝えることが最も重要。
これが依頼者・開発者の互いで認識がズレると、プロジェクトは必然的に失敗しやすいとのこと。
何がしたいのか(What)
『こういう背景・経緯がある(Why)から、これ(What)が欲しい！』と、
システム化に至った背景やシステム化する目的(Why)を前提に『何がしたいのか(What)』を開発者に伝え、それを確認した開発者は技術的にシステムで実現可能なこととして、その実現方法（How）を要件として定義してくれる。
要求したけど、いまの技術では実現不可能なこともあるため、開発者が最適な実現手段を選択したり、要求を最適な実現方法に導くことをしてくれる。
ので、一旦『何がしたいのか(What)』は全部盛り盛りさせておけばいいと思う。言うだけはタダなので。
要求定義書と要件定義書の違い
「要求定義書」とよく似た言葉に「要件定義書」があり、
英語はどちらも「Requirements definition document」と表記される。
「夢」と「理想」・主体の書き手
- 依頼者が開発者に対して誰が何のためにシステム化したいかを表したもの
- 依頼者の「夢」
- 依頼者が開発者に出す依頼事項（リクエスト）
- 開発者が依頼者の依頼に対して、システムが備えるべき機能を表したもの
- 依頼者の「夢」をシステム化した場合の「理想」
- システムに必要な機能や非機能を整理した依頼者と開発者の間の合意事項
品質を高めるための心得
要求定義が失敗する要因は、依頼者側・開発者側、どちらにもある。
依頼者側・開発者側、互いに品質を高めるための心得が必要である。
依頼者側
依頼者の認識不足によって起こることがかなり多い
- 目的が明確でない
- 要求がざっくりとし過ぎている
- 思いつきによる要求の抜け漏れ
- 要求同士の衝突・矛盾といった内容を多分に含めてしまう
- システムへの知識不足
- 重要な機能の優先度を明確にしておく
- 場合によってはシステムに組み込めないことがあるなども理解しておく
- システム開発には開発者側の常識というものが存在することを理解しておく
（※機密情報を取り扱うシステムの場合、厳重なセキュリティ対策を講じるなど） - 要求の中に含んでいなかった内容だが、開発者にその必要性を提案された場合はしっかり確認する。
開発者側
要求定義の作業を行う開発者側SE（システムエンジニア）の力量不足。
- 本当に必要な機能とそうでない機能の整理ができない
- 顧客の理解を得られるよう調整役が上手くできない
- システム開発には開発者側の常識(セキュリティ対策など)の必要性を上手く提案できない
- 依頼者の要求を最大限実現する努力をする
- 必要に応じて依頼者の思いつきの要求を他の機能との矛盾という観点から要求を排除する
- 依頼者の要求にはないが必要とする機能や非機能があれば提案する
パートナー選定のRFP（提案依頼書）
要求定義書とはまた別に『RFP（提案依頼書）』というものがある。
誰に開発を依頼するかを選ぶ『パートナー(業者)選定』の際に、候補の開発者に提案書や見積書を作成してもらうために提示する依頼書のこと。
要求定義書作成
⇓
要求定義書から委託範囲を抽出して開示範囲を整理
⇓
システム化の目的や予算、契約条件や業者選定スケジュールなどのプロジェクト概要をまとめた文書を用意
パートナーを選ぶにあたっては、要望を実現できる技術力があるかどうかだけでなく、協力関係を築いてプロジェクト進行ができるかどうかがポイントになる。
実力がある業者を選ぶためには「情報を開示しすぎない」ことも、RFPを作るにあたってのコツらしい。
要求定義書のポイント
プロジェクトの目的を明確に
- 『なんのためにシステムを導入するのか』という、『達成すべき目的』を明確にする
- 業務改善や業務効率化を叶えるたにシステム導入を検討する際は、何をもって改善・効率化とするか、導入前と導入後の差異を把握しておく
現状分析から理想像を導き出す『As-Is/To-Be分析手法』
業務改善・業務効率化のプロジェクトでは、「As-Is/To-Be分析」という手法がよく用いらる。
As-Is（現状）の業務フローを図に起こし、課題となる部分（ボトルネック）を特定し、
To-Be（あるべき姿）を導き出す分析手法。
現状維持すべき点と改善すべき点を可視化することができ、システムに必要な要件（機能・性能）を見極める。
QCD：Quality（品質）Cost（費用）Delivery（納期）
プロジェクトを進めるうえでQCDのバランスが大切になる。
| QCD | |
|---|---|
| Q（Quality） | 品質 |
| C（Cost） | 費用 |
| D（Delivery） | 納期 |
※重要度が高い順
この3つは、どこかで問題が生じれば相互に影響し合う。
そのためそれぞれの状況を把握しながらちょうどよいバランスを見定め、維持することが重要。
要求定義書を作成する際の注意点
- システム開発・導入の目的を明確にする
- 5W1Hを意識した内容にする
- 搭載機能に優先順位をつける
- 用語や表記を統一する
- できる限り図表や画像を入れる
要求定義書は作成後も管理を怠らない
要求定義の工程が過ぎシステム開発が進んでいる最中に、後から要求が追加されたり要求した内容の変更要求が出てくる場合がまあまあにある。
要求定義書は、依頼者が検収時に行う受入テストのインプット資料にもなるため、もし要求定義書が追加や変更に対応していなければ、その受入テストの根拠が不明瞭となり評価ができなくり、さらに状況によってはトラブルに発展する。
要求定義書は作成後も要求に追加や変更があれば、その都度必ず変更管理を行うことが重要。
参考サイト
おわりに
以上、要求定義についてまとめてみました。
要件定義はIT業界にいると結構聞きますが、『要求定義』という言葉ははじめて出会いましたが、システムを欲しいと依頼する側にとても重要な定義だと分かりました。
システムを開発するのは確かに開発者ですが、どんなものが欲しいのかは依頼者が一番知っているはずなので、自分もシステムを作るんだ！という意思をもって考えていく必要があるのだなと感じました。
コメント