プロジェクトマネジメントで失敗したこと・成功したこと
こんにちは。
カラーミーショップの藤吉です。
自己紹介はこちら
今回は、この3ヶ月間、プロジェクトの管理者・推進者としてやってきた中で失敗したこと・成功したことを書いていきたいと思います。
現在、チームで行っている施策の中で「ショップ診断」というものがあります。詳細は以下で細かく説明しています。
簡単にご紹介すると、このショップ診断というものは、サクセスチームで該当者を20以上の診断項目でチェックし、×だった項目に対する改善方法をメールでお送りするものです。
ショップ診断を開始してから、
・スマホでショップ診断メールを見ると崩れている
・診断結果の表現に難がある
などの課題や、
・もっと診断回数を増やしてほしい
・改善方法がわかりずらい
・やることが多いと感じる（×が多い人には20以上の改善メールが配信されるため）
といったアンケート回答も頂いていたことからショップ診断のリニューアルをすることになりました。
今回のリニューアルでは、チーム7名で取り組むことになったため、リニューアルプロジェクト管理者として、この数か月、動いてきました。
プロジェクトを進めてきた中で、失敗したこと・成功したことがあったので、こちらの記事でシェアできればと思います。
失敗１：ブレストを広げすぎて収拾できないときがあった
リニューアルプロジェクトを進めるにあたり、どのようにショップ診断を改善するかをチームメンバー全員でブレストしました。複数回ブレストをする中で議論が二転三転し、結局落としどころがないまま収拾できないといったことがよくありました。
プロジェクトの管理者としてMTGのファシリテートをしていたのですが、「そもそも診断する対象ってこれでいいんだっけ？」といったそもそも論や着地地点がわからず、次回に持ち越しということもありました。
そのたびに、もともとのショップ診断の設計の話に立ち戻ったり、また別の話になったりとブレストをしたはいいが時間ばかりがとられて、進展しないというのが4～5回ほどあったと思います。
反省点としては、改善の目的を絞り、議論する箇所を限定してブレストする方が改善案もまとまりやすかったのではと思います。
今後同じようなプロジェクト管理をするときは、ブレストする範囲を限定し、ちょっとでも議論がズレたら元の議論に戻すファシリテートを心がけようと思いました。
失敗２：作業の洗い出しができていなかった
あらかた「こうしていこう！」という案が見えてきたので、まずはガントチャートをつくり、必要なタスクを個々人に割り振り、リニューアル作業を開始しました。
ところが、今回はリニューアル作業なので、現状のショップ診断は停止せずに実施しているため、現在のショップ診断に影響が出る事項のタスク出しがなされておらず、作業効率が悪いときがありました。
今まで新しく立ち上げるプロジェクトは何個の経験してきましたが、リニューアルプロジェクトは初めてだったので、既存の業務にどういった影響が出るかといった視点がすっぽり抜けていました。
反省点としては、いきなりタスク出しをガントチャートでやるのではなく、まずはマインドマップを使って作業を分解して洗い出しをしようと思います。
失敗３：段階的なリリースにしたことで、初回リリース後に気が抜けて第２弾リリースが遅延した
今回のショップ診断リニューアルは、合計３回の段階的なリリースで、リニューアルを行うことになりました。まずは初回リリースということで10/11を期限として進め、無事リリースすることができました。
ただ、第２弾のリリースが10/21を予定していたが、初回リリースが納期内にリリースできたことで安心してしまい、第２弾のリリース日のコンセンサスがシステム構築担当者としっかり握れていませんでした。そのため、第２弾のリリースが遅延してしまい、10/25のリリースとなってしまいました。
失敗の要因は、初回リリース後に、どのタスクを誰がいつまでにを明確に管理できていなかったことでした。
反省点としては、段階的なリリースをするプロジェクトの場合、１つ目のゴールが達成されたあとも２つ目、３つ目のゴールに向けた細かい進捗管理を徹底することが大事だと感じました。
失敗４：システム周りの細かいタスクやスケジュール管理ができていなかった
ショップ診断は、salesforceとpardotで設計し運用するものになります。私はsalesforceとpardotは多少は利用していますが、裏の設計を実際に作りこんだ経験が少ないため、今回のショップ診断リニューアルで作業するタスクのイメージをしっかり掴めていませんでした。
プロジェクトの管理者としては、作業の中身までは理解する必要はないと思っていましたが、システム担当者と設計周りの話をするときに、なぜそのタスクをしなければならないかといった業務タスクのイメージが掴めず、システム周りのタスクの進捗管理が徹底できませんでした。
そのため、システム担当者に丸投げに近い状態になってしまったことで、そのシステム担当者の作業の遅れを検知することができず、第２弾リリース遅延という失敗をしました。
反省点としては、システム担当者の作業内容を理解することでタスク進捗を管理するのではなく、「この日までにこのような運用にしたい。このタスクをやったことでこの運用はできるか？」といったこちらが実現したいことベースでタスク確認をすると遅延が発生しにくいということがわかりました。
具体的には、
「今回のタスクをすすめることで、
ショップ診断のフェーズ2の初回診断はできるようになりますか？」
「できます。」
「では、再診断はできるようになりますか？」
「まだできません。」
「再診断ができないのはなぜなんですか？」
「このタスクが遅延しているからです。」
「わかりました。」
というように、実現したいことができているかできていないか？といった視点でタスク確認をしていくとタスク内容を理解できていなくても進捗にどう影響があるのかがわかるので、今後、そのような進捗理解をしていこうと
失敗５：自身が作業者として動いてしまい、第２弾リリースのスケジュール管理が後手に回った
プロジェクト管理者である私自身も、タスク作業を行ったり、メンバーにやってもらった成果物の最終チェックをしていたため、第2弾リリース以降のスケジュールやタスク管理を充分にできていませんでした。
反省点としては、極力自身は全体のスケジュール管理やタスク管理をメインで推進していく方が、プロジェクトの遅延につながらないため、リソースが空いたメンバーに率先してタスクを依頼していくスタイルが良いと思いました。
上記がプロジェクト管理者になって経験した失敗になります。
一方で、少しですが成功したことがありました。これはやってよかったといったものを紹介していきます。
成功１：課題認識から始めることができた
現状のショップ診断施策について、課題感や理解の差がメンバー内であったので、現状の実績や課題、診断を受けたアンケート結果、診断後の改善値をまとめ、それらを共有することで、メンバー全員のスタートラインを揃えることができました。
成功２：現状を絵にすることで進めやすくなった
ショップ診断の流れをスライドにして、毎回のMTGで決定した内容を追記し更新していくことで、メンバー全員に共通認識を持たせることができました。「前回のMTGでこういう意見があったので、このスライドに足しました」という流れで、前回のことも思い出してもらいながら施策をつくりあげていくことに一役買ったと思います。
またスライドで診断の流れを整理していたので、それをもとにシステム担当者とのすり合わせやタスク出しもスムーズに行えました。
成功３：実作業ではチーム分けを行い、チームごとの進捗確認が効率的だった
メンバーが７名もいるため、全員で議論するのは大まかな方針決めまでにして、実作業については、システム設計チームとコンテンツ制作チームに分けて推進しました。
システム設計チームでは、頻度多くMTGを設けて、タスク出しや実際に方針で決めたことがシステム的に可能なのかをテストしました。
一方、コンテンツ制作チームでは、作業をお願いしたいことを詳しくまとめ、作業漏れがないように、締切前にフォローアップMTGを行い、ダブルチェックをするなどを実施できました。
成功４：デザイナーを巻き込めたことが良かった
今までのチーム施策では、あまりデザイナーを活用することはなく、基本、自前でデザインをしてきたのですが、今回はデザイナーさんに入ってもらい、メールテンプレートやランディングページなどの作成を行っていただきました。
デザイナーさんには、別途、方針が決まったショップ診断概要やキックオフで使ったショップ診断の目的や効果を伝え、リソース確保をお願いしたところ、快諾いただき、デザインだけではなくコーディングまでを行っていただけました。
以上が、プロジェクト管理者として失敗したことと成功したことになります。今まで、数人で動くことが多かったため、今回初めてチーム内外のリソースをスケジュールに組み込み、ショップ診断リニューアルのリリースをすることができました。
余談ですが、今回デザイナーさんに入って頂き、自分たちの作ってきたメールテンプレートやランディングページと全然クオリティーが違うという点には非常に驚かされました。なんでもかんでも自分たちで内製化するのではなく、チーム外リソースや社外リソースをうまく使うことで短期的に成果を出せると感じた経験でした。