開発チームのコミュニケーションがうまくいくプロジェクトの始め方　チームの方向性を決める開発初期に、PMが実践したこと

北川氏の自己紹介

北川祐希氏：私のほうからは「開発チームのコミュニケーションがうまくいくプロジェクトの始め方」として、コミュニケーションのところをお話ししていきます。目次はたくさんありますが、後で見せるのでいったんいいとして。

自己紹介します。私は他業種、ゲーム業界から来ています。実はもともとエンジニア、ゲームプログラマーから始めて、ディレクターとしてディレクションをして、そこからまた別の会社に移った時に企画マンとして働いてまたディレクターをやってと、少し変わったいろいろな経歴があります。

これを1回「ゲームディレクターが新規事業開発のPMになった理由」というタイトルで「note」にまとめています。左下にあるQRコードでアクセスできるので、よければぜひ見てください。

現在はRelicに入って1年半ぐらいでしょうか。PjM、PdM、スクラムマスターとして今に至っています。趣味はゲーム、特撮、ガンプラといろいろありますが、もしどれかにヒットする方がいたら、お話しできるとうれしいです。

開発初期に意識していたこと

ではさっそく話を進めていきます。今日は「開発チームのコミュニケーションがうまくいくプロジェクトの始め方」というところで、開発初期に確立されることがたくさんあると思っています。

チームの方向付けが決まってしまう最初がやはり一番肝心ですよね。わかっていると思うのですが、特にコミュニケーションにおいては一度根付くとなかなか変えづらいというところで、やはり最初が大事です。

（スライドを示して）私自身のPM（プロジェクトマネージャー）の立場で、プロジェクトの組織上、どうしてもプロジェクトマネージャーというと上のような見え方をしますが、そういうことはあまり意識しないようにしています。

偉ぶらないとか、人の話はきちんと傾聴して遮らずに聞く。知らなかったら聞くのもけっこう大事で、「これはちょっとわからないので教えてもらえますか？」と言うようにしています。そうすると、現場（側の人）も知らないと恥ずかしいというようなことがなくなっていくので、「心理的安全性が確保できるチームなんだ」ということを（思えるようになることを）自分からもやっていくことを意識しています。

前提条件

今日はやったことを事例として紹介するのですが、「まず前提としてこんなプロジェクトでしたよ」ということを話すと、比較的大人数のプロジェクトでした。多い時で20人ぐらいのプロジェクトで、将来コミュニケーションパスに課題が出そうだな、フロントエンドとバックエンドのセクショナリズムも生まれてしまうかもしれないなと感じていた、ある事例がありました。

デイリースクラムの実施

そこで私がどんなことをしてきたかというと、まず1つ目にデイリー（スクラム）を必ず実施しました。これは何か進捗報告をしてほしいということではなく、誰かと一緒に作っていることを認識させたいと思って実施していました。

特に連携部分ですね。例えばバックエンドがAPIを作って、フロントエンドがそれを叩くという連携部分を中心に、僕らが煽動するようなイメージでやっていく。

ただし、デイリーでは詳細は追いません。「細かいことは後にしましょう」「あくまで15分ぐらいをスタンドアップでさらっとやりましょう」ということをやっていました。なぜかについては後で出てくるので、話を先に進めてしまいます。

「気になったら相談」の文化醸成

2つ目に「気になったら相談」の文化を醸成していきました。先ほどの心理的安全性、「知らなかったら聞く」に近いところになってくるんですが、デイリーは15分なので、確認できなかったこともあるでしょうし、実装を進めていくうちに課題が出てきたら、その場で相談するようにしようということを醸成していくのです。

例えば僕が「見積もりしてほしいです」「実装仕様の詳細をちょっと聞きたいです」というようなところから積極的に聞いていくかたちを取っていきます。その時、Slackのハドル（ハドルミーティング）をかなり多用していました。それが実施して良かったことです。

（スライドを示して）とあるプロジェクトでのSlackハドルの使い方、その1です。ミーティングをセットするというと、例えばGoogle Meetでも、URLを発行して予定も確認して……。なんかけっこう面倒ですよね。それが、「今ハドルいいですか？」だけで済むので、このスピード感をかなり大事にしていました。

