横山実習室へ戻る

システムの理解

1.問題提起

  プログラミングの経験もない学生に、座学でシステムの講義をしても
 理解できるはずがない。
  知識としてのシステムとはの話は書籍でいくらでもある。
  プログラム技術として、10行程度の独立した問題を解かせるのは、言語と
 アルゴリズムの教育で、こことりあげるシステムの理解ではない。
  現実のシステムはプログラムの世界では、1000行より少ないものは
 まずない。
  例題として短いものを作成しても、100行に満たないようなものは
 システムとは呼べないであろう
私の先生は、自然対数のてい e を1000桁 を求め る問題を3行で書ける
 といったが、実際に正しい答えは存在する
 でもこのような問題を解いてもシステムが理解できるわけではない

2.システム開発の技術

  実際にシステムを開発している現場では、何万行、何百万行にもなる、ほとんど全体
 を隅々まで理解することは不可能なプログラムを何人もの技術者が協力して開発していて
 誰も自分が分担している部分以外は詳細には理解できない状況にある。
  このようなものを、普通はシステムといっている。
  このようなシステムの開発を実際に体験すれば、システムの難しさはほとんどの人が  理解できる。
  近代の工場労働者は機械の歯車で、働きがいがないと云われたが、システムで働く
 労働者は歯車ではない、それは誰かが事故で欠けた場合、代わりのできるひとは存在
 せず、その部分は時間をかけて最初からやり直すしかないからである。
  現実には、この方法ではシステムの完成を決められた期間で完成できないので
 なんとか他人が途中からでも引き継いで開発できるようにする、各種のシステム開発
 の技術が工夫され使用されてきているのである。

3.システム開発を体験させる教育


  システムとはなにか、システム開発の難しさ、システム開発技術の必要性を理解させる
 ためには、ある程度(少なくとも300行以上)の大きさを持つ、プログラムを開発
 させる必要がある
  このような規模のプログラムになると、教師は問題が発生してもどこが原因かは指導
 することは困難であるが、学生は時間をかけて自分で原因を追求することで、システム
 開発の本質を理解することができるようになる
  学生に理解させたいシステム開発の本質は、以下のようなものである
  ・ 問題の原因は自分で発見し解決しなければならない
  ・ 問題を起こさないためには、注意深く、個別の命令が正しく動作しているか
    確認する必要がある
  ・ システム開発技術を駆使して開発しないと短期間で完成しない
  ・ 問題の原因究明は試行錯誤では不可能で、論理的な因果関係から推測する手法
    が不可欠である
  ・ 問題の論理的な因果関係で推測するには、客観的な事実の把握が重要で、探偵
    物語とまったく同じ論理により原因を推測することになる


自分はどのようにして育ってきたか



システムのプロとして多くのシステムを手がけ、成功に導いてきたが、最初から実力が
あった訳がない。ここで、自分はどのようにして育ってきたかを述べることは、初心者が
システムを理解するのに役立つと思う。


地銀協為替オンラインシステム


