Konifar's ZATSU

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

定例ミーティングに議題を持ち込む

定例ミーティングの種類にもよるが、ドキュメントが用意されていて議題を参加メンバーが持ち込む形式のものがある。ざっくり雑談、共有、相談があれば持ち寄って話すやつ。協議、決議みたいな分類もあるかもしれない。

ミーティングのオーナー以外の参加者は自分から議題を持ち込むほうがいいと思っていて、そういうことを雑に書いておきたい。


結構ありがちなのが、毎回ミーティングのオーナーが色々議題を上げてオーナーの "一人劇場" みたいになってしまうという状況である。これ自体は必ずしも悪いわけではない。程度の差はあれそうなることのほうが多いと思うし、誰が議題を上げようが結局何かが前に進めばよい。

一方で、自分は「参加者なら自分から毎回何かしらの議題を持ち込むほうがいい」と思っている。実際に毎回持ち込むかどうかは置いといて、定例ミーティングの場に持ち込む意識が先にあると、次の定例までの意識や取り組み方が大きく変わる感覚がある。何かが起きた時や自分が困った時に、「これはちょっと議題として持ち込んで話しておこうかな」とか「共有事項としてドキュメントにメモしておこう」とか、視野や考え方が変わっていく。

そもそも、定例ミーティングが必要な組織の中で動いているチームや個人が、間の期間に共有も相談もないなんてことは本来ありえないはずなんだよな。仮に本当にないのであれば、定例の有無や頻度を見直したほうがいい。それこそ「議題を上げにくい」、「定例の進め方、頻度を見直したい」みたいな議題を上げないといけない。

こんなことを書きつつも、自分が全ての定例ミーティングでできているかというと正直できていない。なんだろうな。「こんな内容上げちゃっていいのかな」と考えて止まってしまうことがある気がする。「トンチンカンなこと言いたくないな」とか「こんな生煮えのお気持ち表明みたいなレベルの話を上げていいんだろうか」とか、「なんか長くなってしまって収集つかなくなって変な空気にしてしまうんじゃないか」とか、何かしら不安になって止まってしまうのだと思う。

これはミーティングやオーナーのことを気遣っているようで、実は自分が不安で躊躇してるだけ。言い訳で止まらず、そういう時は直接オーナーに聞いてみたほうがいい。たいていのオーナーは議題を上げてほしいと言うと思うし、上げてくれる人に感謝してると思う。定例ミーティングってのは参加者皆で作っていくもので、そのためのコンテンツも皆で持ち寄るほうがいい。自分から定例に議題を持ち込む前提でいると、そういう意識も自然と持ちやすくなると思う。

最後にひとつだけ気をつけるべきなのは、「何か起きた時に定例まで待つ」を常態化しないこと。議題を持ち込むことに慣れてくると、何でも定例ミーティングのドキュメントに書いておこうとしがちだが、すぐにシュッと話したほうがいいこともある。特にリモート中心の働き方で起こりやすい。定例ミーティング頼りになりすぎないように注意が必要。

筋が悪そうに見える方針に口を出す

誰かが進めている仕事を端から見て、「そんなに複雑じゃなくてもっとシンプルにできるんじゃないか」、「こうしたほうがいいんじゃないか」「そもそもやる必要ないんじゃないか」みたいに感じたとする。

こういう時、「口を出さないでおこう」となってしまうこともあると思う。そりゃそうだよね。口出しにくいよ。横から何やかんや言ったらやる気を削いでしまいそうな気もするし、ちゃぶ台返したいわけではないけど「いま言われても」みたいな雰囲気になりそうだし、もしかしたら自分が見えていない事情があるかもしれないし、その情報を取りにいく時間を自分がかけるべきかもよくわからんし、自分の感覚が正しいかも正直自信はないし、仮に本当に筋が悪かったとして明確な対案を持ってないこともあるし、口を出しても最後まで責任持てるかわからないしな。そりゃ「まあいっか、静観」となりがちだよね。

