業務アプリ開発　はじまりから運用までの１６ステップ～ indexはこちら

アプリというと、BtoC、つまり一般ユーザが利用するゲームやSNSなどのアプリを想像するかもしれませんが、今回は、業務系アプリを開発する場合、かつ開発を外部委託する場合を前提として説明しています。

今回は、8番目のステップ「要件定義」です。

8.要件定義

要件定義については私も何度か説明しましたのでこちらも合わせてご覧ください。
（参考）

要件定義とは？
『要件定義』ではどこまで「定義」するのか？
要件定義の漏れはなくならない
当社が要件定義でフェイス・トゥ・フェイスにこだわる３つの理由

 

要件定義をネットで検索してみると以下のようなことが書かれていました。

・要件定義は、発注者の要件をヒアリングすること。

・発注者がシステムに期待する要件をまとめること

・要件定義 とは、ソフトウェアの開発において、実装すべき機能や満たすべき性能などを明確にしていく作業のこと

・どのくらいの規模のどんなシステムにするか、どういった業務行程を実現するか、どのくらいの予算をかけるか具体的に決めることが、要件定義。

・要件定義とは、情報システムやソフトウェアについて顧客が望んでいる機能や仕様などの概略をまとめること。

何れもその通りであり、単純に言うと、発注者のやりたいことをまとめる作業です。

しかし、それにも関わらず、上手くいかないことが多々あります。私は要件定義はアプリ・システム開発工程で最も難しい作業だと断言しています。上手くいかない場合、主に以下の３つのケースが考えられます。

■やりたいことが分かっていないケース

要件定義は、要件（＝やりたいこと）を確認していく作業ですが、アプリ開発会社が、色々と質問を投げかけても、明確な回答が返ってこないことがあります。あるいは、前回決めたことが1週間後の打ち合わせで、やっぱり違うとひっくり返してしまうのです。

アプリ開発会社がいくら、機能を詰めていこうとしても、業務自体を決められないとなると機能に落とし込むことができません。

一度決めたことを変更するのもいいと思います。時間をおいて考え直すことも大切なことです。しかし、それが変更して確定ではなく、また次週、その次にもひっくり返してしまう。最終判断ができないのです。

これらの場合、共通して言えることは明確であり、このシリーズの最初に記載した課題・問題を洗い出す、アプリ開発の目的を決める、
アプリを企画するという段階がすっぽりと抜け落ちているからなのです。

検討が漏れていて、要件定義フェーズで検討するということはありますが、核となる企画がない限り、判断基準が見つからないのは当然とも言えます。

こんな場合は、今一度、何が問題であり、課題だったのかに立ち戻ることが、最終的には早道です。

 

これは、発注者側の責任による場合ですが、開発会社側が課題・問題から見直しをしましょうと引っ張っていくこともできないことはないです。

このケースの責任分担としては

責任分担としては

発注者　９：１　開発会社

くらいなものです。

 

■やりたいことを引き出せないケース

「要件定義は、発注者の要件をヒアリングすること」とあったように、ヒアリングするのは正しいのですが、発注者の皆さま全てが雄弁だとは限りません。ヒアリングを、「相手のお話しを耳をすませて聞くこと」だと勘違いしているエンジニアは少なくありません。

その昔、サラリーマン時代。プログラマーから、SEになる過程のなかで、プログラミング教育は数ヶ月かけて行われましたが、ヒアリングスキルを磨く教育というのはありませんでした。

相手から話を聞く、聞いた内容から話を広げ、さらに深く聞く。そこに提案を振り、選択肢を提示し、決断してもらうというのは経験なくしてできないことです。

それでも、要件定義はヒアリングするものだとされているので、聞いているのになんででてこない。という発想になるのです。

このケースの責任分担としては

発注者　４：６　開発会社

くらいなものです。

 

■やりたいことの整理ができないケース

前述までと違い、発注者側がやりたいことがたっぷりある場合、また担当者が複数いる場合に起こることが、あれもこれも機能に入れたい、セキュリティは最大限に高く、サイトは絶対に落ちてはならない。と、要件が盛りだくさんの場合に整理がしきれなくなることがあります。

シンプルに言うならば、要件に優先順位をつけて、残す要件、落とす要件を決めればいいだけなのですが、こちらを落とすと重要な要件に支障をきたすなど、実際は要件が絡みあっていることが少なくありません。

そこを予算や期日、そして何よりもアプリ開発の目的に照らし合わせて大胆に判断しないことには、これまた進まないプロジェクトとなってしまします。この場合は、開発会社がリーダーシップを取り、発注者に対してAかBかを決められるような提案を繰り返し進めていくのがベストです。

このケースの責任分担としては

発注者　２：８　開発会社

くらいのものです。

 

要件定義は大切な作業であるがゆえに、表現を変えたり、事例を添えたりし、何度も取り上げていくつもりです。また、本ブログ以外では、IPA（情報処理推進機構）のサイトにある
「システム構築の要件定義に役立つポイント集を公開
～家づくりを例に、要求を明確にする勘どころ概説～」が、読み物として分かりやすくまっているのでご覧ください。

---

スマホアプリを使った業務システム構築のことなら

株式会社クラボードへお気軽にご相談ください

お問い合わせはこちら

---