Web制作やWebシステム開発において、制作フローを把握しておくことは、スムーズにプロジェクトを進行する上でとても重要です。

ここでは、システム開発を行うベンダー企業側のプロジェクトマネージャーが把握しておきたい流れについて、簡単にまとめました。

言葉の定義

ユーザー企業：システム開発を依頼する側の企業（発注側）
ベンダー企業：開発会社（受注側）

1. 企画

プロジェクトの意図や必要性を検討する段階です。
経営者や上層部から支持を受けた、ユーザ企業の担当者が内容を取りまとめることが多いでしょう。

2. ベンダーの調査

ユーザー企業の担当者が、自社のプロジェクトに適したベンダー企業の調査を行います。
最も手軽な方法はネット検索ですが、IT関連の展示会や、取引先や社内メンバーからの紹介をされるケースもあります。

3. 概算見積り、提案

ユーザ企業がベンダー企業に見積りを取り、ざっくりとした費用感やスケジュールを確認する段階です。
大抵は複数社に相見積りをとり、提案内容や費用などの比較検討を行う形になります。

尚、この段階では詳細な仕様が決まっていないため、あくまでも概算見積りとなります。

多くの企業ではこのタイミングで予算取りされる

しかし、私の経験上ほとんどのユーザー企業ではこのタイミングで予算取りが行われ、後々の追加予算が出ないケースが多いです。
そのため、ベンダー企業側はバッファを含んだ見積りを提出する必要があります。

（とはいえ、あまりバッファを考慮しすぎると他社との差が開きすぎて不利になるため、バランスが大切です…）

ユーザー企業の担当者は、ベンダー企業に対し「どの程度のバッファを含んでいるか」を確認しておくと良いでしょう。

4. 契約

提案内容・概算見積りをもとに、ユーザー企業がベンダー企業を選定し契約を行います。

契約形態は、委託契約か準委任契約になることが多いでしょう。
また、要件定義フェーズは準委任契約、開発フェーズは委託契約というようなケースもあります。

5. プロジェクト計画

契約が締結されてプロジェクトがスタートしたら、プロジェクト計画に入ります。

プロジェクト計画では、プロジェクトの目的、目標、リスク、基本的な進め方などを共有し、関係者と合意をとります。

全体像や前提の共有ができていないままプロジェクトが走り出すと、後々トラブルにつながるケースが多いため、しっかり取り組みたいところですが、要点を押さえて迅速に行うことが重要です。

プロジェクト計画の主なポイントとしては、
ヒアリング、チーム構成、チームビルディング、アサイン、目的の定義、QCD（クオリティ、コスト、デリバリー）優先度の決定、会議体や意思決定フローの定義、契約形態、マイルストーンの設定、情報共有の方法を決める、などがあります。
※詳細は長くなるので、ここでは端的にワードのみに留めます

6. 要件定義

要件定義とは、そのプロジェクトで実現すべきことを決めるプロセスのことです。

要件定義はシステム開発において最も重要とされており、要件定義がうまくいかないと、そのプロジェクトが失敗する可能性が高まります。
そのため、慎重に行う必要があります。

要求と要件

要件定義を行う上で大切なのは、「要求」と「要件」の違いを認識しておくことです。

要求 ＝ 実現したいこと
要件 ＝ 実現すべきこと

言葉は似ていますが、それぞれの意味は大きく異なります。

「要求」を「要件」に落とし込まないままプロジェクトを進めてしまうと、本来必要のなかった機能を実装してしまったり、認識のズレが起こりやすくなります。

そのため、要求と要件はしっかりと切り分ける必要があります。

ビジネス要件とシステム要件

また、要件定義は大きく分けると「ビジネス要件」と「システム要件」に分かれます。

ざっくりお伝えすると
ビジネス要件 ＝ どんな目的を達成したいのか
システム要件 ＝ どんなものを作るのか
です。

プロジェクトが始まると、リリースまでは時間との勝負です。

そのため、できるだけ早く実装に入りたいと言う気持ちが先行し、
「システム要件」を詰めることに意識が向きがちです。

しかし、そもそもどんな目的を達成したいのか？という「ビジネス要件」が明確になっていないと判断基準が曖昧になり、多額の投資をしたは良いものの結局使い物にならなかった、ということになりかねません。

プロジェクトの成功のためには、両方を重視して要件定義を行う必要があります。

7. 詳細見積り

要件定義の完了とほぼ同時に、詳細見積りを提出します。

詳細見積りは概算見積りよりも精度の高い見積りです。
Excelなどで項目・詳細・金額が記載された表形式のものを提出するケースが多いでしょう。

情報量も多いので、このタイミングでステークホルダーを集めて説明の機会を設けるケースも多いでしょう。

8. デザイン

デザインフェーズでは、デザイナーが具体的なシステムの見た目や、エンドユーザーがアクションを実行した時や画面遷移時の動き（アニメーションやモーション）などをデザインしていきます。

要素や画面構成は要件定義フェーズで、ワイヤフレームを作成されており、それをベースにデザインを作成することが多いでしょう。

UXデザインとUIデザイン

昨今は見た目のかっこよさ・綺麗さだけではなく、より良いユーザー体験を作るためにUXデザイン（とUIデザイン）に重きを置く企業も増えています。

そのため、プロジェクトによってはユーザーインタビュー・カスタマジャーニーマップ・ユーザーストリーマッピングの作成などを行い、その結果をもとにデザインを行うこともあります。

