Konifar's ZATSU

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

完璧に理解できるまで聞く

同僚の事業責任者は、何かの報告に対して自身が "完璧に" 内容を理解できるまで質問し続けてくる。そういうスタンスが染みついている感じがする。

一方、自分は理解した気になってすぐにアクションを考えてしまう傾向があって、まだ完全に理解できるまで聞くという姿勢を徹底できていない。

まだ自分の中でもあまり掴みきれていないのだが、同僚が理解しようとしているときの振る舞いを2つ雑にまとめてみる。

1. 全体像を理解する

  • 個別の内容をピンポイントで説明された時に、その周辺も含めた全体像をきちんと理解する
  • たとえば「この業務でこういう問題が起きています」という報告があった時に、その業務がどういう位置づけでなぜやっているかを聞いたりする
  • 確認してみると実は問題が問題じゃないケースだったりすることもあるので、全体像を把握することが大事

2. 疑問をそのままぶつける

  • 専門外のことでも、自分が他の人に説明できる状態になるまで聞く
  • 専門家に対してこのスタンスを続けるのは意外とむずかしい。特にマネージャーやリーダーは、表面的にでも "物わかりがよい" と思われたいという気持ちがどこか出てしまうかもしれない
  • 同僚は誰に対してもドカドカと質問していく。「なんでこうできないの?やればいいじゃん」みたいな感じでそのまま伝えるのでちょっと相手がやりづらそうにしていることもあるが、ここまで疑問を完全に解消できるまで聞き続けられるのかといつも感心している

そんなにむずかしいことはしてなさそうに見えて、完全に理解できるまで聞き続けるのはやってみると意外とむずかしい。わかったふりをしたり、想像でわかった気になってしまったりする。それがないのがすごい。

状況を正確に理解しないと筋のよいアクションは取れない。それはわかってるんだけれど、シュッと何かを解決していくのって楽しいしついつい問題よりも解決を考えてしまいがち。特にAIエージェントがよき相棒になると、解決にかける時間が短くなってシュッと手を動かしてしまう。

そんな中で、どんなことにも完璧に理解できるまで聞いて、理解できたらスッキリした顔をしてどうするかを考えるという順番をしっかり踏んでいる同僚を見るとすごくいいなと思う。

もしかしたら「マイクロマネジメントすぎん?」とか「全部知ろうとする人めんどくさい」とかいう意見もあるかもしれない。まあそれはそうかも。

自分は逆に細かいところはお任せして大丈夫だろうみたいな感じで自分が理解しきれてなくて失敗した経験が多いので、こういう動きができる人にすごく刺激を受けているのかもしれない。

余談だが、自分は最初はこの同僚が少し苦手だった。 2. 疑問をそのままぶつける のときに全く枕詞や遠慮がないこともあって、圧がつよい人だなと思っていた。今はめちゃくちゃ純粋にわからないことを聞いているだけとわかっているし、尊敬している。

根回し入門

仕事における "根回し" がなんとなく苦手という人をちょいちょい見る。

なんだかフロー化されていない属人的で儀式的なやりとりみたいな感覚を持ってしまう人もいるかもしれないが、根回しはただ物事を円滑に進めるために必要な報連相を事前にやるというだけである。

根回しという言葉はもともと園芸用語で、樹木の移植にあたって事前に根の一部を処理して新しい根の発生を促す作業のことを指す。いいも悪いもない。

要はただの進め方のひとつで、ポイントを押さえれば誰でもできるしできるようになっておいたほうがいい。入門として押さえるポイントを雑に書き出してみる。

1. 話す人を決める

  • まず事前に話をしておいた方がいい人を組織のレポートラインや力学を理解して見極める必要がある
  • 意思決定者などキーパーソンが明確ならその人と話しておくとよい
  • 組織によっては、もしかしたらメンツを立てるために話を通すみたいな力学もあるかもしれない
  • 誰と話せばいいかわからなければ、上長に相談すればたぶん教えてくれる
  • 「この人はなんか意見言いそうだなあ」と想起する人がいれば、その人とは話しておくこと
  • 当日を想像してみて、特にいなければここまで。すべてに必ず毎回根回しする必要はない

2. 相談の予定を入れる

  • 事前に相談したいという連絡をした上で、予定をおさえておく
  • いきなり予定を入れまくるのはよくないという意見もあると思うが、なんだかんだ1人30分くらいずつ直接話すのが早い
  • 先に予定を入れることで強制的に準備が進み、直前に中途半端に相談して結局当日にも色々突っ込まれるといった事態を防げる

