この国では犬が

本と芝居とソフトウェア

ファシリテーション入門

今日同じチームの人から「どうすれば(プランニングのような)ミーティングをうまく仕切ることができるのか」といった趣旨のことを聞かれたのだけど、あまりうまく答えられなかったので、ちょっと落ち着いてまとめてみようと思う。

ファシリテーションの問題

まず課題設定。
「(プランニングのような)ミーティングをうまく仕切る」というのはつまり、いわゆるファシリテーションのことを言っていると思う。

ファシリテーションとは - FAJ:特定非営利活動法人 日本ファシリテーション協会 によれば、ファシリテーションとは「人々の活動が容易にできるよう支援し、うまくことが運ぶよう舵取りすること」だ。

僕は、ファシリテーションを以下の要素で捉えている。

  • ゴール: その場の参加者が「何を達成したい」のか。
  • 全体図: ゴールに照らして、おおむねどういう道筋で進んでいくことを想定されるか。
  • 現在の場: 現在の共通認識は何で、共通になっていない認識は何か。場は熱いか、冷たいか。発散中か、収束中か、等々。

これら3つが明らかであれば、自ずとなすべきことが見えてくる。

先の質問をされたときには、ここまでを伝えた。

どうすればできるようになるか

問題はここからだ。

「これら3つが明らかであれば、自ずとなすべきことが見えてくる」と言われたところで、

  • どうすれば、それら3つを明らかにできるのか
  • 3つを明らかにしたところで、本当になすべきことは見えてくるのか。見えてこなかったらどうすればいいのか
  • どうすれば、それらの技術を習得していけるか

といった疑問が湧いてくることだろう。

聞いてくれた人も、僕の回答を受けて少し困惑していたみたいだった。こういった疑問が浮かんでいたのだと思う。

ここからは、これらの疑問に答えることを試みたい。

どうすれば、それら3つを明らかにできるのか

ゴール、全体図、現在の場。

これらを明らかにするには、まず「明らかにしようとすること」が必要になる。

おそらく、当たり前だと思われるだろう。では、「明らかにしようとすること」ができているだろうか?

おそらく、できている部分もあれば、できていない部分もあることに気づく方が多いのではないかと思う。
僕自身もそうだ。

これらに常に注意を払い、曖昧になってきたらそれに気づき、明らかにするための行動を取る。
これができているか。

たとえばゴール。ミーティングが始まるとき、「その時間枠が終わりを迎えたとき、どのような成果が得られていればよいか」は明らかだろうか。
ファシリテーターであるあなた自身にとってはどうだろうか。参加者全員がその答えを共有できているだろうか。

僕の場合は、定期的なミーティングでゴールが明らかである場合以外は、まず明示的にゴールを確認することが多い。
自分なりの答えがある場合は「ゴールは○○でいいですか?」と聞くこともあるし、自信がない場合は「まずゴールを確認したいんですが」と切り出すこともある。

全体図。これは、ある程度経験が積めてくると、その場で提示されたゴールと時間枠から、即興で全体図を描けるようになってくる。
そしてそれが理想だと思う。進行に応じて、全体図は形を変えていくものだからだ。ときにはゴールが変わることもある。

しかし、経験が少ないうちは完全に即興というのも難しいだろう。
その場合、あらかじめゴールをある程度把握しておいて、ミーティングが始まる前に大まかな流れを頭に描いておくと多少安心できる。

定期的なミーティングは、だいたいの目的と流れが決まっているものだし、定期的でなくても、ほとんどのミーティングはいくつかの類型で整理できる。意思決定のためのミーティング、アイデア出しのためのミーティング、情報共有のためのミーティング、等々(それらのミックスであることも多い)。
そういったものを学んで、頭に入れておくのも役に立つだろう。

また、全体図を自分自身が描けなくても、全体図に不安を感じたら、参加者に助けてもらうのも手だ。
たとえば、「ところで、残り時間どう使うのがよさそうですかね?」「ちょっと立ち止まってここからの進め方整理してもいいですか?」といった質問が役に立つだろう。

