こんにちはプロデュース部の上井です。

インターネットを取り巻く環境の急激な変化にともない、要求される技術が広範化、高度化しています。そのため、サイトリニューアルのプロジェクトでは、何かしらの課題を残してしまうことが多くなってきています。

クライアント側のWebマスターへ、発注者・受注者という関係性のみならず、プロジェクトチームを共に率いる者として押さえておいてもらいたいことを、６回にわたりお伝えする短期集中連載の第2回目となります。

前回「第1回：QCDの精度と予算　〜二段階発注のすすめ〜」では、プロジェクトをV字モデルで「計画フェーズ」「構築・検証フェーズ」として捉え、計画フェーズ完了時に構築・検証フェーズの見積りを実施する二段階発注のメリットをお伝えしました。

連載第2回では、計画フェーズの進め方について、お話しします。

計画フェーズの目的とは何か

前回の記事でお話ししたとおり、計画フェーズ（要件定義〜基本設計）では、プロジェクトの範囲と制作仕様を計画し、設計図書にとりまとめます。これにより、サイト構築の全体数量と難易度を決定します。
全体数量と難易度が決まれば、構築に必要となる要員を計画し、作業工数を積算することが可能となります。
この要員計画と工数の積算結果に基づいて、工程計画を立案し、費用を算出します。
構築フェーズのQCDを決めることが、計画フェーズ（要件定義〜基本設計）の重要な目的です。

　・Quality（仕様） ：構築フェーズの全体数量、制作仕様（難易度）の決定。
　・Cost（費用） ：「Q：仕様」に基づき、要員計画を決定。費用を算出。
　・Delivery（工期） ：「Q：仕様」に基づき、工程計画を決定。

また、プロジェクトをV字モデルで捉えると下図に示すように、計画フェーズ（要件定義〜基本設計）のアウトプットは、制作・開発工程へのインプットであると同時に、検証工程（テスト）における基準づくりでもあります。

　＜図＞V字モデル｜品質保証の観点から見た開発プロセス

計画フェーズ（要件定義〜基本設計）は、制作会社側が制作・開発を行うためのQCDを定めるとともに、クライアント側が受け入れを行うための基準を定める工程です。
ここでとりまとめる資料は、制作会社側においては、制作・開発を担当する技術者に対して制作仕様をブレなく伝えることが必要です。一方、出された要望をどのような手法、手順で実現するのか、クライアント側にとっても理解しやすくまとめなければなりません。

見積り変更につながる計画変更とは

計画フェーズを進行し、要求仕様（Quality）を固めて行くのに伴って、プロジェクト着手前に想定した予算（Cost）、工程・工期（Delivery）に変更につながる計画変更は以下の３つに整理できます。

プロジェクト対象範囲の変更

業務着手後、既存サイトの詳細な調査や、業務要件の精査をとおしてプロジェクトの対象範囲が広がることがあります。
初期見積り作成時の外部からの調査では把握できないページがあったり、制作会社側が重要度が低いと判断し制作対象外としたページに対して新サイトへの移行を要請されるなど、制作数量の増加が頻繁に発生しています。

制作・開発仕様の変更

ページへのアクセス条件やユーザーの属性によって表示内容を出し分けるなどの仕組みを設けたページなど外部からの事前の調査ではシステムの仕様が把握できない場合があります。
また、サイトを運用しているサーバーが、デファクトスタンダードな構成と大きく異なっていた場合、開発仕様や構築手順の変更、リニューアルサイト完成後の公開手順の変更などが必要となり作業工数が増大することがあります。
当初の見積り条件に含まれない開発仕様の変更・追加が出てきた場合、費用、工期の見直しだけではなく、制作会社側が当初予定していた担当技術者のスキルセットでは対応ができずに要員計画の見直しとなる場合もあります。

クライアント側での追加対応

設計が進み開発仕様が固まっていく中で、クライアント側で対応する作業や手配に、追加が発生することがあります。
この場合、制作会社への発注費用ではなく、クライアント側のプロジェクト実行予算の変更が必要となるかもしれません。

計画フェーズ（要件定義〜基本設計）での仕様決めに伴って、発注時に想定した要求仕様から計画変更となることは、避けることが困難です。
仕様（Quality）の変更は、予算（Cost）、工程・工期（Delivery）の変更に繋がります。制作数量が大幅に増大したり、開発仕様の難易度が上がった場合、制作コストの上昇や制作日程の延伸が避けられません。

計画フェーズの進め方

それでは、計画変更に適切に対応しプロジェクトを円滑に進めるためには、計画フェーズをどのように進めればよいのでしょうか。

要求仕様の優先順位を決める

