ソフトウェアプロダクトラインが組込み企業の技術力を左右する
チケット駆動開発でアジャイル開発を運用すると必ず並行開発が現れる。
並行開発、ソフトウェアプロダクトラインの関係について連想した事をメモ。
【元ネタ】
ソフトウェアプロダクトラインを考えるセミナーに参加 - 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の世界的権威の一人であるらしい。
最近の韓国の組込み企業が日本を押しのけて強いのは、この点も関係するのかもしれない。
逆に最近の日本の組込み企業が弱くなっているのは、製品系列とソフトウェアのプラットフォームの関係を整理できていないため、常に一から作りこむしかなく、時間もかかり品質も良くない点にあるのでないだろうか?
| 固定リンク
「モデリング」カテゴリの記事
- 組込みソフトウェア開発でUMLを使う手法を説明した書籍のリンク(2022.06.17)
- 超高速開発でアジャイル開発を実現する話に違和感がある(2022.05.06)
- 事業活動のシステム化は非差別化しない汎用ドメインや支援ドメインに注力すべき(2022.04.13)
- 「大国政治の悲劇」の感想~現代はパワーポリティクスの歴史に戻ったみたいだ(2022.03.25)
- マイクロサービスはアトミックな操作で閉じるべきシステム分割論に基づいたアーキテクチャなのか(2022.03.20)
「ビジネス・歴史・経営・法律」カテゴリの記事
- 戦前の日本人の気質はまだ成熟していない青年期と同じだった(2022.06.14)
- 「大人の学びパターン・ランゲージ」の感想~知識と経験を行ったり来たりするタイミングを大切にする(2022.06.05)
- 経済学や心理学の実験で得られた理論は再現性があるのか?~内的妥当性と外的妥当性の問題点がある(2022.06.04)
- 中国人の価値観の考え方(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
「ソフトウェア工学」カテゴリの記事
- メトリクス分析のコツは良いIssueを見つけること(2022.06.29)
- プロセス設計はどの範囲を指すのか?~プロマネの仕事はテーラリングにある(2022.06.19)
- 「大人の学びパターン・ランゲージ」の感想~知識と経験を行ったり来たりするタイミングを大切にする(2022.06.05)
- 「コーディングを支える技術」は良い本だ(2022.05.26)
- ソフトウェアテスト技法練習帳はテストケースの切り方に困っている人向けにおすすめの本だ(2022.05.14)
「チケット駆動開発」カテゴリの記事
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
- タスク分割は親子チケットにすべきか、それともチェックリストにすべきか #redmine(2022.03.04)
- Redmineにメンション機能が入るらしい(2022.01.15)
コメント