トラブル時こそ一番冷静に　クラスメソッドのPMが現場の経験から話すマネジメントに本当に必要なこと

腹を割って話して進めていくことが非常に重要

大橋力丈氏：ここから1つ事例を紹介したいんですけれども。これはリクシル様です。写真に写っているのがこのプロジェクトのプロダクトオーナーであるリクシルの佐々木さんという方です。

この方からまず問い合わせをもらいまして、実際にどんなことを解決したいのかというと、今宅配ポスト、宅配問題というのはけっこう大きいんですけれども。宅配ボックスであるスマート宅配ポストは、もうすでにデバイスとしてあります。

ただこれをホームネットワークにつなげて、さらに社会サービスとつなぐために、サーバー構築が必要ですという話で。IoTだったりサーバーの連携だったりとか、それを使う管理画面みたいなところが必要だねという話で、相談が来ました。

eコマースの大流行から宅配業者が悲鳴を上げて物流が増加しており、住人の不在による再配達、この二度手間をなくすために配送と受け取り側の双方を解決するのが宅配ボックスです。

これはきっちりRFPに書かれていたので、これを中心にどういうかたちで実現していくかというのを、佐々木さんと一緒に相談しながら進めていました。

ただ提供されたRFPはしっかりしたものだったので、僕らが応えきれないものもけっこうありました。そういったときに、うちとしてできること、できないことを正直に伝えました。

できないことに対して20、30個書いて、こうするとできますみたいな話を何度かやって、そのすり合わせをしながら、さらにRFPに記載されていた一部の作業をリクシルさんにも一部お願いをして、こういったかたちで進めていきましょうと。やっぱりここで重要だったのが、最初から無理して取るんじゃなくて腹を割って話して、それを進めていくことが非常に重要だったかなという事例です。

もう、いったんリリースはしたんですけれども、継続的に開発しています。今はリクシルの佐々木さんのプロダクトオーナーとしての役割でオーナーシップをもって僕らもチームとして進めています。

提案と受注に関してしっかり握って一歩目を進める

提案時の注意点としては、そもそも解決したい課題は何かというのがズレていると、開発していくうえでズレてしまいます。まずここは受注前に合っていないとズレます。もちろん受注してから変わっていくことはあるんですけど、最初の一歩目として、共通認識としてもっている必要があります。

求められた要求が難しい、これはうちではなかなか難しいなという場合は、どうしても飲まないといけないわけではなくて、正直に相談してこういうかたちならできますと。それでも無理なときは無理しちゃダメかなと思っています。

なのでこういったときにしっかり提案と受注に関して、お客さん、クライアントさんと握って、しっかり一歩目が進められるような状態っていうのが大事かなと思ってます。

ここに関われないというか、そもそもどういう流れで受注されているのか知らない人たちもいるとは思うんですけれども。実際ここに関わると、かなりおもしろいですし、ここに関わってプロジェクトマネジメントとか開発を進めていくと、実際に最初の状況も共有されているので、スタートダッシュがきりやすいかなと思ってます。

プロジェクト開始後は、視座、視野、視点を合わせる

そこからプロジェクトを開始しますってなったときに、視座、視野、視点を合わせるという話です。受注前に腹を割ることで、まずはクライアントさんと一緒に合わられることは前提かなと思ってます。

視座、視野、視点を合わせると何がいいのかという話ですが、開発スタイルを理解してくれるっていうところがまずクライアントさんと握れるところと、開発チームとしては解決したい課題に対して理解して、それを進めていけること。

僕らの強みとか弱みを正直に見せることで、チームとして心理安全性が高まったり、透明性とか隠しごとをせずに進めていくことで、なにか発生した場合の適応の制御とか改善が可能になったりします。

視点を合わせることで、ビジネス要件とか仕様、設計、開発において方向性をしっかり、それぞれの立場から決めていくスタイルもできます。それでも方向性がズレてたらちゃんとチーム内で議論するかたちになっていきます。これはクライアントさん含めてワンチームになって、プロダクトを作るための同じチームマインドをもつために、非常に重要かなと思っています。

ここらへんができて、実際目指すところで言うと、チームでQCDは誰が責任をもってマネジメントをする？　というところで。これはプロジェクトマネージャーがやることが多いと思うんですけれども、やはりこれはチーム全体でマネジメントすることが理想です。

そのためには、これはGoogleのre:Workの参考なんですけれども、チームの効果性の向上に関する5つの柱が重要です。例えばチーム内でミスをしても非難されることはない。心理的安全性。今よく言われてますよね。あとはチームメンバーを信頼し合いながら、ちゃんと仕事を任せられるかっていう相互信頼であるとか。

