さまざまなプロジェクトを経験し、「成功する理由はさまざまだが、失敗する理由はおなじ」であることが、なんとなくわかってきました。

成功には複数のルートがあり、人的・時間的・仕組み的な要因で、本当にいろんなパターンがあります。一方で、失敗については共通点があるものです。───「失敗への入口は限られている」といったほうが正確かもしれません。

そして、私はその門番をつとめているのが「コミュニケーション」だと考えています。技術的な問題よりも、コミュニケーション不足が原因で失敗するケースのほうが多いように感じるのです。

今日は、そんな失敗をしないための、チーム内のコミュニケーションを活性化させる仕組みについて、私のチームで実践している方法を共有したいと思います。

★結論
「進捗報告」は遅い。チームの思考をライブする「作業つぶやき」スレッドを作成し、問題を先回りするべし。

もっとコミュニケーションする仕組み

私のプロジェクトでは、チャットグループに「作業つぶやき」スレッドを作成し、プロジェクトメンバー全員が積極的に投稿する仕組みをつくっています。

投稿内容は、プロジェクトに関係する内容であればなんでも構いません。課題になりそうなこと、設計に対する疑問、開発時のメモ、検証内容やその結果の共有など、思いついたことを気軽に書いてもらっています。

ほかのメンバーは、スタンプをおしたりコメントを入れたり、好きに反応します。

基本的には「いま、考えていること」をそのままスレッドに垂れ流してもらいます。言語化も、「全然まとまってないしな」という躊躇もいりません。

ささいな疑問を書いてもらうのも大歓迎です。調べればわかることでも、10 分かけて調べてもらうよりも、1 分で質問して、有識者の 3 分を使って回答を得てもらうようにしてもらっています。結果的に作業時間も多くなります。

こういうと、「メンバーに負担がかかる」「コミュニケーションコストが高い」という意見があるかもしれませんが、相互にサポートすることでメンバーの関係性はより深まります。また、コストの話をしたいのであれば、そこにはコストはかけるべきだと、私は思います。

経験によって知識に差があるのは仕方ありませんが、ベテランばかりが活躍しても、若手が恐縮してしまい「チームの一員」としての自覚を持ちにくいものです。コミュニケーションそのものが少なくなるほど、それはさらに酷くなる傾向があります。

気軽に質問・相談ができる仕組みを作ると、チームのコミュニケーションが活発になり、作業の担当者（開発者）の孤立感が解消されます。チームとのつながりがあると、「自分だけで戦っているわけではない」という感覚になります。

─── といったような、「チーム内コミュニケーションの活性化」とか、「心理的安全性」とか、そんなことをダラダラ書いてしまいましたが、それは副次的な効果にすぎません。

真価は「情報共有力」にあります。

思考をライブするべし

このスレッドで共有されるのは結論ではありません。思考の途中です。

私はこれを「思考の垂れ流し」と呼んでいます。思考がリアルタイムで流れることで、チーム全体の認識が揃い、結論だけでは伝わらない判断の背景や検討の過程まで共有できるようになります。

プロジェクトでは、成果物や課題管理だけではみえない情報があります。「ちょっと気になる」「あとで検証したい」「この設計でいいのかな」といった、思考の途中にある情報です。このスレッドは、それらをチーム全体の共通認識に変えてくれます。

例えば、こんなような投稿があります。

★メンバー

こんな制限を見つけました。いまの設計で問題にならないか気にしています。
公式ドキュメントには書いてないんですが、実際に試したらできました。
機能Aはカスタム開発が必要かもしれません。標準機能では難しい気がします。
設計書と画面遷移図で認識が違うように感じます。私の読み違いかもしれません。
今日はじめて知ったんですが、こんな便利な機能があったんですね。

★PL

この設計は最優先。後でひっくりかえされたら困る。はやく客に見せておきたい。
パフォーマンス検証がスケジュールに入っていない。時間あるひと連絡ください。
【確認】もしかしてタスク管理表って最新版ではない？
次回以降も使えそうなのでナレッジ化します。誰かまとめてくれてたりします？

★PM

