Webエンジニアの力を6軸×5段階で言葉にする　次に伸ばす1軸の決め方

「動いてはいるけど不安」「もっと堅く作って」と言われても、次に何をすればいいのかは分かりません。エンジニアの伸び悩みは、たいてい書いたコードの量ではなく、どの力がどう足りないのかを言葉にできていないことから来ています。

ここでは、Webエンジニア（バックエンド寄りの開発者）の力を6つの軸に分け、それぞれを5つの段階として整理します。自分がいまどのあたりにいて、次に何を上げればいいのかを決めるための物差しです。

後半では、目指す地点の決め方から伸ばす順番、次に上げる軸の絞り方まで、この物差しの使い方も扱います。

マークアップや画面まわりの実装はコーダー編で扱っているので、Web制作が主戦場の場合はあちらと組み合わせてください。

Webエンジニアの力は6つに分けられる
Webエンジニアの現在地を5つの段階で測る
目指すのは全軸Lv5ではない
伸ばす順番を飛ばさない
1軸だけ選び、1段階だけ上げる
まとめ

Webエンジニアの力は6つに分けられる

「開発ができる」と一口に言っても、その中身は同じではありません。実装は速いのに公開後の障害が多い人もいれば、コードはきれいなのに外部連携のエラーで止まる人もいます。ひとまとめにしている限り、次の一手は決まりません。

プログラミング: 動くだけでなく、読める・直せるコードを書けるか
テスト・デバッグ: 壊れていないことを、確かめられるか
セキュリティ: 攻撃されることを前提に、書けるか
データベース: データの構造を設計し、安全に扱えるか
API・外部連携: 外部のサービスと、落ちても壊れない形でつなげられるか
保守・運用: 公開後のシステムを、動かし続けられるか。バージョン管理と安全な反映手順もここに含む

この6つを、それぞれ5段階に分けます。段階が言葉になっていると、「なんとなく足りない」が「この軸のこの段階にいる」に変わります。

全体はこの一枚に収まります。軸ごとに横へ読んで、いちばん近いマスに印を付けてください。6つの印を縦に見比べると、自分の凸凹が見えてきます。

軸	Lv1	Lv2	Lv3	Lv4	Lv5
プログラミング	動けば終わり	半年後の自分が読めない	他人が読めるコードを書ける	変更に強い構造を選べる	標準を作り展開する
テスト・デバッグ	壊れているのは公開後に分かる	正常系しか試さない	異常系まで確かめる	自動化で防げる	戦略と基準を作る
セキュリティ	入力を信じてしまう	穴の場所が分からない	基本を組み込める	設計段階で防げる	基準を定め監査に対応できる
データベース	重複だらけになる	制約を考えない	設計して遅さを直せる	将来を見込んで設計できる	方針と移行を設計する
API・外部連携	貼って動かすだけ	失敗への備えがない	安全に実装できる	落ちても止まらない作り	選定から判断できる
保守・運用	納品したら終わり	連絡が来てから動く	原因を追える	先に手を打てる	体制を設計する

Webエンジニアの現在地を5つの段階で測る

Lv2以降の冒頭には、前の段階から何が変わるのかを一文で置いてあります。まずそこで自分の当たりをつけ、6つの軸ごとの記述で、いちばん近い段階を確かめてください。記述はどれも典型例なので、ぴったり一致していなくて構いません。Lv1は脱しているが、Lv3には届いていない。その場合は、間のLv2です。

読むときのコツが1つあります。自分がよく見えるほうを選ばないことです。「やろうと思えばできる」ではなく、直近の案件で実際にできたほうを取ってください。また、フレームワークが肩代わりしてくれている処理を、自分の力に数えないでください。ここを甘く見ると、あとの判断がすべてずれます。

AIにコードを書かせたかどうかは、判定には関係ありません。出てきたコードの動作とセキュリティを自分で確かめ、読める形に直せたなら「できた」に入ります。動いたからそのまま本番に入れたなら、それは出どころがコピペサイトからAIに変わっただけで、Lv1の継ぎ足しと同じです。

