筆者はアラ還の現役プログラマである。幸い視力を含めて健康なので、プログラミングに苦労を感じたことはない。さすがに20代の頃のような体力はないが、求められている情報処理課題に対するソリューションの構想力はその頃より桁違いに向上している（それだけやっているのだから当然だ）。
身体条件に恵まれているとしても、ふつうは定年を過ぎればプログラミングする機会はなくなる。実際にはもっと早く、40代で開発現場を離れて管理や育成の仕事にシフトすることのほうが多い。ところが筆者の身近に、70歳を越えてプログラミングで活躍している友人がいる。変化と発展が止まらないこの業界でその年齢で現役はすごい。彼（下地氏）については自身で書かれた次の記事が詳しい。
60歳以上のプログラマと聞けば、COBOLあたりのレガシーシステムを保守している地味な技術者を想像するかもしれない。たしかにそんな技術者もいて、それはそれで立派な社会貢献である。いっぽう下地氏はCOBOLからこの世界に入ったが、今ではRubyやPythonの使い手である。私自身もAS400のRPGから始めたが、今ではJavaとJavaScriptがメインだ。「古い技術者は古い言語を使っている」は偏見でしかない（まあ今ではJavaはじゅうぶんに古い言語ではあるが）。
問題は「何で（どんな手段で）」ではなく「何を」プログラミングしているかだ。年配の現役プログラマはどんなソフトウエアを日々プログラミングしているのか。私と同世代（つまり年配である）にもプログラマとして活躍している友人が少なくないのだが、彼らにはいくつかの共通点がある。それらをまとめて言えば「ローコード基盤を活用している」ということになる。どういうことか。
今風の用語として「ローコード基盤」を使ったが、厳密には私が「DSP」と呼ぶソフトウエアである。DSPはDomain Specific Platform（ドメイン特化基盤）の略で、DSL(Domain Specific Language,ドメイン特化言語)が発展したものだ。
ここで言う「ドメイン」とは「ソフトウエアの適用分野」くらいの意味で、DSPは特定ドメイン向けに最適化された開発基盤のことだ。ドメインの例としては「ゲームソフト」、「業務システム」、「楽曲音源制作」、「ビジネスデータ分析(BI)」等、いろいろある。ローコード基盤は「業務システム開発用DSP」の別名だし、DAW(Digital Audio Workstation)は「楽曲音源制作用DSP」の別名だ。Unityは「ゲームソフト開発用DSP」に分類され、筆者が愛用するSONARやMuseScoreはDAWに分類される。畏友の杉本氏が開発したfusion_placeは「BI基盤開発用DSP」に分類される。
レガシー分野以外で活躍しているアラ還（以降の）プログラマがいるとしたら、高い確率でこのDSPを活用していると私は考えている。筆者や下地氏はDSPを用いて個々の業務システムを開発しているし、杉本氏はDSPを用いて個々のBI基盤を開発している（次の記事参照）。
そして、偶然にもこの３人に共通しているのが、自分が使うDSPそのものを自作した点だ。なにしろドメイン特化しているので、そのドメイン向けの要件を効果的に回収するためのクラス群がDSPの内部に組み込まれている。ゆえに、DSPを使って個々の業務システムやBI基盤を開発する際、継承だの委譲だの隠蔽だの値オブジェクトだのといったオブジェクト指向概念を考える必要はない。開発したいアプリの仕様書（表示・動作様式）をウイザード形式で書く――それだけで仕様書どおりに動作するアプリが出来上がる。その仕様を変更したければ仕様書を変更するだけでいい。
彼らにとってオブジェクト指向開発は「手段」であって「目的」ではない。自分が構想したアプリを爆速で形にしたい。仕様書を書いて他人に実装してもらうなんて非効率すぎる。保守や運用でも楽したい。そのために開発基盤そのものをオブジェクト指向開発して、日常の開発作業からオブジェクト指向を「隠蔽」してしまった。
これは、自分の働き方を「ITを用いて合理化した」ということでもある。楽曲音源をJavaあたりで開発・保守するのは可能だが、あまりに手間暇がかかる。それなら楽曲音源制作用DSPを使えばいい。生産管理システムをJavaあたりで開発・保守するにもあまりに手間暇がかかる。それなら業務システム開発用DSPを使えばいい。「オブジェクト指向開発を目的にしない」とはそういうことだ。
DSPが普及途上の分野であれば、これはビジネスチャンスでもある。じっさい上述した３人は経営者的な立ち場で活動しており、DSPを使わない業者には達成不可能な生産性と顧客満足を実現できている。DSPを使うからというだけでなく、圧倒的なドメイン知識や経験を援用できるからだ。そういった知見は現場にこだわり続けたことへのご褒美のようなもので、若手が苦労する要件定義やデータモデリングなどもう「瞬殺」なんである。しかも、定年なんて押しつけがましい時限装置とも無縁だ。
この独特かつ軽快なスタンスは、ソフトウエア開発に関する「ハレ（祝祭）」と「ケ（日常）」としてわかりやすく説明できる。日常的なソフトウエア開発では効率主義を旨とする。構想したアプリをどんどん形にしながら稼ぐ。いっぽう、地道に稼ぐ日常を支える開発基盤そのものの開発・保守は祝祭だ。蕩尽的高揚感を味わいながらオブジェクト指向の大伽藍を維持する（もちろん、引退後の保守体制も考えてある）。結果的に、ハレとケの交感によって両者が深化していく。
彼らにとってオブジェクト指向言語は「ハレの開発手段」であり、オブジェクト指向開発されたDSPは「ケの開発手段」である。オブジェクト指向言語を「ケの開発手段」とする年配プログラマもいるが多いわけではない。オブジェクト指向に手慣れたなら、馴染みのドメイン向けにDSLやDSPを自作してこちらを「ケの開発手段」にしてしまうからだ。では結論。現役で活躍するアラ還（以降の）プログラマは、「ハレ」と「ケ」をプログラミングしている。
