Konifar's ZATSU

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

「何か質問や意見ありますか」の後の無言対策

オンラインのミーティングで「何か質問や意見ありますか」と聞いた後の無言がつらいんだよねという話を聞いた。わかる。自分はもはや慣れきってしまったけれど、今でもいい方法ないかなあと考えている。

いくつかやったことを書いてみる。組織によってもだいぶ違うと思うけれど、他の人の知見をめちゃくちゃ聞きたい。

最初に声を出してもらう

少しでも最初に声を出しておくと意見を言いやすいという研究があるらしい。なんとなく実感としても正しい気がしている。

ただ全員に雑談を振るというのもちょっとなあという時に自分がやっているのが「出席をとります」である。皆なつかしい気持ちになってほんわかするし、返事をするだけでもよいので楽。時間もかからない。

参加者の役割を最初に話す

どういう役割や発言を期待しているかを明確にしてあげるとそのスタンスで意見を言いやすくなる。たとえば「○○さんにはモバイルの開発工数観点でかなり現実的な意見を言ってほしいので正直にガンガン言っちゃってください」みたいな感じ。

具体例を出す

「何かありますか」と聞かれると出ないけれど、「○○の観点で不安だなーとか何でもいいですよ」などちょっと具体的に言うとその周辺の意見が出てくることがある。

「よくわからなかった内容の確認とかも歓迎です」のような感じでもハードルが下がってよいかもしれない。

名指しで聞く

全員に聞くとなかなか発言しにくいが、「○○さんこういう観点で懸念ないですか?」のように名指しすると話してくれたりする。

誰に聞くかは表情やこれまでの発言、把握している性格や役割から推測するしかない。

参加者にフォローをお願いしておく

参加者の中に視野が広かったり意見を明確に伝えてくれたりする人がいれば、「切り込んでいってほしい」「必要に応じて他の人にも意見を促すような意識でやってもらえると助かる」みたいなことを先に伝えてフォローをお願いしておくとやりやすいこともある。

意見に対して反応を返す

意見を言ってくれた時に「ありがとうございます」「いい視点ですね」「おーなるほど、たしかに」といったポジティブな反応を返すようにする。ちょっと大げさくらいがちょうどいい。詰めてしまったり変な空気にしたりすることは避けるべき。

テキストチャットを推奨する

オンラインのミーティングにおいて、テキストチャットはとても強力。マルチスレッドでミーティングを進められる。チャットで意見を出してもらえればそれがきっかけになる。ミーティングのファシリテーターはラジオパーソナリティのような振る舞いに変化してきている感覚がある。

「チャットでもいいですよ」ではなく、ミーティングの最初に「何か思ったことがあったらどんどんチャットに書いちゃってください」のように推奨するくらいの方がよい。

テキストやバーチャル背景で意思表示をしてもらう

「意見ありは1、考え中は2、特になしは3」といった具合にルールを決めて、いっせーのーせでテキストコメントを促すと全員の意見を瞬時に集められる。この例の場合、1の人がいたらそこから意見を聞いていく。その間に2の人に考えてもらうこともできる。

やったことないけれど、このやり方はバーチャル背景でも可能。「質問です」「完全に理解した」「ちょっとよくわかりません」みたいな意思表示が書いてある背景画像を用意しておいて、参加者の背景がミーティング中にコロコロ変わるみたいな感じだと面白いかもしれない。

意見を待つ時のルールを決めておく

無言がしんどいのはいつ切り上げていいのかわからないからというのが大きい。「10秒待って特になかったら次行きます」みたいな感じで先にルールを決めて宣言しておくとそれだけでつらみは減る。


自分が話さなくても参加者がどんどん話していく状態を作れるのが本当にファシリテーションのうまい人だと認識しているが、自分は無言がとにかく苦手で話しすぎてしまって後で反省することが多い。余談だが、これは嫁氏との最初のデートの時も同じだったのでここ10年くらい本質的に何も成長していないことがわかる。

タスクの委譲における信頼と伴走の設計

息子氏がスプーンやフォークで一人で飯を食えるようになってめちゃくちゃ楽になった。素晴らしい権限委譲だ。ヤッタネ!!

