こんにちは。ソフトウェアエンジニアのなししです。
私は現在社内業務システムの開発チームに所属し、案件の要件定義〜リリースの全ての工程に関わっています。
その中でも特に「要件定義」の重要性を改めて感じている今日このごろです。
今回は要件定義の重要性を改めて感じるきっかけになったしくじりと今やっているTRYについてお話ししていきます。
要件定義をおざなりにしてしまった話
後に控えているスケジュールを考えるとなるべく早く仕様をFIXさせたい案件がありました。
（※案件Aとします。）
焦る気持ちもあり、要件すり合わせでは大まかな部分を定めて、詳細部分は仕様工程で考える方向で案件A進めていました。
そのときは仕様書で詳細部分が書かれていれば実現はできるという気持ちも大きく、要求・要件の違いも、要件定義書の重要性も曖昧なまま、要件のすり合わせをおざなりにしてしまいました。
結果、要件定義書は下記のような形になってしまいました。
- 要求が具体的になっている（＝要件が要求に記載されている）
- 具体的ではない要件がある
- 特定の観点（データ要件等）の要件が漏れてしまっている
aはレビュー時点で差し戻しとなりましたが、b,cについては気づかれず案件Aは進んでいきました。
bについては、先程も述べた通り仕様部分で賄おうという気持ちもあったと思います。
その結果、それ以降の工程で大きく分けて2つのことが発生しました。
1. 要件漏れ・要件の曖昧性
事象としては「ここ、どうしようか」という課題が仕様〜製造の工程までポロポロと発生しました。
原因としては、前述の2,3に当てはまるものがほとんどで
- そもそも要件が漏れていた
- 要件の定義が甘かった
ことから、仕様や設計に落とし込めなかったと思っています。
要件漏れがその後の工程で判明することによって、
再度要件のすり合わせ〜仕様検討〜設計書反映〜製造とフローを辿るため、プラスで工数がかかってしまっていました。
また、設計書に落とし込むまでその部分の製造やテスト作成が進められなくなるためスピードが落ちることもあります。
要件が曖昧だと、仕様や設計で詳細部分を握れればよいですが
我々のチームでは仕様検討時にUIやふるまいを定義するため、詳細部分の方向性・認識が違うとまるっと作り直しになってしまい工数も膨らみます。
2. スケジュール遅延
1とも繋がる内容ですが、各工程で要件漏れが判明したことで
- 仕様FIXの遅延
- スコープの拡大
- 開発工数の増加
- コミュニケーションコストの増加
が発生し、最終的にリリースは2週間ほど延びてしまいました。
「コミュニケーションコスト増加」については補足しますと、「こういうときどうしますか？」という質問があがり、質問＋確認＋仕様〜設計が再度発生したため含めています。
TRYしていること
案件Aでは前述の1が根本原因として2のスケジュール遅延にも繋がったため、1を解決するために以下2つのことをTRYしています。
でてきた要求／要件の深掘りを満足するまで行う
要件漏れ・要件の曖昧性があると、それ以降の工程で工数増加・スピード感等に影響があったため要件定義時点でなるべく詳細にすり合わせを行うようにしました。
案件Aには要件レベルのことを要求に記載してしまっていました。
というのも、要件定義ではよくある「ユーザーからの要望をそのまま飲み込む」ということをした結果です。
本来、「なぜその機能がほしいのか」「なにがやりづらいのか」「どういう状態になるのがよいのか」などを深掘りし、根本にどんな要求があるのかをヒアリングすべきであり、
「どうシステムで実現するのか」を考えるのは我々開発チームの仕事です。
また要求の中にはシステムで実現するのではなく、アナログで実現することが最適かもしれませんし、業務フローを変えるのが最適かもしれませんし、それは現状をヒアリングして考えてみないとわかりません。
ヒアリング→開発チームで検討→提案→ヒアリング→検討・・・
を繰り返していくことで要件はどんどん明確になり、合意形成を取れた上で次の工程に進むことができます。
また、要件を詳細に定義しステークホルダーから合意形成がとれていると、その後の工程で大きな差し戻しが発生しづらく、スムーズに進められています。
要件を各役割で見直す
要件について開発チームで検討する際にやるといいなと思っていることで、要件漏れの対策の一つだと考えています。
我々のチームでは、主担当のサービスプランナー*1が要件定義を進めることが多いのですが、専門範囲外というところで非機能要件やぼんやりした要件の実現方法、データ保守性などが適切に定義されないことがあります。
また職種関係なく主担当はその案件に集中しているため、時に視野が狭くなってしまい要件が漏れてしまうことがあります。
そんなときに、サービスプランナー ✕ エンジニアなど職種を掛け合わせ、ラフに要件について話し、見直し、もっとよい方法がないかを考える時間を設けることでよりよい要件を提案することができると思っています。
以上２つがTRYしていることです。
要求を正しく理解し、それを実現するためにはどういう要件が必要/不要なのかというところを今は大切にしているため正直スピード感はありません。
今後は要件定義のスピード感を上げ、より早くユーザーに価値を提供することがミッションだと思っています。
まとめ
要件定義は難しいとよく言われますが、本当にその通りだと思います。
ユーザーが「どこに課題を感じどういう背景を持っているのか」等のヒアリングの仕方や、どうシステムに落とし込むと一番ベストなのかを考えることが大切だと感じています。
まだまだどうやっていくのが効率的か等探り探りでやっている状態なので、「要求を正しく理解し、要求に対する解決策（＝要件）が詳細に記載されており誰が見てもわかりやすい」要件定義書を作成できるようにこれからも精進してまいります！
最後まで読んでいただきありがとうございました！
＼\『真のユーザーファーストでマーケットを創造する』仲間を募集中です!! /／