僕がハドルを率先してやっていくと、「これをやっていけばいいんだ」とメンバー内に伝播していって、PMなしの担当者同士のハドルがけっこう発生していきました。

そのハドルに僕も勝手にしれっと入って、「どんな話をしているんだろう」と聞いていく。これは最新の情報収集が目的だったり、あとはPMが入ることで解決できることもあるだろうという目線でやっていました。やはり情報収集能力がPMスキルの1つでもあるので、ここは積極的にやっていたことです。

（とあるプロジェクトでのSlackハドルの使い方）その2として、先ほどちょろっと言ってしまいましたが、ハドルでやっていいんだと思うようになってくると、僕なしとか、担当者同士でハドルをしている時、例えばAさん、Bさんで話をしている時に、「Cさんもこの件は入れないといけないよね」とCさんを招待し始めました。

（あるいは）Aさん、Bさんが話している時に、今度はCさんが、チャンネルが並んでいるハドルを見て、「あれ？　これ、僕も必要なんじゃね？」と入っていく。そういうことが普通になってくるのです。

そうなると今度は、「今ハドルいいですか？」とチャットで打ち込むこともなくなって、直接ハドル招待が普通になっていく。こういった文化を作っていきました。

社内に発信をし続ける

1つ目がデイリーでした。2つ目が先ほどの件（ハドル）でした。3つ目に実施していくこととして、事例紹介でも少し話しましたが、新規事業開発やMVPはスピードがかなり大事です。（では）どうして大事か……。「大事って言っていますが、なんでだろう？」ということで、どうして大事かを言い続けることが大事かなと思っていて。極端な話ですが、「同じコンセプトのプロダクトが、他社から明日リリースされるかもしれない」ということを常に考えています。

あとは社内向けですね。ここまでの話はプロジェクトに閉じた話でしたが、もっと社内向けに「気になったら相談（するの）がいいですよ」と言い続けてきました。そうすると、メンバーには「こうやっていいんだ」「自分もやっていいんだ」ということが広がっていきました。

「デイリー」と「気になったら相談がいいよ」ということと、「社内に言っていこう」というところをしていった。

結果、みんなで話すことがかなり増えました。話すことが普通になったんですね。そして、メンバーが持っているプロダクトの知識の格差がかなりなくなりました。例えば「A機能について話しましょう」と言ったら、僕も含めてみんな同じようなレベルになっている。

あとは、同じ方向に向かうことができました。開発を進めていく時に「こっち（右）を進めばいいかな」と思っていても、別の人は「こっち（左）を進めばいいかな」と思っていることが出てくると思います。（そんな時でも）けっこう同じ方向に向くことができたなと思っています。

反省点

反省点としては、みなさん気づいているかもしれませんが、テキストで済むこともけっこうハドルでしてしまうんですよ。その結果、ドキュメントを作ることが少なくなったというのは、正直あります。

対策として、ハドルで決まったことをドキュメントに残すことはしていました。ただ、これは最初からやるとけっこう負荷が高いかもしれないというところが正直あるので、実施タイミングとしては、チームの成長過程に合わせたほうがいいかなと（思います）。「ここからならやってもいいかな」という塩梅の見極めは必要ですが、やっていたと思います。

良かったこと

良かったこととしては、先ほどの結果の話に近いのですが、メンバーの自立性が生まれましたね。それから、コミュニケーションのハードルが下がりました。「ハドルいいですか？」と言うこともなく、普通に話すことができるようになった。

権限の話も1つあって。WhatとHowの話を僕からみなさんに話すことがけっこうあって。PMが何でも全部決めるとか、メンバーに丸投げ（するの）ではなく、責任範囲をきちんと決めました。「PMはWhatに責任があるので要件の管理をします」「メンバーはHowに責任があるので技術の選定をやるよというように」とか。こういった責任の範囲をきちんと決めると、逆に動きやすくなったという経緯があるので、そういったことも良かったのではないかと思っています。