ソフトウェアのもっとも重要な品質は発展性

　ソフトウェアでもっとも重視すべき品質は「発展性」なんだと思う。 機能要求や非機能要求は、時間とともに変化する。その要求の変化に対応してソフトウェアを発展させていける能力、つまり発展性こそがソフトウェアの価値を大きく左右する。
　発展性に問題があり変化ができないソフトウェアと、発展性に優れ変化と成長を続けやすいソフトウェアの価値の差ということだ。

発展性の価値

　顧客のニーズは変化する。また、市場の競合関係も変化する。そういう事業環境の変化にあわせて、ソフトウェアにも変化を続ける能力が求められている。
　また、顧客のニーズや市場環境の変化がゆるやかだとしても、事業活動をすれば組織は経験を通じて学び成長していく。開発チームに限っても、ソフトウェア開発運用の経験を積むことで、開発の考え方とやり方にさまざまな学びと成長がある。そうやって学んだ知識を適切にかつ迅速にソフトウェアに反映できるほど、事業により多くの価値を提供できるはずだ。

保守性

　従来のソフトウェア品質モデルだと、発展性に似た視点として保守性がある。
　しかし、保守性は発展性とは発想が正反対になる。保守性は文字通り守るための能力である。なにか正しい状態が事前に定義されていて、正しくないことを検出したら、定義済の正しい状態に戻す活動が保守性の基本の発想だと思う。 　それに対し発展性は、次の展開を切り開くための能力だ。現在の状態を前提に、よりよい状態を模索しそこに向かって変化していこう、というのが発展性の基本の発想となる。

変更容易性

　保守性も発展性も「変更容易性」として同一視することも可能かもしれない。しかし、保守しようとするのか、発展しようとするのかの方向性の違いは決定的だと思う。保守性を確保するための工夫と、発展性を向上していくための工夫はおのずと異なるものとなる。

発展性を生み出すための工夫

　ソフトウェアの発展性を向上させるために、いろいろやってみた。次の三つの取り組みに手ごたえを感じている。

  • 要件定義・仕様化・実装の継ぎ目をなくす
  • ビジネスルールに焦点をあわせる
  • 型によるモジュール構造を基本にする

要件定義・仕様化・実装の継ぎ目をなくす

　代表的な二つの開発のやり方、ウォータフォールとアジャイルについてソフトウェアの発展性の観点から考えてみる。

ウォータフォール

　いわゆるウォータフォール的な開発手法は、要件定義・ソフトウェアの詳細仕様の記述・実装のためのプログラミングの三つの活動を分断する。
　要件定義・仕様化・実装の三つの活動を分断し、異なる技術者がそれぞれの活動を担当し、活動間の意図の伝達のために、大量のドキュメントを作成する方法を採用する。

要求と実装の乖離（かいり）

　このアプローチで発展性を向上するのは難しい。要求の発生から実装のあいだの工程が多い。時間もかかるし、なによりも、要求と実装との間に距離がありすぎて、要求の変化に対して伝言ゲームを繰り返した結果、要求とはかけ離れた実装になる。コミュニケーションの方向も一方通行で、実装の段階で発覚するさまざまな疑問・仕様の抜け漏れや矛盾についての適切な補足や修正が起きにくい。

手続き的なモジュール構造

　そもそもソフトウェアの変更が構造的に難しい場合が多い。ウォータフォール的な開発では、画面や機能単位に分割した手続き的なモジュール構造を採用する。手続き的なモジュール構造では、ビジネスルールに基づく計算ロジックや判断ロジックを、画面や機能の視点で分割したモジュール群に記述する。その結果、本来はひとつであるべきビジネスロジックが、モジュールのあちこちに断片化しかつ重複する。こういう断片化と重複は、ずさんの設計の結果ではなく、手続き的なモジュール構造を選択した場合の必然的な帰結になる。もちろん、設計が劣悪であれば、結果はさらに悲惨にものになる。
　多くのレガシーなシステムが現在直面している変更がやっかいで危険という問題は、ウォータフォール方式のソフトウェア開発で採用されてきた手続き的なモジュール構造が直接的な原因となっている。

変化の兆候

　ウォータフォール的な開発をリードしてきたSI'erや大手企業の情報システム部門も、いままでのやり方ではうまくいかない。なにか、新たな開発のやり方に取り組んでいかなければいけない、という危機感は少しずつ広がってきているようだ。そういうところからの相談が増えてきた。顧客の要求に対して、いままでのような重厚長大で、時間とコストをかけるやり方では対応ができないことが明らかになってきた。

アジャイル

　一方、いわゆるアジャイルな開発は、活動を分離せず、伝言ゲームのためのドキュメントの大量作成はやらない。ウォータフォールとは正反対のアプローチを模索してきた。しかし、そういうやり方で開発されたソフトウェアも、時間とともにレガシー化が進み、発展性がどんどん劣化してく問題が起きることが明確になってきた。

