Konifar's ZATSU

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

組織で目立つ人は何をしているか

自分のまわりですごいなと感じた人は、なんだか目立っていたことが多かった気がする。

そういう目立つ人は何が違うのか、何をしているから目立つのか よくわかっていないので、思い出しながら雑に考えてみる。


考えてみたけれど、2つくらいしかないかもしれない。

1. 問題を解決する

目の前の問題を解決するために、自分がすべきこととできることを常に考えてる感じがする。

ボールが浮いていたら手を上げる、会議で気になることがあったら発言する、直接関係していなくても必要だと思ったら越境する、といった動きは全部問題解決のため。物事を前に進めるために自分が何をするべきか、何ができるかをとにかく考えて行動してる。

特徴としては、失敗を気にしすぎないこと、領域を区切りすぎないこと の2つがあるかも。物怖じせず、誰の仕事かを過度に考えすぎず、問題解決に必要なことは全部やるというスタンスを持ってる。いわゆる "オーナーシップを持つ" 振る舞いと言えるかもしれない。

2. 説明責任を果たす

自分やチームが 今やっている途中経過 や 出した成果 を正しく知ってもらう動きをしてる。

いわゆる適切な "報連相" はもちろんのこと、Working Out Loud 的な振る舞いが染み付いていて、勝手に目立っていく感じ。結果としてまわりからフォローも受けやすく、活躍していく循環がまわる。

成果を伝えることも同じ。ちゃんと適切に "自慢" してる。Slack で報告したり、全体会議の中で話したり。そういう知ってもらう活動まで含めて仕事と捉えてる。


「じゃあ組織内では目立つほうがよいのか」、「意識的に存在感を出していくべきなのか」と聞かれるとどうなんだろうね。活躍してるから目立ってるのか、目立ってるから活躍できるのかって話なんだけど、両方なんじゃないかな。相乗効果って感じがする。

目立つことを目的にしてはいけないんだけれど、個人的には 方法論と捉えてある程度 意識的に目立っていったほうがいいんじゃないかと思ってる。と言っても特別なことではなくて、2の説明責任を果たすと結果的に目立つことになるだけ。凡事徹底。過度に自分を大きく見せる必要もない。

目立つ人しか活躍できない組織というのは健全ではない。前提として、約束を守るとか日々の積み重ねのほうが大事。何も起こさない日常を守ることが価値という種類の仕事もあるし、静かに着実に仕事をする人もめちゃくちゃえらい。そもそも目立つのが苦手という人もいる。

一方で、苦手で終わらせてはいけない話な気もしてる。一定以上の規模の仕事を前に進めようとすると、目立たざるを得ないんだよね。影響力/存在感という言葉はあまり好きではないけれど、自分やチームのことを知っておいてもらったほうがやりやすくなるのは間違いない。結果的になんか勝手に目立ってしまって、「俺またなんかやっちゃいました?」みたいな状態がいいのだと思う。

あとは、マネージャーのプロデュース能力も大事かも。2の説明責任を果たすところは特にそう。推進している当人は考えている量が多いので、「こんな過程や成果をわざわざ話すのもなあ」とか思って躊躇しがち。実際には客観視できてないだけで杞憂なことが多いので、慣れるまでは背中を押して最大限フォローするほうがいいと思う。

組織で "役割" を作る時に考えること

最近『Techリード』という役割を作って4人のメンバーにお願いした。現状 Engineering Manager とは別で立てているが、Tech リードの体制の立ち上がりを見ながら「EMはこのままEMという形で存続するべきか?」という話を EMs と話し始めている。

そんな感じで、事業を推進していく中でチームや役割を作ったり廃止したりすることがある。"役割" を作る時にああでもないこうでもないといろいろ考えていることを雑にまとめてみる。

0. 狙いを明確にする

  • いま何が問題なのか、どうしていきたいかを明確にする
  • それに対して、"役割" が本当に必要なのか、 "役割" を作ることが今の最善なのかを考える
    • 役割を作られると物事が前に進めやすくなることも多いが、周囲が無意識に頼りだしたりもする。それでも役割を置くのかと自問するのが大事

