ソフトウェア部品という言葉は、マネジメントや経営層にとって魔法のような言葉に聞こえるらしい。
部品化して再利用することで、似たようなソフトウェアなら工数は劇的に節約できるし、すでに実績のあるモジュールなら品質も担保されている...。
そんなソフトウェアモジュールは希である。
よほど最初から再利用を意識した設計で作らないと、何かのプロジェクトで作ったモジュールをそのまま別のプロジェクトに流用してコストが下がったというケースはあまり無い。
動作環境が異なることで予想していたパフォーマンスが出ない、インターフェース定義も最初に作ったプロジェクトには最適化されてても、他のプロジェクトでの使い方にマッチしていないことが多いのではないかと思う。
確かに当てはまる使い方ができればメリットはとても大きいと思うけれど、それを安易に夢見るマネージャや上層部がほとんどだ。「よそでこんなモジュール作ってたからそのまま使えるよな？」と中身も見ずに言って来て、なおかつ見積もりの工数をその分差し引いてしまったり。汎用性を持たせたモジュールは、どこか使いづらいところが発生しそれをカバーする実装が必要になるということなんだが。
どこかの会社も過去に「部品化の推進」とトップの大号令がかかったけど、ツールやらドキュメントやらソースコード、ノウハウと対象を広げすぎたのと、社員に対してノルマ制で「一人一つは何か部品を部品データベースに登録しろ」という指令のせいで、そのデータベースはカオス状態。なぜか秀丸エディタが「コーディングの生産性を上げるツール」として登録されていたり、使えないものばかりが山積みになったデータベースができあがった。また検索システムが貧弱で何が入っているのか探しづらく、すぐに閑古鳥が鳴く状態に。その後、組織変更でそのデータベースもきっと闇に消えたとは思うのだが...。
この会社の場合はトップの指令を本社部門が目的を理解せずに体面だけを整えようとした結果失敗したというのもあるのだろうけど。
ソフトウェア部品という言葉の響きに期待せず、ある程度似通った性質を持つプロジェクト間で、最初から部品化を見据えて設計するなら効果は出るだろう。片手間では無く、本気で汎用性とは何かを考えて設計するための「部品化の準備」にかかるコストはそれなりに覚悟しておいた方が良いだろう。ソフトウェア部品なんて使われなかったらそれまでの話だから。