現在の場を明らかにすることは、たぶん一番難しく、経験が必要になる部分だ。
ミーティングの内容(コンテンツ)についての認識・把握も、人や場の状態(プロセス)についての認識・把握も、同じくらい重要になる。(正確には、ファシリテーターの立ち位置に応じて後者の比重が高まることが多いが、ひとまずはどちらも重要、と言っておいてよいだろう)

この課題についてはこの記事では書き尽くせる気がしないので、ここまでにとどめる。
基本的には、上手な人を観察しながら身につけていくとよいだろう。また、ファシリテーターが必要以上に出しゃばりすぎなければ、周りの人たちが助けてもくれる。

最後に、何度か言及してきたが、これらの3つは一度明らかにして終わりというわけではない。

ゴールは変わることもあるし、参加者がゴールを見失うこともある。

全体図は刻々と移り変わっていく。時間がなくなってきたら、アジェンダを一部省略する必要が生じることもあるだろう。それに応じて、ゴールの見直しも必要になる。

現在の場については、文字通り移り変わり続ける(それが「現在」の定義だ)。常に把握を試み続ける必要がある。

3つを明らかにしたところで、本当になすべきことは見えてくるのか。見えてこなかったらどうすればいいのか

「3つを明らかにすれば、自ずとなすべきことが見えてくる」ということの意味については、ここまでである程度は伝わっているのではないかと思う。

「自ずとなすべきことが見えてくる」というよりは、「3つを明らかにし続けようとすること自体が、なすべきことそのものである」という言い方のほうが正確かもしれない(ということに、書いていて今気づいた)。
「見えてこなかったらどうすればいいのか」についても答えは同じで、見えてこないということは、おそらく3つのうちのいずれかに不透明な部分がある(生じている)はずだ。

なお、ファシリテーターは当然ながら全知全能ではないし、そうである必要もないので、力不足を感じた場合は参加者に助けを求めるのもよいだろう。というより、途方に暮れてしまうよりはその方がずっといい。

これを、この質問への当座の答えとしたい。

どうすれば、それらの技術を習得していけるか

以前、とある名ファシリテーターの方に「ファシリテーションがうまくなるにはどうすればいいですか? おすすめの本とかあれば知りたいです」と聞いてみたことがある。
答えは渋く、「実践から学ぶしかないですね」といったものだったと思う。(正確には、洋書を一冊だけ教えてもらえたのだったが)

ある程度ファシリテーションができるようになってみて、その答えの意味もある程度わかるように感じる。

個人的には、本も役に立つと思う。基礎知識は持っていて損はない。

ただ、何か一冊世の中に名著があるというよりは、自分に合う本を見つけることの方が大事なのではないかな、とも思う。
それぞれの本に書いてあるファシリテーションの基礎は、(一定まともな本なら)たぶん本によって大きくは変わらない。どちらかというと、読む人に伝わるかどうかの問題で、それは読む人と本との相性によるところの方が大きいのではないかと思う。

だから、本を探すなら、大型書店に行って、自分に合いそうな本を手にとって探してみることをおすすめしたい。

そして、あとは実践あるのみだ。

どうなんだろう。何か、うまいやり方を知っている人がいたら教えてほしい。
残念ながら、ここまで記事を書きながら考えてみても、実践しながら学ぶこと以外に有効な学び方を思いつかなかった。

実践しながら学ぶことの一般的な手引きとして、

  • 安全に失敗できる場所で、小さく失敗しながら学ぶ
  • 本などで学んだこと(座学)を実践に投入してみて、フィードバックを得ながら学ぶ

といったことは言えるだろうか。当たり前だが、大事なことだ。

まとめ

ミーティングをうまく仕切ること、つまりファシリテーションにおいては、(僕の考えでは)「ゴール」「全体図」「現在の場」の3つを明らかにし、またし続けることが重要だ。

それらを明らかにし続けること自体がファシリテーションである、という言い方もできそうだということがわかった。(※これは捉え方の一つに過ぎず、ヒントのようなもので、違った捉え方も可能だとは思う)

そして、ファシリテーションがうまくなるには、本を読んで基礎知識をつけておくことも有効だが、実践し続けることが何より重要だと思う。

