データモデリングとローコード開発の組み合わせを推奨しているのだが、私としては「ノーコード開発」には食指が動かない。理由は明確で、複雑なDB構造を扱えないし、何よりも端正なコードを書く喜びを味わえないからだ。とはいえ、そもそもノーコード基盤はエンドユーザ向けのツールなので、システム開発者がそういう基盤に関わる機会はまずない。技術者がノーコード開発を忌避する意味はなさそうだ。
では、私を含めてプログラミングが好きなIT技術者は、「ノーコード」ではなく「ローコード」であれば満足できるのだろうか。これは技術者が業務システム開発に何を求めるかで違う。ローコードではデータモデルに沿わせるような形で仕様書を書けば、システムは仕様書にしたがって動作する。ただし、定型的なロジックについては基盤によって暗黙的に手当されるが、一定以上複雑なロジックは開発者によってスクリプティングされる必要がある。確立したデータモデルにもとづいて、最小限のコーディングでシステムを動作確認したい――そんな技術者にはうってつけだ。
しかしながら、ローコードでは「オブジェクト指向プログラミング(OOP)」が要らないという問題(?)がある。ローコード基盤そのものはオブジェクト指向言語で書かれているのだが、規定のクラス構造にしたがって個別案件の定義が組み込まれていくので、開発者が新たなクラスを考える必要がない。スクリプティングにおいてオブジェクト指向的なコードも書けるが限定的で、個別案件の開発においてOOPを堪能したいと考える技術者は満足できそうにない。
そのような技術者の多くは、個別案件を「ローコード開発」ではなく「ドメイン駆動設計（DDD)」で扱おうと考えるかもしれない。その枠組みを提唱した著者であるエリック・エバンスにその意図があったのかなかったのかは定かではないが、著書の中で例示されているコードがJavaであったため、DDDは90年代に流行した「オブジェクト指向分析・設計（OOA/OOD）」の正統な嫡子とみなされ、OOP好きの技術者に広く受け入れられた。
しかし現在、OOPベースの開発態勢で仕事は取れるのかという懸念がある。コンペ相手がデータモデリングとローコード基盤を駆使しながら営業段階でプロトタイプを動かしているとすれば、いかにも分が悪い。ライフルを持った相手に竹槍で戦うようだ、では言い過ぎだろうか。
「いやいや、ローコード基盤ではアプリがパターン化されていて、きめ細かな仕様を実現できない」といった反論があるかもしれない。しかし、いわゆる「きめ細かな仕様」の多くが「現行システムの使い勝手を再現してほしい」というユーザのわがままであることは知っておいたほうがいい。グダグダな現行システムや神EXCELシートのようなシロモノをJavaあたりを駆使して完全再現できたとしても、まさに「最新の建材で更新されたピカピカの竪穴式住居」でしかない。きめ細かく対応できることには一定の価値はあるが、その意義を強調し過ぎてもいけない。
またDDDを究めることで、かえって仕様策定のスキルがつきにくいという問題もある。このブログで何度も指摘しているように、特定のドメイン（業務システムやゲームソフトといった、ソフトウエアが適用される社会経済分野）にコミットしてその専門家となることは、IT技術者が長期的に稼ぎ続けるための基本である。「プログラミングの専門家」では厳しいが、「特定ドメインのプログラミングの専門家」であれば長期的に食える公算が高い。
ところがDDDには「ドメインエキスパートと協働すれば、どんなソフトウエアも生み出せる」という奇妙な信念がある。これは危険だ。どのドメインにも詳しくない「DDDの専門家」のような技術者を生み出す恐れがある。なにしろドメインエキスパートだけとやりとりすれば、仕様策定に必要なドメイン知識は手に入ると期待できてしまうからだ。「OOPというドメインにコミットした」といえば聞こえはいいが、自分の役割をプログラミングに限定する形で生々しい社会や他人と距離を置こうとする一種の成熟拒否ではないだろうか。
じっさいのところ、仕様策定に関して自分以外の有識者をアテにしている限り、設計スキルは涵養されない。「ホニャララ（ユーザやドメインエキスパートやプロダクトオーナーを代入しよう）の語りがコロコロ変わるから仕様が決まらない」と嘆いているとしたら、設計のプロではないホニャララをアテにしすぎて失敗している可能性がある。技術者自身がドメインの専門家としてホニャララを牽引できるくらいの知識や経験がなければ、DXを含めてシステム刷新など夢のまた夢だ。
このように、OOPにこだわりながら稼ぎ続けることは簡単でないように思えるが、希望はある。じつは技術者がOOPに伴う喜びと稼ぎを最大限レバレッジできる秘策がある。見定めたドメインにおいて「オブジェクト指向を意識せずに開発できるようなローコード基盤」をOOPすればよい。生み出されるソフトウエアは、私がDSP（ドメイン特化基盤,Domain Specific Platform）と呼ぶものだ。「業務システム」のドメイン向けのDSPがいわゆるローコード基盤ということだが、もちろんこのドメインにこだわる必要はない。
私自身が実践しているのでよくわかるが、これは楽しい。「DSPそのもののオブジェクト指向開発」と「DSP上での個別案件のローコード開発」を同時に味わえる。しかもそれらは有機的に関係していて、個別案件の仕様改善のアイデアがDSPの改善につながることもあるし、その逆パターンもある。結果的に、ドメイン特化して堅実に稼ぎつつ、OOPを趣味のように堪能できる。同じようなやり方で活躍する技術者が私のまわりに何人もいるのだが、彼らもこんなに愉快な働き方はないと口をそろえる。DDDやOOPに興味をもつ技術者は参考にしてほしい。
