-shared-img-thumb-OMG151018150I9A1996_TP_V

会社の仕事で使うような情報システムは、たいてい複雑な仕様で作られています。そして、システムの動作で一部不都合な部分があって直したいと考えたとします。そのような状況では、「システムのこの不都合な動作は、仕様通りなのかそれともバグ(誤り)なのか」が議論になることがあります。

そして、その不都合な動作が仕様通りだった(ソフトウェアのバグでない)という場合に「それではこの仕様は、どのような背景で決まったのか」と追求を始めるエンジニアがいます。「ソフトウェアの現在の動作にはまず仕様があり、その仕様が採用されたのにはまたその背景が存在しているはずだ」と疑わないような人です。

「今のソフトウェアの動作を理解するために、まずその背景を理解する」というエンジニアの姿勢は、一見正しいように見えるかもしれません。しかし結論から言うと、たいていの場合は稼働中のソフトウェアの動作は仕様の背景にさかのぼって考えてもあまり意味がありません

ここでは、稼働中のソフトウェアについて「運用上、不都合のある動作の背景について考えること」に意味がない理由についてお話しします。また、実際にソフトウェアを修正する場合に何から始めていったら良いのかについてもお話ししていきます。

ここで述べる内容を理解することにより、稼働中のソフトウェアの不都合を最も効率的に修正するために必要な考え方が身に付きます。

システムの仕様書は、設計図面にすぎない

システムの仕様は、一般に「システム機能仕様書」(以降、単に仕様書と記述)に書かれます。しかし、仕様書はあくまで設計時の図面です。仕様書に、実際のソフトウェアの動作一つ一つまではまず書ききれません。そのため、ソフトウェアには仕様書に書いていない動作をする部分が必ずあります

それどころか、プログラムがすべて仕様書通りに動いているかどうかさえも実は怪しいのです(さすがに、全く仕様書と違う動きをするということはないでしょうが)。その理由は、機能仕様書の作成者が「システムのすべての動作を把握して仕様書に記述すること」は実質的に不可能だからです。

それほどまでに、今日のソフトウェアの構造は多岐にわたる技術の集合体になっていて複雑です。仕様書に記述がない部分については、「ソフトウェアテスト」(実際に近い環境でソフトウェアを動作させて検証すること)を行うしかありません。

ソフトウェアテストによって不具合が修正されたあとに、仕様書と不整合が発生しそのままとなることもあります。そうなれば、そのソフトウェアは仕様書と異なる動きをすることになるのです。

こうなると、「最終的なソフトウェアの動き」と「設計時の背景」とは結びつきが薄れ関連性がほぼなくなってきます。これが、ソフトウェアの動作に背景を考える意味がないと考える理由です。

ソフトウェアの動作に背景を考える意味がない理由は、他にもあります。たいていのソフトウェアは、複数の人が関わって作られています。例えば小規模のソフトウェア開発であっても、仕様作成担当のSEのAさん、アプリケーション開発担当エンジニアのBさんといった具合に「複数の人の分業になる」場合がほとんどです。

さらに、そのソフトウェア保守はシステム保守担当エンジニアのCさんが行い、一年後に担当者交代でエンジニアのDさんに引き継がれた……などということも普通に起こります。そのように複数の人で開発保守が行われたソフトウェアの動作は、もはや設計時の仕様書など参照されずその場の状況でどんどん修正されていってしまうことが珍しくありません。

つまりソフトウェアやシステムは、複数のエンジニアが関わりその人たちの「意識」「考え方」「思惑」の集合体である考えられます。こうなると、ソフトウェアの実際の動作に元の設計時の背景は残っていないのです。

このように、実際のプログラムの動作は、仕様書に書き表しきれない部分が数多くあります。仕様書は単なる設計図面であり、最終形のソフトウェアの動作を表していないと考えるべきです。それでは、ソフトウェアの動きが不自然でユーザーが困っており、修正したい場合どのようにして修正していくのがよいでしょうか。

ソフトウェアの実際の動作が、仕様であると考えるしかない

ソフトウェアの動きがどうもおかしいので修正したいという場合、最短の道は「今のソフトウェアの動きを基準にして、不都合な部分を直した場合に影響範囲はどうなるか。その影響で新たな不都合が出ないか」を確認することです。

ソフトウェアには、仕様書の他に「ソースコード」というものがあります。ソースコードは、開発者(プログラマー)が作成するプログラムそのものです。ソフトウェアのソースコードを読み、ソフトウェアの動作を修正したときの影響範囲を調べその修正が他に影響がないことを確認するのです。

すなわち、ソフトウェアの不具合は「仕様書や背景とは別のソースコードから得られる情報に基づき修正されている」のです。

このように、ソフトウェアが不自然な動きをするときに「その仕様の背景を考える」ことにあまり意味がありません。ソフトウェアは、実際の動作がすべてです。そのため、ソフトウェアを修正したいと考えたときはソースコードに集中してその対応を考えるのが最短の道であると言えます。