この記事が、ファシリテーションがうまくなりたい人にとって、何かしら手助けになれば幸いだ。

世界に価値のあるプロダクトを届けたい

(この記事は、いわばセルフコーチングのメモ、というか議事録のようなものです)

世界に価値のあるプロダクトを届けたい。

これが僕の行動原理だ。
ということについては、大学を卒業して働き始めるかどうかといった頃に気づき始めたと思う。以降、この認識にほぼ「ブレ」はなく、時とともに「鮮明」になってきた、と感じている。当初はこのように言語化できてはいなかったが、10年以上の時を経るにつれて、焦点が合って、輪郭がはっきりしてきた感じだ。

ということは、たぶんそういうことなのだろう。
こだわるつもりはないが、そういうことだ、と当座認めてもよいとは思う。

僕の行動原理にはもう一つある。
これは、人なら誰しもそう、という気もするが、僕は特にこれが強いと思うので、あえて言及しておく。

自分が楽しく、幸福を感じていたい。

繰り返しにはなるが、これは人なら誰しもそうだとは思う。
ただ、世界に価値のあるプロダクトを届けることが唯一絶対の原理ではない、ということが言いたかった。自分が楽しく、幸福を感じられる方法で、その限りにおいて、世界に価値のあるプロダクトを届けたい、ということだ。

さて、それがわかったいま、何をするとよいだろうか。

「組織をよくする」ことに目が向きがちだと自認している。
自分の正式な守備範囲外のことであっても、ついつい首を突っ込んでしまう。よりよくしようと思ってしまう。

これは、自分が所属する組織が、より価値のあるプロダクトを届けられるようにするためにそうしている。
つまり、組織が主語になっているということだ。

組織が主語、を所与の条件としてシンプルに考えるなら、経営をするとよい、という結論におそらくなる。
経営とは、組織を主語にすることそのものであり、また組織の行く先を定めることでもあるからだ。

だが、そう簡単な話だろうか。

一見して、条件が2つあることに気づく。
まず、自ら経営を行うことが、本当に「自分が所属する組織が、より価値のあるプロダクトを届けられるようにする」ための最善の方法か、ということ。それから、経営を(十分)楽しく、幸福だと感じられるか、ということだ。

これら2つの条件には、因果に近い相関関係がある。わかりやすい言い方として「経営の才能」があるならば(「才能」という概念自体の当否は保留として)、前者は満たせるし、後者もそれなり以上には満たせるだろう。
一方、「経営の才能」がなかったとすれば、まず前者が容易には満たせない。才能を補うための努力をするとして、後者、つまりそれがどれだけ楽しく、幸福だと感じられるかも、せいぜい不透明といったところだ。

では、経営の才能とはなんだろうか、どうすればそれがわかるだろうか、ということを考えることもできるが、これはいったん保留とする。

実は、「経営をするとよい」という単純な結論には、もう一つ見落としている条件がある。

「世界に価値のあるプロダクトを届ける」ための単位(ユニット)が「組織」である、という前提だ。
この前提にはたぶん、それなりのバイアスがある。現代において、会社員として給与をもらうことが、安定的に生活するためのとても有力な手段であること。その手段に乗っかってこれまで生活してきたこと。

僕は無意識のうちに「組織」を所与と思い込んでいるが、おそらく実はそうではない。

もし「組織」というよりどころがなかったら、世界に価値のあるプロダクトを届けるために、僕はどうするのだろうか。

これは考えてみる価値のある問いだ。ただ、既存の組織に頼らずに、「自分が楽しく、幸福を感じられる」状態でいることはそう簡単ではない。それを満たしながら、価値のあるプロダクトを届けるということをも満たす方法を見出すのは、この記事の中では難しそうだ。

