この記事を読んで自分なりに書いてみたくなった。元記事には遠く及ばないが、今現在の自分が考えられることを残しておこうと思う。
エンジニアタイプ
エンジニア、またはエンジニアを目指す人であれば、何らかの RPG をプレイした経験があるはずだ。RPG には、ジョブ、クラス、などと呼ばれる「なりたい自分」を選べるシステムが導入されている場合がある。騎士や魔導師を選ぶのもよし、遊び人スタートもまたよしである。
エンジニアはそのタイプによって、さまざまな方向性があり専門性がある。結論から言うと自分がやりたいものを選べばよいのだが、向き、不向きがあり、ひとつのエンジニアタイプを極めるには努力、時間、運がどうしても必要なので慎重に選ぶ必要がある。
エンジニアタイプの例
- フロントエンド
- バックエンド
- インフラ
- アプリ
- データサイエンス
- アーキテクト
- システムデザイン
- UIデザイン
経験値
エンジニア、またはエンジニアを目指す人であれば、何らかの RPG をプレイした経験があるはずだ。そこには「レベル」なる概念がある場合があり、ストーリーを進めるためには経験値的なものを取得してレベルをあげていく必要がある。ストーリーを進めると自然に適正レベルにあがっていく親切設計の RPG もあれば、過酷なレベル上げ作業を繰り返さないと次のストーリーに進めないレベルあげありきの RPG もある。
脳科学的にはゴルフのハンデを減らすような、あるいは昇給や昇進をともなうステータスの向上を実感することは、世界で最高に気分がよいことの一つとされている。ステータスアップの瞬間には幸福感と結びつくドーパミンとセレトニンのレベルを高め、ストレス低下の指標となるコルチゾールレベルの低下をもたらす。
しかしながら、ゴルフのハンデのようにエンジニアのスキルを測る共通の尺度は存在しない。RPG のようにプレーヤーのレベルを常に表示できればいいのだが、エンジニアのスキルは自分の物差しで測るしかない。エンジニアのスキルを測ることは、自分に真摯に向き合う行為であり、課題を解決した経験を通じて自分が何を実現できたのかを問うことになる。
よいスキル表現の例
- アプリをつくれる
- Webブラウザアプリ
- モバイルアプリ
- デスクトップアプリ
- Slack などのメッセージアプリのようなリアルタイムにバックエンドの状態を画面表示するアプリ
- サーバレスアプリ
- ユーザ認証機能をつくれる
- JWT
- BaaS
- 認証プロバイダー
- REST API を用いて APIプロバイダーから情報を取得できる
- アプリを Web 上に公開できる
- パブリッククラウド前提でシステムを構築できる
- 大量のトラフィック (10万rpsとか) を低レイテンシー (100msとか) でさばくプラットフォームを構築できる
- あたえられたデータモデルに適した AI技術を選定できる
わるいスキル表現の例
- 実務経験 3年
- 基本情報技術者試験合格
- 特定の技術要素に精通している
- C / Java / Python / Ruby / PHP
- React / Vue / Laravel
- 非同期処理
- NoSQL / リレーショナルデータベース
- MUI / Bootstrap / Tailwindcss
一次情報を道しるべにする
エンジニア、またはエンジニアを目指す人であれば、何らかの RPG をプレイした経験があるはずだ。そこにはなんらかの地図システムがあって、冒険の道しるべになってくれる場合がある。
エンジニアにとってもっとも重要な地図は、公式ページの情報である。公式ページの情報は「一次情報」であり、開発コミュニティが執筆しているものが多い。
Web検索で一次情報以外を情報源にするのは慣れが必要である。一次情報よりわかりやすい情報がある一方で、誤った情報、前提が異なる環境の情報、バージョン違いで使ってはいけない情報などが圧倒的に多くあって、失敗を積み重ねるうちに付き合い方がわかってくる。慣れてくると、英語ではないまったく読めない言語で書かれたブログ上に記載されているコンフィグファイルが助けてくれる、ということがよくある。
よい一次情報の例
- react-responsive-carousel
- 開発者向けのウェブ技術
- リアクティブ宣言
- The Twelve-Factor App
- NIST Cloud Computing Program - NCCP
- Reactスタートガイド
- MUI
- Bootstrap
装備
エンジニア、またはエンジニアを目指す人であれば、何らかの RPG をプレイした経験があるはずだ。ゲーム内では適正な装備を用意することで、快適に旅を進めるられるようになり、また他のメンバーの足を引っ張らないですむようにもなれる。
エンジニアにも３種の神器的な技術が存在する。
私にとっての３種の神器
- VSCode
- Github
- Docker
これらはあくまでも私個人にとっての３種の神器であるが、プロジェクトごとにいくつかの Docker コンテナを用意し開発環境を構築している。 docker volume コマンドでコンテナ内のディスク領域をマウントし、この領域を VSCode で編集し、これを Github でホストしている。
Docker
コンテナ仮想化を用いた完全に隔離された開発、実行環境を構築できるもの。Dockerを利用することにより以下メリットが得られる。
- 各エコシステムの公式コンテナイメージを利用することにより、開発コミュニティが推奨するエコシステム実行環境をそのまま利用できる
- 公式コンテナイメージの導入、必要なモジュールのインストール、ネットワークなどのパラメータ設定がコード化できるので、同一環境の構築が容易となり環境構築の再現性を高めることができる
- コンテナ内で行われた変更や実行結果がコンテナ外を汚染することがない
- Dockerコンテナは 1プロセスで 1コンテナを割り当てるためマイクロサービスアーキテクチャを自然に実践でき地方分権が促進される
-
docker volumeコマンドで、ホストOS (たとえばmacOS) 上の特定のフォルダを Docker で利用できるようになり、データを永続的に利用できる
VSCode
OSS の テキストエディターであるが、多くのプラグインが存在し、必要なものを選択、組み合わせることで、IDE (統合開発環境) を上回る開発環境を構築できる開発環境である。VSCode とプラグインを利用することで以下のメリットが得られる。
- コードの誤りを教えてくれる
- 未定義の定数、変数、オブジェクト、データ構造、関数、パラメータ、外部ファイル
- 定数、変数、オブジェクト、データ構造、関数、パラメータ利用時の型、値の誤り
- 文法上の誤り (閉じていないカッコ、多すぎる閉じカッコ、成立してないタグ、キーバリューペア、式、コロン、セミコロン、カンマなど)
- 依存関係があるオブジェクトの設定もれと不要な設定
- 定義したものの使用していない定数、変数、オブジェクト、データ構造、関数
- マウスカーソルをホバーするといろいろ教えてくれる
- 定数、変数、オブジェクト、データ構造、関数、パラメータの型と制約
- 相対ファイルパスで指定した外部ファイルの絶対ファイルパス
- 指定のタイミングでコードを整形してくれる
- 自動インデント
- コーディング標準に準拠したコード整形
- 文字や文字列リテラルを囲うカッコを統一できる
- コマンド入力をうけつけてくれる
Github
みんな大好き、Github。ご存じない方にその導入メリットの一部をご紹介したい。
- コードを共有できる
- リモートリポジトリ (そのプロジェクトの全コードが含まれる大元になる管理単位) を手元PCにクローンできる
- 手元PCにクローンしたリポジトリ (ローカルリポジトリ) はいつでもリモートリポジトリ上の最新の状態にできる
- ローカルリポジトリにくわえた変更をリモートリポジトリに反映できる
- 変更をリモートリポジトリに反映する際にすでに他のユーザが変更済みの場合はその変更は拒絶され、他のユーザによる変更箇所を教えてくれる
- すべてのコード変更は記録され、いつ、誰が、どういう変更を行ったか確認できる
- すべてのコード変更は記録され、いつでも指定の状態まで戻すことができる
- ブランチを利用できる
- たとえば現在サービス提供中のブランチ (たとえば main ブランチ) と新規機能開発中のブランチ (たとえば nextmain ブランチ) と サービス提供中のコードに対する重大障害対応中のブランチ (たとえば hotfixfor4696 ブランチ) の３つのブランチでそれぞれコード変更を並行して行うなどのユースケースが考えられる
キャリアパス
エンジニア、またはエンジニアを目指す人であれば、何らかの RPG をプレイした経験があるはずだ。１つのジョブを極めて究極の装備を求める人、いくつかのジョブをそつなくこなす人、すべてのジョブのレベルを均等にあげる人 (この行為は尊敬の念をこめて「並行上げ」と呼ばれる) などプレイヤーのプレイスタイルはさまざまだ。
エンジニアのキャリアパスにも決まりはない。自由に進めればよいのだが、通常はエンジニアタイプに応じた本人が信じるキャリアパスを駆け抜けていく一方で、フルスタックエンジニアという並行上げ的なスキルセットを目指すエンジニアもいる。
これは私見だが、エンジニアの仕事に対する姿勢とは、非常に細かいことの積み重ねを、早く、正確に、コツコツ、コツコツ、コツコツコツコツ、コツコツコツコツコツコツコツコツ続けていくことだと思っている。これからエンジニアを目指す人は、何らかのエコシステムという巨人の肩にのって数行の魔法のコードを書くことでやりたいことを実現するスーパーエンジニアを夢想すると思う。でもそういうことは決してなくて、はじめに全体を見通したら、優先度が高い機能から、コツコツ、コツコツ作っていく。一発でキレイにつくることはできないので、最低限の機能を実現したら次の優先度の機能に移り、いつか元の機能を作り直す機会 (それが次の優先度になるまで) に作り直せる自分になるように努力する、というのが現実なんだと思っている。
よいキャリアパスの例
- 自分が信じる道を少しずつ進んでいく
- 自分のロールモデルとなる先輩エンジニアのいいところを取り入れたり、コツを教えてもらったりする
- ちゃんと動くものをつくりあげる
わるいキャリアパスの例
- 実務 = キャリアパス
- 資格を得ることをゴールにする
- Udemy の動画を眺めて学んだことにする
よいのかわるいのか判断できないキャリアパス
- 高額のお布施を包んでトレーニングに参加する
協力者
エンジニア、またはエンジニアを目指す人であれば、何らかの RPG をプレイした経験があるはずだ。ゲームのなかでは NPC と呼ばれる non player character が存在することがある。NPC は敵であったり味方であったり案内役であったり、アイテムの売買や交換に応じるものがいるのだが、特定の NPC を自身のロールモデルにするプレイヤーもいて、NPC がよい手本になる場合もある。
エンジニアの仕事は、キレイに仕事をするためには最低２名のペアが必要になってくる。このペアでペアプログラミングまたはコードレビューを繰り返すことが非常に重要になる。製品仕様やシステム設計の共有、バックログの着手検討、バックログ完了時のデモの実施などもレビューの実施が必須であり、これにはレビュアーという協力者が必要となる。
協力者の例
- お客様
- PO
- 開発時に利用する技術要素に関する有識者
- レビュアー
- 開発リーダー
- 開発メンバー
- システムアーキテクト
- aws コンサル
- PMO
- ファシリテーター
- エバンジェリスト
- 製品のモニターやテストをしてくれる人
- PM
敵をつくらないことがエンジニアにとっての最善となる。
失敗
エンジニア、またはエンジニアを目指す人であれば、何らかの RPG をプレイした経験があるはずだ。MMORPGの場合初心者はなるべく失敗しないように、他のプレーヤーに迷惑をかけないようにプレーしようとするんだと思う。でもベテランになるにつれ失敗することが大事だと思うようになり「初見」で自分がどう動けるか知りたくなる。「あのダンジョンには全員初見未予習で行こうよ」というプレイスタイルが生まれてくる。
エンジニアにとって失敗は必要な経験である。「もう一度やらせてくれてありがとう」と思えるようになると、早く、上手に失敗できるようになる。
失敗することのメリット
- つまずくポイントを自覚できるかもしれない
- エラーメッセージを見ることができるかもしれない
- エラーメッセージから問題を特定できるかもしれない
- トラブルシュートに必要な情報が不足しているかもしれない
- トラブルシュートに必要な情報をログに出力するコードが必要になるかもしれない
- 問題を解決できないかもしれない
- 問題を解決できなくても何らかの workaround を導けるかもしれない
- workaround をシステムに組み込むことによって先に進めるかもしれない
- 同じ失敗を繰り返す可能性があることを自覚できるかもしれない
- 同じ失敗を防止するための再発防止策を検討できるかもしれない
- 次に同様のつまずきがあったら前回より早く、上手に解決できるかもしれない
DX
エンジニア、またはエンジニアを目指す人であれば、何らかの RPG をプレイした経験があるはずだ。MMORPG の場合は不正プログラムや外部ツールの使用は禁止されている。
エンジニアにとってはあらゆる自動化が検討に値する。
自動化の例
- インフラ構築のコード化
- コードの構文チェックツールを用いた自動コードチェックの実施
- コードの自動整形ツールを用いた自動コード整形の実施
- コード変更をトリガーとする自動テストの実施
- コード変更をトリガーとする Code smell チェッカーによる自動コード品質チェックの実施
- コード変更やマージをトリガーとする各環境への自動デプロイ、自動ビルドの実施
みんな大好き、石角友愛氏はその著書で「DXのゴールはデジタル化したプロセスとビジネスモデルを恒久的に回しながらイノベーションを起こし続ける状態や、そのような組織体制の構築である」と言っている。またトーマス・シーベルの著書から以下を引用している。
「第一次から第三次までの産業革命は電気や機械などといったメカニカルなパワーを使いこなす変革だったの対して、第四次産業革命はメンタルパワーがデジタル化されることに伴う変革である」
私見ではあるが、エコシステムに支えられたパブリッククラウドのさまざまサービスや Firebase、Supabase といった BaaS、Vercel CDN、CodoPen、CodeSandbox のように「プロダクトを生むプロダクト」や「プロダクトを生むサービス」、「サービスを生むサービス」を提供する流れが加速していると感じている。そのようなサービスのためのサービスを提供するもよし、利用するのもまたよし、というエンジニア天国がここしばらく続くものと考えている。