Konifar's ZATSU

私はのび太の味方じゃないわ、悪の敵よ

人から相談を受ける時に気をつけること

誰かから相談を受けた時、後でよくなかったなと思うことがちょいちょいあるので雑に書いておく。 相談の種類や関係性にもよるので、たぶん違和感を覚える内容も含まれるとは思う。

  • 相手の話を聞く
    • 当たり前なんだけど、意外とできてないこともある
    • 自分の話を起点にしてはいけない。相手の話を聞くのが先で、自分の話は聞かれたらするくらいでいた方がいい
  • アドバイスが必要かどうかを見極める
    • 相談をされると解決のための話をしてしまいがちだが、そういう論理の話をしたいわけではないこともある
    • 例えば聞いてくれるだけで救われることもあるし、相談相手が感情的に怒ってくれることで自分が冷静になるみたいなこともある
    • 相手がアドバイスを求めているのか見極めた上で、アドバイスする場合にはバイアスをかけないように慎重に
  • 同調しすぎない
    • 共感と同調は違う。共感することは大事だけど、同調しすぎると相手の負の感情を増幅させることにもなる
    • 「つらかったね」はいいけど「そいつ最悪だね」はよくないみたいな感じ。まあ相談の内容にもよるけど、あんまりいい方向に進まないことが多い気がする
  • 終わり方に気を配る
    • どういう相談であれ、終わった後に相談しなければよかったという気持ちにさせないようにしたい
    • 相談内容は言語化しきれていないことも多いので、終わった後で「あんなことを言ってしまった」「相手にこう思われたかも」と不安になるかもしれない
    • 相談してくれたことに対して礼を言ったり、いつでもまた話しましょうと伝えたり、終わり際を大事に、少し過剰くらいに気を配った方がよい

これらは全てハンターハンターとバチェラーから学びました。

直接話す、すぐ話す

最近嫁氏とバチェラー4を見ていて思ったことを雑に書いておきたい。

第4話にて、ある女性が「バチェラーがこう言ってた」みたいな少し事実と異なる内容を他の女性陣に話したことで、バチェラーへの不信感が広がりだいぶ面倒なことになるという"事件"があった。

それに対しバチェラーがすぐに1人ずつ対話の時間を作り説明していたのを見て、結局これしかないよなあと思った。

種類や程度は違えど、組織においてこういうことはよく起こる。その時に重要なのは、関係する当人とすぐに直接話すことである。

例えば事業の優先順位に納得できないときに、説明を受けた者同士でああだこうだと話したりするよりも説明をした人に直接聞いた方がよい。

あるいは誰かの発言に棘を感じてモヤモヤした時は、本人に直接話して解消したほうがよい。

小さいところだと、Slackで「これ大丈夫かな」「どうなってるんだろ」みたいな懸念を書くときには関係しそうな人やグループに直接聞いたほうがよい。

ただ、これは個々人がそうしようと思ってもなかなか難しい話である。何か起きた時に直接話すには自分にも相手にもある程度のコミュニケーションスキルが必要だし、スタンスの違いによっては面倒くさいと捉えられがちだからである。

風通しのよさ、心理的安全性といった組織の状態によっても、直接すぐに話せるかどうかは変わってくる。「直接話す、すぐ話す」という行動自体を、行動指針で是とするような一定の方向性を決めておいたほうがいいのかもしれない。例えばdely社のバリューの1つであるHeart to Heartは、そういう話を含んでいると理解している。「直接すぐ話してみたら?」「〇〇さんに直接メンションしたらいいと思いますよ」みたいな会話が自然と出るような状態が作れるとやりやすい。

もちろん対人コミュニケーションでの解決に対して面倒くささを感じる人もいるとは思うが、自分の経験だと何だかんだ直接すぐ話すのが一番早いし楽なことが多かった。逆に推測だけで考えてしまったり、すぐに聞かずに溜め込んだりしたときの方が、振り返ってみるとより面倒くさい状況になっていたように思う。

自分に不信を抱いている複数人の女性とすぐに対話するというフォローをしたバチェラーはすげえよ。ハンターハンターと同じくらい学びのあるコンテンツである。

コミュニケーションのシナリオ

何かの共有や相談をする時に、文章の表現や伝えるタイミング、伝え方や伝える順番などがとても"上手い"と感じる人がたまにいる。

