例によって業務システム（エンタープライズシステム）に関する話である。商品管理、受発注管理、売掛買掛管理、在庫管理といった活動を支えるソフトウエアに限った話だ。業務システム開発の世界でこれまで主流だった分業体制は、すでに過去の遺物であり旧弊である。どういうことか。
これまでは業務システムの実装方針には、大別して２つしかなかった。JavaやPythonといった汎用言語（およびフレームワーク）を用いて手作りするか、ERP等のパッケージシステムを利用するかだ。2010年頃からパッケージ利用が廃れ、代わって「ローコード開発」が普及しつつある。これが大袈裟な分業体制を無用にした。
大袈裟な分業体制とはどういったものか。汎用言語で手作りする場合、設計専任、実装専任、プロジェクトマネージャの分業体制が一般的だ。実装専任はさらにフロントエンド・エンジニア、バックエンド・エンジニア、WEBデザイナに分かれていたりする。いかにも賑やかで大袈裟だ。
ローコード開発においてそういった分業は要らない。設計担当者が自分で実装できるし、フロントエンドとバックエンドが連続しているので手分けする意味もないからだ。UIも定型的かつ地味な「業務用」なので、チャーミングなUI/UXを考えるデザイナも要らない。メンバーが少数で済むので主任設計者がPMやアーキテクトを兼任できるし、ほっといてもアジャイル化するのでスクラムマスターもお呼びでない。ようするに少数精鋭化して無駄が削ぎ落される。
従来体制でとくに問題だったのは「設計と実装の分業」だ。まず、設計成果物に対する実装からのフィードバックが弱いため、設計スキルがてきめんに劣化した。ちょっとしたアプリも自分では作れないばかりか、簿記のデータモデルさえ書けない「設計専任」がいたりする。また、設計担当と実装担当の分断が起こって、互いに「自分たちが苦労するのは彼らのせい」といった反感を持つようになった。そもそも分業は規模の拡大や効率化を狙ってなされる合理的なプラクティスである。しかし、設計担当と実装担当との分断や対立を招く分業体制は、開発チームと個々のメンバーの無能化しかもたらさない。
問題が多いにもかかわらず、大袈裟な分業体制を前提とする開発体制が今でも主流なのはなぜか。一次請けのSIer（ITゼネコン）がそれをやりたがるからだ。
一次請けといっても彼ら自身は設計さえしない。名刺の偽造までして下請けに開発実務を丸投げする。尼崎市の件で明らかになったように、n次請けはさらにn+1次請けに無断で丸投げしたりする。一次請けは高単価のプロパーPMを送り込み、下請けからのマージンで稼ぐことに徹する。当然ながら工数が多いほど儲かるし、こまごました分業の細目は膨大な工数の根拠になってくれる。
では、そんな一次請けになぜ顧客はわざわざ発注するのか。ブランド力がそれなりにあるからだ。発注側は「この有名企業でも失敗したのだがら、無名だったらもっとひどかっただろう」と納得してくれる（かもしれない）。その業者を選定した担当者も責任追及されない（かもしれない）。品質を伴わないブランド商売は長続きしないものだが、多重下請構造を形作るエコシステムの巨大さゆえにまだ存続しそうだ。しかしそこに棲息する技術者が幸せになれるとは思えない。ユーザ企業を含めた多くの関係者の緩慢な不全感の上に、工数主義ビジネスは成立している。
しかしユーザ企業もバカではない。一次請けの開発スキルが空洞化していることを彼らもとっくに認識しており、ローコード基盤を利用した内製化を模索している。もちろん彼らにとってシステム設計は簡単な課題ではない。しかし、設計から実装まで一気通貫で担える外部の専門家と連係すれば、少数の社内要員で多くの開発作業を賄えてしまう。SIer界隈の「設計できる（っぽい）が実装できない者」も「実装できる（っぽい）が設計できない者」も「プロジェクト管理（下請管理）しかできない者」も出る幕がない。
そんな時代に備えるために、従来の分業体制向けに最適化された働き方は是正されるべきだ。代わって、内製プロジェクトに外部の専門家として歓迎されるようなスキルセットを意識したい。複数言語でのプログラミング、複数のローコード基盤、そして業種横断のシステム設計に習熟しておきたい。それは他人のショボい設計によって職業人生を振り回されないためでもあるし、自分の設計の良否を実装者として引き受けるためでもある。なによりも、仕事を通して社会に貢献している手ごたえを得るためだ。
