プロジェクト体制図で事故を防いだ件。

先日、とある２件の案件で１つは「作成途中でプロジェクトが終了（途中までの作業費はいただくことになりましたが）」という案件と、「きっちり納品出来た案件」の２種類の結果に分かれた案件がありました。
クライアントは同じクライアントで（部署は別でしたけど）金額もほぼ一緒。関わる人員もほぼ同じ（メインは）。では何が違ったか、というと、表題にある「プロジェクト体制図」を作ってプロジェクトに臨んだか、そうでないかの違いでした。

それぞれの案件の仕様を簡単に記載しますね。

案件１
概要：サイト内コンテンツの改修
仕様：静的ページ８ページ
人員：クライアント側/担当部署（部長及びその他２名）と企画（WEBサイト管理部門）
　　　制作/ディレクター・デザイナー・コーダー１名ずつ
管理：メールで関係者全員にメール及び、口頭や電話でも確認を取る。
　　　ただし、窓口はクライアント担当部署のみにして、クライアント側の意見や確認はクライアント側の担当部署のお任せ
納期：厳守で2ヶ月間で
原稿や素材：なし（現状、あるものでスタート）

案件２
概要：サイト内コンテンツの改修
仕様：動的ページ２ページ
人員：クライアント側/担当部署（課長とその他５名）と企画（WEBサイト管理部門）
　　　制作/ディレクター・デザイナー・エンジニア１名ずつ
管理：プロジェクトのスタート時に「体制図」を関係者に配布して、それぞれの役割や立ち位置を確認。
メールで関係者全員にメール及び、口頭や電話でも確認を取る。
　　　ただし、窓口はクライアント担当部署のみにして、クライアント側の意見や確認はクライアント側の担当部署のお任せ
納期：厳守で2ヶ月間で
原稿や素材：なし（現状、あるものでスタート）

クライアント側の担当者さんの能力や忙しさの度合いなどはこちらでは測り知れないので、そこは考えず、で。
また、ともに制作会社との打ち合わせや、制作物作成の経験はほぼゼロに等しい、です。
では、経緯からお話していきますね。

2つの案件が同時に流れ込んできた

この「案件１」と「案件２」はほぼ同じ時期に、同じクライアントの普段やり取りしていない別の部署の方からお話をいただきました。
このクライアントさんはWordPressで構築しているのですが、部分的にCMSを使う仕様にしてあり、コンテンツの内容やボリュームに依って、CMSを使うのか、静的ページの作成かをその都度判断させてもらっています。今回のこの２つの案件は静的と動的（カスタム投稿タイプを使った自社更新型）で進むことになりました。尚、余談ですが、僕は基本的にはコードやプログラム系は全くわかりません。故にやりやすさから言えば、静的案件のほうがスケジュールもディレクション作業も動的よりはやりやすいです。

案件１

やりやすい案件１からスタート

上記のような理由と、案件２側の担当者さんとはなかなか連絡がつかないこともあり、案件１からスタートしました。制作打ち合わせに慣れていない、とはいえ、バナーの作成や単発のページの追加、ちょっとしたブロックの追加など、今までに何回かはやり取りしています。今回８ページもあるため、最初に作業の流れを説明し、デザインの確認が取れたあと、コーディングに入り、コーディングが終わったら、納品という、基本的な流れです。企画部門にもデザインの確認をお願いしますね、レイアウトの修正に関しては、コーディングに入る前に必ず言ってください、意見を集約する方を決めてください、と伝えさせていただき、原稿はなかったのですが、既存コンテンツから原稿を持ってこればいいのと、素材写真でなんとかなりそうだな、ということでスタートしました。

この時点で提出している資料

• サイトマップ（コンテンツトップを基軸とした）
• ディレクトリマップ（コンテンツトップを基軸とした）
• 各ページのワイヤー（線だけでなく、どこに何が配置されるのかをスクショの切り貼りで全ページ作成）
• スケジュール（ガントチャートで作成）
• 今回の修正のテーマやコンセプト、戦略性、施工した結果の得られるメリットなど

上記を提出し、その全てに担当部署から承認をいただいたうえで進めています。
また、これらは担当部署より「予算を用意するのに上を説得するために必要だから欲しい」と言われ作成しています。

実際にスタートしてみると・・・

上記にあるような説明と、それに対してわかりました、ということだったので、スタートさせたわけですが・・・

• 担当部署の3名がそれぞれ担当を押し付け合う
• 提出されてきた修正内容と（一応、部長から任命された）担当者の修正内容が真逆。
• デザイン前に打ち合わせで決めた方向性をひっくり返す内容の修正をこちらに提示
• また、その内容は部署のメンバーにも相談していないのが発覚（これに関しては断りましたが）
• コーディングが一段落し（当然デザインはOK）、確認しながらコーディングチェックを行っている段階で企画部門から「OKしてない」と言われる
• 企画部門にはccでメールを飛ばしていたが、担当部署と正式な話し合いをしたわけではないので、OKを出した認識はない、と言われる
• 事前に出した資料、その他諸々全て目を通していないため、今回の改修の意図がわからない、と言われる
• コーディング終了後にこのページいらない（２ページ）と言われる（こちらからの提案時は外部リンクで済ます予定だったが、先方の要望で作成）
• デザインからやり直し（ふりだしに戻る）

・・・とまぁ、惨憺たる結果に。

こちらの責任ではない、ということになったが・・・

