CLOSE

PJメンバーで共有する「プロジェクト憲章」ことはじめ(全2記事)

Webディレクターの愚痴は誰のせい? メンバーが自発的に動くための“プロジェクト憲章”

プロジェクトに関わるすべての方のための祭典、Backlog World。3回目の開催となる「Backlog World 2021 旅 ~Journey~」は、プロジェクト管理に関する知見を相互に高め合うことを目的として開催されました。ここで、株式会社サービシンクで代表取締役兼テクニカルディレクターの名村氏が、「PJメンバーで共有する『プロジェクト憲章』ことはじめ」をテーマに登壇。まずは、プロジェクトマネジメントでプロジェクト憲章が必要な理由を紹介します。

自己紹介

名村晋治氏(以下、名村):「PJメンバーで共有する『プロジェクト憲章』ことはじめ」ということで、時間をいただきたいと思います。まず簡単に自己紹介をします。私は名村晋治です。株式会社サービシンクで代表取締役を務めています。テクニカルディレクターで、開発の現場、制作の現場に携わっています。インターネットを始めたのが1994年ぐらい、1996年からこの仕事を始めて、26年ぐらいになってしまいました(笑)。

2000年ぐらいからは不動産検索サイト「HOME’S」、今のLIFULLという会社でディレクターをしていました。2005年からは制作会社で役員を務め、2010年に株式会社サービシンクを立ち上げて、2021年3月現在で、だいたい23名ぐらいで仕事しています。

2005年ぐらいからWebディレクターという肩書きをずっと使っていて、それに関してのブログを粛々と書いています。もし興味がある方がいれば、ぜひ見てもらえればと思います。

あとは、2020年の夏ぐらいからPodcastを始めました。毎週金曜日の23時から24時ぐらいに、だいたい30分ぐらいのPodcastを更新しています。Webディレクターに何かちょっと疑問や質問があれば、それに答えるようなことを30分ぐらいしゃべっているので、こちらもぜひよろしくお願いします。Twitterなどで疑問、質問を受けつけているので、そちらもお待ちしています。

講演テーマと前提条件

それではさっそく、今日の講演のテーマについてです。まず、プロジェクトマネジメントとは、について。そして、メンバーが自発的に動ける条件を作っていきましょう、と。その後、プロジェクト憲章とフォーマットについての話をしようと思います。

みなさんに対して、1つだけ大前提ということで伝えたいと思います。正論は正解ではありません。これから私は、すごく理論立ったことを言うかもしれません。「確かにそうだな」と思うかもしれませんが、すぐに現場で使えるわけではありません。みなさんが現場の中でどのように使っていくか、という視点も考えてもらえればと思います。

あとはみなさんの会社で、Backlogのようなチケット管理システムを含めて使っているかどうか。そして、今日の私のゴールとして考えているのは、プロジェクトマネジメントをする上で、“メンバーをどうやれば迷わせないか”です。今日の話を聞いて何か使えるなと思った方々も、導入には一定の時間が必要なことは忘れないでもらえればと思います。

プロジェクトマネジメントとは何か

では最初、プロジェクトマネジメントとはですが、実はBacklogさんのサイトに書いているとおりです。こんなふうに書かれています。「プロジェクトマネジメントとは、納期が決められているプロジェクトをどのように遂行すれば成功するのか、詳しく計画を立ててコントロールしていくこと」と、定義されていました。

プロジェクトと呼ばれるものは、必ず始まりと終わりの納期が設定されているのが大前提になってきます。そしてここに書かれているとおり、どうすれば成功するのか。成功させなければならないわけです。そのためにプロジェクトマネジメントが存在していることになります。そのために、PMBOK(Project Management Body of Knowledge)と呼ばれる体系立った学問があります。

PMBOKでプロジェクトマネジメントは体系的に作られているので、もしかしたら聞いている方々の中に、これをちゃんと勉強した方もいるかもしれません。もしよければ『プロジェクトマネジメント知識体系ガイド PMBOKガイド 第6版』などを手に取ってもらえればと思います。ちょっと高いです。1万円超えてくるかもしれませんが、プロジェクトマネジメントにとってはすごくいい本です。

どのように人に動いてもらうか?

私のちょっとした経験です。私は今、ディレクターという仕事をしています。ディレクターの仕事は多岐に渡りますが、困った経験がたくさんありました。要件定義をするのも大変だし、お客さまとの折衝、そしてプレゼンテーション。現在の私がそうなように、ものすごく緊張します。進行管理も大変だし、クオリティ管理もしなければいけません。これらの中で、困ったことがいっぱいありました。

その中で、今日のテーマになってくるのが「どのように人に動いてもらうか?」というところです。プロジェクトマネジメントをしていく中で、どのように動いてもらうのかに、今日は少しフォーカスを当てて話をしたいと思います。

もしWebディレクターの方がいれば、口に出してはいないけど、こんな愚痴を思ったことがある方はいませんか?

「自分はクリエイティブの細部まで詳しくないから、各自がもっと自主的に動いてほしい」「なんでもかんでも、みんな全部ディレクターに聞いてくるよね」。こういうことを思った方がいるかもしれません。でも、それは本当ですか? 本当にディレクターのその愚痴は、ディレクターはがんばっているのにもかかわらず、他のメンバーが全部押しつけているんでしょうか?

メンバーが自発的に動けない理由