3. フィードバックをもらう準備をする

  • 当日に聞いたら突っ込みそうなことや気になることをヒアリングするイメージ
  • どういう観点でその人の意見がほしいかを明確にしておくとさらによい
  • ドキュメントを用意して、当日もらったフィードバックもそこに書くようにする。できれば事前にドキュメントを共有しておくとよい

4. フィードバックをもらう

  • 方向性や考える順番といった次元ですりあっているかを確認するのは必須
  • このタイミングではボコボコにされてもいい。そのための根回しだし、話しておくだけでも当日のサプライズはなくなるのでそれだけでもかなり前進したと思えばよい
  • 具体的な進め方は うまくフィードバックをもらうためのTips が参考になるかもしれない
  • 指摘ポイントを明確にして、必要なら2回くらい話しておくといいかも。3回以上必要になった場合には、進め方を見直した方がいいと思う

5. 当日に事前相談したことを話す

  • 「事前に皆さんに少し相談していただいた意見を取り入れてきています」という話を最初にすると、「今はそういう状態のものを持ってきているのね」という認識が揃って前に進めやすくなる
  • めちゃくちゃ細かいTipsだが、キーマンと概ね合意できているなら「◯◯さんとは事前のすり合わせで大枠の認識が揃っていて」のような感じで話すと話が早く進むこともある。これはあくまで議論の状況を素早く伝えるためであって、参加者のバイアスがかかりすぎたり権威的に感じさせたりする場合にはやらないこと

ざっと思いつくのはこのくらい。営業職の方はもっとずっとハイレベルなことを当たり前のようにやっていると思う。

一番大事なのは、当日をできるだけリアルに想像してみること。「この人がこのへん突っ込んでこんな感じの空気になりそうだな」とか「この人が同意してくれてたらもうそのまま決まるよな」とか。

人ではなくてチームでも同じ。「リーガルチームの立場だったらどこが気になるのかな」とか「CSチームだったらこういうところ気にしそうだけどこれで足りてるかな」とか。

結局は想像力がすべて。当日だけでうまく前に進められるシナリオが思い描けるなら根回し不要という判断をする。そうでなければ根回しをしてできるだけ事前に懸念を潰しておけばいい。

それでも当日は思ってもない方向に議論が進んでしまったりもする。それはもう仕方ない。だいぶ疲れるだろうけれど、根回しが無駄になったわけではない。

「このチームはそういう考え方をするのか」とか、「この人はそういう角度から意見をするのか」といった感じで脳内シミュレーションをアップデートしていくと、少しずつ精度が上がってくる。それでいい。

続けていくうちに、物事をスムーズに前に進めるために必要なことをやるかくらいの感覚になって、"根回し" という言葉すらあまり使わなくなってくると思う。

口数が少ない人の飾り気のない信用

Codex が頑張っている。今日感じたことを雑に書いておこう。

普段しずかで口数が少なめなんだけど、実はプロダクトに対する情熱みたいなものを内に秘めている同僚氏がいる。

「こうしたほうがチームにとっていいんじゃないか」といった意見があれば臆せず言ってくれたりするのもよいんだけれど、スプリントレビューで他の人の機能のデモを見た時に、「いいですね、早く世に出したいですね」みたいなコメントをボソッと言ってくるキャラクターがたまらなくよい。

なんというか、嘘っぽさを感じないのがいいのだと思う。この人が笑ってたら本当に楽しいんだろうなと思って嬉しくなるし、「いいですね」と言ったら本当に心からいいと思っての発言なんだろうなと思ってテンションが上がる。常に口数が多くはないからこそ生まれる飾り気のない信用がある。

今日雑談で話している中で、もしかしたらこういう素朴なよさというのは、強力なリーダーシップを発揮していく過程で"手法"を身につけていくと次第に失われていってしまうんじゃないかと思ったりした。

リーダーやマネージャーの経験がある方は想像つくと思うが、仮面を被って役割を演じて話すみたいなことを意識せずともできるようになってくる。それ自体が悪いことではないのだけれど、「この人は本当にそう感じているんだな」という飾り気のない信用は失われていく。

