システム開発工程ver2

皆さんは、システムエンジニアとしてどの工程を担当していますか？
上流工程を担当していますか？それとも下流工程を担当していますか？
 
フリーランスで働く以前に、システムエンジニアとして働く以上、システム開発工程を理解しておく必要があります。
 
そこで、シリーズ企画として、システム開発工程の概要から各工程の大切なこと、やっていく上でのコツをこのシリーズ企画でお届けできたらと思います。
 
今回はver2として、「上流工程」と「要件定義」についてお届けします。
 
ぜひ、上流工程や要件定義の仕事に従事されている方、上流工程や、要件定義の仕事をされたい方は、ぜひご覧ください。

まず、上流工程についてです。こちらの図をご覧ください。

これは、ウォーターフォールモデルと呼ばれるシステム開発の流れです。
この図の１～３の工程が上流工程と言われています。
まずは、上流工程について、振り返ってみましょう。

システム開発は、要件定義という工程から始まります。
システム開発を依頼する側と開発する側が打ち合わせを行い、システムの性能・機能や運用方法などの「要件」を決定します。
システム開発を依頼する際、希望の機能や性能があるかと思います。その要求と開発会社側の認識にズレがある場合、結果的に希望とは異なるシステムになる恐れがありますので、認識のすり合わせが非常に重要です。

外部設計の工程では、システム使用者(ユーザー)の視点からシステムに必要な機能を洗い出し、それを基に大枠となるシステム設計を行います。
その際システムの仕様などが記された基本設計書を、ユーザー側が確認するケースもあります。

次に外部設計で決定した事項を基に、コンピュータでの実装を想定した上で、より詳細にシステムを設計します。
外部設計がユーザー視点からの設計である一方で、内部設計の工程ではコードやプログラムの設計など、開発者側からの視点でシステムを設計します。

いかがでしょうか？
上流工程の主な作業としては、実際にシステムを使用されるユーザさんから、実現したい要望をお聞きし、実現方法の検討や、対応時期、対応工数などを調整するのが仕事になります。
また、実際にプログラミングを行うプログラマーに、プログラムを作るための設計書を作成し、説明する仕事もあります。
なので、上流工程は、実際にシステムを利用するユーザさんと、実際にシステムを開発するプログラマーの架け橋となる仕事であると私は思っています。

次に、システム開発の最上流である「要件定義」の仕事と、仕事を行う上でのコツを私の経験談からお話します。

要件定義は、開発工程の中で、一番ユーザさんと接する機会が多い工程のため、一日中、打ち合わせとなることが日常茶飯事です。
ユーザさんと打ち合わせを重ねながら、「要件定義書」と呼ばれる成果物を作成することがこの工程での主となる仕事になります。

この要件定義書がないと、ユーザさんがどのような目的でシステムを構築したいのか。や、どのようなシステムを作成したら良いのか。がわからなくなりますので、非常に重要な成果物です。

また、打ち合わせばかりのため、要件定義書を作成する時間をいかに確保するか。と、ユーザ要望をいかに具体的に聞けるか。がこの工程での一番大変な作業だと思います。

●コツ

私が思うこの要件定義を行う上でのコツですが、以下４点だと考えています。
　①システム改修の場合は、改修を行うシステムについて、概要を知る
　②新規システム構築の場合は、IT技術について、幅広い見解を身に付ける
　③要望を全て実現する目標ではなく、より良いシステムを構築する視点を持つ
　④後続工程（設計・開発・テストなど）のことも意識する。

システム改修の場合は、システム内の一機能の改修を行う要件定義が多いです。
そのため、改修を行う機能の知識がないと、どのように改修すればユーザ要望を満たせるのか。や、どのようにシステム改修すれば良いのか。を考えることができません。
ただ、機能の細部まで知る必要はなく、概要を抑えていれば要件定義としては考えることができるので、概要を知るだけで良いとも言えます。

新規システムの構築の場合は、元になるシステムがなく、ユーザ要望だけが存在する状態になります。
そのため、どのようなＩＴ技術を利用すれば、ユーザ要望を実現することができるのか。という考え方が非常に重要になってきます。

そのＩＴ技術の見解を持っていないと、ユーザ要望を実現する方法を考えることもできないため、幅広いＩＴ技術の知識が必要になります。

結構、システム利用されるユーザは、システム開発やＩＴ技術を知らない人が多く、システムでは実現が難しい要望を言ってくることがあります。
また、出てきた要望がちぐはぐになっていることや、単に実現すると矛盾点がが残ることもあります。

そのため、ユーザ要望を全て実現する。という考え方も大切ではあるものの、やはりシステム開発するプロである以上、より良いシステムを開発するために、矛盾を減らすことや、代替案を提示するなどの、ＮＯと言える、かつ 提案できる力と、ユーザ要望を具体的に聞く力が必要となります。

要件定義とは、開発工程の一番初めの工程です。そのため、要件定義の内容を元に、後続工程が進んでいきます。
そのため、後続工程をいかに効率よく作業させるか。や、後続工程の品質を向上させるか。などの考え方も重要になってきます。
この考え方を持ち合わせてないと、後続工程が進むにつれ、手戻りが発生することや、バグが多発するなどが多くありますので、単に要件定義を終わらせるという目線ではなく、開発工程全体を俯瞰した考え方が非常に重要です。

いかがでしたでしょうか？
こちらが上流工程と、要件定義の仕事となります。
プログラム開発とはまた違った視点や考え方が必要とされる工程になりますので、プログラミングをされている方からすると、難しく敬遠する方も居られるかもしれません。
ただ、今後のAIなどのIT技術の進展を考えると、上流工程になればなるほど、AIに代替される仕事ではないため、仕事がなくならない。と言えます。
今後もIT業界で仕事をされていきたい方はぜひ、一度興味を持っても良いかもしれません。