Web制作のプロジェクトマネジメントの目的とは？PMBOKから学んでみた

Webディレクターのリリィです。

突然ですが、「プロジェクト・マネジメント」って何のことかわかりますか？ 正直、聞いたことはあるけど説明できない人が多いのではないでしょうか。わかるようでわからない言葉、「プロジェクトマネジメント」。

知ってる！ 説明できる！ というあなた、すごいです、尊敬します。

改めてプロジェクトマネジメントのことに学んでみました。すると、PMの仕事と思われがちなプロジェクトマネジメントが、実はプロジェクトに関わるすべての人にとって非常に重要な概念だったので自分の仕事に照らし合わせてまとめてみようと思います。

今回は、プロジェクトマネジメントの考え方、概念の部分をメインに紹介します。

PMBOKについて

さて、ここでタイトルにも掲載しているPMBOK（ピンボック）についてです。

PMBOKとは

PMBOK（Project Management Body of Knowledge）とは、プロジェクトマネジメントに関するノウハウや手法を体系立ててまとめたものです。1987年にアメリカの非営利団体PMIが「A Guide to the Project Management Body of Knowledge」というガイドブックで発表してから徐々に知られるようになり、今ではプロジェクトマネジメントの世界標準（事実上の標準）として世界各国に浸透しています。
参照：【第１章】PMBOKを理解しよう：PMBOK とは

調べ始めるまで、プロジェクトマネジメントの世界基準があるとは全く知りませんでした。プロジェクトマネジメントにおいて、共通の考え方があるならまずはそこからインプットしていきたいですね、というわけで、闇雲に勉強するのではなく「PMBOK」の考え方をお手本に進めてみます。

ただし今回は、特にWeb制作領域に絞ってまとめ直してある『Webプロジェクトマネジメント標準』を参照します。

定義の確認

横文字が苦手なので、いかにもビジネスっぽいカタカナ用語が出てくるとオロオロしますが、気を取り直して、まずは前提としてどんな定義で使われている言葉か理解を深めていきます。

プロジェクトとは

プロジェクトという言葉も普段から何の気なしに使っていたので、案件=プロジェクト程度にしか考えていませんでした。しかし、PMBOKの考え方ではプロジェクトにもしっかり定義があります。

プロジェクトマネジメントを推進する代表的な機関である米 PMI(プロジェクトマネジメント・インスティチュート)が発行する PMBOK(ピンボック= A Guide to the Project Management Body of Knowledge /プロジェクトマネジメント知識体系)では、プロジェクトを 2 つの要素で定義しています。「有期的であること」、そして「独自性があること」です。
引用元：林 千晶,高橋 宏祐 著『Webプロジェクトマネジメント標準』(技術評論社、2008年)

なんだか難しく書いてありますが、毎回異なる制作物が求められるWeb制作で発生する仕事は規模の大小を問わず、すべて「プロジェクト」であるということですね。もっというと、Web制作に限らず「期限があって、新しい試みを含んだ仕事」はみんなプロジェクトになりますね。

マネジメントとは

プロジェクトマネジメントの後半のワード「マネジメント」。こちらもよく言う意味合いでは「管理」でしょうか。PMBOKでの定義を確認します。

「マネジメント」と聞くと「管理」という言葉を連想しがちですが、プロジェクトマネジメントは、むしろ「プロジェクトを確実に成功させるための道筋づくり」とでも考えると理解しやすくなります。そして、その方法を体系化したフレームワークがPMBOKなのです。
引用元：林 千晶,高橋 宏祐 著『Webプロジェクトマネジメント標準』(技術評論社、2008年)

あっさり「管理」とは少し違うと書いてありました。プロジェクトそのものをスムーズに進行することがPMBOKにおけるマネジメントのゴールになります。ただ管理するだけではないのですね。

プロジェクトマネジメントを理解するためのヒント

ようやく定義がはっきりしたところで、それではプロジェクトマネジメントをすることで、どんないいことがあるのか実体験を振り返りながら考えてみます。

マネジメントのなかに9つのエリアがある

一言でプロジェクトマネジメントといっても、じゃあ何をするの？ という気持ちになる人も多いでしょう。ここでは方法論は割愛して、どんなマネジメント領域が含まれているのかを以下に挙げてみます。

• プロジェクト全体
• スケジュール
• スコープ
• コスト
• 品質
• 人的資源
• コミュニケーション方法
• リスクマネジメント
• 調達管理

これだけだと、「で？」って感じですね。私もそう思いました。

でも大丈夫、具体的に考えると「ああ、確かにそうだそうだ」と身に覚えがあるはずです。

• プロジェクト全体

プロジェクト全体の責任者として案件の概要を把握。これができていると、第三者への共有などもとてもスムーズにできてハッピー。

• スケジュール

言わずもがなのスケジュール管理。

• スコープ

この作業はLIGで担当します、この作業はお客様お願いしますね、という線引き。ここが曖昧だと後にトラブルになることも……。

• コスト

適切な費用（工数）の算出、工数の範囲内で稼働できるよう調整する一連の管理。

• 品質

