僕が何を考えて Management をしようとしているかについて、まだあまりお伝えする機会が少ないのですが、自身の考えを整理するためにも、文書として公開します。 (あと、1 on 1 で同じ内容を複数人に伝えると、後半の人のほうが話の内容が濃くなるし!)
会社の状態や、自分の状態によって、考え方や、やることは変わるから、まあなんかここに書いてあることは時々変わるかもしれません。
あとなんかよしおりが書いてたのをひろむが真似してたから真似して書こうと思ったけど、途中で飽きたので、途中から雑になっています。
僕は Engineering Manager として仕事をしています。 サービスの全体のアーキテクチャの整合性、誰にどのような仕事をしてもらうか、新規で出す feature の妥当性や、さらなる良い施策を考える、というようなことについて責任をもっています。
また、技術的な側面から、サービスを運用していくためのあれやこれやをやります。
基本的に、各メンバーのスキルが上がるような仕事を振りたいと考えています。そのためには、その人がやったことがないような仕事を振りたいと考えています。 やったことあることだけを延々とやっていても人は成長しづらいものですからね。
僕個人は飽きっぽいので、いろんな仕事を体験したいと考えていますが、人によっては、同じ仕事をずっとやるほうが性に合ってるという場合もあるでしょう。 そういう場合については、言ってくれれば調整します。
チームワークは重要ですね。 Trust and Respect でやってくれ、というお達しを CTO からもらっているから、そういうふうにやっていければ良いと思っています。
サービスの特定の開発部分に属人性を持たせると、結果的にエンジニア側も休めなくなったり開発速度が落ちて全体の成果としてはマイナスになるので、新規 feature 開発時には主担当に設計やメインの実装をしてもらいつつ、バックアップメンバーをよきに計らって担当してもらっています。 (過去に何度か属人性が高い状況があり、その時の反省を活かすようにしています)
今の僕のケースでは、他のチームの開発メンバーにもタスクをアサインする時もありますが、上記のポリシーを優先して、自分のチームと他のチームを分けて考えることなく等しく知見がシェアされやすいようにタスクをアサインしています。
基本的には物凄くゆるいスクラムを導入して開発を進めています、週一のスプリントを区切り、週一の会議を行って進捗を ticket をみんなで見ていく方式です。基本的に全体の ticket の視覚化は週一で行いますが、開発の状況などは適時変わっていくので、タスクの再分配などを必要があれば即時に行うようにしています。
また全員のメンバーが抱えてる大きなタスクを視覚化して、将来的に発生するタスクのアサインを検討したり Planner 側に開発する時間がどのくらい存在しているかを共有するために、物凄くシンプルにしたタスク管理表とかを作る試みを始めました。行に月の上旬下旬ごとに分けて列にメンバーを置いて中規模以上の粒度のタスクをセルに並べていきます。同時に誰がどの開発をリードしているかも見えるようにしておきます。これは伝言ゲームが多発するのを防ぐ側面もあります。ガントチャートだとメンテ出来る気がおきませんが、これならきっとメンテ可能なんじゃないかと思ってるところです。
僕が普段やっているのは以下のようなことです。
- 社内で今後利用しそうなツールの評価とか
- 中途社員の書類審査
- 中途社員のコーディングテストの評価
- 中途社員の面接
- 1 on 1
- 大きなプロジェクトのチームをまたいだアーキテクチャの設計とか
- Planner のお悩み相談を聞いたり、新しい企画にアイディア出したり
- 関連する wiki page のモニタリング。
- メンバーの github のアクティビティを眺めたり
- 業務がスムーズに回ってない場合に、他の部署との調整
- 他の部署の人から相談されたよろずごとの対応とか
- 社外向けのプレゼンとか。
- 技術勉強会に参加して、名刺を交換したり。。
他にもいろいろやってますけど、なんか細々としていて、忘れてそうなので、思い出したら追記します。
基本的にコードは書きません。プロトタイピングとか、なんかちょっとしたツールの開発しかしません。隙をみては TODO で積まれていたり、早めに実装しておいた方が良いけど基本的に優先度が低いタスクくらいしかやりません。 実際にコード書いてみないとわからないことも多いので IDE を開いていることも多いですが、基本的には大したコードは書いていません。
普段は、コードを書き始める前に行うサービス設計や方針などを決める話し合いやら調査やらを行っており blocker になり得るタスクを持つと迷惑をかけるので自重して居ます。
コードレビューも基本的にしません。場合によってはやりますし、 diff が20行以下くらいだったら気がつきベースでやってます。
業務用のチャットグループができた場合は僕を招待してください。招待してもらわないとなにか問題があったときに、サポートすることができません。 エンジニアが自分しかいないグループとかの場合は僕と合わせて席が隣の人とか、適当な人を何人か招待してください。自分が休みのときとかにサポートしてもらえたりするかもしれません。
個別チャットを Planner がやたらしてくる場合は、グループを作って会話するように依頼するか、勝手にグループ作って呼んでください。問題が出たら僕が出て怒ります。
あと僕もなるべく僕の上司を呼ぶようにしていますが、忘れがちなので「あ、こいつ自分の上司呼んでないな！」と思ったら気にせず招待しといてください。今の上司に隠すようなことはほぼほぼ無いので。
コードレビューは、必要なのでやってください。コードレビューは3つのぐらい役割があると思います。 「技術的知見の共有」「サービス全体を把握するため」「コードの品質を高めるため」とかそのへん。開発メンバーが多いので、一貫性をなるべく保つ努力はして欲しいところです。
基本的にコードレビューはコストがかかるので、コストを圧縮するように工夫をしましょう。
基本的に、残業はしないですめばしないほうがいいと思っています。 (ひろむに残業させてるのは年に2回あるかないかのはずや。。)
チームメンバーが残業せざるをえないような状況になるのは基本的にはマネージャーの敗北だと僕は考えています。残業しないといけないような状況になったときはマネージャーに相談してください。
スケジュールは、マネージャーがざっくりとした見積もりを出すことも多いです。基本的に余裕をもって進められる期間プラスアルファで見積もりを出しているつもりですが、短いと思ったらいってください。 無理をする必要はないです（ダラダラやってていいという意味ではないです）。
基本的にソフトウェアの開発は、過去に作ったものをもう一回作ることがないので、いざ実際に作ってみたら時間がかかる項目が判明した! みたいなことは珍しくありません。 まあ、そういうもんですよね! なので、まあスケジュールを途中で伸ばすことは、まあしょうがない面があると思いますので、スケジュールに遅れそうな時は早めに言ってください。 締切のその日になってから「間に合わない! 助けて!」っていわれても何もできることがないです。
ただもちろん、同じ仕事をする場合、短いスケジュールで実装出来る人のほうが評価は上がりやすいです。
僕らのチームは人に楽しんでもらうサービスの開発を担当していますので、利用者の良い体験を最大化できることがまず第一の目標になります。 体験の向上を、技術的な面から支援していくことが僕らの役割です。
基本的には午前中には出社していますが、調べごとやらに時間がかかると少し遅れることもあります。
僕の予定は、時期によっては割と埋まってますが、適当に声かけてもらえればあけるので、声かけてください。
時代の趨勢的に、あんまチーム飲み会をゴリゴリ開催するみたいな風潮じゃないので得にマメに開催する予定はないですが、やりたい人がいたら幹事をしてくれたら参加はします。
一緒に飲みに行きたい人がいたら誘ってくれれば行きます。飲み会の誘いは基本的に断らないです。 サシでも大丈夫です。
あとはまあ、歓迎会はやります。
ランチは適宜いきましょう。サシとかだったら奢りでいいです。
人によって、今後はマネージャーになりたいと思ってる人もいれば、現場でコードをずっと書いていたいという人もいますね。 まあ、どっちも面白いことはあるし、辛いこともあるので、どっちが良いとも言えませんね。。
僕は自分がマネージャーになりたいと思ってなったわけではないですが、なんか流れでそうなりました。別に嫌じゃないのでやってます。 複数のプロダクトを見れるのは楽しいし、アーキテクチャの設計とかをメインでやれるのは楽しいですが、細かい部分についての議論に参加する暇がなかったり、実装をしている暇がないのは少しさみしくもあります。
この section には得にオチはありません。
基本的に、うちの会社ではマネージャーはそんなにすごい権限があるわけでもないし、社内のことも知らないことが多いので、わからないことがあったら室長に聞いてくれ! ってなることも多いです。まあそんなもんですね。
マネージャーじゃない人が思ってる以上に権限がないのが僕です。
1ヶ月に一回、5分から1時間程度やっています。まだ毎月できてないので6月から頑張る。。
キャリアプランの話や、やりたいこと、やりたくないこと、人間関係、などなど。ざっくばらんに話しましょう。
進捗確認など、マネージャーのためにやる会ではなくて、メンバーのためにやる会です。
スタディブースで話したほうが話やすいことがある場合には言ってください。
1 on 1 については、僕の時間があいたタイミングで突発的にやっています。 スケジュール入れてやると、そのタイミングまで話す内容を貯め込んでしまう可能性があっていやんだからです。
あんまり細かく口だすよりは、各人が権限をもってヤッたほうが良いと思うので、できるだけ口を出さないようにしています。 そのほうが各人の成長につながると思うからです。
ただし、ちょっと重荷かなーと思う場合には口を出しています。
このへんは、各人の好みとかもあるんで、調整していけばいいと思うので、やりづらかったらいってください。すり合わせをすることが可能です。
Server side member 向けに特化した文章になってて Client side member 向けのことが書ききれてませんが、コピペ元を少し手直ししたくらいしか書けてないので一旦ゆるしてください！ごめんなさい！そのうちブラッシュアップします！