![見出し画像](https://assets.st-note.com/production/uploads/images/68408635/rectangle_large_type_2_2ef9711837f7d56aa50affc35426d94d.png?width=1200)
マネージャになって3年経った所感
※技術的な内容は出てきません。ただの感想文です。
年末ということで1年の振り返りをしてみようと思ったのですが、そもそも今まで振り返って文章に起こすことをしてこなかったので少し範囲を広げてマネージャになって3年経過した今の気持ちを書いておきます。
マネージャといってもプレイングマネージャですし、n = 1 なので「マネジメントとは」みたいな話はできません。あくまで経験を振り返った感想です。
ざっくり言うと「そう上手くいかないものだ」というのが素直な感想です。
マネージャになった経緯
今の会社に中途入社して1年も経たないうちに自分から「自分のチームを持ちたい」「マネージャになりたい」と声を上げてきました。何を思って声を上げていたか……当時の気持ちです。
30代になったので経験の幅を広げたい
自分が「良いプログラム」を指導していけばスキル水準を上げられる
マネジメントの難しさを知りたい
すいません、3つ目はちょっとキレイな言い方しました。ストレートに言うと「マネジメントできている人に出会ったことがない。みんななんでそんなにマネジメントができないのか、自分ならもう少し上手くできるんじゃないか。」というのが本音です。
声を上げていればチャンスはいただけるものですね。当時の私の直属の課長が推薦してくれたのがきっかけでWEBチームのマネージャになりました。
※WEBチームは当時マネージャ不在でした。
自分の中で成長したところ
もともと「人間はミスをするもの。ミスを無くす仕組み、ミスに気づける仕組みを作らなければならない」とは思っていました。その考えが強化された気がします。
初めの頃は、仕組みにするためには原因を明らかにする必要があると思っていました。そのため、どうしても「どこでミスが発生したか」「どういう経緯だったか」という過去にフォーカスを当ててしまいがちでした。これは責めているつもりがなくても相手の罪悪感を強め、委縮させてしまいます。
それよりも「ミスした結果にどう対処するか」「今後どんな仕組みで防ぐか」と、あくまでも未来にフォーカスを当てる接し方ができるようになってきました。ただ切り口が違うだけではありますが、それが重要だと実感しました。
やったこと
ソースコードレビュー導入
単体テスト導入
仕様レビュー
GitHub導入
Slack導入
ソースコードレビュー
GitHub(当初はGitBucket:非BitBucket)でGitHubフローでコードレビューもしました。1年以上のあいだ私しかレビューしてなかった……
単体テスト導入
弊チーム以外は基本的にC++を使用しているのですが、品質に悩みつつも「IDEが古くて単体テストに対応していない」という惨状です。弊チームではC#、VisualStudioを使用しているためテストコードを書くようにしました。今のところ実行は手動ですがGitHub Actionsも使いたいところです。
仕様レビュー
これは社内の開発フローとしてマネージャの役割だったので。頻繁にちゃぶ台返しが起きるので回避するためのテクニックをメンバーに伝授していました。
GitHub導入、Slack導入
当初、ソースを外部へ預けるのはNG、チャットアプリもNG。チャットアプリは雑談をしたりコソコソと会社批判、個人批判をする人がいるから、と。
どうにか打開できないかと策を練り続けた結果、「オフショアに開発を一部外注化する」という名目で契約を推し、連絡方法として本命であるGitHubとSlackの利用許可を勝ち取りました。
GitHubを使用できるようになったことを契機にGitHub Projectも始めてみました。
参考にしたのはこのあたり。
Slackでは1機能単位でチャンネルを作ることで、その機能に対する要求やタスク、認識の擦り合わせの経緯にアクセスしやすくなりました。
これにより「色々なところを見なきゃいけない」という、ありがちな課題が解消されました。メンバーの自己管理が目に見えて改善され、要件の誤認や実装漏れが大幅に減りました。それまで全てメール、Excelベースだったので非常に大きな変化でした。
※チーム外とのコミュニケーションは相変わらずですが。
できなかったこと
課員の育成
スケジュール管理
権限、タスクの委譲
少し書き起こしたのですが、どうがんばっても愚痴にしかならないので詳細は書かないことにします。
一つ言えるとしたら採用をがんばらないとお互いに不幸になるということですね。……っていうのも言い訳がましいですか。
弊チームのように新しいプロダクトを作り出そうというフェーズでは、少人数の精鋭を集めて土台となる部分を素早く作り上げるべきだったと感じています。そこに未経験新卒新人を投入されたのが戦略ミスとしか言いようがありません。マネージャとは名ばかりでヒト・モノ・カネに一切の権限がなく、取れる手段があまりにも少なすぎました。
あとは、想像はしていたのですがマネージャ以上にしか展開されていない情報の多さを知ることができました。一日に受信するメールが100~200通増えました。情報格差があるせいで明かさないよう命令されている情報を隠しながらメンバーに説明しなければならず、とても論理的とは言い難い、納得感のない一方的な命令になりがちでした。それをどれだけ避けるか。そんなくだらないスキルが磨かれました。
逆に、ただ業務を阻害するだけの不必要な面倒事に関する情報はあえてメンバーには明かさず、「聞いてません、知りません」と逃げられるようにしていました。
まぁその他諸々、明かしたい事情は腐るほどあるのですがメテオフォール型開発という一言で察してください。
おわりに
来年は自己反省をふまえたもっと前向きな振り返りにしたいですね。
メテオの降らない世界で。
この記事が気に入ったらサポートをしてみませんか?