新規事業向けシステム開発の要件定義の極意 Part5【システム化の範囲を定める】〜【データ量を予測する】
新規事業を成功させるためには、ビジネスモデル、資金、リソースなど様々な要素が重要になりますが、昨今の事業ではシステム開発は欠かせないものとなっています。
システム開発で1番最初に行う要件定義は、非常に重要な工程です。システム開発の成否を決めるもの、つまり新規事業そのものの成否を決めると言っても過言ではありません。要件定義は通常、ITベンダー主導で行われるため、発注者は受け身となりがちですが、発注者は自身が主体性を持ちこの工程を牽引する心構えで臨んでください。
今回から数回に渡って、発注者視点で行う要件定義について詳しく解説します。
- 新規事業のためにシステム開発を行う
- システム開発で絶対に失敗したくない
- 発注者が要件定義の前に何をすべきかを知りたい
そんな方は、ぜひ最後までご覧ください!
新規事業向けシステム開発の要件定義の極意
Part1 【要件定義で行う作業の流れ】 ←今回はココ
Part2 【要件定義の重要性と、その具体的な準備方法】
Part3 【業務フローの作成】業務の洗い出しと業務プロセス
Part4 【業務フローの作成】業務フロー図の作成
Part5 【システム化の範囲を定める】〜【データ量を予測する】
Part6【事業展開に応じたシステムの拡張を検討する】〜【関係者で見直す】
Part7 【まとめ】
今回は要件定義で行う作業の流れについて解説します。まずは、この作業の全体感を把握してください。そして次回からは架空のシステム開発を例にしながら、今回の投稿を詳しく、具体的に解説します。
※このコラムの内容は動画で公開しています。Youtube版はこちらをご覧ください。
システム開発に入る前の前提
言うまでもなく、システム開発は目的ではなく、新規事業を成功させるための、いち手段に過ぎません。あくまでも目的は、新規事業の成功にあります。システム開発に入る前に、新規事業で必要とするシステムの企画ができてなければなりません。事業目的、市場、顧客層、提供価値、競合との差別化を、どうシステムへ反映するのかイメージできていることが前提です。
要件定義の準備
作成する対象が基幹システム、WEBシステム、スマホアプリであっても、システム開発をする際、一番最初に行う作業が要件定義です。
ITベンダーは「まず要件定義を行いますので、色々ヒアリングをさせてください。」と言う一言からシステム開発がスタートする、と思ってください。その時に、「はい、一体何をお話しすればいいのでしょう?」というのと、「何でも聞いてください。直ぐにお答えします。」という両者のスタンスでは、もちろん後者であってほしいのです。そのためには十分な準備が必要です。
要件定義の準備をしておくことによって以下の3つを実現できます。
- コストと時間の削減
- リスクの軽減
- 品質の向上
ITベンダーと同時にスタートラインにたち、ヒアリングで初めて要件定義に必要な要素を考え始め、関係者と調整し決断する。これが事前に終えているならば、コストと時間が削減できる理由は明白です。要件定義の過程において、あるいは開発が始まってからリスクが発覚して事業そのもの、あるいは一部を見直さなければならない。事前の準備で、そんなリスクも軽減されます。
要件が明確になっていることは、システムの品質向上に直結します。行き当たりばったりで考えると、追加要件が多発し、開発時の品質低下を招くのです。
では、要件定義の準備とは一体何をすればいいのかというと、以下の内容について準備をしておくことで要件定義がスムーズに進みます。
これらについては、次回以降で詳しく解説します。
要件定義で行うこと
新規事業向けシステム開発の要件定義で、発注者が行うこと。それは次の6つです。
①新規事業について熱く語る
②サービスを説明する
③業務フローを説明する
④プロトタイプを作ってもらう
⑤機能要件を定義する
⑥非機能要件を定義する
ひとつずつ説明していきます。
①新規事業について熱く語る
語ってください。新規事業に対する、熱い思いを。このシステムはどんな人が使うのか、このシステムによって、その人たちはどんな困りごとが解決されるのか、どんな社会的意義があるのか。
実際、それはシステムに直接関係するものではありません。しかし、開発するエンジニアも人間です。熱い思いがあるシステム。このシステムが世の中に貢献することは、ひいては「自分達もそこに関わっている」と感じることができれば、きっと大変なシステム開発においても真剣さが増すに違いありません。少なくとも私達はそうでした。
同じ仕事であっても、目的が共感できるものと、そうでないもので、仕事にかける意識が変わるのはシステム開発であっても同じです。ちなみに、要件定義に関する書籍やWEBの情報を見てもこんなことを書いているものは見たことがありません。
しかし、人間同士が仕事をするに当たって、互いの気持ちを高めることは大切なことだと思いませんか?
②サービスを説明する
どんなサービスを提供するのか。例えば音楽配信サービスであれば、
- 会員制で60日間は無料で利用できる
- 会員登録ではクレジットカードの登録を必須とし、60日間が経過する前に解約しないと、自動的に有料会員になる
- その後、毎月30日に課金される
- 会員の種別には一般会員、ファミリー会員があり、一般会員は1つのアカウント限定、ファミリー会員はアカウントを4つまで登録できる
- 利用料はそれぞれ月額300円、900円
以上のように、準備で具現化したサービス内容を説明します。
③業務フローを説明する
この事業を行うためにはどのような業務が存在し、どんな役割の人がどう業務を進めるのか、という業務の流れを説明してください。通常時の業務の流れ、そしてイレギュラーな事象が起こった場合にどうするかも説明します。
④機能要件を定義する
準備段階で機能は考えてあります。ならば、それを提示すれば終了かというと、そうではありません。あえて機能を事前に準備したのは、要件定義においてシステムエンジニアの視点から機能の実現可否の指摘や、機能の良し悪しなどの意見交換をするためです。
まったく同じ機能でないにしても、システムエンジニアは類似機能の開発経験があるはずです。その経験を元にして、「その機能は実現できるがコストがかかり過ぎるので、このようにしてはどうか」「こんな機能が必要ではないか」「その機能はなくてもこのように代替できるはず」などの議論ができるのです。
⑤プロトタイプを作ってもらう
準備段階でサービスの利用者を決め、デザインイメージも決まっているので、それを伝えて各機能のプロトタイプを作成してもらいます。機能要件では、文章やパワーポイントに描いた図などで定義されますので、実際にパソコンやスマホで見た時に、デザインや操作性がイメージ通りかを確認します。
プロトタイプは実際に簡単なプログラムを組んで動かすこともありますが、多くはプロトタイピングツールを用いて作成されることが多いです。そのため、この段階での修正コストは小さいので、イメージ通りになるよう徹底的に追及してください。
設計・プログラミングが始まってから、最悪完成してから「イメージと違う」となった場合、修正コストはかなり膨らみますし、修正内容によってはスケジュールの遅延やプログラム品質を低下させます。
プロトタイピングを行っているにも関わらず、完成した時にイメージと違うということが多々あるのはリアルですが、その違いを最小限にするため、この作業には真剣に取り組んでください。
⑥非機能要件を定義する
非機能要件では、パフォーマンス・可用性・スケーラビリティ・セキュリティ・データ移行などを定義します。聞き慣れない言葉も出てきているかと思いますが、準備した以下の内容を説明することで、システムエンジニアが一緒に定義してくれます。
パフォーマンス・可用性については、サービス内容、サービスの利用者と行動パターン、管理機能の利用者と利用タイミングから定義。
スケーラビリティについては、データ量の予測・事業展開に応じたシステムの拡張から定義。
データ移行については、手元のデータの活かし方から定義することができます。
いずれも過不足がある可能性はありますが、全てにおいて要件定義の準備で大部分はカバーできていますので、非機能要件の定義もスムーズに進むことは間違いありません。
まとめ
今回は要件定義で行う作業の流れについて解説しました。
①新規事業について熱く語る
②サービスを説明する
③業務フローを説明する
④プロトタイプを作ってもらう
⑤機能要件を定義する
⑥非機能要件を定義する
「新規事業について熱く語る」については、私見ではありながら、経験上必要なことであると改めてお伝えしておきます。
次回以降は架空のシステム開発を例にしながら、今回の投稿を詳しく具体的に解説しますので、これから新規事業でシステム開発を行う予定の方には特にご覧頂きたいと思います。