クライアント制作プロジェクトにおけるディレクターの声として「サービスローンチ直前にクライアントから大リテイクが…」、「今更、要件に無いオーダーが続々…」、「請求の段階で揉めてしまった…」などの、いわゆる制作現場の「あるある」をよく耳にします。

プロジェクトを牽引するディレクターの役目は、そのスタートから完成まで、クライアントと制作スタッフの架け橋となりながらスムーズに進行させ、ビジネス価値を創出することです。
ディレクション上のよくある課題として、クライアントとの合意形成不足から起こる、完成直前でのリテイク。コミュニケーション不足による、相互の認識齟齬などが挙げられます。これらは、制作コストに大きく影響し、プロジェクト自体の存続も危ぶまれる状況を呼ぶ可能性もあります。
ビジネス的な成功をもたらす理想的なプロジェクトの実現は、クライアントと制作サイドが共通認識を持って同じゴール向かい、全ての熱量を注ぎこめる環境を創り出すことが鍵になるのではないでしょうか?

本セミナーでは、リクルートグループを始めとする大手クライアントとの実績も多数持つニジボックス様にて、ディレクターをなさっている小野里芽衣氏をお招きし、制作プロジェクト進行における、プロジェクト計画の要点とその進め方について過去の経験やノウハウを交えつつお話しいただきます。

セミナー内容

リクルートグループNIJIBOXのディレクターが語る
プロジェクトを安心・安全に進行できる!
プロジェクト計画とクライアントコミュニケーションの秘訣

  • 1.プロジェクト進行におけるよくあるお悩み
  • 2.うまく進行するには?
  • 3.プロジェクト憲章のメリット
  • 4.まとめ

登壇者紹介

小野里 芽衣 氏
UI/UX制作室 ディレクター3グループ マネジャー
テクノロジーソリューション室 開発ディレクター
グループ 品質管理セクション

Web制作会社でシステムエンジニアを経験したあと、2016年にニジボックスに入社しディレクターに転身。

大手クライアント制作案件を数多く担当する中で、リクルートの新規事業創出プログラムの運営サポートも経験。現在はディレクター組織のマネジャーとして、マネジメント業務に従事。また、品質管理組織へも兼務し、組織横断的なプロジェクト推進も行っている。

 

はじめに

株式会社ニジボックスでディレクターをしております、小野里芽衣と申します。本日はよろしくお願いいたします。

本日は「プロジェクトを安心・安全に進行できる! プロジェクト計画とクライアントコミュニケーションの秘訣」というタイトルで登壇させていただきます。

まずは簡単に自己紹介をさせていただきます。

前職のWeb制作会社ではシステムエンジニアをしておりました。2016年にニジボックスに入社してディレクターとして様々な業務を努めてまいりました。現在はマネージャーとしてマネジメントメインの仕事をしておりまして、最近ですと会社に品質管理組織というものができまして、そちらにも所属して組織横断的にプロジェクト管理も行なっております。

プライベートではすごく温泉が好きでして、早く温泉に安心して行ける日が来るのを楽しみに待っています。最近買ったウクレレにハマっていて、YouTubeを見ながら楽しんでいます。

 

プロジェクトを失敗させないために

早速メインの話に移りたいと思います。突然ですがみなさんこんな経験はありませんでしょうか。

①「この前FIXしたデザインですが、部長からフィードバックがあり、修正をお願いします」

②「この部分は御社にやってもらえると思っていました」

③「自分の端末で見たら崩れていました」

などたった一言なのですが、これがプロジェクトの失敗に繋がるかもしれません

ここで指すプロジェクトの失敗というのはQCDが守れない状態です。いわゆるQuality(品質)、Cost(予算)、Delivery(納期)というのが守れない状態のことを指します。

ではプロジェクトを失敗させないためにはどうしたら良いのでしょうか。先ほどの例をもとに少し考えてみたいと思います。

①「この前FIXしたデザインですが、部長からフィードバックがあり、修正をお願いします」

こちらはあるあるですね。突如現れる強い権限を持ったステークホルダーの登場です。これはスケジュールにないフィードバックとなっていまして、納期遅延の可能性であったり、想定になかった修正となるため、あらかじめ見積もっていた修正回数からも修正が増えたことで工数超過にも繋がります。