自分はタスクを人にお願いするのが未だに得意ではない。息子氏がスプーンで飯を食えるようになったのも、嫁氏がスプーンを持たせて少しずつやらせていったという要因が大きい。自分は朝の忙しい時などついアーンさせてしまうことも多かった。

この「自分でやった方が早い」、あるいは「相手にはこのタスクはまだできない」という思い込みが、タスクの委譲をうまくできない根本の原因である。できるかどうかはやってみないと判断できないにも関わらず、お願いする前から決めつけてしまっているのである。

そもそも何かのタスクを委譲しようとする時、それは相手にとって初めての内容であることが多い。なので基本的にはお願いしてみないことには何も始まらない。相手を信頼して任せた上で、うまく進めるための設計を考える必要がある。

信頼という点では、何をもって委譲できると信じるのかが重要である。これは、相手のことをよく見ていないとわからない。具体的に言えば、『スキルと意欲に関する事実』を見極める必要がある。

スプーンで飯を食う息子を例にすると、「これまでなんだかんだコップで水も飲めるようになったし手掴みで食べられるようになったよなあ」とか「俺が料理してる姿を真似ておままごとしてたりするよなあ」というのがスキル面で信頼しうる事実である。ちゃんとコミュニケーションを取っていると、彼ならやれるかもしれないと思わせる何かが見えてくる。

仕事で言えば、「個人でアプリ開発してるって言ってたよなあ」とか「面白い記事をよくSlackに投げ込んでいてアンテナ高いよなあ」とか、直接そのタスクと関係がないことでもタスクをお願いするにあたってかぶる領域がある。

スキルに加えて、意欲も重要である。「相手はやりたくないんじゃないかな...」と考えてしまって委譲できないこともある。これも結局相手のことをよく知るしか方法はない。スキルと意欲について知るための設計が重要になる。雑談や1on1、チームラーニング、評価での対話など、色々な方法がある。Slackのやりとりをよく見るというやり方もあるが、ちょっとコストがかかりすぎるのでやめた方がよい。

とはいえ、委譲における信頼は最終的には決めの問題で、エイヤとお願いしてみるしかない。相手自身もできるかどうかやりたいかどうかをよくわかってないこともある。

お願いするにあたって重要なのが、『意義の伝達と伴走の設計』になる。何のためのタスクなのか伝えた上で、うまく進めるための進め方を決めるという話である。

何のためにやるかがすり合っていないと、お願いしたタスクのアウトプットイメージがずれることがある。委譲する時にはやり方のみを伝えがちだが、意義を明確にして伝える方がよい。組織によってはマニュアルの最初に『なぜ必要か』『背景』といった項目をテンプレにしてるところもあると思う。

委譲が苦手という人の中で一番多いのが、『伴走の設計がうまくできない』というパターンなのではないかと思う。自分はまさしくこれに当てはまる。

たとえばスプーンで飯を食うという動作を分解すると、『スプーンの向きを意識して持つ』、『お椀に突っ込み飯をすくう』、『口まで持っていく』、『口から抜く』という手順になる。『飯をすくう』ところまでをフォローすれば、『口まで持っていく』部分はできることはすぐにわかった。なのでまずはスプーンに飯を乗せるところだけは手をとってやってあげることを繰り返していくことで、次第に10回に2回くらいはひとりでできるようになる。そういったストレッチを繰り返して委譲を進めていくのである。

仕事ではこんな単純な話ではないことも多いけれど、詰まりそうなポイントを想定しておくことが大事。最初に一緒にロールプレイングしたり、あるタイミングで状況をチェックする予定を入れたり、相談や共有の時間を定期的に取る時間をとったり、そういった伴走の設計が委譲する側には求められる。ちなみにこの設計はキャッチアップが遅いと自認している人の方がうまくできるのではないかと思っている。詰まりポイントを実体験を伴って想定できるからである。


苦手分野に関して頭の中を整理するためにガッと書いてきたが、山本五十六の名言が全てを表している。

やってみせ、言って聞かせて、させてみせ、ほめてやらねば、人は動かじ。 話し合い、耳を傾け、承認し、任せてやらねば、人は育たず。 やっている、姿を感謝で見守って、信頼せねば、人は実らず。

