ラベル プロダクトライン の投稿を表示しています。 すべての投稿を表示
ラベル プロダクトライン の投稿を表示しています。 すべての投稿を表示

2010年11月15日月曜日

Apple 戦略論

Jobs 率いる Apple の経営戦略が優れていることは多くの方が認めるところです.一方で Apple に比べると日本メーカー各社はうまくいっていないように見えます.このことから, Jobs の経営戦略,とくに Apple を追い出され NeXT を設立してからの戦略の本質が何なのか?について私は多大な関心を寄せています.


私が考える Apple の経営戦略の本質はがコア資産か」についての長期ロードマップを考案し,それを徹底して実践したことだと思います.プロダクトラインにおいてコア資産は,ムーアの言うキャズム(early adopter に売れてから early majority にも受け入れられるまでに存在する大きな「溝」)を超える橋頭堡としての役割も担うと私は考えます.私の仮説は,Jobs は最初に手を付けるべきコア資産(橋頭堡)として OS を選択したのではないか?ということです.


まず1985年の NeXT 設立時に Jobs はニッチ市場として高等教育向けハイエンドワークステーションを選びます.おそらく当時は競合も少なく,ニッチとしてもある程度の魅力があったのでしょう.


1985年前後は PC 向けに MS-DOS が主流の時代でした.日本で組込みシステム用の OS として現在も普及している ITRON の最初のバージョン ITRON1 の仕様策定開始が1984年のことです.またゲーム機の状況はファミリーコンピューターの発売が1983年です.

当時の状況では,計算機資源的に NeXT が狙うハイエンドワークステーションと組込み OS が同じアーキテクチャであることはあり得ません.しかし,ムーアの法則が提唱されたのは 1965 年のことなので,思考実験としてはハイエンドワークステーションのスペックが,いずれは家電にも導入される時代が来ることが机上では予見可能です.実際,プレイステーションの発売が1994年のことで,スペック的には NeXT と同等(あるいはそれ以上)と考えられるので,だいたい10年くらいで NeXT が家電化する時代がやってきたことになります.

この時点で Jobs がどこまで長期ロードマップを考えていたのかは明らかではありませんが,既に Jobs の想像力が家電まで及んでいた可能性はあります.世間に広まっている伝説では,少なくとも Apple に復帰して NeXT を買収する1996年頃までには,iPod に代表されるデジタル家電への進出を視野に入れていたと言われます.さらには NeXT STEP を Mac OS X として取り込む際に,将来 Mac OS X を Mac だけではなく家電の OS として使うことも想定していたとも言われています.これらについては真実を検証することはまず不可能です.しかし,もし今,自分たちのポジションで Jobs のように先を予見するとしたら,何をコア資産とするか?を考察する上で参考になるかもしれません.

このように Jobs は OS を橋頭堡として選んだのですが,Jobs の先見性はむしろ OS の上に載せるアプリケーションやサービスのレイヤーにあります.Jobs のデジタル家電構想により,未来を先取りした生活の中に息づくマルチメディア家電が iPod を皮切りに次々と創造されていきます.これらは OS のレイヤーだけを見ているのでは,けっして生み出せないしろものです.OS のあるべき姿を,OS 以外のレイヤーの将来像を考察することにより創造したのです.

もし日本メーカーの中で Apple に対抗するとしたら,よく名前が挙がるのは Sony でしょう.Sony には Jobs 率いる Apple を封じ込める可能性はなかったのでしょうか?

私はあり得たと考えます.鍵となるのはプレイステーションです.

プレイステーションの登場は1994年のことでした.私は当時の興奮を今でも覚えています.ちょっと前のスーパーコンピューターと同じスペックが,ゲーム機に惜しみなく投入されているのですから.プレイステーションが繰り出す映像や音響は,それまでのスーパーファミコンとは別次元のものでした.これは革命的といって過言ではありません.

