私について
「成長論」とか偉そうなこと言ってるけどお前は誰なんじゃい!ということで自己紹介を。
- 高専を卒業後クリエイティブキャストに入社
- 1年目から単独で現場に参画し、コストパフォーマンスが高いエンジニアとして評価
- 母校での採用活動、インターンコンテンツの作成・実施、他社様への研修など業務外での活動も多々
- 2年目にして25名規模の研修会場講師を担当し、4.7/5.0の高評価
といった感じでなんだかんだ色々やっております。
3年目にしてはそこそこ頑張れているかなぁといったところです。
そんな私の考える「成長」は次の通りです。
結論
結論、エンジニアとして成長し続ける上で最も大切だと思うことは「コミュニケーション」です。上記自己紹介の2~4つ目を実現できたのも、コミュニケーションによるものが大きいと考えています。
何をしたいのか
巨人の肩の上とは
西洋のメタファーであり、現代の解釈では、先人の積み重ねた発見に基づいて何かを発見することを指す
Wikipediaより引用
つまり私が行ってきたことは、上司や先輩の経験・知識を盗むことに他なりません。
目の前に居る上司や先輩達は、自分よりも多くの時間・回数仕事をこなしており、経験が豊富であることが明白です。
これはそれぞれの経験である3年、5年、10年などの期間によって得られたものです。
もし5年の経験を持つ先輩の経験(判断・業務の流れ・日々の仕事のこなし方)を模倣し、1年で同じレベルまで到達できたとしたらどうでしょうか。
かなり飛躍した例ではありますが、私が成長のために目指す行動とはこのことです。
なぜコミュニケーションなのか
極端な例ではありましたが、考えそのものはお分かり頂けたかと思います。
ここでは、巨人の肩の上に乗る(=経験・知識を盗む)ためになぜコミュニケーションが重要なのかを、コーディングを例に説明してみます。
IT業界でエンジニアを職業としていると、コーディングをする機会が必ずあります。
これに付随して、コードレビューなどもよく行われます。
私が初めてコードレビューをして頂いた時、次のようなことに気を付ける必要があると感じました。
- すでに共通処理として実装されているものがないか
- 変数・定数は適当に割り当てれらており、メンテナンスしやすいものになっているか
- テスト実施の観点で考え、最低限の分岐パターンを考慮できているか
多少の経験がある方からすれば、コーディングを行う際に気を付ける最低限のポイントに感じるかと思います。
つまり、その特定の開発において重要な点ではなく、コーディング全般において注意するべき点です。
上記例のように、一般化された観点で指摘をする方は少数派だと思います。
これを引き出すのがコミュニケーションです。
取り組み方・コツ
思考(=経験に基づく考え方・判断)を素早く学習するためには「なぜ」と「結果」が最も重要だと考えます。
しかし、ただ単に理由(なぜ)を聞くだけでは思考にまで落とし込むことはできません。
「なぜ」には3つの段階があると考えています。
- 着眼点(気にかける、疑うポイントなど)
- 着眼した点から何を得るか(着眼した理由に近い)
- 得たモノをどのような形で行動に反映するか
コードレビューで感じた点を例にすると
- 共通処理があるか
- 同じ処理をまとめることで変更に強いプログラムに
- 共通処理の把握・利用
と対応付けることができます。
想像を膨らませる
「共通処理があるとき」に着眼したのであれば、「ないとき」はどうだろうかと考えることで成長は加速します。
どういった処理を共通処理とするのか、逆に固有の処理として実装するべきものは?など1つのことから広げて考えることができます。
自身より経験豊富な人たちから、着眼点をきっかけに思考を盗むことで、短い時間で多くを得ることができます。
これが私の考える成長論です。
終わりに
ここまでで書いたことは理想的なことであって、全てを完璧に行うことは難しいですし、私自身も出来ている訳ではありません。
しかし、淡々と業務を行うのではなく何かを得られないか、と常に考えて取り組むことそのものが重要です。
自分なりの成長論、ぜひ考えてみてください。