ことの経緯その１

はじめに

ここでは，ここまで書いてきた考え方をもつに至った経緯を記述します．言いかえれば，この文章は，それまでやってきたシステム開発への疑問や不満を書いたものです．

まずは当時，私，そして私の周りの人達が行っていたシステム開発のやり方を明かにします．

これまでのやり方

システム開発を生業とするようになって以降，私や私の周りの人達が行なっていたシステム開発のやり方は，以下の通りでした．

マン・マシンインタフェース（早い話が画面や帳表の形式）を決める．
上記で決めた画面や帳表を作りやすいように機能を分割．
画面からの検索時間や帳表の出力時間が最短になるようにテーブルを設計．
テーブルにデータを埋込み，画面や帳表にテーブルのデータを表示するプログラムを作成．

最初に画面や帳表の形式を決める意図は次のようなものでした．

ユーザが直接触る部分の仕様を早く決めることで，最終的な成果物の確認や操作方法に慣れてもらう．画面や帳票が決まれば，後はシステム内部のことなので，仕様が変化してもユーザに迷惑をかけることはない．

「画面からの検索時間や帳表の出力時間が最短になるようにテーブルを設計」すると，画面や帳票そっくりのテーブルができあがります．画面や帳票の形式そっくりのデータがすでにテーブルにあり，画面や帳票のプログラムはそれをただ表示・印刷するだけです．テーブルと画面・帳票の形式を合わせたり，計算したりする必要がないため，処理時間は短くなり，ユーザにストレスを与えません．もちろん，良く似たテーブルや同じ機能で使うテーブルは，処理時間に影響が出ない範囲で統合することもあります．

後は，これらのテーブルに必要なデータを埋込むプログラムを作れば，システムは完成です．

問題点

このやり方の問題点は三つあります．第一の問題点は，「画面や帳票への修正が，システム全体に大きな影響を与える」点です．

この手順，

画面や帳票の形式を決める．
画面や帳票を作りやすいように機能分割．
画面や帳票を作りやすいようにテーブルを設計．
テーブルにデータを入れるプログラム作成．

で作成したシステムの画面や帳表に修正が入ったとします．その修正は次のように波及します．

画面や帳票の形式に修正を加える．
画面や帳票を作りやすいように分割していた機能にも修正が発生．
画面や帳票を作りやすいように設計していたテーブルにも修正が発正．
テーブルにデータを入れるプログラムにも修正が発正．

システムの構成要素全てに修正が波及していきます．システム開発の後半にこのような修正が入ったら・・・．考えただけでもぞっとします．

このような大々的な修正を行うことはまず不可能です．多くの場合，修正に伴う波及を途中で止めることになります．例えば，機能分割とテーブル設計の間で修正を止め，機能分割は修正しテーブルは修正しなかったらどうなるでしょう．

画面や帳票の形式に修正を加える．
画面や帳票を作りやすいように分割していた機能にも修正が発生．
画面や帳票を作りやすいように設計していたテーブルは修正しない．
テーブルにデータを入れるプログラムには修正は発正しない．

この場合，テーブルとその元となっている画面や帳票の形式に齟齬が発生します．そこにあるのは，修正前の画面や帳票が作りやすいテーブルであって，修正後の画面や帳票が作りやすいテーブルではありません．「画面や帳票を作りやすいようにテーブルを作る」という前提が崩壊しています．この結果，「画面や帳票を作りやすいようにテーブルを作ると言う前提でできた，画面や帳票を作りにくいテーブル」のできあがです．

いったん決めた画面や帳票が変らなければこのような問題は発生しません．しかし，いったん決めた画面や帳票がシステム開発の中で変らなかったという経験は一度もありません．

「システム開発とはそう言うものだよ」と良く聞かされましたが，そう言うものなのでしょうか．

もう一つの問題点です．画面や帳票と同じテーブルをただ闇雲に作った結果，異なる名称で同じものを差す項目や同じ名称で異なるものを差す項目がテーブルのあちこちに散在します．

顧客別販売実績確認テーブルにある販売価格と月別売上実績集計テーブルにある売上価格は同じものなのか違うものなのか，支店別必要経費管理テーブルにある売上高と支店別売上実績進捗確認テーブルにある売上高は同じものなのか違うものなのか，誰も全く注意を払いません．その結果，テストになって問題が発生します．同じ項目のはずなのに違う値が入っている，逆に，違う項目のはずなのに同じ値が入っていることが明らかになります．それからは，本来予定していた「テスト」は「値の整合性を確認するためのテスト」に擦替ります．そして，値の整合性が確認し終わった時，本来のテストとは無関係にテストが終了していました．

「テストとはそう言うものだよ」と良く聞かされましたが，そう言うものなのでしょうか．

最後の問題は維持管理で発生します．システム開発に携った人がそのまま維持管理をやっている間は，問題点は明らかになりません．画面や帳票とテーブルの間に存在する不整合の理由を知っているからです．では，その開発に携っていない人が維持管理を行うことになったら，どんなことになるでしょうか．目の前にあるのは，知っているシステム開発の知識「まず画面や帳票を決め，それらを作りやすいように機能分割やテーブル設計を行う」では理解できないシステムです．すなわち「画面や帳票を作るには不便なテーブル」です．そんな形になっている理由は全くわかりません．別のテーブルにも良く似た項目があります．しかし，そのテーブルではなく，このテーブルの項目からデータを取出している理由がわかりません．理由を知ろうと思えば，過去のシステム開発の資料を読みなおし，修正の経緯を一つ一つ追っていく必要があります．えてして，資料は残っていないものです．その場合は，開発当時のメンバに聞いて回ることになります．覚えていてくれれば良いのですが・・・．

