現代は開発抽象化レイヤーが重層化している、あるいは何を見ても開発抽象化レイヤーに見える
「開発抽象化レイヤー」とは
「開発抽象化レイヤー」(Development Abstraction Layer)はご存知でしょうか。
これはJoel Spolskyが言い出した言葉で、彼の2006年のエッセイのタイトルにもなっています。このエッセイは大変おもしろいので必読です。ご存じなかった方はいますぐ読むことをおすすめします。
日本語訳もInternet Archiveから読めます。
ちなみに組込み方面では「HAL」という用語があります。これは「Hardware Abstraction Layer」の略です。HALはハードウェアの違いを吸収することで、プログラマにはハードウェアを意識させないよう「抽象化」するためのものです（が、実際には「抽象化の漏れ」が生じやすくて微妙な話が展開されるようなのですが、それはまた別の話になります）。
この「開発抽象化レイヤー」も、実際にはプログラマーが活動する際に必要となるあれやこれやの物事を「抽象化」し、プログラマーは意識しなくてもよいようにするためのもの、と考えればよさそうです。
2020年代の開発抽象化レイヤーを考える
さて。このエッセイが書かれたのはもう15年以上も前になります。そのため、そのまま無批判で適用されるべきかどうかは改めて考えてみる必要がありそうです。現代の「開発抽象化レイヤー」はどのようなものになっているでしょうか？
もちろん、業務としてのプログラミングという営為そのものは15年たってもあまり変わるものではありません。
プログラマが最高に生産的になるためには、静かな個室と、強力なコンピュータと、無制限の清涼飲料と、20度から22度に調整された気温と、ぎらつかないディスプレイと、あるのが感じられないほど快適な椅子と、郵便を届けマニュアルや本の注文をしてくれる管理人と、インターネットを空気のようにあたりまえに使えるようにしてくれるシステム管理者と、プログラマが見つけられないバグを見つけてくれるテスタと、画面を素晴らしいものにしてくれるグラフィックデザイナと、人々が製品を欲しくさせるマーケティングのチームと、人々が製品を確かに手に入れられるようにするセールスのチームと、顧客が製品を使えるように助け、プログラマにはサポートへの電話の原因となっている問題を伝える忍耐強い聖者のようなテクニカルサポートと、そのほか何ダースものサポートや管理を行う人々が必要になるのだが、典型的な会社では、それらの人々は従業員の80%にもなる。
ー Joel on Software「開発抽象化レイヤ」より
上記引用の中で出てきたような、
- 静かな個室
- 強力なコンピュータ
- 無制限の清涼飲料
- 調整された気温
- ぎらつかないディスプレイ
- 快適な椅子
- 郵便を届けマニュアルや本の注文をしてくれる管理人
- システム管理者
- テスタ
- グラフィックデザイナ
- マーケティングのチーム
- セールスのチーム
- テクニカルサポート
- そのほか何ダースものサポートや管理を行う人々
といったものは、特に不要となっているわけではありません。これはこれで現在でも必要とされています。
ところでこの15年の間に大きく変わったものと言えば、ソフトウェアが広範囲に進出したことです。いわゆる「Software Is Eating The World」というやつですね。
Joelがエッセイで挙げていた開発抽象化レイヤーは、基本的にはソフトウェア開発者以外の物事を指していました。しかし、「ソフトウェア開発（者）」と「それ以外」をざっくりと分けるようなやり方は、現代では不適切になりつつあります。もう少し丁寧に区分けしたり、その関係性を再構築したりする必要が生じています。
そう考えると、このところ流行ったタームは、広い意味での開発抽象化レイヤーの構築に関連するものが少なからずあったように思われます。
例えば「DevOps」はどうでしょうか。これはもちろん、開発抽象化レイヤーに関わるものです。運用に重きを置くソフトウェア開発において、DevとOpsの垣根を工夫することで、「Dev」の人にとってはより優れた開発抽象化レイヤーを提供するようにする、といったことだと考えられます。
「SRE」はどうでしょうか。これももちろん、開発抽象化レイヤーに関わるものです。SREはつまるところ、運用チームもソフトウェア開発者がソフトウェア開発と同じようなやり方でやることで、SREではないシステムの開発者にとっての開発抽象化レイヤーをより優れた形で提供するためのものです。それに加えて、システムの開発者のために構築されてきた開発抽象化レイヤーを運用にも応用できるようにすることで、運用をよりやりやすくするためのものでもあります。
「チームトポロジー」はどうでしょうか。これも言うまでもなく、開発抽象化レイヤーが関わっています。Joelが上記エッセイで語っていたような古典的な「プログラマ」は「ストリームアラインドチーム」と再定義され、それ以外の開発者のチームとして「イネイブリングチーム」「コンプリケイテッド・サブシステムチーム」「プラットフォームチーム」などが導入されますが、これらはストリームアラインドチームから見れば「開発抽象化レイヤー」になるわけです。
言い換えると、ソフトウェア開発者がソフトウェアシステムをもりもりと開発していく、そのproductivityを高めていくには、プロダクトの直接的な機能を設計・実装していくソフトウェア開発とは別に、それ以外のソフトウェアを開発したり運用したりしていく行為が必要となってきた、あるいはその重要性が増してきたと言えるでしょう。
「副業エンジニア」が流行りつつあるのもこの文脈で考えることができます。開発抽象化レイヤーを構築するためには、そのコアドメインに関わる開発者以外にも、いろいろな役割でのITエンジニアが必要となるわけです。そういったエンジニアは、必ずしもフルタイムで活動する必要はなかったり、コアドメインに詳しかったりしなくてもよいかもしれません。つまり、「副業エンジニア」が求められるのも、開発抽象化レイヤーのためなのです。
その意味で、例えば「SaaS」が流行するのも、システムを開発するための便利な開発抽象化レイヤーの一環としてSaaSを利用することが欠かせなくなってきている、といったことも言えるかもしれません。
重層化する開発抽象化レイヤーとソフトウェア開発（者）のポジショニング
このようにあれこれ列挙していくと、2006年と比較した現代の特徴として、「開発抽象化レイヤーを構築するためのソフトウェア開発」というものがより大きくなってきており、そのためのソフトウェア開発（者）が増えつつある、と言えそうです。もちろん、開発抽象化レイヤーをソフトウェアとして開発する現場では、その人達から見た別の「開発抽象化レイヤー」を駆使しているわけで、そのような重層的な関係性が現代的なソフトウェア開発の特徴と言えるでしょう。
また、開発者の方にとっては、自分が開発しているものが誰にとっての「開発抽象化レイヤー」なのか、また自分が利用している「開発抽象化レイヤー」は何なのか、ということを意識すると、自分の開発しているもの、そして自分自身のポジショニングがわかりやすくなるかもしれません。そのような、概念を整理するための用語として「開発抽象化レイヤー」という言葉と概念が重宝されるんではないかと思っています。
Discussion