ソフトウェア開発の問題点
従来のウォータフォール方式で、フェーズ分けと分業を重視し、手続き的なモジュール構造でソフトウェアを開発するやり方には次の問題があります。
- 大量のドキュメントの作成に膨大な時間と費用がかかる（工程が多く、必要な人員がふくらむ）
- フェーズ分けと分業のため、関係者の間の認識合わせが難しい（伝言ゲーム）
- ちょっとした変更でも、調査・修正・確認に膨大な時間がかかる（変更がやっかいで危険）
一方、アジャイルと呼ばれる開発のやり方は、以下の問題が起きがちです。
- ソフトウェアの規模が大きくなると、どこになにが書いてあるか理解ができなくなる
- 増築・改築の繰り返しが、全体の構造と品質を劣化させる
- 全体を俯瞰したり構造を確認するための情報がなく、変更の影響がわかりにくい
- ちょっとした変更でも、調査・修正・確認に膨大な時間がかかる（変更がやっかいで危険）
どちらのやり方でも 変更がやっかいで危険 になることが大きな問題です。
CCSR手法
CCSR手法は、ソフトウェアの最も重要な品質特性は、変更が楽で安全になること、つまり、ソフトウェアの発展性である、という考えに基づく開発手法です。
CCSR:Continuous Concurrent Stepwise Refinement (継続的・並行的・段階的な発展)
ウォータフォールでもアジャイルでも実現できなかった、ソフトウェアの変更を楽で安全にするための開発手法です。
参考資料：ソフトウェア開発のやり方の改善
コンセプト
- ソフトウェア開発者が事業活動を理解し、その知識を使ってソフトウェアを作る
- 要件定義・仕様化・実装の継ぎ目をなくす
- ビジネスロジックを軸に組み立てる
- 値の種類（型）でモジュール化するで組み立てる
特徴
- コードに責任を持つソフトウェア開発者が、事業活動を学び、要件定義に主体的に関わる
- 要件定義手法として、要件の関係性・可視化・関係者の合意形成を重視したRDRA手法を使う
- ソフトウェアの仕様の記述に、プログラミング言語(Java)を使い、ツール(JIG)により可視化する
- アーキテクチャとして三層＋ドメインロジックを採用
- 実装技術としてSpring MVC, MyBatis, Thymeleafを使用
従来の開発手法との違いは以下の点です。
- ソフトウェア開発者が事業活動を理解することでソフトウェア開発の質とスピードをあげる
- ソフトウェア仕様の記述に自然言語ではなくプログラミング言語を使う
- ビジネスロジックに焦点を合わせる
- 型（値の種類）によるモジュール化
- 要件定義・仕様記述・実装を双方向でフィードバックしながら全体を段階的に発展させていく
ソフトウェア開発者が事業活動を理解することでソフトウェア開発の質とスピードをあげる
ソフトウェア開発者が事業活動を理解すればするほど、ソフトウェア開発の質があがり、開発のスピードが加速します。
ソフトウェア開発者が事業活動を理解していると、何をつくるべきかの意思疎通や詳細の確認のコストがいちじるしく低下します。 ソフトウェアに要求の取り違えや見落としが減り、確認作業や修正作業に多くの人手と時間をかける必要がなくなります。
事業活動の理解、特に、事業活動の進め方に形を与え一定の方向に制御するさまざまな決め事であるビジネスルールをソフトウェア開発者が理解すればするほど、ソフトウェアの質が安定し、開発のスピードがあがります。
仕様の記述にプログラミング言語を使う
CCSR手法は、ソフトウェア仕様の記述にプログラミング言語を使います。
従来のエクセルなどで大量のドキュメントを作成していくアプローチとは大きく異なります。
仕様記述にプログラミング言語を使うと、仕様と実装の継ぎ目はなくなります。
問題は、要件定義と仕様記述の継ぎ目をなくす方法です。
CCSRでは、要件定義手法のRDRAで可視化した要件をもとに、ソフトウェアの仕様をプログラミング言語で記述し、 仕様や設計のドキュメントは、ソースコードの記述内容から自動生成するアプローチを採用しています。
ビジネスロジックに焦点を合わせる
CCSRでは、ソフトウェアの要件定義と仕様を記述する時に、ビジネスロジックに焦点を合わせます。
ビジネスロジックは、ビジネスルールに基づく計算や判断のロジックです。
ビジネスルールは、事業活動の決め事や制約です。
要件定義と仕様の記述で、ビジネスロジックに焦点を合わせるということは、ビジネスルールに注目し、そのビジネスルールを発見し整理するために、開発者が事業活動を学び理解する活動を行うということです。
ビジネスロジックに焦点を合わせると、事業活動を進めるためのさまざまな決め事や制約と、ソフトウェアで表現する計算や判断のロジックが明確に対応します。つまり、要件定義と仕様記述の継ぎ目がなくなります。
型によるモジュール化
型とは値の種類です。
型によるモジュール化とは、ビジネスで関心のある値の種類（金額・数量・率・日付・日数など）ごとに、プログラム単位を分割するということです。
つまり、金額型や日付型というクラスを定義して、金額にかかわる計算判断のロジック、日付にかかわる計算判断のロジックをそれぞれのクラスにカプセル化する、オブジェクト指向プログラミングのアプローチのモジュール化です。
型（値の種類）によるモジュール化も、要件定義と仕様記述の継ぎ目をなくします。
ビジネスで関心のある値の種類を、そのまま型としてソフトウェアの仕様定義に使うからです。
型の定義は、ビジネスルールを記述するための基本の語彙になります。
型はクラスとして定義するので、仕様と実装の継ぎ目もなくなります。
型の仕様（外部から可能な操作）の定義とは、クラスのメソッドの定義です。
CCSR手法を実践する
要件定義・仕様化・実装の継ぎ目をなくすために、ビジネスロジックに焦点を合わせ、型によるモジュール化でプログラムを組み立てるCCSR手法を実践にあたって役に立つ技法・ツール・サンプルコードを紹介します。
CCSRを実現する技法とツール
仕様の記述をプログラミング言語で効果的に進めるために、CCSRでは次のような技法とツールを活用しています。
- 要件定義にRDRAを使うことで、整合性が担保され論理的な要件定義モデルが手に入る(仕様記述のインプットの質が高い)
- アプリケーション固有の型をどんどん定義（データの抽象化）して、仕様記述の語彙を増やす
- RDRAの要件モデルに直接的に対応する設計・実装パターンを用意する
- Javaで記述したソフトウェア仕様を図形表現で可視化したり一覧表にして確認できるツール(JIG)を活用する
- 要件定義・仕様の記述・実装の一連の活動を、ビジネスルールに焦点をあわせ、ビジネスロジックを軸にアプリケーションを組み立てていく
CCSRの実践例
RDRA 2.0 ハンドブック(Kindle Unlimited会員は 無償) で使われている「図書館システム」を、CCSR手法で仕様化・実装した具体例を、githubリポジトリに公開しています。
<2020.6.26追記>
この実装例を教材にしたチュートリアルが公開されました。
実装の内容を確認したり、ビジネスルールを変更してみるチュートリアルです。
図書館サンプルのチュートリアル
ビジネスロジック中心のアーキテクチャ
CCSRは、ビジネスロジックを中心にアプリケーションを組み立てる開発手法です。
ビジネスロジックの置き場所を独立させ、入出力の関心事から分離します。
ビジネスロジックをドメインオブジェクトで表現し、それを中心にアプリケーションを組み立てます。
ドメインオブジェクトと外部形式のマッピングの実装例も、githubに公開しています。
CCSR手法の改良と普及
CCSR手法は、さまざまアプリケーション開発で実際に使われ、改良を続けています。
また、ソフトウェア開発組織や技術者個人を対象に、ワークショップや学習の場を提供しています。
CCSR手法に興味があったり、体験してみたい方は、twitter( @masuda220 ) などで、お気軽にご連絡ください。
また、CCSR手法を使って実際に開発している現場に参加したい、とか、CCSRの手法やツールの改善活動に参加したいという方も大歓迎です。ぜひ、ご連絡ください。
参考資料
CCSR開発手法は、記事内に記述したgithubリポジトリ以外に、以下の情報も参考になります。
発展性を重視するソフトウェア開発の考え方
書籍:現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法
ブログ：ソフトウェアのもっとも重要な品質は発展性 (2020/4/5)
スライド：ドメイン駆動設計 15年の取り組みでわかったこと (2020/3/30)
要件定義手法 RDRA
YouTube：RDRA2.0のサンプルをJIGで実装してみたよ (2020/4/30)