1. 期待を整理する

  • 何を担うのか、担わないのかを決めていく
    • 具体的には、ミッション、責務、責任範囲、考える時間軸、最初にやること、やらないこと など
  • 暫定的な期待なのか、将来的にどういう形になっていくのかなども想定しておく
  • 必ずしも明確にしなくてもよい。あえて重なりのあるふわっとした役割にしたり、明確にすること自体も期待したりといった整理もありうる

2. 名前を決める

  • なるべく誰が見ても期待がわかりやすい名前をつける
  • 一般的な組織のフレームワークで定義づけられた名前がマッチするのであればそのまま採用する
    • 一般的に通った名称をつける場合には、想起される役割と実際の期待に齟齬がないかを確認する

3. アサインを決める

  • 個人のケイパビリティ、will、キャリア上のメリットを考えて誰に打診するかを決める
  • 候補者のやっていきたいこと、活かせる強み、チャレンジになる部分、キャリア上のメリット などを整理して考える
    • ストレッチアサインメントになる場合、フォローをどのようにしていくかなども
  • 候補者に提案することになるので、グレードや報酬への影響、職務権限 なども人事を巻き込んで整理して判断材料を渡せるようにする

4. 人事関連を整理する

  • 組織図、グレードや報酬、規程や細則の変更が必要になる場合もあるので、人事とともに具体的に詰めていく
  • 会社によって提案の場所や承認プロセスも違うので、初期段階から上長や人事を巻き込んでおいたほうがよい

5. 本人と周囲に説明する

  • 役割を担う本人と、関連するチームや部署のメンバーへいつどのように説明するかを決める
  • アサインされた人が何をがんばればよいか迷わないように、また周囲が何を頼りどうフォローすればいいかわかるように、狙いや期待などをまとめて明文化し、丁寧に説明していく
    • できれば本人が明文化して説明すると、認識齟齬も減り "やっていき" 宣言にもなるのでオススメ
  • 一度で浸透することのほうが少ないので、繰り返し伝えていくことが大事

6. フォロー体制を決める

  • 狙ったとおりに役割が機能するよう、伴走期間を作る、定期的な振り返りとフィードバックの場を設定するなど、最大限フォローする
  • 明確な役割がつくと想像以上にまわりからの見られ方も変わり、自分自身の考え方や動き方も変化しなくてはいけなくなるので、アサインして放置ではなくフォロー体制が必須
    • たとえば細かいところだと、会議体を一緒に整理するとか。1on1の頻度を一時的に増やしてもいいかもしれない

具体例で書いていないので抽象的でわかりづらいかもしれないけれど、ざっと書くとこんな感じ。

綺麗に上からやっていくことはあまりなくて、順番が前後したり行ったり来たりすることが多い。アサインする相手を想像しながら、役割を調整したりする。

正直こういうことを考えること自体ちょっと傲慢に感じることもあるし、本当に役割を作ってお願いすることが今の最善なのかとぐるぐる考えて不安になることもある。

そもそもこういうのは正解はないんだよね。それはわかってるんだけど、アサインした人がしんどくなるんじゃないかとか、組織全体を混乱させてしまうことになるんじゃないかとか、いろいろ考えちゃう。まあ今まで何度か役割をお願いしてきて、毎回よかったと感じることのほうが多いので、今回もそう思えるようにがんばろう。

最初に仕事で作った機能とアウトカム

「何を作ったかのアウトプットではなく、顧客や自社にどんな変化を起こせたかのアウトカムが大事」的な話を聞くと、自分が開発者として最初に仕事で作った機能を思い出す。

昔話をするのはチョットダサいとも思うんだけれど、思い出話として雑に書き残してみる。


もう15年以上前、開発者として就職したての自分はtoBの勤怠管理のプロダクトを作っていた。SaaSという言葉が一般的になるより前の "パッケージソフトウェア" というやつで、かなり多くの企業に導入されていた。

業務に応じた細やかなカスタマイズが可能なプロダクトで、自分が配属されて一番最初に担当したのは「勤怠入力画面のカレンダーの土日の表示色を変えられるようにしてほしい」という要望だった。

たしか土曜日が薄紫色、日曜日が橙色で決め打ちされていたと思う。これを顧客が決めた色に変えられるようにしたいという話だった。巨大なソフトウェアのコードに手を入れるのは初めてだったし、設定値を持たせるテーブル設計も必要だったのでめちゃ簡単というわけではなかったけれど、まあ普通に作れる機能だった。

