32歳エンジニア・マネジメント論
はじめに
30歳の時に同じテーマで記事を書きました。
この記事から2年で組織や体制、僕自身の考え方なども少し変化があったのでまたこのテーマで記事を書いてみようと思います。
どういう人？
現在32歳。
30歳→32歳の間に子供が生まれ腰痛持ちになりました。
1歳8ヶ月の子供を日々腰痛と戦いながら抱っこしています。
現在社会人8年目のエンジニアです。
2年目: 6人チームのサブリーダーを約1年間経験
3年目: 3人チームのリーダーを約半年経験
その後も3人チームのリーダーを約1年経験
4年目: 1年間プレイヤー
5年目: 4人チームのリーダーを約1年経験
6年目: 10人チームのリーダーを任された
7年目: 人の入れ替わりがあり新卒がJOINして変わらず10人のリーダー
8年目: 人の入れ替わりがあり7人チームのリーダー
ここ数年はリーダー役職での仕事がほとんどでした。
自身がコードを書くというよりは、レビューや相談・チームの方針決めなどが大半の役割でした。
はじめに結論
結論は2年前から変わっておらず、「マネジメント方法に絶対的な正解はない」
その都度チームのメンバーや状況に応じて最適な方法を模索する必要がある、と思っています。
以下で論じているのは僕はこう思っているよっていう考え方です。
マイクロマネジメントについて
2年前の記事では「絶対悪」として取り上げましたが、少し考え方が変わりました。
結論で述べている通り、絶対的な正解がないということは逆に言うと絶対的な悪もないということなのではないか？と思うようになりました。
チームリーダーを長く務めていて、メンバーの入れ替えも多くありました。
色んな人と仕事をしてみてマイクロマネジメントが有効なメンバーも一定数いることが分かりました。
マネジメント論
まず全員にニュートラルに接します。
はじめは誰がどの程度デキるか、どういうキャラクターなのは不明なので平等に等しく接します。
一緒に仕事をしていく中で
「あ、こいつデキるな？」
「あ、こいつデキないな？」
という瞬間が度々訪れます。
僕の場合は以下をよく見ています。
・問いかけに対するレスの早さ
・受け答えのハキハキ具合
・「誰かやってください」というallメンションへの反応
・割り振った仕事の完了の早さ
・抽象度の高いタスクを振ったときの動き
・プルリクの質（指摘の少なさ等）
・当たり前をちゃんとやってるか（遅刻しない、MTGの時間守る等々）
このあたりは一緒に仕事をしていると徐々に見えてくるため、段々とメンバー各自の能力やキャラクターが見えてきます。
特に「抽象度の高いタスクを振ったときの動き」これは顕著に差が出ます。
デキるやつはタスク分解が上手く、抽象度をどんどん下げていき具体的なタスクへと落としていきます。
そのために必要な情報は自分で調べるし、決めや判断が必要なものはリーダーに聞いて固めていけます。
デキないやつは抽象度が高いままタスクに着手し、2,3日経ってから「進んでません」「よく分かりません」と言ってくる印象です。
最優先なのは「デキるやつ」は絶対に粗末に扱わないこと。
デキるやつは大体雑に仕事を振っても上手くタスクをこなしてくれます、だってデキるやつだもの。
ただデキるやつだって人間です、嫌なことだってやりたくないことだってあるでしょう。こういう人材は本当に貴重なので丁寧に扱い、重要度の高い絶対失敗したくないタスクを振るのが良いでしょう。もちろん本人の意思やモチベを確認しつつ。
「デキないやつ」に関しては粗末に扱って良い訳ではないですが「デキるやつ」よりは優先度が下がります。
ここで意識しなければならないのは「デキないやつ」は今デキないだけで、今後デキるようになる可能性があるということ。
この扱い・マネジメントが非常に難しい。
ここからは教育の領域も含みますが以下のことを意識しています。
・アウトプットさせる
・難易度の低いタスクで数をこなし経験を積ませる
・デキるやつのコードをレビューをさせる（質の良いコードを読ませる）
・朝礼等で毎日タスクの進捗確認（困ってることの確認）
「朝礼等で毎日タスクの進捗確認」
これに関してはマイクロマネジメント寄りですね。
僕自身マイクロマネジメントは苦手で嫌いなのですが、かといってちゃんと細かく見ていかないと上手く回らないケースもあるため必要だなと思っています。タスクを任せて1週間後に何も進んでおらず「なんで聞かないの？」みたいな、マネジメント記事でよくネタにされるダメ上司の典型みたいなこともよくありました。これはもちろん本人が分からないことを人に聞かないというダメな部分もありますが、リーダー側の「任せすぎ」というダメな部分でもあります。
少し話が脱線しますが、つい最近そーだいさんが弊社で講演をしてくれました。
この時も非常に有益で勉強になるお話をしてくださったのですが、僕が好きな言葉はこちらです。
プレイヤーの本質は問題解決
マネージャの本質は問題提供
つまりマネージャ（リーダー）がそのプレイヤーの能力やレベルに合った最適な問題を提供してあげること、これがマネージャの本質であるということ。これを聞いたときに大変感銘を受けました。
それまでは「デキるやつは勝手にタスク分解してやってくれるしデキないやつはそれができないから使えない」みたいな認識だったんですが、プレイヤーができるタスクの粒度にしてあげるのがマネージャの本質なんだなぁと考えが変わりました。
なので「デキない」のは「そのタスクの粒度だとデキない」のであって、悪いのはどちらかと言うとマネージャ側。デキる粒度に落とし込んでタスクを振る必要があるのだと理解しました。この考えに至ってからはマイクロマネジメント寄りのことも場合によってはやるようになりました。ほぼ僕が実装したやんけ、みたいなことも稀にありますがそうやってデキないやつをデキるようにしていくのも立派なマネジメントなんじゃないのかなぁ…と。
スクラムの話
ちょっと話は変わってプロジェクトの進め方について。
この2年でプロジェクトの進め方の見直しを行い、スクラムで行うようにシフトしています。「流行ってるから」「なんか良いらしいから」という理由で始めており、本は一応読みましたが見よう見まねと言った感じで日々四苦八苦しながら進めています。朝礼での困ってることの確認もデイリースクラムの立ち位置として始めたことです。
スクラムについてまだまだ分からないことだらけで間違った進め方をしてる部分もあるとは思いますが、やっていて本質的に少し分かったことがあります。それは
なんかスクラムって週間連載みたいだなぁ
ってことです。
あ、僕は週間連載したことはありませんけどね。
週刊誌で連載している漫画家さんってすごいなと思っていて、毎週必ずリリース（コミット）があるんですよね。
これってなんでできるのかって言うと「毎週」っていう区切りがあるからなのかなと思っていて、これが「今回は2日後」「次回は10日後」とかってなると逆にスケジュール立てづらいんじゃないかなーと。
僕のチームは2週間をスプリントの期間としているんですが、この2週間が締め切りで2週後には読者に漫画を届けるが如く、コンスタントにコミットしていくことがスクラムの本質なんだろうなぁと。
まだまだスクラムのいろはは分かってないしやり方も間違っている部分も多々あるとは思いますが、2週間でスプリント切ってからは毎回必ず何かしらのコミットはあるし、2週間でタスクを切っているので進捗感もあるし、良い感じだなーと感じています。
僕自身は開発することは少ないので担当編集者の気持ちでメンバー（作家さん）に「原稿まだっすかねぇ」って毎朝聞く役割になってます。メンバーが方針で困っていればそれこそ編集の如く「じゃあこういうストーリー（方針）でいきましょう」ってアドバイスしてますね。
この考え方にしてからはスクラムというプロジェクトの回し方が少し分かったような気がしています。（違うかもしれませんが）
まとめ
2年前と同じテーマで記事を書いてみましたが、考え方も変わっているし環境ややり方も結構変わっているなと改めて思いました。
定期的に自身の仕事に対する考え方をアウトプットするのは大事ですね👍
技術的なアウトプットが年々減っているので、こういうマインドやマネジメント手法などの方面のアウトプットを頑張るように意識していこうかな（技術は技術で頑張らないと）
それでは良いお年を😁
この記事が気に入ったらサポートをしてみませんか？