日々仕事をしていると日常の素晴らしさを感じるのです。サクサクと仕事を進めて、しっかりと成果を出していく。チームメンバーとの関わりを深める中で、自分の役割を果たして、設計をプロダクトに反映して使ってもらう。そのための基礎としてのエンジニアリングがあって、着実に成果を出していく。それは日々の屋台骨を支えていて、活動を見守っていく。
私にとっては毎日が変化に富んでいるのです。毎日コードを書いているだけに見えても、それは全く違うものです。楽器の練習をしていてただ毎日ドレミファソラシドを弾いているように見えても日々変化があるように、コードを書くことはそれだけで変化があります。求められているものが同じでも描き方が少しずつ良くなっていったり、何を作るのかの判断が変わっていたりします。何を作るかの判断というのはどのように作るかの前の段階に常にあり、どのように作るかを支配するのです。何を作るか、を丁寧にやっていくことが、翌日の変化につながります。
私は 地味な時間 が好きなのです。そしてベストはないのです。今日書いているコードはきっと1週間も経てばより良い方法が見えていることはよくあります。明日のほうが今日のコードより良いことはよくあって、それは歓迎されるべきです。だから、あまりその時点での仕事の出来を賞賛しなくてもいいし、日々少しずつ良くすることが気がついたら半年後には大きな差になっていく。そういう職業なのだと思っていますし、そう感じています。なのでどの時点においても、その瞬間ではより良い選択をしたであろうと確信を持ちつつも、次の瞬間ではまた違う可能性を検討し始めるというのが日常なのです。
可能性があるということ は脆いことだと思っているのです。エンジニアリングというのは、決定をしながら可能性を狭めていくという側面があります。より拡張性があり、安定した方向に決定をするのです。それはコードの一行一行の場合もあれば、どのような機能を作るのかという場面でもあります。決めることを、当たり前にできるということ。これが日常で、そのための準備をそれ以外の時間にするというのが仕事なのです。
なのでベストだと言われると少し違和感があるのです。でもそういったコツコツとした日々の仕事が評価されるということは嬉しいものです。チームメンバーに恵まれ、今やっていることが少なからず認められるというのは嬉しいものです。なので私自身は自分をベストだとは全然思わないけれども、そうしたある時点で切り取った何かがよかったと言ってもらえるのは嬉しく、それはプロダクトへの褒め言葉でもあります。私は私個人が褒められるより、プロダクトが褒められる方が嬉しいのです。そういう意味で、ああこの半年の動きはよかったのだなと思った金曜日の夜だったのでした。ありがとうございました。
---
加筆
可能性を狭める、というと悲観的な印象があるかもしれません。これはリスクをある程度まで抑える、コントロールする、ということです。リスクはゼロにはなりません。ソフトウェアとして可用性を担保するのは当然として、事業としてこの方向性に行くか行かないか、ということを判断していくというのがここでいう可能性、に近いものです。ソフトウェアとして選択肢が多いと、リスクも増えるのです。それを予測して、どこのリスクを許容するか、ということを考えているように思います。その点で、やはりベストはないのです。