その会社では、「顧客が買いたくなるようなメリットをドキュメントにしてマネージャーに承認されないと開発に入ってはいけない」というルールがあった。いま思い出してもめちゃくちゃ思想がつよい。当時はアウトプット / アウトカムという言葉も聞いたことがなかったけれど、いち開発者が「実現するメリットは何か」を明文化して説明できることが求められていた。

当然だが、「カレンダーの土日に色をつけたいのはなぜか?」という背景を深く考え、顧客の業務を理解しないとドキュメントを書けない。要望の裏には、「土日の色をコーポレートカラーで合わせて業務パッケージシステム感をなくしたい」という背景があるかもしれない。あるいは、「土日休みではない職種ではカレンダーの土日に色がついていると邪魔」という背景もあるかもしれない。その場合、必要なのは「土日に色をつけられる」機能ではなく、「休日をわかりやすくする」という解決策で、休日マスタに合わせて色をつけられるようにした上でデフォルトでは土日に色がついている、という作りにしたほうがいいかもしれない。

こういうことを色々考えてまとめていったら、「メリットがわからない」と一蹴され却下された。「これらは推測した背景であってメリットではない、メリットを書け」と言われるのである。自分は最初何を言われてるかよくわからなくて、何度も同じようなフィードバックをもらいながら少しずつ理解していった。当時のマネージャーはとても根気強かったと思うし、今でも感謝している。

メリットという観点では、導入する労務や人事のことも考えなければならない。既存システムと同じような見た目に寄せ、従業員からの「使いづらくなった」という声や問合せを減らせるとか。これはあまりいい例じゃないかったかもしれないが、要はステークホルダーの立場や業務、課題を理解しないとメリットは書けないのである。この機能の場合には顧客と接するbiz担当者に話を聞いてある程度は理解できたが、直接顧客に会いに行ってヒアリングしている開発者も多かった。

正直どんなことを書いたか詳細はよく覚えてないんだけれど、何度かリベンジして結果的に土日の色を変更できるようにするという機能に着地した。休日マスタとの連動などは構想として記載した上で、当時の顧客のマスタ設定状況や開発工数の観点で将来的な方向性として記録するだけになった。

結果的には要望をそのまま形にすることになったのだけれど、顧客を理解をした上で「理想的にはどうあるべきで今回どこまで刻むか」という思考を経てから作れていたのがよかったと思う。実際に「土日に色をつける」みたいな関数ではなく、もう少し抽象化して実装した。エンジニアリングは、事業よりも長いスパンで物事を考えなければならない。将来どうなるべきかを描くと、今の実装も変わってくるのである。

もちろん、先のことを考えすぎてもいけないし、使われないものを作ってもいけない。また、言われていない余計なことをしたら怒られるという開発組織もあると思う。

そのプロダクト自体は全体最適をしきれず、正直に言えば顧客にとっては使いづらい部分も多かったと思う。けれども、「アウトカムを明文化するまで開発するな」が会社全体で徹底されていて、開発者として初めてのキャリアで最初にそれを経験できたのは運がよかった。自分も当時は「なんでこんな小さい要望をそんなに広げて考えないといけないんだよ」とめんどくさく感じていたが、いま思うとよい "刷り込み" だったと思う。


余談だけれど、この最初の仕事を自分にアサインしてレビューしてくれたマネージャーとは、今また同じ会社で一緒に働けている。お互い強くてニューゲーム的な感覚でとても嬉しく、やはり自分は運がいいなと感じている。

自分がやっていることを伝える技術

Working Out Loud 大声作業(しなさい)、チームメンバー同士でのトレーニング文化の醸成 - スタディサプリ Product Team Blog の記事が好きで、今でもたまに読み返している。

自分が "今やっていること" や "やってきたこと" を周囲に伝えるのはむずかしい。これは得意不得意というより慣れの問題で、慣れていない人が多いのだと思う。

慣れるには数をこなすしかないんだけれど、技術として抑えておくとよさそうなこともある気がするので雑に書き出してみる。


なぜ伝えるのがむずかしく感じるかというと、「わからない」と「やりづらい」の2つが要因だと思う。

  • 「わからない」 : 何をどこで誰にどういう頻度で伝えていいかわからない*1
  • 「やりづらい」 : なんか怖かったり恥ずかしかったりめんどくさかったりしてやりづらい

