連載

積算四方山話⑫
システムエンジニアへの変身
野呂 幸一

公益社団法人日本建築積算協会 名誉会長

コンピュータ利用の最前線

システム化に取り組んでいたが、機会があれば外部の講習会に出席してコンピュータ知識の習得に励む

1967（昭和42）年３月、大阪の積算課から東京のことになった。

技術計算準備室へ転勤となった。この準備室は、大阪にある本店の管轄下であったが、執務場所は、東COBOLによる開発

京支店に設けられており、技術計算のコンピュータ

フ ォ ー ト ラ ン

私の手元には、FORTRAN 2 で開発された日の目利用の最前線となっていた。
私は、転勤するとすぐに、４年先輩の助手としてを見ない概算の仕上げプログラムがあったが、概算仮設見積の開発を手伝うことになった。この先輩はでなく精算にも使えるのではないかと考えるように構造設計者だったが、構造設計だけでなく、他の技なった。そこで精算を前提に見直し、再開発するこ術分野にも興味を持ち、工務部、現場、研究所なとにした。しかし開発言語は、どうもFORTRAN

ど、いくつかの技術系実部門の担当者とシステム開は向いていないのではないか、それよりも事務計算発にあたっていた。の分野で使われているCOBOL 3 の方がいいと考え

パ ー ト

その一つがPERT 1 であった。これは米国で開発

コボル

た。

された新しい工程計画と管理の手法であるが、当理由としては、積算の計算は小数点以下２桁あれ時、コンピュータの利用によってネットワーク型のば十分であり、精緻な計算はいらないこと、また数工程表を作成し、実際の工事に導入することが課題量や金額が事務計算と同じように分かりやすく表示となっていた。私も急いで専門書などを読み、先輩できることなどである。実際にCOBOLで仕上げ積の助手として関係する会議などに参加した。PERT算のシステムを開発してみると、プログラミングがは、その後、現場のプロジェクト管理のツールとし容易で優れていることが分かった。て、長期にわたって研究開発が進められたが、現場その後、積算プログラムは、すべてCOBOLで開の多様性にうまく適合できず、結局はものにならな発するようになった。三角関数などのかなり高度なかった。

数学を使う溶接の換算も、予め１度から90度の三角

私は、積算システムの開発が主業務であったが、 関数表を記憶させておき、度数を添字として引き出準備室転勤後は、工務や現場など、幅広い分野でのせば簡単に対応できた。
当時、開発で使用するコンピュータは自社にはなコンピュータ利用も担当させられた。
準備室のメンバーは、それぞれ専門の知識や技術く、外部の計算センターを利用していた。毎日のよを有しているが、その上にコンピュータの知識が求うに使っていたが、使用後明細が届けられる度に、められており、各種団体やコンピュータメーカーなその使用料の高さに驚かされた。１日当たり、20万どが主催する講習会には頻繁に参加していた。

円から30万円であり、開発に１、２ヵ月かかると軽私も先輩連中から指導を受けながら様々な業務の
152

Program（またはProject）Evaluation and Review Technique

建築コスト研究No.1102020.723

Formula Translation、科学技術計算向け言語
COmmon Business Oriented Language、事務計算向け言語

積算四方山話⑫

く1,000万円を超えてしまう。その頃、私の月給は３と思います。開発したらどうでしょうか。ただし、万円ぐらいだったので、あまりの高さに怖くなった。

今後ますます増えていく膨大な調査票のデータ化がそこである日、開発を依頼されているユーザ部門問題となります。何か工夫が必要ですが、とりあえの部長にこのことを話すと、「心配はいらない。君ず東京に戻って検討したいと思います」と言って、が作ったプログラムを全社で使うようになれば、す調査票などの参考資料をもらって席を立った。

ぐに取り返すことができるではないか」と言われた。

この時、私の頭にOMR 4 を利用したらどうかといなるほどと思ったが、それだけ価値のあるプログうアイデアが浮かんでいた。しかし、OMRは未経ラムを果たして開発できるのか自信はなかった。

験であり、まず評価する必要があった。
東京に戻ると早速OMRを取り扱っている業者を専門工の就労実態調査システムの開発探し、相談に乗ってもらった。同時にその知識と使い方を学び、OMRの利用がベストだとの確信を得

仕上げ積算の精算プログラムが完成したので、実務で何とか利用してもらいたいと思い、大阪の本店た。そこで労務課長から了承をもらい、システムの開発をすることになった。に出張した。そして積算課のベテランに一人ひとり

OMRは、マークシートと呼ばれる入力用紙の設説明を兼ねてお願いしたが、誰も関心を示してくれ計がキーポイントとなる。これさえうまくいけば、なかった。実際に、仕上げ積算の精算プログラム後は簡単だった。調査票のマークシートはＡ４判とは、その後１年以上、使われることなくお蔵入りとし、ドロップアウトカラー 5 で印刷した。そして専なってしまった。

門工に直接回答の枠を黒で塗りつぶしてもらった。

私が積算課でガッカリしていると以前可愛がって現場での作業となるので折れ曲がったり、汚れたりくれた営業課長から来てほしいという電話があっするのが心配だったが、専門工の皆さんに丁寧にた。行ってみると今は労務課長になっていた。

扱ってもらい、問題なく回収できた。

「チョット相談に乗ってほしいのだが」と言っ回収した調査票を専門業者に渡すと、２、３日でて、労務課の仕事について説明があり、手間と時間処理され、調査票はデータストリームとなって磁気のかかる専門工の就労実態調査について、「何とかテープに収められた。データストリームでは、調査コンピュータでできないか」とのことだった。

票は１枚ずつ区切られており、黒く塗りつぶした枠

労務課には女性社員が10名近くいて、全国の支店が「１」となり、空欄は「０」となっていて分かりにお願いしている専門工の実態調査を皆忙しそうにやすかった。プログラムの作成は、COBOLで行っ取りまとめていた。手計算で統計処理し、専門工のたが、大阪に２、３回出張し、分析項目を確かめる就労状況を分析するのである。毎年１回行っていたと同時に労務課長の要望を聞きながら進めた。

が、女性社員が全員でとりかかっても半年以上かかるとのことだった。
調査票は、手計算で統計分析するため、数は制限

実際に出来上がったシステムを使ってみると、全支店への調査用紙の配布と回収に１ヵ月ぐらいかか っ た が、 そ の 後 の 調 査 票 の デ ー タ 化 と コ ンされていたが、その数は１万枚近くになっていた。 ピュータ処理は１週間あれば十分だった。女子社員
そして年々、協力会社の数が増えてきており、調査も１名で間に合うようになり、コンピュータの利用票の数を制限してしまうと、実態と調査結果とが乖効果は大きかった。

離していく心配があった。
さあ、どうするか。コンピュータを使えばかなり効果は期待できそうだが、膨大な調査票のデータ化が問題となることが予想された。
「コンピュータを使えばかなり効果が期待できる準備室に転勤後、様々な業務の分析とプログラミングを経験し、いつの間にかシステムエンジニアに変身していた。
45

Optical Mark Reader、光学式マーク読取装置
機械処理上読み取り不要な部分に使われる反射率の高い色調

建築コスト研究No.1102020.753