【企画職向け】システム開発の全工程をわかりやすく解説

初心者PM

そもそもシステムってどうやって作るられるの？

こんな悩みに答えます！

この記事を読むことで、システムが作られるまでの全体の流れと、その中で企画がどうやって動けばいいのかがわかります。これらを知ることで、思い通りのシステムを作るための企画をやりやすくなると思いますよ！

システム開発の全体像

まずは、システム開発ってそもそも何をやっているのか？について、概要を把握していきましょう。

システム開発とは何か？

システム開発とは、特定の目的を達成するためのコンピュータシステムを設計、構築、テスト、導入する一連のプロセスです。ポイントとしては、プログラミング以外にもたくさんやることがある、ということを覚えておきましょう。

システム開発でやることはこんな感じです。ちなみにどんなシステム開発でもこの工程をふみます。

このように、実際にシステムを直すとしてもたくさんの工程があります。特に、要件定義などの初期段階では、企画職が手を動かすことも多いです。

システムでできること

システム開発の経験がない企画の人向けですが、システムを使ってどんなことができるのか？をまとめますね。

まず、システムを使うということは、レバレッジをかけるということです。

例えば、メッセージのやり取り。従来は手紙や電話でした。でも、メールやチャットを使うことで、より便利に早く、広範囲にメッセージを届けることができます。これが、システムのレバレッジです。

他にもシステムを使うと次のようなことができます。

システム開発の工程の解説

では、実際にシステム開発をやるぞ！となったら、具体的にどんな工程があるのか？を説明していきます。

要件定義から設計まで

システム開発の初期段階で、上流工程とも呼ばれます。

まだプログラミングはしません。プログラミングする前に、何をどうやって作るのか？を詳細に決めます。特に要件定義はシステムの要件を決める段階で、企画もがっつり入り込むフェーズです。

要件定義

要件定義はシステム開発の最初の工程です。かつ、最重要な工程です。

ここでは、システムに何をさせたいのかを決めます。このフェーズは、システム開発の会社が行うのではなく、業務系の企画担当者と社内のIT企画担当者が協力して行います。

つまり、企画の皆さんが主役になる工程です。むしろ、この工程でしか意見を言うことはできません。繰り返しですが、超重要な工程です。

まず、要件定義といっても大きく2つに分けられます。

業務要件定義

業務要件定義では、業務観点でどんなことをやりたいのか？を定義します。

例えば、何かの承認業務であれば、承認作業をしたら自動でメールを飛ばしてほしい。のような感じです。ただし、やりたいこと（＝HOW）が先行しないように注意が必要です。

次のように、現状・課題分析を経てから、解決策としての要件を出すことが重要です。

業務要件定義で作成される業務要件定義書は以下から無料でダウンロードできます。まずは実物を見てみるとイメージもわくと思いますよ！

機能要件定義

機能要件定義では、システムの機能観点でどんなことをやりたいのか？を定義します。

先の例でいうと、業務的には承認作業をしたら自動でメールを飛ばしてほしい、でした。一方、機能要件定義では、Aシステムの承認機能について、承認ボタンを押した際にメールを自動で送信する、というように機能を主語にします。

機能要件定義をする前には、業務要件定義を行います。ですので、業務要件定義で定義したものを、システム観点で再定義するようなイメージです。

ちなみに、次に行う設計工程では、システムベンダーのエンジニアが、ここで作った機能要件定義書をもとにシステムを設計します。ですので、ベンダーのエンジニアに伝わるように、どの機能でどんなことをしたいのか、を具体的に記載する必要があります。

機能要件定義書のテンプレートは以下から無料でダウンロードできます。

設計

要件定義が完了したら、次は設計に進みます。

多くの場合、ここからはシステムベンダーのエンジニアに業務を委託して進めることになります。外部の会社に作業を委託するため、企画者がほぼ口を出せなくなります。

設計工程では、次のような作業を行います。

設計では、技術的な観点からシステムを詳細に決めていきます。ここで決めたとおりに、プログラムを組んでシステムを作っていくことになります。そのため、設計漏れがあると、機能自体が欠落してしまいます。

開発からテストまで

開発工程では、設計した内容に基づいてプログラミングしてシステムを作っていきます。でも実はプログラミングするだけでなく、ちゃんと動くかどうかのテストも同時にしています。

