コーダーの力を6軸×5段階で言葉にする　次に伸ばす1軸の決め方

「もっと丁寧に」「もっと速く」と言われても、次に何をすればいいのかは分かりません。伸び悩みは、たいてい頑張りの量ではなく、どの力がどう足りないのかを言葉にできていないことから来ています。

ここでは、コーダーの力を6つの軸に分け、それぞれを5つの段階として整理します。自分がいまどのあたりにいて、次に何を上げればいいのかを決めるための物差しです。

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

想定しているのは、制作会社などで実務としてコーディングをしている人です。働く場所が違っても、軸の考え方はそのまま流用できます。

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

コーダーの力は6つに分けられる

「コーディングができる」と一口に言っても、その中身は同じではありません。マークアップは丁寧なのに見積もりが立たない人もいれば、実装は速いのに公開後に誤字が見つかる人もいます。ひとまとめにしている限り、次の一手は決まりません。

HTML/CSS: マークアップの意味を理解し、崩れない構造で組めるか
レスポンシブ対応: どの画面幅でも破綻せずに見せられるか
JavaScript: 自力で書けるか、動くものを借りてきているか
再現度・品質: デザインどおりに作れて、自分で確認できるか
開発環境・運用: バージョン管理や環境構築を扱えるか
スピード・見積もり: かかる時間を読めて、それを守れるか

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

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

軸	Lv1	Lv2	Lv3	Lv4	Lv5
HTML/CSS	力技で見た目を合わせる	指示どおりには組める	意味で組める	設計を持って書ける	標準を作り展開する
レスポンシブ対応	スマホで崩れる	指定の幅しか守れない	実機で確認できる	折り返しを設計できる	デザインに助言できる
JavaScript	貼り付けるだけ	改修ならできる	自力で実装できる	非同期やAPIを扱える	技術選定ができる
再現度・品質	ズレやミスが残る	指摘されれば直せる	自分で確認できる	アクセシビリティまで配慮できる	品質基準を定義する
開発環境・運用	FTPで直接アップ	Gitの基本操作だけ	ブランチ運用ができる	環境を構築できる	フロー全体を設計する
スピード・見積もり	見積もりが立たない	遅れは伝えられる	見積もれて守れる	代替案を出せる	チームの段取りを組む

コーダーの現在地を5つの段階で測る

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

読むときのコツが1つあります。自分がよく見えるほうを選ばないことです。「やろうと思えばできる」ではなく、直近の案件で実際にできたほうを取ってください。ここを甘く見ると、あとの判断がすべてずれます。コーダーの場合、手元のブラウザで表示が合っていたことを「できた」の根拠にしがちですが、なぜそう組んだのかを説明できてはじめて判定の材料になります。

AIを使ったかどうかは、判定には関係ありません。AIが出したコードの良し悪しを自分で判断でき、崩れたときに自分で直せたなら「できた」に入ります。動いたからそのまま貼っただけなら、それは出どころが検索からAIに変わっただけで、Lv1の貼り付けと同じです。

Lv1　見た目が合っていれば終わり

なぜそのタグなのか、なぜ崩れたのかまでは、まだ考えが回りません。

HTML/CSS: ずれるたびに数字を足して合わせるので、CSSに margin: 37px のような謎の数値が残っていく
レスポンシブ対応: 自分のPCでは完璧。崩れていることは、スマホで開いた人の指摘で知る
JavaScript: ページごとに、出どころの違うスライダーが動いている
再現度・品質: 誤字脱字やリンク切れは、お客さんからの連絡で見つかる
開発環境・運用: 本番サーバにFTPで直接アップ。上書きの瞬間だけ、少し祈っている
スピード・見積もり: 見積もりは立たない。「あとどれくらい？」に「もうすぐです」と答えて3日経つ

Lv2　指示どおりには組めるが、崩れると止まる

Lv1との違いは、指示があれば最後まで作り切れることです。ただし、想定外が起きたときに自力では進めません。

HTML/CSS: 言われたとおりには組めるが、崩れたときに原因が分からない
レスポンシブ対応: 指定されたブレークポイントには対応できるが、その中間の幅で崩れる
JavaScript: 既存コードの改修ならできるが、ゼロからは書けない
再現度・品質: 指摘されれば直せる。裏を返すと、指摘されるまで気づけない
開発環境・運用: Gitは基本操作だけできて、コンフリクトが出ると詰まる
スピード・見積もり: 見積もりはまだ立てられないが、遅れそうなことは途中で伝えられる