当初計画していた要望の全てに応えた開発仕様となると、予算、工期が納まらないとなった場合、要求仕様（Quality）を削減することで、予算（Cost）、工期（Delivery）を調整することになります。この調整を検討するには、クライアント側のWebマスターが要求仕様の優先順位を決める必要があります。
ただし、要求仕様の優先順位は、制作・開発の手法や手順によっては業務要件の優先順位に従うことが難しい場合もあります。クライアント側のWebマスターと制作会社側のプロジェクトマネージャーが協力して最適解を導き出すことが求められます。

やること、やめること、後回しにすることの切り分け

当初計画の予算、工期に納めるために実施する範囲を調整することは、クライアント側から見るとリニューアルでやりたかったことの一部を諦めるということでもあります。
ここで考えなければならないことは、リニューアル完了後のサイト運用でカバーできることはないか、実施しても効果が限定的または見込めない要求仕様がないか、または二次開発として実施時期を遅らせても問題のない課題がないかを切り分けることです。
ここでも、調査・設計を担当する制作会社側と、サイト運営を主管するクライアント側Webマスターの協業が欠かせません。

計画フェーズの進行により、費用（C）、工程・工期（D）が、発注時の想定から変更が必要となった場合、クライアント側と制作会社側が協力し最適解を求めていくことになります。プロジェクトを滞りなく進めるためには、この意思決定を円滑に行うことが重要となります。
そのために、クライアント側のWebマスターの協力が欠かせないことがあります。

承認フローの確認

予算や工期の変更、サイトリニューアルのプロジェクトスタート時には想定していなかった社内対応の手配などは、クライアント側の承認が必要となります。
また、二段階発注とする場合、計画フェーズで決定する開発仕様（Q）・費用（C）・工程・工期（D）が、構築フェーズの発注仕様となるため、ここで作成する設計書の確認・承認は重要です。
これは、クライアント側のWebマスターが社内調整や手続きを行うことになります。承認フローと手続きに必要となる日数などを確認しておいてください。

設計内容の理解

クライアント側のWebマスターがこれらの承認手続きを円滑に進めるためには、決定した仕様とそれに伴う予算、工期の変更についてクライアント社内での合意形成を主導することが求められます。
基本設計は、出された要望をどのような手法、手順で実現するのかを決定し設計図書にとりまとめる工程です。もちろん制作会社側は、クライアント側にとっても理解しやすくまとめなければなりませんが、どうしても制作・開発の専門用語による資料化が避けられない場合もあります。
Webシステムの開発を行う場合、クライアントがオフィスで実行している業務フローをプログラム上でのデータ処理のプロセスに置き換えていくことになります。ここで設計されたプロセスやロジックが、業務要件を満足するものか判断するためには、プログラムの開発仕様を設計書から読み解く必要があります。
もちろん制作会社側のプロジェクトマネージャーは、この理解を得るための努力を怠ってはなりません。しかし、クライアント側のWebマスターにも、ここでの理解、判断について見落としや誤認が起こらないように対応をお願いします。

承認プロセスを考慮したスケジュール

上記のように、計画フェーズでの検討内容に対する承認のプロセスは、プロジェクトの実行メンバーの頑張りで期間を短縮するということができません。
また、クライアント側にとっては受け入れの基準を決めるプロセスでもあります。承認内容を理解し見落としや誤認を防ぐために、十分な期間を割くことが求められます。
そのため、計画フェーズは余裕を持ったスケジュールとなるよう留意してください。

構築フェーズ、検証フェーズのQCDを決定する計画フェーズにおいて、プロジェクトの実行メンバーを束ねる制作会社側のプロジェクトマネージャーと、プロジェクトの進行に伴う意思決定を司るクライアント側のWebマスターは、プロジェクトを推進する両輪です。
コーポレートサイトのリニューアルでは、クライアント側のWebマスターが通常業務と兼務されることも多いと思いますが、計画フェーズの期間中はリニューアルプロジェクトに十分な時間を充てられるように社内調整を行っていただくことも重要です。

短期集中連載の第2回は「計画フェーズの進め方 〜Webマスターとプロマネはプロジェクト推進の両輪〜」と題して、要件定義〜基本設計の工程で要求仕様（Quality）を固めて行くのに伴って、当初想定の予算（Cost）、工程・工期（Delivery）に変更が発生する要因を整理し、計画変更に適切に対応しプロジェクトを円滑に進めるために、クライアント側のWebマスターと制作会社側のプロジェクトマネージャーの協業が重要であることをお話しました。

次回は、「第3回：セキュリティ対応と保守・運用について」と題して、情報セキュリティリスクへの備えとコストのバランスについてお話ししようと思います。