ハシモト ソフトウェア コンサルティング

第10回:～継承⑩『科学的モデリング』継承⑩～『科学的ソフトウエアバリアント開発(派生開発)』＆『ソフトウェア PLUG AND PLAY 』PART-1

第10回の話題～『科学的ソフトウエアバリアント開発(派生開発)』と『ソフトウェア Plug and Play 』

　前回まで継承関係の重要な原理『タイプ(型)置換原理(the principle of type substitution／type substitutionprinciple)』や その代表的な１つである『リスコフ置換原理(Liskov substitution principle)』の解説を行ってきました。

　理論や原理の話題が続きましたので、今回から設計や実装で利用するモデリングの実践的アプローチについての解説を交えて解説を進めることにます。
　漠然とした技術の解説にならない様にすることと、いきなり目的やメリットが分からないまま詳細な技法の解説になることを避けるために、 　ソフトウェアの開発現場の課題を検討し、その課題への対応としての実践的な視点から技法を解説することにします。
　解説の構成と流れは【図10-1】の様に考えています。

　まず、開発現場で課題になっていることを明確にします。そして課題を解決する科学的かつ先進的な開発アプロー チを紹介します。科学的かつ先進的な開発アプローチの目的や効果を解説し、その後で開発アプローチを実現するた めの理論、原理、技法を紹介していくことにします。

　ただし、一度に全てについて詳しく解説できませんので、今回から数回に渡っての実践的アプローチとそのアプロ ーチを支える科学的モデリング技術について解説していきます。

　今回のテーマは下記になります。

グローバルな大競争時代の開発現場の課題

　実開発を行うエンジニアの方にとって、日々直面する課題は多岐に渡ります。しかし、その中には多くの企業で共通する課題もあります。

　現代の開発現場の共通の課題を【表10-1】に掲載してみました。

　【表10-1】の課題に対応するには旧態依然のやり方では限界があります。明らかにより効果的な開発・管理アプロ ーチへの移行が絶対条件です。

　【表10-1】の課題は単独の課題の解決、あるいは目の前にある課題だけに対応する対処療法では解決は困難である ことは誰でも直観的に分かります。理由は課題の１つ１つは独立しておらず、相互に関連しており複雑化しているか らです。そのため、課題および課題間に潜む本質的な原因をまずは明確にする必要があります。

課題1:市場投入の短い開発期間

　「市場投入の短い開発期間」の課題に対して、多くの企業が開発作業を一部外部に委託する「アウトソーシング」 で対応しています。また、既存のソフトウェア資産(仕様書、設計書、コード)を流用し開発することが行われています。

　全くの新規開発でない限り、開発する製品やシステムをゼロから行うことはありませんし、開発時間も開発コスト もかけられません。そのため「アウトソーシング」や既存の「ソフトウェア資産の再利用」をどのように行うかが大きなテーマになります。

　これは製品やシステムの品質向上、開発期間の短縮、開発コストの削減、および最終的に販売価格に直接関わる大きなテーマです。

　効果的な「アウトソーシング」を実施するためには、分散・並行開発において仕様書作成、設計作業およびコード 作成が効果的かつ効率的に行える作業成果物の構成になっていないといけません。

　同じく「ソフトウェア資産の再利用」を行うには、ソフトウェアが「部品化」されていなければなりません。

　現在多くの企業では科学的かつ体系的な「アウトソーシング」や「ソフトウェア資産の再利用」の実施できる開 発・管理プロセスが存在せず、科学的な開発技法およびツールの利用もおこなわれていません。

　また、人がかなりの工数をかけて非効率な文書による管理技法でソフトウェア資産を管理し、再利用する方法を行 っている企業もあるようです。しかしこの様な旧態依然の方法では開発コスト、開発期間および欠陥の削減にはつな がらす、むしろ開発期間、開発コスト、品質が悪化するリスクは増大しています。

課題2:多品種のシステムの開発や生産(多品種少量開発)

