はじめに

未経験からエンジニアになってはや一年、、、あっという間の一年間でした。今後もより一層開発に貢献していくために、これまでの学びを振り返ろうと思います。

要件をしっかりとヒアリングする。要件が不明瞭な状態で開発を進めない

ビジネスサイドの方たちの要望をシステムに落とし込んでいくことが僕の仕事です。

以前、複雑な機能実装を任された際に、テキストで書かれている機能要件を自分の解釈で汲み取って開発を進めてしまったことがありました。その結果、ビジネスサイドの方が実現したかった機能とは少し食い違ったものが完成してしまったことがあります。

このような開発の後戻りを防ぐためにも「対話」が非常に重要です。

また、実装が難しいわりに、ビジネスとして効果が薄い要望もあります。そういった要望をもらったときに、開発者側とビジネスサイドで適切な落とし所を見つける必要があるということも教えていただきました。

対話をしていく中で、相手が本当に実現したいことは何かをしっかりと見極めていくことが大事であると学びました。

前提を疑う

「今自分はこのコードをコントローラの中に書こうとしているけど、そもそもそれは正解なのか？」

「マーケターさんはこう言っていたけど、本当に実現したいことはこれであっているのか？」

このように「○○という前提で進めようとしてるけど、本当に正しいのか？」とクリティカルシンキングを働かせることも重要だと思いました。

責務を意識しながらコードを書く

コードレビューの中で、「ここのmodelの責務を考慮すると、このメソッドはこのmodelにおくべきでない」だとか「凝集度が低いクラスになるから、責務を分離した方がいい」といったレビューをもらうことがあります。

この辺りの責務を意識したコーディングは「良いコード／悪いコードで学ぶ設計入門」や「リーダブルコード」などでも勉強していましたが、適切に実践できていませんでした。

また、良いコードを書くにはどうしたいいか学ぶ中で、以下のような動画をyoutubeで見つけました。

https://www.youtube.com/watch?v=hX9kCwdR8dc

個人的にとても腑に落ちました。

「オブジェクト指向」だとか「デザインパターン」だとか「クリーンアーキテクチャ」だとか色々なコーディング(設計)の技法がありますが、とりあえずまずはシンプルに責務を意識することでgood enoughなコードが書けている気がしています。

目の前の仕事を全力でやることで力がつく

僕は、子供がいて業務外で学習時間が思うように取れない事に悩むことがありました。実力的にもっと勉強しないといけないし、そもそも勉強が好きなので勉強の時間があまり取れないのが割と苦痛でした。

twitterを見ると業務外でたくさん勉強している駆け出しエンジニアをよく見かけます。そのような人たちと自分を比較してしまい、嫌な思いをすることもありました。

そんな時に以下のブログ記事に出会いました。

https://soudai.hatenablog.com/entry/2021/12/23/111510

https://soudai.hatenablog.com/entry/2021/12/31/114009

私はまだ経験が浅いので、業務外でどんどん勉強していく必要があるのは間違いありません。

また、仕事を全力でやるだけで強強エンジニアに追いつけるなんてことも全く思っていません。

ただ、この記事を読んだ後、確実に仕事に取り組む姿勢が変わっていったと思います。具体的には、（設計をよく学べるらしいので）時間がある時にリファクタリングをやらせてくださいと申し出たり、TDDを勉強して仕事で実践してみたりと、仕事の中で主体的に学びを得ようと心がけるようになりました。

これらの記事を読む前までは、淡々と与えられたタスクを期限までにこなすことしか頭にありませんでした。

しかし、自分次第でその一つ一つのタスクの中で色んなことを学ぶことができる事に気づくことができたと思います。

ドキュメンテーション力がとても大事

エンジニアにとってドキュメンテーション力（知識、知見をわかりやすく文章化する技術）はとても大事だなと思う時がありました。

具体的には

個人的に手本にしているエンジニアが書いた新機能の仕様書がすごかった
自分が退職していなくなった後に他の人が読んで意図が伝わるようなドキュメントを書く必要があると先輩エンジニアに教わった

ドキュメンテーション力をあげるためにも、技術記事等のアウトプットは不可欠だなと実感しました。

タスクを細分化する

たまに、何から手をつけていくかわからなかったり、なぜかやる気の出ないタスクに遭遇することがありました。（後者は達人プログラマーでいうところの「爬虫類脳」からの危険信号なのだと思います）

そういった時に打開策はないかと色々調べて見つけたのが、タスクの細分化です。特に以下の記事はとても勉強になりました。

https://qiita.com/jnchito/items/017487cd882091494298

タスクを細分化するという技を覚えて以来、自分のNotionにタスク管理のカンバンを作って、やるべきことを見える化して整理するようになりました。

保守性、可読性を担保しつつスピーディな開発をしていく必要がある

「良いコード」を書いていこうとすると、逆にスピードが落ちてしまうことに悩むことがありました。そんな時に先輩エンジニアとの1on1で教えてもらったのが「QCD」という概念でした。 QCDはもの作りに重要な3つの要素であるQuality（品質）、Cost（コスト）、Delivery（納期）の頭文字をとったものです。特に品質が重要とされ、この3つはトレードオフの関係にあるとされています。 1on1の中ではこのバランスを経験で知っていくのがいいね〜という話でまとまり、非常に納得感がありました。

また、以下の素晴らしいスライドを発見しました。

https://speakerdeck.com/twada/quality-and-speed-2022-spring-edition

短期的にも長期的にも、崩壊したコードを書くほうが、クリーンなコードを書くよりも常に遅い

コード品質を高く保っていた「にも関わらず」速いのではない。コード品質を高く保っていた「からこそ」速いのだ

質とスピードはトレードオフでないことが力説されており、目から鱗の連続でした。

シンプルに技術力を上げていく(保守性の高いコードを書けるようになる)だけでなく、「ソフトウェア開発の最初から最後まで関わる経験」もしてみたいと思うようになりました。

最後に

web開発は楽しい、というのが1年間やってみてのざっくりとした感想です。自分が作った機能をユーザーに使ってもらえることにとてもやりがいを感じました。そして無限増殖する「学ばないといけないこと」にキャッチアップしていくプロセスを充実感を持って楽しめている気がしています。

2年目以降も楽しいという気持ちを忘れずに、いろんなことに挑戦して行けたらなと思います。

RET

Reflection English Technology

エンジニア1年目で学んだことを振り返る