ということで、メンバーが自発的に動けない理由を、ちょっと読み解いていきたいと思います。ディレクターの愚痴は、むしろディレクター側に責任があるからそうなっているのだと私は考えています。なぜでしょう。動けないのには理由があります。

そもそもクリエイティブのメンバーは、自分が何をしたらいいのかがわかりません。そして、自分で調べようと思っても、その調べたい情報、知りたい情報がどこにあるかわからないわけです。

Webディレクターの方、もしかしたらこういう指示を出していませんか? 「僕がワイヤーを書くから、デザイナーはそれをいい感じにビジュアルデザインしてくれ。構成要素は僕が責任を持って必ず書き込むから。マークアップエンジニアは、それをHTMLにしてもらいたい。クライアントはブラウザーで見たときの動きを気にしていたから、野暮ったくない動きを任せたいと思っている」。

こんな指示を出している方はいませんか? でもこの話を聞いたとき、きっとクリエイターはこう思っています。「ほしい情報、それとちゃうねん!」「そんなのは知っとるわ!」みたいな話がくるわけです。

クリエイターにとって必要な情報

では、クリエイターの方たちが必要な情報とはなんでしょう。クリエイターの方たちが、クリエイティブを発揮するために必要な情報です。そもそもなぜこれをするのか。というか、相手はいったい誰か。何ができたらOKがもらえて、それは実際にどのようにやって、いつまでに終わらせなきゃいけなくて、いくらで受注している案件なのか。いくら予算を投下できる案件なのか。こういった情報を、ちゃんとクリエイターの方々に提供しなければいけません。

こういった前提がない中で、ディレクターはよく言います。「デザインはデザイナーさんに任せたい」「うまくやってもらいたいと思っているから」と。違います。前提条件がわからなかったら、動きようがありません。

自主的に動くというのは「あの条件であれば、ここまでやったほうがいいな」をクリエイターの方が考えるための情報です。その条件が与えられなければ、言われたとおりにするしかやりようがありません。さらに言われている情報が少なければ、ディレクターが思い描く以上のものを作れるはずがありません。想像ができないからです。

今日のこのあとのテーマです。どうやればいいのかですが、「クリエイターの方たちに、ちゃんとした情報を提供しましょう」ということが、すごく重要になってきます。Webディレクターの責務は、仲間への情報整理をし、共有すること。これを忘れないでほしい。そしてそのために重要なのが、今日のテーマの“プロジェクト憲章”と呼ばれるものです。

プロジェクト憲章とは

それでは、プロジェクト憲章とフォーマットについて紹介したいと思います。プロジェクト憲章とはそもそも何でしょうか。これは先ほど紹介したPMBOKに書いてありました。ちょっと読みます。「プロジェクト憲章は、プロジェクトの存在を正式に認可する文書であり、プロジェクトのイニシエーターまたはスポンサーが発行する。

プロジェクト憲章は、プロジェクト・マネージャーが母体組織の資源をプロジェクト活動のために使用する権限を与える。プロジェクト憲章を通して文書化されるものとして、ビジネス・ニーズ、前提条件、制約条件、顧客ニーズの理解範囲、ハイレベル要求、新しいプロダクト、サービス、あるいは所産が満たすべき要求事項がある。」と書いてありますが、何が書いてあるかよくわからないですよね。僕もよくわかりません(笑)。なので、もうちょっと読み解きましょう。

どんなことが必要なのか。まず、プロジェクトの目的を書く必要があります。そして、プロジェクトのゴールも定義する必要があります。プロジェクトの概要、どこまでの作業をするのかと、さらには前提条件・制約条件、ハイレベルな要求事項、予算、リスク、そしてマイルストーン、概要のスケジュールです。

あとは、クライアントはどういう人なのか。我々の会社、サービスとどういった関わりをもっているのかを、リスト化することも定義されています。一応最後に誰が作ったかという名前の共有がありますが、一般的に書くのであれば最低限1(プロジェクトの目的)から9(ステークホルダーをリスト化)。10(プロジェクトマネージャーの名前)はわかると思いますが、9までのことは書いて、メンバーに共有していかなければいけません。

このプロジェクト憲章がなぜいるのかは先ほどご紹介しました。そもそも何をするのかを共有する。そして共有したことによって、クリエイターが自由活発に動ける条件を作るためです。クリエイターは決して作業者、ディレクターが言った作業をしてくれるメンバーではありません。

頭のほうから「想像から創造」と書きましたが、前提条件が与えられるからこそ、「ここまでやれるのかな」「どうやったらいいのかな」「よし、じゃあこんなものを作っていこう」に持っていけるのが、プロジェクト憲章で一番重要な内容です。

(次回につづく)

続きを読むには会員登録
(無料)が必要です。

会員登録していただくと、すべての記事が制限なく閲覧でき、
著者フォローや記事の保存機能など、便利な機能がご利用いただけます。

無料会員登録

会員の方はこちら

関連タグ:

この記事のスピーカー

同じログの記事

コミュニティ情報

Brand Topics

Brand Topics

  • 今までとこれからで、エンジニアに求められる「スキル」の違い AI時代のエンジニアの未来と生存戦略のカギとは

人気の記事

新着イベント

ログミーBusinessに
記事掲載しませんか?

イベント・インタビュー・対談 etc.

“編集しない編集”で、
スピーカーの「意図をそのまま」お届け!