僕が何を考えて Management をしようとしているかについて、適宜 1 on 1 等でお伝えしておりますが、全員に同じ内容を伝えるのも飽きるので、文書として公開します。 (あと、1 on 1 で同じ内容を複数人に伝えると、後半の人のほうが話の内容が濃くなるし!)
会社の状態や、自分の状態によって、考え方や、やることは変わるから、まあなんかここに書いてあることは時々変わるかもしれません。
あとなんかよしおりが書いてたから真似して書こうと思ったけど、途中で飽きたので、途中から雑になっています。
僕は Engineering Manager / Architect として仕事をしています。 サービスの全体のアーキテクチャの整合性、誰にどのような仕事をしてもらうか、というようなことについて責任をもっています。
また、技術的な側面から、サービスを運用していくためのあれやこれやをやります。
そして、センター全体に関する仕事とか、会社全体の技術的なことに関する仕事とか、まあそういうのもぼちぼちやっています。
基本的に、各メンバーのスキルが上がるような仕事を振りたいと考えています。そのためには、その人がやったことがないような仕事を振りたいと考えています。 やったことあることだけを延々とやっていても人は成長しづらいものですからね。
僕個人は飽きっぽいので、いろんな仕事を体験したいと考えていますが、人によっては、同じ仕事をずっとやるほうが性に合ってるという場合もあるでしょう。 そういう場合については、言ってくれれば調整します。
チームワークは重要ですね。 Trust and Respect でやってくれ、というお達しを CTO からもらっているから、そういうふうにやっていければ良いと思っています。
僕が普段やっているのは以下のようなことです。
- 社内で今後利用しそうなツールの評価とか
- 中途社員の書類審査
- 中途社員のコーディングテストの評価
- 中途社員の面接(これはあんまやってない)
- 1 on 1
- 大きなプロジェクトのチームをまたいだアーキテクチャの設計とか
- Planner のお悩み相談を聞いたり
- 関連する wiki page のモニタリング。
- メンバーの github のアクティビティを眺めたり
- 業務がスムーズに回ってない場合に、他の部署との調整
- 社外向けのプレゼンとか。パネルディスカッションへの登壇とか。
- 技術勉強会に参加して、名刺を交換したり。。
他にもいろいろやってますけど、なんか細々としていて、忘れてそうなので、思い出したら追記します。
基本的にコードは書きません。プロトタイピングとか、なんかちょっとしたツールの開発しかしません。 実際にコード書いてみないとわからないことも多いので IDE を開いていることも多いですが、基本的には大したコードは書いていません。
僕がやっている仕事は「今日発生して明日までに仕上げる必要があり、かつ時間が5時間かかる仕事」みたいなのが多いので、締切がある仕事をやることが難しいからです。
コードレビューも基本的にしません。場合によってはやります。
業務用のチャットグループができた場合は僕を招待してください。招待してもらわないとなにか問題があったときに、サポートすることができません。 エンジニアが自分しかいないグループとかの場合は僕と合わせて席が隣の人とか、適当な人を何人か招待してください。自分が休みのときとかにサポートしてもらえたりするかもしれません。
個別チャットを Planner がやたらしてくる場合は、グループを作って会話するように依頼してください。
コードレビューは、必要なのでやってください。コードレビューは3つのぐらい役割があると思います。 「技術的知見の共有」「サービス全体を把握するため」「コードの品質を高めるため」とかそのへん。
基本的にコードレビューはコストがかかるので、コストを圧縮するように工夫をしましょう。
基本的に、残業はしないですめばしないほうがいいと思っています。 僕自身、この会社に入ってからほぼ残業していません(やっぽと飲みに行こうってことになっててやっぽの仕事が終わらないで待ってるときとかを除く)。
チームメンバーが残業せざるをえないような状況になるのは基本的にはマネージャーの敗北だと僕は考えています。残業しないといけないような状況になったときはマネージャーに相談してください。うちのチームは結構人数がいるし、全員が仕事でパツパツ、という状態にはならないようになっているので、誰かがヘルプに入ることが可能なはずです。
スケジュールは、マネージャーがざっくりとした見積もりを出すことも多いです。基本的に余裕をもって進められる期間プラスアルファで見積もりを出しているつもりですが、短いと思ったらいってください。 無理をする必要はないです（ダラダラやってていいという意味ではないです）。
基本的にソフトウェアの開発は、過去に作ったものをもう一回作ることがないので、いざ実際に作ってみたら時間がかかる項目が判明した! みたいなことは珍しくありません。 まあ、そういうもんですよね! なので、まあスケジュールを途中で伸ばすことは、まあしょうがない面があると思いますので、スケジュールに遅れそうな時は早めに言ってください。 締切のその日になってから「間に合わない! 助けて!」っていわれても何もできることがないです。
ただもちろん、同じ仕事をする場合、短いスケジュールで実装出来る人のほうが評価は上がりやすいです。
僕らのチームは B2B の開発を担当していますので、売上を最大化できることがまず第一の目標になります。 売上の向上を、技術的な面から支援していくことが僕らの役割です。
子供を保育園に連れて行ってから会社に来ているので、だいたい 10 時ぐらいには会社にいて、19時ぐらいに帰ります。 時々は保育園のお迎えを僕がしないといけない日もあるのでそういう場合は17時に帰る時もあります。
あと、GABA に行ってからくる時もあるのでそういう場合は昼ぐらいに来ます。
僕の予定は、時期によっては割と埋まってますが、適当に声かけてもらえればあけるので、声かけてください。
時代の趨勢的に、あんまチーム飲み会をゴリゴリ開催するみたいな風潮じゃないので得にマメに開催する予定はないですが、やりたい人がいたら幹事をしてくれたら参加はします。
一緒に飲みに行きたい人がいたら誘ってくれれば行きます。飲み会の誘いは基本的に断らないです。 サシでも大丈夫です。
あとはまあ、歓迎会はやります。
ランチは適宜いきましょう。サシとかだったら奢りでいいです。
人によって、今後はマネージャーになりたいと思ってる人もいれば、現場でコードをずっと書いていたいという人もいますね。 まあ、どっちも面白いことはあるし、辛いこともあるので、どっちが良いとも言えませんね。。
僕は自分がマネージャーになりたいと思ってなったわけではないですが、なんか流れでそうなりました。別に嫌じゃないのでやってます。 複数のプロダクトを見れるのは楽しいし、アーキテクチャの設計とかをメインでやれるのは楽しいですが、細かい部分についての議論に参加する暇がなかったり、実装をしている暇がないのは少しさみしくもあります。
この section には得にオチはありません。
基本的に、うちの会社ではマネージャーはそんなにすごい権限があるわけでもないし、社内のことも知らないことが多いので、わからないことがあったら室長に聞いてくれ! ってなることも多いです。まあそんなもんですね。
マネージャーじゃない人が思ってる以上に権限がないのが僕です。
1ヶ月に一回、30分から1時間程度やっています。
キャリアプランの話や、やりたいこと、やりたくないこと、人間関係、などなど。ざっくばらんに話しましょう。
進捗確認など、マネージャーのためにやる会ではなくて、メンバーのためにやる会です。
基本的には、オープンな雰囲気でやったほうが話やすいとおもうので、フリースペースでやるのが良いと考えています。 ただ、人がいるところでは話しづらい話もあると思うんで、3ヶ月に一回ぐらい、スタディブースでやることにしています。
スタディブースで話したほうが話やすいことがある場合には言ってください。
1 on 1 については、僕の時間があいたタイミングで突発的にやっています。 スケジュール入れてやると、そのタイミングまで話す内容を貯め込んでしまう可能性があっていやんだからです。
あんまり細かく口だすよりは、各人が権限をもってヤッたほうが良いと思うので、できるだけ口を出さないようにしています。 そのほうが各人の成長につながると思うからです。
ただし、新卒の場合やちょっと重荷かなーと思う場合には口を出しています。
このへんは、各人の好みとかもあるんで、調整していけばいいと思うので、やりづらかったらいってください。すり合わせをすることが可能です。
なんかこれ書くのに飽きてきたのでここで終わりです。 気がむいたら追記します。