②「この部分は御社にやってもらえると思っていました」

こちらはスコープのお見合いです。よくありますね。例えばテキストライティングとか、あとは素材提供、画像購入などがよく話題に上がるんじゃないかなと思っていまして、もし自分たちが対応するとなった場合なのですが、タスクが増えてしまってスケジュールが遅延したりですとか、あとは工数超過の可能性があります。

また「すみません、できません」となった場合ですね。最初に一緒に良いものを作っていきましょうという風に意気込んだりすると思うのですが、そんな手前制作会社としてのスタンスというのが疑われてしまったり、余計な不信感を生む恐れがあります。

③「自分の端末で見たら崩れていました」

これは他と違ってかなり各論なのかなと思っていまして、私も言われたことがあります。その時は新発売のタブレットを使っての指摘でしたので、検証のために同様のモデルを手に入れるのが難しく、先方から送ってもらって検証したことを今でも覚えています。

こちらの事象の要因は、品質担保条件でいうところの合意不足です。

制約条件や前提条件になると思いますが、そちらの合意不足が考えられます。

これも対応することになった場合に、スケジュール圧迫や工数超過の可能性が考えられます。「やらない」という判断になった場合においても、結構説明が必要だったり「何でやってくれないのか」という不信感に繋がってしまうかもしれません。

ディレクターというのはクライアントとも関係性が重要になってくるので、やはりそこはちょっと痛手になってしまうかなと思っています。

 

プロジェクトが成功するためには

ではどうやったらプロジェクトが成功するのでしょうか。私が心に刻んでいる言葉があります。

プロジェクトの要は計画にあり

ニジボックスではディレクターもPMBOKを参考にしながらプロジェクトマネジメントを学んでいます。

PMBOKは簡単に説明しますと、Project Body of knowledgeの略称でプロジェクトマネジメント協会が発行しているものになります。

プロジェクトマネジメントの知識を体系化したもので、プロジェクト管理において必要な指揮体系となっています。いわゆるプロジェクトマネジメントのガイドラインみたいなものにです。少し前に第7版が出てすごく話題になったのですが、ちょっと内容が変わったりしたのですが、プロジェクト管理方法自体に関しては、大きな軸は変わっていないんじゃないかなと私は考えております。

PMBOKに基づいたプロジェクトマネジメントというのは、様々な「プロセス」と呼ばれるプロジェクトの流れがあるのですが、その内容のほとんどが「立ち上げ計画プロセス」というものに宛てられています。そのためプロジェクトの初期段階がすごく重要であると言えます。

そういった大事な初期段階・初動段階というところでは、

・どうしてこのプロジェクトから生まれたのか
・何を達成しなければいけないのか
・納品物は何か
・納品物にはどんな機能が必要とされるか

といった点が、それぞれもれなくクライアントと制作側で共有しておく必要のあるものです。

特にスケジュールがタイトな案件もあると思いますが、そんな時こそなおさら計画というところにしっかりと時間を割くことが大事です。なぜディレクターがPMBOKを学んでいるのかですね。

プロジェクトマネジメントはプロジェクトマネージャーがやるもののように感じるのですが、ディレクターは基本的にそのプロジェクトの責任者になることが多いと思います。

ニジボックスも以前はそうでしたが、各々の今までの経験ベースでプロジェクトを進めるとか、属人化している部分が多かったりですとか、言った言わないとか、エビデンスがありませんので対応せざるを得ないとか、様々なトラブルがあったりしたのですね。

特に、先ほどの繰り返しになってしまいますが、納期が厳しく走るしかないという案件こそ、沢山のトラブル要因・リスクを含んでいるのですが、計画を立てずにスタートしてしまいがちです。結構ニジボックスもそういうことが多くありました。

そこでニジボックスでは、体系化されたプロジェクトマネジメントの方法である、PMBOKというものを活用することとなりました。ではPMBOKを学んだニジボックスでは、どのようにそれらを活用しているかこれからお話ししていきたいと思います。

 

「プロジェクト計画書」とは?