この記事は、下記を認識できたことを成果として、終わりとしたい。

  • 僕は、世界に価値のあるプロダクトを届けたい。これが行動原理だ。
  • また、自分が楽しく、幸福を感じていたい。これも重要で、譲れない。
    • なお、どちらが第一原理かは明確になっていない。
  • 「組織」を主語として考える習い性を見るに、「経営」をするとよさそうに思える。
  • しかし、「経営の才能」があるかどうかはわからない。そのため、本当に経営をするとよいかも現時点ではわからない。
    • 「経営の才能」がなかった場合、「(組織が)世界に価値のあるプロダクトを届ける」ために貢献する方法として、経営よりもよい方法がある可能性が高いし、「楽しさや幸福」についても概ね同じだろうからだ。
  • また、「組織」は究極的には所与ではない。組織を所与としないケースのことも考えてみる価値がある。
    • これは簡単ではなさそうなテーマに思える。また、今までこれについて真剣に考えてみたこともほとんどない。

2023年のふりかえり

今年もふりかえりブログを書く。

なんだかんだ、2013年にブログを始めてから今年まで、11年間続けているのだな。

やったこと

昨年末には、こう書いていた。

なんとなくだけど、社会にひらいていくのが次の新しいことという気はしている。
基本的に内向的というか、引きこもり気質というか、本質的に一人が好きみたいなところがあるんだけど、いやこの「本質的に一人が好き」っていうやつの解像度をもうちょっと上げてもいい頃合いなんだと思う。「本質的に一人が好き」だったら、こうやってブログ書いて公開したりしないと思うんですよね。だとしたら、の先に何か新しい可能性があるような気がしている。

う〜〜〜ん、どうだろう。

正直、あんまりひらいた感覚はない。

まあ、まだまだ若い業界(ソフトウェア業界のこと)ということもあってシニアと見なされるような立場になってきて、人を育てるとか、組織をよくするみたいなところに今まで以上に目が向いてきて、自分なりにやれることをやって。
これも言うなれば、社会にひらき始めている、とは言えるだろう。

わかったこと

でもどうだろうな、こんなものなのかな。
一つの会社の中で、組織のことを考えたり、周りの人を育てたりといったことが、なんとなく思い描いていた「社会にひらく」ことだったろうか。

そして、これがあまり向いているとも思えない。
いや、正確には、得意不得意はともかく、あまり好きではない、と言った方がいいか。

嫌いでもないんだけど、特に好きではない。
人を育てたり、組織を作ったり、といったことが。うん、別に嫌いではないんですけどね、必要ならやるし。

これをしっかり認識した一年だったと思う。

自分が何が好きか、ということを考えたとき、良くも悪くもというのか、昔からほとんど変わっていないことに気づく。
価値のあるものを生み出すことだ。

たぶん、この自分の本質は、子どもの頃に初詣で世界平和を願っていたり(価値のあるもの)や、漫画を描いたり、曲を作っていたりしていた(生み出す)頃からまったく変わっていない。

なーんか、人って変わらないんだな。

もちろん、強く願って行動すれば、変われることもあるだろう。
でも、僕は今のところ、これを強く変えたいとは思っていない。

次にやること

幸い、「価値のあるものを生み出すこと」は、自分だけでなく、周りの人たちや社会にとっても利益こそあれ、不利益はあまりない。と思う。
であれば、素直にそれを楽しんだらいいのだろう。

組織を作ったり、人を育てることも、見方を変えれば、価値を生み出していると言えなくもない。というか、言える。
ただ、今の自分の認識では、生み出している感触、手触り感というものがないんだよな。平たくいうと、自分で手を動かしたい、みたいなことなのだろう。

それを否定しても仕方ない。
否定するよりも、認識して、受け入れて、生かすというのか、「それならばこうしよう」を見出すのが王道というものだろう。

ただ、今の自分は、「価値」に強く目を向けた結果、「生み出す」の方をないがしろにするような状態になりがちに思える。
組織だったり、人だったりということに、吸い寄せられていく。ただ、それは心の底からやりたいことではない。(少なくとも、部分的には)

来年は、一つのトライとして、あえて「生み出すこと」に意識的に集中するようにしてみようかな。
そのとき、「価値」を多少ないがしろにしているように思えたとしても、心を鬼にして(?)「生み出すこと」の方を選んでみる。

