Konifar's ZATSU

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

本人と直接話す方がよい

何かを伝えたり聞いたりする時には本人と直接話す方がよい。当たり前っちゃ当たり前なのだが、意外とうまくできていないことも多いので最近特に強く意識するようにしている。

「どうなってるか分からなくてモヤモヤする」とか「あの発言や行動ってどういう意図なんだろう」とか、内に籠もって想像だけしているとロクなことがない。直接本人と話してみると実は何の問題もなかったなんてこともある。

ただ、直接話すのは簡単なようで難しい。話す側は感情のコントロールと言語化のスキルが要求される。聞く側のスタンスも重要で、これは話す側はコントロールできない領域なのでより難易度が上がる。話す側聞く側どちらかに負荷が偏ると相手のコミュニケーション能力のせいにして余計にめんどくさいことになってしまう。組織においては、直接話して物事を解決すること自体を推奨するといった工夫が必要かもしれない。また、ある程度はスキルトレーニングもあった方がよい。

直接話せばよいことに人を介すとノイズが増えて正確じゃなくなる。時には仲介が必要なこともあるが、基本的には当事者同士で話す方がよい。

自分が何かしら相談を受けた時、「ちょっと伝えてみますね」「それとなく聞いてみます」といった感じで第三者としてボールを持ってしまうことがあった。これは今はやらないようにしていて、基本的には「できれば直接話すのがいいと思う」「直接話しにくい理由があれば解消のためにサポートはする」といった形で接して本人同士で進めてもらうように意識をしている。

まあ本人と直接話せるような関係を作っておくのが一番難しいという話ではあるのだけれど、そういう関係を作るには直接話す方がよいというニワトリタマゴのような話である。

タスクが終わったらleaveするSlackチャネル

社内アンケートや読んでおいてほしいマニュアルなどがある時、『タスクが終わったらleaveするSlackチャネル』を作って必要な人を全員入れておくと楽。同じようなことをやってる会社も多いんじゃないかと思う。

自分が所属している会社のSlackチャネル命名規則では、こういった一時的な用途で使うチャネルには tmp- prefixをつけるようにしている。

どのくらいの人が終わったかをチャネル内の人数で把握できるし、リマインドも @here メンションでできる。チャネルを切り出しているので、Zapierなどでリマインドを自動化するのも楽。

やる側としても tmp チャネルにずっと入っているのは嫌なので早めにやるモチベーションになる。

やったことがないと「うざったいんじゃないの?」と思われるかもしれないが、関係なかったらすぐleaveすればよいし、関係あったら終わらせてleaveすればよいだけなので実際にはそんなに気にならない。

労務関連などちょっと手間がかかるけれど期日までに確実にやってもらわなければいけない作業には特によいと思う。いろんな人を巻き込まないといけない場合にも向いている。

自分のマネジメントのマインドセットの変化

マネジメントの仕事を始めて1年半くらい経った。日々ハチャメチャが押し寄せてきて泣いている場合じゃなく、落ち込んだりもしたけれどわたしは元気です。

主に気持ちの持ち方みたいなところでの変化を雑に3つくらい書いておくことにする。

自分がやる必要はない

全部やろうとせず委譲するのが大事とはわかっていても、それをやっていると「俺いる意味あるんか...?」と感じることがある。側から見るといわゆる自己組織化、適切な権限委譲が行われているということになるかもしれないが、当人は焦ってしまったりする。

自分が為すべきことを明確にして、それを達成できるのであればどんな形でもよしというマインドを持っておくとよい。メンバーを信頼して任せるというのはもちろん、自分にできないことをまわりを巻き込んで達成することも必要。極端な例だと、自分の言葉でチームメンバーのモチベーションを上げられないのであれば、別の適切な人を召喚するという方法もありうる。Fearless Changeを読もう。

自分がすべてやる必要はない。そのスタンスを自分から宣言しておくとなおよい。何事も自分が選択して動いているという感覚が大事なのかもしれない。

全ての責任が自分にあるわけではないが理由は自分にある

日々起こることすべてが自分の責任と感じてつらくなることがある。あれも想定しておくべきだった、これも手を打てていなかったみたいなことがめちゃくちゃ起こる。

自分ごととして捉えるのはいいんだけど、責任を感じすぎてつらくなってしまうのは自分にとってもメンバーにとってもよくない。つらそう、大変そうという雰囲気はまわりに伝播する。楽しそうにしていることが何より大事なのだ。

そのためのマインドセットとして、責任ではなく理由が自分にあると考えるようにしている。ただの言葉の違いではあるのだけれど、結果の理由として自分の行動があると思うと自分にとっては楽なのである。

期待のすり合わせが何より大事

チームで何かする時にうまく進まなかったりイライラしたりする原因のほとんどは期待のすり合わせができていないこと。期待がすりあっていない理由は「伝えていない」、「伝わっていない」のどちらかで、両方ともマネジメント側の行動で変えられる。

意外と期待を全く伝えていないことも多い。相手にどういう期待をしているか話してもいないのに、勝手にここまでやってくれるだろう、やるべきだと考えてその差分で感情的になってしまったりするわけだ。文字にすると自分が悪いことはすぐにわかるんだけれど、慣れるまではかなり意識しないとできなかった。今でもできていないことが多い。特にチームへの期待は明確に示せていないと思う。

チームの方向性を示したり、各人の役割や目標を話したりするのもすべて期待のすり合わせのため。その設計がマネジメントには求められる。


経験に学ぶ愚者か歴史に学ぶ賢者かでいうと自分は愚者なんだけど、これは学ぶの定義によるよねとも思う。日々やりきれていない部分をフォローしてくれる同僚氏、相談に乗ってくれる同僚氏には感謝している。

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

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

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

最初に声を出してもらう

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

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

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

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

具体例を出す

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

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

名指しで聞く

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

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

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

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

意見に対して反応を返す

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

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

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

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

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

「意見ありは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を買いませんか。これも次の"食洗機"になりうると思いますよ。


現場からは以上です。