すごく単純な話にはなるのですが、ニジボックスではプロジェクト計画書というものを作成しています。ざっくりと全体像を先に説明させていただきますと、プロジェクト概要、プロジェクト体制図、プロジェクトのスコープ、制約条件である対応ブラウザー、最後にコミュニケーション計画といったものになります。

これらは日々アップデートされているので、現在のバージョンの中身について次から説明していきたいと思います。少し手前味噌な部分があるかもしれないのですが、それはちょっと暖かい目で見ていただけると助かります。

まず最初にプロジェクトの概要を整理します。

書いてある通りなのですが、

・プロジェクト名
・リニューアル対象のURL(リニューアルであれば)
・目的
・背景
・要求事項
・成果物
・前提条件
・制約条件
・マイルストーン

となっています。成果物に関してはこのような準委任の場合は「業務内容」に変わったりします。

このように目的や背景、要求事項を改めて整理したりですとか、成果物を定義して前提条件や制約条件を擦り合わせる、マイルストーンを確認する、そういったことでこのプロジェクトの全体像というのが見えてくる、一番重要な部分となっています。

また一番上にあるプロジェクト名が意外と大事だったりします。どういうプロジェクトか端的に表す名前を付けられるというのがすごく重要でして、プロジェクトがスタートするとその呼称が使われるので、他の人が聞いても「あの案件ね」となるのが望ましいと考えています。

あと今モザイクがかかっている部分はテンプレートになってまして、ゼロイチで作るというよりは各項目の中にどの案件でも当てはまりそうな内容であったり、社内で「ちょっとこれヒヤリハットしたから入れておこう」といった内容が初めから入っています。

それらを案件ごとに必要に応じて削除や追記をします。こういったテンプレートを作ることで、属人化しにくく、体系化できるようにしています。

次に体制図を可視化します。ここで重要なのは意思決定者の把握と確認です。それをすることで突然現れる鶴の一声みたいなものを防げる可能性が高くなります。

また例えば、開発ベンダーが他にいる場合ですね。その場合もこちらに記載しておくことでそれぞれの役割分担が明確になりますし、開発ベンダーの役割も確認できます。

開発ベンダーだけではなく、例えばデザインが別会社であったりですとか、他の会社さんと一緒でやることも多いと思いますので、そういった全ステークホルダーをなるべくここで網羅するようにはしています。

ここでは改めてプロジェクトのスコープを確認します。

改めて言語化して整理することも重要ですし、スコープ対象外領域ですね。つまり「やらない事」を定義することもすごく重要となります。

ここで「やってくれると思っていた」というのが解消されますし「そういえばこれってどっちがやるんでしたっけ」といった内容を確認できたりします。

次に少し各論にはなるのですが、開発や実装も自社内で行う場合です。こういったスライドも追加しています。

OSやブラウザのバージョンであったりですとか、確認端末はどこまで見るのか、あとは細かい部分なのですが、iOSの場合はSEやPro Maxも見るのかどうか。Androidもどこまで見るのかというのはよく議論に上がるので、それを事前に確認しておくことができます。

またランドスケープやタブレットへの対応はどうするのかについてはこちらに記載しております。

最後にコミュニケーション計画ですね。プロジェクトのコミュニケーション方法というのを確認します。意思決定であったりとか、合意形成でどこで行うかであったり、どういったツールを使っているのか、セキュリティが問題ないかということがここに書いてあります。

意思決定であったり、合意形成の場をはっきりさせておくことで、例えば「この定例会には意思決定者の〇〇さんを必ず同席いただくようにお願いします」と言ったりですとか、どこの場で合意形成したいのかをすり合わせが行えます。またどういったツールを使うのか都度確認する必要がないというところも利点になります。

結構今の状況ですとオンライン会議ツールはGoogleMeetにするのか、Teamsを使うのか、Zoomを使うのかといったことが結構ありますので、そういったこともここで確認できたりします。

あとはセキュリティの厳しい会社さんもいらっしゃると思いますので、どういったツールを使うのか、使って良いのかをここで確認します。以上がニジボックスで使用しているプロジェクト計画書の内容になります。

これらは通常ですね。社内キックオフとクライアントとのキックオフで確認します。

というのも、これらは作って終わりではなく、こういったドキュメンテーションをすることで全体を把握して、それを持ってクライアントと確認することが一番重要となってきます。

