東京技術開発センタ (その2)【平成7年3月〜平成9年3月】
- 平成7年4月 技術開発センタのスリム化が叫ばれました。開発項目が減ったため「ご用聞きキャラバン隊」を結成することが決まりました。
最初の「ご用聞きキャラバン隊」は設備建設センタのシステム担当へキャラバンすることとなりました。
- ご用聞きの時、設建センタが使用しているツールは全てMS−DOS配下の「桐」と呼ばれるシステムで作られているため、Windowsは使いたくないと開口一番に言われてしまいました。しかし、後に成果となる開発依頼を受けることが出来ました。
- 平成7年5月 事業計画のスローガンに『収益を出し、自立できる技術開発センタ』が掲げられました。そして、『ソフトウェア生産性の向上』、『MS−DOSからWindowsへ向けた取り組み』へと時代の変化を感じた頃でありました。
この年は、支社管内のネットワーク化、Fire Wallの構築、インターネット技術者の育成等、インターネット時代に突入した年でもあります。
- 技開センタにもインターネット時代の幕開けとも言えるIT施策が実施され始めました。
【技開センタのIT施策例】
(1)各担当課長にノートパソコンが配布されました。
(2)会議室に設置されたパソコンを使って配付資料なしで開発会議が実施されました。
(3)グループウェアツールに『ロータスノーツ』が採用され、社内メールや稟議書システムが導入されました。
- この忙しい最中に私は毎年行われている夏の「お客様サンクスキャンペーン」の支店応援のため、平成7年6月
武蔵野支店へ 1週間ほど出張して参りました。
作業内容は、テレチョイス契約お客様のダイレクトメールの宛先チェックと封書作成や伝票整理等でした。
- また、この時期に「T−NOCS」で使っているSONY NEWS−WS(ワークステーション)に、老朽化によると思われる故障が頻発したため、SUN−WSへの更改を急がなければならなくなりました。
- 私はUNIXが不得手のため、更改にあたっての技術的な調査等は全て有能な若手メンバーが実施してくれました。
平成7年6月に担当者2名がソフトウェア研究室へ出張して事前調査を行ったのを皮切りに、SUN−WS更改の本格検討がスタートしました。
- 一方、 3ヶ月前に行った「ご用聞きキャラバン隊」の成果が出ました。
設備建設センタから「稼働集計システム(prost)」の新バージョンを技開センタで開発して欲しいという内容の問い合わせが来たのです。
- その後、トントン拍子で話が進み、開発依頼を受けることが出来ました。
事前調査や開発準備を進めて平成7年9月13日無事開発会議に付議して「新稼働集計システム(バージョン1)」の開発をスタートさせることが出来ました。
- 開発体制は、技開センタ内の「応用担当」より1人稼働応援をもらって、4人体制で開発をスタートしました。
- しかし、2ヶ月後の11月中旬になっても進捗が進まず大幅に遅れたことから、2名を減らして3名を追加するメンバー入れ替えが実施されて、新たに5人体制で再スタートすることが決まりました。
- 新しい5人体制の中に私がメンバーに入ることが決まり、根っからプログラムが好きな私は、うれしくて万歳をしました。 しかし、納期は1月末までの約2ヶ月しかありません。厳し〜い
- 自分はExcelの経験はありましたが、ACCESSについては初めてであり、線表の遅れを取り戻すのは並大抵ではありませんでした。まるで、目の前が火事場のようであったことが鮮明に思い出されます。メンバーになったからには何が何でも線表を守りたい一心だったので、とにかく頑張りました。
- 新稼働集計システムは、データベース処理にACCESSを使い、帳票出力にExcelを使います。それらを操作する言語に*VBAを使う方式を取りました。
* |
Visual Basic for Application |
- 集計システムの入力処理については、別のメンバーが担当し、自分は帳票出力を担当しました。
12帳票ある中で6つを自分が引き受けることとなりました。納期から逆算すると、1週間に1帳票を完成させなければなりませんでした。
- 職場で開発作業していると総括業務の割り込みが頻繁に入り、開発に専念できなかったので極力年休を取り自宅で開発を行うこととしました。
- 年休当日と休日には、朝6時に起きて直ぐにパソコンを立ち上げて、お昼までに一仕事をこなします。
昼食後から夕方まで、また延々とパソコン作業に入ります。
夕食後30分くらい仮眠して8時頃から更に12時まで作業を続けます。毎日がこの連続でした。
- 勝負は金曜日の夜から土曜、日曜日でした。約1ヶ月半はほとんど外出しないで、開発に専念しました。
- 自宅での開発作業は職場より集中して効率的に進めることが出来たので、平日の帰宅後も、直ぐにパソコンに向かって夜の12時まで開発作業に入りました。
あの当時を振り返ると今の自分には考えられない、不思議なくらい体力があったんだな〜と感心してしまいます。
- また、当時開発に用いていた自宅のパソコンは動作が遅くて大変でした。
NECのPC98(CPU:386sx、12MHz)に無理矢理Windows3.1を載せてACCESS2.0を動かしたので、SQL(Structured
Query Language)を実行する都度結果が返るまで5分くらい待たされるのが普通でした。
- 作業を行っていてもほとんどがこの待ち時間でした。なお、職場のパソコンはペンティアム100MHzだったのでそんなに遅いとは感じていませんでした。
- いろいろありましたけど、苦難を乗り越えて、平成8年1月31日 「新稼働集計システム(Ver.1.0)」が無事完了し、完了報告を行うことができました。
- そして自宅のパソコンも平成8年2月に新しく購入しました。ペンティアム100MHzで動くWindows95(ACCESS)は当時、抜群に速かったような感じがしました。
- 「新稼働集計システム(Ver.2.0)」の開発からは自宅でもペンティアム100MHzのパソコンが使えたので、ACCESSの応答も早くなり、快適に作業することが出来ました。
- 「新稼働集計システム(Ver.2.0)」の開発が平成8年2月21日にスタートしました。
完成納期は5月31日(開発期間は約3ヶ月半)に設定されました。
主な機能追加は、
(1)バージョン1の問題点の対処
(2)データのグループ単位一括投入機能
(3)年度更新処理機能 の3点です。
- 一方、バージョン1.0の試行運用が3月から開始しました。正式には4月1日から運用開始されるものですが、早めにスタートさせて問題点を事前に取り除いておきたいという趣旨です。
- その結果、3月25日に『サーバー過負荷』が発生し、応答時間が極端に遅くなる問題が発生してしまいました。
泊まり込みで原因調査を行った結果、サーバーにデータ送信する際にレコードに付与する『“一意”の算出方法』と『属性の設定に誤り』があり、算出時間に多くかかっていることが分りました。
- 単発でデータ送信している場合には問題にならなかったのですが、大量のデータ送信が行われる時、その処理時間が無視できなくなりサーバーが過負荷状態に陥ってしまったようです。
- さらに、『労務費分計率帳票』の稼働率を求める算出式において、四捨五入した稼働率を合計すると100%以外の数値がでてしまう問題が発生しました。
- 稼働率の合計が99.9%だったり100.1%になったりすることは当然許されず、問題になってしまいました。その時私にはExcelの関数の知識があまり無く解決方法に苦慮しましたが、結局、『合計欄の中から最大比率の項目を判断して端数をそこへ吸収させる関数を組み込む』ことで解決ができました。
- じっくり考えればそんなに難しい問題ではなかったのですが、早急に解決しなければらない時は混乱してドタバタしてしまいました。勉強になりました。
- バージョン2.0は開発途中にバージョン1の問題点の吸収や仕様の変更が頻繁にあり、最善を尽くして対応していたところ、5月上旬になった時点で納期に間に合わない事態が起きてしまいました。
- 開発を依頼する側は、納期よりも製品の質(仕様)の方が大切で、様々な注文を付けてきました。注文(仕様)が対処されなければ製品を受け取れないと言う理由です。
- 担当者同士でしたが、納期は多少遅れても仕方がない(遅れても良い)と言う了解を得て、バージョン1の問題点対処と仕様変更や仕様追加の注文に一つひとつ誠実に対処して参りました。
しかし、納期の延期については書類を受け取っていないと何にもならない事を後から気付きました。当たり前のことですが、気づいたときにはもう手遅れでした。
- 仕様変更と納期延期について先方(開発依頼側)から書類(依頼書)を受け取らないまま、なぜ担当者同士の口約束で進めてしまったのか、今何回思い出しても後悔してしまいます。
- 技術開発センタは設備建設センタからの開発依頼書に基づいて開発しているので、その依頼書の納期通りに開発しなければトップ(所属長)のメンツが立たないことは至極当たり前のことですが。目先の開発に追われてしまっていた私は気付くのに遅れてしまいました。 SE業務を知らなかった事でもあるのかも知れません。
- そこからの私の対応は大変な毎日が続きました。約1ヶ月は開発どころでは無くなってしまいました。納期遅れの理由書作成と開発審議のやり直しです。全て1からの出直しでした。
- 途方に暮れる日々を幾日も過ごしましたが、ある日ひらめいて私は、開発をバージョン2.0とバージョン2.1に分割する案を考えました。
5月末に完了できる項目だけをバージョン2.0の開発項目として絞り、積み残した部分とバージョン1での抜本的な改善項目についてはバージョン2.1の新たな開発項目として開発依頼書を出してもらう方法を考えました。早速依頼元へ打診したところ了解を得ることができましたので、上司への説明を行い、部長、所長への説明を行ってようやく開発会議での承諾を得ることが出来ました。
- 承諾を得る頃にはバージョン2.0の完了報告を行わなければならず、また完了報告書の作成に追われる毎日でした。
- やはり、開発というものは舵取り(SE業務)が重要なんだなとつくづく思いました。