めちゃくちゃ気持ちはわかる。わかるんだけど、自分はそういう時にはちゃんと口を出していくべきだと思ってるし、そういう人のほうが好き。皆が「それくらい考えとるやろ」とお見合いしてしまうほうがよくない。なので、組織・個人両方の観点で口を出しやすい状態を作ることに頭を使うべきだと思っていて、そういう話を雑にまとめてみる。


組織の工夫

1. 推奨する振る舞いとして明文化する

  • メンバーが迷った時に、「口を出したほうが偉い」みたいな感じで判断に使えるようチームのスタンスを明文化して伝え、文化にしていく
  • 表現は極端なほうがいい。極端にしないと判断に使えない
  • 口を出す側だけではなく、受け取る側のスタンスも重要。まずは感謝を伝えるとか、相手や言い方ではなく意見そのものに集中するとか
  • 余談だが「口を出す」という表現自体も正直あんまりよくはないと思うので、明文化するならもう少しよい表現にしたいが思いつかない

2. 役割を決めてお願いする

  • 口を出す役割を明確に決めてお願いする
  • 「この人はこういう時にちゃんと言う係で、役割として全うしてくれている」という共通認識を持てるとチョットやりやすくなる。本人も「これは◯◯の役割として確認したいんですが」のように宣言して話すといいかもしれない
  • 明確に権限をつけた上で、本人には「権利じゃなくて義務。口を出さないといけない」といった感じで極端に伝える。極端に伝えないと機能しない。もしバランスが悪くなった場合は補正する。それがマネジメント。 "警察" になりすぎないように、名前は「おかん」とか「◯◯委員」、「◯◯係」とかにするといいかもしれない

3. 口を出せる場を作る

  • タイミングが遅くなればなるほど口を出しにくいので、早めのタイミングで言えるようなプロセスを作る
  • 同時に、遅めのタイミングでも言えるように「ちゃぶ台確認会」、「そもそも会」のような場を用意する
  • ミーティングでうまく伝えられない人を 1on1 でフォローして伝えてもらうなど

4. 個人をフォロー・フィードバックをする

  • 口酸っぱく口を出していってほしいことを伝え、口を出してくれた人にはそのこと自体を称賛する
  • 事後のフォローはマネジメントの責務でもあるので、伝えてギクシャクすることを恐れないでほしいといった話もしておく
  • 伝え方、受け取り方を改善すべき箇所があれば直接フィードバックする
  • 事前に「そういうタイミングがあったらフィードバックさせてほしい」と伝えて認識をあわせておくとよい

個人の工夫

1. 枕言葉を増やす

  • 伝え方だけの話だが、「今さらすみません」、「頓珍漢かもしれませんが」、「ちょっとわからないので教えてください」のような枕詞をいくつか用意しておく
  • 伝えたい度合いや、対案の有無なども最初に伝えるとよい
  • レビューでの指摘なら、 FYImustwantimonits のように接頭辞ルールを決めておくといいかもしれない

2. 寄り添う意思を伝える

  • 対立構造になりがちなので、向いている方向が一緒であることを明確に伝える
  • 「もしかしたらもっとよくできるかも?と思っての just idea なんですが」とか
  • 無意識のうちに自分の知識や考え方を伝えることを目的となって見栄や意地を張らないように注意

3. 直接話す

  • テキストコミュニケーションですべてをやろうとしない。オンラインまたは対面で直接話す選択肢を常に持っておく
  • テキストだけで情報と考え方を擦り合わせる負荷は高く、時間がかかったり感情が揺さぶられてしまったりする。ニンゲンが対面コミュニケーションから卒業するのはまだ早い

4. 先にスタンスを宣言しておく

  • 最初に「こういケースでは伝えていきます」のように自分のスタンスを宣言しておくと楽になる
  • チームのアグリーメントとして揃えておくことも必要だが、まずは自分でスタンスを宣言しておくのは個人でもできる。自分の取扱説明書みたいなのを書いてその中のひとつとして書くとかもいいかもしれない

