変更の周波数

SYNOPSIS

ソフトウェアの変更は、そのソフトウェアに関わる人間の活動によって発生する。人間の活動には周期があり、その周期によって発生する変更の内容も変わってくる。変更は種類に応じて周波数を持つことになるので、その周波数をソフトウェアの設計で考慮することで、「変更を予測」せずとも、変更に強い設計が得られる。

ソフトウェアには変更がつきものです。変更には、画面のデザイン修正や、項目の追加変更、ビジネスロジックの変化や、フレームワークの改修、サーバーのパッチなど様々なものがあります。これらの変更の種類によって、発生しやすいものと発生しにくいものがあります。ユーザーインターフェースの変更は頻繁にあっても、データベーススキーマの変更はそんなに起きませんし、ミドルウェアのAPIが変わるのはさらに稀でしょう。

さて、変更が起きる要因を考えてみると、ソフトウェアの内外に存在する問題に起因することがわかります。変更の発生は人間の活動と同期しています。特にソフトウェア外部に起因する場合には明らかですが、ソフトウェア内部の問題であっても、それを発見するのは人間の活動です。

バグ
- プログラムに内在するバグは、利用者や追加機能の開発者などによって発見されます。いつでも発生する可能性がありますが、発生する頻度は、時間とともにゆっくり低下していきます。利用しているプロダクトのセキュリティパッチなども、いつ公開されるかわかりません。
利用者からの要望
- ソフトウェアを利用しているユーザーが、使いにくい部分や、追加してほしい機能などを発見します。明らかなバグを除くと、使用期間が1週間〜1ヶ月程度で発生し始めます。毎日使う機能では早いタイミングで、頻繁に起きますし、めったに使わない機能(たとえば期末決算処理など)では、それを使うタイミングで起きます。
組織的・経営的な要望
- システムに対する大規模な機能追加や、パッケージソフトウェアのメジャーバージョンアップ、ハードウェアの入れ替えなどは、組織的な事情(典型的には会計年度を区切りとする予算取り)や経営的判断(パッケージの販売戦略や、ビジネスの事業改革など)により発生します。

さらに、変更のきっかけが発生しても、それが直ちに変更作業に結びつくとは限りません。ソフトウェアの性質や体制や組織によって、変更を実施するタイミングを制御している場合があります。

変更の起きるタイミングが人間の活動に依存し、かつ変更の種類と活動の種類が関連することから、「どんな変更が、どんなタイミングで」発生するかがあるていど見当がつけられることになります。具体的にいつ発生する、という予測にはなりませんが、どのくらいの頻度で発生するかを想定することができます。すなわち、人間の活動には周期があり、それに応じて(毎回ではないにせよ)活動のたびに変更が発生する、その周期も予測できるわけです。これを変更の周波数と呼びたいと思います。

設計で変更に対策する

ところで、ソフトウエアを作るときのことを考えてみましょう。いずれの変更も長い目で見ればいつか起きるものと考えると、ソフトウェアを作るときにはそれらの変更を考慮しておく必要があります。変更に対する対策は、3つあります。

無視する。「変更できない！」と言い張ることになります。作り直すこともあります。
事前に対応しておく。「きっとこういう変更が起きるから…」という対応策を設計に組み込みます。
起きてから対応する。「変化に強い」設計を、リファクタリングなどの手法で維持しておきます。

いずれも、コストとメリットとを勘案して選択すべき、有効なオプションです。

ソフトウエアへの変更の内容は千差万別ですが、対象となる機能、コンポーネント、レイヤーなどから整理することができます。また上記の2.の対策も、どこに対するどんな変更かを事前に整理しておくことが前提となります。3.の対策も、どの部分を「変化に強く」しておくかという判別は必要です。

したがって、具体的にどんな変更があるかは予測できなくても、どんな種類の変更がどこの部分に発生するかがわかっていると、変更に対する戦略を事前に立てること(上記の1〜3を選んでおくこと)が可能になります。

変更の周波数と設計のシンクロ

変更の種類ごとに周波数があり、その変更で影響を受けるソフトウェアがあるとき、ソフトウェアの側が変更の周波数にシンクロできると、うまく変更に対応していくことができます。つまり細かいビートでやってくる変更によって影響を受ける部分と、大きなうねりでやってくる変更で影響する部分とを、設計的に分離しておくのです。片方が揺れても、もう片側は動かない。

実際には2種類ではなくもっと多くの種類の周波数が存在するので、設計もそれに応じて細分化されます。また、変更は伝播せざるを得ない場合もあるので、そうした変更は影響範囲が大きいものとしてあえて大きなかたまりで受けることになります(たとえば、入力項目の移動程度であれば2画面ぶんのテンプレートの変更だけで済むが、データベースのテーブルに項目が増えた場合は、関連する画面、ドメイン、パーシステンスなどに広く影響が及ぶ)。

ソフトウェアを作る側では、変更があるものとして設計することはできても、将来実際にどんな変更があるかを予測するのは困難です。変更の要因となる人間活動をもとにして、作るソフトウェアの変更の周波数を考慮することで、変更に対してより適切に対応できる設計を実現できる可能性があります。「リズムに乗る」わけです。

課題

どんな種類の変更がどんな周波数を持つのか、具体的かつ納得のある説明ができないと説得力がない。
変更の周波数を予測することが、単に変更を予測することよりも優れているという理由付けが必要。
変更の周波数がわかれば設計が向上することの説明(これはわりと自明ではないだろうか)。
アーキテクチャ的に、下層のレイヤーは信頼するものと考えることが多いが、変更の周波数を考えるとOSなんてずいぶん高周波成分を持つようになってしまっている。影響範囲が小さいから問題ではないが。