それが王道を進む一つの方法なんじゃないかと思う。
試してみれば、何かがわかる。今の認識が更新されて、価値を大事にした方が本当にいいことがわかるかもしれないし。逆にやっぱり、「生み出すこと」を大事にした方が自分も幸せだし、周囲も幸せになるということがはっきりとわかるかもしれない。

螺旋を一周して帰ってきた感じ。
わくわくするな。

加点法で生きる

加点法で生きると、幸せを感じやすいのではないか。

そして、僕は普段から加点法で生きている。と思う。

昨日からなんとなく京都に一泊で来ていて、来るまでは大きな目的もなく、期待もなく、来てはみたものの楽しめるのだろうかというなぜか不安のようなものさえあった。

加点法なので、その時点では0点だ。
いや、まあ京都に行くというワクワクで、40点くらいはあったかもしれないか。

京都に着いて、10年前に眼鏡を買った店に行った。そこでとても気に入る眼鏡を買うことができた。
ここであっさり100点に到達した。

そうすると、ここからはボーナスタイムだ。

大学の頃の先輩が教えてくれたおでん屋さんに行ったところ、これがまたべらぼうによく、120点。足し合わせると220点だ。

こうなってくると、もう何があっても大抵大丈夫だ。

ホテルのシャワーが快適で、30点。ベッドも快適で、30点。
実は部屋に入ったとき若干臭ったが、加点法なので気にしなければいいだけだ。しばらく窓を開けていたら、爽やかな空気になった。

今朝は雨が降っていた。
京都の街を散歩しようと思っていたので、減点法だともしかしたら減点になるところかもしれない。

しかし、加点法なので「雨の京都を楽しめる」、20点。さらに、小雨になってきて歩きやすくなってきたので10点。
やがて雨はやんだ。なんだかんだ快適なので、20点。たぶん、初めからこの天気だった場合よりも合計点は高い。

これで330点ということになるのかな。
まあ、昨日の記憶は減衰しつつあるので3割くらいは割引になりそうだが、今日は他にも色々といいことがあったので、現在値でも300点くらいはあると思う。

ものごとのいいところを見る。

100点に達するまでは、多少の不快や不満を感じるかもしれないが、100点を超えてしまえば、ボーナスタイムなのだ。
基本的には、いいことしかなくなる。それが加点法の世界だ。

普段は、ちゃんと起きて、それなりに元気に1日を過ごすことができれば100点だと思っている。
だから、平日でもだいたい150点くらいにはなる。何か特にいいことがあった日は200点だ。

平日の朝、たいていあまり調子がよくないのは、単に夜型で朝が苦手だからだと思っていたけど、加点法で生きているから、というのもあるのかもしれない。
こればっかりは、加点法の弱みかもしれないな。

プロダクトマネージャーをチームの一員にする

この記事は、Uzabase Advent Calendar 2023の10日目の記事です。

昨日の記事は@itsukiyさんの「YAGNIから受け取ったメッセージ」でした。


まえおき

現在僕が所属するユーザベースでは、エンジニア、デザイナー、プロダクトマネージャーは別の組織に所属していて、チームとしてプロダクトを開発・運用する日々の活動はエンジニアからなるプロダクトチームのメンバーが中心となって行っています。

デザイナーやプロダクトマネージャーは兼務であることも多く、日常の多くの時間を共にしてはいません。
もちろん、その時間にデザイナーやプロダクトマネージャーもそれぞれがプロダクトにまつわる活動をしているわけですが、いわゆる全員同席状態、常に自然とチームとしての意識を持ちやすい状態ではない、ということです。

それでも、僕はデザイナーやプロダクトマネージャーを含めた「チーム」として考え、行動することが成功するプロダクトづくりのためにとても重要だと考えています。

それを実現するために、(現状のデフォルトとしての)エンジニアからなる開発チームとして、どのようにプロダクトマネージャーと付き合っていくのがよいか、ということを書きます。(今回はプロダクトマネージャーにフォーカスします)
これから書くことには実績のあることだけでなく、仮説も含まれますが、僕が実現していきたいチームの姿として書いてみます。

外部のステークホルダーではなく、チームの一員