5. 普段から話しておく

  • 関係性がないのに口を出すのはハードルが高すぎる
  • なんだかんだ普段から話しておくのはとても重要。特にオフラインで話しておくこと
  • 雑談しておくということなんだけれど、フリー雑談は結構難しいので事前に相手に話しておきたいこと、聞いてみたいことを時間をとって準備しておくといいかもしれない ref: 個人コミュニケーションKPI - Konifar's ZATSU

雑に書いてみて思ったが、自分は組織の工夫があまりできていない。個人でなんとかすればええやろくらいに思っていたフシがあるけれど、こう見てみると両方必要だよね。個人でコントロールできることには限界があるし、やはりそれだけだとしんどい。

そもそも筋がいい悪いみたいな感覚ってなんだろうな。真面目で実直な人ほど、筋が悪い方向にがんばってしまったりする。「こんなにめんどくさいのはそもそもおかしいんじゃないか」みたいな嫌な匂いからくるやつで、間違いなくあるとは思う。

視野や思考を広げて考えるということだと思うが、こういうのはその人の知識と経験で磨かれるものなんだろうか。いろんな意見をもらっていくうちに、考える順番や抑える勘所みたいなのが培われていくんだろうね。そういう意味でも、やはり口を出すべきだし、出される環境のほうが結果的に全員のレベルが上がりやすいと思う。

思想の話になってしまうが、当事者は口を出されてもちゃんと向き合って回答できたり動きを補正できたりするってのが真っ当だと思うしね。口を出すほうも出されるほうも、お互いのリスペクトを忘れずに。そして、次の曲が始まるのです。

役割 → アサインの順に考える

組織体制を考える上で、役割を決めて責務を明確にするやり方をとることがよくある。役職ではなく役割。

そういう時、どうしても今のメンバーのケイパビリティなど "アサイン" を制約条件として考えがち。考える順番を強く意識したほうがいいという話を雑に書いてみる。


考える順番は役割が先、アサインが後。

「やりきれるかはわからないけど未来のことを考えるといまこういう役割を置いて遂行するべき」みたいな考え方にすべきで、最初にアサインから考えてはいけない。

実際には "実現性" の観点でアサインしてやりきれるかを意識して決めなければいけないのでは?と感じると思う。それはそう。けどそんなん嫌でも考えるやろ。いま目の前で見えてる現実の制約なんだからさ。だからこそ、かなり意識して "あるべき役割" を先にイメージしたほうがいい。

そうすると、めちゃくちゃ不安になると思う。アサインして役割をお願いした相手がうまく全うしてもらえるかなとか、負担に感じすぎちゃわないかなとか。よくメンバーを見ている人ほど本当にいいのかなと考えちゃうと思う。

これは正しい悩みで、そういう決めにくいことを決めて物事を無理やり前に進める必要があるからマネジメントの "役割" を置いてるんだよな。悩みで止まって何とかする設計を考えることを放棄してはいけない。たとえば役割と狙いの明文化、お願いする役割によっては昇級昇格の方針整理、フォローアップのための会議体の設計、率直なフィードバックと補正のための自分自身のスキル向上とか。自分がコントロールして何とかするやり方は実は色々ある。大変でやりたくないなと思っちゃうけどね。

もともと自分もこんな考えだったわけではない。過去に同僚氏が「その役割を今お願いするのは無理あるやろ」みたいなアサインをして、決めたら意地でもうまくいかせるみたいな動きをよくしてたんだよね。自分から見ると、アサインされたメンバーもなんだかイキイキしているように見えた。たしかに、何かをお願いされるって緊張もあるけど頼られてるみたいで嬉しさもあるかもしれない。

それを見ていて、自分が現実的な組織のケイパビリティをかなり意識した "アサイン" から発想していたことに気づいた。全然物事をいい方向に進められていないような不甲斐なさを感じて、ちょっと考え方を変えたほうがいいんだろうなと思い始めたのがきっかけである。

正直いまだに全然慣れていなくて、役割とかアサインとか考えるのは今でもちょっと傲慢なような気持ちになることもある。けれど、一定以上の組織で事業、プロダクト、組織の無数の課題を皆でワケワケして倒していくことを考えると、ある程度は役割を決めてお願いしていく形がよいと腹落ちしてもいる。まあこれもひとつの "役割" だよね。役割が先にあって、自分自身の能力が追いついていないアサインだからこういう悩みを感じるんだろうね。悪くない。

