見出し画像

エンジニア26年生から見た、明日の世界

はまあ

この記事は、オンラインコミュニティ「エンジニアと人生」のアドベントカレンダー#1の24日目です。#2はこちら。

謝辞

今の自分にとって、かけがえのないコミュニティを提供してくれた、発起者の堤さん、そして毎日のように、示唆に富んだ議論、興味深い話題、そして的確なアドバイスを提供してくれるサロンメンバーの皆さんに、深く感謝しています。

拙い文章ではありますが、こんな駄文を晒す機会をくれた皆さんに本稿を捧げたいと思います。

はじめに

28年前、ぼくは大学受験に失敗して、モラトリアムを続けるためだけに情報系の専門学校に通っていた。当時の僕は"ちょっとパソコンに詳しい若造"という程度だったと思う。母親は、夜な夜な引きこもってパソコンにかじりついているぼくを、奇怪な趣味を持った社会不適合者になってしまったと心配していた。

在学中のある日、趣味のプログラミングの実装に詰まって、非常勤講師の先生に相談した。何度かそれを続けるうちに、先生と仲良くなった。

実は、先生の本業は、ソフトハウス(今で言う零細SIer)の社長で、技術的な相談を重ねるうちに「うちでバイトしない？」と誘われるようになった。

そのときに書いたZ80のアセンブラが
「コードを書いて初めてもらったお金」
だったと思う。

つまらん昔語りはおいといて。

2021年の今日、四半世紀にわたって、この業界を底辺から眺めてきたわけですが、そんなボトムアップ的視野から、これからのエンジニアがどのように生きるべきなのか、あるいはどこに身を置くべきなのか？

そんな未来について、思っているところを、雑多に語っていきます。

SIの終焉

2020年代になり、多くの企業にとって、ITというものは、外注すべきコストではなく、業務の中核たりえる戦略的な投資対象という存在になってきました。

しかしながら、依然として国内のITベンターにとっては、コンピューターシステムは「安く作って高く売る」という、商材以上のものにはなっていません。
対して、ITに精通した多くのスタートアップやベンチャーは、ソフトウェアが生み出す価値に注力するようになっています。

このビジネスサイドからの要求は、人材投資戦略にも影響を及ぼしており、企業は本当に価値のあるソフトウェアを内製化し、企業の価値に影響はないシステムのみをSaaSを利用したり、あるいは外注で特注するようになっています。

これらの潮流は、我々エンジニアに、どんな影響を及ぼすのでしょうか？

注目すべき点は、企業が資金を投入するときに、それを「コスト」と見なすか「投資」と見なすかの違いということになります。
投資は、より売上や利益率の改善に繋がりますが、コストは安ければ安いほどよいのです。

つまり、投資とみなされる会社において、能力を十全に発揮できれば、高い報酬が期待できるということになります。

つまり、エンジニアを雇いたがっている企業にとって、あなたの存在は投資対象なのか？あるいはコストなのか？を見極めていく時代になったということです。

消えゆくもの、変わりゆくもの

今日、いままで安定したビジネスだと思われていた産業が、ある日、突然、消え去ってしまうことがしばしば発生します。

i-mode(Killed by Apple)
書店（Killed by Amazon)
新聞（Killed by Internet)
電報・郵便（Killed by e-Mail)
固定電話（Killed by mobile phone)
TVとTV広告(Killed by Youtube, Netflix, etc…)

これら、イノベーション被害者リストの列には際限がありません。

明日、突然市場を破壊される企業がどこなのか、もう誰にもわからない時代に我々は生きています。

しかし、実に幸運なことに、我々エンジニアの仕事は、いかなる業界の、いかなる業種の、いかなる業態であろうとも、ほとんどやることが変わらないという奇妙な職業でもあります。

人の話を聞いて、設計をし、コードを書いて、テストをして、リリースをする。（そしてバグを直す）

ある意味、イノベーションによる産業の破壊に対して、最も耐性がある労働者ともいえるかもしれません。

では、我々エンジニアは、この破壊的イノベーションが頻発する社会で、どのように生き残っていけばいいのでしょうか？

まずは、あなたが参画中の会社の、主たる事業が何なのかを把握しましょう。
その上で、その業種が業界が、この先どうなるのか？について注視しつづけるべきです。
こういった業界の空気感というものは、会社の中、業界の中にどっぷり使っていると、意外と見えにくいものなのです。それが目に見えるような空気になったときには、大抵何もかも手遅れということがしばしばです。

したがって、自社や、自業界についての、他者からの評価、決算書、産業統計、募集要項、株価の動向などのエビデンスから判断していきましょう。

今日、この場所が平和だからといって、明日も安泰である保証はなにもないのです。

No Codeとプログラミングの民主化

2020年頃からNo Codeというものが注目されてきました。

これは、システム開発において最も困難だと思われている実装工程を実施するための学習コストを下げてくれるという、実に素晴らしいものです。

…残念ながら、これはITの周辺業界が、およそ4年周期で罹患する、インフルエンザのような季節性疾患です。

