ソフトウェア部品化の幻想

@kuranukiさんと@yusuke_arclampさんのやり取りが面白かったのでメモ。
考えたことをラフなメモ書き。

【元ネタ】
ソフトウェア開発プロジェクトをとりまく６つの誤解?プログラミングを経験しないとわからないこと - Social Change!

「ソフトウェア開発プロジェクトをとりまく６つの誤解」は真実でもある - arclamp

「ソフトウェア開発プロジェクトをとりまく６つの誤解」をとりまく@yusuke_arclampさんとのやり取り - Togetter

僕はお二人とも知っており、尊敬している。
@kuranukiさんは自社のWebサービスを持つ経営者の観点、@yusuke_arclampさんはアーキテクトないしマネージャの観点で議論されている。
二人が経験されている現実をもっとぶつければ、何に引っかかっているのか、もっとはっきりするのになあ、と思ったりする。

@kuranukiさんの指摘は、現場の開発者の立場ではとてもよく理解できる。
違うコンテキストだが、ソフトウェアの品質特性について、従来の製造業の品質管理とは異なる観点が必要ではないかという意識を持って、下記を書いた。

アジャイル開発が問題点をすり替えた品質特性～機能性と信頼性: プログラマの思索

アジャイル開発が重視する品質特性～保守性と移植性: プログラマの思索

@kuranukiさんがあげた６つの誤解のうち、「既にあるソフトウェアを流用した方が速く作れる」「共通部品から先に作ることが出来る」は移植性、「ソフトウェアはハードと違って後から容易に直せる」は保守性の品質特性に強く関係する。

移植性の問題は、OSやソフトウェアの後方互換性、あるいは、ERPやパッケージ製品、組込製品のような製品系列のソフトウェアでよく出てくる。
ある顧客向けに作ったWebシステムの評判が良かった場合、他の顧客にも若干カスタマイズして販売すれば安上がりに売れるだろう、と思って開発するパターンはとても多い。
だが、ERPのような大型パッケージ製品は、カスタマイズという名のデスマーチ案件が非常に多い。

また、MicrosoftのOffice製品のように、PersonalベースからProfessional、Enterprise向けに機能を追加して価格帯を変えて販売するようなソフトウェアプロダクトラインをやっている会社も多い。
だが、このようないわゆる派生開発は意外に難しく、プログラミング工数はほとんどないのに、テスト工数ばかり膨れ上がる案件が非常に多いだろう。

清水吉男さんが提唱されているXDDPという派生開発プロセスでは、移植性や保守性という品質特性を特に重視している。
移植可能なソフトウェアでなければそもそも派生開発がとてもやりにくいし、カスタマイズしていくに従って保守性がどんどん悪くなっていくからだ。
だから、派生開発の要件に、保守性という品質特性も入れるべきだ、という主張をされているが全く同感。

移植性は再利用性とも密接に関係する。
共通部品は再利用できるからこそ「共通」部品なのであり、数多くの顧客や長年の本番運用で使われているから品質が保証されている。
しかし、ERPの部品のようなビジネスオブジェクトのレベルの部品はなかなか再利用できるほどの品質にも使い勝手にもならない。
EJBやCORBAなど今後流行するだろうと言われた再利用ソフトウェア部品は、結局使い物にならなかった現実がある。

その理由は下記の記事にうまく書かれている。

「ソフトウェアの部品化」が失敗する理由 － ＠IT

共通部品の開発、そして再利用できるほどの品質保証、そして、再利用できる部品開発を支える経営資源の確保まで幅広く問題が横たわっている。
個人的には、ソフトウェアの品質特性の中では移植性が一番難しく、移植性の難しさがソフトウェアの特徴をうまく言い当てているように思っている。