　開発・販売する製品やシステムの種類が豊富であることは企業の競争力の大きな源泉になります。 企業が製品に「高性能の部品」「オブション機能」などで「グレード」や「ランク」とよばれる方法により、製品 にバリエーションが生まれユーザーや購入者に魅力的な選択肢を与えています。

　多くの製品やシステムを開発するほど「多品種少量開発／多品種少量生産」と呼ばれる状況になります。

　扱う製品やシステムの「グレード」や「ランク」が多種・多様になり、その結果「多品種少量開発／多品種少量生 産」になればなるほど「課題１」と同様に、開発期間、開発コスト、品質が悪化するリスクは増大します。

　一人あるいは１つのプロジェクトが扱う製品やシステムの種類と作業内容が増加・増大するために、開発の時間は さらに少なりなり、「ミスによる欠陥の品質低下」「欠陥の修正にかかる手戻りコストの増加」のリスクが極めて高 くなります。そのため、開発アプローチや構成管理( Configuration Management )の作業などが「多品種少量開発／多 品種少量生産」に対応したものでなければなりません。

　繰り返しますが、人が多くの工数をかけて多くの製品やシステムの作業内容を行う方法では、開発時間と開発コス トの削減、品質向上を達成することは無理です。非効率な文書による技法でソフトウェア資産を管理し、再利用する アプローチはミスを誘発しやすくソフトウェア開発には向きません。

　ソフトウェア開発にはコンピューター科学を最大限に利用し作業の自動化を前提とする「科学的な多品種少量開 発」の方法が存在し実績をあげています。これにより開発コストの削減と人為的ミスが大きく削減できます。いち早 く旧態依然の危険な開発方法から「科学的な多品種少量開発」に移行すべきです。

課題3:価格競争

　現在の経済活動ではどの分野を問わず、最大のコストは「人件費」です。特にソフトウェア開発は高度に知的な開 発活動ですから、どの企業も高い人件費を払っても優秀な人材確保することは最重要テーマです。

　そのため高い人件費がかかる優秀なエンジニアに専門的な作業に集中させ、なるべく非創造的な作業にはツールに よる自動化で対応することが、開発時間と開発コストを圧縮することにつながります。

　そして、優秀な人材には創造性の高い活動に時間を使わせることのより、魅力ある製品・システムを生み、企業の 競争力向上を達成することになります。

　自動化は【表10-2】のような作業が可能です。

　なお、作業の自動化そのものが難しいのではなく、開発活動や管理活動の自動化を加速する「開発プロセス」や 「管理プロセス」に企業が移行できるかどうかという点が最大のポイントになります。

課題4:大規模化複雑化する製品やシステムの品質確保

　ソフトウェア工学の研究から、分野を問わず開発作業の欠陥(不具合)による手戻りコストは「開発総コスト」の 40%～60%を占めることが分かっています。

　そして欠陥が下流工程になればなるほど欠陥摘出が困難であり、かつ、修正コストが高くなることこれまでの調査 および事例報告で知られています【表10-3】。

　開発時間と開発コストを減少させ、品質を向上させるには、欠陥(不具合)を減らし、手戻りコストを無くすことが最良の方法です。 このことから、上流から作業成果物である仕様書や設計書の品質を確保することが不可欠であることがわかります。

　上流の作業成果物の欠陥摘出はインスペクションが有効です。科学的なインスペクションであれば、極めて高い欠 陥摘出が可能になります【表10-4】【表10-5】。

　しかし、人間が作業成果物のインスペクションやテストを完全に行う事は、「課題１」～「課題３」と合わせて不可能な状況にあります 【表 10-6】。特に開発の一部を「アウトソーシング」する場合は、委託先の品質に大きく依存します。発注側が自ら品質を保証することは限界があります。 このように効率的かつ効果的な受け入れ試験を実施する方法を確立し、またどのように品質を満たす方法を確立すればよいのかということが大きな課題となっています。 委託先の企業も同様に「課題１」～「課題３」を抱えていますから課題は単純ではありません。

　上流から作業成果物である仕様書や設計書の品質を確保可能な『科学的開発アプローチ』に移行しなければこの状況から抜け出すことは不可能です。