もっと高いレベルになるとそんなことはないのかもしれないけれど、少なくとも自分を客観的に見ると「本当にこの人こう思ってるのかな」と心のどこかで感じてしまうかもしれない。それは仕方ないことでもあるので、他の方法で装飾された信用を固めていく必要があるのだろう。

振り返ってみると、仕事にかぎらずこういう裏表のなさを感じさせる人というのはいた。一種の才能だと思っていて、正直うらやましい。同僚氏はすでにチームをリードしていってくれているが、今持っているよさをそのまま活かした感じでボソッとアツいことを言い続けてほしいと思うなどした。

"当たり前レベル"の上げ方

組織の地力は「当たり前のレベルがどういう水準か」に現れる。

たとえば「このレイヤーのテストコードは当然書く」とか「Pull Request の description はレビュワーや将来の自分たちのために丁寧に書く」とか。あるいは、「皆が今期のチーム目標を言える」とか「期日までに勤怠の提出を全員が終えてる」とかもそう。

こういった一つ一つの"当たり前"のレベルがどういう水準かが組織の強さと言えるが、これを上げていくのはなかなかむずかしい。この"当たり前レベル"を上げていくにはどういうステップが必要かを雑に書いてみることにする。

1. トップオブトップを知る

  • まずはトップオブトップの組織ではどういうレベルなのかを知ること
  • 現時点でのトップの当たり前レベルを知り、そこから自組織の相対的な立ち位置を把握する
  • 手段はWebや書籍、Podcastからのインプットでもいいし、イベントやカンファレンスに参加するでもいい
  • 専門職であれば継続的な学習は必須。とにかく世界を広げて知ることが大事。
  • 広げていかないと目指すレベルをどこに設定したらよいかわからず、筋の悪い方針で進めてしまったり、無駄な再発明をしたり、井の中の蛙になったりする

2. 目線を合わせる

  • どういうレベルにしていきたいか、チームでの目線を合わせること
  • たとえば "デプロイ頻度" などは、エリートレベルのような指標も定義されているので共通認識を持って話しやすい。DX Criteria で定量化するのもよいと思う
  • 内容によっては、ここで合わせたことがチーム目標になるかもしれない

3. 引っ張る

  • 数人の引っ張り上げる役割がいないとレベルは上がっていかない
  • 同じレベルのメンバーが色々工夫するのではなく、数人が先に "当たり前のレベル" を上げて見本を見せ引っ張り上げていく必要がある
  • 背中を見せて「この人くらいやらないといけないんだ」と思えるようなタイプだと最高。そういう人はめちゃくちゃ貴重
  • ただし、背中を見るだけで組織の当たり前レベルが上がっていくことはないので、"おかん"のような一定の口うるささも必要
  • 「あの人にこう言われるかもな」という感じで、皆が少し緊張するくらいの人がいるほうがいいのかもしれない。そういういい意味での緊張感を作れる人もまた貴重
  • もちろん、人に依存せず強制するような仕組みを作れるならその方がいい。実際にはそういう仕組みを作るところを引っ張っていく役割が必要になることが多い

4. 振り返る

  • 定点観測して、前と比べてどうなったかを確認すること
  • 振り返るには、定量でも定性でもよいので指標を決めて計測しなければならない
  • これをやらないと効果も測れないし、効果が測れないとだんだんと形骸化して止まってしまう。ダイエットと同じである

5. やり続ける

  • 1~4を繰り返し続けていくことで、少しずつ当たり前レベルが上がっていく
  • なんだかんだこの"成果が出るまでやり続ける"というのが一番むずかしい
  • これを続けていくと文化となり、"当たり前のレベル" がどんどん上がっていく土壌が育つ

雑に書き出してみたが、「せやな」って感じで読むだけだと何の意味もない話になってしまった。これを読んで実践できるならそもそも悩んでないんだよな。自分もできたと言える経験がほとんどない。

結局こういうのは誰かが覚悟決めて歯食いしばって愚直にやり続けるしかない。それこそが真のオーナーシップだし、"当たり前レベル"が高いように見える組織は誰かがその役割を担ってきた積み重ねによるものなのだろう。がんばろう。

チャットコミュニケーションでの不満の表明は悪手

今は全くやらなくなったが、チャットコミュニケーションでなんだか憤りを感じた時に "お気持ち" をガッと文章で書いてしまっていたことがある。

この振る舞いは物事を前に進める上では悪手でしかないと思っていて、そんな感じのことを雑につらつらと書いておきたい。