有効な意思決定プロセスがある構造と明確さ。仕事の意味ですね。自分にとってやっている価値は何だろうみたいなところを思えるかとか。インパクトであったりとか。こういうチームの効果性を向上させるためのチーム醸成とプロセスをマネジメントするのが、この中でのプロジェクトマネージャーの役割かなと思ってます。

こんなにぴったり最初から合うわけはない

とは言え、そもそもこんなにぴったり最初から合うわけはないです。きっちり合って、POやエンジニアがうまく合って、そもそも自律性が高いチームであれば、プロジェクトマネージャーは僕はいらないと思ってますし。最初は、チームの中で進められればいいんじゃないかなと思ってます。

ただやっぱりいきなりはできないので、プロジェクトマネージャーがチーム醸成とかプロセスをちゃんと作っていく必要があるかなと思います。

そもそもチームとは言え、所属とか役割とか立場、育ってきた環境とかもそうですけど、ぜんぜん異なります。あとは参画した時期によっても入り方や温度感もぜんぜん違いますし、やっているものも変わってくるので、そういったところも違うかなと。そもそもチーム内のレベルにスキル差があったりすることもありますよね。

これらを埋めるために、よく言われるプラクティスとかプロセスみたいなのがあると思うんですけど。僕らもけっこう使っているんですけど、インセプションデッキというのを使っています。

これはけっこう主流になってますし、プロジェクトの目的とか背景とかどうしていくみたいな、けっこう簡単に俯瞰で見れるツールなので、利用してみるとすごくいいんじゃないかなと思ってます。Cacooにもテンプレートがあり、非常に便利に使えます。

チーム醸成を上げていくためにはコツコツ努力する

あとはチームの強みを把握するためにということで、これも参考なんですけれども、『ストレングス・ファインダー』を昔やったときがありまして。これは意外と、こんな感じの人たちだなって、会話とかもしながら言ってたのが、改めて言語化されまして。

実際の才能の質問に答えてもらって、本人が取扱説明書みたいにまとめてチーム内で発表すると。この人はこういう特性があるからこういうふうに接すると良さそうみたいなのが実際に言語化されて、共通認識としてもてるというのはすごく効果的だったなと。

これに似たかたちで、ドラッガー風エクササイズみたいなものもあったりするので。まずはチームをどうするかっていうところを高めていくためにも、いろいろなプラクティスとかプロセスは有効かなと思ってます。

それでもこれはやっぱり簡単にはいかなくて。プラクティスとかプロセスっていうのは非常に有用なんですけれども、やっぱりチームは生物なので状況によっても全然変わります。そういったときに、チーム内での振り返りであるとか、まずしっかり立ち止まって現場を把握して受容する。

その中で、とくにオンラインという仕事が増えてきたので、極端に喜び称え合うっていうのは、すごく文化として作っていかないといけないことかなと思ってます。

そのチームの中で起きている問題を共有して把握して受容して、それをさらに改善するためにチャレンジして、またフィードバックを得るというところを繰り返していくと。

それでもチーム内でも意見が出てこないことがある場合は、1on1などによる対話がけっこう効果的かなと思っています。困っていること、楽しかったこと、その人がもっている価値観みたいなのをしっかり話して、チーム醸成をどんどん上げていくためにも、しっかり1つずつコツコツやっていく必要があるかなと思っています。

プロジェクトマネージャーはトラブル時こそ一番冷静に

それを繰り返しても、チームに合わないメンバーがいた場合ですね。向いてる方向がずっと違うとか、自分の範囲のみを決めてしまって壁を作ってしまうとか、そもそもメンバー同士の相性が悪いとか。こういったところは改善できればすごくいいんですけれども、やっぱり改善できないときもあります。

けっこう大鉈を振るう判断だとは思うんですけれども、プロジェクトの成功を考えたときにチームメンバー、そしてクライアントさん含めたワンチームとして一緒になれるかが重要なので、合わないときは切り抜くという判断もかなり重要かなと思っています。

立場的に相談しにくいとかいろいろあると思うんですけれども、そこで諦めてしまうと、ずっと自分が我慢しないといけないので。プロジェクトマネージャーなり、さらに上長なりに相談するというのは全然ありです。そこで、決して我慢する必要はないんじゃないかなと思ってます。

あと、やっぱりトラブルが発生した場合ですね。例えば障害が発生したとか、スケジュールが遅延したとかですね。こういう事象は起こるものです。なのでここは責めてもなにも解決しません。起きた事象は取り返せませんので、起きた事象に対してどう解決するか、解決策に対して陣頭指揮をとって整理する必要があるかなと思ってます。

基本的にはチームを上げていくためのプロジェクトマネジメントのスタイルであったとしても、こういうときは思いっきり陣頭指揮をとるのが、私の経験上ではよかったと思っています。

チームで起きた事象を整理して報告したりとか、例えば障害が発生しましたっていうときには全部の情報を吸い上げるのは時間がかかるかもしれないんですけれども。まずわかっている情報を共有したりとか、次の情報はいつごろになりそうです、とかですね。

