Webの仕事をしていると言うと、「コード書くの大変そうですね」と言われることがよくあります。
たしかに大変です。
ただ、正直に言うと、コードを書いている時間よりも、
「書く前に確認している時間」のほうが長い日のほうが多いです。
これ、あまり表に出てこない話です。
外から見ると、
実装＝コードを書く作業
に見えがちだからだと思います。
でも現場にいると、
「あ、今日はコードあんまり書いてないな」
という日が普通にあります。
その代わりに何をしているかというと、
確認です。
とにかく確認。
今回は、
コードを書く前に確認していることの方が多い
という、かなり地味だけど現場っぽい「あるある」の話をします。
大きな教訓にまとめるつもりはありません。
裏側って、だいたいこんな感じです。
確認してからじゃないと 書けないものが多すぎる
コードを書く前に、まず確認します。
これ、習慣というより生存戦略です。
何を確認しているかというと、
・この仕様で合っているか
・その認識はチーム内で揃っているか
・今から書くものは本当に今必要か
こういうことです。
たとえば、デザインが上がってきたとき。
すぐに書き始められることは、実はあまりありません。
この画面はどのブラウザまで対応するのか。
レスポンシブの挙動はどこまで見るのか。
運用側はここを触るのか、触らないのか。
これが決まっていないと、
書けないというより、
書いてはいけない状態になります。
あとで「やっぱり違った」が一番つらいからです。
だから、
コードを書く前に、確認が増えます。
外から見ると、
「まだ書いてない」
「手が止まっている」
ように見えるかもしれません。
でも中では、
「書く前に潰せる不安を潰している」
だけです。
これ、現場あるあるです。
確認しているのは 技術の話だけじゃない
確認というと、技術的な話を想像されがちです。
もちろん、それもあります。
APIの仕様。
データの持ち方。
既存コードとの相性。
でも、実際に多いのは、もっと人間寄りの確認です。
この変更、誰が確認するのか。
どこまで直したらOKなのか。
これ、今やると別の作業に影響しないか。
ここが曖昧なまま書き始めると、あとで一気にしんどくなります。
だから、
「これって、どこまでやりますか」
「ここは今回は触らない認識で合ってますか」
という確認が増えます。
これも裏側です。
コードを書くより、聞いて、揃えて、止めて、確認する。
この時間が、実装の土台になっています。
派手ではありません。
成果物にも残りません。
でも、ここを飛ばすと、
だいたいどこかで詰まります。
確認が多い日は 仕事してない気がする
正直に言うと、確認ばかりしている日は、「今日、あんまり仕事してないな」と感じることがあります。
コードも増えていない。
画面も変わっていない。
成果が目に見えない。
でも、あとから振り返ると、その日の確認が効いていることが多いです。
あのとき確認したから、
後戻りしなかった。
あのとき止めたから、
手戻りがなかった。
そういう日です。
Webの現場って、作っているようで、実は「作らない判断」をたくさんしています。
確認もそのひとつです。
何でもすぐ書かない。
決まっていないものは書かない。
今やらなくていいものは書かない。
これ、かなり地味です。
でも、裏側はだいたいこうなっています。
あるあるとして 受け取ってもらえたら十分
この話、
「だから確認が大事です」
で締めるつもりはありません。
確認が多いから偉いわけでもない。
コードを書かないから楽なわけでもない。
ただ、Webの現場では、コードを書く前に確認していることの方が多い。
それだけの話です。
これを知っていると、実装が止まって見える時間の見え方が変わります。
新人の人なら、
「自分が遅いわけじゃないんだ」
と思えるかもしれません。
ディレクターなら、
「今、何を確認している時間か」
を想像しやすくなるかもしれません。
笑って終わってもいいです。
「まあ、そういうもんです」で十分です。
裏側って、だいたいこんな感じです。