この2つを解消して慣れていくにあたって、具体的な方法をいくつか書いてみる。

1. 定例報告コーナーを作る

  • 定例会議や1on1などで、自分がやっていることを伝えるレギュラーコーナーを作るといいかも
  • ポイントは、頻度や場所を考えなくても "勝手に" 伝えるタイミングが来るようにしておくこと
  • アジェンダに組み込んで毎回話すことを宣言し、リズムを作るとよい
  • 長期的な重要プロジェクトをリードする時なんかは、自分も経営会議や取締役会の報告事項として定期的に話すようにしてたりする

2. 気軽に書き込める場所を作る

  • 同期的な会議体での報告以外に、今の状況を気軽に垂れ流すような場所を作っておくとよい
  • ポイントは、ハードルを下げて習慣にしやすくすること。このあたりの設計はマネジメントの責務でもあるので、うまくマネージャーを巻き込んで作ってもらうほうがいいかもしれない
  • たとえば Slack なら、今日やることをみんなが書くチャネルとか、ちょっとした成果を "自慢" しあうチャネルとか。個人的には、分報 times チャネルで書いていくのはあまりオススメしない

3. 日報/週報を書く

  • 日報や週報は、古きよき強力なツール。まずここからやっていくのがいいかもしれない
  • ポイントは、フォーマットをとにかくシンプルにすること。今やっていること / これからやること / 一言 の3つくらいでいいと思う
  • 一番の難所は続けることで、今だと AI にサポートしてもらってもいいと思う。ただし、AIの出力をそのまま報告にしないほうがいい。必ず自分の脳を通し、自分の言葉で短く簡潔にまとめること
  • 余談だが、自分は新卒の時に週報を書く決まりがあったにも関わらず真面目に書いていなかった。今思うと本当によくなかったと思う

4. 伝えていくスタンスを宣言する

  • 自分が今やっていることを積極的に伝えていこうと考えている旨を、上司やチームに話しておくとよい
  • ポイントは、まわりにやっていくことを伝えてやらざるをえない状況を自分で作ること
  • スタンスの宣言に加えて、他の 1~3 の内容もすり合わせておくのがよいと思う。「やり方変えたほうがいいとかあればいつでも言ってください」みたいな感じで、フィードバックを求めていることも伝えたりとか
  • そんなことを自分から言うのはちょっとなぁと尻込みしてしまう人もいるかもしれないけれど、まあたいていの上司には歓迎されるんじゃないかな。上司にとっては、報告が少なくて状況がわかりにくいという困りごとのほうが多いと思う

自分が何かを進めている時に、「そもそもなんでそんなことになっているの?」とツッコミを受けたり、「そういえばあれどうなってるの?」と聞かれたりして嫌な汗かいたことあるよな。俺は何度もある。あれはほんと嫌。

普段から自分がやっていることを伝えておくと、評価の時も何やってたかわかりやすくなる。溜め込むから思い出すのも大変なんだよね。

こういう "攻めの報連相" みたいな動き方に慣れてくると、なんというか 自分から早めに伝えることで主導権を握っているような感覚 になる。この「自分でコントロールできている」という感覚はめちゃくちゃ重要。

自分がやっていることを伝えるのは、自分の仕事を自分でコントロールするための大事な技術のひとつ。のちのちずっと楽をするために、チョットがんばって自分から伝えることに慣れていくといいと思う。

*1:「伝える意義がわからない」については、Working Out Loud の記事で効果を説明されてるのでここでは取り扱わない

考える順番を守る

何かを進める上で、守るべき考える順番 というのがあると思ってるんだけど、あんまり整理できていないので雑に書き出してみる。


たとえばシステムの不具合対応の調査。コードのいたるところにログを仕込んだり推測で修正したりする前に、発生事象と事実確認、そして原因の仮説と特定という順番を踏まないといけない。当てずっぽうで進めると結果的に時間がかかるし、もしかしたら報告自体が勘違いで不具合ですらないなんてこともある。

たとえばシステム障害発生後の振り返り。再発防止策をいろいろ考える前に、発生事象の事実確認と真因の分析という順番を踏まないといけない。こうすれば改善するよねというHOWらしきものをいくら話しても、何を防止するのかが固まっていないと芯を食った再発防止にならない。

