エンジニア

システム開発における要件定義とは?要件定義書の中身や要件定義の進め方について

要件定義

 

こんにちは、古賀です!

今回は「要件定義」についてお話します!

 

要件定義は、

システムエンジニアの重要な仕事であり、

システム開発プロジェクトの出発点です!

 

ウォーターフォール型でプロジェクトを進めていくシステム開発は、

要件定義の出来によって、プロジェクトが成功するか、失敗で終わるかが決まります。

要件定義はそれくらい重要な工程になりますので、責任重大です!

 

本記事では、駆け出しシステムエンジニア向けに、

要件定義工程では、

「どのように打合せを進めるのか?」

「どのような成果物が必要なのか?」

などについて、お話していきたいと思います。

 

自己紹介が遅れましたが、

わたしは大学卒業後、上場IT企業に就職し、プログラマー、システムエンジニアとして

約10年間働いておりました。

プロフィールの詳細はこちらです。

要件定義とは?

V字モデル要件定義

要件定義の前に要件整理工程がある

要件定義工程の前に、「要件整理」という工程があります。

「要件整理」ではなく「要件分析」や「要求定義」と呼ばれることもあります。

 

要件整理では、お客さんの以下の内容についてヒアリングをしていきます。

「現在の業務内容及び業務フロー」

「現行システム」

「現在手作業だけどシステム化したい部分」

 

要件整理工程は、システムエンジニアが担当する場合もありますが、

「営業担当者」や「プロジェクトマネージャー(リーダー)」が担当することが一般的です。

 

要件整理の内容を踏まえて、

システムエンジニアが担当する要件定義へ移っていきます。

要件定義は何をする?

要件定義工程では、要件整理でヒアリングした結果から、

新システムでは、

「どの範囲をシステム化するのか?」

「要件に対して、システム上でどのように実現するか?」

「新しいシステムになった時の業務フローはどうするか?」

などを決めていきます。

 

お客さん側の担当者は、

「システム担当者」

「実際にシステムを使用する現場の代表者」

と打合せすることが多いです。

 

最終的に要件定義の成果物である

「要件定義書」

を作成し、お客さんへ提出します。

お客さんが要件定義書の内容を確認承認後に、

次の工程である「基本設計」へ移っていきます。

※要件定義レビューという打合せで、

要件定義書の内容を互いに確認して承認を得るやり方が一般的です。

要件定義の進め方!「フィット&ギャップ」で打合せを進める

企業や個人によって、打合せの進め方は異なると思いますが、

要件整理時に作成した「現行業務フロー」を基に、

新しいシステムでは「どのような画面」で、

「どのように使うか」を説明していきます。

 

パッケージシステムがある企業の場合は、実際にシステムを動かしながら、

スクラッチ開発の場合は、作成した資料ベースで打合せを進めていきます。

 

パッケージシステムを扱っている場合は、

「実際に行っている業務を新システムでも行えそうだ」

とお客さんが思うこともありますし、

「そのやり方だと実際の業務は難しい」

と思うこともあります。

 

このように実際の業務と新システムを照らし合わせて、

新システムで運用できるかできないか確認していく作業を、

「フィットアンドギャップ」

と言います。

 

「ギャップ」が発生した場合は、

別途「課題管理表」に転記しておき、

次回以降の打合せで別案を提案していきます。

 

パッケージシステムでの対応が難しい場合は、

「カスタマイズ」、「アドオン」での対応を提案していきます。

 

何度も打合せを繰り返していき、先程お話した、

「どの範囲をシステム化するのか?」

「要件に対して、システム上でどのように実現するか?」

「新しいシステムになった時の業務フローはどうするか?」

を確定させていきます。

要件定義の成果物!要件定義書とは?

要件定義は最終的に「要件定義書」を成果物として、お客さんに提出します。

企業によって提出物は異なりますが、わたしの経験上から回答させて頂きます!

システム導入の目的・ゴール

今回システム導入の目的、ゴールを明確化した内容の資料を作成しておきます。

システム全体図

システム全体図

新システムのシステム化範囲を把握するため、

新システムだけでなく、周辺システムを含めたシステムの全体図を作成します。

 

企業は様々なシステムを導入しています。

会計システムは既存のまま、販売システムを今回新システムへ入れ替え、

その販売システムは会計システムと連携する

という内容が分かる図を作成します。

新業務フロー

業務フロー

上記のような、新システム上での業務フローを作成します。

「誰が?」

「いつ?」

「何を?」

「どのプログラムで?」

などを、時系列で分かるように資料を作成していきます。

新システムで業務を行っていく上で、穴がないかを確認できる資料になっています。

使用予定プログラム一覧

新業務フロー上で登場してくるプログラムを、一覧にしてまとめておきます。

1つ1つのプログラムの詳細は「基本設計」で決めていきます。

詳細を決めていく際に、使用するプログラムが変更になったりする場合があるため、

現時点でのプログラム一覧になります。

 

パッケージシステムの導入であれば、

「どのプログラムに対して、カスタマイズを行うのか?」

「カスタマイズ内容は何なのか?」

についても記載をしておきます。

業務やプログラムの詳細資料

業務フローのみですと、言葉足らずな部分であったり、

表現不足で伝わらない部分が出てきます。

