中途採用メインの会社に転職して、違うバックグラウンドのひととたくさん話すようになって、自分の中の固定概念というか思い込みや信念みたいなものがよく見えるので、それを言語化しておきたい。
— 新米医療情報技師 (@Kengo_TODA) 2024年1月27日

固定概念、自分の行動を爆速にしていくうえでは非常に有効なバフなんですが、ナチュラルに「あれ？僕またなんかやっちゃいました？」を生産する機会にもなるのできちんと棚卸しして自覚的になっておきたいため、まとめました。

「ちゃんとやる」コストを自分で払う

ソフトウェアエンジニアリング業あるあるだと信じているのですが、この仕事はベスト・プラクティスが積み上がっていて目指すべき働き方が明確なだけに、「ちゃんとやる」ことがとても難しいという問題があります。たとえばRedmineのようなものでチケットを積み上げてガントチャートを消化していくようなプロジェクトであれば、チケットの管理だけでも以下のようなことを「ちゃんとやる」ことが理想です：

チケットは最長でも3日でデフォルトブランチにマージできる大きさを保つ
新しく発生したタスクはチケットに落とし込み、DONEの定義についてチームで合意を取る
チケットにはチケットを解決するうえで判明した事実やブロッカーを書く
朝会までに変更をpushし、着手していたチケットを更新し、経過を共有できるようにしておく
チケットやチャットで判明した事実のうち、ストックするべきと思われた事実はWikiやドキュメンテーションコメントにする
チケットは他のチケットやPull Request、デプロイとの紐づけを行い、あとから関係性を追跡できるようにしておく

さて、これをチーム全員ができているプロジェクトはどのくらいあるのでしょうか。無いでしょというのが自分の意見です。これは新卒採用がメインで「走りながら教える」必要があった自分の経験から来ている考え方ではありますが、ベテランが集うプロジェクトでも大差ないだろうと感じています。

ではやっていない人を吊るし上げればいいのか、やれない人に根気よく教えるべきかというと、そうではありません。中途半端なコードの共有に抵抗のある方、状況や考えをテキストにダンプすることが苦手な方、コードを書くときは集中しており終わったら疲れ果てているのでチケットを更新する時間が捻出できない方、他のことに挑戦していてチケット管理の優先度が低い方など、「ちゃんとやれない」背景には様々な事情・個性があります。特に気質や価値観、健康に根ざしている場合は「やれ」と言うこと自体がリスクなわけです。

少し抽象化した表現をすると、自分は企業文化・行動規範以外に「チーム全員に画一的な素質・行動を求める」のは失敗パターンだと思っています。そりゃ面倒をみる側からすればチーム全員がちゃんとチケットを管理してくれれば大助かりです。実際に教えればできるようになるケースも多数あるでしょう。しかししばらく声をかけてみてダメだったり、ヒアリングや観察の結果「いまは難しそうだな」と思ったら、諦めも肝心です。あまりにも致命的で協力関係が築けない場合は除くとして、基本的には自分が「ちゃんとやれる」範囲で手助けするほうが良いでしょう：

新規に作成されたチケットの粒度を確認し、大きすぎると思ったら分割を提案する
チケットのDONEの定義が明確ではない場合、チームで話し合いの機会を持つ
考えをテキストに落とせていない場合、朝会でヒアリングしてその場でチケットに書いていく
変更をpushできていない場合、朝会の前後で座席に行って画面を見せてもらう
wikiやドキュメンテーションコメントを更新できていない、自分で変更を提案する
紐付けられていないチケットがあれば、自分で紐付けるか、自動化を用意するか、デプロイやレトロスペクティブのタイミングで一緒に紐付ける機会を持つ

こんな考えだからマネジメントに超人性を求めてしまうのだとはわかっていますが、チームワークを円滑に回して組織としてのアウトカムをコミットするのがマネージャである以上、必要なことだとも思います。

実際、こうやって「ちゃんとやる」フォローに回ることで一番メリットを享受できるのは、マネージャである自分自身なんですよね。組織がアウトプットを作れていてアウトカムの実現に近づいているかという、そのプロセスの透明性を見たいですよね。ので「ちゃんと見せろ」と他力本願するよりは、「ちゃんと見に行く」ほうがControllableだし育成の方向性も見えてくるし建設的なはず。

なおマイクロマネジメントとの線引きは自分の中では明確で、「ちゃんと設計できてないから自分で設計する」「ちゃんとテスト書くのが大変だから書いてあげる」「ちゃんと機能追加するのが難しそうだから代わりにやってあげる」あたりはマイクロマネジメント寄りかなと思います。

この判断基準については、最近同僚が「相手のプロフェッショナルに踏み込む」という表現をしていていいなと思いました。相手がプロフェッショナルとしてやるべきところ、やりたいと思っているところには触れない。スクラム回すからには透明性を上げるのもプロフェッショナルの範囲だろうと言う考え方はできるかもしれませんが、そこは先程の「チーム全員に画一的な素質・行動を求める」のは避けるを適用します。

まぁこれ、たぶん真のcross-functional teamをマネジメントしてるとあんまり問題にならないんでは無いかなと思います。そもそもチームメイトと自分のプロフェッショナルがぜんぜん違うんで、代わりにやってあげるという選択肢がそもそも取れない。ので自分がcross-functional teamの経験が浅いことの裏返しなのかなとは思う。

