多くの開発ベンダーには基本設計フェーズで求められる能力、すなわち「顧客の問題を解決するシステム仕様の構想力」が決定的に不足している。彼らが遅かれ早かれ始めるのが、顧客自身にシステム仕様を決めさせる手法だ。そのスタイルは「要件定義支援」とか「アジャイル手法」と呼ばれている。
ベンダーに代わって顧客自身にシステム仕様を決めさせることの何が問題なのか。顧客はシステム設計のプロではない。にも関わらず彼らの要望をそのまま具体化するなど危険極まりない。自家用飛行機を開発したいと考えている顧客に対してベンダーが「わかりました。カッコイイと思う飛行機のイメージを存分に語ってください。そのとおりの図面をまとめて組み立てます」と提案するようなものだ。それで出来上がった飛行機にあなたは乗りたいだろうか。そんな無責任なベンダーは航空機業界にはいないだろうが、業務システムの開発業界にはゴロゴロいる。
要件定義支援の問題
じっさい、「外部業者による要件定義なんて要らない」で述べたように、IPAの要件定義成果物一覧は「基本設計成果物一覧」とほとんど区別がつかない。要件定義書にもとづいていきなり実装を始めるベンダーさえいる。ベンダーが要件定義書の文書化を支援するにせよ、中身を考えるのはけっきょく顧客。要件定義支援が「素人に丸投げされた基本設計」と化している実態がある。
恐れ入ることに、基本設計における最高難度Hのワザである「データモデリング」までが、本来は顧客の仕事であるはずの要件定義に堂々と含まれていてる。それは以下の調子で実施されるのだろう。
「要件定義書としてデータモデルという図面をまとめる必要があります」「データモデルですか。聞いたことはあります」「どんなデータモデルが必要でしょうか？」「えーっと、よくわかりません」「困りましたね。自分たちの情報システムなんですから、それなりのデータモデルは決めてもらわないと」「そうはいっても描いたことないし」「では我々が代理でまとめますから、検収（評価）してもらえばその通り作ります」「わかりました」
代理で作られたモデルは粗悪なデッチ上げなのだが、その妥当性を顧客は素人なので評価しようがない。しかし、いったん要件が検収され、そのとおりに実装されたものについて顧客が満足できない場合、そのの責任はモデルを含めた要件定義書に検収印を押した顧客側にある。なぜなら要件定義書は「顧客が欲しいものの定義」だから。図面どおりに組み立てた飛行機が墜落しても、その責任は図面を検収した顧客側にあるという論法だ。訴訟対策なのかどうかは知らないが、あまりに無責任と言わざるを得ない。
このようなスタイルで要件定義に進出するベンダーは、主にメーカー系の大手SIerに多い。COBOLあたりで動いていた古いシステムの機械的モダナイズや、ERPの導入ばかりこなしたせいで設計スキルが空洞化した結果である。なにしろプロパーの多くは簿記の資格を持っていても、簿記のデータモデルを描けない。会計知識を情報処理の文脈で理解していないからだ。航空力学を知らない航空機技術者や、構造計算できない高層ビル建築士のようなものだ。
アジャイル手法の問題
いっぽう、プログラミング指向の技術者が集まる独立系ベンダーが向かうのが「アジャイル手法」である。システム設計に関して素人である顧客の「UI/UXへの納得感」が仕様策定の根拠となるので、技術者自身の深い知見やシステム観は要らない。小ぶりなサービス系やプロダクト系にアジャイル手法は合うだろうが、業務システムのように複雑なデータベースを核とするソフトウエア向けに適用するとロクなことにならない。なぜか。
アジャイル手法の信奉者は、データモデリングのような辛気臭い作業よりUIデザインやプログラミングを優先させる。そのため、広域データモデルを確立せずにいきなりアプリを作り始める。結果的に、個々のUIやアプリを制御する永続クラス群（主キーはぜんぶid）を含むものの、関数従属性にもとづく「情報の論理構造」のないデータベースもどきが出来上がる。情報基盤が軟弱なので、異常値がいつまでも解消されないモグラ叩きが始まる。
こうなると顧客も辛いがベンダーも辛い。顧客が検収印を押すタイミングが存在しないという意味ではベンダーのほうが辛いかもしれない。複雑なデータベースの上で機能する情報システムを甘く見てはいけない。本来ならば「自分も試乗する飛行機」を開発するくらいの覚悟と、優雅に飛行する機体をひとりでゼロから設計・実装できるくらいの腕が求められることを知ってほしい。
ドメイン駆動設計の問題
アジャイル手法がなかなかうまくいかないので「最後の頼みの綱」的な人気を博している手法が「ドメイン駆動設計(DDD)」だ。「ドメイン知識（当該事業の業務要件）をプログラムコードで端正に記述せよ」というもっともな提案なのだが、これにも無理と欺瞞が隠されている。
ビジネスルールを含む業務要件を的確にコードに落とし込めたとしても、それはあくまでも「業務要件のスケッチ」であって、「業務要件をスマートに扱うためのソリューション」ではない。開発者は後者を創造しなければいけない。エバンスはそれを「深いモデル」と呼んでDDDの目標とするが、あまりに観念的で参考にならない。
しかも、深いモデルなるものを「コード」で端正に記述することが前提になっているのが解せない。コード以外の手段（たとえばドメイン特化言語）でエレガントに記述できるような工夫がほしい。すべてを汎用言語で記述すべきと言い張るのは、ソフトウエアは機械語で緻密に記述されるべきと言い張るのに似ている。実装の合理化という観点で、DDDのコード偏重主義は受け入れがたい。
また、DDDでは依頼者側の「ドメインエキスパート」や「プロダクトオーナー」の役割が強調されており、彼らをドメイン知識の源泉としている。DDDを実践する開発者はプログラミングのエキスパートに徹すべし。個々の案件に必要なドメイン知識については必要に応じて他者から調達すればよい。そのように彼らは考えるが、技術者のキャリアにとって危険な思い込みだ。
本来であれば、技術者自身が「事業活動を支える情報システムの開発」というドメイン（経済分野）のエキスパートであり、ドメイン知識の豊かな源泉でなければいけない。その膨大な知識量に比べたら、顧客が語る業務要件は重要だが局所的・付加的なものでしかない。自分が持つべき高度専門性に関して他人をあてにしてはいけない。IT技術者にプログラミングスキルは欠かせないが、それはいずれかの経済・社会分野の深い知見と統合されることでようやく稼げる手段となる。ようするに「プログラミングだけやりたい」では低収入のままだし何者にもなれない。
基本設計から逃げてはいけない
業務支援システム開発を担うIT技術者が身につけるべき高度専門性、それは「業務支援システム開発」という特定ドメインに関する知識とセンスと経験である。それらは基本設計を遂行するため、すなわち、顧客の曖昧かつ散漫な悩みを抜本的に解決するための論理的枠組みを創造するために欠かせない。それさえあれば、無責任な要件定義支援や蛮勇あふれるアジャイル手法に頼る必要はない。
もちろん、そういった専門性を身につけるのは簡単ではない。地道な学びや実績作りのための積極性、そしてある種の職業適性が求められる。しかし、困難だからといって安易な要件定義支援やアジャイル手法に逃げれば、10年くらいあっという間に溶ける。
どうか、IT技術者としてグングン伸びる35歳までに、日商簿記3級（2級は無駄に複雑なのでお勧めしない）を学んで、簿記のしくみを理解するとともにそのデータモデルをそらで描けるようになってほしい。学びの過程で「簿記のデータモデルって描けますか？」と社内で訊き回ってみよう。さっと描ける先輩がいたらあなたは果報者だ。ビールを飲みながら「出庫単価の設定ってなんかややこしいですよね」とか「減価償却のテーブル操作ってどんな感じになるんでしょう」なんて会計ネタを交わせる仲間は、業務システム開発の専門家を目指すあなたの盟友となるだろう。