ちなみに、上記で欠番になってる2008年は、自社開発せずにASP(Application Service Provider)を使って「自分でプログラムしない」のがトレンドでした。

さて、コードを書く仕事を続けていて、ここ10年の大きな変化について思うことなのですが
「コードを書くのが、極めて簡単になった」
ということです。

正直、Firebase+Flutterなどは、実質的にNo Codeのようなものです。
ほとんど何も書いてないというレベルで実装作業が短くなっています。

最も困難なのは「どこに何をどれだけ書くか」という設計のプロセスで、実際の実装にはほとんど時間がかかりません。

現代では、小学校でプログラミングを教え、プログラミング思考を鍛えるためのゲームもたくさん入手できます。いうなれば今学校に通っている子どもたちはプログラミングネイティブな世代といえます。

これから社会に出てくる若者は、プログラミングをするという事に抵抗がない人々であるのは想像に難くありません。

翻って我々の置かれた状況を鑑みると、プログラミングそのものはシステム開発におけるごくごく一部の工程になりつつあり、真に苦労すべきところはコードを書く以外の何かになっています。

したがって、誠に残念ながら、実装だけをいくら省力化してみても、システム開発という全体像からは、非常に限定的な効果しか及ぼさないのです。
（そして、リリース後に厄介を引き起こします）

プログラミングという概念に慣れ親しんでいない人にとっては、実装こそが最も困難な工程であるということは理解できますが「あなたにとって困難である」ことが「システム開発において最も困難である」とは限らないのです。

さて、我々エンジニアにとって、これらの流れをどう見るべきでしょうか？

結論：No Codeによって我々の仕事はなくなりません。

それらは、新しい（そして寿命が極端に短い）言語/フレームワークとして扱うのが妥当だと思われます。実際、習得は簡単ですし、やるのは構いませんが、世界を変えることはできません。

最後に、Swiftの発表で話題を攫った2014年のWWDCには、こんな標語が書かれていました。

Write the code. Change the world. 
（コードを書いて、世界を変えろ）

あなたはコードを書きますか？それとも？

さんざんdisっておいてなんですが、日常のちょっとした課題を解決するためにNo Codeを使うのは悪くないと思います。

しかしながら、それらの「日常的なちょっとした課題」を解決するためのプラットフォームは、じつに1980年代のUNIXの時代から、何一つ変わらず、ずっとあなたの前にいるのです。

それがシェルコマンドです。

もしあなたがNo Code等に興味を持っているのなら、便利なPOSIXコマンドについてほんの少しで良いので学習してみましょう。

No Codeで出来ることのほとんどがコマンドラインだけで実行可能なことに気がつくでしょう。

HTML/CSSは死なず、ただ消え去るのみ

おそらく、2010年代にエンジニアを指向した人にとって、システム開発というものは、ほとんどがWebアプリケーションの事を指していると思います。

つまり「アプリケーションの基本」とはWebであり、それ以外のものは「本流でないシステム」のように感じているのではないでしょうか？

さて、ぼくのようなロートルエンジニアから今のユーザーアプリケーションの世界を眺めてみると、このような風景にみえています。

Webブラウザで、ユーザーアプリケーションを実行するようになったのは、当時、たまたま流行していたクライアント（人はそれをWebブラウザと呼びます）で、強引にユーザーアプリケーションを実行している。