できあがった成果物のクオリティは担保できているか？ 要チェック。

• 人的資源

チームで制作するならメンバーのアサイン次第でプロジェクトの成否も変わるポイント。

• コミュニケーション方法

プロジェクトチーム内でどうやって意思決定をとりますか？ 定例ミーティングの頻度はどうしましょうか？

• リスクマネジメント

問題になる可能性があることは先に把握しておきたい。事前に洗い出して対策を立てましょう。

• 調達管理

外部業者にデザインだけ発注することなったら、その契約管理が必要。

分解された項目を見ると、プロジェクトにおいてはすべての作業工程に何らかのマネジメント領域があることが改めて分かります。そして文章だけ見ると、何から手をつけたらいいのやら……（困惑）となりそうですが、実務に置き換えると何気なく対応していることもちらほら。今後は、何気なくではなく意図的に取り組みましょう！

アウトプットを残すこと

次なるヒントはアウトプット。この場合のアウトプットとは、仕事や作業の結果を形として残したもののことを指しています。なぜこれがわざわざ項目として選出されているのか気になりますね、このあたり、背景も理解すると続きが非常に納得感があります。

日本は欧米のような契約社会と違って、アウトプットを残すという文化がこれまであまり意識されてきませんでした。ひとつの案件にかかわるメンバーに変化がなく、案件で達成すべきミッションに毎回大きな違いがなければ、アウトプットを意識しなくても問題はほとんど起こらなかったからです。

しかし、ウェブ制作のように、かかわるスタッフが毎回異なり、求められる成果物も千差万別であるプロジェクトでは、それぞれのプロセスで何が生み出され(=アウトプット)、それが次に何の作業につながるのかを意識することが必要になります。
引用元：林 千晶,高橋 宏祐 著『Webプロジェクトマネジメント標準』(技術評論社、2008年)

これ、思わず頷いてしまいますね！ というのも、大きな声で言えないですがやはりプロジェクトの中で誰かが「よしなに」やっておいてくれていることがまだまだあるなと思います。例）、明確な定義はなかったが、エンジニアさんが辻褄が合うように修正してくれた、など

そして、LIGではBiTT事業部に所属しているセブ支社のエンジニア（つまり外国人）と一緒に開発をすることもよくあります。すると何が起きるか。普段日本人のエンジニアさんが「よしなに」やっていてくれていたことは、依頼していないので対応してもらえません。

当然ですが明確に定義しなければ対応してもらえないのです！ つまり、依頼内容であれデザインであれ、確実にアウトプットを残すことがとても重要です。

そんな背景や苦い思い出があったので、強く頷いてしまいました。上記の例では「定義書」が該当しますが広い意味ではそれだけではありません。すべての作業の結果としてのアウトプットが対象です。

残したアウトプットを循環して次のインプットへ

アウトプットを残すことはもちろん重要なのですが、さらに重要なのはその先です。とあるプロジェクトが進む過程でできあがったアウトプットはすべて、言い換えると経験と実績という資産になります。

たとえば、苦労して仕上げた要件定義書も、参考デザインを探しに探したまとめも、検証を繰り返したコードも、すべてです。これらが、次回のプロジェクトにおいてのインプットとなり、経験に基づいて質を向上させながら循環してきます。

PMBOKではこの流れを「インプット→ツールと技法→アウトプット」というプロジェクトマネジメントに必須の方法として定義されています。

プロジェクトごとにKPTを実施、次回に活かしていくというのは社会人の皆様にとってはある種当然の試みかとは思いますが、制作フェーズにおけるすべてのアウトプットを次回のインプットとする、というのは改めて考えるとこれまで特別に意識してこなかったな、と反省しました。

もちろん、「以前のプロジェクトでこういうことがあった。だからあれを参考にしよう」という経験則に基づいた判断をすることは誰しもしてるはずです。PMBOKの考え方では、そういった「以前のプロジェクトのあれ」をアウトプットとして明確にしておきましょう、とあえて方法論になっているのですね。

プロジェクトマネジメントはただの管理ではない

ここまで見てくると、PMBOKの提唱するプロジェクトマネジメントとは、ただプロジェクトを管理するだけのものではなさそうなことがよくわかりますね。先述の通り根底には「プロジェクトを確実に成功させるための道筋づくり」という考え方があると理解できます。

そのために必要なスキル、経験、知識は多岐にわたりますが、PMBOKではそれすらも「前回の失敗」をインプットとして、これからのプロジェクトのクオリティを向上させるために必要なこととしています。

そしてクオリティが向上すると、制作陣のスキル・経験も向上し、さらに次回のプロジェクトのクオリティが向上する好循環となる、といういいことづくめ！ これがプロジェクトマネジメントの本質であり、最終目的でもあるのです。

Webディレクターに限らず、プロジェクトに関わるすべてのメンバーが概念として知っておきたい部分かと思います。プロジェクトに取り組む際の大前提、勉強になりました。

概念を押さえたところで、これからは具体的な方法論に進んでみようと思います。それではまた次回！

LIGはWebサイト制作を支援しています。ご興味のある方は事業ぺージをぜひご覧ください。