プロトタイピング

また、不特定多数のユーザーが利用するサービスでは、部分的にプロトタイピングを活用することで、効率的にデザインのフィードバックを行うことが可能です。

プロトタイピングは、文字では想像しにくい機能や動きを直感的に理解することができるため、システム開発に慣れていないユーザー企業と円滑なコミュニケーションを行う上で有効です。

ただし、プロトタイピングは工数がかかるものとなるため、なんでもかんでもプロトタイピングを行ってしまったり、細かいレベルまで作り込もうとしてしまうとコストを圧迫しかねません。

そのため、特に関係者間で合意を得ておきたいメインの画面や重要な機能などに的を絞って行うと良いでしょう。

また、プロトタイピングは、リリース後の改善に利用することも有効です。
（どちらかといえば、新規開発でプロトタイピングを行うことは手間やコスト的な面で採用されるケースが少なく、既存サービスの改善に利用されることの方が多いと思われます）

9. 設計

各機能を実装するためのロジックや詳細条件を定義して設計を行います。

設計は、要件定義とデザインフェーズで決まった内容を「どうやって実現するか」を固めていくプロセスです。

設計書を作成する前段階

設計書を書き始める前に、技術スタック（プログラミング言語、OS、ミドルウェア、フレームワークなどの使用する技術の組み合わせ）を決めたり、使用ツールやコードの管理方法、設計書の精度を決めたりします。

これらは要件定義と同時進行で行われるケースが多いでしょう。

設計書の作成

次に設計書の作成に入ります。

設計書は全てを完璧にやろうとすると、かなりの工数がかかります。

どこまで設計の工数をかけるかはプロジェクトの予算や工数などで変わってきます。

後から変えることが難しい処理、データベース、フローなどの基本設計が疎かだと、後から機能を追加したり修正する際に不必要な手間がかかってしまう可能性があるので、機能追加や変更を考慮した中長期的な視点で設計することが望ましいです。

設計書の作成が終わったらレビューを行います。
要件定義で決定した仕様が正しく定義されているか、各設計の整合性は取れているかなどを確認します。

10. 実装

設計まで完了したら、実際にコードを書いて実装に入ります。

実装に関しては、
表側（ユーザーが直接触れたり目にする部分）は、Webデザイナー・コーダー・フロントエンドエンジニア、裏側（データベースやプログラム処理など）はバックエンド領域のエンジニアが担当するなど、それぞれの得意分野ごとに分業して行います。

11. テスト

実装が完了したらテストに入ります。

テストでは、仕様が正しく実装されているか、できるはずのことができるか、できないはずのことができてしまわないか、セキュリティ上の問題がないか、などを確認します。

テストは付加価値を生まない作業でありながら、多くの工数を消費するため、軽視されたり削られがちです。

しかし、テストを軽視しすぎるとユーザー企業やベンダー企業のみならず、そのサービスを利用しているユーザーにも多大な損害を与える可能性があります。

特に、問い合わせフォーム・商品購入や決済周り・個人情報漏洩についてはしっかりテストを行う必要があります。

主なテストの種類

テストには、主に下記のものがあります。
一つ一つ説明すると長くなるため、ここではワードのみに留めたいと思います。

• ユーザービリティテスト

• クリエイティブチェック

• 単体テスト

• 結合テスト

• リグレッションテスト

• システムテスト（総合テスト、シナリオテスト）

• 連携テスト

• 負荷テスト

• 脆弱性テスト（脆弱性チェック）

• 受入テスト（検収）

「バグゼロ」は、ほぼ不可能

どんなにしっかりテストを行った優れたシステムでも、必ずバグの1つや2つ（それ以上）はあります。

また、あるバグに対応したことで逆に処理が遅くなったり、使いにくくなるという弊害が発生することがあります。

そのため、重要なのはバグをゼロにすることではなく、本当に対応が必要なクリティカルなバグなのかを見極めることです。

12. リリース

テストが完了し、ユーザー企業からリリースのGOサインが出たら、いよいよリリースです。

リリースは準備をしっかりしていれば一瞬ですが、トラブルの発生が多いフェーズでもあります。

本番環境と全く同じステージング環境を用意していたとしても、実際にリリースしたら予想していなかったトラブルが起きることは、珍しくありません。

リリース前は入念なシミュレーション、何かあった際に巻き戻せるようにバックアップ体制をとる、トラブル発生時の対応方法をまとめておく、などしっかりと準備をしておくと良いでしょう。

またリリースがどのような手順で行われるか、事前にリリース計画を作成して共有し、濡れや漏れがないかを関係者にチェックしてもらうのも一つの対策方法です。

13. 運用、保守改善 

リリースが終わったら運用や保守に入ります。

保守はプロダクトが安定して稼働するために必要です。
例えば、WordPressなどの頻繁にアップデートが行われるCMSを利用している場合などは、古いバージョンのまま放置すると、セキュリティ上のリスクを負うことになります。
（バージョンアップ対応がされるかは保守契約によります）

また、リリースされたプロダクトは作って終わりではなく、ユーザーに利用され、より良いプロダクトに育てていく必要があります。

中にはリリース後に全く改修されないまま、リリース当初の姿を維持するプロダクトもありますが、現在では少数派と言えます。

ユーザーのフィードバックをもとに、改善を繰り返し、より良いプロダクトに育てていく必要があります。

参考資料

プロジェクトマネジメントの基本が全部わかる本

予定通り進まないプロジェクトの進め方