自分が一番考えてるという自信を持つ

自分がオーナーシップを持って物事を進める時には、少なくとも組織内ではその領域のことを一番考えているという自信を持つほうがいいと思っていて、そのあたりの話を雑に書いておきたい。

なんでかというと、結局一番考えてないと説明責任を果たせないからなんだよな。たとえば「なんでこういう方針にしたんですか?」、「このあたりは考慮できていますか?」みたいにまわりから聞かれた時に、「それはもう過去に私の脳が通ってきた道だ」みたいな感じで二周目状態になっていないと説明できない。

自分は昔「説明責任とかしゃらくせえ、"遂行" できればええやろ」と考えていたことがある。それはそうで、小さいタスクだとそれで全然OK。けどねぇ、なんかうまくいかなくなるんだよな。説明しながら "刻む" 進め方を身につけないと、物事を前に進められなくなってくるのよ。もしかしたら "圧倒的" なレベルの人はそんなことはないのかもしれないけれど、少なくとも自分は成果が頭打ちになった。

「一番詳しい」じゃなくて「一番考えてる」という自信でいい。結果的に一番詳しくなってしまうことも多いが、結果ではなく自己満足な "やってきた" というプロセスに対する自信でいい。何を言われても「いや、俺が一番このことを考えてるわ」と思える状態になることが重要。これは回数と時間を積み上げていけばちょっとずつできてくる。むずかしいこともあるけどね。

そもそもそんな情熱持つの無理だわという人もいると思う。わかる。こういうスタンスは人によって向き不向きあるのかもしれない。自分は何かを説明する時にうまくできずに玉砕することが多くて、そういう状況になるのがほんと嫌なんだよね。今は慣れてはいるけど嫌なものは嫌。で、比較的うまくいった時は自分が一番考えてるという自信を持てていたと気づいて、それからそういう状態を目指すように動き方を変えてきたみたいな感じ。出発点は「恥かきたくない」みたいなわりとネガティブよりなモチベーションかもしれない。

最後に余談なんだけれど、この「自分が一番考えてる」という自信は、自分がオーナーシップを持っている時にのみ発揮するべきだと思っている。他人がオーナーシップを持っている時に、「俺のほうが考えてる」みたいな態度で接してはいけない。その振る舞いは相手のモチベーションを根っこから削ぎ、オーナーシップを殺してしまう。実態は自分の方が長くやっている分野で詳しいこともあるし、意見を言ってはいけないということではない。相手に接する時のスタンスの話である。

自分がオーナーシップを持って説明する時は他人より10倍考えてきた自信を持ち、他人がオーナーシップを持って説明してる時は自分より10倍考えてるはずという敬意を持って接しよう。そういう態度は必ず相手に伝わる。そんだけ。

調査と改善、考える順番

開発の不具合調査やちょっとした改善を進める時、考えるべき"順番"がある。

タスクの粒度の差はあれど、自分はいまだに順番を間違えては無駄な遠回りをしているので雑にまとめておく。

1. 事実を確認する

  • 誰かからの報告や予想を鵜呑みにしてはいけない
  • 本当に起きている事実を自分で確認しにいくこと

2. 問題を理解する

  • 結局何が問題なのかを理解せずに対応してはいけない
  • なんとなくわかった気になることなく、何が問題かを理解すること

3. 真因を特定する

  • なぜその問題が発生しているのかを特定せずに局所的に解決しようとしてはいけない
  • 仮説を立ててもいいが、全体像を理解し広げて考えた上で、削ぎ落として真因を特定していくこと

4. 解決策を選択する

  • 真因に対してたったひとつだけの思いつき解決策に飛びついてはいけない
  • 最終的に一つに決める前に、決定軸を整理して評価し選択すること

例を一個上げると、たとえばあるジョブがコケやすいみたいな報告が上がったとする。

