« 「関連クラス」をデータモデルで解き明かす(後編) | トップページ | 「As-is先行」か「To-be先行」か »

2005.05.01

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

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

◆「DOA対OOA」でも「改革派VS守旧派」でもなく

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

|

« 「関連クラス」をデータモデルで解き明かす(後編) | トップページ | 「As-is先行」か「To-be先行」か »

コメント

はじめまして。

渡辺さんのブログは、毎回楽しみに拝見させて頂いております。


「なぜパッケージが普及しない(できない)のか」あるいは、
「なぜパッケージを適用する必要があるのか」を絡めて論を
展開する必要があると思います。

開発要件は、顧客の特殊事情や組織の文化によっても異なり、
組織が抱えている現状の問題を背景として確定されます。

長年システム開発に携わられている方はご存知だと思いますが、
機能的要求だけが求められているわけではないとうことです。

業務知識そのものは普遍的ですが、顧客の要求やそれを取り巻く
環境の変化は激しく、生物と同じように常に進化しています。

これをパターンとして定型化することは困難であり、無理に
定型化しようとしても、極々普遍的な共通部分だけが可能に
なるだけで、僅かな安定性の向上が実現されるだけです。

それ以前の問題として、本来オリジナル開発が適切であるところ
を、最終的にパッケージに頼らざるを得ないほどに、我が国の
システム開発能力が低いのか、そこが問題であると思います。


一般に、バグの原因の80%以上は、仕様と設計に関するものです。

通常の開発組織では、「何を作るのか」「どう作るのか」を定めない
ままで、開発(プログラミング)に取り掛かってしまいます。

何度も仕様を顧客に確認することになり、修正を余儀なくされます。
これが手戻りの原因であり、生産性と品質を大幅に低下させます。

仕様が曖昧だということは、つまりそこで開発する(作成する)
成果物が正確に把握できないということです。それゆえ、正確な
見積もできないし、まともなスケジュールも立てられません。

こんな状況で、まともなソフトウェア開発ができるはずがない。
しかし、世の中のプロジェクトは、大半がこういった状況です。


自分は、我が国のエンジニアリング教育に問題があると考えます。

実際、システム開発に携わっているのは、プログラム言語を覚えて、
文献にある設計法(というより単なる表記法)をかじっただけの、
まったくの素人な技術者なわけです。

本来なら、上司や先輩が教育を行うべきなのですが、先輩諸氏も
正式な工学手法を教わった、あるいは自ら学んだわけではない。

プログラム言語を使える適度の教育を施し、あとはOJTと称して、
火を噴く寸前のプロジェクトに放り込まれます。そこでは、正しい
システムの設計法や要件の分析法など、学ぶ機会などないわけです。

自分自身はまだ学生ですが、以前にプロセスについて深く勉強する
ために、CMMで有名なハンフリー博士が執筆された教科書である、
PSP「パーソナル・ソフトウェア・プロセス」を勉強しました。

そこでは、「バグの発生する仕組み」=「バグを作りこむ仕組み」
からはじまり、どうすればバグを作りこまないように開発できる
のか、そのための設計法やレビューの方法などを学びました。

残念ならが、無欠陥開発(ZD)には到達できませんでしたが、
しかし、適切な手法と適切な訓練さえ行えば、可能であるとの
結論に行き着きました。実際に、数万行のオープン系コードを、
一回のコンパイルで通すほどの技量を持つエンジニアもいます。

【参考】:
http://homepage3.nifty.com/koha_hp/process/Proc.Dr.Humphery.html
http://homepage3.nifty.com/koha_hp/process/ProcRework.html

重要なのは、手法論や業務知識に関してではないと考えます。

「どうすればバグを作り込まないように開発することがでるか?」
「どうすれば手戻りによる生産性の低下を防ぐことができるか?」
「どうすれば顧客の要求(真意)を掴み取ることができるか?」

そのための「仕組み(=開発プロセス)」と、それを考案し実現する
要員の教育についの議論が主体となることを期待しております。


自分自身としては、その為に貢献できる努力として、統合CASE
環境の開発プラットホームを研究開発しています。開発プロセスに
ついての教育に使用する「教材」としての活用も考えております。