打ち合わせは話し合いの結果、非はこちらにない、とはなりましたが、クライアントのサイトを管轄しているのは僕ですし、なんらかのカタチで納品しなければ費用はいただけません。この時点で一旦お支払いをお願いすることも考えましたが、追加予算は厳しい、と言われてしまうと、コンティンジェンシーで見込んでいた予算のなかで済むようなやり方を模索しなければならず、出来るだけ手を加えない編集で先方が納得する着地点を模索しなければならない状況になりました。ただ、案件２がスタートすることになっており、案件１に関してはクライアント側でももう一度話し合うということを言っていただいたので、ペンディングとさせていただきました。

案件２

案件１から「どうすればこんな結果にならなかったのか？」を考えてみた

こちらに非はない、という話しになったものの、結局、お金は納品しなければもらえないですし、クライアント側に問題がある、とわかっているのであれば、こちらで対策を立てるしかありません。クライアントも作って運用したい想いは同じですから対策さえあれば、案件１よりはいい結果になると思いました。で、考えた結果、クライアントにある問題は

• それぞれが思い思いに勝手なことを言ってる（部署内で打ち合わせや意見の集約が出来ていない）
• クライアントに限らず、日本企業は縦のつながりが出来るが、部署間連携（横断型）の動きが弱い
• チラシを作るのと同じ感覚でいる
• クライアント社内でも、制作物の社内承認の流れがわかっていない
• 意見集約しなかった結果、招く結果（リスクやデメリット）を理解していない

といった問題が先程記載した「起こった事例」から見えてきました。結局、立ち位置やそれぞれの役割が見えていない、デメリットやリスクヘッジがわかってないので、体制が整ってない、責任が負えない、誰かがやってくれるだろう、という姿勢になってしまうんだろう、と。それらを解消するために「案件１」では作成しなかった「プロジェクト体制図」にそれそれの役割、承認の流れ（クライアントの社内承認に流れを外注業者である僕がクライアントに説明するのはおかしな話ですけどね）を記載して、クライアント側の担当部署の課長さんにお会いして全て説明し、それをやらなかった結果、「案件１」がどうなったのか、というリスクも説明しました。

この時点で提出している資料

• サイトマップ（コンテンツトップを基軸とした）
• ディレクトリマップ（コンテンツトップを基軸とした）
• 各ページのワイヤー（線だけでなく、どこに何が配置されるのかをスクショの切り貼りで全ページ作成）
• スケジュール（ガントチャートで作成）
• 今回の修正のテーマやコンセプト、戦略性、施工した結果の得られるメリットなど
• プロジェクト体制図

プロジェクト体制図を見せながら立ち位置、関係者の洗い出しと認識確認をして、「御社のどなたからの連絡であっても、それは御社の”総意”として我々は認識します。会社対会社のビジネスです。だから、課長が一旦集約されないと収集がつかないことも出てきまいます。そうなると予算超過、スケジュールの超過、プロジェクトのストップなどを招きます。住宅の建築でも施主の家族がそれぞれ現場のスタッフや監督さんに意見をバラバラに言っていたら、混乱するし、建築作業は止まってしまいますよね？それと同じです。御社スタッフさんの意見は御社の会社としての意見です。我々はそれを以て要望や修正指示として請けて動きます」とはっきりと説明させていただいたところ、社内事情があるのでしょうか、かなり困った顔はされていましたが、「こんなに正面から正論をはっきりと言われたのは初めてだわ」と笑いながら、同席されたスタッフさんからも「当たり前の認識ですよね」という後押しもあり、その認識で進めていただくことになりました。

実際にスタートしてみると・・・

• こちらも根回ししましたが、企画部門からの指摘は早い段階で指摘が出た
• デザインに関して、微修正のみ
• デザインが出来た時点で企画、担当部署、制作の３者で合同の打ち合わせ、動作の事前確認
• テスト版びコーディングが終了した時点（CMSに組み込む前）で動作確認、微調整、最終の修正要望、現実的なスケジュールの報告
• テスト版に組み込み、実際に事例を登録し、管理画面の内容も確認、残作業の内容確認と納品までの双方の流れを再確認
• インシデント表でバグ潰しをやりながら事例登録で動作検証

動的な部分は僕が理解出来ておらず、慎重に進めたこともあり、打ち合わせをその都度おこなっていますが、ほぼ、止まることなく案件は進捗し、先方の都合で半月ほど納期はズレましたが予定していた月の月内には納品できました。案件１に関しては、案件２の納品後に再度取り掛かる、という話でしたが、先方都合により、このプロジェクトは解体することとなり、現状までの作業料を精算するカタチで終焉を迎えました。

プロジェクト体制図について今まで思っていた認識

PMBOKを読んだ際にプロジェクト体制図についても記載してあったので読んではいたのですが、必要となるのはもっと大きなプロジェクト（それこそ複数社が絡み合うような、ン千万とか、ン億の）かと思っていました。若しくは、制作サイドの連絡網、制作側の体制を見せてクライアントに「安心感」や規模の大きさを伝えるためだけに必要な資料程度、という認識でした。

今回の件は、事前に案件１の顛末を案件２の担当者も知っていたため、先方が動いたのもありますし、僕もしつこいくらいに根回しして、確認取ったからってのもありますが、最初に提出したプロジェクト体制図で関係者の洗い出しと連絡・伝達の流れを決めた、それをやらなかった結果、どういった結果を招くのか、といったことまできっちり説明して、プロジェクトと関わる人間の相関関係を明確にしたのが大きいと思います。PMにおいて作業範囲を明確にするわけですが、体制図を作り、クライアント側の関係者の作業範囲を明確にした、明確にしてもらった、ということになります。