　【注10-1】インスペクション:

　1970年代にIBMのMichael Faganによって開発された欠陥摘出の技法がインスペクションです。多くの企業で実施 されているレビューやインスペクションとは大きく異なるため、「Faganインスペクション」と呼び区別することも あります。「科学的なインスペクション」技法であり、7つのアクティビティから構成されます。厳密なインスペクシ ョン手順、ルール、参加者の役割が存在します。高い欠陥摘出率を誇る技法として有名で世界中で利用される様にな りました。単なる欠陥摘出が目的ではなく、欠陥の原因を分析しプロセス改善で欠陥予防を実施することに本質的な狙いがあります。 摘出した欠陥の分析結果と開発作業およびインスペクション作業に関連するメトリクスを利用して精度の高い品質管理を行います。

【注10-1】欠陥摘出率(Defect Detection Percentage):

　インスペクションあるはテストで単位となる時間、コストあるいはその他で、欠陥(不具合)を摘出(検出)した割合 を意味します。

課題5:増加するオフショア開発／アウトソ-シング開発への対応

　「課題１」で「アウトソーシング」について触れました。中大規模の企業や多くの製品・システム開発を行ってい る企業では「アウトソ―シング」はごく普通に実施されています。しかし、「アウトソーシング」先である委託先企 業の品質をどのように担保するかについては確立された基準と作業方法がなく非常に曖昧な品質保証および品質管理 に陥っている企業が大多数です。

　「アウトソーシング」により委託先企に開発の一部を依頼することは、１つの「分散並行開発」です。そのため、 効果的な「アウトソーシング」を実施するためには、既存の製品やシステムの設計やコードが分散・並行開発できる ような作業成果物(仕様書、設計書、コード)の構成になっている必要があります。

　さらに、委託先の成果物を受け入れる際の「受け入れ試験」についても、有効な方法がとられていません。「受け 入れ試験」の「妥当性確認」と「検証」作業が極めて不十分な状況になっています。

『ソフトウェアPLUG AND PLAY』と『ソフトウエア・バリアント・デベロップメント(ソフトウェア派生開発)』

　開発現場の課題を整理・確認しました。ここからは【表10-1】の課題を解決する『科学的先進的開発アプローチ』を紹介します。 今回紹介する『科学的先進的開発アプローチ』は、【表10-7】に掲載します。

『ソフトウェアPlug and Play』

『ソフトウェアPlug and Play』の概要を紹介します。

『ソフトウェアPlug and Play』は技法でありプロセスです。そして効果的な「アウトソーシング」や「ソフトウェアの再利用」の実現に効果的です。 『ソフトウェアPlug and Play』はソフトウェアを「部品」として開発・管理・再利用できることを実現します。

　「ソフトウェア部品」は、ハードウエアを構成するブロックと同じ様に自由にソフトウェアの「再利用」「交換」「配布」が可能です。
　「ソフトウェア部品」が自由に「再利用」「交換」「配布」が実現できるのは、「ソフトウェア部品」のインタフェースが明確に定義され、 　「ソフトウェア部品」としての機能が実装されている必要があります。そして、「ソフトウェア部品」が利用しやすい粒度と利用容易性が 成立するからです【図10-2】【図10-3】。

　コンポーネント内部はコンポーネントの利用者にはブラックボックスになります。コンポーネント内部の修正や拡張は、コンポーネント の利用者には影響をあたえません。コンポーネントの利用者にはインタフェースとなるクラスだけに依存しているからです。さらに、コンポーネント内部 も容易に機能の修正や拡張が行えるように設計・実装します。具体的にどのようにして優れたコンポーネントを設計・実装をおこなえば良いかは、コラム の中で順次解説していきます。

　「ソフトウェア部品」のインタフェース定義とは、単にプログラム言語の操作のシグネイチャを記述した内容ではありません。インタフェースには 「ソフトウェア部品」の処理(振る舞い)の正確な「仕様」の定義が記述されます。 このことは大変重要な意味をもちます。
　処理を満たすことを含めた「仕様」とは、このコラムでこれまで解説してきた「タイプ(型)置換原理」を適用し「振る舞いサブタイプ(型)」を満たすことや「クラス不変条件」および操作の「事前条件」「事後条件」「例外定義」などの理論と原理を利用して記述されます【図10-4】【図10-5】。