逆に下手な人もいて、そういう人を見ると"もったいない"という気持ちになる。そういう人は伝え方で損をしてしまっているだけで、内容についてはかなりよく考えて準備もしていることが多いからである。上手い人と下手な人の違いはわりと暗黙知になりがちなので、何が違うかを考えながら雑に書きなぐっておきたい。

文章のテクニックや声の抑揚、表情といった細かい要素はあるのだけれど、一番の違いはコミュニケーションをとる時のシナリオをどれだけ想定できているかだと思う。イメージとしては将棋やチェスで相手の手を読むのに近い。

「この話はSlackで伝えたら微妙なニュアンスが伝わらなそうだから直接話そう」とか「チームの定例で話すよりも1対1で直接説明した方がいいかもな」とか、それくらいのレベルのシナリオは誰しもが考えると思う。上手な人はそこからさらに細かくシナリオを立てているように見える。

「こういう伝え方をしたらたぶんこういう反応が来るからそのへんの内容も盛り込んで最初から伝えよう」とか「自分よりもこの人からこういうふうに伝えてもらって、たぶんその場でわからない疑問とか出るから自分が後で補足しよう」とか、そういう複数に分岐したシナリオを頭の中で色々想定して、いざコミュニケーションを取る時はもう半分答え合わせみたいな感じなのではなかろうか。

相手の持つ知識や情報を見極めた上で、感情や思考を何手か先まで読んでコミュニケーションプランを考えて取捨選択してるという話だと思うが、これができるのはセンスなのだろうか。伝える人、伝える相手、タイミング、伝える場などいくつか要素があるけれど、言葉の選び方は正直センスじゃないかと思っている。

センスは知識と経験によってある程度までは磨くことができるので、まずはシナリオを立ててからコミュニケーションをとる癖をつけるのが重要なのかもしれない。簡単なところだと、何かを相談する時に相手とのやりとりの数を減らすことを考えて、「こうきたらこう」という想定と検証を積み重ねていくと、だんだんと身に染み付いて"上手い"人になっていくのではないかと思う。

仕事のインパクトを大きくしようとすると人を巻き込む必要がある

マネージャーではなくとも、ある程度高い成果を期待されている人にはマネジメント能力を要求される。そういう話を雑に書いておきたい。

1人でガッと進められる範囲の仕事のインパクトには限界があり、あるレベル以上に達すると、誰かに何かを依頼したりチームを超えて足並みを揃えたりする必要が出てくる。

ここで要求される能力には、チームビルディング、ネゴシエーション、ファシリテーション、スケジューリング、ロードマップ作成といったものも含まれる。マネージャーロールではない場合、「これってマネジメントなのでは?」と感じることもあると思う。それに対する自分の答えは「Yes」である。仕事のインパクトの大きさを広げようとすると、マネジメントと同じようなスキルはプレイヤーにも必要になる。結局 Manage (なんとかする) 能力も技術と捉えて磨いていく方がよい。

つまるところ、いわゆるマネージャーとプレイヤーの違いは、チームのピープルマネジメントの有無でしかないのだと思う。キャリアを考慮してチーム構成やタスクを考えたり目標の設定をしたり、そういう人と向き合うマネジメント以外のスキルは、プレイヤーも身につけて発揮しないと高いレベルの成果は出せなくなる。

もちろん、そこでの進め方や調整のフォローアップなどはマネージャーにも相談する方がよいが、プレイヤーといえども人を巻き込んでその中でマネジメント能力を駆使する必要がある。まあ実際どの程度そういうことをしなければならないかは組織体制や役割にもよるが、仕事のインパクトを大きくしようとする時にはそういう能力が必要だという前提で考えておいた方がいい気はする。

マネジメント自体は全員が持って発揮するべき能力で、マネージャーだけのものではない。ただしピープルマネジメントは少し違った能力なので、そこはロールを分けてマネージャーにしているくらいの役割分担みたいな理解でいた方がいいと思う。マネージャーもプレイヤーもそこまで分けて考える必要はない。

一方で、マネージャーの方が様々なマネジメント能力を要求される場面が多いのはたしかである。そういう意味では、マネージャーからプレイヤーに転換した人は強い。一度マネージャーを経験した人はプレイヤーとしても経験を活かして影響範囲を広く持って高い成果を出しているように思う。マネージャーとプレイヤーを行ったり来たりできる組織こそが、もしかしたらすごく強いのかもしれない。