大学を卒業して(電気工学)2年目、当時は正直にいって何もわかっていなかった。
コンピュータ業界もまだ存在しない時代、富士通で配属された課は「システム課」で
テレタイプの交換機をコンピュータで実現するのが仕事で、技術者は20人ぐらいいたが、
3つのシステムを開発中で、ユーザ先へ行ったきりで、先輩から技術を学べるような
状態ではなかった。
この頃のコンピュータは一つのプログラムが動作するだけで OS も存在しないで、
たとえば 入出力装置で読み取りエラーが発生したら、その命令で機械は停止する
とゆうような、状態であった。
テレタイプの交換機を実現するためには、複数の回線につながった入出力装置が並列に
動作し、たとえどこかの装置でエラーが発生しても、全体が停止することなく、
エラーが発生した部分のみの停止ですむようなシステムにすることが必要であった。
このような機能をもったコンピュータがようやくできたばかりで、プログラムを並列に
動作させる仕組みのOSに相当する部分も個別のユーザで作成する必要があった。
コンピュータの中心の装置 CPU が故障した時には、一時全体が停止してもやむおえない が、
代わりのCPUと切り替えて、続きの仕事を再開する必要があり、何時もなにもない
最初の状態からスタートするシステムでは不十分だった。
このようなことが、この頃のオンラインシステムに要求される主な機能であった。
地銀協為替オンラインシステムは、銀行間で金の送金(振込み、取り立て)などを
行うもので、テレタイプにない以下のメリットがあった。
・コンピュータで金額を集計できるので、銀行間では集計された金額での貸借の
清算ができる。
・プログラムで金額のチェック(二重に書く)ができるので、銀行間の取引の信頼性
に耐えられる。
このシステムの開発メンバーとして設計とプログラミングを担当したが、当時はほんの
数人の経験者を除いて誰も技術が無かったので、プログラムが組めるだけで技術者と
して活躍できた。
このプロジェクトではNTTと富士通の多くの人と共同で働いた。
プロジェクトを効率よく快適に推進するコツは、
・自分のプログラムで実現できることは自分のプログラムで実現した方が他人の負荷
が減るのはもちろんであるが、意外にも自分の負荷も減るのに気づいた。
・機能を他人に押し付けると自分は楽になるのが、世間の常識だが、コンピュータの
世界ではこれが逆になる。
・プログラム間では機能分担はどうも最初から自然に最適なものが決まっていて、この
事実に反する分担は、両方の作業が困難になり、ついには破綻する。
・たとえば、共通サブルーチンでチェックできることを、さぼって依頼側で正しいデータ
であることを義務ずけると、テスト段階でエラーが発生した時、原因の発見が遅れ、
何倍ものテスト時間が増えて両方で苦しむことになる。
このように、コンピュータの世界は一般の常識が通用しないとゆう教訓を得た。

ブルガリア資源供給省システム


この頃のブルガリアは共産主義国で何事も国家で計画し、経済もその通り運用する
のが原則であった。
国中の工場の生産計画をすべて、コンピュータで立てようとするプロジェクトであった。
各工場の生産予定とそれに必要な材料の量を全国の工場からオンラインで集め、
どの工場からどの工場へ何の材料を何トン何日に輸送するか計算させようとゆう、
システムであった。
正直いって、当時の計算機にできる量の計算ではなかった。
システム設計するとゆうことは、プログラムを作成するための、ロジックを考える
ことのように考えるかも知れないが、実際の設計では、必要な処理能力や、メモリ容量
や、ファイル容量を見積もることが重要な設計である。
建築の世界でビルディングを設計するとすれば、柱、壁、床など強度は地震にも耐え
られるかどうか計算しなければならない。
コンピュータのシステムを設計するときも、同様に計算をして1日のデータ量を24時間
で処理できるか、たしかめなければならない。
このシステムでは、このような計算を行うところから指導し、このシステムの目標は
絶対に実現不可能であることを数字で説明して、顧客も了解したところで、改めて目標
を修正し実現可能なものにするところから始めた。
処理能力や、メモリ容量の計算はソフトウエアの実現方法で大幅に変わるので正確には
計算できないが、誤差はあっても計算により実現の可能性を大雑把に知ることが大事
である、






地相銀CDネットワークシステム