「維持管理とはそう言うものだよ」と良く聞かされましたが，そう言うものなのでしょうか．

問題点への対処方法

これらの問題点については，当時も対処法を検討していました．その内容はこんなものでした．

画面や帳票については，システム開発の早期に客先と綿密な確認を行い，変更の発生を防ぐ．
画面や帳票の修正がシステム全体に与える影響の大きさを，客先にも理解してもらう．
いったん決めた画面や帳票の修正には応じない．
画面や帳票の修正には適切な納期の延長や追加料金を要求する．
仕様変更があった場合は，設計書の修正をきちんと行う．
テストには十分な時間を取る．

疑問

私も最初はこの考えでした．「切羽詰まっての修正が多すぎる．もう少しシステム開発の大変さをわかってくれ」という気持ちでした．そして，できるだけ早い時期に，画面や帳票の形式を決めようとしました．そして，客先と衝突もしました．

ある時，ふと思いました．システム開発の早期に客先とどれだけ綿密な確認を行っても，画面や帳票を決めることは不可能なのではないのか，と．確認しようにも，客先・開発側どちらにも判断に足る材料がないのです．

新規開発の場合は「まだよくわからないけど，そんな感じで良いんじゃないのかな」，現行システムの再開発の場合は「とりあえず今と同じで良いや」という判断がせいぜいです．そんな状態で決めた仕様を元に開発を進めてはまずいのではないか，というもやもやとした考えが胸の中にわいてきました．「ちゃんとハンコもある．あなたも確認したはずだ」そんなことを盾に客先と喧嘩をして，一体何になるのでしょう．

また，問題点への対処方法とした考え方は，「システム開発のやり方に問題はない．納期や予算がが逼迫するのは，いったん決めたことを途中で変えた客先に問題がある．したがって，客先が考え方を変え，こちらの都合に合わせるべきだ」と，あまりにも身勝手なものだったのではないでしょうか．

そう思いながら，やっとここまでたどり着きました．

「設計書の修正をきちんと行う」や「テストには十分な時間を取る」というのは，果たして対処法と言えるのかどうかについてはここでは触れません．

周囲の反応

当時勤めていた会社で，システム開発の方向性を決める権限を持っている上司に向って，私の考え方の実践の場を求めました．それに対する反応です．良し悪しを言うつもりではなく，異なる考え方もあったということです．参考までにどうぞ．

客先からはそう言う設計をしてくれとは言われていない．客先の言う通りにシステムを構築するのが私達の仕事だ．
客先からそのような話がない以上，こちらから提案をするわけにはいかない．
君にそんな力は期待していない．
これまでと違うやり方をするからスケジュールが遅れるのだ．
これまでのやり方で何一つ問題は出ていないのだから，これまでのやり方を改める必要はない．
そんなことは常識だ．普通そうやるのだ．
「なぜ」とか「どうして」ではなく「そういうものだ」と思え．
開発標準と違う．

参考文献

林衛, "データ中心設計のためのERモデル・システム分析／設計法", ソフトリサーチセンター 1993

C J. Date "An Introduction to Database System 3rd Edition" Addison-Wesley 1975
（藤原譲 "データベースシステム概論" 丸善 1985）

Tom DeMarco "Structured Analysis and System Specification" 1979
（高梨智弘，黒田純一郎監訳 "構造化分析とシステム仕様" 日経BP出版センター）

Audrey M. Weaver "USING THE STRUCTUAED TECHNIQUES A Case Study" Prentice-Hall, Inc. 1987
（神間清展訳 "構造化技法を使いこなす" 総研出版 1989）

Brenda Laurel, "Computer as Theatre", Addison-Wesley Publishing Company, 1993
遠山峻征, "劇場としてのコンピュータ", トッパン, 1993

奥井規晶，岩宮伸幸 "クライアント/サーバソフトウェア開発" リックテレコム

James Martin, Joe Leben "Strategic Information Planning Methodologies 2nd Edition" Prentice-Hall, Inc 1989
（坂本広，山崎五郎 "Ｊ．マーチンの情報システム計画方法論" 日経BP社）

Arthur Young Information Technology Group "The Arthur Young practical guide to information engineering" Arthur Young & Company 1987
（高梨智弘，竹本則彦 "管理職のためのインフォメーションエンジニアリング" 日経BP社）

Alfred V. Aho, John E. Hopcroft, Jeffrey D. Ullman "Data Structures and Algorithms" Addison-Wesley Publishing, 1983
（大野義夫，データ構造とアルゴリズム，培風館，1987）

Niklaus Wirth, "ALGORITHMS AND DATA STRUCTURES", Prentice-Hall, 1986
（浦昭二國府方久史，アルゴリズムとデータ構造，近代科学社，1990）

近藤嘉雪，Ｃプログラマのためのアルゴリズムとデータ構造，ソフトバンク，1992

Roger Sessions, "Class Construction in C and C++", Prentice-Hall, 1992
（石川克己，C/C++クラスの構築法，トッパン，1993）

岡田英明, "システム部門再生講座", 戦略コンピュータ ,1994年10月号 Vol.33 No.10 p.50- 日刊工業新聞社

日経オープンシステム 1994年10月号 no.19 p.285-296
"AccessとVBユーザのためのDB設計入門（Ｉ）"

日経オープンシステム 1994年11月号 no.20 p.249-260
"AccessとVBユーザのためのDB設計入門（II）"