説明責任と信頼

仕事において、やる目的や内容が見えないとすごく憤りを感じることが人がいる。自分もたまにある。これは当然の感情だと思っている。

ROIの高い仕事をするには目的が何より大事だ。また、「わからない」「自分は知らない」という情報の非対称性に対する不安や嫌悪感は、誰しも持ち合わせている。これは物事を知り学ぶことによって生き延びてきた人類の本能と言ってもいい。いや、チョット言いすぎたかもしれない。

それを前提として、説明する側はしっかりと説明責任を果たそうと気を配る。いわゆる情報の透明性や風通しの良さというやつである。組織についてしっかりと考えているところはどこもすごく頑張っていて、それ自体もとてもよいことである。

一方で、説明をする側、受ける側という構図がなんだかよくないというか、フェアじゃないような気持ちになることもある。説明をする側を経験してきた方はわかると思うが、本人も正解かどうか自信がない状態で何とか説明していることも多い。

説明を受ける側は、ある程度ゆるく「まあ説明する方も大変だし一緒に補完していくか〜」みたいなスタンスでいる方がよい。その方が無駄にイライラしなくて済むし健全である。これは「相手に対する期待値を高く持たないこと」と捉えることもできるが、どちらかというと「ゆるい信頼」みたいな感じで接することができる状態が理想だと思う。

「まあよくわからないけどあの人なら何か考えてるだろ」とか、「このへんはたぶんそのうち説明されるだろ」みたいな関係性で仕事ができるとめちゃくちゃ楽。まあ実際にはそんなに信頼できないから憤りを感じるという話なんだろうけど、正しく細かく説明すること以前にそういう信頼の方が大事でレバレッジが効く。逆にいうと最低限の信頼がなければ、情報としては100点の説明内容だったとしても全体の納得度は低いという残念な話にもなりうる。

余談だが自分は15歳の時の出来事をきっかけにつよく感情的になることはなくなったように思う。姉には感謝している。

説明をする側も受ける側も相手へのリスペクトを大切に、そして次の曲が始まるのです。

HUNTER×HUNTER×PdM

先日参加した pmconf 2021 の Discord に、クロージングのあと約20分ほどハンターハンターのチャンネルが作成され、そこで少し雑談をした。

ハンターハンターの台詞はプロダクト開発の中でも活かせるものが多いよねという、雑談チャンネルにふさわしい内容であった。正直自分でも後で何の話だっけ?となりそうなので、話した内容 + α をざっと書いておく。

ドキドキ2択クイ~~~~~~~~ズ!!

プロダクト開発の中で、トレードオフを考慮しなければいけない場面は多い。「ではドキドキ2択クイズしますか」のように使うと議論が整理できてよい。ただし、この場合の答えは「沈黙」ではない。また、トレードオフだと思い込んでいるだけで実は「ナカヌキ」的な一手が存在しうることもあるので注意が必要。

今オレ達にとって最悪のケースってのは何だ?

議論の本質が見えなくなった時に整理できる。実は今話している前提から間違っていることもありうるので、PdMに限らずフランクリン的な立ち回りは大事。何かのキックオフで「それでは堅苦しいあいさつはぬきにして...」と始めるのもいいかもしれない。

オレが3人分になる...

PdMはやることが多い。チームで期待のすり合わせをしたとしても、間を埋める仕事は山のようにある。自身が仕様を作り、白い賢人 (ホワイトゴレイヌ) が法務の確認をして、黒い賢人 (ブラックゴレイヌ) がリリース時の諸々を整備するといった切り替えを意識的に行えるとよい。

ゴンが止め!! ヒソカが覆い!! キルアが支える!!

これがチーム開発の理想である。中でもキルアの役割は大きい。そう、PdMに求められる役割というのは、レイザー戦終盤におけるキルアなのではなかろうか。そしてまわりのメンバーはキルアの役割を認識し、「キルアじゃなきゃダメなんだ」という気持ちで自身の役割を全うするのがよいのだろう。

来週死ぬのあたしです

ヤバイ時にヤバイと言えるチームはよい。振り返りの時には皆で4行詩を読み合いましょう。あるいは、「オレは これでも そこそこ腕は立つ」という枕詞から自身の状況を伝えてもいいかもしれない。

(つーか これが限界)