そのときに重要なのが情報を隠さないことですね。すべて正直に伝えないと、後々別のトラブルが起きたときに実はあのときのこれでしたみたいなのがあります。隠せば隠すほど、プロジェクトだったりとかシステムは辛くなってくるので、ここは正直に伝えるのが大事です。

そのためにもクライアントさんとの関係づくりであるとか、チーム内での環境づくりは非常に重要になってきます。プロジェクトマネージャーとしてはこういうトラブル時こそ、一番冷静であって、その判断をしていくことが重要です。

エンジニアが気持ちよく働けるように

僕自身何度も失敗してます。キツかったプロジェクトもいくつもあります。例えば20年前、プログラマーのときですね。社内状況的にそもそも「あそこ行ってきて」って言われるレベルのときです。それはプロジェクトに対して入り込んで、あとは言われたものを淡々とやるだけだったり。あと火消しで入らざるを得ない状況とかですね。

やっぱりこういうのを改善しないといけないかなぁと思って、プロジェクトリーダーになって、マネージャーになったという背景もあったりします。やっぱりエンジニアが気持ちよく働ける必要があるので、その中でどうやってプロジェクトマネージャーとして振る舞えるかは、すごく大切かなと思っています。

ただそれをやっていく中でも、やっぱりクライアントさんとエンジニアからの板挟みにあうときもありましたし、そういうのを乗り越えていろいろやってきたかなぁと。どうやって解決すればいいかなって思ったときに、とにかくプロセスとかプラクティスの本を読みまくってですね。

インプット、インプット、とにかくインプットして、じゃあプロジェクトで実戦しようとするんですけど。やっぱり合わないんですよね。型に合わせようとしすぎて、チームを見てなくて、プロセスとか、プラクティスをやるのが目的になってしまって、過去ずっと失敗してきた経験もあります。今でも何が正解かはわかってなくて、1個1個積み上げていくしかないかなという状況です。

チームがウオ～ってなっている状態がプロジェクトの成功

結局何を伝えたかったかというと、プロジェクトの成功って何だろう？　って考えたときに……。これすごく抽象的な絵なんですけれども、プロジェクトの成功はシステムがちゃんと納期と予算と品質に対して納まっているというのがベースにあるとして。

それでもやっぱり、チームであるとかユーザーさんが疲弊してたりとかいうのは、あんまり成功とは言い切れないんじゃないかなと思ってます。やっぱりチームとかユーザーがウオ～ってなっている状態が、結果的にトータルのプロジェクトの成功なんじゃないかなと。

そのためには、やっぱりこれは目指したいところではあるんですけれども、できることは1個1個コツコツやるしかないかなと思ってまして。視座、視野、視点を合わせるところで言うと、クライアントさんとまず正直な関係性を築く。

これは、それぞれがプロジェクトのチームとしてそういう関係性を築けるかですね。今までやってきた中では、プロセスとかプラクティスも、過去にいろいろな事例があったりとかするので、自分で考えるのではなくて、有効的に活用しながら、成功事例などを聞きながらやっていくのは、すごくいいんじゃないかなと思っています。

どうしようもないときはキッパリ割り切る

あとチームの効果性を高める話なんですけれども。チームが効果的に、効率的に動ける状態を考える。そのためには自チームでがんばってもできないことはできないので……。私たちも昔スクラムをやろうとして、ドンってやって失敗して、自分たちではできない部分があったので、もう1回やるときには、外部のコーチなどを頼んだりしました。

その中で腹を割って話ができるチームづくりはすごく大事です。それをやるにはチームとか個人との対話は重ねて改善していく必要があると思ってます。でもこれがベストプラクティスというわけではなくてですね。1つひとつを地道に積み上げていって、よりよいプロジェクトになっていくのがいいんじゃないかなと思います。

ただし、これ、やりすぎると辛いときもあります。自分が求めているチームのなりたい姿であるとか、プロジェクトのチームとしてやるべきことがズレてるときがあるので。ここ、けっこう極端にバッサリ変えちゃったんですけども、どうしようもないときはキッパリ割り切る。これですね。

思い切りのよさが必要です。ずっと追い続けてても疲れが溜まってきますし、チームも疲弊する。やっぱり合わないものは合わないっていうのをちゃんと理解して、今の状況を受け入れて、こういうやり方で落ち着かせようっていうのが、割り切るときには重要かなと思ってます。

積み上げて積み上げてよくしようというのもあるんですけれども、そうすると自分のバランスを崩すときもあるので。今回はここまでで割り切るっていうのも、プロジェクトマネージャーとしての自分をコントロールするのに重要かなと思ってます。

私からは以上になります。Let's enjoy project！　登壇ありがとうございました。