設計者の発言

前回、前々回と、良き友人である平澤さんがオブジェクトモデリングの立場から反論してくれて楽しかった。平澤さんとは彼が「オブジェクト指向でなぜつくるのか」でブレイクする前からの仲で、「上流工程入門」で書いた「モデリングって芸ですよね」と語った同業者というのは彼のことだったりする。ＸＰの実践やＪｕｄｅで有名な平鍋さんや、「モデリングの本質」の児玉さんを紹介してくれたのも彼で、出不精でひとづきあいの悪い筆者にはありがたい友人だ。

◆「ＤＯＡ対ＯＯＡ」でも「改革派ＶＳ守旧派」でもなく

平澤さんとのやりとりを読んで、システム開発の世界に「ＤＯＡ対ＯＯＡ」の対立があると理解してもらっても間違いではない。しかし、それだけでこの世界の情勢を理解したつもりになってもらっては困る（平澤さんも同じ気持ちだと思う）。なぜなら、「非ＤＯＡ」はＯＯＡとは一致しないし、「非ＯＯＡ」もＤＯＡとは一致しないからだ。実際の上流工程の現場の大半は、ＤＯＡでもＯＯＡでもない「無手勝（むてかつ）流」、要するに「無批判に踏襲された昔からのやり方」でなされているのが実態だ。

では「改革派ＶＳ守旧派」の図式でこの世界を理解できるかといえば、それでも十分ではない。ＯＯＡもＤＯＡも無手勝流も、「スクラッチ開発（一からの手作り）」を前提にしているという意味では同じ穴に棲むムジナである。重要なのは、その「穴」が経済社会のどこにあって、競合するものが何であるかを理解することだ。この穴が小さいか縮むばかりだとしたら、開発手法にまつわるすべての議論が「コップの中の嵐」にすぎなくなる。

◆「スクラッチ開発」という名のゴムボート

別の言い方をしよう。友好的であれ、けんか腰であれ、「いかに分析・設計・開発すべきか」の議論に興味をもつような人々はすべて「スクラッチ開発」という名のゴムボートの同乗者である。そして、ゴムボートが縮むとしたら、「オブジェクト小僧」も「ＤＯＡ小僧」も「方法論のセンセイ」も、ひとりまたひとりとこぼれていかざるを得ない（たぶん、声の小さい順で）。

「ソフトウエアビジネスの競争力」(ソフトウエア産業研究会,中央経済社,2005)という本では、受託開発偏重のビジネスモデルが、日本のソフトウエア企業の拡大を阻む原因のひとつとされている。その根拠として、海外にビジネスを広げにくいとか、重層的な下請け構造が強化されるいっぽうとか、オフショア開発が普及しつつあるとかいった問題が挙げられている。

そのような分析を読むまでもなく、受託開発が「成功しにくく手離れが悪い、効率の悪いビジネス」と感じている人々は少なくない。このスタイルに将来性がないと考えている経営者の比率も意外と大きい。筆者が知っているある経営者も最近そのような理由で受託開発事業から撤退した。現場の技術者の多くも、システム開発のオイシイところは元請け企業の連中に持っていかれていると感じている。スクラッチ開発のスタイルは想像するほどステキなものではない、そのように思えてくるのも無理はない。

◆同じ川を行く別のゴムボート

この閉塞感を打開する方法は基本的に２つある。ひとつは「同じ川を行く別のゴムボートに乗り移る」で、もうひとつが「今乗っているゴムボートの乗り心地を良くする」だ。

上掲の本では、日本のソフト開発企業は、欧米で主流の「パッケージ開発」のスタイルにビジネスモデルを転換しなければいけないと結論づけている。つまり、「スクラッチ開発」のゴムボートは縮退するいっぽうだから、別のゴムボートを組み立てて乗り移ろうというわけだ。

ケーススタディを読んで驚くのは、パッケージ開発に特化した企業の、スキル習得に関するバランス感覚の健全さである。ある有名なパッケージのシリーズを扱っている企業では、社員全員が日商簿記２級とマイクロソフト認定技術者の資格を持っているという。また、広く知られているとおり、パッケージ導入にはさまざまな無理や不合理がともなうが、それらの問題を克服する手段もないわけではないようだ。さすがに適用可能な業種・業務領域は限られるとは思うが、特定の業種向けのパッケージ導入で定評を得るだけでも、市場規模は決して小さくはない。

