軸
前回の記事を書いた後に、「具体的にどういうことで頭を殴られたの？」と何人かの方に聞かれたので、今回はそのあたりのことについて、自分が日々考えていることを書いてみたいと思います。
◆ エンジニアとしての矜持
受託開発が中心の会社にある技術開発の部署で、いろいろな技術を先行的に調査するような仕事をしていると、難易度の高い技術の要諦をいかに早くつかむかが重要だと思えてきます。これはこれで、きっと正しかったのだろうと思います。しかし、その仕事を続けた結果として、いつしかその技術が何のためにあるのかと考えること忘れてしまっていたような気がします。
平易な技術について考えることは誰でもできる。だったら他の誰もが考えられないような難易度の高い技術について考えよう。それが自分がここで仕事をしている意義だと。そうやって、技術というものに対する比重がどんどん大きくなっていった気がします。
◆ 価値
転職して自社のサービスを開発する立場になると、期待されることは一変して、どんな実装をしても、どんな技術を使っていたとしても、ユーザーの価値さえ向上するなら何でもよい環境になりました。極端な話として、どうしようもない実装をしても評価され、イケてる実装をしても評価されないということが起こりうるわけです。そこまでの例はさすがにありませんが、似たようなことは実際にあって、エンジニアとしては簡単に納得できる話ではありませんでした。そりゃそうです。何のために日々膨大な時間とお金を使って学んでいるのかという話です。イケてる実装をするためではないのかと。
一方で、ユーザー価値の向上こそが唯一にして最大の評価点だというのも、冷静に考えればそのとおりです。我々エンジニアはそのために存在しているわけですから。このこと自体は、受託開発だろうと自社サービスの開発だろうと変わらないはずです。ここがまさに殴られポイントです。頭では分かっているつもりでも、どうしても条件反射というか、これまで培ってきて自分の根底に流れている価値観からそう思えない。なぜだろう、何が間違っているのだろうと考える日々が始まります。
実際に自分がこれまでに経験した事例をご紹介するのはややはばられるので、あくまでも架空の事例としますが、より具体的な作り話をしてみたいと思います。
◆ 知恵で解決するか、お金で解決するか
例えば、あるところにデータ量の増加に伴って性能が出せないクエリがあるとします。このクエリは複雑で、DBMS の設定などを含めてチューニングするのには多くの時間が必要だけれども、早くできるのは、エンジニアの勘から分かるという経験はあるでしょう。
受託開発であれば、プロジェクトには期日や予算などの制約があるので、お客様との調整によってある種の解決を図る場合もあるかと思います。しかし、我々のように自社でサービスを運営していると、プロジェクトの期間や予算というのはあまり強い制約としては働きません。
このとき、クエリのチューニングにかかる時間がハードウェアの調達時間よりも長いなら、まずは追加のハードウェアで問題を解決することを優先的に考えなければなりません。その方が早くお客様に価値を提供できる（毀損されていた価値を回復できる）からです。
追加ハードウェアの費用と人件費という観点もありますが、我々ベンチャー企業にとって人というリソースは実際の人件費以上に重要な価値を持っていますから、多少高くてもハードウェアで解決できるなら、その分の作業時間を他にもっと重要な機能を開発する方に向けたいのです。
このようなケースがあったとしたら、私は（貧乏性だからなのか）どうしても自分の知恵でもって問題を解決したいと思います。それは、ソフトウェアのエンジニアとして自分たちが作ったものに責任を持ちたいという感情もありますし、ハードウェアで解決したとしてもその問題は潜在的にも残り続けるので、それが将来どんな重荷となって自分たちに降り注ぐかも分からないとも思うからです。
しかし、このケースでいえば、まず真っ先にハードウェアで解決する方法を検討するべきでしょう。もし本当にその問題が将来何らかの大きな課題に発展する可能性があるならば、それは別の問題として捉えて、ハードウェアによってサービス価値を向上させた後に考えるべきなのです。
◆ 新しいテクノロジの導入
フレームワークのバージョンアップ等でも同様のことが起こりえます。新しいフレームワークには魅力的な新機能が実装されていて、開発がさらに面白くなりそうだと。当然多くの不具合も改修されているわけで、開発としてはバージョンを上げない理由はないわけです。
ただし、その行為がお客様価値の向上にどれだけつながるのかということも真正面から考えなければなりません。新しいテクノロジやバージョンには学習コストがかかり、見えないリスクがあります。さらに移行するためには多かれ少なかれ作業が必要です。
それらのコストを払ってでも上げる必要があるのかと。それでも機能面で何も変えられなければ、それはユーザーにとっては本当にどうでもいいことなのです。新しいバージョンで解決される不具合に悩まされているということがなければという前提ですが。
◆ 軸の話
ここまで書くと、エンジニアとして面白くもなんともない実装でサービスを作っていればいいのかと思われるかもしれません。それが大人の考え方だと。一見すると、ここで挙げた事例からはそう見えます。
しかし、私がお伝えしたいのは、そういうことではありません。やはり、遅いクエリをよいハードウェアで早く実行できても、それはごまかしでしかありませんし、新しいバージョンには世界中のエンジニア達の知恵と経験が、新機能という形で搭載されているのです。先述のケースで違和感を感じることは誤りではありません。何が言いたいかというと、自分の矜持とか、面白そうだとか、そういうことではなく、きちんと顧客価値という視点から技術をとらえましょうということです。
エンジニアが求めるものの多くは間違っていないと思います。が、それらは「世の中に提供する価値という軸で説明されなければならない」と思うのです。常にそれを頭の中心に据えておくと、技術の動向のみならず、組織における技術選択の背景も理解することができるようになってきます。
先の例で言えば、「この問題を最も効果的に解決するには、ハードウェアを購入するべきか、クエリのチューニングを行うべきか」と考えます。そして、ハードウェアを購入することを選択したならば、今度は問題となったクエリを将来の課題にしないためには今何をするべきかを検討します。フレームワークのバージョンアップがあったならば、その新しいバージョンを使ってどうやって顧客価値を向上させようかと考えます。この機能を使えば、今よりもこれだけ早く開発できる（漠然とではなく具体的に）とか、これだけ品質を上げられるかなどを発想するのです。
◆ 技術ってすばらしい
我々エンジニアは、世界を変える力を持っています。そのことを強く意識して、「自分は今どれだけ世界に貢献しているのだろうか」と考えるようにしてみることをお勧めします。世界に貢献するという意志を持って技術に接すると、それが純粋に面白いかとかイケてるかどうかではなく、その技術が持つ本当の価値が見えてきます。そうすると、その技術を採用するかどうかを進言するようなシーンでも、なぜ採用するべきなのかということを明確に説明できるようになります。その結果、どんどん自分の周りに面白い技術が集まってくるはずです。要するに、面白い技術が面白いのではなく、価値のある技術が面白いのです。
もしこのコラムを読んでいただいている方の中に、ベンチャーでやってみたいと思っている人がいれば、ぜひ飛び込んでみてください。私のようにハンマーで頭を何度も何度も殴られるかもしれませんが、その苦痛を補って余りある成長があります。そして、世の中に貢献するための技術を身に付けて、1人でも多くの方に真に楽しいエンジニアライフを送っていただきたいと思います。