課題について、類似プロジェクトから情報もってきました。確認お願いします。
海外フォーラムで同じ事象を見つけました。まだ詳細は見れていませんが……
追加で確認事項が来ています。回答はまだ不要ですが頭の片隅に置いておいてください。

「思考の途中が書かれている」という特徴があります。大半は「～かもしれない」「ちょっと気になる」「確認してほしい」「あとで調べる」といった、まだ確定していない内容です。

これらを周囲が早い段階で反応できるため、認識のズレや手戻りを減らせます。

（そのスレッドで「ちょっとこの方法試して欲しい」とか「それ課題管理表に書いておいて」とメンションすることもあります。）

部下は上司が考えている「未来のこと」を把握できるし、上司は部下の「現場のこと」を把握できます。そんな、プロジェクトメンバーの思考がリアルタイムで流れてくるスレッド……どうでしょう？って話です。

--

◎たまに、（基本設計書に書いてある）プロジェクトの前提ともいえるような質問をされることがあります。そういうときに、「設計書は読んどけよー」と呆れるのではなく、「このタイミングで理解が進んでいないことがわかって良かった」とホッとするものです。

◎「さきほどの件なんですけど、できるっていいましたができなくて、誰かサポートして欲しいです」というヘルプを受けることもあります。この手の相談は言いにくく、ギリギリまで頑張ってしまうひとも多い。早めのアラートを出してくれたことに感謝です。

◎「～の検証が必要かも」と打つと、「空いているのでやります！」というひとがあらわれます。「手が空いてるなら連絡しろよ」とは思いません。「午前にいまの作業がおわるので、午後から着手します！」というケースがほとんどだからです。もうすぐ空きそうなひとを事前にみつけられたことを、よろこぶべきでしょう。

思考の過程は、結論の説明と同じ

このスレッドは「思考の過程」を振り返ることができるというメリットもあります。

例えば、課題 X があるとします。

「アプローチは 2 つありそう」「でも、A 案はデータ取得時のパフォーマンスが心配」「だったら B 案か……いや、システムの制約で B 案は無理か」「となると、A 案しかない。ただ検証は必要」─── を垂れ流すとする。

すると、それらを見ていたメンバーは、「課題 X は A 案でいく」という結論に加え、「B 案も検討はされていた」「パフォーマンスが心配なので検証が必要」という情報を得ることができます。

たいていの場合、報告や相談というのは、思考はある程度終わっていて、まとまった状態で出てきます。それはそれでうれしいのですが、結論だけでは「なぜその判断なのか」という思考が読めないのです。

すると、なにが起こるか。

先ほどの課題 X の例でいえば、「課題 X は A 案でいく」だけを共有した場合、メンバーから「A 案でも実現できそうですが？」という意見が出ることがあります。

その案はすでにシステムの制約により採用できないという結論に至っているのですが、経緯が共有されていないため、おなじ検討を繰り返してしまうのです。シンプルに時間の無駄です。

また、メンバーが「承知しました」と作業に着手するものの、「なぜパフォーマンス検証が必要なのか」「何を確認するための検証なのか」を理解しないまま進めてしまっていることもあります。

─── 思考の過程まで共有されていれば、結論だけでなく、判断の背景や検討の流れも伝わります。その結果、理解が深まり、ノウハウや勘どころも鍛えられます。

活性化のコツは自分がたくさん使うこと

で、これをメンバーにも書いてもらうには、「PL（PM）の立ち振る舞い」や「チームの文化」が大きく影響します。ただ、みんなに使ってもらうための方法はシンプルです。

自分がたくさん使うこと。

─── これだけです。

最初は「自分の思考を → メンバーに共有するためのスレッド」くらいのつもりで構いません。そうやって自分が使っていると、その有用性に気が付いたひとが、ひとり、またひとり増えていき、チーム全体で思考を共有する文化が伝播します。

自分から発信する内容は、ささいなモノであればあるほどよいです。それだけ周りが書くハードルが下がりますから。「なんだ、このレベルでいいのか」と思われたらしめたものです。

自分がきっちり言語化されたものばかりを載せていると、部下が「思考もまとまってないし、まだいいか…」という感じで離れていってしまいます。

なので、ここまでの内容で何回か表現されています、「思考の垂れ流し」をするのが一番イメージにあいます。（慣れないうちは、ブツブツと細切れた投稿になるはず。）