都市銀行が公共のスペースにCD(現金自動支払機)を設置し共同利用することにより
ユーザの利便をよくし、利用コストも抑えるシステムを計画した。
地方銀行、相互銀行もこの計画に入りたくて都市銀行に相談したが、規模が異なるので
システムのバランスが悪い、複数の地方銀行を一つの都市銀行に見立てるような
サブセンタを作ればシステムに加えてもよいとゆう条件がでてきた。
地方銀行、相互銀行としては遅れてスタートしたにもかかわらず、サブセンタを立ち上げる
余計な時間を取られることとなったが、これに乗り遅れるわけにいかないので、突貫工事
を覚悟で富士通に依頼がきて、ブルガリアから帰ったばかりの私に設計開発が回ってきた。
都市銀行のシステムはNTTが受注し設計し、開発は富士通が委託されていた。
このシステムの特徴は以下のとおり。
・CD(現金自動支払機)は各銀行ですでに実用化されていた。
・ただし、銀行内システムなので、CDの故障、センタの故障などで正常に支払いができ
なかった時はその状態を人手で調べて対応する。
・元帳ファイルからすでに残高を引き落としていれば、残高を元に戻す方式であった。
・この共同利用システムでは、銀行間で運用するので自動化をすすめる必要がある。
・故障時の扱いはセンタでは統一手続きで行い、元帳ファイルの整合性は各銀行それ
ぞれのやり方で行うようにする必要があった。
NTTがこの基本設計をしたが、大変良くできていて、途中にサブセンタを入れても統一
運用ができるインターフェースを設計していた。
このシステムの開発からは、多くのシステム設計、開発に有効な示唆を得た。
・自動化できる機能、人手に頼る機能、銀行間で統一しなけてばならない機能、個別の
銀行の事情で統一できない機能、これらを明確に切り分けあいまいな点は残さない。
・インターフェースのどちらで何を行えば良いかは、おのずから最適なものが決まって
いて、押し付けあいではないことをすでに、前システムの経験で感じていたが、
このシステムではNTTの設計で見事に実現していた。
・多くのシステムをつなぐ時、最も重要なことはテストを充分に行うことである。
このことは、皆解っているが、現実になると、つらい仕事の連続でつい省略しがちである。
・NTTは最初から各銀行との接続は、スケジュールから割り当られる時間を各銀行に示し、
各行でこの時間内に合格しない銀行は、一時稼動に入れないと決めた。
・これにより、各銀行は競争でテストし、最初からテスト時間の割り当てを増やしてくれる
ようにNTTに相談に来る状態であった。
・NTTは事前に詳細なテスト項目を示し、テストを効率的に行うためのテスト専用の
プログラムを用意して、テスト作業を自動化した。
・開発の効率化は作るプログラムの量を減らすことではなく、全システムの完成にかか
る工数を最小にすることであり、このために自分の開発量を増やすべきところは増やす
英断を示した。
・結果として1行の落伍もなしに予定期日に完了し見事な采配であった。
・サブセンタとしても同等以上のテストプログラムを作成し、采配のしかたも見ならって
当初予想された困難も乗り越えて見事、都市銀行と同時の稼動に間に合わせた。


群馬銀行総合オンラインシステム


30代も半ばになり、かなり経験も積み自信もでてきていたが、今から思えば未だ
未熟な時期であった。
このシステムの課題は、銀行のオンラインシステムも取引の多い業務だけのシステム
からすべての業務を扱うシステムに展開する時期に当り、
開発しなければならないプログラムの量が従来に比較して圧倒的に多くなる点である。
都市銀行においては4000人月程度の工数を投入して開発したものと同等の業務
を半分の2000人月以下で開発する必要があるので、開発の効率化が最優先の課題
であった。
この課題にたいする一般的な対策は
‥垰垓箙圓箸琉磴い肪緻椶掘対象業務を減らす
▲廛蹈哀薀爐旅渋い肪緻椶掘開発する量を減らす。
9盖藐生譟開発技術を駆使し、生産性を向上させる。
ぅ廛蹈献Дト管理技術により、生産性を向上させる。
である。
丁度この頃、業界では構造化設計、ストラクチャードプログラミング、HIPOなど
ソフトウエアの生産性向上をめざす手法が次々と発表され、その効果を競争して
いる状況であった。
上記の一般的な対策の中で、このシステムでは△紡个靴峠電静に工夫をこらし
・銀行の専用端末に対する出力の編集を行う方式として、仮想端末の構想により
大幅なプログラム記述量を削減し
・階層型データベースのアクセスに対し、ダイレクトアクセスイメージで使用できる
アクセスルーチンを提供し、プログラミングを簡易化し
生産性を大幅に改善したことである。
仮想端末は銀行専用端末が旧型と新型で同じ帳票に同じ内容を印字するのに、別々に
しかも、それぞれの端末特有のファンクション記号を使ってプログラムを記述する
方式から、共通の仮想端末インターフェースを定義し、汎用プリンタに印字するのと
同等の編集でどちらの端末でも出力可能にしたものである。
データベースアクセスは階層型であるため親子のチェーンを意識してアクセスする方式
からリレーショナルデータベースアクセスのように必要なキーを指定すれば、ダイレクト
に必要なレコードが得られる方式にしたものである。
この方式により、開発の効率化は予定通り改善され、開発期間、開発工数の面からも
画期的なプロジェクトと評価された。
仮想端末もデータベースアクセスも銀行と富士通との作業分担では不明確な部分で
あり、全体の効率化を目指した考察からのみ着目されるものであった。


