はじめに
エンジニアとして成長し、「つよつよエンジニア」と呼ばれて周囲から評価されるエンジニアになりたいという若手エンジニアや学生の方は多くいると思います。
私は今までで数百人以上のエンジニアと一緒に仕事をしており、その中にはベンチャーや上場企業でCTO/VPoT/テックリードといった役職についている「つよつよエンジニア」も多くいます。
(かくいう私も組織マネジメント力よりは技術力を評価されてCTOをしていますし、今もコードを書いています)。
「つよつよエンジニアになるためにはどのようなアクションをとればいいか」という視点で述べられていることは多くても「成果物にどのような特徴があるのか」という観点で述べられていることはあまり無い印象です。
成果物の特徴さえわかれば、まだ自身がそのレベルまで到達できていなくても、成果物のレベルを引き上げることができます。
（世阿弥の「風姿花伝」でも「真似る」ことが「学ぶこと」に通じることが述べられています。）
成果物のレベルを引き上げることができれば、今自分が所属している組織やプロダクト、自身のポートフォリオに大きくプラスになるはずなので、この記事ではつよつよエンジニアの成果物の特徴を５つに絞って述べていきたいと思います。
1. 非機能要件が考慮されている
一番違いが生まれるのがこの要素ですね。
つよつよエンジニアのアウトプットはセキュリティやユーザビリティ、保守性、可読性、拡張性、パフォーマンス、テスト性、例外処理といった非機能要件が考慮された実装になっています。
これらの要素は要件定義書や開発チケット上に書かれていることは少ない要素ではあるものの、高いユーザー体験や安定的なサービス運営には欠かせないものです。
言われたこと（要件を満たす）だけでなく、言われていないがサービスの運営上重要なこと（非機能要件）も考慮して実装できるかどうかがつよつよエンジニアの成果物における非常に大きな違いになります。
これらの非機能要件は外部業者に業務委託で開発を丸投げしたときに高確率で落ちた状態で納品される要素でもあります。
保守性や拡張性等、定量化が難しい要素も多いので、外部業者への発注時の要件に入れることも難しいです。
数値化が難しく、無限責任になるリスクがあるため、要件にしようとしても基本受注者側に拒否されるでしょう。
組み込めてパフォーマンスとセキュリティくらいでしょうか。
これらの要素を欠いた実装は、保守フェーズになると以下のような形で牙を剥いてきてデスマーチの原因となります。(経験談)
- 例外処理が考慮されていない → 不整合トランザクションによるエラーの発生とリカバリー対応、サービスダウン
- セキュリティが考慮されていない → 攻撃によるサービスダウン、サイト乗っ取り
- 保守性が考慮されていない → 開発/テスト工数、不具合の増加、エンジニアのモチベーション低下による離職の増加
この要素の考慮がなぜ難しいかというと、非常に重要でありながら実装時に参考にするであろう技術書やググって出てくる記事で考慮されているケースが非常に少ないんですよね。
また、結構広範な領域の知識が必要になります。
従って要件通りの実装を試みたときに実装過程で自然と抜け落ちてしまうことが多いです。
Generative AIを使った場合でもこの要素は抜け落ちてることが多いので自身での補完が必要になります。
２. プログラミングの原理原則が守られている
つよつよエンジニアのコードはSOLID原則やUNIX思想、DRY原則、KISS原則、YAGNI原則、OAOO原則といったプログラミングの原理原則が守られています。
一言でいうと可読性や保守性が高いコード、すなわち「シンプルで美しいコード」になっていることがほとんどです。
つよつよエンジニアのコードが読みにくいということは私はあまり経験したことがないですね。
一部例外として極限までパフォーマンスを重視する必要があるときに、最適化のためにトレードオフとして可読性や保守性を犠牲にしてたときぐらいです。
プログラミングの原理原則を守って、シンプルで美しいコードを書くことは保守開発をするうえで非常に大事なことです。
複雑で読みにくいコード、すなわち「可読性の低いコード」を読んで理解するのには時間がかかります。
そして、コードの理解に時間がかかるということは、新規メンバーのオンボーディングや機能追加、不具合の調査/修正にも時間がかかります。
循環的複雑度の指標にもあるとおり、複雑なコードは不具合の発生源にもなりやすいです。
これは、ビジネス的にもマイナスですし、作業を行うエンジニアのモチベーション低下の原因にもなります。
3. リポジトリ内に無駄なものが無い
デッドコードや.DS_Store などの不要なファイルがリポジトリにコミットされたとしてもつよつよエンジニアは発見次第除去していくので、リポジトリ内は綺麗な状態に保たれる傾向があります。
「使われてないなら消すべき」というスタイルの人がほとんどなので、コメントアウトされているコードなどもすぐに消されていきます。
作業時に異物(不具合)の混入を防ぎ、最高のアウトプットを提供するために作業場を常に綺麗に保つという意味では高級料理店の料理人の作業場と同じですね。
4. CI/CD pipelineが初期から整備されている
つよつよエンジニアは開発初期フェーズからCI/CD pipelineを整備していることが多いです。
Linter/Formatter/単体テストの実行やデプロイ作業は単純作業なので、自動化してしまうのが一番効率的です。
プログラマーの３大美徳のうち「怠惰さ」に結びつく要素ですね。
5.テストコードが（高確率で）存在する
つよつよエンジニアがいるプロジェクトでは高確率でテストコードが存在します。
webエンジニア界隈だと「テストコードが無い保守開発とかありえないでしょ」というスタイルの人も多いです。
アジャイル開発の原点となった、アジャイルマニフェストを出したKent Beckさんや James Grenningさんといった世界レベルで有名なつよつよエンジニアの方もTDD(Test-Driven Development)やXP(Extreme Programming)といったテストコードを軸とした開発を提唱しています。
私もテストコードの書きやすさをプログラミング言語/フレームワーク選定時の要素とするぐらい重要視してます。
「高確率で」と記載しているのは、スクラップアンドビルドが基本となるスマホゲー業界のつよつよエンジニアは基本書かない人が多いですし、全くテストコードを書かないつよつよエンジニアも偶に見かけます。
エンタープライズ界隈だと、つよつよエンジニアであっても結構テストコードを書かない人が多い印象です。
さいごに
ここまでで、「つよつよエンジニア」のアウトプットの特徴を５つに絞って紹介しました。
この成果物を支えているのは継続的な勉強です。
つよつよエンジニアと呼ばれる人は例外なく皆勉強熱心です。
まあ、エンジニアに限らず専門職の第一線で働いている人はバリューを出し続けるために皆勉強熱心ですね。
1日1日の勉強の積み重ねが５年後、10年後の自分を作ります。
自身の最終的なキャリアとして、エンジニアから技術系経営層をめざすのであれば、以下の5つの観点での勉強は必須となります。
目指す最終的なキャリアがスタッフエンジニアであれば3つ目まで、エンジニアマネージャーだったら4つ目までですかね。
- 「プログラミング言語、原理原則論、セキュリティ/ネットワーク等の周辺領域の勉強」(非機能要件をカバーしつつ綺麗なコードを書くために必要)
- 「最先端の技術スタックの勉強」
- 「自身が開発するサービスのドメインに関する勉強」(高いユーザー体験を持ったサービスを作るうえで必須。ドメイン知識が無いとエンドユーザーにとって使いやすいものは作れません。)
- 「組織マネジメントに関する勉強」
- 「法務/労務/財務/経理といったビジネス領域の勉強」(取締役/執行役員 CTOのような技術系経営層になるうえで必須。これらの基礎知識がないと他のボードメンバーと経営課題の議論ができません。)
勉強にはそれなりに時間の投資を必要とするので、私はすべてのエンジニアがつよつよエンジニアを目指すべきとは思っていません。
ライフプランを考えたときに、家族や恋人との時間を優先したいという人もいれば、趣味に時間を割きたいという人もいるでしょう。
一番大切なことは、ライフプランやキャリアプランを考えて自分なりに落とし所を見つけて充実した人生につなげることなのかなと思います。
キャリアプランの一つとして、つよつよエンジニアを目指していくのであれば、成果物の特徴を真似しつつ、そこから逆算しながら勉強を進めていくことが一番効率的な勉強につながるはずです。
（受験で経験している人も多いかと思います）。
この記事の内容が皆さんがつよつよエンジニアを目指すうえでの一助になれば幸いです。