[TiDD] 制約による高品質ソフトウェアの開発

以前、「ある種の制約は自由を増やす」というまつもとゆきひろさんのRuby on Railsに関するコメントを紹介しました。実は、ソフトウェア工学の歴史を振り返ると、ソフトウェア開発に制約を与えることで高品質なソフトウェアの開発を実現してきたと思います。

高品質といってもその特性は時代と共に変化してきました。

(1) 高機能の追求

ソフトウェア危機が叫ばれた1980年代から、大規模ソフトウェアをどのように開発するかが議論されました。解決法として考えられたのは、プログラムに論理的構造という制約を与えることです。

古くは構造化プログラミングがそれにあたります。GOTO文を禁止し、IF、WHILEなどという構造化が容易な制御文のみでプログラムを書くことで理解が容易になり、高機能なプログラムの実現が容易になりました。

これはその後、プログラムを一定規模のモジュールに分割する、システムを組み合わせるといったシステムの構造に対する制約につながりました。一方、スパイラルモデルを始めとする時間軸の分割、すなわち段階的な開発も行われました。

さらにアジャイル開発の時代になると、タイムボックスという制約が加えられて一定の時間に収まる機能に開発対象のスコープを制限するようになり、管理の容易な単位の開発を組み合わせて高機能なソフトウェアを開発するようになりました。

(2) 高信頼性の追及

信頼性はソフトウェア工学の主な課題の一つでしたが、高機能ソフトウェアが開発されるようになると、より注目されるようになりました。

1980年代には、各種のチェックリストのほか、テスト技術としてドライバ、スタブ、カバレージ等の技術が開発されました。

やがて、1990年前後の開発標準やプロセス改善の時代になると、定量的なデータを蓄積して、品質が管理されるようになりました。テスト項目数のほか、レビューやテストにおける不具合の件数に制約をつけることで、安定した品質のソフトウェアが開発できるようになりました。

さらにアジャイル開発の時代になると、ペアプログラミングやテスト駆動開発という新しい制約によって、バグを作りこまない開発が行われるようになりました。

(3) 顧客満足度の追求

高機能で高信頼性のシステムが構築できるようになると、使いやすいユーザインタフェースや社会変化に対応した顧客満足度の高いシステムが求められるようになりました。

顧客による確認を行うために、レビューやインスペクションというプロセスの制約によって、顧客満足度が高められました。

また、ユーザインタフェースに関しては、プロトタイピングやアジャイル開発のようにものづくりを優先するという制約によって、使いやすいシステムの開発が行われるようになりました。

社会の変化に関しては、繰り返し開発によって変化を受け入れられるようになりました。この実現方法には2つの方式がありました。一つは、変化を厳密に管理するという制約です。ウォーターフォール開発を基本とする場合に行われます。

もう一つは、変化を受け入れた上で要件を実現するというものです。前述のプロトタイピングやアジャイル開発のように、変化することを前提として限界に達するまで仕様を凍結しないという制約です。

これらに共通するのは、混乱状態を整理し、パターン化して制約を与えることで、混乱からリズム(テンポの良い開発あるいはスタイル)に変えていることです。

次回は、この制約という観点で、チケット駆動開発を考えてみる予定です(少し先になるかもしれません)。