マネージャーの経験から得たこと
こんにちは、シニアソフトウェアエンジニアのリドルです。このポッドキャストでは、IT業界のいろんな話やリアルをお届けします。
今回は、エンジニアリングのマネージャーをやった後に、またメンバーに戻ったら見えたものということをご紹介したいと思います。
私はエンジニアリングマネージャーを一時期やっていたんですけれども、現在は1メンバーとして働いております。
メンバーで普通に現場の仕事をしているんですけれども、一回そのマネージメントみたいなことを経験すると、ちょっと見えるものが広がるわけですよね。
視差が上がるというか。そういう中で、こういうことをしたらいいんじゃないの?みたいなことがわかるようになったので、そちらを共有したいと思います。
もしまだマネージャー経験がない方で、メンバーの方いらっしゃいましたらですね、パクっていただけると幸いです。
まず一つ目なんですけれども、これはですね、どっちかっていうと、マネージャーの時にちょっとない場所にしすぎたなっていう話なんですけれども、
現場でいろんなものを作ったりすると思うんですけれども、その時にマネージャーの時は、Aを作るにはBやってCやってDやればできるから、
だいたいこんなもんかなーみたいな構数をざっくり計算することがよくあるんですけれども、それがですね、現場に立つとですね、そんなにうまくいかないぞっていう話ですね。
確かにBやってCやってDやればうまくいくんだけど、BとCやるためには結構ししめんどくさい設定があったりとか、
一行設定ファイルの書き方間違えたり、コードの書き方変えるだけで動かなかったりするっていうのがプログラミングだったりとか、
インフラとかアプリケーションの設計のもんですから、確かに理屈はそうなんだけど、そんなに簡単じゃねえんだぞっていうのを改めて思い出しました。
思い出したっていうか直面しました。ただマネージャーになるとそういう細かいことをちょっと忘れちゃうんで、
AやりたいならBとCとDやればいいからだいたい5日で終わるよねみたいなね、そういう概算で計算しだすんで、ちょっとよろしくないなという反省です。
なのでちょっとマネージャーが見積もるコースは結構ブレがちというか、大体論理的には合ってるんだけど細かいところのやつがあんまり含まれてないんでズレがちです。
ただですね、こういう細かい設定というか、なんかやらないといけない細々としたことってAIのエージェントで結構だいたいできると思っていて、
例えばですけど、BとCをつなぐためにちっちゃいスクリプトを書かなきゃいけないとか、シェルをちょっと書かなきゃいけないみたいなことがあったときに、
それってやりたいことわかっていればAIがパパパって書いてくれたりするもんなので、だいぶですね、論理的なB、C、Dさえわかっていれば、
なんか間の細々としたやつはできるから意外とマネージャーの見積もりの精度は上がるんじゃないかなという気はしています。
メンバーとしての役割
精度が上がるというか、マネージャーが想定した見積もりに現場が追いつくんじゃないかなという気がしています。
続いてですね、続いては現場が一番見えているのはメンバーなので、転ばぬ先の杖、こんなの打っといた方がいいですよっていうのは、
マネージャーにどんどん進言しましょうということですね。これは単純で、プロジェクトに入っていると思うんですけど皆さん、
そのプロジェクトにはゴールがあって、そのゴールを達成するためのいくつかのステップがあるわけじゃないですか。
今は一番最初のステップをやってるけど、次週、翌月はどんどんステップが進んでいきますと。
ステップが進んでいく前に、これやっといた方が絶対効率いいよなとか、これ先にやらないとアドバントめっちゃ困るぞみたいなものが、
現場の人であればあるほど見えていると思うんですよ。もちろんそのね、新入社員とかまだこの一通りのプロセスを体験したことがないという人は難しいと思いますけど、
なんとかね、そのプロジェクトの経験をしている人であれば、例えばエラーとかって初めに定義しといた方がいいよねみたいなのがあると思うんですよ。
そうすると、現場で今エラーなくて困ってるってことであれば、マネージャーに進言してですね、
エラーとか初めに定義しといた方がいいですよとか、それコース大体こんぐらいかかるんで追加しといてもらえますか、マイルストーンにみたいな話をしておけばですね、
マネージャーはね、喜びますよ。あ、それ抜けてました、ありがとうございますみたいなね。
まあそういう感じですね、一番現場のことは分かっているのは現場のメンバーなので、
ぜひですね、現場にしか見えないもの、問題をマネージャーに進言して、さらに転ぶ先の杖みたいなものをですね、マネージャーに共有してあげるとめっちゃ喜ばれるかなと思います。
はい、最後ですね。最後はですね、マネージャーの仕事をどんどん奪ってください。
マネージャーってね、忙しいんですよね。調整とかね、いろいろあるんで。
で、別に皆さんがマネージャーに将来になりたいかどうかは全然分かんないんですけども、
マネージャーの仕事をですね、できるようにしたことはないと思っていて、
ここで言うマネージャーってエンジニアリングマネージャーだけじゃなくて、プロジェクトのマネージャーとか、技術的なマネージャーとか、いろいろあると思うんですけども、
彼らのですね、仕事をですね、少しでもいいから隠れるたりとか、
別にマネージメントじゃなくて、若干メンバーの仕事に似てないみたいなやつとかは、どんどんパクった方がいいですね。
パクるとですね、自分にも経験にもなりますし、
マネージャーの手が開くとですね、もうちょっと全体のことを考えてくれる時間が増えるので、
結果的にプロジェクトがうまく回りやすくなるんですよね。
マネージャーもですね、仕事を振るのって仕事ではあるんですけども、
別になんか、自分でやった方が早いぜとか思ってる場合とか、振るのも面倒くさいなーみたいな思ってるタイミングとかもあるので、
それやってスタックするくらいだったらね、メンバーが巻き取ってうまくやった方がスムーズに進むこともありますし、
別に巻き取らなくていいよっていう場合はマネージャーがね、巻き取りを断ることもあると思いますんで、
そういうところにですね、目を、目端を光らせてですね、仕事をパクっていくっていうのがね、結構マネージャーにとっては助かるかなというふうに思います。
はい、ということでですね、今回はですね、かつてマネージャーをやっていたリドルがですね、
実際にはメンバーとしてマネージャーを助けるというか、マネージャーのために何ができるかみたいなところをいくつかご紹介しました。
このポッドキャストをハッシュタグライティで皆様からの感想やコメント募集しております。
またチャンネル概要欄にGoogleフォームのリンクもありますのでそちらからのご投稿も大歓迎です。
ありがとうございました。