ちなみに次は息子氏に靴下を履いてもらえないかと画策中で、彼はようやく靴下には穴が開いているということに気づき始めたところである。

相談されなくなる理由

誰かからの相談がなかった時、遅かった時、どうして相談してくれなかったのか、なぜ勝手に物事を進めるのかと憤りを感じることがあると思う。

自分の経験から言うと、相談されない時は相談を受ける側に理由がある。いや実際には違うかもしれないが、そう考えておいた方が楽。相手の行動を変えるより自分の行動を変える方が簡単だしコントロール可能だからだ。100%自分に理由があると仮定して物事を考える方が建設的である。

相談されなくなる理由は大きく分けて2つしかない。「相談する必要がないと考えている」か、「相談したくないと考えている」かのどちらかだ。

「相談する必要がないと考えている」

この場合、どういう時に相談をしてほしいか相手とすり合わせる必要がある。デリゲーションボードなどで権限委譲を見直したりしてもいいかもしれない。

目的とインパクトの大きさの認識があっていないこともある。まあこれも話すなり明文化するなりしておけば解決できる。

一方、話してすり合わせるのが難しいものとして、仕事を進める上でのスタンスの違いがある。たとえば「許可より謝罪」はわかりやすい。やってみてあとで修正していくという仕事の進め方が身に染みていない人にとっては、「勝手に物事を進められてやりづらい」という気持ちになるかもしれない。これは、組織文化レベルでどちらのスタンスでいくのを正とするか指針を決めておく方がよい。

「相談したくないと考えている」

一言相談した方がいいけれど、相談したくないなあと思われているというケースである。

相談したくない理由は多岐に渡る。相談される側はなかなか気づけないことが多いが、相談した結果「めんどくさかった」「何も進まなかった」「嫌な気持ちになった」など、これまでに何かあったことが多い。

この時、相談を受ける側の振り返りとして重要なのは「なぜ相談してくれなかったのか。もしかして相談しにくいと感じられているのではないか」と自省してみることである。全部自分に理由があると考えてみるのだ。実は常にしかめっ面をしていて怖がられているのかもしれない。いつも忙しそうにしていて相談する機会を見失っていたのかもしれない。あるいは、以前に相談された時に追い詰めるようなコミュニケーションをとってしまったかもしれない。

相談をしたいとまではいかなくとも、少なくとも相談したくないと思われないように自分のマインドや行動を変える必要がある。その上で、相談しやすくなるようなタイミングや空気を作る。そういった設計が相談を受ける側のスキルとして必要なのである。


色々書いてきたけれど、要はいつもニコニコして余裕を持っておくのが一番だいじ。慾はなく決して怒らずいつも静かに笑っている、そういうものにわたしはなりたい。

CIと食洗機

ソフトウェア開発の経験がない嫁氏と、たまに開発の話をする。いつだったか、たしか個人開発している時だったと思うが、CIとCDを先に整えておくのはとても重要という話をした。

仕事が終わってからもMacbookをいじっている自分に「今何してるの?」と聞かれたのがきっかけだった気がする。「開発に入る前の下準備だよ」「下準備って?」「やっておいた方がそのあとの効率がよくなることってのがいくつかあって、それをやってる」「たとえば?」「CI/CDの設定とか」みたいな感じ。そこからCIの説明に入った。ざっくりまとめると以下のような会話だ。


CIというのは、食洗機のようなものだ。我々も食洗機を使い出す前は「食洗機なくてもいいよね」という話をしていたと思う。しかし今はどうだ?食洗機がない生活は考えられない。食洗機をもっと早く買っておくべきだったという共通認識がある。

使い出す前はどうだったか。「何でも洗えるわけじゃないし、結局手で洗った方が早いのでは」みたいな話をしていた。それはその通りである。食洗機は必須ではないし、何でも洗えるわけでもない。しかし、一部やってくれるだけでも日々の業務がだいぶ楽になるし、何より食事で食器を使うことにためらいがなくなるので思い切った料理を作ったり一汁三菜をちゃんと意識したりと選択肢がぐんと広がる。

