派生開発とは
Q：ソフトウェアエンジニアリングの世界には、もともと「保守」あるいは「保守開発」というプロセスがありますが、「派生開発」はこれとどう違うのですか？
Q：組み込みシステムの世界では昔から「保守」とか「保守開発」という概念はありません。私の所属する組織でも「派生開発」と呼んでいますが、「XDDP」で呼んでいる「派生開発」とは違うのでしょうか？
XDDPとは
Q：「XDDP」というのは、派生開発全般に対する呼び名でしょうか？
派生開発推進協議会(AFFORDD)について
Q：正会員になってXDDPやUSDMなどの活用方法の研究に参加したいのですが、地理的に遠くて会合に出席できません。このような状況でも研究会に参加できますか？
Q：ソフトウェアエンジニアリングの世界には、もともと「保守」あるいは「保守開発」というプロセスがありますが、「派生開発」はこれとどう違うのですか？
A： おっしゃるように、もともとは要求仕様作成―基本設計―詳細設計―テスト―運用―保守というライフサイクルの最後に「保守」あるいは「保守開発」というステージがあります。JIS X 0161にも｢保守開発」が定義されています。
「保守」というのは、元来、そこで作られたソフトウェアシステムに残っているバグに対応したり、システムを取巻く環境の変化に対して維持していくための対応を想定したものです。企業の中で使用するシステムなどのビジネス系のソフトウェアでは、このような対応で維持できることが多いと思われますが、組み込みシステムでは、こうしたパターンとは全く違った要求が発せられます。
たとえば、従来の製品に新しい機能を追加したり操作性を改善したりして製品の競争力を高めたりしますが、これは従来の「保守」の概念からはみ出しています。明らかに製品が変化あるいは成長しており、この作業を繰り返していく中でまったく異なった製品になることも起きてしまいます。実際、「携帯電話」が「ケータイ」に進化（変化）する過程は「保守」では説明できません。
また最近では、新規開発に対する負担を軽減する目的で、ベースのアーキテクチャだけを新規に開発し、個々の機能については一部の新機能については要求仕様書から取り掛かり、いくつかの機能はオープンソースや既存の製品で使われているソースコードを流用して作り上げるという方法も取られています。これは従来の新規開発のアプローチとは全く異なったプロセスの連鎖になります。もちろん「保守」ではありません。
そして、このような状況は組み込みシステムに限らず、パッケージソフト、さらには交通や輸送などの制御系のシステムでも起きていますし、ビジネス系のソフトウェアでも、従来の「保守」のパターンとは大きく異なるプロセスが求められることが起きています。この状況を表現するために「派生開発」と呼ぶことにしたものです。組織によっては「改造」と呼んでいることもあります。
2008年にJISの保守の定義が改訂されて「改良保守」という概念が追加されました。これはまさに従来の「保守」とは違った機能追加を扱うものです。つまり、この部分が従来の「保守」や「保守開発」には不足していたということです。
問題は、呼び方だけではありません。機能追加や機能の移植にはそれを受け入れるためにベースのソースコードの変更が必要になりますが、それを扱うプロセスが機能追加を扱うプロセスとは別に必要になることです。「XDDP」はこのような機能追加や流用の要求にこたえるために、「変更」と「追加」の２種類のプロセスを並行させるという特徴を持っています。
Q：組み込みシステムの世界では昔から「保守」とか「保守開発」という概念はありません。私の所属する組織でも「派生開発」と呼んでいますが、「XDDP」で呼んでいる「派生開発」とは違うのでしょうか？
A： 確かに組み込みシステムの世界では昔から「派生開発」と呼んでいるところも少なくありません。「保守」とか「保守開発」という言葉を耳にすることないかもしれません。
その原因として考えられるのは、そこで行われている作業が「保守」のイメージではないということの他に、「ソフトウェアエンジニアリング」の考え方が持ち込まれなかったことが考えられます。
実際、組み込みシステムの組織では、エレキやメカの設計技術を習得した技術者が、事前にソフトウェアエンジニアリングなどの知識や技術を習得する機会を持たないままソフトウェアの設計に着手したことで「保守」という概念が持ち込まれなかったと考えられます。
「XDDP」は、「保守開発」の世界で求められている要求に合理的に応えるために考案された派生開発専用の開発アプローチであり、多くの組織で行われている「派生開発」の方法とは異なります。
多くの現場で行われている「派生開発」には合理的な開発アプローチはなく、ほとんど無規律に担当者の思いのままにソースコードが変更されるためにバグが多発し、手戻り工数が増えてしまい、納期限をオーバーしてしまうのです。
これに対して「XDDP」は、派生開発の要求の特徴にマッチした合理的な成果物とプロセスの連鎖で構成され、最小限の規律の下に整然と作業を進行します。
Q：「XDDP」というのは、派生開発全般に対する呼び名でしょうか？
A： 「XDDP」というのは「派生開発」の中の一つの開発アプローチであって、「XDDP」＝「派生開発」ではありません。
派生開発には新規開発とは違った特徴があります。規模の大小や変更と追加／流用の比率の違い、変更内容の違いなどによって多様なパターンが考えられますので、将来、あるパターンには「XDDP」よりも効果的な開発アプローチが考案される可能性があります。ただし、現時点では派生開発において効果的でかつ繰り返し可能な方法としては「XDDP」以外には提案されていません。
Q：「偽装工夫」ってどういうことでしょうか？
A： 「偽装工夫」とは、プロセスを設計するという習慣を身につけていない人が行った（良かれと思って行った）「工夫」が、結果的に方法論との不整合が生じ、却って負荷と時間をかけてしまい、さらに利用したプラクティス（XDDPなど）も効果が見いだせないために「役に立たない」と批判的に捉えられてしまう現象や行為を指します。
たとえば、多くの人は「ソースコード上で該当箇所を見つけしだいに変更する」という「習慣」が体に染み込んでいます。「XDDP」はここに問題の根源があるということで、これを否定して変更要求仕様など「変更３点セット」の形で記述することを求めています。この説明に対して、頭では理解したつもりでも、体には従来の「習慣」が残っていますので作業はスムースに行きません。変更（すれば良さそうな）箇所を目の前にして「ここをさっさと変更してしまえば済むのに」「３種類も文書を書く必要があるのだろうか」といった迷いが生じてきます。こうした状況の中で、『変更要求仕様に変更方法を記述すれば「TM」や「変更設計書」を書く作業が省けるじゃないか』といったいろいろな「工夫」が行われます。
これは従来のプロセスに対して新しい成果物を作ることで増えた工数を少しでも減らそうという意図から「工夫」（これを「偽装工夫」と呼ぶ）がなされたものです。このような「偽装工夫」を防止するには、体に染み付いた習慣を変える取組みが必要です。その方法として２つ提案します。
１つは、うまく出来ている人の話を聞いたり、原典（文献）に戻って読み落としている箇所がないか探してみることです。個人の経験の差にもよりますが、一般には、１回目で文献の内容を理解できるのは、せいぜい５割前後と思われます。一度取り組んでみたところで疑問や迷いが生じた箇所というのは、理解が繋がっていない箇所であり、読み落とした箇所と考えられますので、こうした箇所を繰り返し拾いながら進めてください。
例えば、CMMで推奨されたヨードンの「ソフトウェアの構造化ウォークスルー」という本があります。この本の68ページに「少なくともひとつの肯定意見を持ち込む」という記述がありますが、多くの（日本の）人はこの部分を見落としています。そのため、ピアレビューの効果がでないのです。つまりヨードンが見えている景色を見ることができないのです。この本の中で「肯定意見」はこの１箇所にしか記述されていませんので、多くの人は重要性を感じなかったものと思われますが、従来から身につけてきた「レビュー」プロセスの習慣の中で判断してしまったのです。
２つ目は、PFDのようなプロセスを設計するツールを使って、自分がイメージしているプロセスを表現してみることです。まずは「as-is」で構いません。どのような成果物とプロセスを繋いでゴールに向かおうとしているのかを表現することで、自分が考えていることを客観的に見える状態になります。
体に染み込ませた「習慣」を自分の外に出すことで、自分自身と「会話」が可能になり「習慣」を薄める効果があります。
ただし、これも簡単なようでいて意外と書けないものです。これらの手段を組み合わせながら、「偽装工夫」が生まれる根源から変えて行くことが重要です。
なお、「偽装工夫」については「XDDP」の文献の373ページ（その周辺）を参照してください。
Q：「XDDP」でアーキテクチャは改善できない？
A： アーキテクチャの改良あるいは再構築というのは範囲が広く、人によって捉えるイメージが異なります。いわゆる「リファクタリング」と呼ばれるモジュール構造の改良や、タスク間での機能の変更などであれば「XDDP」で問題なく対応できます。むしろ「XDDP」で捉えた方がスムースに実現できるでしょう。
これに対して、本格的なアーキテクチャの再構築となると「XDDP」の対象外です。
これまでのアーキテクチャがその後の変更の中でいろいろと支障をきたしているので、新規開発によってアーキテクチャを作り替えるといのが一般的なのです。それでも、最近は全くの新規開発ということが少なくなりました。
例えばベースのタスク構造などの基本構造を新規で作り替えて、個々の機能は従来のソースコードから移植する方法が取られる可能性があります。この場合、機能の移植は「XDDP」で対応できます。
ところで、現状のアーキテクチャに問題があることは派生開発の中で多発するバグによって思い知らされているとしても、それではどのようなアーキテクチャであれば良いのか、作り替えるとすれば今度はどのようなアーキテクチャにすべきか、ということを事前に研究する時間を確保しなければなりません。
例えば、『実践ソフトウェアエンジニアリング』（ロジャー・S・プレスマン）に「データ中心アーキテクチャ」「データフロー・アーキテクチャ」「コール＆リターン・アーキテクチャ」「オブジェクト指向アーキテクチャ」「レイヤー・アーキテクチャ」の５つのアーキテクチャスタイルが紹介されています。自分たちの製品やソフトウェアシステムは、どのアーキテクチャがふさわしいのか、そしてそのようなアーキテクチャによるシステムの設計方法を習得し準備をしておかない限り、望ましいアーキテクチャを再構築することは出来ないでしょう。一般には事前にこうした準備ができていない状態で「再構築」に取り掛かるために、現状のアーキテクチャとたいして変わらないものになるのです。
なかには場違いなアーキテクチャを採用したりして、かえって混乱していることもあります。
本格的な再構築に取り掛かるには、事前にこうした準備を進めておく必要があるのですが、派生開発の厳しい条件の中で、こうした準備のために時間を余らせるという部分にも「XDDP」（や「USDM」「PFD」）の出番があるのです。
Q：プロセスって設計するものなの？
A： 一般には「プロセスを定義する」と呼ばれています。しかしながら、「定義する」には「言葉で明確に限定する」という意味があり、文章によるプロセスの記述が中心になります。その結果、文章による「プロセスの定義書」が積み上げられることになります。
ところが現実には要求は常に変化し同じ要求は２度とありません。また対応する担当者も開発の環境も同じではありません。つまり「要求を仕様化する」というプロセスも、状況によって相当に変化させる必要があるのです。いわゆる「テーラリング」が必要なのですが、文章による定義書をベースにしたのでは、そのような変化に対応できないのです。
実際、「定義書」をベースにしている現場では「テーラリング」はほとんど行われないまま、そこに定義されたプロセスが実施されていると思われます。世界ではプロセスは「DFD」で表現されています。「DFD」はもともと構造化分析の手法で提案されたもので、ソフトウェアのプロセス（この場合は処理のまとまり）を設計するためのツールです。つまり「DFD」と「データディクショナリ」と「ミニスペック」のセットをソフトウェアの開発プロセスの「設計」に活用しているのです。
本会ででは「DFD」の代わりに「PFD」を勧めています。
「PFD」は「DFD」のルールをベースにして、成果物を表す記号を導入することで「成果物」と「プロセス」の生成関係を一目で分かるようにしたもので、これに「成果物定義書」と「プロセス定義書」を組み合わせます。これによって、今回の要求に合わせて「テーラリング」で小さく変化させる箇所を表現できます。
このように、プロセスは要求に合わせて毎回作るものであるという認識をもってもらうために、「プロセスを設計する」と表現しているのです。
Q：この会だけでなく、他の組織でもカンファレンスへの応募や研究会の取り組みの結果を「論文」の形にするようですが、私はこれまで論文というものを書いたことがありません。論文にすることにどのような意味があるのでしょうか？
A： 派生開発協議会では、研究会の成果は基本的に論文の形にまとめることを求めています。派生開発カンファレンスも本来であれば皆さんからの論文の応募をベースにして選考したいと考えています。初回のカンファレンスは準備の関係で論文を前提にすることは出来ませんしたが、次回以降は本来の目指す姿を追いたいと考えています。論文の形にすることの理由は、論文の構成が
- 問題の定義に始まり、
- 現状の計測から解決策の仮説を立て
- その仮説に沿って実践し
- 結果の計測を含めてその効果を検証する
というステップを追う形になっているからです。
現場にはいろいろな問題が山積しています。ただし、定義された問題が横たわっているわけではありません。あることが原因となって問題を引き起こし、そのことがさらにいくつかの新しい問題を引き起こしています。つまり、長く放置されてきた組織にあっては、何が問題なのかが分からない状態になっているのです。解決策を講じるにも、問題を定義するスキルが前提となります。
「問題は何ですか？」
「いや、バグが15件／KLOCも出て困ってるんだよ。その内の8割が仕様のバグでね」
多くの人は、問題を定義することを省いてきました。いや、組織はそのことを求めてきませんでした。そこで行われているのは表面に出た症状に対応することであって、それを繰り返しても問題が解消するわけでありません。単に頻発するバグを潰すため行動であり、対応の結果を分類集計して見える形にしているだけであり、バグは減りません。これが現実です。
たとえば、
「変更内容について担当者任せになっていることで、変更依頼に関連した箇所の変更し忘れがバグ全体の６割も生じている」
「派生開発では全体を理解できない状況にあるにも関わらず、該当箇所と思えるところを見付け次第に変更していることで、思い込みや勘違いがバグなって吹き出している」
というように「因」と「果」の形で問題を定義できれば、担当者任せに成らない方法を考えたり、ソースコード上で該当箇所を見付け次第に変更しなくてもよい方法を探したり、思い込みや勘違いが原因と思われるバグを減らす方策を考えることができます。もちろん、同じような混乱の中にいても、人によって問題（「因」）の捉え方が異なる可能性があります。それは問題が一つではないことを意味しており、人によって見える「因」が異なるのです。
このように問題を定義できなければ論文の形にはなりません。本会では研究活動の効果を高めるためにも、「論文」という形を利用してそしてそれぞれの所属する組織に山積する問題を解決するスキルを身に付けてもらうことを考えています。
Q：正会員になってXDDPやUSDMなどの活用方法の研究に参加したいのですが、地理的に遠くて会合に出席できません。このような状況でも研究会に参加できますか？
A： 本会の研究会では、それぞれ研究会ごとに設定したML（メーリングリスト）や掲示板をフルに活用して研究活動を進めていきます。研究テーマについての意識合わせや、各自の分担分けなどもMLを十分に活用しながら進めていきます。研究会としては何度か顔を合わせて各自の分担範囲の進み具合や内容について議論する機会も設けますが、その結果などもＭＬを通じて研究会のメンバーに知らされることになります。確かに、研究を進める上で、実際に顔を合わせて議論することのメリットはありますが、MLを活用することで時間の制約からも解放されます。また、本会の会員は別に仕事を持っており、その状況の中で問題の解決のために研究するわけですので、地理的な制約をできるだけ排除したいと考えています。それでも、最後の成果の発表会にはぜひ参加して頂きたいと思っています。