最後まで自分で追いかける

先の例（チケット管理）だと、マネージャじゃなくてスクラムマスターがやればいいのでは？という疑問があるかと思います。もちろんスクラムマスターに委譲するなど、仕組みや委譲で解決できればその方が良いことも多々あります。

それでもそのスクラムマスターがちゃんとやっているか？は自分で見る必要があります。チームメイトの1on1を通じて、スクラムマスターに目指してほしいチームづくりができているか、できていないなら何を変えるべきかを考えていくわけです。またこの姿勢は相手と一緒にDONEの定義を考え、適切な問題空間を設定することに繋がります。チームメイトにとって難しすぎる問題設定を避けるとともに、あとあとで「期待とぜんぜん違うアウトプットが出てくる」リスクに対する対策にもなるため、チームマネジメントにおける重要な姿勢だと言えます。

これはスクラムマスター以外のプロフェッショナルについても同様で、新しいデザインや機能が顧客の課題を解決したのか、新しく導入した品質管理手法はどう作用したのか、作成したドキュメントやツールが現場で使われているのか、実装の最適化でランニングコストやレイテンシは改善されたのか……などをプロフェッショナルと一緒に最後まで追いかけることが必要です。昔の上司が「信頼はするけど信用はしない」と言っていましたが、プロフェッショナルを信頼することとそのアウトプットを確かめもしないことは別なのです。

もちろん他のチームやお客様に対しても同様の姿勢が必要です。依頼したタスクが終わったのか、その効果が出ているのか、やるべきことを忘れていないか……などを追跡することで、組織的な課題がチームの間にこぼれ落ちたり、顧客が必要としていないことにコストを掛けたりといった問題を早期に発見できます。

ここは意外と多くのマネージャが「そこまで私の仕事なの？」と言いがちなところで、まぁ実際マネージャのマネージャや経営がしっかりしてたらマネージャがそこまでやらなくていいよねとか、給料に入ってるんだっけこれという思いも無いわけではないのですが、結論、やったほうがいいですね。チケットのDONEの定義をクリアしたらオッケーなのはチームメイトにとっての話で、マネージャの仕事である「チームとしてアウトカムをデリバリーする（横文字多いな）」はチケットの積み上げからは見えないラストワンマイルがあったりするので、ほぼ例外なくデリバリー先を見に行くことが必要です。そしてこれをやるためにも日頃からのチーム内外との関係性構築が大切で、このためにもマネージャはWorking Loud Outしておくと良いと思います。

developers.freee.co.jp

が、すべてのマネージャがこの考えを持っているかというとそうではないので、あくまでも自分の固定概念だということに自覚的になっておきたいと思いました。

なお、これはマネジメントもそうだけど、リーダーシップを発揮するうえでも必要な姿勢かもしれません。リーダーシップについても近々考えをまとめておきたいです。→まとめました。

マネージャは暇してるべき

自分でやれ、最後までやれと来て、最後がこれか？とは自分でも思います。思いますが、チームの前に立ちはだかる障害を即座に解決してチームをトップスピードに保つためにはやはり必要です。経験的には毎日勤務時間の4割に空きがあって、いつでも1on1や対応工数を積めるくらいの暇さがあったほうがいいです。どんなに定期1on1や朝会などの仕組みを整えてもイレギュラーは発生するので、即対応できる時間はいつでもつかえるようにしておくべきです。

べきですが、ここは自分の考えに柔軟性がなかったなと反省するところで。大企業ならチームの役割も比較的明確なのでこれで回るのですが、そもそも市場を探している段階だったり1人で3つも4つも役割を兼任しないといけない場合だったりすると、そんな暇を抱えてるわけにはいかないのも事実でした。本来マネージャに兼務はご法度なんですが（むしろ兼務自体が滅べばいいとすら思っている）、マネージャをやるということは集まる情報が増えるということなので、その人が複数の役割を持つことは展開としてまぁナシじゃないなという。

この場合、即応するのはマネージャではなくチームメイト同士が有機的に行うことになるはずで、お互いに即助けに入れるくらいチームメイトの仕事と状況を理解していないといけません。cross-functional teamであれば一時的に自分の専門外のことに着手することもあるでしょう。そういう空気や関係性を醸成することのほうが、マネジメントにとっては優先度の高い営みなのかもしれません。

まとめ

自分のなかにあったマネジメントに関する固定概念を一言でいうと「全部自分でやれ」なんですよね。もちろん組織としてのアウトカムをコミットするのがマネージャである以上、マネージャが口にする主語は常にweなんですが、weという存在を円滑に動かす機能の最後の砦がマネジメントなのは疑いないので、文化情勢や仕組みでの解決では漏れてしまうところは常にマネージャが拾い続ける必要があると思っています。

何でもかんでも自分でやる姿勢、一歩踏み外すとマイクロマネジメントや部下の成果をぶんどる系上司になりがちなのはあると思います。自分でやるのか、コーチングするのか、根気よく教えるのか、それとも諦めて別の手段を取るのかという判断基準は「相手のプロフェッショナルに踏み込む」を基本にしつつも相手に依って調整が必要なため、今後も手探りになりそうです。