銀行業務記述言語BAGLESS


地方銀行の大手までは、何とか総合オンラインシステムを開発できる資金力を持つ
が、その下位銀行、更には信用金庫、信用組合など小規模の金融機関では資金力
から考えても、投入できる開発工数からみても、独自の総合オンラインシステム
を開発する力はない。
富士通ではこの点に着目しすでに銀行業務のプログラムを組み込んだパッケージ
として、APFS と名づけたシステムを発売し、ユーザを拡大しつつあったが、
総合オンラインの時代になり、業務の量も大幅に増加し、業務内容も本質はどこの
銀行も同じであるが、帳票の形式、銀行専用端末など個別の銀行毎に異なる部分
も多く、パッケージに個別の銀行に合わせた修正を行う作業(カスタマイズ)が
間に合わない状況になってきていた。
このシステムを活性化して拡販すべく、新たな企画をするプロジェクトを担当する
ことになった。
システムの解決すべき目標を以下のように設定した。
〜躪腑ンラインのシステム(APFS改)を1ユーザに適用する修正工数を500人月
以下とする。
追加業務を容易に拡大できるようにするため、先行する銀行で開発したプログラム
がそのまま、パッケージとして後発のユーザに提供できること。
6箙埓賤冀舎がレベルアップしても、業務パッケージはそのまま提供できること。
これらを実現する技術は、群馬銀行で実証済みの
・仮想端末の方式
・データベースのアクセス方式
に加えて、
・日本語ドキュメントとプログラムの一体化(BAGLESS言語)
を新たに実現した。
銀行業務システムを他の銀行に提供し適用するには、プログラムと完全に一致する
ドキュメントが提供されることが必須である。
BAGLESS言語は日本語でデシジョンテーブルの様式で記述すれば、COBOL言語の
プログラムを自動生成するもので、銀行業務開発の経験から必要な標準化を言語
のレベルで完全に吸収しているので、一般的な自由度はないが銀行のオンライン
に特有の銀行専用端末(仮想端末)、データベース構造とアクセスルーチンの
インターフェースを内部に持ち込んでいるので、誰でも誤り無く同質の良好な
プログラムを作ることができるようになった。
20年以上経過した現在でも、多くの銀行で継続して使用されている事実からも
当時の技術の集積であり、設定した目標も正しかったといえる。


オブジェクト指向言語



BAGLESS言語以降も多くのプロジェクトに参加して、言語も第4世代言語とよばれる
言語も各種経験してきたが、大規模のプロジェクトではソフトウエアの生産性は
なかなか向上せず現在にいたっている。
ソフトウエアの生産性はプログラムを作りやすく簡易な命令にしてもあまり効果
がないのはなぜか。
 .愁侫肇Ε┘△論気靴だ澤廚罵想的な開発環境にすれば、ある程度短い期間
  で開発できるが、正しい動作を保証するには多くのテストを行い結果を
  評価する意外にない。
◆\気靴て虻遒鮓‐擇任るのはシステムの利用者のみであり、開発のプロは
  業務の知識を充分にもたないので、検証には不向きである。
 ソフトウエアの開発はコスト高なので、既存のソフトを利用するのが良い
  という人もいるが、現実には企業は競争することで他社より効率的な
  システムで企業価値を高めようと考えるので独自のソフトは必要である。
このような問題からソフトウエアの生産性の向上はあまり期待できない。


2006年を迎えて


