はじめに

SIerからマーケティング会社に転職したため、最近はあまり行っていませんが、
どの業種においても、業務をきちんと進める上で要件定義の進め方・考え方は参考になるため、
久しぶりに要件定義のポイントについて振り返ってみました。

特に要件定義はシステム開発の上流工程に位置するので、難しい、、、というか、
如何にクライアントと、これから作るシステムの**「認識を合わせられるか」、
お互いの「合意が取れるか」**が肝になってくるので大事なフェーズと言えます。

そもそも「要件」って

ようけん
【要件】

大切な用事。
2.
必要な条件。
「資格―」

Google先生に聞くと要件とは「必要な条件」と出てきます。
つまり、クライアントの要望や課題を洗い出して、
システムを作る上で「必要な条件」を定義するということになるのでしょうか。

要件定義で定義する項目

とにかくたくさんあるので抜粋します。

システム概要: システム化の背景; 目的・方針; システム化する範囲; ・・・
機能要件: 業務フロー; 機能一覧; ・・・
非機能要件: 性能; 拡張性; ・・・
移行要件: 移行プロセス; 移行タイミング; ・・・
運用・保守: 運用体制; 保守; ・・・

特に重要だと感じる項目

要件定義で定義する項目はたくさんありますが、
特に大事だと考えているのは「システム化の背景」「目的・方針」「範囲」「業務フロー」です。

というのも、要件定義では

なぜシステム化する必要があるのか
システムが果たす役割はなんなのか
システムに何を期待しているのか
依頼したい範囲はどこなのか

が重要で、これを誤るとこの先の工程が全て破綻してしまう恐れがあるからです。
最後の最後になって、「期待していたのと違うなあ」とならないためにも、
目的を明確化し、認識を合わせ、コミュニケーションを取ることが大事だと思います。

余談ですが、これはマーケティング業界でも同じことが言えると思っており、

現状の課題は何なのか（課題の本質は何か）
なぜ分析する必要があるのか
分析結果がもたらす役割は何か
どんな施策につなげたいのか

など、初めの認識を合わせるということはとても大切になってきますね。

業務フローについては、当然といえば当然ですが、
現状の業務を洗い出し、どんなフローで業務を回しているのかを整理することで、
何処のフローを変え、効率化を図り、どんなシステムとするのか、を
全体を通して俯瞰して見ることが出来るためしっかり押さえておきたいポイントです。

これもクライアントと認識を合わせるためには大事な要素になってきます。

要件定義には業界・業務の基礎知識は必要？

要件定義を進める上では、クライアントと会話をする必要があるので、
基礎知識はやはり必要です。

何でもかんでも「それはどういう意味でしょうか？」「どういう事でしょうか？」と
聞いていては、クライアントに不安を与えることになってしまいます。

とは言え、知らないものは知らないし、業界特有の言い回しもあるので、
聞くべきところはちゃんと質問して疑問を残さないようにしたいですね。

クライアントからの要件を切り分ける

クライアントと会話を進める中で、当初のRFPに記載のない要望が出てくる
ことがあります。（夢がふくらんできます）

すべてを実装してあげた方が喜んでもらえる場合もありますが、
逆に実装したため納期が遅延し、怒られるなんてこともあるかもしれません。

そこで大事になってくるのが、

必要な機能
あったらいいな機能

を切り分けることです。

これらの判断は、予算、スケジュール、リソースなどを総合的に判断して、
決めきる必要があります。

特にウォーターフォールモデルで開発を進めている場合、
あとで実装するかも？的な機能要件を残しておくなんて出来ないですよね。

要件定義では「あったらいいな機能」の落とし所（無理やりではなく双方が納得する）を見つけ、
要件を整理することも大事になってきますねー。

すべての要件を決めきるなんて出来るの？

システム開発を進める上で、プロジェクト初期の段階で要件定義のスケジュールを
引いていると思いますが、

その要件定義の期間中にすべての要件を完全に「詰める」「決めきる」ことは、
小さなプロジェクトならともかく、大規模プロジェクトでは難しくなってきます。

