企画工程、要件定義工程の記載方法
弊社では企画工程から参画することが多く、現在まで数多くのお客様からご依頼を頂いております。基本的な考え方やポイントについてご説明したいと思います。
目次
1.｜企画工程とは
1-1.｜システム企画の目的・概要を設定
1-2.｜開発スケジュールの設定
1-3.｜開発体制の検討
2.｜要件定義書とは
2-1.｜要件定義書の記載方法について
2-1-1｜.お客様の要求をヒアリングする
2-1-2.｜ヒアリング内容から、システムでの解決方法を検討する
2-2.｜要件定義書の成果物について
2-2-1.｜システム概要・背景・目的
2-2-2.｜システム導入後のメリット
2-2-3.｜システム機能
2-2-4.｜性能面を考慮
2-2-5.｜非機能要件を検討
3.｜抑えるべきポイント
3-1.｜既存システムを把握する
3-2.｜要件定義書を擦り合わせる
3-3.｜専門知識がなくても内容が理解できる
3-4.｜問題点の解決策が記載されている
4.｜まとめ
企画工程、要件定義工程の記載方法についてご説明
1.｜企画工程とは
システムの目的・概要の明確化、体制、開発期間、開発費用、リスクの調査分析、費用対効果を行う工程です。新規システム開発や既存システムの改修など問題点を調査・分析した内容を元にシステムの企画を行います。
主にお客様側にて実施されることが多いですが、昨今では、コンサルティング会社に依頼してお客様にプレゼンテーションをするケースが多いです。
1-1.｜システム企画の目的・概要を設定
システムを構築するにあたり、どのような業務上の課題を解決でき、コストメリットはどのような影響を与えるかを検討します。現状を調査・分析した上で目的・概要の設定を行います。
1-2.｜開発スケジュールの設定
開発スケジュールの設定を行います。システム稼働日を決定し、開発順序や移行予定日を考慮してスケジュールを落とし込みます。無理のないスケジュール設定をすることをお勧めします。
1-3.｜開発体制の検討
システムを構築する上で開発体制を検討します。企画工程の時点では、開発ベンダーが未確定の場合が多いため、同等の開発プロジェクトを見て、予算規模を把握します。また相場感を知っていれば、大きなブレは発生しません。
コンサルティング会社に依頼するか、開発ベンダーに依頼するかで、値段とアウトプットに大きな違いが発生しますので、開発規模を考慮した上で見積りを依頼しましょう。
2.｜要件定義書とは
要件定義書とは、システム開発時にお客様の要望を開発ベンダーがヒアリングし、要望を実現するための機能やイメージを文書にまとめたものです。
お客様と認識齟齬がない様に、システムの完成イメージをすり合わせることが重要です。ポイントは下記の通り。
・誰が見ても完成形のイメージが持てること。
・共通の認識が持てる資料になっていること。
要件定義書を元に、システムの基本設計書、詳細設計を進めるので、ポイントを抑えた内容でないと、開発ベンダーから質問攻めになりますので、何度も打合せを実施して内容を精査しましょう。
2-1.｜要件定義書の記載方法について
要件定義書に記載する前に実施する内容について記載します。
2-1-1｜.お客様の要求をヒアリングする
お客様が抱えている問題点をヒアリングすることから開始します。どのような解決策を望んでいるかを明確化します。ヒアリングする際に、明確化されていない場合が多いため、じっくりと話しを聞く事が大切です。システムリプレイスする場合は、現在使用されているシステムを理解することが一番の近道です。
2-1-2.｜ヒアリング内容から、システムでの解決方法を検討する
お客様からヒアリングした内容を細分化します。実現するためにはどうすれば良いかを検討します。実現する上で、問題点が発生する場合は、内容を明確化し代替案を検討して、お客様に相談しましょう。事前に社内での認識合わせを実施することをお勧めします。
2-2.｜要件定義書の成果物について
要件定義書の成果物について、具体的に何を記載するかをご説明します。
2-2-1.｜システム概要・背景・目的
システム導入する背景と理由を記載します。またシステム概要も記載します。記載することで認識齟齬が無くなり、全メンバーと共通認識を持つことで出来ます。
2-2-2.｜システム導入後のメリット
調査・分析結果を基に、システム導入後のメリットを具体的に記載します。
・**工程の一括処理が可能になり、その結果30％工数削減が見込める。※ヒアリング時の問題点１の解決案。
・全工程の連携処理が一括可能になり、その結果50％工数削減が見込める。※ヒアリング時の問題点２の解決案。
2-2-3.｜システム機能
システムの具体的な機能を画像を用いて詳細に記載します。仕様を明確化することで、お客様の理解が明確になりますし、追加要望があればこの時点で盛込みましょう。またシステム全体の流れを記載して、一連のイメージが分かる様にします。新システムのメリットが一目瞭然で分かるように記載するのがポイントです。
2-2-4.｜性能面を考慮
システムの処理速度、使いやすさの考慮、エラー時のメッセージ内容の表示等細かい気配りが必要になります。使用方法を最大限考慮して、誰でも簡単に使用できるように考慮しましょう。
2-2-5.｜非機能要件を検討
非機能要件とは、お客様が機能面以外で求める要件です。セキュリティーや保守・運用サービスについて記載します。要件定義の段階でヒアリングしますが、お客様側で検討していることが少ないため、機能要件が決定後にお客様からヒアリングして、詳細内容を詰めましょう。
3.｜抑えるべきポイント
弊社で要件定義工程時に抑えているポイントについて記載します。
3-1.｜既存システムを把握する
お客様の要望を確実に理解するには、既存システムの業務フローに課題があり、問題を解決したい場合が多いです。要件定義の段階での一番の近道は、既存システムを見せて頂き、理解することです。そのためには、保守担当者やシステム利用者からもヒアリングしましょう。
3-2.｜要件定義書を擦り合わせる
お客様を含めて要件定義書の認識を一致させます。ここで注意すべき点は、全員の認識を一致させることです。事前に社内で認識を合わせてからお客様と打合せを実施して下さい。
3-3.｜専門知識がなくても内容が理解できるように記載する
お客様に理解して頂くために、IT分野に関する専門用語や専門知識を極力使用しないようにして下さい。記載内容が理解して頂けず不信感に繋がる場合があるからです。誰が読んでも分かる文章になっているか注意しましょう。
3-4.｜問題点の解決策が記載されている
問題点に対する解決策を分かる様に記載しましょう。明確化することでお客様及びSEが正しく理解して初めて要件定義書が完成になります。
4.｜まとめ
要件定義書とはシステム開発時にお客様と認識を一致させるための書類です。開発前に要件定義書をまとめておきましょう。またお客様とのコミュニケーションが重要になりますので、早い段階で仲良くなることをお勧めします。
＃企画工程、要件定義工程の記載方法