Lv1　動いた、で終わる

動くことと壊れないことの区別が、まだありません。

プログラミング: なぜ動いているのか分からないので、消したら壊れそうなコードがファイルに溜まっていく
テスト・デバッグ: 確認は正しい値を1回入れて動かすだけ。変な値を最初に入れるのは、公開後のユーザー
セキュリティ: フォームには善意の人しか来ない前提で、入力をそのまま処理している
データベース: 顧客名がひとつ変わると、あちこちのテーブルを手で直して回る
API・外部連携: 相手のAPIが止まる日のことは、考えたことがない
保守・運用: エラーログは、障害の連絡が来てから探し始める

Lv2　作れるが、壊れたときに弱い

Lv1との違いは、求められたものをひととおり作れることです。ただし、異常系と半年後の変更には、まだ弱いままです。

プログラミング: 動くものは書けるが、半年後の自分が読めないコードになる
テスト・デバッグ: 動作確認はするが正常系だけで、境界や異常系を試さない
セキュリティ: 対策の名前は知っているが、自分のコードのどこに穴があるかは分からない
データベース: 言われたとおりのテーブルは作れるが、正規化や制約を考えない
API・外部連携: つなげられるが、エラーやタイムアウトへの備えがない
保守・運用: 障害の連絡が来てから対応する。原因が分からないことも多い

Lv3　壊れにくく作り、壊れたら直せる

Lv2との違いは、うまくいかない場合を前提に作れることです。エラー処理、異常系の確認、原因の切り分けが自分の型になっています。

プログラミング: 命名・関数分割・エラー処理まで揃えて、他人が読めるコードを書ける
テスト・デバッグ: 異常系や境界値まで確認し、不具合の原因を切り分けて特定できる
セキュリティ: 入力検証・エスケープ・認証認可の基本を、実装に組み込める
データベース: 正規化とインデックスを理解して設計し、遅いクエリを直せる
API・外部連携: 認証・エラー処理・リトライまで含めて、安全に連携を実装できる
保守・運用: ログと監視を仕込み、障害の原因を追える。更新を安全に反映できる

ここが、実装をひとりで任せられる状態のひとつの区切りです。

Lv4　設計で、問題を先に潰せる

Lv3との違いは、実装に入る前の設計で問題を潰せることです。変更・負荷・攻撃・障害を見込んで、形を選べます。

プログラミング: 設計パターンを使い分け、変更に強い構造を選べる
テスト・デバッグ: テストを自動化し、修正のたびに壊れていないことを仕組みで確かめられる。小規模受託や少人数の開発を想定した位置づけで、CIが整った現場ではもっと早くから求められる
セキュリティ: 脆弱性を想定してレビューでき、設計段階で防げる
データベース: データの規模と将来の変更を見込んで設計できる
API・外部連携: 障害時の影響範囲を設計し、外部が落ちても止まらない作りにできる
保守・運用: 負荷や劣化を予測して、障害が起きる前に手を打てる

Lv5　チームの標準を、作る

Lv4との違いは、対象が自分のコードからチームに変わることです。自分が書くことより、チームが安全に作れる状態を作ることが仕事になります。

プログラミング: 設計標準やレビュー基準を作り、チームに展開する
テスト・デバッグ: テスト戦略と品質基準を作り、チームに定着させる
セキュリティ: セキュリティ基準を定め、診断や監査に対応できる
データベース: データ全体の設計方針を決め、移行を設計できる
API・外部連携: 連携全体の構成を設計し、どのAPIを使うかの選定から判断できる
保守・運用: 運用の体制と基準を設計し、改善を回せる

目指すのは全軸Lv5ではない

5段階と聞くと、全部をLv5にするのがゴールに見えます。そうではありません。

Lv5は「その職種のトップ」の姿であって、全員が目指す地点ではありません。多くの実務は、各軸がLv3であれば問題なく回ります。

補足

当面のゴールは、全軸Lv3です。突出した軸を作るより、Lv1やLv2で止まっている軸を無くすほうが、実務では効きます。