　さらに、並列・並行性を持つクラスとコンポーネントも同様です。並列・並行性を持つクラスとコンポーネントに は、通信メカニズムの同期・非同期や排他制御およびリアルタイム性における条件をクラス不変条件」および操作の 「事前条件」「事後条件」「例外定義」で定義します。

　これにより正確かつ厳密な「ソフトウェア部品」の仕様・設計・コードの記述が可能になります。そして、「ソフ トウェア部品」同士のインタフェースがシグネイチャ(構文レベル)だけの合致ではなく、「意味的整合性」である 「振る舞い」も含めて合致するかについて自動判定が可能になります。

　より具体的に言えば、並行開発の際のサブシステムやコンポーネント間の結合時にコンポーネントやサブシステム のインタフェース仕様を満たしているかを演繹的に自動判定が可能になるということです。これはアウトソーシング した開発成果物を発注側が受け入れる「受け入れ試験」にも応用ができます。

　この「ソフトウェア部品」同士のインタフェース定義がお互いに仕様を満たし、連結が可能かの判定は、全て科学 的なモデリングツールを通じて実施します【注10-2】。開発者は煩雑な作業をすることなくツールによる自動化で開 発時間、開発コスト、欠陥削減による品質効果を大幅に短縮できます。

　『ソフトウェアPlug and Play』の直接の応用が、『ソフトウエア・バリアント・デベロップメント(ソフトウェア 派生開発)』になりす。そのため『ソフトウェアPlug and Play』が可能になると、『ソフトウエア・バリアント・デ ベロップメント(ソフトウェア派生開発)』に大きく前進します。

【注10-2】ソフトウェアCAD(科学的モデリングツール):
この技術コラムでは『科学的ソフトウェア開発』『科学的モデリング』を解説するために特別なモデリングツール を使用します。クラスの不変条件である表明(契約)の設定・表示機能、継承関係の評価として「タイプ(型)置換原 理」と「モジュラー推論」の数種類の演繹推論規則を実装し、各種数学的な方法によるモデルの正当性・妥当性の判 定と自動コード生成機能などが利用可能なツールです【図10-4】【図10-5】。 本コラムで分かり易い解説を行うために、今後このツールを利用して解説を行っていきます。

『ソフトウェアPlug and Play』と先進的構成管理

『ソフトウェアPlug and Play』と『ソフトウェア部品』

　『ソフトウェアPlug and Play』は、単にコードだけの部品化ではありません。「ソフトウェア部品」の意味にはソ フトウェア部品の作業成果物(仕様書、設計書、コード、その他)も含まれます【図10-6】。

　企業では開発する製品やシステムの作業成果物を保存・管理することが義務であり責任ありますから、部品化され たソフトウェア毎に適切に作業成果物を保存・管理することが求められます。

さらに「ソフトウェア部品」が継続的に利用されるためには、「ソフトウェア部品」自身も必要に応じて変更がか けられる様にする必要があります。そのため、「ソフトウェア部品」を利する開発者に必要な情報も必要になりま す。ソフトウェア部品の性能を示すメトリクスデーター、コンパイラ&バージョン、仕様書、設計書およびコードな どが「ソフトウェア部品」に含まれています。

『ソフトウェアPlug and Play』と「先進的構成管理」

　『ソフトウェアPlug and Play』は、効果的な「アウトソーシング」や「ソフトウェアの再利用」を実現します。 上記した様に開発する製品やシステムは先進の開発アプローチにより部品化を意識して開発と管理が推進されます。

　効果的な「アウトソーシング」や「ソフトウェアの再利用」の実現には、ソフトウェアを独立して並行開発するこ とが可能な、設計プロセスと技法および開発ツールの利用が不可欠になります。