CIも同じだ。CIは、コードのテストを定期的に行ってくれたり、フォーマットを直してくれたりする。これは手元のMacbookでもできるし、あとで必要になった時に作ることもできる。ただ、あとで入れるより先に入れた方が絶対によい。コストをかけてでも最初にやっておくことで、開発で考えることが減る。結果スピードも上がる。これは自分が経験したどのプロジェクトでも同じだった。

これは個人開発だけれど、仕事でも同じだ。むしろ仕事の方が重要である。食洗機を経験した人が、食洗機のない家に引っ越そうと思うだろうか。思わないだろう。これが普通に行われているということは、エンジニア組織における採用優位性という観点でもとても重要なことなのだ。

そういう意味では、洗濯機も同じである。洗濯機は食洗機よりひとつ上の認知を取れている。洗濯物を手で洗う家庭はほとんどない。常識として根付いている。CIの初期導入も、結構常識として根付いてきている感はある。先人たちの頑張りによって当たり前の水準が上がった結果、洗濯機と食洗機の間あたりまで来た気がする。

ところで、Nature Remoを買いませんか。これも次の"食洗機"になりうると思いますよ。


現場からは以上です。

言いたいことを言える場の設計

言いたいことを言える場を強制的に作っておくことってめちゃくちゃ大事だと感じているのでその話をガッと書く。同じような話はいろんな書籍やブログで書かれているので、体系的なことを知りたい人はそっち読んだ方がいい。

いい感じのチームでは、言いたいことを言える状態をうまく作っているなあと感じることが多い。

例えばプロジェクト中に1週間2週間ごとに振り返りの場を設定していたり、毎日の朝会の中で相談コーナーを設けていたり、ウチでもやってるよというところは多いと思う。1on1もその機能の一端を担っている。一方で、場を設定したからといって言いたいことを言えるかというとそうでもない。場の設計が必要なのである。

例えば、「そもそもこのプロジェクトってやる意味あるのかよくわかってないんですよね」みたいな話をプロジェクトごとの振り返りでポンと言えるかと言うと、なかなか言いにくい。

こういう今さら感のある話や言いにくい話を言えるかどうかは、その場の目的次第である。例えば、「今さら言いにくいことだけ言う会」というのを定期的に6人くらいずつ開催したら言いやすいかもしれない。

これは組織文化にもよるかもしれないが、言いたいことを言える場というのは定期的に作っておき半ば強制的に抽出できる形にしておいた方がいいと思う。組織が大きくなればなるほど課題の抽出とNext Actionの決定に時間がかかるのでやらなくなったりもするが、少なくとも3ヶ月に1度くらいは「日々仕事をしている中では言いにくいですけど、実はこう考えてるんですよね」とか「あれ微妙じゃないですか」みたいな話を好き勝手言う場を作っておいた方がいい。ファシリテーションは大変だろうけど。

ただこういうやり方は理想的ではないとも考えている。定期的な場を設定すると、その時まで言わずに問題の解決が遅れることもあるからである。言いたいことをいつでも言えるのが一番よくて、会社によってはSlackで分報チャネルや好き勝手言うチャネルみたいなのを運用してより素早いフィードバックループを実現しようとしているところもありそう。

これを実現するには、文化の浸透と個人のスキルが必要で相当難しい。そういうことを言っていいんですよ、歓迎しますよ、という文化がないとそもそも意見が出てこないし、意見があったとしてもある程度自分の感情的な部分を認識して言語化するスキルがないと発信をためらってしまう。文化が先だと思うけれど、小さな規模ならできそう。大きな規模だと相当トップダウンで言い続けなければ実現できない。

個人的には言いたいことをそのまま言う人はとても好きである。ムカついた時はムカついたと言ってほしいし、嬉しい時は嬉しいと言ってほしい。余談だが、妻はそういうタイプの人で助かっている。ただそんな妻でも中長期のストレスはどうしても伝えるタイミングがないという話があり、土日に一緒に散歩しながら話すという形で解決しようとしている。そういうことである。

自分の定型Tweetまとめ

最近雑なこと書いてないなあと感じているのでリハビリする。

自分の中で決まっている定型Tweetというのがある。たまにアレ何なんですか?と聞かれるのでざっとまとめておく。

俺が3人分になる

