ITの仕事はコードが書ければ十分だと思っていた

学生の頃、私はIT業界をとてもシンプルに考えていました。

成功したければコードを書けるようになればいい。

技術力が高いほど価値がある。

より多くの言語を覚える。

より多くのフレームワークを学ぶ。

難しいソースコードを読めるようになる。

そんなふうに考えていました。

当時の私には、それ以外の道は見えていませんでした。

社会人になってからの数年間は、だいたい想像していた通りでした。

コードを書く。

バグを直す。

リリースする。

締切に追われる。

時々残業する。

開発者としての毎日は、とても分かりやすいものでした。

考え方が変わり始めたのは、日本のお客様と仕事をするようになってからです。

技術的な視点だけで見ると、そこまで詳しくない人たちにたくさん出会いました。

営業の人。

コンサルタントの人。

プロジェクトマネージャーの人。

中には技術を深く理解していない人もいました。

それでも、その人たちは大きな価値を生み出していました。

お客様を理解していました。

良い質問ができました。

関係者を同じ方向へ導いていました。

曖昧なアイデアをプロジェクトに変えていました。

そしてプロジェクトをビジネスに変えていました。

正直、最初はよく分かりませんでした。

なぜこの人たちはこんなに重要なんだろう。

なぜお客様は開発者よりも彼らと話したがるんだろう。

なぜ会社は彼らを必要としているんだろう。

そんなことを考えていました。

何年も経ってから、ようやく少し分かった気がします。

お客様はソースコードを買っているわけではありません。

結果を買っているのです。

今では当たり前に聞こえるかもしれません。

でも私はこの意味を理解するのに何年もかかりました。

お客様はフレームワークのことで眠れなくなることはありません。

アーキテクチャの議論をしたいわけでもありません。

JavaかGoかを気にしているわけでもありません。

少なくとも最初は。

お客様が本当に知りたいのはもっとシンプルです。

この問題は解決できるのか。

それだけです。

その頃から、私はこの仕事を少し違う角度で見るようになりました。

今でも技術は好きです。

今でもコードを書きます。

今でも何かを作るのが好きです。

コードが重要ではないと言いたいわけではありません。

むしろ、とても重要なスキルだと思っています。

ただ、それが仕事のすべてではないと思うようになりました。

長く働くほど、ソフトウェアはコードだけで作られているわけではないと感じます。

人。

コミュニケーション。

信頼。

期待値。

意思決定。

責任。

そして時には、誰も本当には理解していないまま終わる長い会議。

たぶん、それがこのサイトを Andy Don’t Like Code と名付けた理由です。

コードが嫌いだからではありません。

そうではありません。

ただ、毎年少しずつコードが上手くなることだけに、自分のキャリアを使いたくなかったのです。

私はコードが書かれる前に何が起きているのか、そちらの方に興味があります。

そして今も、その答えを探し続けています。