コードを書くことが、仕事じゃない

コードを書く。

新しい技術を覚える。

いくつものプログラミング言語を学び、パソコンに向かって、自分が考えたものを少しずつ形にしていく。

そして、思ったとおりに動いた瞬間。

これは、本当に嬉しいものです。

エンジニアという仕事には、ものを作る楽しさがあります。

でも、ひとつ忘れたくないことがあります。

コードを書くことそのものが、エンジニアの仕事ではありません。

完成を決めるのは、コードの量ではない

システムを使った人が、

「あら、便利。」

「これ、助かる!」

と思ってくれる。

これまで困っていたことが、少し楽になる。

時間がかかっていた仕事が、早く終わる。

間違えやすかった作業で、迷わなくなる。

エンジニアが作っているのは、本当はそういう変化なのではないでしょうか。

だから、何千行のコードを書いても、解決したかった課題が残っているなら、仕事はまだ完成していません。

反対に、たった1行のコードでも、それで誰かの困りごとが解決するなら、その1行には大きな価値があります。

コードの量ではなく、その先で何が変わったか。

そこに、エンジニアの仕事の成果があります。

自分や家族のためなら、何を作るだろう

少し、仕事から離れて考えてみましょう。

自分や家族のために、小さなシステムを作るとします。

「朝、これを自動で教えてくれたら楽なのに。」

「ここを押したら家族に通知が届いたら便利だな。」

「これ、忘れやすいから前日に知らせてくれたら助かる。」

そんなところから考え始めるのではないでしょうか。

自分が使って「むふふ」と嬉しくなる機能。

家族が「うわぁ、便利!」と笑顔になる仕掛け。

作りたいのはコードではありません。

その先に起きる、小さな嬉しい変化です。

だから、まず現状を見る

仕事でシステムを作るときも、同じです。

まず、今そこで何が起きているのかを見る。

誰が困っているのか。

何に時間がかかっているのか。

どこで間違えるのか。

そして、

  • 何を変えれば役に立つのか
  • 誰のための機能なのか
  • どこまで自動化すればよいのか
  • 結果を誰に知らせるのか
  • いつ知らせるのか
  • どんな方法なら、その人にとって負担が少ないのか

を考える。

その答えが見えてから、コードの出番です。

必要なら自分で作る。

すでに良い仕組みがあるなら、それを使う。

APIをひとつ呼ぶだけで解決するなら、それでもいい。

大切なのは、どれだけ作ったかではなく、課題をどれだけ良くできたかです。

エンジニアは、変化をつくる仕事

コードを書く技術は、もちろん大切です。

その技術がなければ、考えたものを形にすることはできません。

でも、その技術を何のために使うのか。

そこには、前回お話しした想像力があります。

使う人を想像し、

その人が困っていることを見つけ、

どうすれば少し良くなるのかを考え、

そして技術で形にする。

だから、エンジニアの仕事を一言で表すなら、

「コードを書く仕事」ではなく、「技術を使って、より良い変化をつくる仕事」

なのかもしれません。

Engineering Time

コードが動いた。

それは、とても嬉しい瞬間です。

でも、その先で、

誰かが「あら、便利」と笑ってくれたら。

そこで初めて、そのコードは誰かの役に立つものになります。

仕事は、コードを書くことではなく、課題を解決すること。

そして、そのためにコードという素晴らしい道具があります。

横山 愛子

横山 愛子

顧客支援及び運営担当

2014年1月に入社。関西外国語大学卒業後、貿易商社での勤務、オンラインストアの立ち上げ、運営、15年に亘る海外在住経験あり。幅広い視野を持って、お客様とのコミュニケーションに努めたいと思っております。