20
19

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

【デブサミ2023レポート】開発マネージャー1年目が語る、開発マネージャーのお仕事

Last updated at Posted at 2023-02-18

Developers summit 2023に登壇してきたのでレポートがてら、まとめ記事を投稿しようかなと思います。
合わせて、喋り足りなかったことなどは補足しようと思います。

概要

紹介ページ

Code Zine

発表資料

内容

今回は私がマネージャー歴1年ということで、1年目だからこそ話せる内容にフォーカスしようと思いました。
あまりにも視座が高すぎると「マネージャーってなんかすごい人」とか「自分は到底無理だ」と思われかねないなぁと思いました。
そこで以下のような内容にしました。

  • マネージャーになる以前から、自らの仕事の質を高めるためにやってきた色々なアクションプランを紹介すること
  • アクションプランをマネジメントで活用・応用して、チームマネジメント、プロジェクトマネジメントしていること
  • それが発展途上ではあるものの「なんだかんだやれてるし、うまくいきつつあるよ」ってのを見せること

結果的に、新人からベテランまで使えるアクションプランの紹介ができ、マネジメントを志す若手の背中を後押しするような内容に出来たのではないかと思っています。

発表の内容

ここからは話したことをざっくり書き出します。※アーカイブがあれば見たほうが良いかもです。

発表のゴール

発表の目的やゴールを話しました。

  • なりたい、やってみたい、やれるかもと思う人を1人でも増やすこと
  • ずっとやってきたことがマネジメントでも支えになっていることが伝わる

リモートワークが普及し、マネジメントに対する意欲が低下しているらしいことと、難易度が上がっていることが個人的には大きな課題だと思っています。
そこで、なにかやれることが無いか考えたときに、マネジメントで使うスキルがプレイヤー、IC1で使うスキルと比較し非連続的でないものも結構あることがわかれば、ハードルは下がるだろうと思いました。
さらに、マネジメントとして自分のやってきたことをうまく活用し、チームが成長軌道にのり、上手くいきだすと超絶面白いということが見えれば、エンジニアとしてシステム作ったり、インフラ組む以外にも面白い仕事があるということが伝わるのではないか?と思いました。

マネージャーになるまでの経緯

マネージャーになる話をもらったところから、チーム発足(開始)までの間にやったことなどを話しました。

  • キャリアの中で、チームを持ってマネジメント経験を持っておくべきと昔から思っていたので、断る理由が何もなかったこと
  • 本読みまくったこと
  • どういうチームにしたいのか、何を目指すのかを定義したこと

話の中で、本をいくつか紹介したのですが、著作権絡みで表紙を使えなかったので、ここで貼っておきます。

WHIのプロダクト開発とチーム発足

私の所属組織はどのような領域を担当し、どのような仕事があるのかを簡単に紹介しました。
その後、私個人の状況、チームの状況がやばい状況だったことを、実際に観測した情報や事実ベースで話しました。

マネージャーになってからの気づきと支え

ヤバい状況をどう変えていこうか考えた際に、今までやってきたことを上手く個人→チームと応用することを考えました。
その際に特に伝えたかったネタをピックアップして話しました。

工数を計測すること

メンバー時代の2018年頃から工数を秒単位で計測できるTogglを利用して工数を計測し始めました。
スタートボタンと停止ボタンを押すだけで計測可能。
Projectとtagを事前に登録しておけば、チケット番号をDescriptionにかくだけでコストを掛けずに計測可能です。
粒度は結構細かくて、概ね以下のような感じです。(一部抜粋)

  • 機能開発・機能改善・機能強化(これらをチケット単位で計測)
    • カタログ2作成
    • 設計(基本・詳細)
    • 実装・テスト(コーディング)
    • 打鍵テスト観点・ケース作成
    • 製品観点作成
    • Review準備・Review(MTG形式のもの)
    • 機能マニュアル作成・リリースノート作成
    • その他
  • 不具合修正(これらをチケット単位で計測)
    • 不具合再現・原因調査
    • 実装・テスト(コーディング)
    • 打鍵テスト観点・ケース作成
    • 機能マニュアル修正・リリースノート作成
    • Review(MTG形式のもの)

これにより

  • 自分がどこに時間がかかっているのか
  • 改善できる部分はないのか

