ソフトウェアプロダクトラインが組込み企業の技術力を左右する
チケット駆動開発でアジャイル開発を運用すると必ず並行開発が現れる。
並行開発、ソフトウェアプロダクトラインの関係について連想した事をメモ。
【元ネタ】
ソフトウェアプロダクトラインを考えるセミナーに参加 - Basic
CACM の特集記事:ソフトウェアプロダクトライン工学(1) - IT、アイスホッケーそしてヒップホップのある日常
【1】Redmineでチケット駆動開発をアジャイル開発っぽく運用すると、必ず2個のコードラインを保守するようになり、自然に並行開発になる。
つまり、リリースした本番システムはリリースブランチ、裏で機能改善中のシステムはtrunkの2本を常時保守しなくてはならない。
特にアジャイル開発を実践すると、2~4週間のサイクルで小刻みにリリースしていく為、リリースしたコードラインと次のイテレーションのコードラインの2本を並行で作業しなくてはならない。
だから、イテレーション期間中に、リリースしたソースの障害修正と開発中のソースの機能追加の2つを常に同時並行せざるを得なくなる。
アジャイル開発の運用が難しい理由の一つが、この認識漏れにあると思う。
並行開発の難点は、2つのコードラインのタスク管理やマージ作業が大変な点にある。
チケット駆動開発では、それぞれのコードラインのタスクをチケットで別々に管理してリンクさせる事で、複雑な構成管理の作業漏れをなくすようにできる利点がある。
更に、MercruialやGitのような分散バージョン管理を使えば、マージ作業そのものをpull/pushで自動化できるため、手作業による漏れや失敗を無くせる。
従って、並行開発を成功させるには、チケット駆動開発と言う変更に強いタスク管理のインフラと、複雑な構成管理を楽にしてくれる分散バージョン管理が必須だと思う。
【2】この並行開発の考えをビジネスモデルへ更に発展させるとソフトウェアプロダクトライン(ソフトウェア製品系列:SPL)の概念へ行き着く。
SPLでは、コア資産をベースに次々に亜種となる製品を作り出していくのが特徴であり、利点でもある。
しかし、SPLはSW工学の範疇ではあるが、実際はビジネスモデルに密接に関係するため、そう簡単に導入するのは難しい。
SPLを並行開発の観点で見ると、コア資産というコードラインから次々にアプリケーション資産というブランチを分岐ないし派生させていく事になる。
派生開発の観点で見ると、一つの製品を常時保守しながら、コア資産をベースに、携帯にお財布ケータイやデジカメ機能を追加するなどの改良保守も含まれる。
【3】SPLの具体例はパッケージ製品や組込み製品があげられる。
例えば、MSのOffice製品、AppleのiPod/iPhone/iPadが成功例としてあげられるだろう。
Officeには、Personal/Professionalなどの製品ファミリーがあるし、AppleはMacOSXという優れたUnixOSを元に各モバイル製品のコアOSを作り出し、次々に売り出している。
他にノキアなど、北欧の企業にもSPLに強い会社が多い。
SPLに強いということは、コア資産であるOSなどのプラットフォームを自社で持っており、そのプラットフォームの品質やブランドが大きいことでもある。
だから、MSやAppleのように、自社で優れたOSを持っていると、SPLの利点を生かしやすい。
又、パッケージ製品やASPのように自社の製品やサービスを販売しているソフトウェア企業は、SPLを運用できれば、違う顧客にスピーディに亜種となる製品やサービスを提供できるようになる。
【4】SPLのもうひとつの特徴は、アーキテクチャを重視している点だ。
コア資産を抽出するためにアーキテクチャと言う観点を入れて、アーキテクチャも含めた機能を再利用できるようにする。
「実践ソフトウェアアーキテクチャ」では、北欧の軍需企業が、空母のシステムから防空システムをプロダクトライン開発した例が載っている。
この例は、SPLを持つ組織はアーキテクチャを習得しているおかげで、新製品ファミリーを派生させて作れる仕組みを持っていることを示唆している。
アーキテクチャを重視すると、最終的にはSPLにたどりつく気がする。
アーキテクチャは製品ファミリーやビジネスモデルと密接に関係するのだ。
【5】ここでもう一つ注意すべき点は、韓国がSPLに熱心である点。
韓国の姜教哲という大学の先生がSPLの世界的権威の一人であるらしい。
最近の韓国の組込み企業が日本を押しのけて強いのは、この点も関係するのかもしれない。
逆に最近の日本の組込み企業が弱くなっているのは、製品系列とソフトウェアのプラットフォームの関係を整理できていないため、常に一から作りこむしかなく、時間もかかり品質も良くない点にあるのでないだろうか?
| 固定リンク
「モデリング」カテゴリの記事
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システム開発・刷新のためのデータモデル大全」を読み直した感想~親子頻出アンチパターンは初心者モデラーに多い(2024.08.31)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
「ビジネス・歴史・経営・法律」カテゴリの記事
- ビジネス書の名著はどれ?(2023.09.18)
- 営業は顧客の”購買代理人”である(2023.08.16)
- 第85回IT勉強宴会の感想~概念データモデルからビジネスモデルを構築すべきという考え方(2023.05.13)
- 令和4年度春期試験のITストラテジスト試験第4問をastahでモデル化してみた(2023.04.15)
- ChatGPTで起きている事象の意味は何なのか(2023.04.02)
「ソフトウェア工学」カテゴリの記事
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
- マイクロサービス設計は従来のアーキテクチャ設計と何が違うのか(2024.01.02)
「チケット駆動開発」カテゴリの記事
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
コメント