しかしその後プレイステーションが進化するにつれて,初期の衝撃はどんどん薄れていくように感じられました.私が感じたのは,プレイステーションシリーズがもたらす新しいゲーム,新しい生活が,それほど革命的なものではない,今までの延長線上にすぎない,想像が容易につくものだということです.

今にして思えば,プレイステーション3で打ち出した Cell を中心とする情報家電への展開の構想は,もっと前にプレイステーション2の時代に行うか,あるいはプレイステーションポータブルを中心に据えるべきでした.そして Cell プロセッサそのものへの投資よりは,ソフトウェアとくに OS や基本アプリケーションへの投資を中心にするべきでした.おそらくプレイステーションでの成功体験が強すぎて,それまでの延長線上でしか思考していなかったのでしょう.だから,プレイステーション3がもたらした新しい生活は,革命的でない,今までの延長線上のものだったのです.

Cell に関して言えば,ゲーム機からの要求・制約と,家電からの要求・制約の両方を満たそうとするあまり,どちらにも中途半端なものになったのではないでしょうか.そのため,ゲーム機は任天堂の Wii にかなわず,家電は Apple にかなわずという結果でした.

任天堂も Apple も共通項として,ハードウェアスペックでは勝負せず,それぞれのサービスがどうあるべきか?を真剣に追求して勝利をつかんだのは,私にとって大変興味深いことです.少なくとも今の時代は,サービスとか価値とかを真正面から捉えないと勝利はおぼつかないのかもしれません.



(社)トロン協会 ITRON専門委員会, Introduction to the ITRON Project - Open Real-Time Operating System Standards for Embedded Systems -. http://www.ertl.jp/ITRON/panph98/panph98-j.html#SEC4





2010年2月18日木曜日

製品指向とフィーチャー指向の可変性実現(3)

前々回前回で製品指向とフィーチャー指向がどういうものかを説明しました.おさらいです.

  • 製品指向で可変性を記述した場合,製品に対応したコードを生成するときには製品名のマクロを定義すればいいので楽ですが,そのかわり製品を追加するたびにプログラムコードを改変する必要があります.
  • フィーチャー指向で可変性を記述した場合,プログラムコードの変更は製品指向と比べて少なくてすみますが,ビルドするときにフィーチャーを細かく指定する必要があります.
両方のいいとこ取りはできないのでしょうか? 実はできます.フィーチャー指向で可変性を記述し,ビルドファイルで製品指向からフィーチャー指向への変換をすればいいのです.

たとえば次のような製品マップだったとしましょう.


製品 A をビルドするときにはフィーチャーX,Z を,製品 B をビルドするときにはフィーチャーX,Yを指定する必要があります.この対応関係をビルドファイル中に記述します.たとえば,PRODUCT_A が定義されていたときには FEATURE_X, FEATURE_Z を定義するように書くわけです.このような情報をコンフィギュレーションといいます.

このとき製品指向とフィーチャー指向は上の図のようなレイヤー構造(階層構造)にあります.まず可変性を具体的に記述するのはフィーチャー指向で行います(下の層).その可変性記述のメカニズムを利用して製品指向の可変性記述をコンフィギュレーションとして記述します(上の層).上の層が下の層の機能を使って実現されているとき,その構造をレイヤー構造といいます.

以上をまとめると,次のような表になります.


僕は,おそらくこの発見(製品指向の利点はフィーチャー指向でも実現できる)が,フィーチャー中心のプロダクトライン開発の原点ではなかったかと思っています.裏をとりたいので,何か情報をお持ちの方はお知らせください.


つづく

製品指向とフィーチャー指向の可変性実現(2)

前回は製品指向について説明しました.今回はフィーチャー指向について説明します.

フィーチャー指向は,フィーチャー(≒機能)に対応して可変性を記述する流儀です.もうみなさんだいたい想像がつくと思いますが,次のようなコードを書きます.


#ifdef FEATURE_X 
/* フィーチャー X 向けのプログラムコード */
#endif 

 このような書き方の場合,プログラムコードの変更は製品指向と比べて少なくてすみます.もちろん新たなフィーチャーを追加したときには変更が必要ですが,単にフィーチャーの組み合わせを変えただけの新製品を作成するときには.プログラムコードを変更しなくてもできます.