全軸がLv3に揃ったあとのLv4は、全員が順に目指す段階ではなく、役割で選ぶ段階です。設計を任される、レビューする側に回るなど、立場が変わるタイミングで、その仕事に使う軸から上げていきます。

もうひとつ、ゴールの置き方で注意があります。平均点を上げることをゴールにしないでください。6軸の平均が3.2から3.4になったところで、現場で何ができるようになったのかは説明できません。上がったのはどの軸か、そこで何ができるようになったのかだけが意味を持ちます。

伸ばす順番を飛ばさない

6つの軸は横並びではありません。土台になる軸が低いまま上の軸を鍛えても、どこかで頭打ちになります。

Webエンジニアの場合はこの順番です。それぞれ、まずLv3まで上げることを目安にしてください。

プログラミング

命名・関数分割・エラー処理まで揃えて、他人が読めるコードを書けるところまで。
テスト・デバッグ

異常系や境界値まで確認して、原因を切り分けて特定できるところまで。
セキュリティ

入力検証・エスケープ・認証認可の基本を、実装に組み込めるところまで。
データベース

正規化とインデックスを理解して設計し、遅いクエリを直せるところまで。
API・外部連携

認証・エラー処理・リトライまで含めて、安全に連携を実装できるところまで。
保守・運用

ログと監視を仕込んで、障害の原因を追えるところまで。

テスト・デバッグが2番目と早いのは、意外に見えるかもしれません。データベースや外部連携より先なのかと。しかし、異常系を確かめる型は、以後のすべての軸の学びを速くします。データベースも連携も、「試して、壊して、確かめる」ことで身につくからです。確かめる型が先にあると、新しい領域を恐れずに触れます。セキュリティが3番目でデータベースより先なのは、Webは公開した瞬間から攻撃されるからです。動くものを作る力より先に、壊されないものを作る意識が要ります。

保守・運用が最後なのは、時系列として公開後の軸だからで、軽いからではありません。Lv1の「納品したら終わり」を抜け出すのに特別な才能は要りません。読めるコード、確かめる型、攻撃への備え。ここまでの5軸が揃った人の運用は、自然と回り始めます。

1軸だけ選び、1段階だけ上げる

現在地が分かったら、次に伸ばす軸を1つだけ選びます。選ぶのは、前の章の順番で最初にLv3に届いていない軸です。一度に全部は上がりません。6軸を同時に意識した瞬間、どれも動かなくなります。

選んだら、上げるのは1段階だけです。Lv2の軸をLv4にしようとせず、Lv3にすることだけを考えます。

上げ方は、難しく考えなくて構いません。次の段階の記述が、そのまま次の案件で試す行動です。プログラミングをLv2からLv3にするなら、いま書いているPHPのコードで、命名・関数分割・エラー処理を他人が読める形に揃えてみる。その繰り返しです。

このとき、「なんとなくLv2」で済ませないでください。どの案件のどの場面でそう判断したのかを、具体的に言葉にします。根拠が書けない判定は、次に何をすればいいかを教えてくれません。

あわせて、その段階に上がったと言える条件も先に決めておきます。決めていないと、上がったかどうかを気分で判断することになります。

言葉にすると、たとえばこのくらいの具体さです。

エンジニア本人テスト・デバッグはLv3にしました。先月の会員機能の改修で、退会済みユーザーのログインや空の入力などの異常系を一覧にして試して、公開後の不具合をゼロにできたからです。

先輩エンジニアその判定でいいと思います。次はセキュリティですね。同じ改修のレビューで、検索フォームの入力を検証せずにSQLに渡している箇所を指摘したので、いまはLv2。入力検証とプリペアドステートメントが自分の実装の標準になったらLv3、と決めましょう。

見直しは1〜2ヶ月ごとで十分です。同じ軸が2回続けて動いていなかったら、やり方を変えるか、そもそもその軸を選んだ前提を疑ってください。

できれば、同じ6軸で他の人にも見てもらってください。自己判断と食い違った軸が、最初に話すべき論点になります。