自分の経験上、チャットコミュニケーションで「お言葉ですが」とか「気持ちだけ書いておくと」とか「ちょっと言っておきたいんですが」みたいな感じで自分の不満をテキストで表明するのは悪手。ここまで露骨ではないにせよ、ちょっと非協力的になって"拗ねた"り、線引きして突き放したりするような物言いをするとかもこれに含まれる。

やっちゃダメとまでは言わないけれど、建設的に物事が進むことは少ない。もし進んだとしたら、それは不満を表明した自分のおかげではなく噛み砕いて軌道修正してくれた相手やまわりのおかげ。勘違いしてはいけない。

「そうは言ってもきちんと明確に自分の考えを伝えておかないと同じ状況が繰り返されるじゃんか」という考えもある。わかる。そのとおり。不満に感じたことを伝えなければならない場面もある。不満というかフィードバックだね。この違いをきちんと意識するのもむずかしい。そういう時はテキストではなく "直接話して" 伝えるほうがいい。

テキストコミュニケーションで相手に齟齬なく意見を伝えるのはそもそもむずかしい。うまくできる高度なスキルを持った人のほうが少ないので、基本的にはやらないというルールを自分に課したほうが考えることが減って楽になる。

自分が意見を伝えたこと自体を証跡として残したいのであれば、直接話してから話した内容をドキュメントに残してチャットに投げておけばいい。いきなりチャットでピシャリと書く以外にも方法はあるので少し落ち着こう。特に、「自分が代表して言ってやらねば」みたいな気持ちが少しでも混じってる時は要注意である。「何かいいことを言ってやろうとしていないか」と自問してみてもいいかもしれない。

チャットに書いた "お気持ち" に対して数人から好意的なリアクションがついたりすると、言われた相手も感情的にやりづらくなってさらに物事が進みにくくなることもある。自分はこういう "お気持ち" 的なコメントを見かけた時、内容に関わらず反応しにくい。言った人/言われた人両方がどう捉えるかわからないからである。「ちょっとhaddleで話してみるのはどうですか?」みたいな感じで間に入ることもあるが、基本的には静観になってしまう。こういう時はどうすればいいんだろうね。ナイフエッジ・デスマッチでも提案できればいいんだろうけれど、そんなスキルがない。

自分自身も相手に不満をテキストで伝える振る舞いをしていたことがあるが、なんかそのやり方を続けても物事が好転しないなと気づいて色々試した結果「テキストでやるのは悪手」いう結論になった。過去のSlackの自分のやりとりを検索してみると、なんだかヒロイズムを感じていたような、自分にとっての正論をぶつけるようなコメントが出てきてしんどい。大人の黒歴史である。まあこうやって少しずつ成長していくんだね。

自分の立場や役割を宣言してから話す

仕事で何か意見を言う時に、"いま自分がどういう立場や役割で話そうとしているか"を宣言するとチョットだけ話しやすくなる。このあたりの話を雑に書いておきたい。


チーム、職種、職責の違いによって、同じ発言でも捉えられ方が変わってしまったり、受け入れられなかったりすることがある。

あるいは逆に、マネージャーやリーダーが意見を言うとその意見が"正"だという雰囲気になってしまったりすることもある。経験がある人はわかると思うが、これは結構やりづらい。かといって、あえて発言を控えるのもよくないし悩ましい。
そういう時に、「マネージャーではなくて自分もいちメンバーとして話すと〜」のような感じで切り出すと少しやりやすくなる。

チームメンバーでも同じ。たとえば「実際に開発するエンジニアの立場としてちょっと現実的なことを言うと〜」みたいな感じで話すと、いち個人の懸念というよりは役割を全うしようとして出てきた意見だということが伝わって建設的な議論に進みやすい。

「これは友人としての意見と思って聞いてほしいんだけど〜」、「これはマネージャーの立場としてフィードバックさせてください」、「経営の中で一番開発をしてきた立場としては〜」みたいなのもそう。役割や立場を最初に宣言することで聞く側もモードを切り替えてくれるし、自分自身も気持ちを切り替えて伝えやすくなる感覚がある。

新しい組織に入った時とかも、「先入観のない意見を言える立場として、ちょっとだけいいですか」みたいな感じで宣言すると意見を出しやすくなったりもするかもしれない。

