要件定義ってなにすればいいの？
コミュニケーション能力って、何ができればいいの？
この記事では、システムエンジニアの仕事の一つ、
「要件定義」に特化した、必要なスキルや仕事の流れをご紹介します。
そもそもこの「要件定義」という言葉に拒否反応さえ起こしそうですが、
順を追って説明しますので習得しちゃいましょう♪
「要件定義」は英語で “Requirements Definition” と呼ばれます。
よく “RD” と略されますので知っておくと便利です。
早速、本題に入りましょう！
要件定義で意識すべきポイント：２つ
まず要件定義のポイントを整理しておきます。
言葉をバラしちゃいましょう。
・要件：お客さんの要望を具体的に聞く（理解する）
・定義：要望をどのように叶えるかを整理する
ざっくり言うとこの2点だけです。
システム開発は、伝言ゲームのような一面があり、
「要望したものと、出来上がったものが違うものだった」
なんてことが多々あります。
この最初と最後の差を限りなくなくすために、
要件定義という工程が存在するのです。
従って、ここを疎かにすると、
お客さんが思ってもいないシステムを作ってしまうことになります。
とても重要な工程なので、
この記事でしっかりインプットして、実際の仕事に役立ててください♪
要件定義・・・お客さんの要望を聞き、それを整理するフェーズ。
要件定義に必要なスキル：【理解 ✕ 整理 ✕ 確認】
要件定義をする上で、どんなスキルが必要なのかをご紹介します。
・お客さんの要望を理解できる
・お客さんの要望を整理できる（表、分析、図解）
・お客さんの要望と自分の理解が正しいか確認できる（資料説明、質疑応答）
お客さんが言うことを理解できる
「理解する」ことの意味
お客さんが日々、いろいろな業務を行っていて、
その中で課題や改善したいことがあるからシステム化を行います。
この業務内容や流れが分からないと、システムエンジニアは何を作ればいいのかもわかりませんよね。
ここで理解すべきポイントは「業務フロー」です。
フローは「流れ」という意味の英語なので、どのような流れで業務をしているのか。
これを理解することが大切です。
コミュニケーションを通して業務フローを整理しましょう。
わからないものは調べたり、直接聞いたりして全体像と、今回システム化するポイントを明確に理解する。
これが「理解する」という意味です。
①業務の全体的な流れを図解する
→実際の業務とその順番、登場人物、時間軸を明確にする
②今回システム化するポイントを明確にする
③これらの内容が正しいことをお客さんに確認する
システム開発を行う上で大切なのは、
お客さんのお仕事（業務フロー）を理解することです。
実はこの業務フロー、
理解しないまま進める人が少なくないです。
ということは、理解できていると希少性が高くなり自然と重宝されます。
案件を通して理解する、でも遅くないので、
業務内容を理解する姿勢を持っておきましょう。
なぜ業務内容の理解が必要なのか
例えば、BinanceやCoincheckといった、
有名な仮想通貨の取引所があります。
この取引所で利用されているような、
「仮想通貨を売買できる取引システム」を開発するとします。
そこで、
お客さんとの会議中にこんなことを言われました。
仮想通貨を売買する時に、
「指値注文」をする機能が必要なんだよね。
「指値注文」というワードができてきました。
仮想通貨の取引をしたことがある人であれば、
「価格をあらかじめ指定して売買する機能ね！」と分かりますが、
指値？注文？という言葉が分からない人にとっては、
専門用語がわからず理解に苦しむ場面が多々あります。
では、分からないときどうすれば良いのか。
これは単純に質問することが近道です。
聞き方にもいろいろありますが、オススメがこちらです。
「不勉強で申し訳ございませんが・・・」
＋
「・・・という理解で正しいでしょうか」
本来知っておくべき内容の場合、
先に不勉強だと謳うこと、
自分の理解、想定を提示することがポイントになります。
お客さんが言うことを「うんうん」と頷くだけでなく、
分からないこと、理解が怪しいところは質問をしながら
コミュニケーションを取り、理解を深めることが大切です。
これが「お客さんの言うことが理解できる」というスキルになります。
この例では、個人で仮想通貨の売買をしている方は、
お客さんが担当している業務内容を把握しているため大きな武器になりますね。
ちなみに知ったかぶりをすると、
知っている前提で事が運ぶので、絶対にやってはいけないことです。
（私はこれをして、本当に苦労しました・・・）
ただし、むやみに聞きすぎても印象が悪いです。
お客さんは、その道のプロに仕事を任せる上で、
知ってて当然というスタンスで依頼をしているためです。
我々システムエンジニアはプロです。
まずは社内の人に聞く、自分で調べるといった意識は大前提です。
知ったかぶりは絶対ダメ！分からないことや心配なことは確実に仕留めること！
お客さんが言うことを整理できる（表、分析、図解）
ここでのポイントは、情報の整理です。
要件定義では、
お客さんの要望を資料に落とし込む必要があります。
情報量が多くなるため、表や図解を用いて作成しましょう。
昔のシステム開発は、要件定義書という形で、
よくわからない文章がズラズラ書かれていることが多いです。
読んでも分からないものは、曖昧な解釈になり危険！
なので視覚的にも分かりやすく表や図解をオススメします！
自分しか理解できない文書は、
後で他の人が読んだ時に理解しづらいのでNGです。
人に依存しない様なシンプルな作りを心がけること。
1つの課題に対して
パワーポイント1〜２枚くらいの目安で整理すると、
シンプルかつわかりやすい資料が出来上がります。
図解の例として、
この記事を１枚のスライドで表現するとこんな感じです。
こんな感じでざっくりと要点を整理。
細かい内容は質問を一覧化したものを用意すると
より深い議論ができるようになります。
・要件定義での情報整理は必須。ブレないように、しっかりと整理して文書化しよう！
・資料はなるべくシンプルに。複雑なものはマトリクスや図解を活用して整理する。
お客さんの要望と自分の理解が正しいか確認できる
要望をヒアリングして得た情報は、なるべく早めに文書化します。
難しい内容の場合、一回聞いただけでは理解しきれていなかったり、
情報が多いと漏れていたりすることが結構あります。
そのため、理解が怪しいものは
お客さんに確認をすることをオススメします。
情報の整理結果だけでなく、
お客さんへ確認するきっかけはもう１つあります。
・これまでヒアリングした情報が正しいか確認したい時
・検討の中で発生した課題の解決方法の合意を取りたい時
情報を整理していると、内容の矛盾だったり、
このままだと実現できないといった問題に直面することがよくあります。
この問題は一般的に「課題」と呼ばれます。
要件定義では、この課題解決を行うためのスキルが必要なのです。
これが、「確認できるスキル」です。
ではどんな時にこの課題が発生するのか。
一般的なシステム開発において、
システム化する上で、実現できないことってほとんどありません。
けど、すごい複雑な作りになって処理が重くなったり、
予定していた開発の時間が間に合わなくなったりします。
なので、ある程度の妥協だったり、
部分的なシステム化という手段を取り、
お客さんにこれでも問題ないかという合意が必要になります。
当初の想定システムと、実際のシステムとのギャップに整理し、
これをお客さんと合意することが、確認するスキルの全貌です。
・作成した資料を使って、お客さんに丁寧に説明しよう！
・この説明でOKなら、それは仕様として「合意」という意味！
実際に要件定義をしてみると・・・
要件定義は、
【理解 ✕ 整理 ✕ 確認】の繰り返しを行うことでクリアできます。
何となくイメージは湧いたかと思いますが、
実際に要件定義をしてみると課題にぶち当たります。
それは、お客さんが言うこと（要望）は変わることです。
検討が進むにつれてほぼ確実に変わります。
「あのときこう言ったじゃん！」
「そこまで深く言ってなかったよ！」
こういったことは、システム開発においては
日常茶飯事だということを認識しましょう。
そこで、議事録が役に立ちます。
お客さんと会話した内容は議事録として文書で保管＆共有しましょう。
認識齟齬が発生した時や、
どう結論付けたかを忘れた時などに利用します。
何か変更が発生したとき、過去のやり取りから
どのように変わったのかを明確にすることが可能です。
議事録は面倒なタスクですが、
いざという時に効果を発揮します！
実際に問題が起きた時に備えて、正確かつスムーズに対応できるようにしましょう！
・課題は絶対発生するので、あらかじめ準備をしておくこと！
・文書で共有できていれば、それが証拠（エビデンス）となる！
まとめ
要件定義で実施すること、必要なスキルは以上です。
【理解 ✕ 整理 ✕ 確認】の繰り返しを意識して取り組みましょう。
よく「コミュニケーション能力」が必要と言われますが、
突き詰めるとこの3つが主な内容となります。
次は具体的に定義するものをご説明します！
別記事にて説明しますので、そちらをご参照ください。（近日公開予定）
↓日本ブログ村に登録しております。よければクリックをお願いします！！
コメント