http://members.at.infoseek.co.jp/aspara_2000/

渡辺さんの開発したツール「XEAD」は非常に良くできているので、
研究する上での御参考にさせて頂かせてもらいました。

今後も勉強させてもらうことがあるかも知れませんが、
なにとぞ宜しくお願いいたします。

投稿: 後町剛 | 2005.05.01 17:05

こんにちは、トラックバック打たせたもらったものです。
いつも拝見させていただいております。

なぜパッケージを使うのか?
・・・質の高いものが早く安く入手できるから?

一方でこんなレポートもあります。興味深い。
「なぜ、R/3のシステム開発と運用コストは高いのか?」
http://www.atmarkit.co.jp/fbiz/cbuild/serial/r3/01/01.html
アドオンの問題について触れてます。

投稿: dev | 2005.05.01 18:16

私はブレイクしてたんですね?全然気づきませんでした(笑)。
さて、またまた面白いテーマなので、自分のblogから「イチャモン」をつけさせていただきました。それでは

投稿: ひらさわ | 2005.05.05 21:56

>後町さん
興味深い研究です。業務知識ライブラリーの流通に貢献するかもしれませんね。それにしても、日本の大学はソフトウエアのような変化の早い世界の教育を提供できない構造なのでしょうかね。「ソフトウエア教育の変革」というより、「経済社会の変化に俊敏に対応するような変革」が要るのだろうなあ。

>devさん
@ITのその記事、私も面白く読んでます。アドオンをはなから想定していない、日本の商慣行に一致したパッケージが普及すると、外国製パッケージはつらいと思いますね。

>ひらさわさん
私が心配しているのは「バランス」なんですよね。魅惑的なデートのための手練手管を修練するばかりで、当の相手のことをちっとも理解しようとしないみたいなアンバランス。ようするに会計の勉強をもっとマジメにやれってことなんですがね。

投稿: わたなべ | 2005.05.08 07:42

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: 「スクラッチ開発」という名のゴムボート:

» スクラッチ開発とか [眠る開発屋blog]
「スクラッチ開発」という名のゴムボートで「スクラッチ開発」と「パッケージ開発」の対比について述べられている。 そう。「スクラッチ開発」という名のゴムボートに乗っている我々にとっての「敵」は、彼らのようにやる気と実質的な専門技能にあふれた「日本の商習慣にアドオンやカスタマイズなしで馴染む業務パッケージの開発企業」だ。 いや、あわてて訂正する。彼らは我々の「好敵手」ではあるが「倒すべき敵」ではない。多様性の一部として受け入れるべき仲間だ。実際、パッケージ導入がもっと普及すれば、受託開発に求められるシス... [続きを読む]

受信: 2005.05.01 15:42

» 本質を突かれた [atsushifxの七転八倒]
「非DOA」はOOAとは一致しないし、「非OOA」もDOAとは一致しないからだ。実際の上流工程の現場の大半は、DOAでもOOAでもない「無手勝(むてかつ)流」、要するに「無批判に踏襲された昔からのやり方」でなされているのが実態だ。 では「改革派VS... [続きを読む]

受信: 2005.05.01 23:20

» [友人] 再び「設計者の発言」へのイチャモン [UMLモデリングレッスン執筆日誌]
渡辺幸三さんの「設計者の発言」の最新エントリを読んだ。率直な印象は「なんだか渡辺さんらしくないなー」である。 何しろ氏は、数年前に40才を通過したにも関わらず((自分も渡辺さんとは同い年である。))、DOAの設計手法にこだわり続け、JavaでCASEツールを自作してしまう「良き中年技術者仲間」なので。そうでしょ、渡辺さん(笑)? たしかに最近業務パッケージやオフショア開発が業界に浸透してきているのは事実である。それらは成功している面と、苦労している面の両面があるのが実態だが、今後もさらに広まっ... [続きを読む]

受信: 2005.05.05 21:38

« 「関連クラス」をデータモデルで解き明かす(後編) | トップページ | 「As-is先行」か「To-be先行」か »