ソフトウェアエンジニア 3年目で振り返る、大切だったこと 6選

正社員として、ソフトウェアエンジニアを 3年ほどやっているのですが、ここらへんで一度振り返ってみようかなと記事にしました。

社会人としての基本的なところも含まれますが、自分の主観として何が大切だったのかを振り返ります。

新しいこと、知らないことを知る努力は欠かせない（貪欲に学ぶ）

ソフトウェアの世界ではどんどん新しい技術が生まれ、新卒のほうが良い解答を知っているということを往々にしてあります。

そのとき、「いや、これが自分のやり方だから」と避けるのではなく、「その手法を使った場合はどうなるのだろうか」と検討してから進め、新しい技術を学び、場合によっては新卒に教えてもらうという努力は継続する必要があります。

優秀なソフトウェアエンジニアとペアプロをしていた際に、「この tips いいね」と言い、すぐにそのエンジニアが使い始めたということもありました。 優れたエンジニアは常に学ぶ姿勢があります。

一度理解したことを忘れないようにする（DRY）

知らないことは恥ではありません。知らないことは誰でも教えてもらえばよいです。しかし、一度教わったことを忘れないようにどこかに書き出すことは必要です。

僕の周りの優秀なエンジニアは、常に自分の tips を書き留めていて、常にそれを呼び起こせる状態にしています。 そのため、同じ問題などが発生した場合でも対処がすぐに行えたりします。

ソースコードでも DRY原則がありますが、通常の業務であっても「一度やったことは繰り返さない」ように心がけるのが大切です。

常に手法をアップデートしていく（改善）

設計であれ、開発方法であれ、教えてもらったこと、自分で理解したことを慣れるまで使っていくのは大切なのですが、それだといつの間にか「自分のやり方」という罠にはまりがちです。

その手法をもっとうまくやる方法はないか、実は簡単な方法があるんじゃないかと「問い続ける」ことは意識が必要です。

Keep it simple, stupid

これは世の社会人の基本から大いに離れますが、メールやメッセージ、議事録などのテキストは「失礼じゃないけどできるだけシンプルに」ということが大切です。 というのは、ソフトウェアエンジニアが力を発揮すべきは「いかにプロダクトに役立つコードが作れるか」であって、懇切丁寧な辞句や丁寧なフォーマットの議事録にはないのです。

じゃあ、テキトーに済ませてコードだけ書いていればよいのかと言われると微妙なところで、他人と協調して働いているのであれば、やはり「簡潔で趣旨がわかる」ものであるべきです。

実際、業務でアメリカのソフトウェア企業とやりとりすることがありますが、彼らは丁寧なドキュメントを渡すことはありません。基本的に誤字脱字はありますし、テンプレートだけ整えたメモ書きみたいなものが多いです。

でも、趣旨が伝わり、情報として十分であれば体裁はどうでもよいです。 アーカイブするときや広く公開する前に校正すればよいので、フォーマット整えるのに時間を極力とらないようにしています。 （これはアーキテクチャ設計でいう、「実際に実装するのを遅れさせる」のに近しいところがあります。遅延評価でいきましょう）

機械にやれることは、人間がやる必要はない。有限な時間をいかに使えるか

自分が働いて違和感を感じるのは、「別に機械がやればいいんじゃないの？」と思うことも、人間の手で行っていることが往々にしてあることです。

具体的には、昔のドキュメントを探すのに時間をかけて調べたり、チェックで人の目を通したり、細かいことを言えば枚挙にいとまがありません。

もちろん、機械では 100% うまくいかないこともあります。しかし、80% うまくいけば、時間短縮につながることがあります。実際、画像の識別について、まだディープラーニングが発達してなかった頃でも、画像整理で決定木ベースのツールを導入するだけで、人間の整理の手間を減らせたという研究もあるくらいです。

別に人間がやることについて否定をする必要はないのですが、尋ねたいのは あなた（そして他人）のとてもとても大切な時間を費やすほど、それを人間がやることは重要なのか ということです。

健康と生活習慣

長い間プロダクトに関係していくのであれば、健康を保って、「常に明晰に物事を考えられる状態」にしておくことが大切です。 お腹が痛いときにコードについてよく考えることはできません。

ユウェナリス が言っていたように、健全な精神は健全なる身体に宿ります。 健康な身体であれば、良い設計やコードを考えることができます。

長い目で見たときに健康でいるのとそうでないのとで出るアウトプットは大きく変わるでしょう。