システムエンジニアの働き方完全に理解した
この記事について
この記事は、「Easy Easy」というコミュニティの「エンジニア達の「完全に理解した」Talk #64」で登壇発表した際の記事版となっています。
「エンジニア達の「完全に理解した」Talk #64」の配信
発表時のスライド
また、「エンジニア達の「完全に理解した」Talk」というイベントのコンセプト上、「なんとなくわかったこと」をゆるく発表するために正確でない内容が記載されている可能性があります。
内容に関しては十分注意して取り扱っておりますが、閲覧の際はご了承ください。
初めに
沢の村です。
普段は都内のブランド二次流通事業を行うスタートアップ企業でフロントエンドエンジニア(?)をやっています。
(バックエンドやったり、SEOやったり、お客さん対応やったり、デザインやったり、動画編集やったりもしています...)
今回は、新卒として1年間働いてきて感じたエンジニアとしての働き方についてお話ししたいと思います。
特に新卒一年目のような、エンジニアとしての働き方が全然わかっていない方に向けて、「こんな意識で仕事をすればもっと楽に取り組めるのではないか」というアドバイスになっています。
私もこれらのことを実際に実践してみて、以前よりも仕事に対して楽に取り組めるようになった気がします。
まだまだ荒削りなところがあるかと思いますが、今後の働く上での参考にしていただけると幸いです。
まず初めに全体像を掴む
仕事を終わらせるために、一番大事なことは全体像を掴むことだと考えます。
なぜなら、全体像が掴めないままだと、理解のスピードが遅くなってしまうからです。
全体を把握してから細かいところを把握しようとすると、その事柄についての大まかな流れがわかっているので、何をしているのかが理解しやすくなります。
逆に、細かいところから把握しようとすると大半を把握してからでないと、何を行なっているのかが把握できません。
例えば、初めて見るコードを読解しようとしたとき、「このファイルはこんなふうなことを行なっている」というのを把握した上で、細かいところを把握しようとすると、「この処理はおそらくここで使われているんだろうな」と予測を立てながら読解することができます。
これによって、全体の理解が速くなります。
一方で、細かいところから読解するとなると、初めて見るコードは、「何をしているのかわからない」という状態から始まります。
コードの大半を把握して初めて、「このファイルはこんなことやっているのかな?」と理解します。
場合によっては、もう一度最初から読み直すなんてことも発生するかと思います。
また、社内アプリを改修するということになっても同じことが言えると思います。
現場から「この部分を改修してほしい」というふうに依頼が来たときに、全体の業務フローがわかっていなければ、どこをいじれば他の部分と干渉せずに改修できるかがわかりません。
私が今仕事をしている会社では、大半のリポジトリでドキュメントが存在しないので、コードを改修する際は毎回ドキュメントを作成するところから始めています。
ただ、私自身が全て手で作成しているわけではなく、VSCodeのCopilotでドキュメントを作成するようにして、これを読んでから改修をしています。
ドキュメントを作成している例
本当は、コードを作成した人にドキュメントを作成してほしいのですが、スタートアップなのでとりあえずリリースするがデフォになっています。
(コード理解が毎回大変です...)
このように、全体像を掴むことが何より大事です。
その仕事がどれだけ早く終わらせられるかが、本題に取り組む前からの準備にかかっています。
有識者の知見を活用する
価値を生み出したり、成長したりするために、自分の興味だけでなく、目上の方から発信したことは積極的に確認するようにしましょう。
なぜなら、基本的に自分より年が上の人は、自分より知識や経験が多いので自分に欠けている知識や視点を持っているからです。
これまでに経験してきた事柄から抽出された高濃度なアドバイスは、何よりもずっと意味があります。
隣で働く先輩は自分よりも会社の雰囲気や歴史に対しての造詣が深いはずです。
そこに自分が身につけた知識や経験をプラスすることで、新しい価値を生み出すことが可能です。
また、同じ会社の人のみだけを対象としなくてもよいです。
エンジニアという大きな括りで見た時に、有益な情報を発信する方々がいらっしゃいます。
Twitterやnote、YouTubeでその人らをフォローしたり、エンジニアの勉強会に行ってみて話を聞いたりすることで様々な知識と経験を得ることができます。
仕事がうまくいく人の特徴として、「なんでもかんでも質問して自分の糧にする」というのがあります。
エンジニアとして働く場合は、「まず自分でググってから聞け」というのが慣わしになっているので、些細なことでもなかなか聞きづらいことがあると思います。
そこで役に立ってくるのが、有名な方の情報発信を見て読んで、自分の糧にすることです。
例えば私は、noteで星影さんのメンバーシップに入っています。
ほぼ毎日更新の「星影のニュースめも」は個人的に超役に立っています。
自分の知らなかったITに関する情報を素早く手軽に手に入れることができるので、時間がなくてもキャッチアップできます。
また、CTOを経験した方が普段どんなことを意識しながら働いているかを知れるキッカケになるので参考になると思います。
他に私がフォローしたり参考にしている方々の中でも特におすすめな方々を下記に置いておきます。
このように、自分が興味あることだけでなく、知識を持っている人のことについても吸収するようにしましょう。
「意識高いな〜」なんて思ってバカにするよりも、一つでも自分の成長につながることをしたほうが結果的に得します。
社外コミュニティで視野を広げる
新しい視点を持つために、同じ会社のエンジニアだけでなく、社外のエンジニアとも仲良くなりましょう。
同じコミュニティにしか所属していないことになると、考えていることが凝り固まるからです。
勉強会や交流会に参加すれば、自分の会社とはまた違う角度からの知識を得ることができます。
日々の仕事やプライベートに役立つ内容とかも知れる良い機会になります。
私はconnpassというエンジニア向けの勉強会プラットフォームを利用しています。
私の場合は、知り合い作りのためにも勉強会や交流会に参加している側面もあります。
エンジニアとして仕事をしていると、休日は家にこもって一日中勉強みたいなことが多々あるので友達もできづらいです(私の場合は...)。
最近ちょこちょこ勉強会や交流会に参加するようになったのですが、「こんなサービスがあるなんて全く知らなかった」とか「今度これやってみよう」なんてことが色々あります。
例えば、私がZennに記事投稿をしていこうとなったきっかけは、1回目のZenncafeでのことでした。
普段Zennに投稿されている有名な方から直接お話ができて、何も記事を書かないままじゃいられないと刺激をもらいました。
また、受け身になっているだけではなく、自分から自発的に行動しましょう。
例えば、自分から話に行くだったり、参加する会の内容についていけるようにあらかじめ勉強しておいたりするなどです。
交流会では何もせずに座っていたりせず、「よかったらお話ししませんか?」と話に行きましょう。(かなり自戒を込めています...)
せっかくのいろいろなバックグラウンドがある人と交流できる機会があるのにも関わらず、何も話しに行かないのはもったいないです。
また、例えば、Reactの交流会であれば、少なくとも1つくらいはアプリを作っておきましょう。
他の参加者と交流する際に、「こんなことやったよ」と話の話題にもなりますし、知識がないと全く話についていけなくなります。
これもまた受け身にならないための方法です。
このようにいろいろな勉強会や交流会に参加することで、自分自身の行動や意識に必ず変化を与えてくれます。
その人だからこそわかる事柄を吸収して、成長して、多角的な視点を持ちましょう。
初心者こそアウトプットが成長の鍵
学んだことを身につけるには、学んだことを積極的にアウトプットしましょう。
アウトプットしてから始めて自分が理解しているかしていないかがわかるからです。
自分が理解していない状態でアウトプットを行おうとすると、理解していないところで必ず詰まります。
例えば、コードを書いているときに曖昧なままでいると、「この処理が書きたいけどどうやって書くんだっけ?」となるはずです。
また記事を書くときも、「この記述の部分弱いから修正したいけどどう書けばいいんだろ」となるはずです。
このように、何が理解していないかが明確になります。
その理解していない弱点を再度勉強して補強することで、少しずつ理解していきます。
アウトプットの方法ですが、コードを書いて実行してみるだとか、色々あるかと思いますが、中でも私はアウトプットをするなら記事作成をおすすめします。
実際の体験をもとに言語化して記事を書くために、より書いた内容が頭に残りやすくなります。(テディベア現象に近いものを感じます)
例えば、私は基本情報技術者試験の勉強の一環として、2つ記事を書きました。
これらは、完全に自分に対しての知識整理として書いたもので、基本的には誰かに読まれることを想定していませんでした。
しかし、「マサカリ」[1]は飛んでくることはありませんでしたし、あやふやなところを整理したことで知識を確実なものにすることができました。
エンジニアの知識が少ない初心者の方は、必要以上に「マサカリ」を警戒しているように思います。
私も実際に初めて記事を書いてみるかとなっても、「マサカリ」が飛んでこないかかなり警戒していました。
結局のところ、先ほども述べたように全く「マサカリ」は飛んできませんでした。
「誰かから批判されるかもしれない...」と思って記事を書かずにいるよりも、とりあえず出してみる方が自分に対してプラスにつながります。
初心者だからアウトプットする際のメリットは他にもあります。
初心者の時に考えていたことをアウトプットすることで、のちの自分が振り返ってみた時に、「そのとき何が起こっていたのか」が記録として残るからです。
「具体と抽象」という本の中でも書かれていたのですが、「抽象側(上)が見える人には具体側(下)は見えるが、具体側(下)しか見えない人には抽象側(上)が見えない」というものです。
これはつまり、「上のレベルの人が上のレベルで行動を行っても、下のレベルの人には理解ができない」ということです。
例えば、私は大学でオブジェクト指向を知った時、「オブジェクト指向のクラスはたい焼きの金型みたいなものだよ」と説明されても全く理解できませんでした。
「たい焼きが〜」とか「設計図が〜」とか抽象的なことで説明を受けていたので、具体的にどんなところで効果を発揮するのかという例があまりなかったためです。
しかし、この時の自分が初心者だった頃の心情や記録を残していると、初心者の立場がわかりやすくなります。
初心者の立場がわかった上で、これまでの経験からどういったところを補強して説明したらいいのかを考えやすくなります。
このように、アウトプットを行うことで「自分に不足している」ことを明確にして、今の自分・後の自分を改善することができます。
「これは自分の成長のためだ」と、「マサカリ」を恐れずに積極的にアウトプットしましょう
最後に
エンジニアとしての働き方について、新卒で一年間働いてきた私の経験則からお話ししました。
- まずは全体像を掴むことで作業効率が上がること
- 有識者の知見が自分の成長につながること
- 社外コミュニティに参加して新しい視点を持つこと
- 初心者だからアウトプットして知識を固めること
これら4つのことを実践してみるだけでもエンジニアとして働くにあたってよりよいものになると思います。
エンジニアとしての仕事がうまく行かないなと感じたら、これらの方法を参考にしていただけたら幸いです。
-
「マサカリ」...過度に攻撃してくる指摘や批判の声 ↩︎
Discussion
LT登壇＆ご紹介ありがとうございます！
具体と抽象の話はとても大事なことですね〜😌
こちらこそありがとうございました！
具体と抽象って意外と仕事で重要なんだなって思いました