僕がエンジニアをやっていて面白いと思うのは、この技術がどういうことに使われて、どのように世界が変わっていくか？を考えて、それを実現していくことに携わるのが好きなようだ。
昔、XMLが流行った時に、XMLによって世の中のデータが定型化されて電子化されることを臨んだが、世の中はそんなに甘くはなく、jsonのような非定型な記述法で自由にやることが流行っている。一方で、アマゾンのように圧倒的に自分達のビジネスに利がある世界にあわせさせることに成功すると、XMLによるフォーマットでも記述ができて、Amazon Web Servicesのような形で、商品情報の流通に成功した例もある。
技術とリアル、どっちが強いかで技術は生きもするし死にもする。位置情報である緯度経度をGPSやWiFiを使って場所を特定する技術はもう１０年以上前から簡単に扱えるようになったが、目の前にある飲食店に入って、席が空いているかどうかを店の外から知る方法はまだない。
こういう時に技術の難しさを知ると共に、その行為にビジネスメリットを付加し、ユーザなど利害関係者の投資を正当化してもらう方法論の必要性を強く感じる。これを技術を活用して実現する会社にはCTOの役割が求められて、そうでない会社にはCTOはいらない。
告白になってしまうかもしれないが、僕自身は、技術そのものの良し悪しにあまり興味はない。その命令が1サイクル早いかどうかなんてのは、もちろん重視はするけど、ベンチマークを取ることに喜びを感じるタイプではない。むしろ本質的な生産性が高いことを重視する。言語仕様が少々イカれてても、トータルのメリットが優れていれば後は、致命的にコストがかからないか？であったり、採用に不利ではないか？なども含めて市場の評価に委ねるタイプだ。
もし技術そのものに興味があったなら、情報系の大学に行って、XMLの標準化に強く興味を持って、世の中をメタデータで記述することやRFCを記述することに喜びを感じていたかもしれない。今ならマストドンのインスタンスの運営ではなく、OStatusを拡張したAI botの開発に時間を費やしているに違いない。そもそも大学の頃からサイエンスを応用する側のエンジニアリング＝工学部にいたわけだから、新卒の製造業も含めて、そういう動き方しかしたことがない、というのが正直なところだ。コンピュータはサイエンスとエンジニアリングの区別がつきにくいから面白いんだけど、サイエンス領域の関心があるのがエンジニアとして当たり前みたいになってるのは少し窮屈だと思うこともある。
僕が興味があるのは、今ある技術の中で、飲食店の情報をどれだけ集められるかにチャレンジするアプリを作ることであったり、この技術を運用していく場合に、何年後までやっていけるのか？その場合にはどのように新しい技術に変化していけば、メンバーは問題なくついてきてくれるか？などを考えることが好きだ。
技術の良し悪しや、うまい運用方法は、幸いにして近くにいる人達や、インターネットを通じてたくさんの人から教えてもらうという形で成長してきた。昔、モバツイの負荷で苦しんでいた時に、とある方が、はてブやブログを通じて「そんなハズはない、多分どうにかする方法はあるハズ」などというコメントをつけてくれて、そのコメントを頼りに問題解決したことがある。
問題が問題だと認識されれば、問題追求をして、どうにかして解決をするのは苦手ではない。もちろん自分の技術力の範囲に限られてしまうだろうが、それも含めて、どうにかするのは比較的得意な方だと認識している。
しかし、問題が問題であることを認識するためには、経験が及ばないことがある。そのために沢山の人のアドバイスをいただく。今、技術顧問やアドバイザーとして、何人かの外部の方にお手伝いいただいているが、一番欲しいのは「それで大丈夫」「もっとどうにかできるんじゃない？」という一言だけなのだ。今は、そのようなフィードバックを得られる場を作ること、それに携わるメンバーを一人でも増やし、学びの機会を作ることが、僕の仕事において結構重要な役割で、かつそういう機会に立ち会えることを喜びだと思っている。
Webサービスを作るビジネスが難しいのは、残念ながら足元の技術が変化することを前提としていることである。
もちろん、それによって、新しいビジネスの種を仕入れてサービスそのものを変化させ、新しい収益源を生むことが重要だ。
一方で短期的には、技術の変遷とは無関係に、自分達のビジネスをよくするために技術的負債なども顧みずサービスを向上させていくことが求められる。本来は、その短いスパンだけを見れば、足元で使っている基盤技術が変化することなんて、無駄なことでしかない。せっかく投資をしてコードを書いているのに、全く同じ処理を別の言語に移植するなんて無駄以外の何者でもない。
しかし、時代の変化に応じて、スクラップ・アンド・ビルドしていくのも事実だ。
投資の本によると、株式市場の長期投資においてIT業界は不利だと言われている。
常にそれまでの王者のビジネスを無効化するような破壊的技術が出てきて、いつもスクラップ・アンド・ビルドすることになるので、同じ名前の企業が長期的に繁栄することを若者が阻止してしまうことで、長期投資で得られるべきリターンが減るからだと言われている。
僕が一番好きなのは、そういう変化を乗りこなす道筋を作り、プロトタイプを作り、深掘りしていくプロセス、なのかもしれない。変化しなくなった世界は飽きてしまうタイプの可能性が高い。常に変化して、未来がどのように変わるのか？を考えて、その中心のエリアに属してプレーヤーの一人として戦い続けるのが好きだ。
残念ながら、この世界は手に職をつけても30年同じ技術で生きていくのは不可能だ。Webの技術において、これまで１５年程度ならどうにかなっているようだが、それはWebそのものが進化していないと考えるべきなのかもしれない。今後はよりリアルタイム、より時間軸遷移を意識したWebサービスへの変化に興味がある。マストドンに飛びついたのは、10年前のツイッターがやっていたであろうタイムラインシステムのソースコードが実際に動いている場面に立ち会えたからというのもある。
でも、これにスケール問題があるのは、twitterの歴史も含めて御存知の通り。１０年間twitter社が時間を費やしてきたのは脱rails、脱mysql、対スパムなどの取り組みである。それらに時間を取られている間に、サードパーティのツイッタークライアントはスケーラビリティをtwitterに外注する形で、UXを向上させてきた。その結果が、今のTwitterとサードパーティの関係性である。
まぁそれはいい。要するに、「簡単にリアルタイムWebをプログラミングできる時代」はまだまだこれからなのだ。
おそらく、その時に、少なくともRubyだPHPだ、なんて話ではないのかもしれない。もっとその時代の要請に適した開発言語かフレームワークで、安全かつエラー処理等のトレーサビリティや再実効性などのフロー制御性を確保した上で、非同期の処理を記述できるようになっているのだろう。
接続クライアントも人間よりもIoTやWebサーバ同士のM2Mの方が圧倒的に負荷をかけ続ける時代になっていることが予想される。少なくともマストドンはその片鱗を見せつけた。でも、そういう世界に向けて技術を学んだりアーキテクチャを考えるのはめっちゃ楽しいです。
だから、みんなも、この変化を予想して欲しいし準備して欲しい。技術者であるならば良いサービスを作る知恵と並行して技術力の研鑽は絶対に必要です。
僕はそんなパラダイムシフトを望む１ユーザーとして、今やるべきことを頑張ります。
この記事良かったです。
エンジニアの幸せ
技術的負債と向き合う
