cloudpackプロジェクト管理ホワイトペーパー
本ホワイトペーパーでは、cloudpackのプロジェクト管理のノウハウを公開しており、システムの構築フェーズにおける、円滑なプロジェクト遂行を実現するためのプロセスおよびコミュニケーションルールなどを明確にしています。プロジェクト管理方法については、一般的なガントチャートの活用や効率的かつ漏れのない課題管理のテクニックまでを網羅しています。このホワイトペーパーは、パートナー企業様のレビューを受けながら、cloudpackチームによって執筆されたものです。このページおよびホワイトペーパーは定期的に更新されるため、新しいコンテンツがないかご確認ください。
1. 概要
本ホワイトペーパーは、cloudpackがご提供するサポートサービスの詳細をご紹介し、お客様とcloudpackとの間で円滑な業務遂行を実現することを目的にご提供するものです。
対象読者：
- AWS、cloudpackをご利用中の方
- AWS、cloudpackの導入をご検討中の方
2. プロジェクト管理の重要さ
物事の成功は「段取り八分」と言われるとおり、プロジェクトの成功も段取り（=プロジェクト管理）が大きな成功要因となります。
ITシステム基盤がクラウドに移行することで、ハードウェアの調達が不要となり、プロジェクト期間の短縮化が期待される中、一方で従来型のプロジェクト管理手法ではなかなか期待したように、期間が短縮されないといった声を聞くことも少なくありません。
cloudpackは、クラウドを基盤としたプロジェクトを年間で数百件規模でこなしており、品質を確保しつつ、スピードと成果を最大化するノウハウ（=手法）を有しています。この手法をお客様と共有し、お客様と一体となってプロジェクトを進めていくことが、プロジェクトの重要な成功要因であると考えています。
3. cloudpackにおけるシステム構築の流れ
3.1 初回のお打ち合わせまでの準備
システム開発を始めるに当たり、弊社営業担当者は、まず、そのシステムの構築に必要なものは何かを洗い出し、初回のお打ち合わせに向けて、次の準備をします。
（1）機能別担当者の割り当て
システムの多くは、いくつかの機能に分けられます。例えば「インフラ」「アプリケーション」「他システム連携」などです。cloudpackでは、こうした区分のことを「カテゴリ」と呼びます。
そこでまずシステムの構築が、どのようなカテゴリで構成されるかを洗い出し、カテゴリごとに担当責任者を割り当てます。
※システムによっては、機能区分ではなく、「要件定義・設計」「構築・開発」「テスト」「運用」などのフェーズで担当者を分けることもあります。
（2）大まかな工程の洗い出し
（1）のカテゴリごとに、どのような工程が必要なのかを洗い出します。例えば「インフラ」なら「ネットワーク・サーバー設計」「開発サーバー構築」「本番サーバー構築」「本番運用前のサーバーへのコピー」などの工程があります。
これらの工程に対しても担当者を割り当てます。そして「いつまでに終わらせなければならないのか」を線引きします。
（3）チェックポイントの設定
システム開発においては、いくつかのチェックポイントがあります。「リリース日」は、その最たるものです。
それ以外にも、作ったものを確認する「レビュー会の日」や、お客様との「定例ミーティング」などもチェックポイントとなります。システム納品までの期間を考慮したうえで、こうしたチェックポイントを仮決めします。
上記の内容を決めた上で、お客様との初回のお打ち合わせを行います。この初回のお打ち合わせのことを「キックオフ（kickoff）」と言います。
3.2 リリースまでの流れ
システムをリリースするまでの大まかな流れは、下図の通りです。キックオフまでに、カテゴリや工程の洗い出しが終わっているので、このスケジュール表は、キックオフの時点で概ね決まったものとなります。
それぞれの工程には、期日が設定されていることに注意してください。予定通りリリースするには、それぞれの工程を期日通りに完了することが重要です。
図3.2 リリースまでの流れ
3.3 工程を細分化する「課題」
工程が決まったら、その工程でやらなければならない作業をリストアップします。例えば、アプリケーションの設計であれば、「データ構造を決める」「入力画面を設計する」「出力画面を設計する」「外部と連携をとるAPIを設計する」などが、しなければならない作業の例として挙げられます。
こうした、「やらなければならない作業」を「課題」と言います。
3.3.1 課題に「期日」と「担当者」を設定する
課題は、工程を細分化したもので、
- いつからいつまでにという「期日」
- 誰が作業するのかという「担当者」（担当者が未確定のときは、その課題の責任者）
を定めたものです。
細分化すると、工程に対して、多数の課題がぶら下がる構造になります。ぶら下がった課題すべてを、それぞれの担当者が片付ければ、工程は完了です。下図からわかるように、課題の期日は、必ず、工程の期日内に収めるようにします。
図3.3 工程を細分化し、課題として落とし込む
3.3.2 課題にはチェックポイントを設定する
課題に設定した期日は、「完全に終わらせなければならない日」であり、「作る」という意味での締め切りは、それよりも少し前です。それは次の理由によります。
（1）確認作業の必要性
完全に終わらせるには、確認作業が必要です。ですから、確認作業の日までには、作り終えていなければなりません。
（2）進捗の確認、方向性の打ち合わせ
課題の多くは、定例ミーティングで議題として採り上げ、進捗を確認したり、方向性を打ち合わせたりする必要があります。ですから、ミーティングの日までには、何かしらの途中報告をできるだけの材料を作っておく必要があります。
「確認作業の日」や「定例ミーティング」は、ここまで説明してきた「チェックポイント」です。そこで課題には、チェックポイントを設定しておき、それを「何かしらの作成の節目の日」として扱います。
課題によって、何をチェックポイントとするのが適切なのかは異なります。直近の定期ミーティングが適することもありますし、もっと先の期日直前の定期ミーティングが適することもあります。
課題に設定されたチェックポイントは、繰り越されることもあります。例えば、一度、ミーティングの議題として採り上げた後、さらに次のミーティングでも議題で採り上げるときには、チェックポイントを、次のミーティングの日に再設定します。
図3.4 チェックポイントを節目として議題としたり確認したりする
本ホワイトペーパーをご覧になりたい方は、下記のボタンよりダウンロードの上、ご確認ください。