PM（プロジェクトマネージャー）の基本姿勢や立ち振る舞いを徹底解剖
プロジェクト全体の計画や実行、品質や納期などに責任を持ち、プロジェクトの目標達成に向けて先導していく役目を担うのがプロジェクトマネージャー（PM）です。
PMに従事する方からいただいた質問をもとにトークテーマを設定し、「プロジェクトマネジメントの基本が全部わかる本」著者で、パラダイスウェア株式会社 代表取締役の橋本将功さんと、株式会社Sun Asteriskのプロジェクトマネージャーチームを統率する青木 史也を中心に、ディスカッションしていきます。
プロジェクトマネジメントの“型”を作り、「工数」と「工期」の違いを理解する
──まず初めに、 お二人がPMになったきっかけは？
青木：就職してしばらく企業で働いているなかで、将来は旅をして、仕事から一度離れることを思い描いていたので「手に職をつけたい」と思い、ソフトウェアエンジニアになりました。
ソフトウェアエンジニアとして働いていると、その先のキャリアパスとしてPMがありました。なので、最初からPMになろうと思っていたわけではなく、仕事をしていった先にPMという職種にたどり着いた感じになります。実際にPMとして働いてみると、仕事だけではない“人生のなんでもプロジェクト”であり、プロジェクトマネジメントだとも感じていますね。
橋本：私はもともと、新規事業やサービスの企画職からキャリアが始まりました。学生時代から趣味でコードを書いており、本当はソフトウェアエンジニアになりたかったんですが、誰もやりたがらない雑務や取りまとめ、調整、交渉ごとをやっているうちに自然とプロジェクトマネジメントを実践して身につけることになりました。
チームワークが良くなることが嬉しかったり、ものづくりの喜びを感じたりと、そういうものを体感しながら仕事を続けて早23年というのが現状です。
──ではここから、参加者からいただいたお二人への質問をしていきたいと思います。かっちりし過ぎない、ゆるめのプロジェクトマネジメントの“型”を作ることは可能でしょうか？
橋本：「ゆるめ」の定義によりますが、人が育つ強い組織は「型」やテンプレートを持っている。自分がコンサルティングをやってきたなかでそのように感じていて、「型」を作るのは組織強化の良い施策になると思います。
例えば、要件定義をまっさらな状態でやるのと、すでにテンプレートやフォーマットがある状態で始めるのとでは、難易度も進めやすさも全く違う。そこを整備することが組織力につながっていくでしょう。ただ、型やフォーマットに頼り過ぎてしまうと、それを満たしているかどうかのチェックが主眼になって本末転倒になることがあるので、その意味での「ゆるさ」はあっていいと考えています。
青木：私は基本的に「ゆるめ」ではなく、しっかりした型を作った方がよいと考えています。プロジェクトマネジメントのスケジュールや品質、コスト、スコープなどの管理については「きっちり」とした型化が重要だと思うからです。その上で、チーミングとか定性的な部分はゆるめの指針もありだと思います。
── 要件定義中に詳細の見積もりを求められた時の立ち回りについて教えてください。
青木：プロジェクトマネジメントにおいては、「工数」と「工期」の違いについても理解しておく必要があるでしょう。例えば、あるプロダクトを開発するのに10人のメンバーが必要だと置いた際に、10人が1人月をベースに稼働し、それを工期に当てはめていくと、「1ヶ月で開発できる」と錯覚してしまうんですよ。
それに対し、しっかりとスケジュールに当てはめて、「10人月で開発を行うが、実際の工期としては2.5ヶ月かかる」と正確なものを提示し、クライアントと目線合わせしないと、スケジュールのコントロールで揉めることになります。
橋本：プロジェクトを進めていく上での基本というか、お作法みたいなのを丁寧に説明すると、クライアントからも信頼されますよね。その辺りを手を抜いてしまうと、手戻りが発生したり揉める原因にもなります。
プロジェクトを成功に導く3要素。「期日への寄り添い」「NOが言える関係性」「相手選び」
── プロジェクトを進めていく上で、期日を守ってもらうことや日報を欠かさず書いてもらうにはどうすればいいか？
橋本：期日を守らせる側は常に問題意識を持っていると思いますが、本質的な話なのは「自分は果たして同じことができているのか」ということだと感じています。タスクを任せる側は「きっちり、そつなくやってほしい」と思う一方、自分がやる側に立ったときに本当にできるのかというのは、別に考えた方がいいでしょう。
なぜかと言うと、期日を守ることに関しては、日本における仕事の倫理観として絶対に守るべきものだと捉えられていますが、これが海外だとそうでもないわけです。契約書で縛らないと期日通りに遂行しないなど、普通にやっていては期日が守られないことも少なくない。なので、「期日に対して、どのくらい“合理的な合意があるのか」というのが重要で、スケジュールで立てた期日が現実的なものかどうかを見定めることが肝になってきます。
青木：指示を出す側も、やる側の仕事量や業務負荷が、リアルにシミュレーションできているかも大事になりますよね。自分の場合、プロジェクトの背景や目的をメンバーに伝達するんですが、「聞き直しは3回まで」と決めているんですよ。3回以上、同じことを質問してきた人は、ガッツリ行く時はプロジェクトから外してしまっています。
というのも、プロジェクトのゴールを考えたときに「どうやったら成功するのか」という視点で考えないといけないゆえ、プロジェクトの意図を汲めていないメンバーがいると、どうしてもマイナスに働いてしまうからです。
橋本：PMとして、プロジェクトの納得感をメンバーにしっかりと伝えられているかも大事な要素になりますよね。その人がやらないと、プロジェクトが進まないタスクがある場合は、人を替えるなどしてアジャストしていくことも、プロジェクトを円滑に進める上で求められることです。とはいえ、今は人手不足で難しいと感じる場面もありますね。
青木：ベテラン勢は今まで話したような内容は理解している人も多く、新米メンバーの方が、このトピックにまつわる課題を感じやすいかもしれません。
橋本：日報をきちんと書いてもらうには、テンプレートを用意して、最低限書いてもらう項目を埋めてもらうようにすれば、うまく回ると思いますね。
── プロジェクト関係者の間でフラットな関係性を構築するために工夫していることはなんでしょう？
青木：クライアントと受発注の関係ではなく、プロジェクトに対してフラットに話せるような関係性を構築するのが大事になるでしょう。イエスマンにならず、「この場合はやらない方がいい」とか、「もっとこうした方がより良くなる」といった提案をしていけるように、私の場合は意識しています。
橋本：フラットな関係性であれば「断る」こともできるわけで、青木さんが仰るように「NOと言えるかどうか」というのは結構大事なことなんです。結局はプロジェクトを立ち上げるのは人であって。
恋愛でもその人と付き合ったからトラブルが起きるように、プロジェクトを一緒にやる人を決めた判断が、そもそも間違っていたのではと思うことも必要ですね。「誰とやるか」という相手選びも、プロジェクトを成功に導くには重要な視点だと考えています。
青木：確かに相手選びはものすごく大切ですね。それに尽きると言っても過言ではないかもしれません。
プロジェクトは「一期一会」。人への恩義を忘れないこと
── PMがとるべき基本姿勢（考え方や動き方、各ステークホルダーへの接し方など）について教えてください。
青木：プロジェクトの成功云々というよりも、終わった後に「クライアントから飲みに誘われる」ことがあれば、自分としては「成功」だと思っています。そのように言ってもらえるということは、信頼が醸成されたからこそであり、また会いたいと思ってくれている行動の表れだと思うんです。プロジェクトが終わった後でも、仕事以外で人対人のコミュニケーションが取れるのはとても重要なことだと考えています。
橋本：PMは人それぞれのスタイルがあり、これが正解というのはないわけですが、私自身がイメージしているのは「武士道」なんです。プロジェクトは「一期一会」で、その中で起こったこと、発生した物事に対して、礼を失わないように意識しています。
プロジェクトに向き・不向きのメンバーはどうしても出てきてしまう一方で、私が着任/離任する際にはしっかりと感謝の念を持って、恩を伝えるのを忘れないようにしています。当たり前のことかもしれませんが、ここをきっちりやる人はそんなに多くないと感じています。
青木：「一期一会」はプロジェクトマネジメントを考える上でひとつポイントになりますね。合う人、合わない人はいても、またどこかで再会するかもしれないですし。
橋本：過去に揉めたクライアントでも、なんとか冷静を保って、関係性を壊さなければ、また一緒に仕事する機会が生まれるかもしれない。そう思うと、「一期一会」を大事に謙虚でいることが大切になるでしょう。
青木：今後、グローバルプロジェクトが増えていくなかでも、たとえ海外の人であろうが、礼を忘れずに恩義を持つことは通じることだと思います。
プロジェクトの要件定義を「例え話」を用いて咀嚼する
── 非技術者、設計者に対して、システム設計や見積もりを伝える良い方法や教育方法はありますか。
橋本：見積もりや追加要件などについて、よく例えるのが“中華料理屋”。中華ラーメンを注文した後に、ビールと餃子を注文したということはお会計が変わるわけです。また、最初に見積もりしたものから要件変更が発生した場合は、しょうゆラーメンを頼んだのを途中で味噌ラーメンに変えてほしいと言われても「しょうゆに味噌を入れたところで味噌ラーメンにはならない」という話なわけで。
つまり、味噌ラーメンとして一から作り直さなければならないから、追加料金をいただくというのをクライアントに説明するようにしています。
青木：例え話を織り交ぜるとわかりやすいですよね。プロジェクトの要件定義をしていくのは、すなわちクライアントの夢を伺っているわけであり、折衝を繰り返して折り合いをつけていく必要がある。そんな時に、自分がよく使う例え話は「マイホームを作る」ような楽しさですね。何が必要で、どんな家にするのかを考えていく思考と同じようにプロジェクトの要件定義を定めていくのを意識しています。
── ウォーターフォール型からアジャイル型へ移行する際に、両者の考え方の違いを理解してもらう場合、どのような方法がありますか？
青木：自分の場合、「いきなりアジャイルは厳しい」とまず伝えるようにしています。代わりに“ミニ・ウォーターフォール”と銘打って、ある程度の範囲で機能単位で開発し、新しいやり方にトライしてもらい、そのやり方を見た上でアジャイルに移行するかを判断してもらうといいのではないでしょうか。
橋本：日本の企業は基本的に単年度の予算しか組まないんです。その中で発注者側は、最大限の効果を得ようとしてしまう。そうなると、追加要件や要件変更が発生しやくなり、ハンドリングが大変になるケースが多くなるわけですが、そもそもアジャイルは単年度の予算でやるための手法ではなく、3年や5年といった中長期で予算を組んで進めていくものなんですよ。
ただ、いきなり企業の中で予算の立て方を変更するのはハードルが高く、まずは単年度の予算内で最良なもの、遊園地に例えると「花やしき」を作ることを念頭に置くといいのではと私はクライアントによく言っています。まず「花やしき」を作ることができれば、クライアントも喜んでくれますし、事業上の利益も生まれる状態になる。それを踏まえて、次の計画を立てればいいという考え方でまずは進めてみるのもいいでしょう。
── 炎上したプロジェクトに対し、PMはメンバーへどのような声がけをしてフォローアップすればいいのか？
橋本：プロジェクトが炎上しているときは、どうしてもメンバーみんなの視野が狭くなりがちで、ただひたすらゴールの見えない迷路を走り回っている状態なんですよ。私の場合、「まずは状況を整理するので、手を止めてください」と声をかけ、その間にメンバーを休ませるのを心がけています。そうすると、タスクに埋もれていて、視野が狭まっていたのが徐々に解放され、元に戻っていくので、ここからプロジェクトの仕切り直しをしていくような意識へと持っていくようにしています。
── ありがとうございました。PMという仕事内容とその魅力について存分に学ばせていただきました。20年以上のキャリアを持つお二人が、その豊富な経験をもってでもまだ自己研鑽されていることも素晴らしいと感じました。第二回以降も楽しみです。よろしくお願いします。
この記事が気に入ったらサポートをしてみませんか？