この記事で言いたいことを一言でまとめると、「プロダクトマネージャーを、外部のステークホルダーではなくチームの一員にしよう」ということです。

しかし、日々の活動の中には、プロダクトマネージャーをステークホルダー的に、下手をすると「発注者」のように扱ってしまいかねない数々の罠があります。
ここからは、プロダクトマネージャーをチームの一員にしたいという前提で、「やってしまいがちだが、避けるべきこと」を「Dont's」、「かわりにこうしよう」を「Do's」というかたちで対比させながら記していきます。(なお、記事中の画像はすべてDALL·Eで生成しました)

意思決定に必要な情報を引き出す

Don'ts: 意思決定を委ねる

すべてを知っているプロダクトマネージャーとその他の人たち

プロダクトマネージャーは、その知識や経験から、どのような機能に取り組むか、どのような順序で取り組むか、どのような仕様にするかといったことについて決める能力が高いことが多いです。
僕がいる会社では特にこの傾向があるようです。プロダクトがB2B SaaSで、プロダクトマネージャーは営業や、CSといった職種の経験があるケースが多く、ユーザーと話したことも多ければ、自らユーザーとしての視点も強く持っているからだと思います。

だからといって、エンジニアから「どうしますか?」といった聞き方をし、意思決定を委ねてばかりでは、いつまで経ってもプロダクトマネージャーがいないと何も決められないままです。
意思決定を委ねてしまうことは、もともとある情報の偏りがならされないこと、意思決定をする経験の量自体にも偏りが出ることという2つの偏りにつながり、悪循環が生じるからです。

Do's: 意思決定に必要な情報を引き出す

プロダクトマネージャーと対話しながら意思決定するチーム

「どうしますか?」という質問は、たとえば「どうするのがいいと思いますか?」と言い換えることができます。

前者は決定そのものを委ねているのに対して、後者は決定のために必要な情報を引き出そうとする態度に一歩踏み出しています。
そこでプロダクトマネージャーが「○○するのがいいと思います」と言ったら、たとえばこういう風に続けることができます。「××だからですか?」、「その場合、ユーザーはどう嬉しいんでしょうか?」、「△△という場合についてはどうでしょうか?」。

こうすれば、チームはユーザーや、プロダクトを取り巻く環境について学ぶことができます。
さらには、プロダクトマネージャーを孤独にすることなく、プロダクトマネージャーを含むチームの共同責任において意思決定を行うことができます。

「どうしますか?」と「どうするのがいいと思いますか?」は小さな違いですが、重要な違いです。
チームが学び続ければ、やがて「こうしませんか?」と言えることも増えていくでしょう。

補足

これは「合議」や「全員の納得」を最重要視することとは違います。
結果として議論が盛り上がったり、全員が納得できる結論が導かれることも多くなるでしょうが、それ自体が目的ではありません。

チームがお互いに学び合って成長し、知りうる情報を最大限活用して意思決定し、エンジニアとしてコードだけではなく、プロダクトにコミットできるようになっていくことが目的です。

プロダクトマネージャーを情報源とのコネクターにする

Don'ts: プロダクトマネージャーを情報のボトルネックにする

外の世界とのやりとりはプロダクトマネージャーを通じて行う様子

プロダクトマネージャーはたいてい、エンジニアが知らないさまざまなことを知っています。

ユーザーのこと、ビジネスのこと、ステークホルダーのこと。
プロダクトが使われる世界のことも、組織のさまざまな事情も、多くの場合、一番知っているのはプロダクトマネージャーです。

だからといって、チームが情報を得るための源泉を、プロダクトマネージャーだけに限定していては危険です。

チームが情報を得る能力が、プロダクトマネージャーの能力(可処分時間、コミュニケーション力、情報処理力等のすべて)を上限としてしまうからです。
プロダクトマネージャーがボトルネックになっている状態です。それでは量も、多様性も足りません。

また、ユーザーや他部署とのやりとりの間にプロダクトマネージャーを挟んでいては、コミュニケーションの階層が増えることから、効率もスピードも落ち、お互いを知る機会も失ってしまいます。