そのため、**「優先度」**をつけ、重要な要件、次の工程に影響の出る要件などは優先的に進め、
後からでもスケジュールに影響の出ない要件（簡易な定義等）は優先度を下げるなど、
全体スケジュールを意識し進めることも大切になってきますね。

要件の詰め方

要件詰めを口頭確認だけで済ますと、
お互いの認識がフワッとしたまま進んでしまう恐れがありますので、
「時系列のデータの流れ」や「ステータスの遷移」など、認識が曖昧になりそうな定義は、
サンプルデータなどの補足資料を準備し会議を進めた方が、時間も短縮され、
認識も合わせ易くなると思います。

誰と会話するの？

基本的にはクライアントの「プロジェクト担当者」と進めると思いますが、
役職が上の方であったり、情シスの方であったりと、
現場から意見を吸い上げて持ってきている場合があります。

もちろん最終判断はプロジェクト担当者に決めてもらえば良いと思いますが、
要件を詰める中では、現場のユーザーにヒアリングさせてもらったり、
会議の場に呼んでもらったりした方が生の意見を聞けるため、認識が合わせやすく、
リスクも減るかと思います。

議事録の重要性

要件定義を進める上でもう一つ大事になってくるのが**「議事録」**です。

議事録は下記の利用が考えられます。

会議の振り返り／メンバーへの共有
議題・課題の「可決・否決・保留」の承認記録
課題管理への起票（対応期限は明確に（※））

（※）会議の中で新たに出てくる課題については、誰がいつまでに対応するのか、を
明確にする必要があります。

また、議事録の重要な用途としては、後から**「言った、言わない」**の水掛け論を防ぐことに
あると思います。

水掛け論になってしまった場合、調整がややこしくなる（押し切られるなんてことも...orz）ので、
そうならないためにも、

必要要件は議題にのせる
議事録を取る
議事録をクライアントと共有する
議事録自体の承認を得る（必要に応じ、読み合わせや捺印返却）

しっかり記録を残しておきましょー。

その他

要件定義書、議事録、スケジュール表、課題管理表、設計書などなど
事前に使いまわしのきく資料は**「テンプレート化」**しておくと良いと思います。
出来れば社内全体で。

メリットとして、

時間短縮（フォーマットを考えなくて良い）
品質向上（抜け漏れが減る）
社内共通のため人の入れ替わりに強い（急遽プロジェクトに組み込まれたとき汗）

但し、これらをちゃんと運用していくには、整備担当を決め、改善点のブラッシュアップを行い、
社内教育を行ってメンバーに利用を促していく必要があるのでハードルは上がります。

もしテンプレート化されていないようであれば、まずは個人利用から始めても良いかもですね。

まとめ

要件定義では「システム化の背景」や「方針・目的」を明確にし、**「お互いの合意」**を取る
必要機能とあったらいいな機能を**「切り分ける」**
後で**「言った言わない」**が発生しないよう必要事項は議題にのせ記録を取る
わからないことは素直に聞く、疑問を残さない
必要要件を可能な限り詰め切る（課題が残っていると後工程の影響がデカい）
プロジェクト担当だけでなく、ユーザーの意見も聞く
資料のテンプレート化は行った方が良い

おわりに

少しだけ進め方のポイントを振り返るつもりが長々と書いてしました。。。が、
これらをスムーズに進めるためにはクライアントとコミュニケーションをちゃんと取って
お互いの目指すべき方向性や意識を合わせることが大事ですね。

要件定義の難しさは、それぞれの仕様・定義をもれなく決めるというところにありますが、
クライアントから見れば、出来ればこれもやってほしいなあと思うのが人情です。
でも、対応が難しい場合はちゃんと会話し、お互いが納得する落とし所を見つけてあげる
のも要件定義の醍醐味かなあと思います。

私自身、打ち合わせの場でクライアントの要件を汲みつつ、
こちらのペースに持っていくことが出来たときは気持ちよく帰れたものです笑

要件定義の進め方は、各社、各人各様あると思いますので、少しでも内容がお役に立てれば幸いです。

宜しければこちらの記事「こんな時代だからこそテストの重要性を思い出せ！」もご覧くださいませ。