ITでビジネスを行ってる会社は日本では、顧客から依頼を受けてシステム構築を行う(もしくは人を派遣する)というのが多いと思います。以前に本ブログで取り上げたSoR/SoEに当てはめるとSoRであれば、一度作って安定稼働すればよいのですが、ビジネスとシステムの結び付きが強くなってきていてSoEの性質をもつシステムが増えてる中、最初に作ったものをそのまま使い続けるのは難しいわけです。
https://toaruit.hatenablog.com/entry/2016/07/30/125927
で、もちろん構築を請け負ったベンダーにとっても、SoEのシステムで継続的に案件をもらえる機会はあるものの、ノウハウが属人化して会社としての資産が作れない、といった悩みがあるかもしれません。
そのようなケースでは、改善型開発の考えが使える余地があるのではと感じます。改善型開発は何か一般的に定義されているものではなく、下記のブログ記事で紹介されてるものとなります。改善型開発では最初に自社の資産となるソースコードをベースにシステム導入して、そこから顧客の要望を取り込んで開発していくというスタイルとなります。
【改善型開発 〜 システムを作るのではなく育てるという発想】
https://kuranuki.hatenadiary.org/entry/20060228/p1
この考えを実際の開発に活かしていく手法として、SPL(ソフトウェアプロダクトライン)が挙げられます。SPLではまず自分達がベースとするコアのソースを用意します。コア資産をバージョン管理しバージョンアップ時には、各システム固有の機能に変更がなくても、更新する形になります。
【プロダクトライン開発】
https://www.exmotion.co.jp/solution/spl-solution.html
位置付けとしては、スクラッチ開発でもなくパッケージでもなく、コア資産をフレームワーク化するというイメージが近いのかなと感じました。ただ、一般的なフレームワークと異なるのは、コア資産をベースに開発したシステムについても保守をしていくという点になるかと感じます。
顧客のシステムでSPLを実現するのは、ハードルが高いかもしれません。それは顧客のシステムをベンダー側で保守管理するという、開発と保守をセットで契約しないと実現困難であり、ソースコードの管理主体どうするんだという問題もあるからです。
なので、ベンダー側はこういったSPL管理をする方法を顧客側にレクチャーして、顧客側で管理していくというやり方が現実解かもしれません(もちろん、顧客側にスキルの高い人材がいることが前提になってしまいますが)。現状SPLを管理するツールもあったりしますので作って終わらすのではなく、いかに複数のシステムを管理していくか、という観点で顧客とベンダーで協議してみてもよいかなと感じます。
【ソフトウェア プロダクトライン(SPL)への適用】
https://www.techmatrix.co.jp/product/accurev/impre_sample/spl.html
