当記事の概要はタイトルのとおりです。
あまりポエム系記事は書いたことがないのですが、エンジニアになって3年経っていたので一つの節目としてポエってみようと思います。
略歴
私のエンジニア歴をざっと載せます。
案件1（1年3ヶ月）
某企業様の販売管理システムの保守・改修を担当させていただいたのが最初の案件でした。
最後の3ヶ月は上記保守・改修と並行して、とあるサービス上で動作するWebアプリの開発・改修も経験しました。ただ、その実態はアプリの要件に応じたAPIを呼び出す、ちょっとしたJavaScriptコードを書くだけという感じのタスクでしたので「Webアプリの開発・改修経験があります！」とは口が裂けても言えません。
案件2（1年9ヶ月）
次に経験したのが、とある企業様の商品売買契約情報管理システムの開発・改修でした。
事実上の、初めての開発・改修案件ということもあり多くのことを学べました。特に設計とテスト周りについては、それまでまったく意識したことがなかったので大変勉強になりました。
案件3（4ヶ月）
現在参画させていただいているのが3つ目の案件です。
2つ目の案件と同様に開発・改修系のタスクを担当させていただいています。
キャリア初期と現在とのいろいろな違い
エンジニア歴1年未満の時分と現在とで、エンジニアという職業・仕事内容に対して見方が変わったところ、変わらなかったところがあります。
そのあたりをつらつらと書いてみようと思います。
仕事は常に楽しい
仕事は常に楽しいです。エンジニアという職業・仕事自体に不満をもったことは一度もありません。今後どうなるかは分かりませんが、少なくとも現時点では天職そのものです。
なぜ不満を感じないのか考えてみたのですが、エンジニアという職業の嫌われるところが私に刺さっていないのが大きいと思います。新しい技術を学ぶのは楽しいですし、エラーが出ても直せばよいだけですし、仕様が変わって作り直しになっても作り直せば済む話ですし……ほかにもいろいろありますが、巷の「エンジニアという職業における嫌なところ」のほとんどは気になりません。
実装以外にも興味が出てきた
エンジニアになって1年半くらい――2つ目の案件に参画して3ヶ月が経ったくらいまでは実装にしか興味がありませんでした。いかに綺麗なコードを書くか、読みやすいコードを書くか、スマートな処理にするか、そんなことばかり考えていました。
ただ、2つ目の案件でテスト工程をちゃんと経験したことで考えが変わってきました。
当たり前のことではありますが、どんなに綺麗なコードを書いたとしても、そのコードが要件どおりになっていなければそれは「綺麗だけどダメなコード」なんです。この気づきから、私のなかで「綺麗なコードを書きたい」から「良いプログラムを作りたい」に意識が変化しました。
ここでテストの重要性を実感できたのは良かったのですが、まぁ、それでもテスト自体は今でも好きではありません。他人が作ったプログラムをテストするのはまだ楽しいのですが、自分が作ったプログラムを自分でテストするのは「一度クリアしたゲームの2周目をプレイする」ような感じがして、かなりストレスです。
それから3ヶ月か半年経ったくらいには要件定義や設計にも興味が出てきました。このあたりから綺麗なコードはシステムの複雑化を「抑える」ことはできても「止める」ことはできないということに気づき始めました。例えば、エンジニア歴1年の駆け出しエンジニアが作った10命令ぶんのシステムと、エンジニア歴50年のスーパーウルトラエンジニアが作った1,000,000,000命令ぶんのシステムとでは、圧倒的に前者のほうが保守・改修が容易です。
もちろん、綺麗なコードを書くことは相変わらず大事です。ただ、それだけでなく要件定義・設計の段階から、そのシステムの用途や目的・仕様をハッキリとさせ、のちのち改修したりすることがあっても改修担当者が混乱しないようなシステム構造にしておかないといけないな、と思ったのです。
どう作るかよりも何がしたいのか
なにかタスクが振られたとき、かつての私は「どう実装しようか」「どう作業しようか」ということが真っ先に思い浮かぶ人間でした。
それが今では「何を目的としたタスクなのか」「何をもって『作業完了』なのか」ということを真っ先に考えるようになりました。
こうした変化が生じた要因はいくつか思いつくのですが、たぶん最も比重が大きいのは「良い意味で、実装にある程度飽きた」ことにあると思っています。
私は今でも実装という作業が好きです。小さい頃にレゴブロックで遊んでいたときを思い出します。ブロックをくっつけて飛行機や宇宙船を作っていたあのときのように、コードを書いていって1つのシステムを作る――その流れが今でも好きです。
ただ、エンジニアに成りたての頃よりも実装に対する熱は弱くなりました。それは上でも述べたように、良いシステムを作るには実装だけでなく要件定義・設計・テストも大事であるということに気づいたことも大きいのでしょうが、あるていど実装してきたので慣れた・飽きたということに尽きるのｄせよう。
しかし、その飽きが良い方向に繋がっていると感じています。駆け出しの段階では見えていなかった「作業の目的」「作業の背景」そういったところに意識を向けられるようになったからです。
明確、かつ主体的なコミュニケーション
プロジェクトメンバーとのコミュニケーション方法もエンジニア初期と現在とでは違いがあります。
まず、あいまいな表現に気を付けるようになりました。「～のような状態です」「～だと思われます」よりも「～です」「～かは分かりません」といった表現を意識的に使うようにしています。理由はシンプルで伝わりやすいからですね。
また、タスクからタスクへ移行するときに、以前は「Aが完了しましたのでBに移ろうと思いますがよろしいでしょうか？」という質問をしていましたが、現在は「Aが完了しましたのでBに移ります」という意思表示というかたちを採るように意識しています。前者も後者も私の認識に問題があれば突っ込みが入ります。くわえて、前者の場合は問題が無くても誰かが私の問いかけに対して返答をする必要があります。その返答のコストが気になって、今のようなスタイルになりました。
……と書いてみましたが、なんだかこの項目については上手に言語化できていない気がします。また、どこかで「エンジニアにとっての良いコミュニケーションとは」みたいなタイトルで自分の考えを整理しつつ記事化してみたいですね。