「1. 事実を確認する」では、本当にコケてるのかを確認する。めちゃくちゃしょうもない話だが、もしかしたらログの出力ミスだけでコケていないみたいなこともありうる。自分でやりとりやデータを見て確認する。

「2. 問題を理解する」では、コケることによる問題を理解する。コケるなんて問題に決まっとるやろみたいに思いがちだが、実は仕様上想定されるもので、想定外の異常終了は問題だが、異常終了自体というよりも異常終了した場合のハンドリングの問題かもしれない。

「3. 真因を特定する」では、なぜその問題が発生しているのかを確認する。ここが一番疎かになりがち。ログやデータを確認して可能性を削ぎ落としてピンポイントな真因を特定しにいく。たとえばメモリ枯渇で落ちていることがわかったとして、なぜメモリ枯渇しているのかをさらに深ぼることなく対応を考えてはいけない。

「4. 解決策を選択する」では、真因に対して何をすればいいかを決める。特定のコードの修正になるかもしれないが、影響範囲の大きさや根本解決を考えた時にはいくつかの選択肢が出てくる。どんなことでも3つくらいは出てくると思うので、広げて考えてからひとつを選ぶようにする。


書くと当たり前の話でしかない。ちゃんと内容確認して、特定してからピンポイントに対応しようねという話である。

けどねぇ、思った以上にこの順番をすっ飛ばしちゃうんだよね。

1 をすっ飛ばして、実は報告内容がぜんぜん違ったとか。2をすっ飛ばして結局何の問題もない話だったとか。3をすっ飛ばして当てずっぽうに調査してめちゃくちゃ時間かかったとか。4をすっ飛ばしてレビューでそもそもの指摘を食らったりとか。それぞれできてると思っても深さが全然足りてなくて実態としてはまるでできていないこともある。

順番どおりに一個一個やらないと結局遠回りになるし、説明責任を全うできない。自分はできてると思ってる時ほどしっかりやろう。

リーダーが "弱みを見せる" とはどういうことか

最近「リーダーが意図的に "弱みを見せる" ことも必要」という記事を何度か読んだ。例) リーダーが弱点を見せるべき理由

自分はこれに対して少し懐疑的というか、本来の狙いと違った解釈になりやすい表現だなあと感じていて、雑に考えを吐き出しておきたい。


この話は、「リーダーが自ら完璧ではない姿を見せることで誠実さが伝わって信頼が増し、チームの発言のハードルも下がって協働が加速する」といった趣旨の内容だと理解している。

これ自体はそうかもなあと思うものの、「だからリーダーは弱みを見せるとよい」と言われると、それは違うやろと思ってしまう。

たとえば「自分はリーダーの役割としてやっているけど全然すごくはない」みたいな話をまわりに伝えるのは、悪いとは言わないけれどチームにそんなにプラスの効果をもたらさないと思う。これは弱いリーダーシップ像を晒しているだけで、リーダー自身の気持ちの整理くらいにしかならないんじゃないかな。

あるいは、「失敗した話を自ら話す」というのはどうか。伝え方によっては、チームメンバーからの相談のハードルが下がったり、新しいことや難しいことにチャレンジしやすくなったりするかもしれない。けれど、あえて「失敗した話を開示していくぞ」みたいなスタンスで行動するのは違う気がする。

自分の考えでは、 "弱みを見せる" というのはそんなに特別なものじゃない。「背伸びしすぎない」、「知ったかぶりしない」、「謙虚でいる」、「裏表なく接する」、「間違ったら謝る」、こういった振る舞いの中で "必ずしも完璧ではない姿" が自然と滲み出て伝わるものだと思う。

その積み重ねによって、リーダー自身が過渡期で学び続けていることや、チームメンバーの意見を尊重し歓迎していることが少しずつ伝わりチームの当たり前になっていくことに価値がある。

一方で、"弱みを見せる" という考え方は、リーダーが "完璧なフリをしない" ように意識づける補助線としては有効かもしれない。リーダーは責任感からか完璧に振る舞おうとしすぎる傾向があるからである。

