自分の所属するシステム部では、機能追加などの開発には、アジャイル方式の開発スタイルをとっているので、要件定義のようなフェーズがありません。
前職では、100人単位でのチーム編成で開発を進めるプロジェクトが多く、要件定義フェーズもしっかりとスケジューリングして進めてきました。
この要件定義は、基本設計に入る前に、決められることを徹底して決めていくので、作業が大変でした。
もちろん、時間的な都合から、後の工程で決定するという一般的な逃げ道も使ってきました。
現職のシステム部の開発スタイルに慣れてしまうと、開発者自身は楽になるのですが、組織として考えた時に色々と問題発生してきます。
例えば、追加した機能仕様を確認する時に、コードレビューから注視していなかったときは、実装を確認して、仕様を把握する必要があります。
これは、とても非効率なことです。
もちろん、何かしらのドキュメントを残すようなプロジェクト方針が決まっていると、ドキュメントも充実していると思います。
このあたりのさじ加減は、PMやリーダーの責任だと感じます。
要件定義やプロジェクト管理って、何気なく当たり前のように使ってきているけど、要件定義をエンジニア以外の方に説明する時に、わかり易く説明することが難しいと感じました。
本記事は、『要件定義』を自分なりの考え方で整理した内容となっています。
要件定義と聞くと、なんだか難しく面倒なイメージを持つ人も多いかもしれませんが、本記事に読むことで、要件定義はそれほど難しいものではないことがお分かりいただけると思っています。
要件定義自体は難しくないのですが、システム開発で肝となる最も大切なフェーズとなり、システム開発のトラブルを遡ると、ほとんどが要件定義のフェーズに問題ある場合が多いのです。
そのため、より一層、要件定義というものを難しく、面倒なイメージを持たれる方々が多いと思っています。
要件定義とは
要件定義とは、発注者の要望を明らかにし、リソースとのバランスを考慮した上で、目的を達成するために何をすべきかを明文化することです。
顧客の要望を吸い上げ、整理し、まとめあげることは、プロジェクトの重要な工程であり、建物でいうところの基礎部分で、上に立つ建物を支える重要な部分にあたります。
顧客の要望を吸い上げるというと、まず『ヒアリング』が思い当たると思います。
でも、顧客自身がシステム化するための要望をわかっていないということが意外と多いのです。
そういった整理されていない要望を整理しつつ、制約のある中で、費用対効果が最も高いシステム化案をまとめていく作業といってもよいと思います。
要件定義で行うことは、以下の４つに大きく分けられます。
プロジェクト全体の方針決定
プロジェクトの背景や目的を確認しゴールを設定します。そして、プロジェクトの体制やスケジュール、納品物を決めていきます。
このプロジェクトの背景や目的の文書は、プロジェクトの各フェーズでも特に参照する成果物となります。
製造フェーズでは、開発のピーク時には、多くの開発者が参画してきますが、この時に、プロジェクトの意味を共有するためのドキュメントとなることも多々あります。
業務要件の確認
業務要件の確認では、現在の業務やサイトを分析し、システム化する範囲の決定を行います。
システム化する範囲が広すぎる場合には、開発のフェーズを分けて、2次開発に持ち越すこともよくあります。
サイト要件の決定
サイト要件の決定では、サイトマップやページ構成の決定と、ターゲットブラウザ・ユーザ・OSの決定を行います。
システム要件の決定
最後に、 機能要件・非機能要件・ユーザビリティ要件・技術要件の４つを決定します。
機能要件では、サイトにどのような機能をもたせるか明確にし、非機能要件では、セキュリティや品質、リリースや運用保守などの目に見えない機能について明確にします。
またユーザビリティ・アクセシビリティ要件では、ユーザビリティ、アクセシビリティについてどの程度のレベルまで対応するかを決め、技術要件では、サーバやドメインなどのインフラ要件と、サイト構築のためのソフト・技術選定などの開発手法を決定します。
おすすめの参考書籍
改めて、要件定義とは？
を再考する時に、とても役に立つ書籍を紹介したいと思います。
いずれも入門書からベテランまでを対象とした書籍で、要件定義というものを体系的に学ぶことができます。
また、改めて要件定義というものを整理したいベテラン技術者にもおすすめの書籍です。
はじめよう！ 要件定義 ～ビギナーからベテランまで
はじめよう！プロセス設計 ～要件定義のその前に
はじめよう！システム設計 ～要件定義のその後に