新しいツールの導入なんかも同じ。なぜやるかを明確にして、選択肢を広げて、評価軸を整理して評価して、ひとつを選ぶみたいな順番がある。

データを分析する時に仮説を先に立てるとかもそう。依頼に取り掛かる前に依頼内容を理解するとか、仲裁の前に双方の話を聞くとかも。

こういう順番は人によって違うとかいう話じゃない。守らないといけないもの。「そんなの当たり前というか、その順番じゃないと "できない" だろ」と思う人も多いと思う。それは100%正しい。正しいんだけど、実は自分もすっ飛ばしてしまうことがある。

たとえば、採用募集要項を書く前には、いま何が問題で何を解決したいのか、なぜ人員の採用という選択肢をとるのかといった整理を先にしなければならない。一方で、きっちり順番どおりに整理しきる前に、ある程度の内容で固めて並行して募集要項を公開するみたいな動き方をしてしまうことがある。

よくないよね。よくないんですよ。よくないんだけど、まあ程度問題もあるというか、考える順番というのはグラデーションがあるんだろうね。

あるべき順番を認識して、それを逸脱して進めていると自覚的になることが大事なのかもしれない。いや、これは自分の言い訳みたいなもんで、きっちりひとつひとつ順番を踏んでいくほうが遠回りしないし気持ちがいい。しっかりやっていこう。

時間を取れていないと感じた時にやること

時間が全く取れないことはないはずなのに、なぜか時間が過ぎ去っていて時間が取れていないことあるよな。俺はある。そういう時に自分がやるべきことを雑に書き殴ってみる。

やめてみる

勝手に自分がやらないといけないと考えてるだけで、たいてい今自分がやらなくていいことをいっぱいやってるよ。「これやめたら何がどのくらい困るんだっけ?」と一度立ち止まって考えて、思い切ってやめてみるといい。自分だけで想像せず、関わる人に直接聞いてみるのがオススメ。

特にオブザーバーで入ってるミーティングとかね。なんか不安ってだけで出席してるミーティングが週に3つとか入っていないか?まず2週間出ないでみてどうなるか振り返ってみるのもいいと思う。たぶん何の問題もないことに気づけるよ。そうでなくとも関わり方が変わるはず。

立ち止まる

自動化、効率化にちゃんと時間を使わないとジリ貧になる。「2日あったら仕組みを作れるか?」と自分に問うてみて、Yesなら立ち止まったほうがいい。今はそういうのがやりやすい時代だしね。

とにかくひたすら歩き続けるのか自転車を手に入れるかみたいな感じ。複利で効いてくる。

予定をまとめる

「コンテキストスイッチングコストがつらい」と嘆いているなら、自分のコントロールできる範囲で予定をまとめてみるといい。たとえば水曜をミーティングデーにするとかね。まわりの人に提案してみたら、実は同じ悩みを持っていて歓迎されることも多い。

かわりにガラ空きの作業デーができると、今度は他の予定を入れられたりするよな。そこは強い気持ちで "断固拒否" するしかない。拒否できないとしたら、たぶん自分が時間を取れたら何を成すべきかが明確になってないんだよ。もっかい考え直して、忘れないようにZoomの背景にして貼り出しとくのがいいんじゃないかな。まわりへの牽制にもなる。

宣言する

はたして本当に時間が "取れていない" のか?時間がないんじゃなくて "集中できていない" だけじゃない?無意識に忙しいと思い込んでることもある。

多くの人は追い詰められないと集中できない。逆に言うと、追い詰められるように設計するとやれる。他者を巻き込んで宣言して、 "やらないといけない状況" を作るのが一番いい。たとえば上司に「今日18時までにドラフトを出します」って言っとくとかね。緊張する間柄やイベントを利用するのがいいと思う。とはいえあんまりやりすぎるとしんどいので、無理しすぎない程度に。


なんか完全に未来の自分への私信みたいになってしまった。すべての人に有効な話ではないと思う。

10分単位で予定が詰まってるエグゼクティブとかじゃないかぎり、本来時間が取れないなんてことはないんだよ。いつのまにか自分でコントロールできないように思い込んじゃうんだけど、実際はそうじゃない。