などを振り返るための客観的な数字がえられます。
また2年くらい継続することで、自分のパフォーマンスが可視化され見積もり精度があがります。

TODOを逆算して分解すること

世の中のすべての問題解決は、すべてここに帰着できると言っても過言ではないと思っています。
大小問わず、細かく区切って、マイルストーンを定義する。合わせて工数も見積もる。

結果として進捗も可視化され、適切な粒度であれば日々何かしらが閉じられprogress barが進んでいく感覚が得られ、
モチベーション維持に役立ちます。

そして、デカくて難しいものを正面突破するのではなく、
戦略と思想を持って、小さい単位に崩すと言う作業を経て、あとは1個ずつ順にサクサク高速に倒す。
大規模開発でも、家事でも考え方は同じにできるはずです。

ここのスキルは、マネージャーとか関係なくすべての人に持ってほしいと思って話の内容に含めました。

優先順位付けをすること

マネジメントのもっとも重要な仕事の一つ、
「やるもの」「やらないもの」を決め、
「何からやるか」を決める仕事があります。

その一つの例として「1日の仕事をどのように設計するか」を私の考えをもとに話しました。
マネジメントをやると必ず必要なスキルですが、マネジメント以外は出来なくてもいいかというと、そんなことはないです。
アサインされたタスクをもれなく無駄なく確実に進めるためには必要なスキルです。

幸い、WHIは渋滞を起こすくらいタスクが次々に発生するのでこういうスキルが無いとやっていられません。

2番目に踊ること

いきなり何かを企画したり、自力でなにかを成し遂げるのはムズいので、
誰かが企画したものに乗っかることで、中身だけでなく、方法論、集客方法などを学ぶことができます。

それをもとに、自らが企画者として、自身のアウトプットの機会を生み出すことが出来ます。
これはアクティブラーニングの中でもっとも効果のある「人に教える・自ら体験する」ということになるので、企画した人が最も成長します。
そして組織にとっては、それを連鎖させ、規模拡大だけではなく、同時多発的にあらゆるところで発生することにつなげることが出来ます。

日々コツコツやり確実に成長するためのアクションプラン

  • 仕事意味付けと、24時間以内のアウトプットを伴った復習
  • 改善点(成長点)のTODO化

に付いて話しました。
こちらは詳細に資料に記載しているので御覧ください。

想っていること考えていること

チームをマネジメントする者として

  • チームの成果を最大化、最速化したい
  • 隣のチームに負けたくない
  • 自分を追い越していく、匹敵するメンバーと仕事したい
  • 「今までの自分の成果×人数」以上の成果を常に出したい

を常に考えており、そのために「メンバー各位が成長し続けられるように、メンバーが成長し活躍できる機会を作り出す」ことを意識したマネジメントをしています。

「ティーチング」よりも「コーチング」、つまり「教える」よりも「気づかせる」。
やらされ仕事だけができるようになっても10年後20年後、人材価値としては平凡なものにしかならない。
抜きん出るためには、自分の頭で考え、自発的に行動をおこし、問題解決できる人材である必要があると考えています。

そのため、新人だからとかベテランだからとか関係なく、
とにかく試行錯誤の機会を大量にあたえ、自分力で方法論を考え、解決策を見つけ出し、解決していくようにサポートや助言をしています。
その過程でのつまずきや失敗はつきものなので、絶対にやってはいけないミス以外は、謝れば済むので、
どんどん失敗して「あーこれじゃダメなんだ」「これは無駄なんだ」と自分で感じ、改善するアクションを自発的に起こせるように、
物によっては、あえて手を差し伸べず転ばせることもあります。

そういうマネジメントを心がけています。

感想

本番はとてつもなく緊張していて、ペース配分もミスって最後巻く形になりました。
ただ、いい機会をいただけたなと思っています。
WHIの広報やProduct Div. のDMOのメンバーには感謝するとともに、
リアルタイムで見てくれた方、アーカイブ(多分まだ出てない)でみてくれた方、資料読んでくれた方
ありがとうございました。

  1. Individual Contributor

  2. WHIの機能開発時に作成されるメリットベースのプロダクト(機能)の企画書

20
19
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
20
19

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?