この記事の内容は古くなっており、飯塚の現在の仕事とは異なります。資料のために残しています
この記事は LeapMind Advent Calendar 2019 4 日目の記事です。
CTO が「マネージャには Manager README を書いてほしい」とつぶやいていたのを見て、自分がマネジしているチームのチームメンバに向けて書いたものです。社内向け情報については一部削除しました。
以下 Manager README
Manager README - Kentaro Iizuka
この文書は私（飯塚）がマネージャとして、どんな仕事をしているのかを記載したものです。私たちのチームでの仕事の進め方についてもふれています。
役割
私は今の所 2 種類のマネージャを兼任しています。ひとつが皆さんのキャリアグロースやプロジェクト外の課題について一緒に解決していくピープルマネージャで、もうひとつがプロジェクトの遂行に責任を持つ、プロジェクトマネージャ (PM) です。ここでは混同しないように PM と言います。言い換えれば、 人 と プロジェクト の別軸のマネジメントを同時に行っています。これらの役割はゴールがやや異なります。
マネージャ
2 種類のマネジメントの仕事のうち、マネージャの仕事のほうが優先度が高いです。私には、皆さんとキャリアグロース、ライフワークバランス、ハラスメント、仕事環境などについて話し合い、対策を実施する責任があります。これらについて、主に、 1 on 1 を通して話し合います。
1 on 1
1 on 1 はチームメンバーとマネージャーの雑多な話し合いの場です。1 on 1 はチームメンバーのための時間です。基本的に、毎週か隔週 30 分設定しています。1 on 1 では、以下の項目のようなことも話しますが、参考までです。話したいと感じることを何でも話してください。また、配属されてしばらくは話したいことが多い時もあり、1 時間設定することもあります。
キャリアグロース
ソフトウェアエンジニアもしくは機械学習エンジニアとして、どういったキャリアを歩みたいと考えてるでしょうか。組織に対してどういった貢献をしたいでしょうか。長期目標はしばしば変動しますし、いつでも変更可能であるべきです。しかしこれらのゴールに向けた行動の指針を考えることは、常に一歩先に進み続けることを可能にするもので、重要な意味があると考えます。 長期のキャリア展望は今の仕事と関係なくても問題ありません。どういうキャリアを歩みたいか、一緒に考えたいと思っています。また、キャリアをひとつに絞る必要はありません。
ソフトウェアエンジニアとしてのレベルアップ
いまのところ、私達のチームはソフトウェアエンジニアリングが主たる仕事です。そのためすべてのメンバーに、ソフトウェアエンジニアとしてレのベルアップ も 目指してもらいたいと思っています。いま、会社では （具体的なレベル数を削除） までのソフトウェアエンジニアのレベルを定義しています。これは、プログラミング能力や専門知識、自律性、アウトプットのインパクトなど様々な軸に従って考えられたものです。このレベル定義は、会社が設定した評価軸ではあるものの、一般性が考慮されており、社外のソフトウェアエンジニアとしての評価と大幅な乖離がないように設計されています。私はチームメンバーに常にひとつ上のレベルを目指して行動してもらいたいと思っています。自分も意識して仕事をしていきます。
人事評価
（人事評価については社内向け情報が含まれるため削除しました）
フィードバック
フィードバックは、人事評価の時だけではなく継続的に行います。1 on 1 で話すこともありますし、別途不定期にミーティングを設定することもあります。
ワークライフバランス
プライベートの時間を十分にとれることは、いい仕事をするための必要条件です。なので、しっかりと自分の時間を持ってほしいと思っています。 もし仕事によってプライベートの時間を十分に確保できていないと感じたときはご相談ください。皆さんの所属するワーキンググループのリーダーや、さらに組織階層が上の人に、私から話してみることもできます。それによって皆さんの評価が下がることは絶対にありません。 場合によってはリモートワークをしたいと思うかもしれません。リモートワークは社内制度化されていますので、制度にのっとって手続きをお願いします。基本的に許可しています。
PM
私のもう一つの仕事は PM で、プロジェクトの進行に責任を持ちます。プロジェクトの進行を健全に保つため、以下のような仕組みを使っています。
OKR
OKR は、組織の中で目標の統一性を持たせるためのツールです。OKR については、Google Re:Work のページ を見るか、 "Measure What Matters" のような本にも詳しく書いてあります。また、 "How Google Works" の中でも触れられています。 重要なことは、OKR によって四半期ごとに事業部及びチームの目標が設定され、OKR によって定められた項目に従ってチーム内で注力すべきことが一目瞭然であるということです。なにはともあれ、チームの OKR を見てください！ そこにはそのチームが今の四半期に何を目標に何に取り組んでいるか簡潔に記載されています。また、OKR はしばしばストレッチゴールを含みます。
Design Document, Design Review
私達のチームでは、能動的に仕事を進める能力を重視します。
ソフトウェアエンジニアが組織内で能動的に仕事を進めるための方法のひとつが Design Document です。一ヶ月以上かかるような中〜大規模の仕事をする場合、その仕事の背景や実装法を簡潔に記した Design Document を書いてもらいます。なぜならば、大きな仕事は影響範囲が大きく、関係者やシニアエンジニアによるデザインへの合意が必要だからです。Design Document の例は社内にたくさんあります。オンライン上で閲覧できるようになっているので、場所を訪ねてみてください。デザインがない仕事は、迷走しがちです。
Design Review は、個別のデザインについて議論し、合意を得るためのミーティングです。Design Review は週一回開催され、誰でも参加できます。チームごとではなく、会社でひとつの Design Review 会があります。基本的には、議論されるデザインに関連するメンバと、各エンジニアリング部門のマネージャ、シニアエンジニア、CTO が参加します。Design Review では、執筆者がデザインを簡潔に説明します。そしてその場で議論を行い、ブラッシュアップします。
コードレビュー
コードレビューは重要です。コードレビューがボトルネックになることは避けたいのでので、私達のチームではレビュー待ちの Pull Requst について Slack で通知するシステムを運用しています。もしコードレビューを依頼されたら、ミーティングを除いて高い優先度でレビューをお願いします。もし時間がかかりそうな場合は、Pull Request にいつレビューするか記載してください。
私達のチームのコードレビューでは、コードのオーナーによる Ownership Reviewer とプログラミング言語別の Readability Reviewer の両方のレビュアから Approve を得る必要があります。コードレビューシステムについては別途ドキュメントがあります。
飯塚の働き方について
勤務時間
私は 09:00 - 18:00 の間で比較的規則正しく勤務しています。この間で Google Calendar 上に空きがあれば、いつでも予定を入れてもらってかまいません。
ミーティング
私のカレンダーを見て、お好きな時間にミーティングを設定してください。多くのミーティングに出席するので、カレンダーが埋まりがちですが、気にせず設定していただいて問題ありません。
リモートワーク
通勤電車のストレスを軽減するため、早朝と夕方リモートワークをしています。また、週に一日程度フルリモートで仕事をしています。リモートワークはにしています。リモートワーク中にも相談事などのミーティングの予定をいれてもらって大丈夫です。リモートでのミーティングには Hangout を利用します。
音楽鑑賞
私は音楽がたいへん好きで、空きあらば音楽を聴いています。
そのため、イヤホンやヘッドホンで音楽を聞きながら仕事をしていることが多いです。これは話しかけないでくださいという合図では無いです。モニタの前で手を振るか Slack で mention するなどして、気軽にいつでも話しかけてください。もし私が音楽を聴きすぎだと思う場合、こっそり教えて下さい。
Manager README ここまで
改めて見直してみると、どうも一般的なことを言い過ぎているきらいがあるような感じがしますね。もう少し内容を絞ってもいいのかもしれない。
最後に、LeapMind ではソフトウェアエンジニアを通年採用しています！ 興味を持たれた方はぜひ 募集職種のリスト を御覧ください。