これを例えば送って「ここに書いてありましたよ」という感じですと、やはりクライアントも困ってしまいますので、確認すべきところは必ずクライアントと確認・合意を忘れずにするようにしましょう。

 

「失敗事例」から対策を考える

ちょっと時間がありますので私が経験した失敗談にはなってしまいますが、軽くご紹介したいと思います。

私の経験した案件でデザインは別のデザイン会社さん、弊社はフロントエンドの開発を行うという案件がありました。

デザインをSketchでしてもらっていていましたが、弊社ではSketchアカウントがなく「Zeplinでお願いできませんか」と伝えたのですが、実はZeplinですとアイコンなどを書き出すためにSketchのデータの体裁を整える必要がありまして、上手くいかずにデータ作成の手戻りが発生しました。

すごく時間と労力を要しまして、この事例のポイントとしては「何を使ってデザインするのか握っておく」ことです。今回の場合は、

・Zeplinを使う想定でデザインを作ってもらうこと
・データの書き出しはどちらがするのかを決めること

になるかなと思っています。

今までの例を見ていると分かると思いますが、前提条件ですね。プロジェクト概要の段階でそういったものは前提条件で握っておくべきですし、体制図でデザイン会社さんとの棲み分けをしっかり行うこと。あとはコミュニケーション計画でどのデザイン共有ツールを使うのか、デザインツール使うのかというのを共有することで、トラブルが防げたのではないかという事例です。

こういったプロジェクト計画書を作るようになったことで、ニジボックスで抱えるトラブルが格段に減りました。日々日々必要なものを追加したり、アップデートしています。

では少し話を戻しますが、

最初に出てきた事象はどうしたら防げたのでしょうか?

何を計画しておけば良かったのかということですが、

1つ目はステークホルダーを把握し、確認することです。先ほどのプロジェクト計画書で言うと体制図とか、またコミュニケーション計画がそこにあたるかなと思います。

2つ目に関してはスコープを把握し、確認することですね。こちらはプロジェクト概要の前提条件であったり、スコープの確認のスライド、あとは体制図でしょうか。これらをしっかりと計画しておけば防げたかなというものです。

最後はプロジェクト概要の制約条件・前提条件を把握し、確認することです。先ほどの例で言えばどの端末で見るのかしっかりと把握して、先方とを確認することです。これがすごく重要になってきます。

 

最後に

最後に「プロジェクトで目指すべきこと」のお話をさせていただきます。

これは私の持論ですが、

プロジェクトをハッピーに成功させること

だと思います。ディレクターであったり、プロジェクトマネージャーが計画をするということは、そのプロジェクトの道を作っていくことだと私は思っています。

ディレクターとしてプロジェクトの道を作りながら、その道に沿って進めるようにクライアントさんもそうですが、社内メンバーも含め、自分自身もハッピーにプロジェクトを成功させるために、ぜひこのプロジェクト計画書を生かして計画をしていただければと思います。

私からの説明は以上です。ご清聴いただきありがとうございました。

 

Q&A

Q1:計画書を作ろうとなった時に属人化から脱却したという認識でよろしいでしょうか?その際浸透させるにあたってどのような形で行いましたか?

小野里

この計画書を作って実際に運用できたという段階で、割と属人化から脱却できたかなと思っております。

やはりこういった物が形骸化しがちというのはもうおっしゃる通りだなと思っていまして、浸透させるにあたっては、みんなで協力して啓蒙し続けていくということが重要になってくると思っております。

最初の方で私の自己紹介で品質管理組織に所属しているとお伝えしたのですが、今はその品質管理組織の第三者機関的なところがこういった計画書を作っているか横断的に見て、やっていない場合はやるように促すということは行っています。

Q2:資料を見ていると横文字の単語が増えてきて、意味がぼやけてくることはないですか?

小野里

私ではありませんが、同じ会社の人が「ちょっと横文字が多すぎる」とクライアントから忌憚のない意見が来たと聞きました。横文字に限らず、単語が一人歩きすることはすごくあるなと思っていますね。その単語が何を指しているのか共通言語化するというところが大事ですので、それも計画書に書いて先方とすり合わせたりもします。言語化するというのが一番だなとは思いますね。