ただ、リーダーとしての役割を全うするというのが大前提で、これが疎かに見える状態で "できていない自分" を開示しても意味がない。とにかくできない自分をありのままに開示して「あの人は本当にダメだから自分がやってあげないと」と思わせるような稀有な才能を持ったリーダーもいるとは思うが、これは本当に稀。真似してできるものではない。

変に "弱みを見せる" という意識を持たないほうがいいのだと思う。意識してそんなことをせずとも、リーダーとして物事を前に進める意思決定をする際に、その経緯を論理的に整理しつつ葛藤した部分も含めて丁寧に開示し説明していくだけでいい。

結果としてそれが各記事の中で語られている "弱みを見せる" と同じようなよい効果をチームにもたらすんじゃないかと思う。

『DroidKaigi.collect { #26@Kanazawa } 共催 GDGoC KIT』に行ってきた

DroidKaigiが日本各地で行っているイベントに誘ってもらって、金沢工業大学でチーム開発の話をしてきた。

新鮮で刺激も多く楽しかったので雑に感想を残しておく。

広くてきれい

  • 金沢工業大学 扇が丘キャンパス 26号館 チャレンジラボ 1F というところで開催された
  • どんだけ建物あるんや…?と思ったのと、建物がきれいでびっくりした。聞いてみると、この建物が一番新しくてきれいらしい
  • 3DプリンタやArduinoとかがたくさん置いてあって充実してそうだった

参加者多かった

  • 学生がメイン参加者でチーム開発がテーマだとまあ10人くらいかなと思っていたら30人くらい来ていてマジかと思った
  • 土曜に参加する学生の方々がすごいのはもちろんだが、主催のDroidKaigi, GDGoC KITの皆さんがうまくお声がけしてくれたのだと思う。ありがとうございます

チーム開発で最初にやっておくとよさそうなことを話した

  • 学生が多い場でチーム開発についてどこまで広く深く話せばいいかわからなかったので、わりと全般的なふわっとした内容にした
  • もう少し深く具体的な話を盛り込んでもよかったかもしれない

ひつじさんと久しぶりにゆっくり話せた

  • DroidKaigiオーガナイザーのひつじさんとパネルディスカッションで話した
  • それ自体もよかったのだが、開催までの間にも「最近3Dプリンタ買ったんですよ」、「ムードメーカーって評価できるんですかね」みたいなとりとめもない話をゆったりできてよかった
  • ちなみにひつじさんは21時から技術書典の生配信があるということで17時半くらいに東京に戻っていった。"本物"の3人分になるというのはああいうことなのだろう

学生と話している感覚はなかった

  • 参加者は1年生から4年生、卒業して就職している方までいたが、正直学生と話している感覚はあまりなかった
  • 20歳前後ってこんなにちゃんと相手の話を聞いて対話できるものだったっけ?自分にとってはもう15年くらい前のことなのであまり覚えてないけど、普段仕事やコミュニティで話している感覚と全然変わらずに話していた
  • 最近の就活の話も聞いたが、かなり早期化しているらしい。2年生は当然のように皆インターンをしているとのこと。すごい
  • 「ロボコンのコントローラーの実装をKotlinにしたんだけど、次に入ってくる1年生のKotlinに関するオンボーディングをどうするとよいか」、「有志で何度かゲーム開発をしているが完成させられずに断念してしまうが、どうマネージしていけばよいか」、「チームの中で温度感が揃わない時、どのようにモチベーションを高めていけるか」みたいな話をしていて、普通に勉強になった。すごすぎる

日帰りなのが残念だった

  • 家事の都合で日帰りになったのが残念だった
  • 打ち上げのお店の料理は美味しく、運営やLT登壇者の方々の話ももう少し聞きたかった
  • コミュニティを立ち上げて熱量高く運営している源泉とかもっと聞いてみたい
  • 4年生の方々は4月には東京で働くとのことなので、またどこかでお会いできるのが楽しみである


誘っていただいたDroidKaigiの皆さん、GDGoC KITの皆さん、参加者の皆さん、ありがとうございました!