ID:21977さん

どのエンジニアよりもマネジメントに優れ、どのマネージャよりもエンジニアリングに明るい人間になること

カイゼンのサイクルを会社内で回し続けること。 会社に技術によって利益をもたらすために、推奨されるべきエンジニア行動様式を実践することをしていきたいと考えています。 この重要な2軸を同時に実施することが、エンジニアとマネージャーの両方経験してきた私が 最も会社に貢献でき、楽しんで会社に参加する手段であるからです。 この考えは、これまで2社に渡ってエンジニアとマネージャの活動をしてきた経験によるところが大きく関わります。 1社目はエンジニア兼マネージャ候補として仕事をしました。 この会社は綿密なWBSと日本語で書かれたコード同然の細やかな設計書がプロジェクトを支配する典型的なSIerでした。 顧客の要望をしっかりと捉え、全てにおいて完璧とも言える段取りをしていましたが、 成果物としてのアプリはバグフィックスはしっかりとしているものの、 実行計画を見ずに実装された鈍重なクエリとチューニングされていないWebサーバによる低速なものでした。 また大量のドキュメントが足かせになり、機能変更や追加に対して軽やかとは言えませんでした。 2社目は1社目よりもはるかに技術力が高く、美しいコードを記述することができるエンジニアが多く在籍するベンチャーでした。 しかし一方で大日程のみが記載されたガントチャートと、 曖昧な要求のまま実装が可能な単位までブレークダウンされていないタスクに溢れていました。 優秀なエンジニアは顧客の要求を思い思いに解釈し、自らが美しいと思うコードを自由に記載していたため、 ときには顧客の要求とは異なるアプリを実装していたこともありました。 ここでプロジェクトマネジメントをエンジニアリングを両方をやりながら仕事をしたいと申し出たところ、 上司に快諾していただき、1年ほど自社プロダクトの運用兼、技術負債返済チームのリーダーとして、 スクラムマスターとしての活動を続けてきました。結果として以下の発表内容のような一定の成功を収めました。 https://speakerdeck.com/lighttiger2505/zi-she-sabisufalsedjangowo-1-dot-3kara1-dot-11-lts-ni-atupuguredosurumadefalsedao-falseri この活動の中で得たものは、スクラムという一定の成果を持つフレームワークに沿っていても、 その会社ごと、ヒトごとの特色に合わせて会議体や約束事チューニングを行い、 常に新しい変化をし続けなくてはマネジメントはすぐに陳腐化してしまうということ。 行動すべき指針を示すだけではなくそれを体現し、メンバーに見せてゆかねば理解を得られないということを知りました。