こんにちは。セルネッツの竹本です。
今回は「システム開発要件定義」というテーマで解説をしていきます。
業務システム開発とは、特定の開発言語に特化した内容ではありませんのでプログラムを勉強中のかたはぜひ最後までご覧ください。
システム要件定義ということで3つに分けて考えています。要求分析があって、その要求を定義して、それをシステムの要件に置き換えていく。この3つについて解説をしていきます。
要求分析に関しては「お客様からの要求要望を出していただいて分析していく」作業になります。要求要望の総点検のような感じです。
これがイメージですが、エクセル開発の場合は「特定の部門の特定の業務の生産性が非常に良くないので効率化を図りたい」というご相談からスタートすることが多いので、すべての部署にまたがっての開発ということはないです。
要求分析のポイントとしては、まずは要求要望をいったん箇条書きで洗い出していただくということです。
なぜそれが課題になっているのか、背景だったり、それを解決する意図・目的・狙い、期待成果を確認・整理していくような作業になります。
作業の中心はヒアリングになりますので、齟齬、理解誤りなどがないように全体図を作成して確認し合うことも必要になってきます。
この作業は打ち合わせを繰り返す必要があります。たとえばお客様とのヒアリングの中で現状をお聞きして「どんな要望があるのか、どういうゴールをイメージされているのか」の打ち合わせになります。この段階では、打ち合わせの参加者が増えてくると都度要件が増減変化することも少なくありません。
続いて洗い出した要望を整理する「要求定義」に入ります。
要求の一覧表を作っていくことに重きを置くので、この段階で実現可否はそれほど加味されません。
まず「困っていること」、「こういう要望」と出していただくところが中心になってきます。よっぽど非現実的なものに関してはここに上げていないですが、お客様の要望はいったん要求定義書に落とし込む必要があります。ちなみに社内の場合と社外の場合、内容は基本的には同じです。
ポイントはこの2つです。「なにを課題と感じているのか」と、「本質的になにが課題なのか」。この2つは相違するケースがあります。「課題を解決することで問題は解決するんですが、成果が少ないケース」が結構あるんです。「本質的な課題を解決する」という考え方になるので注意が必要になります。
要求定義でやることは、要望一覧に対して優先順位をつけていくことです。要求と要件（次の工程）を分けて考えるというのがこの工程を分けている理由です。要求に関しては要求要望としていったん出していただきます。
ここでシステム要件を定めることになります。システム目線でやるべきことの洗い出しをして、項目として立てていく作業になります。
いろいろな要望がありましたけれども、どの項目を「やる・やらない」、「できる・できない」、「どんな方法でやる・やらない」という落とし込みになっていきます。
これらを「仕様要件書」というドキュメントにして、明確に作業範囲を定めていく必要があります。
たとえば「利益検索機能」、「簡単に作成したい」だと、漠然としているところがありますね。「毎月の売上集計」、「顧客ごとの受注率」、「統計などを簡単に作成できるようにしたい」という要望があった場合は、「どういう作業であれば簡単」だとイメージしているのか具体化します。
たとえば「ボタンひとつで売上集計表ができるようにしたい」となると、「それに必要なマスターはあるんでしょうか？」「なければ作れるんでしょうか？」「商品マスターの点数だけで数万商品となると現実的には難しくありませんか？」など、要望をどういう方法で実現するかも含めて、「できる・できない」、「条件付きでできる」など、システム開発の実装要件レベルで定めていく必要があります。
のちに不具合が発生したときや、不具合と指摘をされたときに、仕様なのか不具合なのか、ソフトウェアの瑕疵欠陥なのかというところも関係してくるので、「作業範囲を明確にすること」と、「作業範囲の内容を細かく定めること」が必要になってきます。
この絵をご覧いただきたいです。
これはネットで探せば出てきますが、「顧客が本当に必要だったもの」ということで、1970年あたりにアメリカで書かれたシステム開発・プロジェクト進行の風刺画のようなものです。
簡単に説明をすると、左上の赤い部分が「Marketing Requested It」となっていますが、これが「お客様が説明したイメージ」です。対して右下が「お客様が本当に必要だったもの」です。
左上の説明を受けてセールス部門はこういう理解をしました、そしてエンジニアリングデザインではこんな理解をしましたということで、絵に描いてみると理解・解釈にちょっと差が出てきています。
お客様からいただいた説明からスタートして、「こういうふうにしてほしい」というようなリクエストがあれば、これを目指してやっていくわけです。
最終的にシステム開発はどこでトラブルが起きやすいのかというと、求めたものを忠実に作っても成果にならないと、「そうではなかった、これが正しかった」ということになります。スタート時点で「こういう方法論も思いつかなければ、こういう方法があるということも知らなければ、これで解決できるとも思っていないし、これで解決できるんじゃないか、だからこれを作ってくれませんか？」でスタートすることが非常に多いです。
それをヒアリングで聞いた側は、開発の立場と営業の立場では解釈、受け止め方が違ったりします。これはシステム開発に限らず伝言ゲーム的な、Aさんが言わんとしていることをBさんにもCさんにも正しく理解してもらうのはなかなか難しいものがあります。
どういうトラブルが想定されるかというと、「納品直前にイメージが全然違う」、「納入したものの成果が得られない」、「極めて成果が少ない」などは、トラブルになりやすいです。
ここをいかにすり合わせしながら進めていくか。要求分析、要求定義、要件定義でしっかり決めていく必要があります。
大切なのは、お客様が要望してきたことは「どんな問題課題を解決するためのシステムなのか」、その「目的を明確にする（成果を定義する）」ことです。成果が明確になっていれば、要望を聞いた時点で成果が得られる要望なのかどうかをシステムの見解・システムの見地から確認する作業ができます。ここが重要になります。
要件定義のまとめです。
プログラムでの自動化には、基本的には「規則・ルール・法則」があります。ここに乗らないものはプログラムではできません。
自動化できなければ運用でやるのですが、「運用を極めて少ない量にするようなところまでをシステムでやる」という考え方もあります。
留意点として2つ書いたのですが、
１．洗い出していただいた要望のすべてが実現できるとは限らない
２．いただいた要望のすべてを仮に実現できたとしても、求める成果が得られるかどうかは別問題
ということです。ここは注意しないといけないところです。
求める成果も先ほどの絵のように、10人いれば考え方が若干違っていたり、ブレだったりズレだったりするところがあるので、コミュニケーション能力が非常に求められるのが超上流の工程になってきます。
ここに書いてある通り、100の要望があっても3個は実現ができない。その理由として「理論上あるいは運用上、それからコストがかかりすぎる、スケジュールがかかりすぎる」というものがあったりするので、「そのうちの3つは次のステージに送り込みましょうとか、やめてしまいましょう」などと決めていくのが「要件定義」であり、書面化・ドキュメント化することで「要件定義書」というものになります。
「要件定義」は、システム開発の流れの中で超上流を占める部分であり、一番大事なところになります。
「要件定義書」があって設計に入っていきますが、設計段階で変わることも日常的にあります。「やっぱりあれをやめて、これができませんか」、「これを優先していただけませんか？」という、上流から下流に入ってなお要望が出てくることがあります。
これに関しては「現実的にできること・できないこと」をふまえ、「できることはやります、できないことは次に送りましょう、検討していきましょう」と進めていくことになります。
今回は要件定義の重要性について解説をさせていただきました。
解説は以上となります。
少しでも参考になったかたはぜひチャンネル登録・高評価をお願いします。
エクセル中心の業務の効率化だったり、システム導入についてお困りのかたは無料オンライン相談も受け付けています。
動画は毎週金曜日の夜9時に投稿しています。
ご視聴ありがとうございました。
タケモ塾では、今後も皆さんのVBA学習に役立つコンテンツを作成してまいります。
ブログ記事、Youtubeチャンネルのご質問・ご感想・ご要望などお気軽にお問合せください。
お問合せはこちらから ✉
タケモ塾運営：株式会社セルネッツ
