こんにちは、古賀です！
今回は「要件定義」についてお話します！
要件定義は、
システムエンジニアの重要な仕事であり、
システム開発プロジェクトの出発点です！
ウォーターフォール型でプロジェクトを進めていくシステム開発は、
要件定義の出来によって、プロジェクトが成功するか、失敗で終わるかが決まります。
要件定義はそれくらい重要な工程になりますので、責任重大です！
本記事では、駆け出しシステムエンジニア向けに、
要件定義工程では、
「どのように打合せを進めるのか？」
「どのような成果物が必要なのか？」
などについて、お話していきたいと思います。
自己紹介が遅れましたが、
わたしは大学卒業後、上場IT企業に就職し、プログラマー、システムエンジニアとして
約１０年間働いておりました。
プロフィールの詳細はこちらです。
-
-
プロフィール
こんにちは、古賀正雄です。現在３６歳です。 簡単ではありますが、こちらのページで自己紹介とこのブログについてお話します。 高校時代 学生時代は主に野球をしていました。 進学先の高校も野球で選びました。 ...
続きを見る
※YouTubeで同内容を公開しております。
要件定義とは？
要件定義の前に要件整理工程がある
要件定義工程の前に、「要件整理」という工程があります。
「要件整理」ではなく「要件分析」や「要求定義」と呼ばれることもあります。
要件整理では、お客さんの以下の内容についてヒアリングをしていきます。
「現在の業務内容及び業務フロー」
「現行システム」
「現在手作業だけどシステム化したい部分」
要件整理工程は、システムエンジニアが担当する場合もありますが、
「営業担当者」や「プロジェクトマネージャー(リーダー)」が担当することが一般的です。
要件整理の内容を踏まえて、
システムエンジニアが担当する要件定義へ移っていきます。
要件定義は何をする？
要件定義工程では、要件整理でヒアリングした結果から、
新システムでは、
「どの範囲をシステム化するのか？」
「要件に対して、システム上でどのように実現するか？」
「新しいシステムになった時の業務フローはどうするか？」
などを決めていきます。
お客さん側の担当者は、
「システム担当者」
「実際にシステムを使用する現場の代表者」
と打合せすることが多いです。
最終的に要件定義の成果物である
「要件定義書」
を作成し、お客さんへ提出します。
お客さんが要件定義書の内容を確認承認後に、
次の工程である「基本設計」へ移っていきます。
※要件定義レビューという打合せで、
要件定義書の内容を互いに確認して承認を得るやり方が一般的です。
要件定義の進め方！「フィット＆ギャップ」で打合せを進める
企業や個人によって、打合せの進め方は異なると思いますが、
要件整理時に作成した「現行業務フロー」を基に、
新しいシステムでは「どのような画面」で、
「どのように使うか」を説明していきます。
パッケージシステムがある企業の場合は、実際にシステムを動かしながら、
スクラッチ開発の場合は、作成した資料ベースで打合せを進めていきます。
パッケージシステムを扱っている場合は、
「実際に行っている業務を新システムでも行えそうだ」
とお客さんが思うこともありますし、
「そのやり方だと実際の業務は難しい」
と思うこともあります。
このように実際の業務と新システムを照らし合わせて、
新システムで運用できるかできないか確認していく作業を、
「フィットアンドギャップ」
と言います。
「ギャップ」が発生した場合は、
別途「課題管理表」に転記しておき、
次回以降の打合せで別案を提案していきます。
パッケージシステムでの対応が難しい場合は、
「カスタマイズ」、「アドオン」での対応を提案していきます。
何度も打合せを繰り返していき、先程お話した、
「どの範囲をシステム化するのか？」
「要件に対して、システム上でどのように実現するか？」
「新しいシステムになった時の業務フローはどうするか？」
を確定させていきます。
要件定義の成果物！要件定義書とは？
要件定義は最終的に「要件定義書」を成果物として、お客さんに提出します。
企業によって提出物は異なりますが、わたしの経験上から回答させて頂きます！
システム導入の目的・ゴール
今回システム導入の目的、ゴールを明確化した内容の資料を作成しておきます。
システム全体図
新システムのシステム化範囲を把握するため、
新システムだけでなく、周辺システムを含めたシステムの全体図を作成します。
企業は様々なシステムを導入しています。
会計システムは既存のまま、販売システムを今回新システムへ入れ替え、
その販売システムは会計システムと連携する
という内容が分かる図を作成します。
新業務フロー
上記のような、新システム上での業務フローを作成します。
「誰が？」
「いつ？」
「何を？」
「どのプログラムで？」
などを、時系列で分かるように資料を作成していきます。
新システムで業務を行っていく上で、穴がないかを確認できる資料になっています。
使用予定プログラム一覧
新業務フロー上で登場してくるプログラムを、一覧にしてまとめておきます。
１つ１つのプログラムの詳細は「基本設計」で決めていきます。
詳細を決めていく際に、使用するプログラムが変更になったりする場合があるため、
現時点でのプログラム一覧になります。
パッケージシステムの導入であれば、
「どのプログラムに対して、カスタマイズを行うのか？」
「カスタマイズ内容は何なのか？」
についても記載をしておきます。
業務やプログラムの詳細資料
業務フローのみですと、言葉足らずな部分であったり、
表現不足で伝わらない部分が出てきます。
その表現が不足している部分を、別途詳細の資料を作成します。
非機能要件定義書
要件定義で決める内容は、システム上の話だけではありません。
システム外の要件のことを、「非機能要件」と呼びますが、
以下のようなことをまとめた資料を作成します。
- テスト計画
- データ移行計画
- 操作説明会の日程・頻度・場所
- 本稼働日程・計画
テスト計画
開発企業がプログラムのテストを行いますが、
最終的には、お客さんにもテストをしてもらいます。
お客さんが行うテストの内容の詳細も決めていく必要があります。
データ移行計画
新システムを業務で使っていくために、
現行システムから取引先のデータなど、必要なデータの移行をする必要があります。
データの移行の方法であったり、頻度、時期等を決めておく必要があります。
操作説明会の日程・頻度・場所
お客さんがテストを行う前に、新システムの操作説明会を行います。
以下のような、操作説明会の詳細を決めておきます。
「いつ行うか？」
「何回行うか？」
「どこでやるか？」
「スピーカーは開発企業？お客さん？」
本稼働日程・計画
プロジェクト開始当初で本稼働日は決めておきますが、
改めてその日程と事前準備について確認をしておきます。
特に決めておくべきことは、
「現行システム」と「新システム」の両方を使用して業務を行う「並行稼働」
を行うかどうか？とその並行稼働のやり方です。
並行稼働のどんな結果を受けて、
新システムのみで業務を行う
「本稼働」
へ移行するかが大事なポイントになります。
議事録
毎回の打合せ内容を記録した「議事録」も成果物の１つです。
基本設計以降の工程で、
要件定義時の打合せ内容を確認しておきたい場面も多々ありますので、
議事録も重要な成果物の１つです。
課題管理表
打合せの中で、日々発生する課題を１つの表にまとめておきます。
システム要件に関する課題もあれば、確認事項など様々です。
課題内容に対して
「開発企業側のボールなのか？」
「お客さん側のボールなのか？」
「期限はいつまでなのか？」
などを記載して基本設計以降の工程でも使用していきます。
まとめ：要件定義とは？
ここまでの話をまとめます。
まとめ
＜要件定義とは＞
要件整理した内容を基に、
「どの範囲をシステム化するのか？」
「要件に対して、システム上でどのように実現するか？」
「新しいシステムになった時の業務フローはどうするか？」
を決めていき、「要件定義書」を作成する。
＜要件定義の進め方＞
・現行業務フローを基に、新システムでの運用を提案していく
・パッケージシステムの導入であれば、実際にシステムを動かしながら説明する
・新システムで業務を行えるか？行えないか？「フィットアンドギャップ」を行う
＜要件定義書の内容＞
・システム導入の目的・ゴール
・システム全体図
・新業務フロー
・使用予定プログラム一覧
・業務やプログラムの詳細資料
・非機能要件定義書
・議事録
・課題管理表
わたしはプログラマー歴が長く、
要件定義に始めて参加したのは、入社して７年目あたりだったと思います。
先輩システムエンジニアがお客さんと打合せを進めていきますが、
始めは何を言っているのかさっぱりでした。。
打合せの移動時間で先輩に色々と確認をしたり、
質問したのをよく覚えています。
その後自分がメインに要件定義を進めるようになりましたが、
要件定義は全工程の中でも一番難しいと思います。
昨今はいかにカスタマイズを減らしていき、
システムの初期費用を抑えて、
パッケージシステムに実際の業務を合わせていくことがポイントになってきています。
お客さんの気持ちを最大限汲み取って、
システム化することだけでなく、
業績が良くなっていくような提案をしていかなくてはなりません。
そんなことができるようになれば、
「一流システムエンジニア」
の仲間入りです。
最初はできなくてもいいです。
わたしも全然できませんでした。
今も要件定義は完璧にこなせません(笑)
１歩１歩「一流」へ進んでいきましょう！
システムエンジニアの記事へ戻る
-
-
システムエンジニアとは？プログラマーとどう違う？ＳＥの仕事内容を解説！
IT業界で働こうと思ったけど、「システムエンジニア」ってどういう仕事なんだ？ 「プログラマー」とは違うのかな？ こんにちは、古賀です。 「システムエンジニア」って響きがいい ...
続きを見る
SIer業界の記事へ戻る
-
-
SIer業界ってどんな仕事？独立系SIer企業で働いた経験からお答えします！
IT業界に挑戦したいけど、その中のSIer業界ってどういうとこなんだろう？ 自分の能力に合っているかどうか、どんな仕事をしているか知りたい。。 IT業界と一口に言っても、そ ...
続きを見る