　『ソフトウェアPlug and Play』は、構成管理が極めて重要となります。『ソフトウェアPlug and Play』および 『ソフトウエア・バリアント・デベロップメント(ソフトウェア派生開発)』に最適化された構成管理作業プロセスは、 組織あるいは開発プロジェクトのリポジトリ内に「ソフトウェア部品」を含むソフトウェア資産のリビジョン、バー ジョン、バリアントを正確に管理します。常に製品・システムのソフトウェア部品の構成の整合性と追跡可能性(トレ ーサービリティ)を保つことが可能になります【図10-7】。

　この最適化された構成管理作業プロセスは、従来の構成管理対象(構成アイテム( Configuration Item )とも呼びます) の成果物や構成管理作業プロセスとは大きく異なる点が多数あります。構成管理作業プロセスはせ成果物の修正点の 履歴管理とバージョン管理およびブランチ管理が主な目的でした。そのため従来型の構成管理作業のやり方では、 「アウトソーシング」や「ソフトウェアの再利用」では、扱う構成管理対象の作業成果物が激増しますので、構成管 理活動プロセスが複雑化し、その結果開発時間、開発コスト、品質保証に直接影響を与えます。

　『ソフトウェアPlug and Play』(および『ソフトウエア・バリアント・デベロップメント(ソフトウェア派生開 発)』)に最適化された構成管理作業プロセスは、完全自動化に近い状態で作業が実施されます。そのため、構成管理 ツールの利用が不可欠ですが、フリーで利用できる構成管理ツールで十分間に合います。ただし『ソフトウェアPlug and Play』(および『ソフトウエア・バリアント・デベロップメント(ソフトウェア派生開発)』)に最適化した構成管 理活動は、利用する構成管理ツールの機能差の影響を受けるものではありません。

　実際、欧米の企業では構成管理のリポジトリから1000以上の種類の製品・システムを完全な自動化によりコンパイ ル、リンクをしてデプロイメント(deployment:テスト環境に置く事やリリースすること)を行う事が普通に実施され ています。

　なお、バリアント(variant)、リビジョン(revision)、バージョン(version)という用語については、次回以降で解説 する『ソフトウエア・バリアント・デベロップメント(ソフトウェア派生開発)』のところで解説します。

ミッションクリティカル・システムと『ソフトウェアPlug and Play』

　ミッションクリティカル・システムではソフトウェアの品質に特に慎重になる必要があります。「枯れたコード」 と呼ぶ、長く使用されて信頼性の高いコードを大切に保守し、継続して使用する傾向が大きいのもミッションクリテ ィカル・システムの特徴です。

　一方で「枯れたコード」を使う企業の多くは、「枯れたコード」の管理を特定の開発者に依存しています。担当者 の経験と属人的なスキルに頼っていますので、この担当者がいなくなった場合はどうなるのでしょうか。

　さらに「枯れたコード」が古い開発アプローチで作成されたことが原因で作業成果物の管理が容易でないことも大 きい課題です。このことが原因でアウトソ-シングや海外へのオフショアを利用した分散並行開発の時代に適した開発 アプローチや成果物構成に移行できないというジレンマがあります。

　ただし、ソフトウェアの欠陥をゼロにすることは容易ではないために、「枯れたコード」という考え方とコードの 利用は、今後もミッションクリティカル・システムでは必要でしょう。

　この点についても『ソフトウェアPlug and Play』(および『ソフトウエア・バリアント・デベロップメント(ソフト ウェア派生開発)』)は威力を発揮します。科学的に「枯れたコード」の開発／改良／再利用／管理を実現が可能なの です。

　『ソフトウェアPlug and Play』は、「ソフトウェア部品」を明確なインタフェース定義、インタフェース間の整合 性判定、効果的な成果物の分割による部品化、および科学的な構成管理技法により、長く継続的にソフトウェアを利 用・管理する仕組みを確立することが可能になります。

　『ソフトウェアPlug and Play』および『ソフトウエア・バリアント・デベロップメント(ソフトウェア派生開発)』 は、ミッションクリティカル・システムや組み込み、制御系の製品・システムの開発で積極的に利用され始めていま す。「多品種少量開発」を効率的に実施し、リコールの発生リスクを大きく軽減するためです。

