長く運用してきたシステムの移行や新技術の採用など、昨今の「要件定義」は複雑化し、難易度が上がってきているといえます。
顧客は常にタイトなスケジュールを要求してくるでしょう。
要件定義に時間を費やしている場合ではない、早く着手しなければ間に合わない、という焦りから、十分なヒアリングや検討を行わないまま、次の工程に進んでしまうプロジェクトは多くあります。
要件定義の重要性を理解し、間違った道に行かせる「トラップ要素」を知っておくことで、失敗を回避しながらゴールに向かうことができるでしょう。
要件定義をなんとなく行い、次の工程に進むとどうなってしまうのでしょうか。
要件定義の重要性を確認していきましょう。
顧客は常にタイトなスケジュールを要求してくるでしょう。
要件定義に時間を費やしている場合ではない、早く着手しなければ間に合わない、という焦りから、十分なヒアリングや検討を行わないまま、次の工程に進んでしまうプロジェクトは多くあります。
要件定義の重要性を理解し、間違った道に行かせる「トラップ要素」を知っておくことで、失敗を回避しながらゴールに向かうことができるでしょう。
要件定義をなんとなく行い、次の工程に進むとどうなってしまうのでしょうか。
要件定義の重要性を確認していきましょう。
要件定義をあいまいに行うと、不具合発生率が1.3〜2.7倍になる
ある実験で、要件定義を明確に行ったグループと、行わなかったグループの不具合発生率を比較しました。
結果、要件定義を明確に行わなかったグループの不具合発生率の差は2.7倍となりました。
また、IPAの分析でも、
“上流工程を強化した信頼性が高いグループと信頼性が低いグループで、上流工程での不具合摘出比率に中央値で約 1.3 倍の差が見られる。
上流工程での不具合摘出比率（中央値）は、信頼性が高いグループの約 85%に対し、低いグループでは約 66%である。”
(引用：ソフトウェア開発データが語るメッセージ「設計レビュー・要件定義強化のススメ」)
いずれも要件定義の重要性がわかる分析・実験結果です。
「不具合が発生する＝修正コスト、手戻りのコストがかかる」という事です。
最近では、ウォーターフォール型の開発から、アジャイル開発を採用するプロジェクトも増えてきました。
しかし、アジャイル開発を正しく理解しないまま進めるケースも多くあります。
アジャイルはドキュメントを書かなくて良い、要件はしっかり決めなくてもよいと「誤った理解」のままプロジェクトを進めた結果、失敗に終わり「アジャイル開発は駄目だ」と残念な判断が下されることもあります。
粒度や押さえどころが手法によって異なるだけで、要件定義は必要かつ重要な工程です。
プロジェクトを成功に導くためにも、要件定義は特に注意して進める必要があります。
結果、要件定義を明確に行わなかったグループの不具合発生率の差は2.7倍となりました。
また、IPAの分析でも、
“上流工程を強化した信頼性が高いグループと信頼性が低いグループで、上流工程での不具合摘出比率に中央値で約 1.3 倍の差が見られる。
上流工程での不具合摘出比率（中央値）は、信頼性が高いグループの約 85%に対し、低いグループでは約 66%である。”
(引用：ソフトウェア開発データが語るメッセージ「設計レビュー・要件定義強化のススメ」)
いずれも要件定義の重要性がわかる分析・実験結果です。
「不具合が発生する＝修正コスト、手戻りのコストがかかる」という事です。
最近では、ウォーターフォール型の開発から、アジャイル開発を採用するプロジェクトも増えてきました。
しかし、アジャイル開発を正しく理解しないまま進めるケースも多くあります。
アジャイルはドキュメントを書かなくて良い、要件はしっかり決めなくてもよいと「誤った理解」のままプロジェクトを進めた結果、失敗に終わり「アジャイル開発は駄目だ」と残念な判断が下されることもあります。
粒度や押さえどころが手法によって異なるだけで、要件定義は必要かつ重要な工程です。
プロジェクトを成功に導くためにも、要件定義は特に注意して進める必要があります。
要件定義で行うこととは？要件定義の全体像
要件定義を簡単に言うと「5W1Hを明らかにする」ことです。
5W1Hとは
・Why なぜ、何のために
・When いつ
・Where どこまでの範囲を
・Who 誰と(関係者)
・What 何を
・How どのように作るのか
一見シンプルに見えますが、要件定義の全体像を表すとその範囲は広く、明確にすることや整理することは非常に多くあります。
（出典：IPA 情報処理推進機構 要件定義を成功に導く128の勘どころ）
これらを100%に作り上げるとなると、工数がかかるうえに、要件定義がいつまでも「終わらない」という状況になってしまいます。
各要素をどこまでの粒度で行うのかは経験も必要です。
可能な限り、納得のいくレベルまで実施するのが良いですが、重要度やリスクから考え、それらに重点をおいて進めます。
①真のユーザー・ニーズを掴む
②非機能要件を明らかにする
③あとで「言った言わない」になりそうな曖昧な要求を列挙し、潰す
④開発において実現可否がわかっていないところに目処をつけるか、方針を明らかにする
上記4つのうち、一番大事なことは「真のユーザー・ニーズを掴む」ことです。
これは5W1Hを充実させ、良い要件定義にするための肝になります。
5W1Hとは
・Why なぜ、何のために
・When いつ
・Where どこまでの範囲を
・Who 誰と(関係者)
・What 何を
・How どのように作るのか
一見シンプルに見えますが、要件定義の全体像を表すとその範囲は広く、明確にすることや整理することは非常に多くあります。
（出典：IPA 情報処理推進機構 要件定義を成功に導く128の勘どころ）
これらを100%に作り上げるとなると、工数がかかるうえに、要件定義がいつまでも「終わらない」という状況になってしまいます。
各要素をどこまでの粒度で行うのかは経験も必要です。
可能な限り、納得のいくレベルまで実施するのが良いですが、重要度やリスクから考え、それらに重点をおいて進めます。
①真のユーザー・ニーズを掴む
②非機能要件を明らかにする
③あとで「言った言わない」になりそうな曖昧な要求を列挙し、潰す
④開発において実現可否がわかっていないところに目処をつけるか、方針を明らかにする
上記4つのうち、一番大事なことは「真のユーザー・ニーズを掴む」ことです。
これは5W1Hを充実させ、良い要件定義にするための肝になります。
要件定義の肝『ユーザーニーズ』を把握する
ユーザーニーズを知る事で、自ずと5W1Hは充実し、良いアウトプットができでしょう。
ただしこの「ユーザーニーズ」を正しく引き出すことが難しいのです。
その難しさを表した図が下記です。
『顧客が本当に必要だったもの』という有名な図です。
この図は「真のユーザーニーズ」を捉えることが如何に困難であるかを表しています。
ユーザは「木を使ったブランコを作りたい」と要求し、左上の図のようなものを要求しました。
しかし、受け手の理解不足や誤認、伝言ゲームによって、最終的にアウトプットされたものは全く異なるものでした。
さらに、右下の図「顧客が本当に必要だった物」は、実は当初の要求とも異なっていた、という話です。
詳しくは
「Tree Swing Cartoon Pictures」
ただしこの「ユーザーニーズ」を正しく引き出すことが難しいのです。
その難しさを表した図が下記です。
『顧客が本当に必要だったもの』という有名な図です。
この図は「真のユーザーニーズ」を捉えることが如何に困難であるかを表しています。
ユーザは「木を使ったブランコを作りたい」と要求し、左上の図のようなものを要求しました。
しかし、受け手の理解不足や誤認、伝言ゲームによって、最終的にアウトプットされたものは全く異なるものでした。
さらに、右下の図「顧客が本当に必要だった物」は、実は当初の要求とも異なっていた、という話です。
詳しくは
「Tree Swing Cartoon Pictures」
良い要件定義を阻むもの
なぜ「顧客が本当に必要だったもの」の図のような事が起きてしまうのでしょうか。
何が「真のユーザー・ニーズ」を捉えることを阻んでいるのか。8つあります。
①ユーザーは本当のニーズを把握していない
②ユーザーが気づいていないニーズがある
③ユーザーは全てのニーズを語らない
④ユーザーはニーズを整理して語れない
⑤ユーザーは当たり前だと認識しているものについては語らない
⑥ユーザーが語ったニーズと、設計者の受け取り方が一致しない
⑦語る人によって言葉の定義や意味が異なる
⑧把握したニーズは、正確に残されない
詳しく確認していきましょう。
①ユーザーは本当のニーズを把握していない
②ユーザーが気づいていないニーズがある
ユーザの要求通り作ったにもかかわらず、使いにくいシステムになることがあります。
例えば
「在庫をリアルタイムで分かるようにして欲しい」
という要求があったとします。
これは、ユーザが何らかの課題に対して出した「解決策」としての「結論」にすぎません。
結論に至るまでの根本的な「Why」を聞き出せなければ、真のユーザニーズには辿りつけません。
在庫をリアルタイムで知りたいのは、即座に発注したいからかもしれませんし、売れ筋を把握して値段を変えたいからかもしれません。
「Why」を知ることで、真のニーズを捉え、エンジニアはより良い解決策を提案することができます。
③ユーザーは全てのニーズを語らない
④ユーザーはニーズを整理して語れない
⑤ユーザーは当たり前だと認識しているものについては語らない
システムの要求は、一度に語れるものではありません。
ユーザが我々に100%要求を伝えることは困難です。
要求をそれからそれへと述べるうち、話が飛び、ひとつを語り終える前に次の要求の話になる事もしばしばあります。
また、ユーザは、自身にとって「当たり前」の事は、わざわざ口に出しません。
このように、整理して語られないことが多くあると認識した上で、ヒアリングを重ねる必要があります。
⑥ユーザーが語ったニーズと、設計者の受け取り方が一致しない
会議でユーザが語ったことをメモして、要求としてそのまま持ち帰って大丈夫でしょうか。
ユーザにそのメモを改めて確認してもらうと、多くの修正が入るでしょう。
受け手の経験による解釈や、良かれと行間を読んだ事による認識違いで、伝言ゲームが始まっていきます。
必ず「○○は△△ということですね？」など、細かく確認を取り、認識違いをなくしましょう。
⑦語る人によって言葉の定義や意味が異なる
プロジェクトでは、しばしば「用語集」を作ることがあります。
人によって違う表現をしたり、ひとつのことに複数の定義があることで発生する問題を防ぐためです。
小さく地道なことですが、この「あいまいさ」をなくすことが、後の大きな事故を防いでくれます。
⑧把握したニーズは、正確に残されない
形ばかりのドキュメントを作っていないでしょうか。
何も残さないのは論外ですが、人によって解釈が異なってしまうような書き方では、残す意味がありません。
アウトプットは、チームが設計作業に入れる粒度にしなければいけません。
正確に残すにはUMLやユースケースなど「図」を多く使うのも良い手です。
何が「真のユーザー・ニーズ」を捉えることを阻んでいるのか。8つあります。
①ユーザーは本当のニーズを把握していない
②ユーザーが気づいていないニーズがある
③ユーザーは全てのニーズを語らない
④ユーザーはニーズを整理して語れない
⑤ユーザーは当たり前だと認識しているものについては語らない
⑥ユーザーが語ったニーズと、設計者の受け取り方が一致しない
⑦語る人によって言葉の定義や意味が異なる
⑧把握したニーズは、正確に残されない
詳しく確認していきましょう。
①ユーザーは本当のニーズを把握していない
②ユーザーが気づいていないニーズがある
ユーザの要求通り作ったにもかかわらず、使いにくいシステムになることがあります。
例えば
「在庫をリアルタイムで分かるようにして欲しい」
という要求があったとします。
これは、ユーザが何らかの課題に対して出した「解決策」としての「結論」にすぎません。
結論に至るまでの根本的な「Why」を聞き出せなければ、真のユーザニーズには辿りつけません。
在庫をリアルタイムで知りたいのは、即座に発注したいからかもしれませんし、売れ筋を把握して値段を変えたいからかもしれません。
「Why」を知ることで、真のニーズを捉え、エンジニアはより良い解決策を提案することができます。
③ユーザーは全てのニーズを語らない
④ユーザーはニーズを整理して語れない
⑤ユーザーは当たり前だと認識しているものについては語らない
システムの要求は、一度に語れるものではありません。
ユーザが我々に100%要求を伝えることは困難です。
要求をそれからそれへと述べるうち、話が飛び、ひとつを語り終える前に次の要求の話になる事もしばしばあります。
また、ユーザは、自身にとって「当たり前」の事は、わざわざ口に出しません。
このように、整理して語られないことが多くあると認識した上で、ヒアリングを重ねる必要があります。
⑥ユーザーが語ったニーズと、設計者の受け取り方が一致しない
会議でユーザが語ったことをメモして、要求としてそのまま持ち帰って大丈夫でしょうか。
ユーザにそのメモを改めて確認してもらうと、多くの修正が入るでしょう。
受け手の経験による解釈や、良かれと行間を読んだ事による認識違いで、伝言ゲームが始まっていきます。
必ず「○○は△△ということですね？」など、細かく確認を取り、認識違いをなくしましょう。
⑦語る人によって言葉の定義や意味が異なる
プロジェクトでは、しばしば「用語集」を作ることがあります。
人によって違う表現をしたり、ひとつのことに複数の定義があることで発生する問題を防ぐためです。
小さく地道なことですが、この「あいまいさ」をなくすことが、後の大きな事故を防いでくれます。
⑧把握したニーズは、正確に残されない
形ばかりのドキュメントを作っていないでしょうか。
何も残さないのは論外ですが、人によって解釈が異なってしまうような書き方では、残す意味がありません。
アウトプットは、チームが設計作業に入れる粒度にしなければいけません。
正確に残すにはUMLやユースケースなど「図」を多く使うのも良い手です。
まとめ
要件定義で最も重要なことは『あいまいさ』を無くしていくことです。
100%を最初から目指すのは難しいことですが、注意すべき点を念頭におき、プロジェクトの進行中も徐々に質をあげていくことはできます。
IPAやPMBOKには、良いテンプレートやサンプルがあります。
テンプレートも上手に使いながら「良い要件定義を阻むもの」を念頭に置き、進めていくと良いでしょう。
100%を最初から目指すのは難しいことですが、注意すべき点を念頭におき、プロジェクトの進行中も徐々に質をあげていくことはできます。
IPAやPMBOKには、良いテンプレートやサンプルがあります。
テンプレートも上手に使いながら「良い要件定義を阻むもの」を念頭に置き、進めていくと良いでしょう。
