SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

組込み開発の「銀の弾丸」

プロセスライン


  • X ポスト
  • このエントリーをはてなブックマークに追加

プロセスライン

 プロセスラインというキーワードでWEBを検索したところ、いくつかが表示された。この中に国立情報研究所の鷲崎さんの名前を見つけ、話を伺いに行った。すべてを調査した結果の正確な情報ではないが、プロセスラインの基となるプロセスのテーラリングに関する研究は1990年代半ばには行われており、プロセスラインという用語を使うようになったのは2005年くらいからだという。日本語になった情報は、京都高度技術研究所の松本先生がソフトウェアファクトリーの中で言及しているものや、鷲崎さんが組込みソフトウェアシンポジウム2005で発表したものなど数件程度しかない。

プロセスラインの実装

 プロセスラインはプロダクトライン同様に特定の技術を指し示すのではなく、あくまでも考え方、パラダイムであり、その実装は複数存在するものだろう。以下に、まだ柔らかい段階ではあるが、私のアイデアを示そう。

 基本は、プロダクトラインと同様に、プロセスフレームワークに開発に適したプロセスコンポーネントを組み込むことによって開発に最適なプロセスを定義するというものである。ここでは、まずにプロセスコア資産を使ってプロセスを定義する話、次に、プロセスコア資産を開発する話をしよう。

プロセスの定義

 プロセスフレームワークとプロセスコンポーネントを定義する前にしなければいけないことがある。それは開発の特性を分析し、明らかにすることだ。ソフトウェア開発では、一言で「ドメイン」と表現するが、異なるドメインにも共通するものは多々ある。ドメインとは、特性を組み合わせたものに過ぎない。複雑な問題を解決する場合の王道は、単純な問題に分解することだ。複雑なままだと解は見つけにくいが、単純な問題だと容易に解は得られるものである。この単純な問題の解を組み立てることによって、目的の複雑な問題を解決することができる。これは「関心事の分離」(SoC)*3と呼ばれる技法である。また、逆の見方をすれば、標準部品と標準部品を組み合わせると、標準度が低下することがわかるだろう。

*3 SoCというと、組込み技術者はSystem on Chipと混同するが、Separation of Concernsの略である。

 今のところ組込み開発における開発特性は、プロダクト特性、プロセス特性、組織特性の三種類くらいを考えている。プロダクト特性は、携帯電話や自動車のエンジンなどのプロダクトに共通するリアルタイム性や標準的なフットプリントなどである。プロセス特性は、開発人員、開発期間・周期、体制、役割、そしてビジネスなどが含まれるだろう。組込みシステムやソフトウェアの開発を請け負う組織は、同じプロダクトであっても、顧客や地域によって作り方を変えることが多い。最後の組織特性は、組織的な文化や企業トップ、プロジェクトマネージャなどの考え方、戦略などがあげられる。これら特性ごとに「軸」を定義し、それに値を設定することによって、その開発固有の「カルテ」ができる。このカルテをもとにプロセスやプロダクト、そしてツールなどを整備すれば良いのである。

 この後は、カルテをもとに、プロセスコア資産からプロセスフレームワークとプロセスコンポーネントを選定し、組み合わせればカルテ通りの開発に最適なプロセスを手に入れることができるはずである。

プロセスコア資産開発

 プロセスフレームワークは、ソフトウェアプロダクトラインのプラクティスパターンを基に定義するが、必要に応じて、複数定義することになる。次に、プロセスコンポーネントをplug-inするプロセスフレームワークのスロット、つまりプロセスコンポーネントの標準仕様をソフトウェアプロダクトラインの各プラクティスを参考に定義する。

 プロセスコンポーネントは、プロセスフレームワークで定義されたプロセスコンポーネント標準仕様をもとに、関係する特性に合わせて詳細に定義すれば良い。

最後に

 プロセスラインを適用すれば多種多様な組込み開発において最適な組織技を比較的容易に導入することができる。まさに開発現場が欲する「答え」、「銀の弾丸」である。
 しかし、プロセスコア資産の開発は、特定の開発組織で行うものではなく、大学や学界、国の組織などで行うべきものであろう。今後の組織横断的な取り組みに期待したい。

参考文献
  • Paul Clements, Linda Northrop著, 前田卓雄訳,『ソフトウェアプロダクトライン』,日刊工業新聞社
  • D. Rombach, “Integrated Software Process and Product Lines,”  Post-Proceedings of the Software Process Workshop, LNCS Vol.3840, 2005.
  • P. Mi, M.J. Lee and W. Scacchi, “A Knowledge-based Software Process Library for Process-Driven Software Development,” Proceedings of the 7th Annual Knowledge-Based Software Engineering Conference, 1992.
  • Jack Greenfield, Keith Short with Steve Cook, Stuart Kent著, 野村一行監訳,マイクロソフト株式会社監修,『ソフトウェアファクトリー』, 日経BPソフトプレス
  • Y. Matsumoto, “Japanese Software Factory,” in Encyclopedia of Software Engineering, (ed.) J.J. Marciniak, John Wiley & Sons, 1994.
  • Hironori Washizaki, "Deriving Project-Specific Processes from Process Line Architecture with Commonality and Variability", Proc. 4th International IEEE Conference on Industrial Informatics (INDIN'06), August 2006.
  • O. Jaufman and J. Munch, “Acquisition of a Project-Specific Process,”  Proceedings of the 6th International Conference on Product Focused Software Process Improvement, LNCS Vol.3547, 2005.
  • Alexis Ocampo, Jurgen Munch, and Fabio Bella: Software Process Commonality Analysis, Softw. Process Improve. Pract. 2005.

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
この記事の著者

佐藤 啓太(サトウ ケイタ)

組込み業界に身を置いて、四半世紀が過ぎた。組込みの開発や組込み・ITのコンサル、オブジェクト指向の教育やデザインパターンなどの研究などを経て転職を重ね、現在7社目となる某社の組込み関係の研究者が表の顔である。一方で、特定領域や企業のための活動よりも、多くの領域や企業に価値ある活動を志向し、企業や大学など組織を超えたコミュニケーションの場がないことに問題を感じ、業界の裏方と...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/3705 2009/03/17 12:51

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング