BacklogWorld 2019 の運営スタッフを終えて

先ずは感想と感謝の気持ちを込めてご報告から。1/30(水) 夕刻、イベントの振り返り会 を終えて全てのミッションを終了しました。ヌーラボの皆様、他 JBUGスタッフの皆様 本当にお疲れ様でした！BacklogWorldの運営に関わってから あっという間の半年間、駆け足ではありましたが 大変有意義な時間となりました。この経験を また来年に還元出来たら幸いです。

また、秋葉原UDX の会場に脚を運んで頂けた来場者の方にも感謝しなければいけません。300人というキャパの中、あれほどの熱量、熱気をもったイベントもなかなか見当たらない中、冬という季節柄にも関わらず、午後以降の動員数は凄いものがありました。秋葉原という沿線上に隣接しているアクセスの良さも少なからず影響したと思います。次回、2020も記憶に残るイベントに出来るよう運営スタッフで一層努力して参ります！

reCapミートアップの再演イベントもありますので、当日どうしても都合悪く行かれなかった方、やっぱり行っておけば良かったと後悔して夜も眠れない方、是非 お気軽にいらして下さい。

プロジェクトマネジメントはプロマネのためのプロマネによる手法に非ず

さて、ここからが本題です。つい先日、職場の問題かるたでお馴染みの 沢渡あまねさん(@amane_sawatari)が このように呟いておりました。これが 会話のトリガーとなって、PMBOK は やはり、当事者以外の関係者には難しいよねと話しは進んでいきます。そう、確かに理解するには厳しいのです。

PMBOK "ピンボック"とはなんぞや

プロジェクト管理を実践していくバイブルとして、PMBOK（Project Management Body of Knowledge）と呼ばれるものがあります。何かと申し上げますと、建設業、製造業、ソフトウェア開発などのプロジェクトに適用できるプロジェクトマネジメントの基盤を提供する国際的にルール付けされた手法のことを差します。界隈では、頭文字を取って"ピンボック" と称されてますが、和訳は「プロジェクトマネジメント知識体系ガイド」の略称になります。なんのこっちゃと思われますが、分業制がまかり通っているWEB業界だからこそ知っておかなければいけないお約束ごとです。

プロマネだけが知っておくべきことなのか？

沢渡あまねさんが仰るとおり、現場監督が役割のプロジェクトマネージャーだけ知っておけばいいというものでもなく、プロジェクトに関わっているステークホルダー全員が知っておかないと同じ道筋を辿っていくことは難しいとさえ思います。ただ、ご存知の通りPMBOK自体は、「10個の知識エリア（他9個の知識エリアを統合する総合マネジメント含む）と5個のプロセス」に体系化されています。

各知識エリアの詳細な内容は、ロフトワークさんで全文無償PDFで公開されている「Webプロジェクトマネジメント標準」をご参考頂けると大変分かり易いと思います。これらの知識体系は、目的とするものをどのような手段を用いてを具体化させられるかの定義でしかなく、結局のところ、炎上しないように予め火種を炙り出して消しておくことが最たる趣旨になってくる訳です。"プロセスを大事にしよう"とは良く言われたものですが、3大要素と目される Quality(品質)、Cost(原価)、Delivery(納期) は QCD管理とも言われ ドラクエで言うところの 最後のラスボス的な目標 となっていきます。

共通言語化として "ライト" な 軽いものが必要

プロマネやディレクターはさておき、この小難しいPMBOKの知識体系やらをチームのメンバー、又は外部のパートナー、果てはクライアントにまで共通ルールとして認識させるには、かなり高いハードルであろうと予測は付きます。ただ、だからこそ 共通言語化 は MUST であり、そうしないと安心してプロジェクトを進めるどころか、炎上して暗礁に乗り上げてしまうリスクを背負うことに成り兼ねません。

最低限、これだけ理解しておけば事故らないもの

とはいえ、10個も知識体系があるし、5個のプロセスも全部やらなければいけないのか？という発想に陥りますが、決してそうは思いません。必要最低限のルールをきちんと守りさえすれば、自ずとゴールは見えてくるものです。共通言語化できる判断材料として そこだけピックアップして共有すれば、皆 ハッピーに近づけると信じています。

少々前振りが長すぎたので、、次回へ持ち越します！ 次は、Twitterで呟かれた事例も交えながら、抑えておくべきポイントと、これだけ知っておけば炎上しない最適解を導き出すルールを作れたらと思います。

＜後編へ続く＞