開発

いわゆるプログラミングをして、システムを作る工程です。システム開発というとこの工程をイメージする人も多いと思います。

具体的には以下のような作業を行います。

開発の段階になると、ほぼ企画者は手出しできなくなります。待つだけです。

テスト

開発が完了したら、次はテストをします。

このテスト工程が開発工程と同じくらい大変です。開発工程で行う単体テストも含めると、トータルで4段階くらいのテストを行います。

そして、テストの最終段階であるUAT（User Acceptance Test）では、企画者や現場のユーザが主体となってテストを行います。

企画職として覚えておきたいのは、システムの最終的な品質担保はユーザが行うということです。UATでは、企画やユーザがテストケースを考えて、自らテストをして品質を確認します。

リリースと保守

UATを経て品質に問題がないことを確認されたあと、リリースを行います。

ただし、システムはリリースして終わりではなく、そのあとも保守といって継続的なメンテナンスや監視を行います。使われ続ける限り、誰かが保守をし続けていることを覚えておきましょう。

リリース

リリース自体はシステムベンダーのほうで実施します。

一方、企画としては現場向けに広報を行ったり、必要に応じて説明会を実施します。システムをリリースしても使われなかったら意味がありません。そこで、企画が中心となって現場で使われるようにアクションすることが大事です。

保守

システムのリリース後は、保守に入ります。この段階では、継続的なシステムの運用とメンテナンス、追加開発を行います。

保守作業もシステムベンダーが対応します。ただし、より使いやすいシステムにしていくにはリリース後の追加開発が欠かせません。そのためにも現場からの声を拾い上げ、企画要件定義をして開発を進めることが企画には求められます。

企画職が知っておくべきポイント

システム開発プロジェクトにおいて、企画のみなさんが抑えておくべきポイントは大きく2つあります。

コミュニケーション

システム開発プロジェクトでは、多くのステークホルダーとのコミュニケーションが求められます。特に、システムベンダーのエンジニアといかに円滑にコミュニケーションをとれるかが、システムの品質に大きく影響します。

特に重要なコミュニケーションのポイントについて解説します。

要件定義でのコミュニケーション

• 明確な要件の共有: 原則として要件定義の段階でしか、企画の要望を伝えることができません。なので、要件定義工程で明確に要件を伝えきることが重要です。

• ステークホルダーとの連携: 要件を固めるにあたっては、システムのユーザー、開発者など関係者全員との連携が重要です。認識の相違を作らないコミュニケーションが大切です。

UATでのコミュニケーション

• UAT支援の依頼: UATは企画や現場のユーザが主体でやります。しかし、すべてをやりきるのは難しいので、必要に応じてエンジニアにも支援を求めましょう。

• 不具合の共有: UATで不具合が見つかったら、迅速に共有しましょう。不具合内容を可視化して、解決するまでウォッチすることが大切です。

プロジェクト管理

自分自身でプロジェクトマネージャーをやらないとしても、プロジェクト管理の視点を持ってプロジェクトに参加することが大事です。

わからないからといって、システム側のPMにすべてをゆだねると、多くの場合失敗してしまいます。抑えておくポイントは次の5つです。

企画はプロジェクトにおいて要件を出す側になることが多いです。そのため、その要件を確実に実現するためにもプロジェクト管理には目を光らせ、口を出していくことが大切です。

まとめ

システム開発プロジェクトは、多くの工程から成り立っていることが分かったと思います。企画のみなさんにとって重要なのは、プロジェクトの全体像を把握し、各段階での役割を知っておくことです。

特に、要件定義やUATでのコミュニケーションは、プロジェクトの成功にとって欠かせません。これらのポイントを意識し、柔軟に対応することで、システム開発プロジェクトを円滑に進め、高品質なシステムを実現することができます。

あわせて読みたい

【企画職向け】プロジェクトマネジメントの基礎知識と必要スキル

大和田 淳

プロジェクトマネージャー / ITコンサルタント

XContact

プロジェクトマネジメント経験10年以上。システム開発系のPMだけでなく、企画・BPRなどのPMも多数経験。SIer、外資コンサル、自営業、事業会社といろいろな環境でのプロジェクト経験がある。