　『枯れたソフトウェア部品』の管理を、特定の開発者の経験と属人性に編重した作業から解放し、アウトソ-シング 開発時代に適した新しい開発アプローチや成果物構成技術への移行を可能にします。

『ソフトウェアPlug and Play』で課題が解決できる理由と実現するための理論・技法・原理

　『ソフトウェアPlug and Play』の概要を解説しました。『ソフトウェアPlug and Play』で【表10-1】の課題を解 決あるいは低減できる技術的な理由を考えていきます。作業から見たとき『ソフトウェアPlug and Play』で【表10- 9】で掲載したことが可能になるからです。

　どのようにして【表10-9】のようなことが実現できるかですが、主に下記の理論・技法・原理を適用します。

まとめ＆次回

　今回は多くの企業で共通する課題を取り上げて整理を行いました。また各課題の原因と解決策を検討しました。

　そして『ソフトウェアPlug and Play』および『ソフトウエア・バリアント・デベロップメント(ソフトウェア派生 開発)』の概念とメリットを解説しました。『ソフトウェアPlug and Play』については簡単な原理と仕組みを紹介し ました。

　次回以降は【表10－10】の『ソフトウェアPlug and Play』を実現する理論・原理・技法の詳しい解説と『ソフト ウエア・バリアント・デベロップメント(ソフトウェア派生開発)』の紹介をしていきます。

　最後に１つ重要な事を記述します。
　『ソフトウェアPlug and Play』および『ソフトウエア・バリアント・デベロップメント(ソフトウェア派生開発)』 は、理想論的なアプローチではなく、欧米の先進的な企業では、既に実用化がおこなわれているアプローチであると いうことです。

　そしてもう１つ重要なことは、非常に科学的なアプローチということです。人工知能機能の応用が著しい時代にな り、人間にとって代わることが危惧されています。一方で人工知能機能を含む数学・論理学を土台としたコンピュー ター科学を利用した科学的な開発アプローチは、企業の開発・生産プロセスとしてこれからの「グローバルな大競 争」時代に不可欠なものとなっているということです。

「参考文献」

文献[10-01] [J.-M. Jezequel1998] Reifying Configuration Management for Object-Oriented Software

文献[10-02] [Clemens Szyperski 2002] Component Software: Beyond Object-Oriented Programming (paperback) (2nd Edition)

文献[10-03]「Design and code inspections to reduce errors in program development」 Fagan, M. E. IBM

文献[10-04]「Advances in Software Inspections」Fagan, M. E

文献[10-05] [ Tom Gilb,Dorothy Graham ] Software Inspection(邦訳「ソフトウエアインスペクション」)

文献[10-06] [Paul C.Clements2000] Active Reviews for Intermediate Design」

文献[10-07]「Automated Requirement Measurement Tool」

文献[10-08] [David Farley,Jez Humble] Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (邦訳「継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化」)

文献[10-09] [ Paulk, M., Curtis, B., Chrissis, M. B.] Capability Maturity Model for Software, Version 1.1 Pittsburgh,Software Engineering Institute, Carnegie Mellon University.(邦訳「成功するソフトウエア開発-CMMによるガイドライン」)

文献[10-10] [ Boehm,Barry W. 1981] Software Engineering Economics. Englewood Cliffs,NewJersey

文献[10-11] [ Grady,Robert B. 1999] An Economic Release Decision Model: Insights into Software Project Management. Proceedings of Applications of Software Measurement '99 Conference. San Jose, California: 225-239.

文献[10-12] [Kaplan,Craig A. 1995] Secrets of software quality. Proceedings of the Fifth international Conference on Software Quality. Austin,Texas.American Society for Quality Control

文献[10-13] [ Haley,Thomas J. 1996] Software Process Improvement at Raytheon.

文献[10-14] [ Grady,Robert B.,and Tom van Slack.1994] Key Lessons in Achieving Widespread Inspection use. IEEE Software 11, no. 4: 46-57.