はじめに
フューチャーAdvent Calendar 2022の9日目です。
今年は、いままでの流通小売の事業部からHealthCare Innovation Group（HIG）へ転籍したり、初のチームリーダーを担ったりと6年目にして変化の多い1年でした。
いままではメンバーとして目の前のタスクやソースコードに集中していればよかったですし、それに甘んずる形でリーダーになることを避けてきたのが正直なところです。半数以上が自分より若いメンバーという中で、チームやプロジェクトをより良い状態にするにはどうしたらいいのか、を模索する1年でもありました。本記事は、ベストプラクティス、というよりも自分自身の感想と振り返りを記録するものになります。
なお、記事内にちょこっとだけ経営学の専門用語っぽい言葉を使っていますが、今年受けた中小企業診断士試験（昨年の記事を読んでくださった方、察してください…。）で得た知識をなんとか活かせないかなあと考えてたからになります。
チームリーダーの役割と考え方
プロジェクトやチームの状況によって変わるかと思いますが、たいてい以下のタスクを求められるかと思います。
- 計画立てと進捗管理
- 成果物の品質管理（レビュー）
- メンバーの育成
- メンバーの評価(フィードバック)
これで過不足がない、というわけでなく、チーム内やチームリーダーより上のリーダーで分担したり、顧客対応など他の役割も担うこともあるかと思います。
また、タスク以外にも、メンバーの働きやすい環境を整えたり、チームをまとめ、凝集性を高めていったり、とタスク（＝Redmineのチケットにならない）動きも求められるかと思います。ここではまとめてチームビルディングと呼びますが、むしろこちらの方が大切で、いろいろと模索しました。
また、１~4のタスクを行う上で、1on1やナレッジマネジメントを実施しました。
チームビルディング
1.メンバーとの良好な関係を築く：心理的安全性を高める
心理的安全性を高めるという言葉も最近よく聞きますが、メンバーとの良好な関係は、チーム運営の土台であると考えています。
もちろん単なる「仲良しこよし」というわけでなく、仕事を行う上での良好な関係であり、場合によっては耳がいたいことも互いに言うことができる関係性を目指していました。
「ホウレンソウ」がないのはリーダーのせいかもしれない
よく世の中には、「部下の報告が遅い」という愚痴などを見聞きします。「メンバーはネガティブニュースを早く上長にエスカレーションすべし」はメンバーのあり方としては正しいのですが、リーダーとしては報告が遅いと愚痴っているだけでは何も解決しないのではないでしょうか。いわゆるホウレンソウが来ない原因を取り除く必要があると考えています。
気軽に相談できるような関係性を築ける取り組みとしては、まず、アサインやフェーズの初めのうちは相談枠を設けたり、こちらから声をかけたりしていました。
また、相談には時間の許す限り、一緒に解決方法を考える（なるべく突き離さない、自分じゃどうしようもならないときは、別の有識者に頼ることもあり）ことも意識してました。逆に、進捗が悪い・コーディングがうまくいかないと言ったネガティブなことをエスカレーションしたとしても、怒られたりするだけで、何にも解決にならないのであれば、進んでエスカレーションしようとはならないよなあとも思っており、しっかりとメリットを与えることを意識していました。
私に相談すればメリットがあるということを「信じてもらえる」ようになって、対面（web会議含む）だけでなく、slack上でもコミュニケーションが進み始めたかなという印象です。
2.プロジェクト成功へ向けてのモチベーション・パッションを高める：凝集性を高める
モチベーションコントロールは自責なのか
自分のモチベーションをコントロールするのがプロとしてあたりまえ、仮にモチベーションが低くても、成果に影響を与えないのがプロだという考え方もあります。１プレイヤーとしてその考え方はめちゃくちゃかっこいいのですが、チームリーダーという立場であれば、メンバーのモチベーションを把握し、なるべく高めていく働きかけを行なった方がよいのではないかなと考えていました。上記の考えで、メンバーを突き放したところでそのメンバーのモチベーションが上がらないよなというのが大きな理由です。
目標を共有する・身近にする
モチベーション、熱を帯びた言い方をすればパッション（熱意・情熱）を高めていくには、共通の目標を共有し、それに向かって頑張ろうと鼓舞していくことが有効かと思います。
プロジェクトの（目の前の）目標というと、システム開発では問題なくリリースすることになるかと思いますが、メンバーのプロジェクト参画時にはその背景や大義などが共有されるかと思います。定期的にその背景や大義を振り返ってみるのも良いかと思います。
また、1on1を通じて、プロジェクトの成功とメンバーのタスク、そしてメンバー個人の成長目標達成が結びつけられるように話すこともありました。
1 on 1
1on1については、Future tech blogの真野さんの記事を参考に実施していました。
特に記事内の「1 on 1を開催する意図」に賛同していて、そのままgoogleカレンダーの1 on 1の予定の説明欄に引用していたりしますw
1 on 1 を開催する意図とは？
こまめなフィードバックをしたい
半期ごとの評価時に行うフィードバックをもっと刻みたい
「あの時、実はこうして欲しかった」みたいに伝える人もいるけど、「その時に言ってよ」と過去の自分が思ったのも影響している
私のビュー（視点）からはこういうふうに見えていると伝えたい
良くも悪くも事実だと思うので、やったことが伝わってない場合は見せ方を変えるなどに活かしてほしい。活かしたくないなら無視して欲しい
アドバイスをできる範囲で。一方で自分過去の武勇伝を語っても仕方ないので、なるべく自分で考える切っ掛けを与えようと思う
振り返りの場としても活用して欲しい
キャリア志向にそったタスクアサインにも活かしたい
もちろん、不満や業務上の聞きにくい質問もOK。それで時間が潰れたら別途枠を用意する
私自身、半期や1年ごとの評価の場で、初めて評価・フィードバックを下されるガラガラポン状態に違和感がありましたし、フィードバックする側として半年前のことまで覚えている自信もなく、こまめにフィードバックしたいと思っていたので、チーム内で開始しました。
真野さん記事の
私のビュー（視点）からはこういうふうに見えていると伝えたい
良くも悪くも事実だと思うので、やったことが伝わってない場合は見せ方を変えるなどに活かしてほしい。活かしたくないなら無視して欲しい
にあたりますが、
（特にネガティブな）フィードバックについては、「理解」してもらうことを意識しています。理解してもらうために事実とどう見えていたかを丁寧に説明するように心がけました。なお「納得」してもらうことまでは求めてません。1絶対に従ってくれと思っているわけではなく、フィードバックを受けて自分自身で考えて行動してほしいからです。
開催頻度としては隔週を標準にして、アサイン当初やフォローが必要かなと思ったときは週１回に頻度を増やして実施していました。
ナレッジマネジメント
ナレッジマネジメントは主に育成面に関わります。
ナレッジマネジメントというと、俗人化している暗黙知をwikiとかに書いて形式知にしてみんなが使えるようにしよう（＝表出化）というイメージが強いと思いますが、SECIモデルが提唱しているように、暗黙知を暗黙知として移転するというプロセス（共同化）もあります。
ペアプロなんかはまさに良い例で、上級者はこんなショートカットキー使ってる、に始まり、このメソッド使うと冗長にならずにシンプルに書けるのかとか、エラーがでたときに、エラー文のどの部分に着目して、どういった検索ワードで調べて、どのあたりの情報に着目して解決していくか、といったことを横で学べます。
この例でわかるように、すべての暗黙知が形式知できる（しやすい）といったわけでもないです。ショートカットキーやメソッドは文章化しやすいですが、上級者のエラーの対処のコツを言葉にしていくのはなかなか難しいです。そのため、共同化プロセスも結構有効だったりします。
上記のようなコツだったりを共有する目的で、チーム内でもペアプロや、対面でのレビューを実施していました。
もちろん暗黙知を形式知化する表出化も大切で、「そのノウハウはぜひwikiに書こう」という呼びかけもしていました。
終わりに：リーダーをやってよかったかもしれない。あと未来の話
プロジェクトが無事終わったとき、システムのリリースそのものよりも、メンバーの成長への嬉しさだったり、このチームでやり遂げたぞといったところのほうが自分自身の中の達成感として大きく残りました。過去一番小規模なプロジェクトにも関わらず、一番の達成感がありました。（過去参画したプロジェクトの皆さんには本当に申し訳ないですが・・・）。
6年前、就職活動をするなかで、当社への入社の決め手となったのが働いている「人」だったので、人に関心があって人で達成感を感じるのも自分らしいなとは思います。
最近、「リーダーの作法 ささいなことをていねいに」を読んでいます。自分にはできてなかったなと反省することも多く、表紙のハチに刺されたような痛みを感じますが、次回に生かしていきたいです。
-
私はしばしば「理解」と「納得」という言葉を使い分けています。メンバーにも伝えたかもしれない。 ↩