そもそも、WWWはアプリケーションプラットフォームとして開発されたわけではありません。しかしながら、市場のニーズに合わせるために、サーバ=クライアント間で、なぜか「ハイパーテキストをトランスファーするためのプロトコル」(HTTP)を使って、まっこと非効率なエンコード方法(21世紀にもなってASCIIコードでBase64？アホなの？）でアプリケーション用データの送受信を行っています。

アプリケーションのステートを維持するために、これまたHTTPというその場限りの刹那的データ転送を行うという、まったく不向きなプロトコルを使って、繰り返しセッションを再接続しながら、クライアント=サーバ間のデータ同期をなんとか行っています。HTTP/2が開発されるまで、継続的なデータ送受信がまともにできなかったのは驚くべきことです。

そしてまた、ドキュメント装飾用に設計されたCSSという仕組みを使って、ユーザーインターフェースをレンダリングするという、実に奇怪で、まったく奇妙な方法で実装されています。

正直、こんな頭のおかしい、使いづらい、アプリケーションを実装するのに適していない、出来損ないのプラットフォーム上で、ユーザーアプリケーションを作るのは、純エンジニアリング上の問題として、全く必然性がないのです。

しかしながら、Webブラウザという、世界で一番利用されているアプリケーションで動作するということは、マーケティング上、強い必要性が存在しているのも、また確かなことです。

これから先、歴史が生んだ奇形児はどのような運命になるのでしょうか？

筆者の予測では、HTML/CSS技術は、現代のアセンブラに匹敵するような「コンパイルした先」になっていくと思います。いうなれば、技術指向の人々、たとえば言語コンパイラの作者たちが触る、ちょっと尖った技術という存在になっていくでしょう。

そしてまた、アプリケーションフレームワークとしての一強の座を降りるのは時間の問題だと考えます。

すでにいくつかの代替プラットフォームが提案され、台頭する気配を見せています。
強力な対抗馬になりそうなのは、iPhone/Androidなどのネイティブアプリケーション、wasmの派生等、ブラウザ上で動作する代替レンダリング手段などでしょう。

今現在においては、HTML/CSSに代表されるWebアプリケーション技術の習得は、ほぼ必須であるのは確かです。
しかし、ReactやFlutterに代表されるような「HTML/CSSを知らなくても実装ができてしまう」プラットフォームの台頭はもう止めようがありません。

旧来のWebアプリケーション実装技術を、今後5年10年にわたり、企業が安定して採用し、エンジニアリングのニーズがある、という保証はありません。

この30年、業界をまたたく間で席巻し、そして、それより早い期間で駆逐されていった技術は数多いです。

「Webからはじめて、Webだけやっていれば良い」という時代は10年前にすでに終わった、ということを覚えておいてください。

すべては"D"へ

昨年までのプログラミング人生において、開発者としての体験が劇的に変化したことは何か？と問われたら、「gitとgithub」と即答することができます。
githubがもたらした変革については下記の記事の冒頭で触れています。

さて、gitが世界を変えた理由の一つには、旧来の中央集権的であったSubversionに比してDVCS(分散バージョンシステム)という、まったくもって奇妙な概念を採用したことだと思います。

githubは一見、中央集権的のように見えますが、Forkあるいはリポジトリそのものを世界中のあらゆる場所にcloneすることで、「最初に作った人の管理」から離脱することができてしまいます（ライセンス的な問題はさておき）

そういった自由な改変が可能であっても、fork元に自分の変更のプルリクエストを出し、そのリポジトリを利用している人々やコミッターの議論を経て、本家にマージされるかが決断され、最終的にリポジトリにはコミットが加えられていきます。
プルリクがリジェクトされたのが気に入らなければ、forkプロジェクトを立ち上げ、袂をわかった人たちで新たなライブラリが開発されることもあるのです。ライセンスが許す限り、それらの活動はすべて自由です。

こういった分散型のソースコード編集は、まさにブロックチェーンにおけるコンセンサスアルゴリズムと同じ事を、人間がやっているとも言えます。

つまり、ぼくらエンジニアは、知ってか知らずかいつのまにかデータ中央集権主義から解脱していて、それを日常的に受け入れているのです。
（まともなエンジニアはね？）

ところで、ブロックチェーンの応用例でよく出てくる「分散台帳技術（DLT）」はDistributed Ledger Technologyの略です。

そしてまた、ブロックチェーンを基盤として運用される、新たな概念の組織は「分散型自律組織(DAO=Decentralized Autonomous Organization）」と呼ばれます。

本来、我々霊長類というのは、群れのリーダーに追従することが生残戦略としてうまく機能していたはずなのですが、不思議なことにホモ・サピエンスは、これら中央集権的システムに対して、なぜか文化的な反発を感じるのが常のようです。

歴史を振り返ってみると、かつて封建制から中央集権政治に移行した政体は、結局は民主主義(Democracy)に代表される、分散意思決定統治システムにほぼすべて取って代わられました。
先進国のほとんどがこの統治システムを採用していることから、その優位性は揺るぎないものといえます。

中央集権政治、Subversion…それら「中央集権」の名を冠するものは、長い歴史の中で、主役の座からことごとく蹴り出されました。

時代は、「D」、すなわち「Distributed(分散)」というキーワードに、すべての羅針盤が向いています。

GAFAに代表される、「中央集権的」データ資本主義企業たちは、はたしてこの流れに、抗うことができるのでしょうか？

おわりに

1993年の東京都の最低時給は620円だった。
駅前のゲームセンターでのアルバイトは720円だった。
先生は時給2,000円でオファーをくれた。20歳の若造にとっては破格といえる。

先生が悩んでいたのは、外部機器への制御が遅延していた問題だった。ぼくはアセンブラのソースコードをフロッピーディスクで受け取ってから、一睡もせずに原因をつきとめ、翌朝、学校をさぼって改善したコードを見せた。

先生はとても喜んでくれた。なぜそんなに簡単に直せたのかを知りたがった。お金はどうでもよかった。

思い返すと、自分がコードを書いて生きていこうと決断したのは、あの瞬間だったのかもしれない。

後日、驚くほどの金額になった最初のバイト代で、Microsoftのマクロアセンブラのコンパイラ(6万円)を買った。

何枚ものフロッピーディスクと、辞書よりも分厚いマニュアルが何冊も入った、大きな白い箱。

何の役にたつのか、友達も家族も、誰一人理解していなかった。

もちろん、自分が、将来どうなるのか、僕もわからなかった。

Follow Me!

Twitter: @hummer


この記事が気に入ったらサポートをしてみませんか？