そう。「スクラッチ開発」という名のゴムボートに乗っている我々にとっての「敵」は、彼らのようにやる気と実質的な専門技能にあふれた「日本の商習慣にアドオンやカスタマイズなしで馴染む業務パッケージの開発企業」だ。

いや、あわてて訂正する。彼らは我々の「好敵手」ではあるが「倒すべき敵」ではない。多様性の一部として受け入れるべき仲間だ。実際、パッケージ導入がもっと普及すれば、受託開発に求められるシステムの完成度が高まって、ソフト開発企業間の健全な競争が進むだろう。

◆業務知識のライブラリー化が急務

「倒すべき敵」はむしろ、「分析手法ＡかＢか」だの「関連を示す線は直線か曲線か（とほほ、筆者のことさ）」だの「言語ＸかＹか」だのを議論して夢中になってしまう、我々自身の技術偏重の姿勢なのではないか。そのような瑣末な違いでの優位性を主張して、限りあるゴムボートの空間を確保することに躍起になってるような場合じゃない。そんなことよりも重要な、乗り心地を悪くしている「ゴムボートそのものの問題」がある。

そのような問題として筆者は、「業務知識ライブラリーの貧弱さ」をまっさきに挙げたい。何十年にも渡って蓄積されてきた業種別・業務別の設計事例を、わかりやすい様式で体系化して、誰もが利用できる形で流通させる。この動きが決定的に不足している。以前の記事にも書いたが、この現実は何度蒸し返しても足りないくらい重大だ。

これは、我々が乗るゴムボートの経済社会での位置づけを考える際に、いやでも意識せざるを得ない問題でもある。なぜなら「パッケージ」が、現時点で実現されている希少な「ライブラリー化された業務知識」の一形態だからだ。我々がモタモタしていまだに提供できていない知識を、パッケージが代わって企業社会に提供してくれている。パッケージ導入のやり方にさんざん問題が指摘されているわりに絶える様子がないのは、要するにそのように一定の社会的役割を果たしているゆえだ。

我々「スクラッチ開発至上主義者」たちの体たらくはどうだ。スクラッチ開発が始まってから何十年もたつのに、業務別、業種別のシステム設計の「型紙」がまるで整備されていない。相変わらずシステム設計は経験者頼りで、その数少ない経験者も知識を公開することに消極的だ。石を投げれば、決算の意味も知らないような開発者に当たる。

しかも、業務知識習得の意欲の減退は年々強化されるばかりだ。このゴムボートの乗客の多くは、業務知識を地道に身につけようとしない。年々登場する新しい技術を追いかけるほうがファッショナブルだし楽しいからだ。実際のところ、技術論は語って楽しいし、同系統技術のファンによるコミュニティも林立していて、共感してくれる仲間も多い。気の合う仲間同士でわいわいやっていると、その種の知見がゴムボートの乗り心地を良くしてくれる決め手のようにも思えてくるものだ。

自戒をこめて言うが、技術論がゴムボートをパラダイスに導いてくれるなんて考えは幻想だ。分析設計技術はほっといても精緻化され、プログラミングやテスティング技法はほっといても洗練されてゆくだろう（なぜなら、みんなそれらのいずれかが大好きだからだ）。しかしそのいっぽうで、コンピュータの文脈で再編成されるべき業務知識の層は薄くなってゆくだろう（なぜなら、みんなそんな地味でオッサンぽいハナシには興味を持てないからだ）。このようなアンバランスが是正されない限り、どんな技術論もゴムボートの穴をふさいではくれない。

こんな調子では遅かれ早かれ、技術論とは健全な距離を保っているパッケージ開発企業のボートに、我々のボートは先を越されてしまうだろう。もっとも、相変わらず技術論トークで盛り上がっていて、遅れをとったことにも、ボートが沈みかけていることにも気づかないかもしれない。