要件定義や分析設計スキルの軽視と劣化

　アジャイルが提唱され始めたころは、要件定義や分析設計について一定の知識と経験をもった技術者が取り組んでいたと思われる。しかし、アジャイルが広まるにつれ、要件定義や分析設計についてきちんと教育や訓練を受けない技術者が急速に拡大した。また、それほどの分析設計のスキルがなくても、小規模なアプリケーションであれば、それなりに動くソフトウェアを作れるようなフレームワークやその利用のtipsが簡単に手に入るようになったことも、この方向を加速させた。

問題の顕在化

　しかし、アプリケーションがある程度の規模になり、複雑なビジネスルールを扱うことが要求されるようになると、要件定義や分析設計のスキル不足の問題が顕在化するようになった。
　アジャイルというソフトウェア開発のやり方であっても、しっかりとした要件定義やソフトウェア仕様化の知識と経験が重要であることに、多くのアジャイル系の開発者も気づき始めている。

要件定義・仕様化・実装の継ぎ目をなくす工夫

　ウォータフォール的な開発のやり方でも、アジャイル的な開発のやり方でも、発展性を重視するのであれば要件定義・仕様化・実装の継ぎ目をなくすことに取り組むことで大きな可能性が生まれる。

ウォータフォールからの移行

　ウォータフォール的な開発のやり方に習熟した組織であれば、要件定義やソフトウェア仕様化についてのさまざまなノウハウの蓄積がある。問題は分業と一方通行の伝言ゲームである。分業ではなくひとつの技術者チームが要件定義・仕様化・実装を担当するようにすれば、伝言ゲームのためのドキュメントづくりは不要になる。
　要件定義から実装・運用までひとつのチームが継ぎ目なく担当することで、ドキュメントづくりは必要最小限になり、ソフトウェアの生産性は劇的に改善する。しかし、継ぎ目をなくすだけでは残念ながら発展性の向上はそれほど期待できない。手続き的なモジュール構造からの脱却が大きな挑戦テーマになる。（発展性を向上させるモジュール構造への移行については後述する）

アジャイルからの移行

一方、アジャイルな開発スタイルでは、そもそも継ぎ目はない活動を目指してきた。しかし、それは要件定義や仕様化の活動自体が軽視され、経験や知識が足りないという現象を生み出した。アジャイルな方法でソフトウェアの発展性向上にと取り組むためには、まず、要件定義やソフトウェアの仕様化の基本的なスキルをきちんと学び習得することが効果的だろう。アジャイル的な開発だけをしてきた技術者には要件定義や分析設計のスキルが大きな伸びしろになるはずだ。

モジュール構造の移行

　アジャイル的な開発であっても、多くの場合、モジュール構造は手続き的なアプローチのことが多い。アジャイルに取り組んでいるある程度の年齢の技術者は手続き的なモジュール構造で技術を覚えてきた人が多いのが実態だろう。また、Webアプリケーション用のフレームワークでは、手続き的なモジュール構造をフレームワークとして組み込んでしまっているものが多い。ソフトウェアの発展性を生み出すためには、手続き的なモジュール構造から抜け出すことがアジャイル系でも重要な挑戦テーマになる。

継ぎ目をなくす手法とツール

要件定義・仕様化・実装の継ぎ目をなくす手法とツールについては、現在、以下の取り組みをしている

仕様の記述言語と可視化

仕様の記述にプログラミング言語を使うことで、要件定義・仕様化・実装の継ぎ目をなくせる手ごたえを感じている。この仕様の記述にプログラミング言語を使うという取り組みの具体的な内容は、このブログで紹介していきたいと思う。
　プログラミング言語で書いたソースコードだけではわかりにく、全体の構造、クラス定義の一覧、メソッドの呼び出し関係などはJigというオープンソースのツールを使って関連図や一覧表を自動生成している。
　エクセルなどを使って自然言語で記述する詳細仕様よりも、プログラミング言語での記述のほうが、整合性や一貫性が明らかに向上する。また、アプリケーションの関心事に対応する独自の型を積極的に定義することで、ソフトウェアの意図が明確になることがわかった。独自の型をモジュール構造の基本にする点については、後述する。

関係性に注目するRDRAのよさ

　要件定義に使っているRDRA2.0は、要件のさまざまな視点間の関係性に注目して、要件定義の整合性を向上を図る手法である。その結果、要件定義とプログラミングの論理構造との対応がつけやすくなり、要件定義・仕様化・実装の継ぎ目をなくし、ソフトウェアの発展性の向上につながっている。

ソフトウェア開発の複雑さに立ち向かう

　ソフトウェア開発の複雑さを生み出す理由はさまざまあるが、本質的にはアプリケーションの対象とするビジネスの複雑さがその主たる原因だと考えている。したがって、ソフトウェア開発の複雑さに立ち向かうアプローチとしては、ビジネス活動の複雑さ、より具体的には、ビジネス活動を刺激し制約する決め事である「ビジネスルール」の複雑さをあつかうスキルを磨くことが、ソフトウェアの発展性を向上させるための重点課題になる。