逆に欠点としては,ビルドするときにフィーチャーを細かく指定する必要があります.製品指向だと製品 A のビルドをするときにマクロ PRODUCT_A を定義してビルドすれば良かったのに対し,フィーチャー指向では製品 A が採用する全ての可変フィーチャーを指定する必要があります.これは可変フィーチャーの数が多いと,面倒ですし,間違いの元です.

しかしこの欠点は,少し改良すると解消することができます.次回はその話をしましょう.

つづく

2010年2月13日土曜日

製品指向とフィーチャー指向の可変性実現(1)

前回の最後にプロダクトラインにおける戦略について触れましたが,それを論じる前に,プログラムコードなどの開発成果物で可変性を実現する2つの流儀,製品指向フィーチャー指向を紹介します.


なお,この製品指向,フィーチャー指向という分類の呼び方は,僕独自の見解であって,文献などで裏をとっていません.類似のことを主張している文献は,いかにもありそうなので,もしご存じならコメントいただくと助かります.

可変性を実現するにはさまざまな方法があります.数々の技法を紹介するのは,また別の機会ということで,最も基本的な C 言語のマクロ(#ifdef)を使った方法を見てみましょう.


よくある定義のしかたは,開発する製品に対応して可変性を記述する方法です.この流儀を製品指向と呼びましょう.

#ifdef PRODUCT_A 
 /* 製品 A 向けのプログラムコード */
#endif /* PRODUCT_A*/
なお,「製品 A 向けのプログラムコード」とコメントされている部分には,実際には製品 A だけに実装するプログラムコードを記述します.

C 言語のコンパイラーは,#ifdef の直後に指定されているマクロが定義されているときに #ifdef から #endif までのコードを含めてコンパイルし,そうでないときには含めずにコンパイルします.したがって,製品 A をビルドするときには,コンパイルスイッチでマクロ PRODUCT_A を定義します.そうすると製品 A 向けのプログラムコードを含むソフトウェアが生成されます.

この方法の問題点は,製品の数を増やすときに,プログラムコードを改変する必要があることです.たとえば新たな製品 B を作るとします.そのとき上記の製品 A 向けのプログラムコードを製品 B にも使うとしましょう.この場合,次のようにプログラムコードを改変する必要があります.
#if defined(PRODUCT_A) \  
  || defined(PRODUCT_B) 
 /* 製品 A・B 向けのプログラムコード */
#endif /* PRODUCT_A, PRODUCT_B*/
#if defined(PRODUCT_A) は  #ifdef PRODUCT_A と同じ意味です.ただし, defined を使うと複数の条件を扱うことができます.また,バックスラッシュ(\) は改行があってもマクロが続くという意味で,縦棒ふたつ(||)は「または」という意味です.したがって,この例では,PRODUCT_A または PRODUCT_B が定義されていた場合に #if から #endif までのプログラムコードを含めるという意味になります.

まとめると,製品指向で可変性を記述した場合,製品に対応したコードを生成するときには製品名のマクロを定義すればいいので楽ですが,そのかわり製品を追加するたびにプログラムコードを改変する必要があります.



追記: あとで明かしますが,製品指向は可変性の表現としては悪い例です.このようなコードをあとで説明するフィーチャー指向に改めていく必要があります.

つづく

2010年2月2日火曜日

J-SPLEリストで Follow us!

SPLE を推進する技術者・研究者の Twitter リストを作りました.
J-SPLE リストはこちら


注意点としては,Twitter のシステムの都合上,僕がリストに入っていないという問題があります.ご面倒だとは思いますが,僕も合わせてフォローいただきますよう,よろしくお願いします.


2010年1月31日日曜日

講演: 「組込みソフトウェア技術動向セミナー」@岐阜県大垣市

来る2月19日(金)にセミナーで講演します.

場所は岐阜県大垣市です.講演タイトルは「戦略的再利用『プロダクトライン』〜その本質とは何か」です.

http://it-mono.jp/news/20100219.html

先日の名古屋での講演からさらにパワーアップする予定です.よろしく!

2010年1月30日土曜日

共通性と可変性,スコーピング

プロダクトラインはソフトウェア工学の集大成と位置づけられています.既存の技術をある観点で統合しています.そのため,プロダクトラインに特有の技術は実のところあまり多くありません.

今回説明する共通性(commonality)と可変性(variability)は,プロダクトラインを統合する観点であり,共通性・可変性分析と呼ばれる技術は,数少ないプロダクトライン特有の技術です.

前回のチュートリアルで,プロダクトラインの目的は大量個別生産であり,それを実現するために共通部分をプラットフォームにするという話をしました.したがって何が共通で何が変化しうるかを見極めることが,プロダクトラインの成功のために重要な鍵の一つとなるのは,自然のことでしょう.

たとえば Apple の iPod シリーズを考えてみましょう.iPod には iPod classic, iPod shuffle, iPod nano, iPod touch といった製品群があります.さらに iPhone や iPad も仲間に入るでしょう.

よくカタログ等で,次の表のように機能と製品の対応関係を表すことが一般的だと思います.


この表を製品マップ(product map)といいます.この製品マップでは,横に製品,縦に機能が並んでいます(縦横逆に書いてもかまいません).

プロダクトラインの世界では,機能という言葉ではなく,フィーチャー(feature)という言葉を用います.フィーチャーは「ソフトウェアシステム(群)の顕著または特有のユーザに見える観点,品質,または特性」で,おおむね機能だけでなく品質要求も含んだ概念だと思ってください.iPod の品質要求の例としては,音楽再生時間などが挙げられます.

このように製品とフィーチャーの観点から見たとき,あるフィーチャーが (1) 全ての製品に備わっている,もしくは同一の値を持っている場合(たとえばオーディオ)と,(2) 1つまたは一部の製品に備わっている,もしくは製品によって値が異なる場合(たとえばディスプレイ)があることがわかります.前者の場合そのフィーチャーは全製品で共通であり,後者の場合は可変であるといいます.フィーチャーが共通であるか可変であるかを識別することを共通性・可変性分析といいます.

共通性と可変性を表現する方法は製品マップだけではありません.最もメジャーなのはフィーチャーモデルでしょう.他にもさまざまなモデルが存在します.総称としては可変性モデルです.

プロダクトラインを作る際に,どのような製品を提供し,それぞれの製品でどのような機能を提供するかを決めることは非常に重要です.このようにプロダクトラインがカバーする範囲を決めることをスコーピング(scoping)といいます.スコーピングにはいくつか種類があり,ここで取り上げたのは製品ポートフォリオスコーピング(product portfolio scoping)といいます.

よくプロダクトラインは戦略的再利用だといわれることが多いのですが,スコーピングはまさにこの戦略の中核にあたります.スコーピングの成否がプロダクトラインの命運を分ける要因の一つになります.この重要性ゆえに,僕はこのあたりの研究に取り組むことにしたわけです.

だんだん本題に近くなってきました.また次回,お楽しみに.

つづく

参考文献
"Feature-Oriented Domain Analysis (FODA) Feasibility Study," 
Kyo C. Kang, Sholom G. Cohen, James A. Hess, William E. Novak, A. Spencer Peterson
Technical Report CMU/SEI-90-TR-21 ESD-90-TR-222, November 1990 

http://selab.postech.ac.kr/
150ページ以上にわたる超大作の論文です.第1著者の Kang 先生はプロダクトラインの世界の重鎮の1人ですが,その地位を確立したのがこの論文です.


iPod, iPhone, iPad およびその派生製品は Apple の登録商標です.

2010年1月19日火曜日

プロダクトラインとは(1)

このブログはじめての記事として,ブログの説明や最初のあいさつにも書いている「プロダクトライン」とは何かを説明しましょう.

ソフトウェアの生産性を向上させたいと経営者も開発現場も思っているでしょう.それに対し,ソフトウェア開発の実態は1つ1つ手作りに近いという現状があります.なんとかしてソフトウェア開発を現代の発達した工業のように効率化できないだろうか,工業化の歴史から学ぶことはないだろうか.それがプロダクトラインという考え方が生まれたきっかけです.

Henry Ford 登場以前の工業は1つ1つ手作りでした.手作りだと顧客1人1人に合わせて仕立てることが可能ですが,生産性が低いため,単価を高くしないと元が取れません.ついでにいうと属人性が高いという問題もあります.つまり,品質や工数が生産者の技術レベルに強く依存する,勘と経験の世界で,技術の継承が難しいという状態です.これは現在のソフトウェア開発では1品ものの受託開発に相当します.

20世紀初頭に Henry Ford が登場し,大量生産(mass production)を発明しました.これは同一仕様の製品を大量に生産することで,細かい個別の顧客ニーズを無視するかわりに高い生産性を実現するというものです.大量に生産するほど固定費を広く薄く回収することができるので,単価を安く設定できるのが大きな武器でした.また,属人性を低くできるというメリットもあります.つまり,作業を高度に標準化できるので,1人1人の技術者は1つの作業に専門化でき,生産者の入れ替えが容易になります.これはパッケージソフトウェアに近い状態だと考える事ができます.

しかし,生活レベルの向上とともに消費者の基本的欲求が満たされるようになり,ニーズや価値観の多様化が起こりました.それにより魅力的な特徴(フィーチャー: feature)がないと売れない事態になります.こうなると大量生産では対応できません.

そこで次に登場したのが大量個別生産(mass customization)です.これは個々の顧客に適合させた物品を大規模に生産することです.つまり,個別の顧客ニーズに応える一方で,生産性は高くといういいとこ取りを狙うものです.ついでに属人性が低いとうれしいところです.

以上をまとめると次の図のようになります.


ところがここにジレンマがあります.大規模に生産するからにはエンドユーザーがたくさん存在します.一方でエンドユーザーそれぞれには個別の要求があります.かといって,たくさんのエンドユーザーの要求に1つ1つ個別対応していると生産性が悪くなります.したがって大量個別生産の実現のためにはブレークスルーが必要です.

着眼点は共通性です.エンドユーザーの要求には共通性があります.そこで,共通部分をプラットフォーム(platform)として再利用できるようにし,異なる部分をプラットフォームに結合する部品として実現すれば,個別対応能力と生産性を両立できます.これをソフトウェアで実現するのがプロダクトラインです.

ソフトウェアの世界でプロダクトライン(product line)と言った場合,厳密に言うと Software Product Line (ソフトウェア製品系列) または Software Product Line Engineering (ソフトウェア製品系列開発)の2つの意味合いがあり,よく混同されます.

Klaus Pohl, Günter Böckle, Frank van der Linden による Software Product Line Engineering (ソフトウェア製品系列開発)の定義は次の通りです.前述の説明から容易に理解できる定義ですね.
  • 大量個別生産を実現するために
  • プラットフォームを用いて
  • ソフトウェアアプリケーションを
    • ソフトウェア集約システム(≒組込みシステム)
    • ソフトウェア製品
  • 開発するパラダイム
これに対し,Paul Clements と Linda Northrop による Software Product Line (ソフトウェア製品系列)の定義は次の通りです.
  • ソフトウェア製品系列とは次のようなソフトウェア集約システム群である
    • 特定のマーケットセグメントやミッションのニーズを満たす,共通の管理されたフィーチャー群を共有する
    • あらかじめ決められた方法でコア資産から開発する
これはちょっと難しい定義ですね.この定義については,また後日説明したいと思いますが,マーケットセグメントというキーワードが実は僕の研究テーマにつながっていくとだけ予告しておきましょう.

参考文献


Pohl Clements & Linda Northrop Software Product Lines: Practices and Patterns