エンジニアとしてキャリアアップを考える際、ぜひ身に付けておきたいのがプロジェクトマネジメント(PM)のスキルだ。特に近年のシステム開発プロジェクトは低予算化・短期化が進んでおり、ただでさえ計画どおりにプロジェクトを運営することは困難になっている。こうした中、多くの現場で「経験のあるプロジェクトマネージャが不足している」という声を聞く。
しかし、PMスキルを実際に習得するとなると、これがなかなか難しい。ちまたにはPMBOK(Project Management Body Of Knowledge)をはじめとするPM関連の本があふれ、体系的に学習できる素材はそろってきた。しかし、実践的なものは少なく、理論と現場のギャップに戸惑うことも多々あろう。
そこで、この連載では実際の現場でよく見られるシチュエーションを取り上げながら、PMの実践的な勘所をケーススタディ形式で紹介していく。これからプロジェクトマネージャを目指す方はもちろん、すでにプロジェクトマネージャとして活躍されている方にも、「知識」としてではなく現場で使える「スキル」を磨くうえで役立てていただければ幸いである。
プロジェクトマネージャとは、何をする人だろうか。あなたの身近にいるプロジェクトマネージャを、ちょっと想像してみてほしい。
一般に「プロジェクト」とは、何らかの目的の達成を目指して、一定期間に行われる活動のことをいう。目的の大小や期間の長短は関係ない。会計システムの導入も、Webページの制作も、プロジェクトという意味では同じである。仕事に限らず、受験や就職、結婚や出産といった人生のイベントすべてがプロジェクトであるという人もいる。そういう意味では、あなたはすでに何らかのプロジェクトを手掛けた経験を持っているはずだ。あなたの身近にいるプロジェクトマネージャは、あなたよりほんの少し複雑で、ほんの少しリスクの高いプロジェクトを手掛けているにすぎない。
では、その人は普段どんな仕事をしているだろうか。プロジェクトの進ちょくの管理、顧客やユーザーとの折衝、人件費や費用の管理、要員の確保と配置、関係者への報告……。数え上げればきりがないほど、種々雑多な仕事が思い浮かんでくるに違いない。
しかし、プロジェクトマネージャの仕事は、本質的にはたった1つだ。それは、
プロジェクトを成功という1つのゴールに向かって導く
ということだ。
プロジェクトには目的があり、期限があるという点で、決まった作業を繰り返す「ルーチンワーク」とは異なる。中には、期間が数年にわたるような長期のプロジェクトもあるだろう。そういったプロジェクトの中にいると、ルーチンワークをこなしているような感覚に陥ってしまうことがあるかもしれない。しかし、あなたの気付かない間にも、プロジェクトの状況は刻々と変化している。期限に向かって、1日1日が費やされているのである。こうした中で、プロジェクトマネージャはプロジェクトを成功に導くために、「必要なことすべて」を行うのである。
しかし、「必要なことすべて」を思いつくまま漫然とやっていては、労力も無駄だし、抜けや漏れが生じる。「必要なこと」をやらなかったばかりに、後になって「本来やらなくてもよかったこと」までやる羽目になってしまうこともある。そこで本稿では、プロジェクトマネージャがプロジェクトを成功に導くためにやるべき「必要なこと」に焦点を当て、ケーススタディ方式で紹介していくことにしよう。
今回は、プロジェクトを1つにまとめるコミュニケーションの勘所を紹介しよう。
例えば、あなたがあるプロジェクトに参画することになったとしよう。その初日に、マネージャからプロジェクトのオリエンテーションがあるということで、あなたは打ち合わせに出席することになった。さて、ここでタイプの異なる2人のマネージャが登場する。
「今日は朝から忙しくて、ミーティングの予定でびっしり埋まってるんだよ」
「時間が取れないから、今日はプロジェクトに関するこの資料を読んでおいて」
「何か分からないことがあったら、後で質問するように」
「細かいことは、実際の作業をこなしながらキャッチアップしてくれよ」
「じゃあ、後はよろしく」
「今日は朝から忙しくて、ミーティングの予定でびっしり埋まってるんだよ」
「このミーティングには15分しか取れないから、要点を押さえて簡潔に進めよう」
「事前に渡しておいた資料は読んでもらったかな? 質問もまとめてきたね?」
「資料からだけでは読み取れない部分もあったと思うので、私から補足して説明しよう」
「まず、このプロジェクトの目的とその意義は……」
「次に、このプロジェクトのスケジュールと主なマイルストーンは……」
「次に、このプロジェクトのチャレンジ(克服すべき困難)は……」
「最後に、このプロジェクトの体制とあなたに期待する役割は…」
「では、残りの時間で、まとめてもらってきた質問のうち、いまの説明で不明な点があれば質問してほしい。じゃあ、始めようか」
さて、あなたは矢見雲マネージャのプロジェクトと、出来杉マネージャのプロジェクト、どちらに参加したいだろうか。
いきなりプロジェクトに投げ込まれ、右も左も分からないような状態に陥ることを望む人はいないだろう。やる気が起きるわけがない。プロジェクトにメンバーを新規で配属する際には、できるだけ明確にプロジェクトの重要事項、すなわち目的と期限、リスクと期待役割について説明しておくべきだ。
重要なのは、この動機づけをプロジェクト全体で一貫した形で行い、使命感を共有することだ。こうすることによって、細かい指示を与えなくても各自が状況に応じて適切に判断を下せるようになる。大きなプロジェクトであれば、新人向けの説明資料をひとまとめにしておくとよいだろう。プロジェクト開始時の企画書や提案書、計画書などを抜粋して、バインダーに綴じるなり、ファイルサーバの所定の場所に置くだけでよい。これだけの作業と、ちょっとした配慮だけで、新規にプロジェクトに参加するメンバーの不安を解消し、同じ方向に気持ちを向けさせることができる。
プロジェクトによっては、最初からスコープが流動的だったり、スケジュールが確定していなかったりすることがある。筆者の経験上、そのような場合は包み隠さず情報を公開した方がよい結果を生むことが多い。「ここまでは決まっているが、ここから先は決まっていない。最悪の場合、こういう事態に発展するケースが考えられる」というように、メンバーとリスクを共有して初めて、プロジェクトに一体感が生まれるのではないだろうか。
ちなみに、スカイライトコンサルティングでは、プロジェクトマネージャは新規のメンバーに対してプロジェクトの内容を説明することが義務付けられている。説明すべき事項が記載されたチェックリストは社員にも開示されているので、詳細に知りたいと思ったら、進んで説明を求めることができるようになっている。
さて、オリエンテーションも終わり、あなたはいよいよプロジェクトメンバーとして作業を開始したとしよう。しかし、これまでの経験とは異なり、プロジェクトの進め方やコミュニケーションなど、勝手が違うことに戸惑いを覚えてしまった。周りのメンバーも同じように感じているようだ。そこで、あなたはマネージャに相談することにした。
「はじめは、多少そういうこともあるだろう」
「慣れれば大丈夫だと思うから、もう少し様子を見て」
「問題があれば、また相談してくれよ」
「じゃあ、後はよろしく」
「プロジェクトの出だしで顧客とのミーティングが重なりバタバタしてしまった。申し訳ない」
「チームとして作業を進めていくに当たって、キックオフミーティングを開催しよう」
「そこで作業の進め方やコミュニケーションについての案を私から説明するので、みんなからも意見があればそこで出してもらって、このプロジェクトのやり方を決めよう」
「それから、新メンバーも加わったことだし、歓迎会をやろう。どんなところでやりたいか、皆考えておいてくれよ」
いくら優秀なメンバーが入り、適切に動機付けされたといっても、日々の具体的な作業がどのように進められていくかが決まっていなければ、足並みはそろわない。結果としてチームのパフォーマンスを引き出すことはできない。
プロジェクトマネージャは、個人の持っているパフォーマンスを、チームとして最大限に引き出すことができるよう、「円滑に連携」させる仕掛けをつくる必要がある。それが、「キックオフミーティング」に代表される、チームビルディングのためのイベントである。
キックオフミーティングでは、前項で取り上げたプロジェクトの重要事項の説明をさらに詳しく行うとともに、次のようなトピックについて説明しよう。
これによって日々の作業をどう進めていくか、ほかのメンバーとどのように協調すべきなのかが明確になる。特に会議体については、顧客や協力会社など、外部メンバーとの重要な接点であると同時に、何らかの意思決定の場でもあり、大変重要です。プロジェクト計画時にきちんと定義しておくべきであることはいうまでもないが、運営面で形骸化してしまわないよう、キックオフミーティングの場などでその位置付けを再確認し、メンバーの理解を高めておく必要がある。
さらに、出来杉マネージャが最後に「歓迎会」の開催を提案していたように、プロジェクトマネージャは次のような点にも配慮すべきだろう。
一見、仕事には直接関係ないことのようにも思えるが、プロジェクトの初期段階でメンバー同士がお互いに打ち解けた関係になっておくことは、非常に重要だ。欧米では、プロジェクトに限らずセミナーやワークショップなどでも「アイスブレーキング」といって簡単なゲームをやってリラックスした雰囲気を短時間で作ってしまうことが多い。日本では酒席をもうけることが一般的だが、やり方に関係なく共通しているのは、「お互いを知り仲よくなる」ことではないだろうか。それによって相手を気遣い、円満にコミュニケーションをしていく素地が出来上がる。
最後にもう一点、メンバーとのコミュニケーションは双方向でなければならない。プロジェクトマネージャは、自分のやり方を一方的に押し付けるのではなく、メンバーから意見を吸い上げる姿勢を持つことが大事である。これは、何もメンバーの意見すべてを尊重しろといっているのではなく、「現場に問題が生じたときに、速やかに情報を吸い上げる」環境をつくることが大事だということだ。
よく、食事時などにプロジェクトや上司の陰口をたたくような光景が見らることがあるが、これはあまり褒められたことではない。そういう場合は、得てしてプロジェクト内のコミュニケーションがうまくいっていない。メンバーが現場の問題や不満を抱え込まずに、素直に相談できる環境をつくることによって、初めてプロジェクトのリスクをコントロールできるようになるといえる。
あなたがプロジェクトについてから1カ月が経過した。プロジェクトにも慣れ、忙しい日が続いている。しかし、作業を進めるにつれ、チーム内では仕様に関する課題が目立ってきて、遅れが出てきた。そんなある日のチームミーティングで……。
「スケジュールが遅れているとはどういうことなんだ!!」
「みんなスケジュールは分かっているだろ!」
「深夜残業しても、土日を使ってでも、来週までにはなんとかキャッチアップしておくように」
「じゃあ、後はよろしく」
「当初のスケジュールに対して遅れが出ているようだが、原因は何だろう?」
「いろんな原因があるようだな。仕様が不明確で、顧客に対してその確認に時間を要しているメンバーが体調を崩して3日間休んだ。ユーザーから新たな要望が出ている……、などだ」
「遅れとなっている課題をクリアして、どうすればばん回可能か、担当者と一緒に考えてみよう」
実際にプロジェクトが進んでいくと、目的を達成するまでの道のりは決して平たんではなく、さまざまな阻害要因が発生する。プロジェクトマネージャは、これらの阻害要因を取り除きゴールへ導くことが求められる。これらの阻害要因は、PMBOKの定義に合わせると、以下の要素(エリア)に分類される。
伝統的な日本のPMは、3K(経験・根性・気合)とかKKD(経験・根性・度胸)などといわれてきたが、今日ではPMBOKを中心とする体系的なPMのあり方が整理されている。
次回以降は、これらの各エリアに対して、実際のプロジェクトに見られるシチュエーションとPMBOKなどが書かれているPM上のテクニックを織り交ぜながら解説していきたいと思う。
杦岡充宏(すぎおかみつひろ)
スカイライトコンサルティング シニアマネジャー。米国PMI認定PMP。関西学院大学商学部卒業後、アンダーセンコンサルティング(現アクセンチュア)を経て現職。製造業や流通業のCRM領域において、業務改革やシステム構築のPM(プロジェクトマネジメント)の実績多数。特に大規模かつ複雑な案件を得意とする。外部からの依頼に基づき、プロジェクトの困難な状況の立て直しにも従事、PMの重要性を痛感。現在は、同社においてPMの活動そのものをコンサルティングの対象とするサービスを展開している。
Copyright © ITmedia, Inc. All Rights Reserved.