マネージャになって半年間にやってきたいくつかのこと
多分ポエム。Qiitaじゃないので許されるかなあ、と思ってます。
はじめに
私が #R社 に来てもうすぐ1年ですってよ、奥様(誰。配置的には、小西さんの当初の目論見からは外れてしまったようですが、個人的には現状適材適所かな、と。正直な話、某社より楽しく仕事をさせていただいています。
今のチームのマネージャを拝命してはや半年が経過してしまいましたが、チームがもっと価値を出すためのプロセスを作っていく最初のステップとしての半期が割と上手く行ったので、やってきたことを整理してみたいと思います。で、以下に挙げていくことは、このチームのためのパターンランゲージになるのではないか、と意図しながら整理しているものです。と、まあ、言うてもそんなにたいしたことはしてないです。だいたい何かの受け売りです。もし、これを読んで「こんなことで？」と思うのであれば、早速取り組んでみると良いと思いますよ。
なお、取り組んできたことそれぞれには前提となる文脈や課題があるので、同じ通りにやっても同じ結果が出るかどうかは保証しません。
目的
今回あげるいくつかのことはすべて、「開発プロセスをチームで作る」ことを目的としています。
何か特定のプロセスに対して自分たちをいきなりはめ込むようなことはしていません。効率的な設計やプログラミング、品質向上のための取り組み、およそ全てのエンジニアリングに関わることについて、チームですべきことを決めていくためにやってきたことです。
幾つか理由はありますが、最も大きかったのはチーム再編と継続した外向けの開発を同時にやらなければならなかったことです。今までよりも人数的には厳しい状況で、走りながらチームを変えていくとなると、開発プロセスに対してメンバーに当事者意識を最初から持ってもらう必要がありました。半年経った結果、思ったよりもスクラムやなんかに近づいているとは思いますが、スクラムをすることが目的ではありません。
もう一つ理由としては、メンバーに中堅やベテランが比較的いたことです。当然パフォーマンスの大小はありますが、この業界で10年以上仕事をしてきている実績というのは伊達じゃありません*1。彼らには、経験を生かして高いパフォーマンスを出してもらわないと困るのです。そのため、彼らの手になじんだやり方をベースにそれをグレードアップしてもらう方が良いと判断しました*2。
メンバーは「自分」ではない
前項の目的を達成するために、前提として意識したことです。
セロリじゃないけど、「育ってきた環境が違うから」できることは違うんです。今私にできることがメンバーにできる訳ではないのと同様に、今メンバーにできることが私にできる訳ではない。
少なくとも後から来た私よりも、メンバーはプロダクトのことも知っているし、その中で試行錯誤しながら乗り切ってきたはずです。それを無視して、自分ができることを中心にメンバーとチームの評価をしないこと、自分ができることができないからと言って、それは仕事ができないという意味ではないということを意識しました。
これは、スキルに限った話ではありません。文化の話も同様です。英語に対するスタンスであったり、技術に対するスタンスであったり。ワークライフバランスにおいてどこを重視するか、自己の戦略をどう捉えているかはメンバーによって違います。マネージャが自分が育ってきた文化以外を認めない環境だと、おそらくチームは息苦しくなってしまうと思います。
とにかく、自分とメンバーとは、できることも感じることも違うことは前提として意識するようにはしました。
やったこと
スキルセットの面談
そもそもコミュニティであったこともなく、会社で初めてあった人なので、できることも今までの仕事の経験も知りません。メンバーはそれぞれ、それなりの経験とスキルを積み重ねてきています。
このチームで持っているスキルを存分に発揮してもらうために、スキルセットの面談をしました。聴いたことは以下の三点です。
- 仕事の経験(技術)
- 仕事の経験(内容の特性)
- コード書くのは得意か
特に2番目を聴いておいてよかったです。メンバーに保守開発の現場が得意という人が多く、継続していくために必要なドキュメントワークやレビューなど、コードを書く一辺倒ではない動き方や仕事の依頼ができるようになりました。
ふりかえり
これはもう、今更言うまでもないですね。まずはふりかえりをすることから始めました。定番のKPTと、redmineでタスクを管理しているのでその棚卸しとアサインです。
チームの仕事の改善は細かく試して、細かくフィードバックを得ることが重要です。案件ごとに総括会みたいなことやったりするところもありますが、だいたい半年〜数年前のことなんて忘れていて、終わったときには達成感みたいなものが邪魔をします。この手の達成感は割と厄介で、「まあ、なんだかんだあったけど、俺たちがんばったよね」という感覚になって、問題点を冷静に分析できないバイアスがかかってしまいます(俺調べ)。人が老害化する原因の一つがこの手の達成感だと思っているので、達成感を感じる前の段階で改善していこう、という試みです。
この半年間はこのメリットを実感してもらうために、まずは継続することを重点においてきました。ProblemとTryの質についてはあまり深入りしませんでしたが、それでも回を重ねるたびに目指すチームの姿に近づくための課題に迫っている気がします。そろそろふりかえりのふりかえりが必要になりそうな気がしています。
朝会
これも比較的早めに取り組み始めました。定番のシンプルなもので、メンバーの「今日やること」を短い時間で共有します。半年経ったら、朝会の最後に今の開発全体のフェーズについての確認的な一言を私が添えることが多くなってきました。
チーム内での仕事のムラや進捗度合いの違いは、人が違うので当然出てくるものです。まずそれをチーム内でオープンにすることを考えました。誰が今サポートをほしがっているか、誰がそのサポートに入れそうなのか、隠さずにこの場にあげることによってチーム全体で仕事をする意識をつけることを目的としています。元々現メンバー同士の結束はかなり固い方でしたので、オープンにさえすれば自然とサポートに入ってくれるという思いもありました。
目指すチームの姿
どういう仕事をするチームが理想なのか、その姿をチームで話し合いました。狙ったのは、ふりかえりへの効果とメンバーの個人目標を立てやすくすることです。
前者はProblemとTryに対して、「この課題や改善の道筋はチームが目指す方向に沿っているだろうか」と考えるバイアスを作ることです。理想像を作ったからと言ってすぐにそれができるようになるとは思っていませんが、こういう根本的な問いをするためのバイアスは意識しないと作れないものなので。
後者は、チームが目指す姿に対して自分がどのようにマッチしていきたいか、そのためにどういうところで貢献するのか、ということを意識しやすくすることです。興味あることから手当り次第に学んでいくことも楽しいんですけど、学ぶことに対してチームの理想に対する承認と評価で答えられるようにしたかったので。メンバーが自己の目標を達成することでパフォーマンスが上がって、チームの評価や業績が上がって、それに対してメンバー個人への評価で答えるという単純なサイクルですが、はっきりしている方がモチベーション上がりますよね。
期待を丁寧に伝える
マネージャとしての仕事と言えばそれまでですがメンバーの評価をしなくては行けません。メンバーの生活の一端について決定権を持つというのはあまり居心地の良いものではないので*3、なるべく良い評価ができるように、各メンバーに期待することを合わせて伝えるようにしました。もちろん、ある程度本人の指向も見た上でのことですが。
あわせて伝えるように心がけたのは、期待することに対して学習の入り口となるような情報の提供です。まあ、本やコミュニティ、キーワードの紹介にとどまっていますが、新しいことを学習する前にきっかけがあると良いですよね、あまのじゃくでなければ。
みんなで見積もり、みんなでレビュー
これはオープンに議論することと、集中して各自の仕事をすることに対してメリハリをちゃんとつけたいと思って始めたことです。
見積もりもレビューもそうですが、不明なところや心配事、やることややらないことをできるだけリストアップしたいので、いろんな視点が必要です。議論をオープンにしてより多くの目を効率的に光らせる必要があります。ただ、ダラダラと時間をかけてしまえば際限がなくなってしまうので、時間は区切りたいのです。それに対して設計やプログラミングなどは、やることを決めてしまえば出来上がってしまうまでは集中して取り組みたい仕事になります。
これらのメリハリがついていない状態に備えることが、私自身が非常に大きなコストになってしまうため、見積もりとレビューは時間の枠を決めてメンバー全員で集まってすることにしました。作戦会議して目的と役割を確認したら、散開、というイメージです。
スーパーサブになる
これだけは残念な話なんですが、チーム内で一番コードが書ける*4のは、未だ私であるという状況があります*5。ということもあって、特にプログラミングの領域において、私がやった方が早いという状況はこの半年間で何回か見受けられました。そこをぐっとこらえて、あまり自分で手を出さないようにしました。チーム全体のパフォーマンスとして見た場合、私一人が向上させたときの結果と、メンバー全員が少しずつ向上させた時の結果、どちらがチームの成果に結びつくかは明らかです。
いつでも現場に戻れるような準備はしておいて、案件のこともわかっていて、流れを変えたいときに便利なスーパーサブになるつもりで常にベンチ入りしております。理想を言うと、私が出る幕がないレベルの人が育ってくれると良いですが、そんなにすぐに育つものでもありませんし。
その他
他にもやっていることは有りますが、チームでプロセスを作ることを促す目的ではないので除外しています。雑にリストアップすると以下のような感じですね。
- 率先して早く帰る
- 抜き打ちコードレビュー
- まだ使ったことがない便利そうなツールで遊んでおく
- チーム外のレビュアーを頼む
だいたいね、私は楽をしたいのです。早く帰って嫁と過ごしたいのです。そのために全力を尽くしているのです。はんこ押すだけの存在にしてくださいよ(バンバン。
ちなみに最後に関しては、私がマネージャとしてコントロールできる状況ではありません。ほぼ偶然に近いことなのですが、身近にきよくらさんやnitro_sandayさん、zephiransasさんがいたからできたことですね。そういう職場と言ってしまえばそれまでの話になります。
マネージャとリーダーについて
今回のエントリは、完全にマネージャ向けのものです。リーダー向けでは有りません。
自分の中では明確に役割は分かれています。マネージャはチームがうまく仕事ができるような下働きができないと行けません。「俺がかっこいいんじゃない、チームがかっこいいんだ」と本気で思える人とかマジで向いてるんじゃないかと思います。
リーダーはもっと先のビジョンを見なきゃいけないわけですよ。プロダクトをこうして展開していきたいとか、こういう風に世間から評価されるチームにしたいとか。その辺りについてはまた機会があれば、ということで。
最後に
新人マネージャがとりあえず書き散らかしてみた感のある文章ですが、少なくとも自分の備忘録にはなったかと。この半年くらいは、自分の周りで優秀だったマネージャがどんなことをしていたかを思い出しながらやっています。
とりあえず結果を急ぐ人は、このエントリなんかより「ピープルウェア」「人月の神話」「FEARLESS CHANGE」の三冊を読んだ方が良いと思います。