Q3.事前に合意はしたものの、それでも納期や追加要件で発破をかけてくるようなクライアントに対して心がけていることはありますか?

小野里

難しい質問ですね。そのクライアントさんとの関係にもよりますし、どうしてその納期や追加要件なのかお互いにすり合わせはします。「やってよ」「できない」などの言い合いになると生産性がない話になってしまいますのでどうしてそうなったのか整理した上で、どこを落としどころにするのか決めると良いですね。そこの調整がディレクターのすごく重要な仕事でもあります。

Q4:揉めてしまった場合に備えて、契約などにかけられる保険があれば教えてください

小野里

計画のところでどう進めるのか上手く握れない案件は往々にして揉めてしまうなと思っていますので、計画を始めるタイミングとか、始める前の段階であやふやな部分は作らずにしっかり握っておくことはすごく重要になりますね。

Q5.計画段階で各種情報を言語化・体系化されているとのことでしたが、どうしてもこの情報は言語化しづらいなと思ったことがあれば、教えてください。

小野里

言語化が難しいものは図示化します。例えば、紙1枚に図を描いて「こういうことですよね」と伝えた方が分かりやすい場合があります。図があることによってより理解度が増したり、認識がそろうことがありますね。

私はツールは何でも良いのかなと思っているタイプでして、私はPowerPointが多いですね。XDが得意な方はそちらを使ったほうが良いでしょうね。

Q6.資料ではプロジェクト管理ツールとしてBacklogを利用していると記載がございましたが、プロジェクト参加外のメンバー(上役など)にプロジェクトの進捗状況を説明する際に何か良いツールがあれば教えてください。

小野里

Backlogはエクスポートできたと思いますので、そちらをしても良いのかなと思いますし、最初から入れないと分かっているのであればスプレッドシートなどで共有するのも良いでしょう。またはキャプチャーを取るなどですね。

これはBacklogを利用していないユーザーも進捗確認ができるようにして欲しいという依頼だと思いますので、その依頼を事前に受けておいて、そのためのプロジェクト管理方法に変えていくというのが良いのではないかと思います。

Q7.日頃Webディレクターとして働いている中で、いわゆる普通のサイト案件はそれなりに数もこなし、経験を積んでいるのですが、これからはCMS領域やシステム案件も求められています。それらの経験や知識を得るにあたり、留意すべき事やポイントなどがあればぜひ教えてください。

小野里

難しい質問ですね。経験や知識を得るにあたってはやはりシステムとかCMSとかですとやはりやってみないと分からない部分がやはり正直多いかなと思います。私の場合はTwitterやNoteなどで情報収集をして活用したりもしていますので、そういった感じで進めたりですとか、弊社ですとノーコードツールのようなものが流行っているのですが、無料で触れるものもありますので、そういったものに触れてみるのも良いと思いますね。進んで新しいものに触れていくことで知識が溜まっていくと思います。意外と関係ないと思われる知識も実は繋がっていたりすることも往々にありますね。

私はポイントポイントでインプットする癖がありまして、「この本、初めて読むのにすごく既視感がある。あっ、そういえば以前読んだ本に似たような考え方が書いてあった」といったことは原体験としてありますので、そこは他の仕事でも生かせるんじゃないかなと思っております。

Q8:プロジェクト計画の立て方を教えてください。

小野里

疑問が浮かんだらすぐに聞いて解決する。これがすごく重要だなと思っています。それは特に計画の段階ですごく重要です。

私の経験上「あとでいいか」と先送りしたものは絶対後で困るんです。

そういったものを敏感に察知していくというのがすごく大切です。その上で計画を立てることで揉めごとも防止できますし、先方との関係性も上手く進んでいくのではないかなと思っています。

本応募フォームで取得した回答内容および個人情報は、株式会社メンバーズグループ各社、株式会社 ニジボックスがお取り扱いいたします。

ブラウザによりお申込みフォームが表示されないケースがございます。
フォームが表示されない場合や、その他ご質問等がございましたら、お手数ですが下記運営事務局までご連絡のほどよろしくお願いいたします。
メールアドレス:m_mc_pgtbs_mkg@members.co.jp