最後に、プロダクトマネージャーが窓口になることで、受発注的な関係にも陥りやすくなってしまいます。
本当はユーザーとビジネスのためのプロダクトを作るチームのはずなのに、ユーザーとビジネスのことを考えているのはプロダクトマネージャーだけで、チームは言われたものを作るだけ、という状態です。

Do's: プロダクトマネージャーを情報源とのコネクターにする

プロダクトマネージャーのサポートで、自由に会話する人たち

プロダクトマネージャーには、情報のボトルネックではなく、情報源とのコネクターになってもらいましょう。

プロダクトマネージャーに頼んで、営業やCSの人を紹介してもらったり、一緒にユーザーと会わせてもらったり。

エンジニアと他部署のメンバーが直接つながれば、必要なことは直接やり取りしたり、CSの人とのつながりができれば、ユーザーに会わせてもらったり、といったこともできるようになります。

チーム全体が、プロダクトを取り巻く環境とすばやく、豊かなやり取りができるようになり、早く、多くのことを学べるようにます。

補足

個人的な考えですが、最近、文字通り「すべての」メンバーが「直接」ユーザーを知るべきだと思うようになりました。

以前は「開発に集中したいスペシャリストがいてもいいはずだ」と思っていました。しかし、スペシャリストであっても、ユーザーに直接会う経験は持った方が絶対にいいと感じています。

誰が、どういう環境で、どういう目的のためにプロダクトを使うのかということについて、直接ユーザーに会うことで得られる情報が圧倒的に多いからです。
量的にも、質的にも、人づてに聞くのと比べて、非常に大きな差があります。(このことについての解像度がまだ低く、これ以上うまく言語化できないのですが……)

その人自身が有用な情報を得られるという点でも、チームの人たちとのコミュニケーションが取りやすくなるという点でも、投資対効果が抜群に高いのが「ユーザーに会う」だということです。

もちろん、人によって頻度や濃淡は違っていいと思います。

一緒に仕事に取り組む機会を作る

Don'ts: すべての仕事を分担する

プロダクトマネージャーと別の時間を過ごすチーム

エンジニアのチームとプロダクトマネージャーとが同じ部屋で同じ時間を過ごしていない場合、コミュニケーションを取るまでの腰が重くなったり、非同期的なやり取りが中心になったりしやすいです。
「ここまではプロダクトマネージャーの仕事」「ここからはエンジニアの仕事」のように、境界線を引くような様子も、意識的にも無意識的にも、表れてきます。

すべての仕事を一緒にやる必要はないかもしれませんが、一方で、すべての仕事を分担するのも決して効果的とは言えません。

本当は、お互いの仕事の内容や、やり方から学べることがたくさんあり、結果的にチーム全体の成果ももっと大きくできるはずです。

Do's: 一緒に仕事に取り組む機会を作る

プロダクトマネージャーと一緒に仕事をするチーム

プログラマペアプログラミングやモブプログラミングをするように、プロダクトマネージャーとも、様々な仕事に「一緒に取り組む」機会を作ることができます。

たとえば、リリース計画やイテレーション計画。あるいは、受け入れテスト。プロダクトマネージャーにモブプログラミング自体に参加してもらうこともできます。

これは、「作った計画を説明して見てもらう」であったり、逆に「受け入れテストの定義をしてもらう」ということとは違います。
計画でも、受け入れテストでも、同じ時間、同じ場所で、一緒に計画を作り、一緒に受け入れテストを書く。プロセスも、成果物への責任も共同所有します。

補足1

計画や受け入れテストの例でいうと、もしかしたら、見積もりはあらかじめ済ませておいたり、受け入れテストの自動化コードを書くことはプログラマやテストエンジニアだけでやってもいいかもしれません。
必ず100%の作業を一緒にやろうという話ではありません。

もちろん、一緒にやるのもよいでしょう。

補足2

こういう取り組みは初めはエンジニアから提案し、プロダクトマネージャーに協力してもらうというかたちになることが多いと思います。