最初の目標は、メンバーに「課題になりそうなこと」を気軽に書いてもらうことでしょう。

タスクというのは、着手して 30 分も経てば「あ、これ結構やばいか（時間かかるか）」という感覚が見えてきます。その感覚を、当人のことばで、早い段階に共有してもらえることには大きな価値があります。

私はその感覚を共有してもらっていますから、メンバーから「〇〇の機能について、まだできてなくて、すみません３日ほど開発が遅れます」といわれても、こころは穏やかなものです。既存機能に影響があり、改修範囲が広そうなことは「聞いていた」し、彼が困っていたのも「見ていた」から、「知っている」のです。

もし知らなかったら、

・もっとはやく教えて欲しかった
・なにで困ってる？それは解決できそう？
・ちょっと状況が見えないんだけど、会話できる？

─── などと、精神を疲弊し、時間も浪費していたことでしょう。

--

メンバーによって経験やスキルに差があるのは当然です。

同じ課題であっても、そのひとにとってどれほど大きな壁であるか、どれほど不安に感じているかは、本人から聞くしかありません。そういう状況がみえていれば、事前にサポートを強化したり、別の作業に割り当てることも検討できます。

そうやってリソースを最大限活用し、チーム全体の生産性を高めることができます。

スレッドの名前は重要

話が横道にそれますが、スレッドの名前はかなり重要なので触れておきます。

まず、「思考板」「ブレインストーミング」「作業ディスカッション」のような名前にしてしまうと、メンバーが「キチンとしたものを書かないと」と萎縮してしまうことがあります。「気軽に話そう会」「カジュアルトーク」などにしておくと、口笛を吹きながらひとがやってきます。

PM や PL が厳しい雰囲気のチームであれば、「ゆるトーク」のような頭の悪そうな名前を付けるのは難しいかもしれません。

かといって「意見交換」などとしてしまうと、こうなると「目的があって話す」的な意味が強くなってしまい、「意見を持っていかないと」という気持ちが投稿を遅らせてしまいます。

「作業つぶやき」くらいが落としどころのようにみえますが、これはなんとなく本来なかった意味にも思えます。やはり「思考の垂れ流し」的な名前が、「整理は不要！考えていることをそのまま書いてみよう！」というメッセージを含んでいる、ような気がします。

こんな問題が解消できる

─── ということで、プロジェクトメンバーの思考がリアルタイムで流れてくるスレッド……どうでしょう？って話でした。

さいごに、私のプロジェクトではこんな問題が解消できている、ということをかんたんに共有して締めようと思います。

★解消できる問題

①「困っている」が共有されず、手遅れになる
　　→　予定日までに作業が終わらない
　　　　→　スケジュール変更、応援依頼、顧客調整が必要

②上司の判断理由がメンバーに伝わっていない
　　→　部下が間違った方向へ進む
　　　　→　作業が無駄になる、同じ議論を何度も繰り返す

③「知っている前提」で進めてしまう
　　→　経験豊富なメンバーだけで会話が進む
　　　　→　後工程で「それ知らなかったです」が発生

④課題管理表には載っているが、温度感が伝わらない
　　→　管理者は「まだ大丈夫」、担当者は「かなり厳しい」と思っている
　　　　→　ある日突然「間に合いません」になる

⑤会議が進捗の報告で時間いっぱいになる
　　→　裏では「設計に不安がある」「技術的な懸念がある」
　　　　→　終盤で問題が爆発する

⑥気軽に質問をできる場所がない
　　→　メンバーが「どういう意味だろう？」と半日調査する
　　　　→　ただの認識違いだと分かり、時間が無駄になる

本質的な問題である ───

問題の芽がみえた時点で情報が流れなかった
判断に至った思考過程が共有されていない
知識差が可視化されていない
管理表で「状態」は見えるが「温度感」は見えない
会議は「報告の場」であり「途中をだす場」になっていない。
質問するまでの時間が長い。

が解消されるのかなと。

思考の垂れ流しは、「問題を管理する仕組み」というより「プロジェクトメンバーの頭の中を同期する仕組み」として捉えたほうが、本質に近いのかなと思います。

以上です。