こういうのって本人だと気づきづらいし動きにくい。なので、できるなら他者に コーチ / おかん / ジャーマネ みたいな立場になってもらうほうがいいと思う。放置せず何かアクションを起こせば少しずつ好転するのでいろいろ実験しよう。幸運を祈る。エル・プサイ・コングルゥ。

間に落ちそうなボールを拾う人の葛藤

何かの問題が放置されていそうな時に、自分がオーナーシップを持っていなくても必要ならガッと前に進められる人がいる。

これはめちゃくちゃ素晴らしいことなんだけれど、こういう『"間" に落ちがちなボールを拾う人』は結構悩みつつ動いていることが多い。過去に 1on1 でも何度も同じような相談をされたことがあって、うまく答えて対処できたか自信がない。今後のためによくある悩みと対処方法をざっと書いてみる。


「ネクストアクションとアサインが明確じゃないからボールが宙に浮いちゃうんでしょ」という意見もあると思う。それはそう。基本はアクション、アサイン、期日を決めればいいだけではある。けどねぇ、部門やチームをまたぐような問題だと、なんか止まっちゃうことがあるんだよね。

そういう時に先陣を切って動ける人は本当に貴重で素晴らしい。傍から見ると非常にありがたい存在なんだけれど、当人は次のような悩みを抱えながら動いてるように見える。

  • 「見えていない情報や考え方があるんじゃないか」
  • 「中途半端にボールを持つことで引っ掻き回すことになるんじゃないか」
  • 「本来持つべきメインの責務に集中するべきじゃないか」
  • 「他のチームや担当者のやる気や機会を奪うことになるんじゃないか」

自分が一番うまくできるとも思っていないし、本来の役割としてもボールを持つべきなのかわからない。けどやらないと前に進まないならやる。言ってしまえばそれだけなんだけど、それが正解だとも思っていないので悩むんだよな。そしてそんな悩み自体も傲慢なように感じてしまう。

この悩みに対してどうするかという話なんだけど、次のステップで進めていくしかないと思う。

1. いったん割り切って動く

  • 「自分がやってていいのかな」とか思いながら中途半端に行動するのはよくない。「今回は自分がやる」と決めて動くほうがいい
  • 上長や周囲に宣言し、もし動き方を変えたほうがよければそこで言ってもらうとよい

2. 本来どう対応されるべきだったかを考える

  • 本来どのチーム、または誰がどう動くべきだったかを考えてみる
  • 組織的にはこうなるべきという形が見えてくると、同じことを繰り返さないように次に活かせる

3. 当事者を集めて振り返る

  • 結局まわりがどう考えているのかわからないから悩むので、ボールを拾うべきだった "かもしれない" 当事者たちを集めて直接話すのが一番いい
  • とはいえ、なかなかむずかしいので上長など他の誰かに頼ったほうがいいかも。形式は事後の "振り返り" がいいと思う
  • どのチーム、または誰が動くべきだったかを明確にした上で、次回少しよくするために放置された原因を深堀るとよい。たとえば次のような観点
    1. ボールに気づいていない
    2. ボールが落ちていることに気づいていない
    3. ボールが落ちていることに気づいているが、誰が拾うべきかわからない
    4. 自分が拾うべきと思っていたが、どう進めていいかわからない
    5. どう進めればいいかも見えているが、後回しになり連絡もできていない

「気づいていなかった」、「今やらなくてもいいと思ってた」、「誰かがやると思ってた」みたいな感じでボールが落ちてしまうことはある。それに対して自分から声を上げて動ける人はすごい。組織的な課題はあれど、称賛されるべき振る舞いだと思う。

個別には前には進むけれど、そういう動きができる人ほど本当に自分が動いてよかったのかと葛藤しがち。正直いきなり次回から劇的に改善したりはしないので、ある程度そういうもんだと割り切って必要な時は拾うのがいいと思う。ちょっとずつ改善するしかない。

たいてい自分の守備範囲を超えた話なので、上長がいれば上長に相談してボールを持ってもらうこと。役割を明確にして「自分がやらない」と決める "引き出し" を持てると、気持ちは楽になると思う。それでもボールが落ちるのを見てられなくて、結局悩むと思うけどね。まあそういう時は、「おまえらちゃんと拾えよ」、「マネージャーは組織的に何とかしろよ」みたいな感じで、適度に他責になっていいと思う。