Lv3　実務がひととおり回る

Lv2との違いは、指摘や助けを待たずに、自分で気づいて自分で直せることです。

HTML/CSS: セマンティックなマークアップができ、FlexとGridを場面で使い分けられる
レスポンシブ対応: 主要なデバイスで破綻せず、実機で確認する習慣がついている
JavaScript: DOM操作やイベント処理を自力で実装できる
再現度・品質: デザインの意図を崩さずに再現でき、ブラウザ間の表示差も含めて公開前に自分でチェックできる
開発環境・運用: Git運用ができ、ブランチを切って作業を進められる
スピード・見積もり: 自分の作業時間を見積もれて、おおむね守れる

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

Lv4　設計を持って書ける

Lv3との違いは、手を動かす前に設計を考えられることです。目の前の1ページだけでなく、規模の拡大や変更にも耐える形で書けます。

HTML/CSS: 命名規則や設計手法を自分の中に持ち、規模が大きくなっても破綻しないCSSを書ける
レスポンシブ対応: ブレークポイントを指定されるのではなく、コンテンツを基準に最適な折り返しを設計できる
JavaScript: 非同期処理やAPI連携を扱え、書く前に設計を考える
再現度・品質: 見た目の再現だけでなく、アクセシビリティやパフォーマンスまで配慮できる
開発環境・運用: ビルドツールやCMS（テーマ実装程度）を扱え、環境そのものを構築できる
スピード・見積もり: 工数を踏まえて「この方法なら間に合います」と代替案を出せる

Lv5　標準を作り、チームに展開する

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

HTML/CSS: 設計標準を策定し、チームに展開する
レスポンシブ対応: デザイン段階から、実装可能性を助言できる
JavaScript: フレームワークを使いこなし、技術選定ができる
再現度・品質: 品質基準を定義し、レビューを任される側に回る
開発環境・運用: 開発フロー全体を設計し、改善する
スピード・見積もり: チーム全体の工数を見て、段取りを組む

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

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

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

補足

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

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

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

伸ばす順番を飛ばさない

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

コーダーの場合はこの順番です。それぞれ、まずLv3まで上げることを目安にしてください。

HTML/CSS

意味を考えてマークアップでき、FlexとGridを場面で使い分けられるところまで。
再現度・品質

デザインの意図を崩さずに再現でき、公開前に自分でチェックできるところまで。
レスポンシブ対応

主要なデバイスで破綻せず、実機で確認する習慣がつくところまで。
開発環境・運用

Git運用ができ、ブランチを切って作業を進められるところまで。
JavaScript

DOM操作とイベント処理を、自力で実装できるところまで。
スピード・見積もり

自分の作業時間を見積もれて、おおむね守れるところまで。

再現度・品質が2番目に来ているのは、自分の成果物を自分で確認する目が、この先のすべての軸の土台になるからです。3番目のレスポンシブ対応で崩れに気づけるかどうかも、この確認の習慣の上に載っています。

JavaScriptが後半にあるのは意外に見えるかもしれません。これはJavaScriptを軽く見ているのではありません。DOM操作もイベント処理も、対象になるのはHTMLです。構造を意味で組めていない段階でJavaScriptだけ鍛えても、崩れたときに原因を切り分けられません。開発環境・運用がその手前にあるのも同じく準備のためで、Gitでいつでも戻せる状態を先に作っておけば、JavaScriptで恐れずに試行錯誤できます。

スピード・見積もりが最後なのは、後回しでいいという意味ではありません。かかる時間は、他の5つの軸の作業が安定してはじめて読めるようになります。先にこれだけを鍛えることはできない、結果として付いてくる軸です。

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

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

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

上げ方は、難しく考えなくて構いません。次の段階の記述が、そのまま次の仕事で試す行動です。レスポンシブをLv2からLv3にするなら、次の案件で公開前に実機を開き、中間の幅の崩れを自分で見つけて直す。その繰り返しです。

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

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

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

コーダー本人 HTML/CSSはLv3にしました。先月のキャンペーンLPで、見出しの階層を自分で判断して組めて、途中で崩れたときも自分で直せたからです。

先輩コーダーその判定でいいと思います。次はレスポンシブですね。同じ案件で、タブレットの中間の幅の崩れに気づけていなかったので、いまはLv2。公開前に実機で確認する習慣がついて、崩れを先に自分で見つけられるようになったらLv3、と決めましょう。

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

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