ビジネスルールが複雑さの根源

　ソフトウェアの複雑さの根源はビジネスルールにある、というのはエヴァンスのドメイン駆動設計の基本的な考え方である。また、RDRA2.0で取り入れられたビジネスルールの分析とモデル化にも共通する考え方である。

ビジネスルールに焦点を合わせる効果

　ドメイン駆動設計に１０年以上取り組み、また、RDRA2.0を使った要件定義に取り組んでみた結果、ビジネスルールに焦点を合わせて要件定義・仕様化・実装を継ぎ目なく行うことが、ソフトウェアの発展性を向上させること、またソフトウェア開発の生産性の向上に大きな改善を生み出すきとにたしかな手ごたえを感じている。

分析設計の知見の言語化への取り組み

　要件定義・仕様化・実装の継ぎ目をなくし、一貫してビジネスルールに焦点を合わせる取り組みの中から、ビジネスルールの分析パターンと実装パターンについて、いろいろな気づきが生まれつつある。ビジネスルールに焦点を合わせた分析設計の実践から生まれつつある暗黙的な設計の知見について、このブログで言語化に取り組んでみようと思う。言語化に取り組むことで自分自身の学びと成長につながることを何度も経験してきている。

モジュール構造の転換の重要性

　画面や機能の単位でモジュール構造に分解する手続き的なアプローチでは、入出力の手順の記述の中に、さまざまなビジネスルールに基づく計算や判断を記述することになる。このアプローチの問題点は、ひとつのビジネスルールのソフトウェア表現が、断片化し重複しやすいことだ。またビジネスルールがif文などに暗黙的に埋め込まれがちだ。

型によるモジュール化

　ソフトウェアの発展性を向上させるには、モジュール構造の考え方を抜本的に変えることが必要である。具体的には、型（値の種類）ごとのモジュール構造を、基本とすることである。 　この考え方は、前述の「ソフトウェアの複雑さはビジネスルールの複雑さに起因する」という考え方と密接に関係する。

ビジネスルールを型を使って表現する

　ビジネスルールとは事実を表現する値（データ）に基づき、計算や判断によって、なんらかの結果（導出した事実）を生み出す決め事だといえる。このビジネスルールに関わる計算・判断のロジックを一元的に記述し、一貫性を持たせるための工夫が「型によるモジュール構造」である。

型はビジネスルールを明示する

　より具体的にはビジネスに登場する様々な値の種類（金額、日付、期間、区分、カテゴリ、..）を、分類・整理し、それぞれの値の種類を独自の型として定義し実装する、というアプローチである。
　独自の型を定義することで、その型の名前がビジネスルールを表現する豊かな語彙(ごい)になる。独自の型を積極的に使うことで、ソースコードがビジネスルールを具体的に語り出すようになる。どこに何が書いてあるかが明快になることはソフトウェアの発展性を生み出す力になる。

オブジェクト指向プログラミング

　値とそれを使った計算や判断ロジックを一つにまとめて独自の型として定義するのは、まさにオブジェクト指向プログラミングの根本にある発想である。さまざまなビジネスルールで扱う値を分類・整理して、その結果を独自の型として定義しプログラミンしていく技法についてもいろいろなパターンが明らかになってきた。ビジネスルールの表現にオブジェクト指向プログラミングを活用するやり方についても、このブログで紹介していきたいと思う。

　継続的・並行的・段階的な発展(CCSR)

　この記事で書いたソフトウェアの発展性を重視した開発のやり方に、CCSRという名前をつけた。

  • Continuous 継続的
  • Concurrent 並行的
  • Stepwise 段階的
  • Refinement 発展

の略語（頭字後）である。

CCSRへの取り組み

　ソフトウェアの発展性は、事前の設計や要件として作りこむ性質ではない。顧客ニーズの変化、ビジネスニーズの変化、事業組織や開発チームの学びと成長に合わせて、継続的に、さまざまな活動を並行的に、そして一歩ずつ段階的にソフトウェアを発展させていく取り組みが生み出す能力である。CCSRという体系化は、まだ仮説と検証の初期の段階である。しかし、個々の要素は、私自身のさまざまなソフトウェア開発経験の中で会得してきた工夫であり技法である。そしてCCSRとしての体系化に取り組み始めたこの半年で、初期の検証結果として、十分な手ごたえを感じている。

ともに取り組む

　CCSR手法のついて、より多くの人に知ってもらい、可能であればそれぞれの現場で挑戦・評価してもらい、お互いの知見を共有できることを願って、ブログとして言語化に取り組んでみた。イベントなどの登壇の機会があれば、そちらもでCCSRの言語化と紹介を積極的にやっていこうと思う。

興味のある方は、ぜひ、いっしょにCCSR手法を取り入れたソフトウェア開発に取り組んでいきましょう。