2022年1月から末端エンジニアを抜け出して、エンジニアリングマネージャーという役割に変わりました。
※そもそもエンジニアリングマネージャーか？といわれると微妙な気もするが、エンジニアが数人いるチーム（グループ）のマネージメントだから、まあ間違っていないでしょ～。
約1ヵ月が立ちました。
1ヵ月間（それ以前から）、いろいろなことを考えていろいろなことをやってきたので、自らの1か月間を振り返る意味でもまとめておこうおと思い筆を取った次第です。
弊社のマネージャーという役割は「組織（チーム）マネジメント」「組織構造上のリーダー（長）」という位置づけだと考えているので、双方の立場である前提で記載してみます。
私が考えるマネージャー
役割
私が今考えるマネージャーの役割は大きく4つ。重要度順に書きます。
- チームメンバーを成長させ、成果を出させる
- チームの成果を最大化する
- 上や横からの（無駄な）圧力などからチームを守る
- タスク、業務の進捗管理をする
思い
特に私は1つ目のチームメンバーを成長させ、成果を出させるが最重要任務であると考えています。
成長という言葉は非常に抽象度が高い言葉ですが簡潔に言いたいときはよく使います。
具体的には以下のような感じです。
- プログラミングスキルを上げる
- プロダクト特有の仕様などの知識を増やす
- 問題解決のための思考力、知識、実行力を高める
これらを継続していくことで、結果としてチームの成果が大きくなり、チーム外からの圧力に対しても対応できるようになっていくだろうと考えています。
エンジニア集団は極論、人の力、個の力です。力不足な人間が寄り集まったところで、どんな仕掛けを実行しても限界があります。
個が強くなれば、組織の力は仕組みや仕掛け次第でいくらでも大きくできると考えています。
（サッカーの本田圭佑さんが記者会見で放った有名な言葉みたいですね。結局組織のパフォーマンスは個のパフォーマンスに依る。）
参考：本田圭佑、2分半の熱弁 「チームワークは生まれ持ったもの。個を磨くしかない」
今の我々（チーム）の状況
現状と課題
我々のチームはまだまだ伸びしろのあるメンバーで構成されています。
逆に言うと、まだまだ知識や技術が足りていない部分がたくさんあります。
- プログラミングスキル不足
- プロダクトの基盤技術、世の中の業界、界隈のトレンドなどの理解不足
- 問題解決のための思考力、知識、実行力の不足
当然これらは私自身にも言えます。
これらの課題意識をもち、継続的にレベル上げをしてくことで、
組織として強くなっていくだけでなく、メンバー個人が転職市場やエンジニア採用市場での価値を高め、社会に対し高いレベルで貢献できる人材になると考えています。
結果として、これが雇ってくれている会社への貢献、社会貢献、業界への貢献だと考えています。
こんなことを考えながら、以下では「やったこと」、「やっていること」を、私の考えや思いなどと絡めて紹介してみます。
やったこと（やっていること）
以前からいろんなチームで実施されていることもあれば、私がいたチームでは全くやっていなかった新しく導入したものもあります。今までのチームでもやっていたけど、解釈や目的を変えたものもあります。
デイリースクラム
弊社では、進捗確認になってることが多いです。
私がいたチームでもその傾向にありました。
ただどちらかというとそんな事は、ガントチャートや、タスクリストを適切に作ればわかるので、わざわざミーティングでやる必要はないと考えています。
そこで私は、後述するtrelloを使って、タスクのアサインと、順調じゃないタスクに対する問題解決の必要性を議論検討する場としています。
実際そんなに上手く行ってない気もしますが、毎日メンバーと話す時間、話せる時間を定期的に置いておく事で、燃え盛る前に手を打てる状態を作っています。
週次振り返り
週の初めに「今週はこれをここまでやりたい」という願望を宣言しておき、そこに対する到達点を共有する場を設けています。
厳密なスクラム開発、アジャイル開発にはなっていないのですが、1週間のスプリントを意識した仕組みにする事で、自分の仕事を見積もる訓練、癖づけを目的にしています。
また、1週間という大きすぎず、小さすぎないサイズにする事で、日々の工数の使い方や、スケジューリングがやりやすい期間で、将来的に3ヶ月、半年などの比較的長いプロジェクトをマネージするための訓練にもなります。
そして「先週はこんな問題があってやりきれなかったから、今週はこういう工夫をしてみます」のようにフィードバックループを短期間で回すことが出来ます。
これによりメンバーの成長を促しています。
One On One
最近ではどの会社でも普通にやられていると思います。
私も継続しています。最低週1回。
うまくできていない点は、いつもしゃべりすぎちゃうところです。
上司に当たる人間がしゃべるのではなく、部下に当たる人間が、できる限りいろいろな悩み、
頑張っていること、成し遂げたことなど公私関係なく吐き出せる場所にしておくことが重要だと思っています。
ただやはり、コミュニケーション能力がまだまだでイケてないのもあって、個人的には全然うまくやれていないというのが実感。
ペアワークタイム
チームメンバーをシャッフルして、主に開発に上がってくる問い合わせなどを題材に、
ペアで問題解決に取り組む時間を取っています。
自分よりできる人の所作を学んだり、後輩に気付きを与えるなど、双方向の学び、ティーチング、コーチングの場になっています。
ガイドラインとかは特に作っていません。
重点的にどういう取り組みをしてほしいかは各位に伝えています。
ネタがないときはペアプロとかやってもいいよとかも言ってます。
モブワークタイム
リモートワーク化で、振り返ればメンバーがいる、「ちょっといいですか」ができる、といった状況ではなくなり、意図的に「チームで仕事しているんだ感」を出していかないと、チーム内の連携とかも薄くなってしまうと考えています。
そこで普段はそれぞれのタスクをやっているメンバーが、週次で集まり、チームで一つのことに取り組む時間を確保しました。
内容は
- スキルマップ作製
- サブ知識の共有
- モブプロ（Junitライブコーディング会）
- アジャイルソフトウェア開発宣言の読みとき方を読んで感想を言い合う会（弊社では「あつ読み」と呼ぶ）
と、まだ4回ですが、やりたいことをストックして、そこから今週やるものを選ぶ方式にしています。
唯一の欠点として、私以外があまりがつがつしてないので、ネタが集まりにくい。
私が「モブワークタイムでそれやってよ」て言わないと、ネタが集まらない。
他人の工数を使って、自分の成長や能力強化の時間にできるという意味で、ちょうどいいサイズ感なのだけど、私の伝え方の問題もあるのかな？とは思っています。
One On Oneするとみんな口を開いて「あれできるようになりたい」「これやりたい」みたいなこと言うんだけどな。
「じゃあその時間使ってこういうことを継続的にやるとこういう能力伸ばせるよ！」とかもちゃんと伝えないとだめっすね。
※私は本やらなんやらで勝手に学んでるから、自分と違う人をマネジメントしたりコーチングする難しさは日々感じているところ。
ドキュメンテーション
各自で担当サブシステム新たにキャッチアップしていく過程で、
どうしても詰まったりすることはよくある話です。
そんな中でよくあるのが、
- 今のドキュメントイケてない
- そもそも無い
みたいなことがあります。
ここをチャンスととらえ、「今回学んだことをドキュメントに整理して、勉強会やってよ」と言っています。
理由は以下の通りです。
- 情報を収集しつつ関連情報まで探し集める（input）
- 実際に手を動かす（output1）
- 第三者に伝えるためのブログ（ドキュメント）や勉強会コンテンツとしてまとめる
結果的にそのドキュメントを作った人、勉強会で説明した人が最も成長すると考えているからです。
それと同時に、読んだ人、参加した人も、知識を増やすことができます。
trello
カンバンを使ってタスク管理を始めてみました。
理由は単純でUI的に使いやすいのと、手間がかかりにくい、ただそれだけです。
ドラッグアンドドロップでステータス管理できるのが最高です。
ただ、無料版しか稟議が下りていないため、一覧形式かつ双方向の同期を可能にしたGoogle Spread Sheetも作りました。
そしてこのSpreadSheetはガントチャートもインテグレーションしてます。
カンバンは操作性は卓越しているが、全部で何個あって、何個進んでいて、いつまでなのか？が一目で把握しにくいです。
そのため一覧とガントが欲しかったという感じです。
ちなみにまだ使いこなせてないです。メンバーが慣れていないんですね。
これからやりたいこと
変化をするには大きな障壁があります。
チーム内での考え方やコンテキストを埋めたり、今までの常識をいい意味で批判的にみることで、悪いところは改善し、世の中でいいとされていることはどんどん取り入れたいと考えています。
※記事執筆時点で考えていることだけ書きます。
ペアプロ＆モブプロ
うちのメンバーはお世辞にもシニアエンジニアとは言えません。
まだまだエンジニアとしてのコーディング力は全然足りないと思っています。
なので、モブプロ、ペアプロの時間を増やして、私の知識を伝えていくことをやりながら、
それぞれがメンターとして、後輩に伝えていけるように、能力強化をはかり、
合わせて、メンバー同士のペアプロ、モブプロもやりながら、
2人以上でリーダブルなコードを書いていくこともやれればとは思っています。
（マネージャー兼リーダー兼メンター兼ティーチャーはさすがにしんどいですね。）
スプリント&スクラム開発
そのままです。
うまくやれてないのでちょっとずつ寄せていきます。
まあまず弊社の開発プロセス的に完璧に振り切るのは現時点で難しい気もしていますが、
徐々に進めていきます。
参考：【保存版】スクラム初心者でも5分で総おさらい！スクラムの超重要単語と導入方法
最後に
まとまりのない文章で読みにくいかもしれませんが、
メンバーを成長させ、成果を出させる。それがチームや会社の成果になる。そのために働くのがマネージャーであり、マネージャーの仕事は進捗管理だけではない、あくまで一部である。
ということが伝わればよいかなと思います。
また、なんかその取り組み面白そうね！とかあればコメントとかいただけるとありがたいです。
（目新しいものはないと思うけど）