ソフトウエア開発業務の変革期

　今現在は世界的にも、日本的にもソフトウエアの開発業務の変革期です。１つは、本格的なグローバリーゼーションの時代になるからです。価格競争に突入、ソフトウエアのより効率化のためのオフショアなど戦略と課題が真っ向からぶつかるものもあります。

　他の問題としては再利用の話題が今まで以上に盛り上がる時期となるでしょうね。技術的な視点からは再利用はOOADやコンポーネントベース開発が中心の話題ですが、昨今大きく取り上げられているものに、マルチパラダイム的アプローチがあります。簡単に言うと、いくつもの手法や技術を効率的・統合的に利用すると言うものです。

　つまり、OOADやコンポーネントベース開発など特定の手法や技術では、大きな成果もありましたが、同時に、開発中およびシステムの保守に幾つかの問題がありました。これらは未だに完全には解決で出来ないからです。

　この事は機会を見つけて雑誌の記事や講演などでお話しをしていきますが、以前から開発プロセスやオブジェクト指向技術によるコンポーネントの部品化を真剣にやられている方には経験がある課題です。いわゆる「Crosscutting Concerns」のことですが、これは色々な粒度、レベルで発生します。

　AOP（アスペクト指向プログラミング）の世界では「拡散（散らばり）」、「もつれ合い（ゆがみ）」などで言われることがあります。コードレベルでは、クラスの定義に「割り込み」が挿入されるなどと表現される事もあります。

　最近は良く話題になることがありますが、オブジェクト指向開発が本格化してきた1980年代後半から開発現場でも良く話題になる課題でした。研究レベルではもっと以前から議論の対象であったでしょう。もっとも用語はこのような呼び方は当時はされていないですね。
今でも呼び方はまた標準的なものに整理されては居ない状態です。

　例えば、オブジェクト指向技術などを使いたとえ上手く分析・設計しても（キチンと上手く分析・設計するからこそ）、要件に求められている機能をクラスやサブシステムに綺麗に責務を割り当てられずクラスやサブシステムに横断する機能・非機能があります。

　古くは、ビジネスロジックの切り出し（いわゆるコントローラー）のような話題もありました。これも１つの関心の分離です。コントローラークラスを入れることで、ユースケースが変わったときに多くのクラスに修正を入れないで済みますし、そもそもエンティティ・クラスは、ビジネスロジックの知識を入れるべきではないです。
#最も、「関心の分離」の課題は、コントローラークラスを入れるだけでは解決できないものもありす。

　組込みシステムやリアルタイムシステムでは、「並行性」、「フォルトトレランス性」などが代表的なものです。こちらは粒度が大きい関心事です。

　ただ、「直交する」ことは必ずしも悪いと言う事ではなく、単純に対応関係がないと言うだけです。上手く「直交性」を活かした設計手法もあります。互いに直交性を活かして分析・設計をし、統合時点でマッピングする訳です。とわ言え、それでも技術的な課題は存在します。

　保守性や再利用性を高めるためには、単に設計・実装の時点で、「Crosscutting Concerns」の分離を考えれば言い訳では無いです。要求定義時からハッキリと明確にすることが望ましく、意識して分析・設計することが必要です。

　実装時点では何かの開発環境を用いて統合（AspectJ的な言い方ではウィーブ）することになりますが、仮に色々な制約で、「Crosscutting Concerns」の分離を最終的に、ある程度諦めないといけない場合でも、要求定義・分析、分析、設計、実装を通じて「横断的な「関心事の分離」を意識して行けば、従来よりアーキテクチャの保守や再利用性は格段と向上します。

　再利用時代に他に話題となっているプロダクトライン戦略や複数の手法を効果的に融合・統合して用いることになりますが、要求定義のやり方も変化をもたらすと言う事です。

　要求開発から実装まで、今後は多くの開発アプローチの話題が出るでしょう。多くは本当に新しいものでは無く、以前から議論されていたものが多いのですが、よりリファインされ他の技術と効果的に扱うことが強調されると思います。

　CMMIによる改善も、組織が旧態然とした開発から「より効果的な開発手法の導入とプロセスの整備」などにもっと用いるべきです。今は形だけの改善活動が多い気がしますね。単に成熟度が上がってもそれだけでは、開発現場の課題は解決されないですからね。