その表現が不足している部分を、別途詳細の資料を作成します。

非機能要件定義書

要件定義で決める内容は、システム上の話だけではありません。

システム外の要件のことを、「非機能要件」と呼びますが、

以下のようなことをまとめた資料を作成します。

  • テスト計画
  • データ移行計画
  • 操作説明会の日程・頻度・場所
  • 本稼働日程・計画

テスト計画

開発企業がプログラムのテストを行いますが、

最終的には、お客さんにもテストをしてもらいます。

お客さんが行うテストの内容の詳細も決めていく必要があります。

データ移行計画

新システムを業務で使っていくために、

現行システムから取引先のデータなど、必要なデータの移行をする必要があります。

 

データの移行の方法であったり、頻度、時期等を決めておく必要があります。

操作説明会の日程・頻度・場所

お客さんがテストを行う前に、新システムの操作説明会を行います。

以下のような、操作説明会の詳細を決めておきます。

「いつ行うか?」

「何回行うか?」

「どこでやるか?」

「スピーカーは開発企業?お客さん?」

本稼働日程・計画

プロジェクト開始当初で本稼働日は決めておきますが、

改めてその日程と事前準備について確認をしておきます。

特に決めておくべきことは、

「現行システム」と「新システム」の両方を使用して業務を行う「並行稼働」

を行うかどうか?とその並行稼働のやり方です。

 

並行稼働のどんな結果を受けて、

新システムのみで業務を行う

「本稼働」

へ移行するかが大事なポイントになります。

議事録

毎回の打合せ内容を記録した「議事録」も成果物の1つです。

基本設計以降の工程で、

要件定義時の打合せ内容を確認しておきたい場面も多々ありますので、

議事録も重要な成果物の1つです。

課題管理表

打合せの中で、日々発生する課題を1つの表にまとめておきます。

システム要件に関する課題もあれば、確認事項など様々です。

 

課題内容に対して

「開発企業側のボールなのか?」

「お客さん側のボールなのか?」

「期限はいつまでなのか?」

などを記載して基本設計以降の工程でも使用していきます。

まとめ

ここまでの話をまとめます。

まとめ

<要件定義とは>

要件整理した内容を基に、

「どの範囲をシステム化するのか?」

「要件に対して、システム上でどのように実現するか?」

「新しいシステムになった時の業務フローはどうするか?」

を決めていき、「要件定義書」を作成する。

<要件定義の進め方>

・現行業務フローを基に、新システムでの運用を提案していく

・パッケージシステムの導入であれば、実際にシステムを動かしながら説明する

・新システムで業務を行えるか?行えないか?「フィットアンドギャップ」を行う

<要件定義書の内容>

・システム導入の目的・ゴール

・システム全体図

・新業務フロー

・使用予定プログラム一覧

・業務やプログラムの詳細資料

・非機能要件定義書

・議事録

・課題管理表

 

わたしはプログラマー歴が長く、

要件定義に始めて参加したのは、入社して7年目あたりだったと思います。

 

先輩システムエンジニアがお客さんと打合せを進めていきますが、

始めは何を言っているのかさっぱりでした。。

 

打合せの移動時間で先輩に色々と確認をしたり、

質問したのをよく覚えています。

 

その後自分がメインに要件定義を進めるようになりましたが、

要件定義は全工程の中でも一番難しいと思います。

 

昨今はいかにカスタマイズを減らしていき、

システムの初期費用を抑えて、

パッケージシステムに実際の業務を合わせていくことがポイントになってきています。

 

お客さんの気持ちを最大限汲み取って、

システム化することだけでなく、

業績が良くなっていくような提案をしていかなくてはなりません。

 

そんなことができるようになれば、

「一流システムエンジニア」

の仲間入りです。

 

最初はできなくてもいいです。

わたしも全然できませんでした。

今も要件定義は完璧にこなせません(笑)

1歩1歩「一流」へ進んでいきましょう!

 

システムエンジニアの記事へ戻る

システムエンジニアとは?プログラマーとどう違う?SEの仕事内容を解説!

SIer業界の記事へ戻る

SIer業界ってどんな仕事?独立系SIer企業で働いた経験からお答えします!

おすすめ記事

道のり 1

※本記事は、各記事のまとめ記事です。   こんにちは、古賀です!   本記事では、 「プログラミング未経験者がエンジニアとして働き、 年収1000万に到達するまでの道のり」 をご説 ...

成長するエンジニア 2

  エンジニアになったけど、いまいち成長を感じられないなぁ。。 作業スピードも品質も平凡。 この先成長していけるんだろうか。。   こんにちは、古賀です!   エンジニア ...

闘病記 3

※本記事は、各記事のまとめ記事です。   こんにちは、古賀です!   わたしは25歳の時に、悪性リンパ腫になりました。 不安な気持ちになって、たくさん泣きました。 本気で「死ぬかも ...

プログラミングスクール 4

  プログラミングを本格的に勉強して仕事に繋げていきたいけど、 プログラミングスクール多すぎる。。 どういう目線で選べばいいんだ。。   こんにちは、古賀です。   プロ ...

-エンジニア
-, ,

Copyright© Koga Masao's LifeBlog 〜Alive Today〜 , 2020 All Rights Reserved.