その場合、プロダクトマネージャーは慣れないことをしているわけなので、はじめはうまくできなくても大丈夫であることをしっかりと伝え、またやり方についても少しずつ伝えながら徐々に慣れていってもらうとよいでしょう。
一緒に取り組む時間や内容についても、少しずつ増やしたり、少しずつ複雑なものに取り組むようにしていくのがおすすめです。

また、一緒に取り組み続けることで、やがて本当に効果的な分担が見つかり、再び分担するのがよいということになっていくかもしれません。

補足3

最近は、「プロダクトマネージャーへの進捗報告」や、「プロダクトマネージャーが捕まらなくて困っている」などが、このDon'tsが生じているサインだと考えています。

「進捗報告」が必要になるのは、そもそもうまく分担できていないから。(上下関係になってしまっている)
プロダクトマネージャーが捕まらなくて困るのは、そもそも十分な目的と情報の共有・同期ができていないから。

どちらも、「一緒に取り組む時間を増やす」という方法で緩和・解消していけるのではないかという仮説を持っています。(※まだ実績が少なく、仮説レベルです)

お互いに学び合う

Don'ts: エンジニアだけが学ぶ

プロダクトマネージャーから学ぶエンジニアたち

エンジニアリングはすべてを具体化していく仕事なので、自然とプロダクトマネージャーから情報を「引き出す」側に回ることが多くなります。

すべてが具体化された「コード」を書くためには、不足している情報を発見し、聞き出し、確定させていく必要があるからです。

たとえば、エラー処理一つとっても、どうあるべきかを決めるには、ユーザーからどのように使われるかを知る必要があります。
作業の優先順位を決めるにも、ユーザーやビジネスから、どちらがより望まれているのかを知る必要があります。

これらの情報をプロダクトマネージャーに求めること自体が間違っているわけではありません。

しかし、聞く側・聞かれる側という関係が固定化してしまうと、他のDon'tsを誘発し、受発注的な関係に陥ってしまうリスクがあります。
また、エンジニアが知っていることの中には、プロダクトマネージャーも知っていればもっと適切でタイムリーな行動や意思決定ができることもあるはずです。

Do's: お互いに学び合う

お互いに学び合うチームとエンジニアたち

エンジニアがプロダクトマネージャーから学ぶように、プロダクトマネージャーにもエンジニアから学んでもらいましょう。

プロダクトマネージャーには特に好奇心や他職種のことを学ぶ意欲の強い人が多く、エンジニアが思っている以上に学びたがっている可能性が高いと思います。

計画のこと、テストのこと、リリースのこと。どういう理由、どういう考え方で、何をやっているのか。どこにどういうリスクがあり、また機会があるのか。
そういったことを、折に触れて、聞かれなくても、共有していくことはできます。

プロダクトマネージャーが何かを聞いてくれたら、怖い上司や取引先に伝えるようにではなく、すぐ隣の席の同僚に伝えるように、知っていることを気前よく伝えましょう。

文化や慣行、考え方の違いもあるでしょう。驚かせてしまうこともあるかもしれません。
それでも、いや、だからこそ、それらを伝え、学び合うことが、チームになるためには必要です。

補足

これは、デザイナーなどの他職種との間でも同様だと思います。
相手から学ぶことと、相手に学んでもらうことの両方ができているかを問うことは多くの場面で有効です。

おわりに

この記事では、エンジニアとプロダクトマネージャーが日常的には(一見)チームとして活動していない組織で、それでもチームになっていきたいとき、どうすればチームになっていけるかを書きました。

意思決定に必要な情報を引き出す、プロダクトマネージャーを情報源とのコネクターにする、一緒に仕事に取り組む機会を作る、お互いに学び合う。
これらの行動が、プロダクトマネージャーをチームの一員にし、チーム全体として強くなっていくために有効だと考えています。

そもそもなぜチームになっていきたいのか、ということについては特別に取り上げて触れてはいませんが、それぞれのDon'tsやDo'sの中である程度は表現できたのではないかと思います。

僕自身もまだまだ日々考えたり、試してはうまくいったり、いかなかったりしているところなので、記事へのフィードバックや、「自分(たち)はこうしているよ」といったコメントをお寄せいただけるととても嬉しいです。