業務上3人分にならないとなあ〜と感じた時に書いてる。累計120人くらいになっていた。

クッソ二郎食いてえ

二郎が食いたくなった時に書いてる。月一ペースくらい。

最近はこんな感じ

息子氏爆誕以降、自分の生活リズムのログとして書いてる。

ハチャメチャが押し寄せてくる

主に業務でハチャメチャが押し寄せてきたなあ〜と感じた時に書いてる。

業務RT失礼します

業務でたくさんRTをしていく前に書いてる。

はい + 自分の記事

何か思うことあって書こうとしたらすでに自分が昔同じような話を書いていたことに気づいた時に書いてる。

ヤッタネ!!

業務で何かをヤッタ時に書いてる。その時のテンションで!の数が変わる。

THIS IS WFH

主に二郎を家で作ってWork from homeを噛み締める時に書いてる。

窓から差し込む 希望の光が

ジョーカーゲームの主題歌が頭に浮かんだ時に書いてる。

これがホットカーペットの力

ホットカーペットの力を感じた時に書いてる。

ああ、調査するのはいいが――別に、アレを直してしまっても構わんのだろう?

特にめんどくさそうな不具合調査を始める時に書いてる。

まあまあ"月がきれい"でも観て落ち着けよ

インターネッツが怒りに満ちている時に、みんな月がきれいを観れば落ち着くんじゃないかと感じた場合に書いてる。

身体が軽い…こんな幸せな気持ちで闘うなんて初めて

何かが楽になって身体が軽くなった時に書いてる。

組織の"わからない"に対する不快感

組織の中で何らかの歪みを感じる時、その根っこにはある人が関係する物事について「わからない」「知らない」という感覚があることが多い。

例えば「なんでこんな非論理的な意思決定するのか。アホじゃないのか」と感じた時、本当にアホなこともあるかもしれないが、判断材料となる情報が正しく伝わっていなくてそう感じるだけということも多い。1対1で色々聞いていくと「なるほど、たしかにそれならそうなりますね」と納得できるのに、情報が欠落しているだけで不和を生むのだ。

情報だけではなく、人格も同じである。仲のいい人から言われる冗談は笑ってやりとりできても、よく知らない人から同じことを言われると嫌な気持ちになることもある。

組織において、こういった「わからない」が積み重なると雰囲気が悪くなっていく。「あのチームは」「あの人は」といった形でわからないものを自分とは違うものとして表現して、一体感がなくなるのだ。なんだか少し喧嘩みたいなコミュニケーションになりがちだと感じた時は、自分と相手の知識や認識に差があることが多い。わからないこと=コントロールできないことが増えると、自分から主体的に動くアクションも減っていく。この話は、エンジニアリング組織論への招待で「情報の非対称性」という言葉で表現されている。

この「わからない」ということに対する不快感って、会社組織に限らず人間誰しも持ち合わせているよなあと思う。例えば仲良しグループ3人組で、2人が知っていて1人が知らなかったみたいな話とか。コロナ状況下での政府の方針に対する反応とか。疎外感なのか、自分がコントロールできない物事に対する恐怖心なのか、多かれ少なかれ嫌な気持ちになって心がもやっとするものだ。

この組織の「わからない」に対する不快感は、誰しも持ち合わせている。その前提で、「わからない」を減らすアプローチをとっていかなければならない。

情報の透明性という点だと、レポートラインの整理、ドキュメント文化、そのための教育など。1on1とかで「今組織においてよくわからないことはあるか」みたいな話をしてもいいかもしれない。チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019 は何度読んでもよい資料である。

人格という点だと、入社時のオンボーディング設計、チームビルディング、雑談の設計など。こういうの得意な人羨ましい。

逆に自分が何らかの不快感を感じた時は、そのまま感情をテキストにしたり顔にだしたりする前に「何かがわからなくて不快に感じているのではないか」「自分が把握/コントロールできるようにするにはどうしたらいいか」と考えた方がいちいちイライラしなくて済むのでオススメ。

小さな不快感がつのると大きな歪みになるので、こういう取り組みを意識的にやっていかないといけないなーと『ひぐらしのなく頃に 業』を見ながら思った。