なぜソフトウェアの部品化／再利用は進まないのか？：情マネ流マーフィーの法則（34）

ソフトウェア開発において、部品化／再利用は永遠の課題とも言える。昨今ではオブジェクト指向やSOAが注目されているが、本格的に普及しているとは言い難い。では、なぜソフトウェアの部品化は進まないのだろうか。今回は部品化／再利用に関する法則を紹介する。

[木暮 仁，＠IT]

　ソフトウェア構築の生産性向上、品質向上のために、ソフトウェアを部品化して再利用することが重要なことは、コンピュータが出現した当初から指摘されてきた。それなのに、現在でもオブジェクト指向だのサービス指向だのと騒いでいる。

　なぜソフトウェアの部品化／再利用は進まないのか？

情マネ流マーフィーの法則その191

部品箱をごみ箱にするな

　工業分野では、部品の標準化は常識である。

　例えばボルトの寸法はJISで定められており、「M6」と指定すれば、頭部分の寸法やネジのピッチは周知であり、いちいち指定する必要はない。しかも、それに対応するナットや工具があることが保証されている。標準化が生産性向上やコストダウンに貢献することは明白である。

　IT分野でも、昔からサブルーチンや標準パターンなどの標準化が試みられてきた。ところが実際には、公式ライブラリの利用が少ない、統一管理ができない私有ライブラリが数多く存在しているなど、有効に活用されてこなかった。オブジェクト指向やサービス指向では、コンポーネントの部品化と再利用が必須になるが、現実にはライブラリは、体系化されていない再利用不能なコンポーネントのごみ箱になっているのだ。

　そのため、ライブラリから適切な部品を探して、その機能やインターフェイスを調べる労力が大変で、独自に新規開発する方が手間が掛からないような状態になる。これでは、部品化／再利用が進まないのは当然である。

情マネ流マーフィーの法則その192

「探す」労力が「作る」労力よりも大きければ、部品化は実現されない

　教科書では、このような事態を改善するために、標準化推進の担当組織を作れとか、意識変革のキャンペーンをせよと指摘する。それは正しいことではあるが、サブルーチン時代から言われており、実効が得られなかったのである。もっと原因にさかのぼる必要がある。

　独自のボルトを設計して製造するよりも、JISの表を探す方が簡単だし、独自の新規仕様部品を用いるために多方面を説得するよりも、既存仕様の部品をうまく利用する方が手間が掛からない。工業製品の部品にはこのような特徴があり、部品化（標準化）が進んだのだ。

　それに対して、ソフトウェアの生産技術は、部品化を行うにはあまりにも発展しすぎてしまった。ソフトウェア部品を探すよりも、作る（プログラミングする）労力の方が小さい。しかも、素人でもそれなりに自作することができる。

　昔、アセンブラプログラムを紙カードに穿孔してコンピュータの順番を待っていた時代の方が、部品化・再利用が盛んだった（思想的には幼稚であったが）。現在でも、科学技術計算アルゴリズムなど、自分では作成できない分野では、サブルーチンやパッケージが使われている。

　このようなことを考慮すると、部品化の対象を再検討する必要があることが分かる。

情マネ流マーフィーの法則その193

複雑な部品は使えない

　「作る労力が大きな対象を部品化対象にすべきだ」とするならば、部品の粒度を大きくすることが考えられる。プログラムの一部を部品化するのではなく、業務システム全体を対象にするならば「作る」労力は大きくなる。

　実際に、ITでの部品化では、サブルーチンからオブジェクト指向へと部品の粒度を大きくしてきた。その究極がERPパッケージである。

　しかし、粒度が大きくなると、仕様を指定するための複雑性が非常に増大する。ERPパッケージをユーザーニーズに合わせるためには、膨大なカスタマイズ（仕様指定）が必要になり、独自仕様で構築するよりも大きくなることすらある（業務をパッケージに合わせよという議論はここでの対象外である）。

　さすがに、これは極端だというので、粒度を「サービス」のレベルまで小さくしようという動向になってきた。ところが、最も共通化されているはずの財務会計ですら、A社のアプリケーション部品で償却計算を行い、B社の部品で在庫評価を計算して、C社の部品で財務諸表を作成するというような部品化にはなっていない。

　私見であるが、この部品化が円滑にできない理由はデータにあると思う。

　単一データの処理仕様は単純であっても、対象となるデータが大量で、しかもその記録方法が多様なことが、サービスの分割を妨げているのではなかろうか。部品化技術として、これまでにハードウェアやプログラミング言語からの独立は達成されつつあるが、データベースからの独立は、これからの問題であろう。

著者紹介

▼著者名　木暮 仁（こぐれ ひとし）

東京生まれ。東京工業大学卒業。コスモ石油、コスモコンピュータセンター、東京経営短期大学教授を経て、現在フリー。情報関連資格は技術士（情報工学）、中小企業診断士、ITコーディネータ、システム監査など。経営と情報の関係につき、経営側・提供側・利用側からタテマエとホンネの双方からの検討に興味を持ち、執筆、講演、大学非常勤講師などをしている。著書は「教科書 情報と社会」（日科技連出版社）、「もうかる情報化、会社をつぶす情報化」（リックテレコム）など多数。http://www.kogures.com/hitoshi/にて、大学での授業テキストや講演の内容などを公開している

「情マネ流マーフィーの法則」バックナンバー

• 情マネ流マーフィーの妖誤集〜その3
• 情マネ流マーフィーの妖誤集〜その2
• 情マネ流マーフィーの妖誤集
• 情報科学の法則を復習しよう
• 社会科学法則の「情マネ流マーフィー」への適用
• 自然科学法則の「情マネ流マーフィー」への適用
• コンピュータが発展すると人間はバカになる
• バグとの長い長い付き合い
• なぜソフトウェアの部品化／再利用は進まないのか？
• “バカ・マジメ”をメンバーに入れるな！
• なぜIT部門は提案できない／しないのか？
• ユーザーニーズを基にシステムを作るな
• 成果の出ないIT戦略
• IT技術者、どう評価する？
• 何かが足りない日本のIT教育政策
• 電子政府の研究はIT推進の教科書として最適だ
• 日本にはびこる素人CIO
• IT部門の戦略部門化は矛盾だらけ
• なぜIT部門アウトソーシングがうまくいかないのか？
• IT部門の社内的地位が低い“本当の原因”は？
• 役に立たないグループウェア
• ユーザーの過度体裁愛好症が問題だ
• ユーザーの過度依存症とIT部門の没我的愛情症
• ああ、上司と部下の悲しいすれ違い
• IT系アンケート結果は信用できない
• “クラウドコンピューティング○×”の寿命
• 羊頭狗肉のIT用語、誇大表示を告発する
• そして、歴史は繰り返す − 2度目は喜劇として
• ITエンジニア今昔物語
• “リスク管理のリスク管理”が必要だ
• 納期とは遅れるものだ
• ITの効果とはプロジェクトの効果だ
• 費用対効果を追求することで出銭が増える愚かさ
• そもそも、IT計画が実現すること自体が奇跡だ
• 経営者にITの費用対効果を説明するのは難しい
• ERPパッケージの不思議あれこれ
• 合併時の代理戦争には気を付けろ！
• ないものねだりのRFP
• 標準化にメリットはあるのか？
• システム開発の可視化で何が見える？
• 「他人のふんどし指向アプローチ」を考える
• マーフィーの法則がIT版になって帰ってきた！