コードを書くことが、仕事じゃない
コードを書く。
新しい技術を覚える。
いくつものプログラミング言語を学び、パソコンに向かって、自分が考えたものを少しずつ形にしていく。
そして、思ったとおりに動いた瞬間。
これは、本当に嬉しいものです。
エンジニアという仕事には、ものを作る楽しさがあります。
でも、ひとつ忘れたくないことがあります。
コードを書くことそのものが、エンジニアの仕事ではありません。
完成を決めるのは、コードの量ではない
システムを使った人が、
「あら、便利。」
「これ、助かる!」
と思ってくれる。
これまで困っていたことが、少し楽になる。
時間がかかっていた仕事が、早く終わる。
間違えやすかった作業で、迷わなくなる。
エンジニアが作っているのは、本当はそういう変化なのではないでしょうか。
だから、何千行のコードを書いても、解決したかった課題が残っているなら、仕事はまだ完成していません。
反対に、たった1行のコードでも、それで誰かの困りごとが解決するなら、その1行には大きな価値があります。
コードの量ではなく、その先で何が変わったか。
そこに、エンジニアの仕事の成果があります。
自分や家族のためなら、何を作るだろう
少し、仕事から離れて考えてみましょう。
自分や家族のために、小さなシステムを作るとします。
「朝、これを自動で教えてくれたら楽なのに。」
「ここを押したら家族に通知が届いたら便利だな。」
「これ、忘れやすいから前日に知らせてくれたら助かる。」
そんなところから考え始めるのではないでしょうか。
自分が使って「むふふ」と嬉しくなる機能。
家族が「うわぁ、便利!」と笑顔になる仕掛け。
作りたいのはコードではありません。
その先に起きる、小さな嬉しい変化です。
だから、まず現状を見る
仕事でシステムを作るときも、同じです。
まず、今そこで何が起きているのかを見る。
誰が困っているのか。
何に時間がかかっているのか。
どこで間違えるのか。
そして、
- 何を変えれば役に立つのか
- 誰のための機能なのか
- どこまで自動化すればよいのか
- 結果を誰に知らせるのか
- いつ知らせるのか
- どんな方法なら、その人にとって負担が少ないのか
を考える。
その答えが見えてから、コードの出番です。
必要なら自分で作る。
すでに良い仕組みがあるなら、それを使う。
APIをひとつ呼ぶだけで解決するなら、それでもいい。
大切なのは、どれだけ作ったかではなく、課題をどれだけ良くできたかです。
エンジニアは、変化をつくる仕事
コードを書く技術は、もちろん大切です。
その技術がなければ、考えたものを形にすることはできません。
でも、その技術を何のために使うのか。
そこには、前回お話しした想像力があります。
使う人を想像し、
その人が困っていることを見つけ、
どうすれば少し良くなるのかを考え、
そして技術で形にする。
だから、エンジニアの仕事を一言で表すなら、
「コードを書く仕事」ではなく、「技術を使って、より良い変化をつくる仕事」
なのかもしれません。
Engineering Time
コードが動いた。
それは、とても嬉しい瞬間です。
でも、その先で、
誰かが「あら、便利」と笑ってくれたら。
そこで初めて、そのコードは誰かの役に立つものになります。
仕事は、コードを書くことではなく、課題を解決すること。
そして、そのためにコードという素晴らしい道具があります。