自分の能力を正確に見極めて断言できるのはすごい。PdMが無理にタスクを抱えすぎてボトルネックになったり潰れてしまったりするよりは、限界なことは限界と伝えておくとよい。

オレも旅団 (クモ) の一部。生かすべきは個人ではなく旅団 (クモ)

PdMは役割のひとつ。マネージャー = 上長 というイメージが先行して上下関係を連想する人もいるが、どちらかというと部活のジャーマネに近い。それぞれ役割があり、チームがよい方向を向き、最終的によいプロダクトを作れればよい。

四大行とは意志を強くする過程の修行

「点」で心を1つに集中し自己を見つめ目標を定め、「舌」でその想いを言葉にし、「錬」でその意志を高め、「発」でそれを行動に移すというプロセス、これは中長期のプロダクト開発の流れそのものではなかろうか。

これが属性の相性を示す表 六性図です

PdMはカバー範囲が多い。強みを持たないとキャリアを考える上でも不安になること多そう。PdMチームを作る際の評価軸はおそらくひとつではなく、念の六性図のように分解して考えるとよさそう。その中で容量のムダ使いにも注意しながら面積を増やしていくのがいいのかもしれない♠️

己の肉体と武術に限界を感じ 悩みに悩み抜いた結果 彼がたどり着いた結果は 感謝であった

自分の経験の中でイケてるPdM、特にもともとプレイヤーとしてエンジニアやってた人なんかはこんな感じの境地に達していた気がする。ただし一日一万回必要なことはプロセスの見直しをしていたとも思う。

言わないんじゃなく言えない♠️ ボクがギリギリ言えるのはそこまでだ♣️

対ユーザーやパートナーに対するコミュニケーションを考える時にこういうことよくある。これは実際にプロダクト開発をリードして様々なステークホルダーとやりとりした人なら必ず経験があることだと思う。


書き出してみると、なかなか好みが偏っていることがよくわかる。来年pmconf 2022が開かれるまでに、暗黒大陸に上陸していてほしい。

ドキュメントが更新されない問題

むかし、この国が深い森におおわれ、そこに太古からの神々がすんでいた頃から語り尽くされているドキュメントが更新されない問題について雑に書く。

実態が変わったのにドキュメントが更新されない問題はいつどの時代も絶えない。これにいちいち憤りを感じるのは不幸になるだけなので、何かしら対処を考えておかねばならない。パッと思いつくのは次のようなものだろうか。

  • 使う
    • 使わないから更新もされなくなる。定期的に使われるように設計して、そもそも使わない場合は消した方がいい
    • いっそ参照回数が少ないドキュメントは自動でアーカイブしちゃうみたいな硬派なスタイルの方がいいのかも
  • 詳細に書きすぎない
    • 細かいところを書きすぎると保守できない。骨組みだけ大事にして、細かいところはフロー情報として分けて書くのがよい
  • 管理者を置く
    • ちゃんと更新されるようロールを作る。属人化しないようにロールを引き継ぐ設計も必要
    • 個人的にはあんまり管理者は置きたくはない
  • 目線を合わせる
    • ドキュメントに対する感度は人によって違う。例えばドキュメントは気づいた時に皆で更新するものというような目線合わせは必要
  • 掃除をする
    • 何やっても必ず古くなるんだから、半年に1回くらいはみんなで大掃除するようなイベントを作る
    • そもそも整理できていないから気づかれず更新されないというのもあるのでこういうのは必要

書き出してみたけれどたぶんこれらはわりと細かい話で、一番大事なのはドキュメントが更新されやすくなるような最初の設計なんだと思う。

たとえばフローとストックをうまく分ける指針だとかディレクトリ構成だとか、適切なグループ分けや権限設定、ルールが守られていない時に自動検知してワーニングを出す仕組みなど、根っこの設計がないといたちごっこになりがち。

こういう設計を考えたりツール選定したりあるいは作ったり、社内に浸透させたりするのって、ある規模よりでかいと片手間ではできなくなる気がする。そういう専門チームが社内に必要になるのかもしれない。

自分の経験だと設計は途中から変えるのはわりとエネルギーがいる。途中から変えることに躊躇のない決断力や、そういうもんだよねと順応できる組織が結局のところ強いのだ。

なんかドキュメントが更新されない話からはだいぶ外れてきた。他の森の知見吸いたい。