「そんなんあえて明確にするのめんどいし必要ないやろ」という意見もあるかもしれない。わかる。わかるんだけど、自分の経験上はこういう枕詞を入れたほうが余計な感情の摩擦を減らせるし、意見自体も齟齬なく伝わる。まあやっといてもいいんじゃないかな。

正直に言えば、いちいちそういう宣言をしないと話しにくいと感じてしまうこと自体になんというか少し寂しい気持ちになったりもしなくはない。けど今のところ最適な動き方だとは思っているので、意識しなくてもできるようになるまで慣れていくほうがいいかなと考えている。

浮いたボールを拾えない理由

仕事で浮きそうなボールを拾ってくれる人はめちゃくちゃ尊い。

ずっとやり続けている人はもはや癖になっていて、浮きそうなボールを見るといち早く手を上げて飛びついていく。自分のまわりのすごい人はそういうムーブをしている人が多くて、結果的に色んな経験が有機的に紐づいてどんどんさらにすごい人になっていっていたように見える。

ただボールを拾うのは意外と難しいというか、躊躇してしまう理由も色々ある。思いつく「浮いたボールを拾えない理由」を雑に書き出してみる。

1. 余裕がない

  • 今持っている仕事で手一杯なのに、拾ったボールも自分のボールも落として両方中途半端になってしまったりしないか不安になって拾いにくい
  • 「今こういう状況で自分は拾ってもやりきれるか自信はないんですが」みたいな感じで拾ってみるのをオススメしたい

2. 詳しくない

  • 正直内容がよくわからなくてほぼ0からキャッチアップしなければいけないし、自分よりうまくできる人がいるならその人のほうがいいと感じると拾いにくい
  • 「正直0からキャッチアップなのですが、他に手を挙げる人がいなければやります」みたいな感じで拾ってみるといいかも

3. 適役ではない

  • 自分がやってもいいけど、役割を過度に越境してしまっていないかとか考えると拾いにくい
  • 「もっと適任がいるかもですが、ひとまずやってみます」みたいな感じで拾っていくといいかも

4. 得にならない

  • 自分のためになるかとか、やり損にならないかとか、しんどくなりそうだなとか考えだすと拾えない
  • これはそうだよねぇ。難しい。結果的には自分にとっても絶対プラスになるのでやっていこうなとしか言えない

1~3 は「いま自分が拾っていいのかわからない」という感覚が根っこにある。

そりゃそうだよね。拾う前にはできるかどうか自信もないし、どのくらいかかるかわからないし、もっと詳しい人がいるかもしれないし、中途半端に拾って迷惑かけたくないし馬鹿や出しゃばりとも思われたくないし、自分が拾っていいんだろうかという気持ちになるよ。

だからこそ、そういう時にお見合いせず手を挙げて取り組める人はそれだけでだいぶ上等になる。ユーザー問合せ対応やアラート対応、浮いてそうなPRレビュー、拾われていないグループメンション、誰も手を挙げていないタスクなどは、基本的に貢献しやすくすべておいしい。

たしかにやっていくときには踏ん張る必要はある。うまくできない不安はもちろんあると思うし、短期的には損をしたと感じることもあると思う。一方で、そういう姿勢を持って仕事をしていると必ず次につながってプラスになる。前のめりに浮きそうなボールを拾い続けている人は、明らかに成長の速度も違う。

"ボールを拾う"の前に、"手を挙げて意思を表明する"だけでもいいかもしれない。その際、前置きとなる言葉を増やしておくと少し楽になる。「わからないけど見てみます!」、「詳しい人いたら補足お願いします!」、「いったん自分が持って◯時まで見てみて、無理なら連絡します!」とかそんな感じ。

あとは、同僚やチームと共通認識を合わせておくとハードルも下がっていいと思う。役割分担や仕組みをうまくやっても必ずボールは落ちるから、間に落ちそうなボールを皆で拾っていくぞみたいなやつ。

LayerX 羅針盤 には、「自分のボールを落とさず」という文言が入っているのもすごくよいと思う。songmuさんが書いていた記事 の「私は仕事においてお見合い落球が発生することが大嫌いです。」みたいな宣言もとても好き。

まあ色々書いてきて最後に雑なことを言うと、こういうのは最終的には美学と気合い。覚悟を決めてやっていくしかない。最初から色々考えずに、まず一回全力でやってみてからバランスを取っていくのがいいと思う。