Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

中の下のエンジニアを脱出するための仕事術

43,088 views

Published on

2015/10/21 社内勉強会(スキルウェンズデー)での発表資料

Published in: Engineering
  • Be the first to comment

中の下のエンジニアを脱出するための仕事術

  1. 1. 中の下のエンジニアを脱出する仕事術 株式会社CyberZ 門田矩明
  2. 2. 自己紹介 ● 門田 矩明(かどた のりあき) ● 株式会社CyberZ 「F.O.X」 プロダクトマネージャ兼エンジニアマネージャ ● JavaエンジニアでFWはほぼSpring固定。JSもJavaと同じぐらいには好き。 ● 前職はSIerで、某レーベルのFCサービス作ったり、新卒就活サイト作ったり、 某出版社の楽器検索サイト作ったり、FXの取引&周辺システム作ったりとか。 ● 2012年にサイバーエージェントに入社。 Amebaで複数のスマホ向け新規サービスにエンジニアとして参加しつつ、 (運良く)いくつか開発責任者したり、技術ボードやったりしてた ● スマホ広告周りの開発がやりたくなって、2014年にCyberZ 異動。
  3. 3. いきなりですが あなたは中の下のエンジニアから 抜け出せていますか?
  4. 4. 中の下のエンジニアの特徴 ● 一通りの開発に関する経験はしている ● 降ってくるタスクは大体こなせるし、こなせる自信はある ● 職場では中堅エンジニアだし、業界でも大体真ん中ぐらいだと思っている(?) ● 一人でゼロベースの新規開発しろと言われたら不安 ● オープンソースのコードをあまり読まないで使っている ● 技術のキャッチアップがおろそかになってきている ● 目の前のタスクをこなすだけになっていて目標設定出来ていない ● 「自分の強み」がなんなのかよくわからない
  5. 5. 中の下のエンジニアとは? ● いわゆる一人前の普通のエンジニアです。 ● 突出したスキルを持っているわけではなく、平均を抜け出せていません。 ● 同時に技術者として成長が鈍化しているのを感じていて、 自己学習したり外部のセミナーも行ったりしますが、うまくいかなかったり。 ● 平均だし、普通だし、中の中かと思いますが、 周りから「なんか足りない」と思われてたりします。 ですので、実際の評価だと、中の下のエンジニアに。。。 ● サイバーエージェントに入社する前あたりの僕はこの状態でした。 このままじゃマズイ!と思って、考え抜きました。
  6. 6. 中の下のエンジニアから抜け出す方法
  7. 7. 「アウトプットを増やす」
  8. 8. 「アウトプットを増やす」 違う!
  9. 9. 「アウトプットを減らす」
  10. 10. 「アウトプットを減らす」 + 「インプットを増やす」 コレダ!
  11. 11. 中の下のエンジニアをぬけ出すのに必要な事 ● インプットを増やします。 要は情報収集に時間をかけ、アウトプット(コードとか)の質を確実に上げます。 ● よくある、「アウトプット増やす」のライフハックは、 経験が少なく、コードをひたすら書くことでスキルを伸ばせる時期は有効ですが、 伸びしろのある時期を過ぎてしまうと意味が無いものになりがちです。 ● であれば、「インプット増やす」だけで良さそうなのですが、 実際にはアウトプットを減らさないとうまくインプットの時間を確保出来ません。 アウトプットは厳選したものだけにして、減らす分のバランスはとります。
  12. 12. 実際に門田がやったこと ● アウトプットを増やすことで成長が見込めるメンバーを確保します。 ● 自分は難易度高い厳選したタスクを担当し、その他タスクは他に振ります。 ● メンバーの設計/コードレビューは積極的かつ、最優先で見るようにして、 お互いに納得が行くまでとことん話し合い、答えを出すことにコミットします。 ● タスクにはすぐアウトプットせず、イメージがつくまで、ひたすら調査します。 スタンダードを常に意識するようにし、設計理論、OSSの設計思想、 隣のプロジェクトなどを参考に自分の中での考えをまとめます。 ● 夢に出てくるぐらいになったら一気にアウトプットします。
  13. 13. 結果得た事 ● アウトプットの質が短期間で格段に上がりました。 ● 調査が多くなるので、中断することによる効率ダウンが少なくなりました。 ● 設計/コードレビューや相談を通じて、色々なメンバーの考え方を吸収できました。 納得がいくまで話し合うので、結果「標準」を強く意識するようになりました。 ● 隣のメンバーと一緒に成長している実感がわき、良いモチベになります。 ● 自分で書くより、人のコードを読むほうが成長できるし、面白くなりました。 アクセスできる限りのプロジェクトのコードを勝手に読み漁りました。 「すげー!」と思った人には勝手にチャット送ったりして仲良くなったり。 勝手にバグ見つけて報告した時は気持ち悪がられました。
  14. 14. 最後に ● 多分僕は中の中ぐらいにはなることが出来ました。 平均をぬけ出すと、自分にすごく自信が付きます。 世界が広く感じられると同時に、上には上がいることを痛感できます。 なので僕はまだまだ中の中です。

×