少し飛躍した考えであるかも知れないが、生物はすぐれたコンピュータであり。
視覚機能、聴覚機能、運動能力どれを取っても現在のコンピュータではとても
立ち打ちできない。
これらの機能の元は細胞であり、細胞ひとつを取っても大変に小さいが高度に
独立して機能しているように見える。
細胞の機能は担当する機能により、分化しているが、ひとつの機能をみればかなり
汎用的で多くの同種の細胞が協力して高度の機能を実現すべく巧妙に連携している。
コンピュータのソフトもこのように巧妙に連携するように作れないであろうか。
オブジェクト指向言語の画面上の部品は、従来のサブルーチン構造の部品に比べ
なんとなくこのような細胞に近づいてきているようにも思える。
少し具体的に考えるために、整数データを扱う部品の機能を新たに仮定し、その
部品の機能を考えてみる。
 .如璽燭鯤飮する void set(int n); int get();
◆.如璽燭鯤儡稿力する void set(String s,String フォーマット);
 データを編集出力する String get(String フォーマット);
このような機能は現在のオブジェクト指向言語の範囲である。
この部品の物足りない点は、すべて受動的で、これらの部品を集めても何も
起こらない。
自分から、データをもらう部品を探しだし、出力する部品も探し出すように
できないか。
更に自分で探した相手が正しいかどうかを確認するにはどうするか、良い結果
なら何かアメがあり、結果が悪い時はムチのようなインターフェースで自動的
に正しい結果が得られるようにできないか。
このような機能はオブジェクト指向言語で実現できるか、
これから、こんな夢のようなプログラミングを作って見たいが、時間は充分に
あるが、私自身生物であり、環境としてこの問題解決にアメもムチも無いので
多分自己実現の機能がアメとムチを与えてこの文章を書かしたと思うが、
実現に向けての活動は、ほとんど期待できないであろう。
悪い初夢をみたものだ。

バッチ処理のパッケージ(JAVA)


プロセスフローを書いて、システムを作成する、バッチ処理は古い技術であるが
単純でわかりやすい。
現在はデータを大量に処理するバッチ処理は特殊な場合を除き無くなったかも
しれない。
データは全てデータベースに格納し、必要なとき必要な部分のみ取り出す処理は
使うかどうか解らない大量の印刷物を、あらかじめ印刷しておくバッチ処理より
無駄がない。
このような現実はおいておいて、とりあえず勉強のためにバッチ処理用のJava
パッケージを試作してみた。
バッチ処理のパッケージ(JAVA)ダウンロード
import batch.*;

public class Test001 extends List{
SeqFile inf=new SeqFile("test01.txt",'i');
SeqFile outf=new SeqFile("out01.txt",'o');
public Test001(){
Item[] items0=new Item[]{
new Item("大分類","xx"),
new Item("小分類","xx"),
new Item("通番","999"),
new Item("製品名","xxxxxxxxxxxxxxxxxxxx"),
new Item("原価","999.9"),
new Item("数量","9999")
};
inf.setItem(items0);
Item[] items1=new Item[]{
new Item("大分類"," xx "),
new Item("小分類"," xx "),
new Item("通番"," 999 "),
new Item("製品名"," xxxxxxxxxxxxxxxxxxxx "),
new Item("原価"," z99.9 "),
new Item("数量"," z999 "),
new Item("金額"," zzz,zzz,zz9.9 "),
};
outf.setItem(items1);
setItemLink(outf,inf);
outf.setBreak(new String[]{"大分類","小分類"});
outf.setTotal(new String[]{"大分類","小分類","金額","小計"});
outf.setTotal(new String[]{"大分類","金額","大計"});
outf.setTotal(new String[]{"金額","合計"});
list(inf,outf);
}

public void setSpecial(){
Item kin=getItem(outf,"金額");
Item gen=getItem(outf,"原価");
Item suu=getItem(outf,"数量");
kin.setDV(gen.getDV()*suu.getDV());
}
public static void main(String[] arg){
Test001 prc=new Test001();
}

}
簡単なリストを作成するプログラムのサンプルである。
必要最低限の記述で、裏でパッケージが動きリストを作成する
COBOL,cなどの言語で作成したパッケージに無い良いところが出ていると思う。