再利用資産を作る勇気

最近、「別製品の過去のソフトウェアを参考にして（とある）機能を実装した」という変更履歴を見た。その行為に対して「同じ機能を実装するのになぜ修正が必要なのか？」「再利用できる資産を使うという解決方法はないのか」という突っ込みを入れる者はプロジェクト内に誰もいない。これこそが、「あたたかい人間関係の中のやさしい一員」の特徴だ。プロジェクトリーダーの承認やプロジェクトメンバーのレビューなしに変更が進められ、誰からも「ちょっと待った」と言われることはない。直近の問題解決が優先され、長期的な改善活動のことは視野には入っていない。

厳しい言い方をすえば、再利用資産を作る技術も勇気もない。コピペして直して動いたら終わり。それを続けることでソフトウェアエンジニアは楽になれるのか？　それとも末端の技術者に問題意識を持てという方がおかしいのか？

それはそのソフトウェア資産の価値と寿命で判断する。価値が高く、寿命が長いソフトウェア再利用資産は技術を駆使し、勇気を持って再構築する。顧客に対する価値がそれほど高くなく寿命が短いソフトウェアは無理して再利用資産にする必要はない。資産化するコストに見合わないことが多い。

価値は高いが寿命が短い、価値はそれほどではないが寿命が長い場合はよく考える。価値は表に出やすい顕在的価値だけでなく、バグがあるとユーザーに多大な不利益が降りかかるような潜在的な価値（当たり前品質）もあるので注意が必要。

ソフトウェア再利用資産を構築しメインテナンスするには技術だけでなく勇気もいる。特にボトムアップで再利用資産を構築するときは自己犠牲を払う覚悟もいる。だから、コピペしてお茶を濁してしまう技術者があちらこちらに出てきてしまう。

日本でソフトウェアの体系的な再利用戦略を実践するには、「開発効率と品質向上の向上」についての現場からの必要性の叫びと、組織的トップダウンの取り組みの両方がかみ合わないと難しい。どちらかだけでもダメだ。一度構築したソフトウェア再利用資産を使い続けるには組織的マネージメントも必要だ。統制が取れていないプロジェクト、組織ではせっかく作成したソフトウェア再利用資産が使われなくなってしまう。実質的にはソフトウェア資産の可視化と、その資産がどれくらい価値があるのかの周知ができなければ、見えにくいソフトウェア資産はすぐに埋もれてしまう。

価値を見えるようにするということがいかに大事かということである。