エンジニアのはしくれ

システム開発、ものづくり、etc…

要件定義ってどうやるの?~顧客に一目置かれるためのコツをまとめました~

はじめに

システムエンジニア(SE)のシステム開発の仕事の一つに、顧客の要望をヒアリングしてシステムに求める要件を決める「要件定義」という工程があります。
今回、その要件定義の経験者として私が普段から意識していることや後輩(要件定義の初心者)にレクチャーしているコツなどをまとめました。

目次は以下の通りです。ご参考になれば幸いです。

要件定義で意識していること

裏にある真の要望を探り出す

顧客の発言が常に正しいとは限りません。その理由として以下が考えられます。

  • 顧客のアイデアはまだ漠然としたものであり、考えがまとまっていない
  • 制約(予算、納期など)を無意識に考慮している
  • システムに関する知識、経験が少ない(顧客がSEでなければ当たり前)

上記を踏まえ、自分が納得できるまで質問して発言の裏にある真の顧客要望を聞き出すようにしましょう。

例えば「システムを○○○して欲しい」という要望には注意が必要です。なぜならその要望の裏にある背景が分からないためです。具体例として「システムで電話番号を2つ表示できるようにして欲しい」を挙げるとすれば、なぜ2つ表示させたいのか、どんな時に2つ表示させるのか、2つで足りるのか、電話番号以外で同様に対応するものはないかなど、色々と疑問が湧いてきます。

また細かい話しですが「それがいい」と「それでもいい」というのはニュアンスが微妙に異なります。顧客の思いを正確に汲み取るよう心掛けましょう。

ちなみに私は要件定義時に以下の内容を聞くように努めています。

  • 要望の背景(困っていること、理由)
  • 目的
  • コンセプト(あれば)
  • メリット(デメリット)
  • 費用対効果(最低限効果は聞く。費用はこの段階では分からないかも)
  • 今回のゴール
  • 今後の展開

特に背景と目的は重要だと思います。これらを聞くことにより、全く異なる視点のアイデアが浮かぶこともありますし、そのアイデアの有り無しの判断基準となり得るためです。これらはタイミングを逃すと今更感が出て聞きづらくなったりするので、システム開発の上流工程である要件定義でこそしっかり聞くようにしましょう。

顧客の考え方に沿うこと

システムは顧客の考え方に沿って作るべきです。

例として新商品販売に伴うシステム開発を挙げた場合、はじめに新旧商品で異なる部分を洗い出します。その際、新商品で何らかの機能を追加するとしたら、それは「新商品だから機能がある」と考えることもできますし、反対に「旧商品だから機能が無い」と考えることもできます。どちらと捉えるかによって作り方が変わってきますので、どちらがしっくりくるか、今後の展開(新商品2を売る場合など)も踏まえて明確に顧客に聞き、その考え方に沿うように作りましょう。

それにより、顧客にシステムの動きを予想してもらいやすくなりますし、想定外のケースが発生した場合に安全な方に倒れやすくなると思います。

その他、顧客と双方で考え方を合わせるため用語を統一するなど、基本的なことはやりましょう。

いつ、誰が、どういう考えで、何を言ったか

要件は結論だけでなく、結論に至るまでにいつ、誰が、どういう考えで、何を言ったかの経緯もしっかり記録しましょう。それにより、何か問題や懸念点が出てきた時、答えを持っている人は誰かが分かるようになります。

なお、言質をとって後から変えさせないというややネガティブな役目もありますが、時間が経てば考えが変わることもあるので、そこらへんは許容範囲内であれば取り入れましょう。

シンプルな提案、解決策であること

私はシステム開発側の立場で最も意識すべきは「保守性」だと考えています。その保守性を保つために、提案や解決策は極力シンプルにしましょう。

「シンプル」という言葉は人により解釈が異なると思いますが、私が考えるイメージは以下の通りです。

  • ムダに作らない
  • 分岐を作らない
  • 抽象的な考えでつくる

また、保守性のよさは開発量とトレードオフの関係にあります。

そもそもの課題解決の方向性として、システム化がベストとは限りません。運用で対処してもらったり、Excelなど別のツールをオススメすることもあります。顧客の真の要望を踏まえ、時には顧客にも協力(妥協)してもらいながら、不必要に保守性を下げないようにしましょう。

一度に複数聞かない

会話していると、ときどき論点が複数混じっていると感じる時があります。顧客側はどちらを回答すればいいか迷ってしまったり、罠をかけられている感じになったりしますので、論点は一度に一つずつにしましょう。

例などを交えながら一つずつ議論して、個々に解決策を検討していきます。もし煮詰まった場合は、一旦保留として誰がタマを持つかをしっかり決めた後、次の論点に移りましょう。その際は「○○は一旦終わりとして、次に△△に移りますが」みたく、次に移る旨をきちんと言ったほうが皆の頭を切り替えられるのでいいと思います。

また論点を分け、その後必要に応じてグルーピングしたりすれば、全体が整理されていくように感じています。

進め方は広く浅く、時間があるなら深く

要件定義は顧客要望を膨らませる工程であり、後続の設計工程以降は徐々に絞っていく工程だと考えています。

そして要件定義のゴールは「後続工程の見積が大きくブレなくなるまで」だと考えています。そのための進め方はまずは広く浅く、時間があるなら深くというのが効果的です。

概要を伝えたいときは絵を、比較したいときは表を活用し、順番も意識して進めましょう。絵を描くのが上手い人は全体を理解できている人だと思います。絵をうまく描けるようになりましょう。

【参考】要件定義書のフォーマット例

簡単ですが、Excelで要件定義書のフォーマット例を作ってみました。

f:id:akairopapa:20190114120556p:plain

ダウンロードはGitHubからどうぞ。

https://github.com/akairopapa/formats/raw/master/要件定義書フォーマット.xlsx

まとめ

いかがだったでしょうか?

少し前に顧客から「○○(私)さんは夢を売っている」というありがたい言葉をいただきました。ちょうど私が目指していたことなので、とても嬉しかったのを覚えています。

単に顧客の表面上の要望通りに作るのではなく、裏にある真の要望を捉えて作ればきっと満足いただけます。また例え顧客と異なる意見だったとしても、協力してよりいいものができれば一体感が生まれます。それを積み重ねて、少しずつ信頼を勝ち得ていきましょう。