この度、「のぞみシステム」を更新することとなった。
それでこのコーナーも「新・のぞみシステム」と称して再開することとした。
今回はハードもソフトも今までとはかなり変わったものになるだろう。細かい話はこれから書くとして、舞台を一新した田舎芝居が再び始まる。どうか我慢して最後までおつきあい願いたいと思う。
(2009.05.14)
−−−−−−−−−−−−−−−−−
日記で紹介したように、職場の業務システムを更新することになった。「陸蒸気組」で１０年も使っていたサーバーがついに風前の灯状態になり、大騒ぎになった。
よくもまあここまで持たせたものだ（というか単なるドケチ）と思いつつも上司からハードも含めた新しいシステム構築のリーダー役を私が指名され、プロジェクトがスタートした。
ＰＣを２０年触ったとはいえサーバーについてはド素人、しかし大根でも他に役者がいなければ仕方がない。脇役に陸蒸気サーバーの管理をしていた職場サポート幹事長と先日Windows2000サーバーの講習会を受けた若者（さっぱりわからんかったとの感想）を従え、何はともあれ４ヶ月程度のプロジェクトを始めることになった。名付けて「のぞみ化プロジェクト」。
その一部始終を紹介することにした。途中すったもんだもあろうが、どうぞその奮闘？ぶりをご覧頂きたい。また読者諸兄のアドバイスがあれば掲示板にでも一筆いただけたら幸甚である。
では田舎芝居のはじまりはじまり！
2010.08.30
予想通り「新・のぞみシステム」は延期となった。
しかも８月からスタートした情シスによるテストはボロボロ。画面遷移すらまともにできない状態で、これではユーザーによるテストすら無理。
手直ししたもので再度テスト、ユーザーによる訓練兼テストは９月中旬からとなった。
やはり実務を知らないソフトハウスが作ったものは、軌道に乗るまでが大変なようだ。
2010.05.30
詳細設計のレビューがずるずると延びて、やっと終わったのは先週。詳細になると画面イメージだけでなく、入力の制限や警告メッセージ、初期値を何にするかも決めなくてはいけない。
ここでまた、システム開発会社が作った案はもうひとつ。特に各メニューを誰が使うのかの権限はかなりいい加減で、コメントだらけになった。
さらには、出てくる設計書類の質が、遅れとともにだんだん悪くなってきた。とにかく提出さえしてしまえば・・・という姿勢が丸見えで、ミスだらけのものであっても、それは客にチェックしてもらおうという魂胆が見えてきた。
さすがにこれには閉口した。そして遂には私も切れかかって、「客にチェックしてもらおうという意図が丸見え。ようやるわ」と文句を言った。
今後プログラミング(Java
Script)に入り、７月中旬に総合テストとになるのだろうが、どれだけ人を集めても２ヶ月弱で完成するのはほぼ不可能に思う。誰もおおっぴらに口にはしないが、１０月１日スタートには赤信号が点滅している。
2010.03.16
昨年のキックオフのすぐ後、システム開発会社が作った基本設計のレビューに参加。例によって私は言いたい放題だから、相手は相当煙たい顔をした。しかし今言いたいことを言わないと、後出しじゃんけんでは変更作業に手間がかかるし、何より追加費用がかさむ。
相手にすれば、いきなり変なオッサンが出てきて「こんな項目は手入力やなくて、マスターから引っ張らなあかん」とか、「画面表示の用語が統一されとらん」、はては「使えるＩＥのバージョンは？（今回はウェブＤＢである）」ということまで矢継ぎ早にコメントするので驚いたと思う。
しかしこちらは「新幹線」と「のぞみ」を含めて１０数年間システム開発と実務をやってきたシスアドレベルでものを言うから、的を外すことはない。
そして今週は詳細設計のレビュー。
向こうは警戒したのか、またぞろ細かく突っ込まれると思ったようで時間に余裕を持ったスケジュールを組んできた。だが話は順調に進んで、今日などは２日分のレビューを１日で済ませてしまった。
さて、今回の開発会社の言うことを聞いていて思ったのは、意外と実務に疎いこと。開発のベースは「のぞみシステム」時代の仕様書だけだし、運用に関することはろくにレクチャーしてこなかったので、あまりきつい評価はしない方がいいのだが、社員が若いと実務の理解度は低い。
現在開発スケジュールはやや遅れ気味なので、少し心配になってきた。
2009.11.04
半年前の会議以来、正式なゴーサインは幹部の優柔不断でなかなか出なかった。しかしやっと決まったので、今日は「新・のぞみシステム」のキックオフ会議。
実はこの出遅れ、１年前に別事業部が早々とシステム開発を先行していたものに便乗するという、極めて情けない決断に腹が立つ。便乗だから要件定義は既に終わって基本設計もほぼ終了。「のぞみシステム」からの変更はほとんどないとはいえ、今からの要望はほぼ許してもらえない状況である。
2009.05.14
７年少し前、私が「のぞみシステム」開発に加わったことを機にこのコーナーを設けたが、あれからシステムは順調（？）に動いており、しばらく記事の更新をすることもなかった。
だが、今日当然上司に呼ばれて「新・のぞみシステム」の会議に出ろと言われた。
１年ほど前から動きがあるのは知っていたが、貧乏事業部でもあり、また上層部の無理解で「陸蒸気システム」のように十数年も使い続けた経緯もあって、私の現役時代には日の目を見ることはあるまいと諦めていた。
ところが雰囲気が急に変わって、具体的に話が進み始めたのである。そうなると私抜きでシステム開発が始まるわけがない。現「のぞみシステム」の概念や要件定義を熟知しているのは私一人。
ということでいきなり寝た子は起こされた。
2007.04.15
「のぞみシステムの落とし穴」３：初めての返品
色々な問題が表面化したのは昨年の１２月。
きっかけは倉庫への返品処理、それも元の伝票番号を使って倉庫へ戻すことがシステム稼動以来初めてだったことである。以前は客が使い古した機械の部品の引き取り・再生を目的として持ち込まれたもの返品処理ばかりで、この場合はいずれも返品専用の伝票番号を新たに作っていた。ところが納入直後の返品は始めてのケースでもあり、当初の番号を使うことにしたのだ。これが思わぬ波紋を呼ぶことになる。
2007.04.11
「のぞみシステムの落とし穴」２：固定資産に在庫があってはならない？
経理から突如クレームがついたのが、決算の時に新しい固定資産（例えば工場建屋）を作るための資材を在庫扱いにしてはいけないとのこと。だがその根拠は？と聞いても明確ではない。
経理に言わせると、材料費の支払い計上と原価としての費用計上が食い違うのはまずいらしい。今までは設備も小さかったために在庫が生じることはなかったのだが、今回は大規模な設備を入れたことによる在庫が発生して問題が初めて発覚した。
こういう場合に悩ましいのはプログラムであたかも在庫が発生しないような仕掛けを作るのか、運用で逃げるのかの判断。めったに起こらないことのために費用をかけて改造するのか、というのが判断のキーポイント。まだ結論は出ていない。
2007.04.08
「のぞみシステムの落とし穴」１：在庫がゼロになる直前の出庫伝票が印刷できない
原因は、見込発注した在庫の手続きを簡略化するためにプログラムの改造を行ったこと。当初は伝票すら印刷できなかったが、これを解決したら次は在庫がゼロになる最後の出庫の時だけ伝票が出ないトラブルに見舞われた。明らかに伝票出力のタイミングが在庫数の変化の後になっていたために起こったもの。
ＳＥが本番スタートの時間に追われてルーチン処理をミスった。
2007.04.07
最近「のぞみシステム」のトラブルが続発している。
システム稼動から３年半、今になって何故問題が発見されるのか、非常に悩ましいところである。だが多くの原因を調べているとその共通点が目立つ。それは仕事の質が変わってきて、当初想定していたデータの性質が変わってきたことである。
ここしばらく、日記で取り上げた問題を総括し、原因と対策を書くことにする。ただ、今日はその予告ということにとどめ、具体的問題は明日以降に「のぞみシステムの落とし穴」として紹介することにする。
2004.06.23
「のぞみシステム」の会議もついに、麻雀用語でいう「ラス前」になった。
今後も多少の懸案事項はあるが、それは来年度になる。
従ってこのシリーズもいよいよこれで完結。もし何かイベントが発生したらそれは日記の方で取り上げることにする。
２年以上に亘った「のぞみプロジェクト」、これで一応の締めくくりとしたい。
2004.05.19
システムの不具合や改造要望に関する会議を開いた。特に「陸蒸気組」の上流が未だに旧式の操作方法やルーチンにこだわるのである。
それで話を聞いたが、２時間かけて議論をした結果、「できることをできないと思い込んでいた」ということに落ち着いた。
在庫から部品を持ち出す伝票について、品物のグループ分けしているコードがあるのだが、グループごとに別の伝票を作らないとダメだと勝手に解釈していたのである。１枚の伝票に１行しか品物の記載がなかったからおかしいと思っていた。それが２時間かかってやっと判明したのである。今後は伝票の数が半分くらいになるだろう。
そもそもその職場にはサポーターがおらず、またユーザーもろくにマニュアルを読んでいない。その一方で旧式の入力方法に固執するし、「難しいことはわからないが、このボタンを押したら一発で動くようにしてくれ」みたいな文句を数十件、ファイルに書いて送ってくるのである。
上流のシステムを仕切っているキーマンは苦り切っていた。
2004.04.03
ここ数日、「のぞみシステム」に一本化するために旧システムの閉鎖作業で忙しかった。そして週明けも、今度は「のぞみシステム」自体に含まれている一部マスターを新年度のものに設定する作業が待っている。
2004.03.31
今日、「陸蒸気」サーバーの電源を落とした。１２年間、よくもまあ持ったものだ。本当にご苦労様でしたと手を合わせた。明日は電子機器ゴミとして産廃業者に引き取られていく。
関係者の話によると、導入当時の価格で６００万円だったそうだ。今なら贅沢をしても２００万円は絶対に越えないだろう。隔日の感がある。
−−−−−−−
さて、「元祖・新幹線システム」の終結作業はとうとう今日、３１日までかかった。お陰で最後のゴミ掃除の手伝いがやっと昨日からスタート。多分明日一杯までかかる見込み。幸いにして私の決算作業が少なかったから良かったものの、冷や汗ものだった。
2004.03.18
２月１２日に書いた「元祖・新幹線システム」の終結作業がまだ完了しない。今日もその会議で大騒ぎになった。とにかく残り未完データの１／３がまだ終らない。おまけに末端では３月３１日ぎりぎりでもいいじゃないか、という声が出ているそうで、さすがの私も開いた口が塞がらなかった。
このままでは大変なことになる。そこで中途半端なデータはすべて取消処理をして、「のぞみシステム」で再度新規に起票することになった。システムを統括している部長も合意し、明日から作業開始。私も手伝いをする。
2004.02.26
「新幹線」、「陸蒸気」双方の下流システムとのデータ交換が今日終了した。これでシステムの通常業務は１００％完了。
オンラインプログラムの停止そのものは、年度末処理を終えた後になる。また「陸蒸気」サーバーも同時に電源が落とされ、産業廃棄物として処理される。
盛大な葬儀をしてやろう。
2004.02.12
いよいよラスト前の会合があった。
来る２０日でバージョン1.0Xが完成し、今までの不具合を一気に解決する段取りが決まった。
その後は来年度の１年をかけてバージョン1.1、すなわち新たな追加ルーチンを開発する作業に取り掛かる。但し、要件定義はほぼ出来上がっているので、ＳＥとプログラマーが細々と作業をするだけで、定期的な会合はもはや不要となる。
来月は完成を祝って有馬温泉で怪気炎を上げようということになった。
さて、実は不思議なことが進行している。
あれほどてこずることが予想されていた「陸蒸気システム」の終結が既に終了し、私は左団扇で３月を迎える予定である。ところが統合する他の事業部の旧システム、特に私が前の事務所で使っていた「元祖・新幹線システム」の終結が２月でも終らない可能性が出てきて大騒ぎになっているのである。当事者は特別体制で処理をすることになり、私は裏で作業がどの程度進んでいるかを監視するお目付け役を仰せつかった。
来週は毎日のように未完データをしらみつぶしにチェックし、向こうのキーマンに報告することになっている。やれやれ・・・＼(●o○;)ノ
2004.01.30
喜びあり、悲しみあり・・・複雑な１日だった。
１．「新幹線」の最後の２件が完結し、システム最後の処理がすべて終った。これで「新幹線」用プリンターと駆動用ＰＣ２台が引退する。同時に「博物館」行きデータのリストを情シスに送った。「陸蒸気」も同時に今日で完結。こちらは週明けにゴミがないか確認する。
やっとゴールにたどり着いたことには感慨深いものがある。自分を誉めてやりたい・・・おっと、これは盗作だ。
２．終わりと思った矢先、「陸蒸気」は既に済んでいたのに、「新幹線」ではまだ在庫データの「のぞみ」への移行が残っていて、私の担当ではないものの在庫管理担当者からお助けコールが入った。調べると在庫データが１件破損していることがわかった。
不思議なことに「新幹線」では在庫になっていない壊れ方をしているのに、原価へ受け渡しする棚卸用ＤＢは在庫として存在している。「のぞみ」へ移行するためには「新幹線」で出庫して「のぞみ」で再入庫する必要があるが、今のままでは正常に出庫する手段がない。直接ＤＢに手を突っ込む方法もあるのだが、これは情シスなど関係者を交えて来週に協議する。例え１件であろうと不正な経理操作は許されないからである。
３．これは以前日記に書いたと思うのだが、「ルール違反」を建前に使用禁止をわめいていたクソタレ上司が便利ルーチンをなし崩しに（つまり謝りもせずに）許可した。具体的には正式な発注書がなくても下請企業から納入を急いでもらうために納品書を先行して発行する仕組みである。法律に抵触はするが、緊急の場合は互いに暗黙の了解でやること。もちろん双方で日付をバックデートした注文書を当月に交付することで了解するのである。無用のトラブルを避けるために「新幹線」時代からやっていることだし、世間の常識でもある。彼はそれを幹部会で「ルール違反」を力説して顰蹙を買った経緯もある。だが、下請を含めて納品書の先行発行を禁止することには実務に多大な支障が生じるためにあちこちから猛烈なブーイングが出ていて、遂には彼も抗することはできなかったのである。
ザマーミロ！！
2004.01.14
そろそろ多くの社員が「のぞみシステム」に慣れてきて、蓄積されたデータを色々な切り口から分析することをやり出した。それは結構なことなのだが、時として「あるべきデータがない！」と騒ぐケースも出てきた。
ひとつは、下流システムに流れた完了データの何個かが抜けているというもので、それを利用しているコスト計算の担当者から「のぞみシステム」から月末データが流れていないものがあるとクレームを受けた。だが、問題になった１０件のデータは「のぞみ」側で正常に完結しており、なおかつ下流側でもちゃんと受け取られたことが判明した。そして詳しく調べると、コスト計算をやっているグループの中で完了データの元になっているExcelファイルを加工しているマクロが、受け取ったデータをうまく処理し切れていないことがわかったのである。要するに一人相撲を取っていたもので、大山鳴動ネズミ一匹で終った。
その次は本当に抜けがわかったというもの。
「のぞみシステム」から上流側には、進捗に応じてイベントとなる処理の日付が送られることになっていた。ところがその内の２種類の日付が何故かまったく送られていないことが今頃になって判明したのである。現在両方の開発ＳＥが共同で調べているが、忙しいのかまだ結果が知らされていない。
2004.01.05
「のぞみシステム」は何事もなく年を越しホッとしている。
しかし「新幹線システム」にはまたもや躓きの石が見つかった。１２月１８日に書いたバックアップの不具合について、念の為本社情シスのＳＥに本番データのキーコード一覧をExcelに落としてもらい、バックアップと比較したのである。それを見てまたもや目がテンになった。バックアップ側のＡ、Ｂ両データベースにもキーコードが存在しない健全なデータが３件も見つかったのである。
仕事始めの日はこの比較・抽出作業に殆どを費やしたが、これでどうやら虫潰しは終わりになりそうだ。
2003.12.26
ついに「新幹線」の残データが２件になった。担当者のサボリではなく、工程が遅れて年末に完結しなかったからである。
とはいえ、プリンターを使わなければならない仕事はなくなった。そろそろプリンターを片付けようかと考えている。
一方、「のぞみシステム」は順調に進み、四半期決算のデータ抽出も担当者に手ほどきしたので、無事年を越える事ができそうだ。
2003.12.18
前回、完結した「新幹線システム」を「Business
Objectで展示・閲覧できる準備をほぼ完了した」と書いたが、ゴミデータをリストから見えなくした後の抽出したデータに不審な点があるので再度調べたらとんでもないことがわかった。
何と健全と思っていたはずの一部のデータに虫食いが発生していたのである。理由はこういうことだ。
そもそも今の事務所では、ホストでの関連データの連携を毎日手動（！）でやっているのだが、２００２年に３〜４回の連携失敗があり、その際本番データは壊れなかったが、バックアップは不完全になっていたのである。その事を情シスに問い詰めたら白状した。
バックアップには更新された部分のデータが差分ファイルで送られるため、失敗した日のものは書き込まれず、虫食いになったのである。見つかったきっかけは、Ａ、Ｂ二つのリレーショナルなデータベースを開いたときに、片方からもう一方のデータを引っ張ろうとするとあたかもデータが存在しないような動きをしたことだった。調べると関連付けているキーコードが片側には存在しない。さらに調べると、ＡからＢを呼べないものとＢからＡを呼べないもの双方合わせて、約１万３千件の全データのうち１４件もの「片手落ち」が見つかった。
本番データはさすがにそのような現象はなかったが、バックアップは一から作り直し。「のぞみプロジェクト」のＳＥの作業が増えることになった。
ところで、「陸蒸気システム」と「新幹線システム」は来年３月末で完全に停止する。「陸蒸気」はもう少し早いかもしれない。関係者が手分けして未完データの手仕舞いを急いでいる。私はその関係で「新幹線」の残データ８件分を常時監視する毎日が続く。
できれば年末で完了してしまいたいので、担当者の尻を叩くのに懸命になっている。
2003.12.12
「のぞみプロジェクト」の会議兼忘年会があった。
「新幹線システム」をはじめとする旧システムの未完データを自動で「のぞみシステム」に取り込む議題がメインだったのだが、結局手動で完結させて独立した保存データとして扱うことになった。私の方では新幹線システムに含まれている旧事務所の不要データをすべて抽出し終わり、身奇麗にした上でホストの「博物館」エリアにBusiness
Objectで展示・閲覧できる準備をほぼ完了した。
システムとしての残作業のピークも終わり、いよいよプロジェクトチームの最後の懸案、新システムのデータが肥大した場合の完結データをどう扱うか、いわゆる「データクローズ」が残るだけになった。
いいニュースがある。プロジェクトの完成を評価され、プロジェクトチームが来年年頭の表彰を受けることになったのである。
2003.11.28
昨日に各種の修正プログラムをまとめて上げた。その中で最大の変更部分はパスワードの入力である。「新幹線システム」ではパスワードがなかった。パスワード忘れによる混乱よりもユーザーを信頼することの方を優先したためである。
しかし今回はうるさい経営幹部の発言で「セキュリティー強化」を余儀なくされた。だが私はここに至る議論で非常に不愉快に感じた事がある。
というのも、パスワードの必要性についてその経営幹部は「派遣の人達にデータのすべてを見せるのはいかがなものか」と、差別意識を丸出しにしたからである。
このご時世、派遣社員はどこの職場にもいるし、正社員と同じ仕事、同じスキルで活躍している例はいくらでもある。同じ能力でありながら給料が安いと積極的に入れたのは誰なのかと言いたい。職場の女性陣は今や９９％が派遣。正社員はほとんどが４０歳から上で、新入社員を取ることがあってもそれは重役の縁故が圧倒的である。
そういう派遣社員全盛時代に突如として不信感をあらわにする発想は情けない限りである。企業秘密を漏洩する心配なら、正社員とて就業規則はあるし、派遣社員でも派遣契約で歯止めの条文がある。もし規則に反して情報を意図的に洩らすとするヤツがいるとすれば、正社員であろうとなかろうと同じこと。また犯人の特定はログを見たらですぐにわかること。
真面目に仕事をしてきた新システム関係者は、非常識な発想に非常に苦々しい思いをした。
2003.10.08
今日は天に唾するサポートになってしまった。
クレームが出たのは部品関係のマスターデータ。上流システムとの共有をしているのだが、上流でマスターを呼んでもデータが消えてなくなっているという。ファイルがおかしいのかと思い、上流のサポーターを通じて調査を依頼したら、結局たらい回しになって、最後は私のところに戻ってきた。
原因は何と、私がメンテしているこのデータの一部の有効期限が９月末で切れていて表示されなかったためとわかったのである。
慌てて関係先に実状を聞き、有効期限が延長できることを確認してから設定をいじった。
勘違いの元は、私がマスターの有効期限がすべて３月末だと思い込んでいたためである。
情けない・・・(T_T)
2003.10.07
「のぞみシステム」とは直接関係ないが、「新幹線システム」でとんでもないことを発見した。事の経緯はこうである。
「新幹線システム」の残りデータを整理していると、外部支払いに関するデータがまだ未払いとなっているものが数件発見された。幸いにも支払い先からはクレームが来ていないものばかり。しかし情シスとデータを照合していると、「新幹線システム」では支払要求が出ているのに支払に繋がる中継ファイルが受け取っていないことを確認。その原因を情シスに調査させたら意外なことがわかったのである。
詳細を調べると、支払要求のデータは私の同僚が８月に休日出勤して打ち込んだものとわかった。ところが中継ファイルは休日にデータを受け取る仕組みになっていなかったのである。というのも、データ転送は情シスが手動で（！）取り込みするようになっていて、休日分は最初から考慮に入れていないために完全に無視されていたのである。
ではこれが何故今まで見過ごされていたか。これは全くの偶然であるが、「新幹線システム」が今の事務所に持ち込まれて以来４年間、休日に出勤する者はいても、システムに打ち込む作業は一切していなかったからである。
不幸中の幸いだったが、よくもまあ４年間もバグが見つからなかったものだと妙に感心した。もっとも、もうすぐ閉鎖されるシステムだからプログラムを修正するつもりもなく、関係者に休日のインプットをしないように注意喚起するだけになりそうだが。
2003.10.03
「のぞみシステム」が稼動して初めての決算を終えた。ちょっと決算の帳票関係でゴタゴタしたが、何とか解決できた。
旧システムの残っている未完データもかなり減っていた。
ところで相変わらず、サポートについての悩みがひとつだけ沈静化しない。それは上流システムユーザーからの問い合わせである。今日もいきなり電話で「ＩＤがＸＸＸのユーザーだが、ＹＹＹ画面のデータを全部入れたのに確定のためのリリースができない」と、こちらが見たこともない画面についての説明を一方的に喋った後で、何とかして欲しいと要求するのである。悪いことに定時後で、その職場のサポーターは帰宅していた。
こちらは本当に見たことのない画面なので、「助けてあげたいのはやまやまだが、そのプラグラムについての操作については知らないし、答える権限も義務もない。」と突っぱねるしかなかった。
データのやり取りの関係から上流システムの操作の一部は教えて貰っているし、私の長年のカンで、初めて見る画面でも何かできる能力はある。しかし上流システムに首を突っ込むときりがない。可哀相だが心を鬼にして門前払いをするしかなかった。
2003.09.17
「新幹線システム」と「陸蒸気システム」に残っている未完データの抽出を実施した。ところが厄介な問題が出てきたのである。
実は今使っている「新幹線システム」は、以前いた事務所から引っ越した時にデータを分離して、ＪＲ東海とＪＲ西日本のような形で、別々のデータベースとして並行して運用されてきた。しかし実際はきちんと分離されずに、いくらかの部分は同じデータのコピーが出来てしまい、片方は更新されているが、もう一方は分離以前のまま、ということが生じていたのである。
従ってどちらかのデータを「正」としてもう一方は削除せねばならない。しかしこれはかなり骨の折れる作業である。今日そのことを旧事務所のキーマンに伝えた。幸い彼は「えらいこっちゃ」と言いながらも、笑いながら共同虫取り作業を同意してくれた。
実際の「新幹線システム」と「陸蒸気システム」の残データは、本日現在２桁台。９月末決算にはかなり減るから、移植は手作業で充分、残りは仕事の進捗で完結データになって行く。
2003.09.10
「のぞみプロジェクト」は一部の手直しを残してほぼ安定した。「新幹線システム」を作ったときは１２０件もの手直しを必要としたことに比べればわずか数件、雲泥の差である。
しかしこの時期になってやや面倒な話が出てきた。旧来の「新幹線システム」と「陸蒸気システム」に残っているデータを順次減らして軟着陸させ、墓場へ送り届ける作業が必要となったのである。残りデータがいくらか、ゴミデータをどう取り除くか、どうしても新システムに移植せねばならないデータはどれかなど、手作業でないとやれないことがわかったのである。そのためにデータをダンプし、紙とにらめっこをすることになる。
これを来年３月までに終了する必要があり、さらには「のぞみシステム」のサポートも手が抜けないとあって、ついに上司は「日常業務はしばらく休んでシステムに専念せよ」と宣言した。気は楽になったが、システムのお守りは全部私の肩にかかってしまった。
2003.09.04
私が休んでいる間のトラブル、いくつかあったが何とか乗り越えたようである。私がいなくてもシステムが無事動くことを祈っていたが、無事８月末の処理も終了してホッとしている。
今日は手間のかかるトラブルがあった。
１．エミュレータの設定ファイルがひとつ壊れていて、プリンターから正しく印刷されず、緊急修復。
２．１名が昨夜データを編集中のままＰＣを切ったため、データの一部が破損、作り直し。
３．月報関係がスムースに出力されない。７月であれほどクレームしたのに改善されず。
2003.08.07
プロジェクトの実機稼動から１ヶ月、致命的なトラブルはなかったが、実際に使ってみてしっくりこない点もあるし、実は時間切れで積み残したルーチンの開発にも着手しないといけない。
そのための反省会兼問題整理の会議を開いた。盆休み明けから情シスの作業が始まる。
ところでふと思ったことがある。引き続く開発作業の中には旧システムの「のぞみシステム」へのデータ移管が含まれるのだが、当初から「陸蒸気システム」はそのあまりのゴミデータの多さに移管を断念した経緯がある。
１２年前、「陸蒸気システム」がスタートした時からこのゴミデータの存在と下流へのデータ転送でデータが化けることはわかっていたはずで、それを何故今まで放置したのだろう？という疑問が湧いた。その原因を考えていると見えてきたことがある。それは「陸蒸気システム」の管理・メンテに対して工場情シスがずっとそっぽを向いてきたという事実である。
工場情シスは昔から下流側と本社ホストに関する仕事だけをやってきた。しかし「陸蒸気システム」のサーバーは工場内で独立したサーバーを持つクローズドシステムとして構築された。だから「それは俺たちの知ったことではない」というスタンスを貫いてきたのである。おまけにＯＳも違えばアプリも特殊とあって、開発に携わったキーマンが上司と喧嘩して辞職した後も、自分たちではメンテできる能力がないことを棚上げにして、ずっと他人事として厄介者扱いしてきたのである。それがためにゴミデータも転送データが化ける問題も、自分たちは関わりたくないがために、解決しようという動きを１２年もの間一切しなかった、・・・と、思えて来るのである。
2003.08.04
月末処理が正常に終了して、下流のシステムもデータをうまく受け取った。まずはこれで決算を除いて一通りのルーチンをこなしたことになる。
そんな中、基幹データは問題ないのだが、月報関係の処理がもたついて関係帳票が遅れて出ている。おまけに開発済のはずだったレポートの一部がまだ完成していないという。重大な問題ではないが、開発側メンバーの能力が疑われている。
それから、上流側でシステムを理解せず使っている連中がいてまだもめている。原因は最初の起票作業で、伝票の種類を何種類か使い分ける必要があるのだが、これを理解しないというか、理解する気もない状態で、要するに「自分たちが入力し易い方法」を基準にしているのである。
下手をすると会計処理に支障が出る場合もあり、経理がクレームをつけないか心配なので、上流側の管理者に申し入れているが、彼も相手の無知さ加減に困っていて、なかなか解決しない。どこでガツンと言わせるか、悩ましいところである。
2003.07.30
本日のトラブル：
１．「新幹線システム」のプリンタ駆動用ＰＣ１台がアウト。正確に言うとモニターに帰線が走って白っぽい画面になった。これはよくあるパターンで、ブラウン管の偏向コイルにかかる高電圧電源回路がイカれた証拠。要するに寿命である。
２．突如のお助け電話。ある端末の操作をしていた人間が席を離れた間に、誰かがＰＣ電源のコンセントを抜いたという。本人は怒りとともに救いを求めてきた。
ホストとの接続を無理矢理切ると、システムが異常な動きをする可能性があるのでこちらも一瞬青ざめたが、再接続の手順を踏んで無事回復。
３．ある部署での入力操作に必要な端末が１台不足することがわかった。慌てて番号を貰い、セットアップのためにチャリを飛ばした。月末までのインプットが迫っているだけに必死である。
2003.07.28
本日のトラブル：
１．バーコードリーダーを取り付けたＰＣのうちの１台がおかしい。数値入力フィールドに文字が入ってエラーになる。よく調べたらバーコードの最後のチェックサム文字まで出力される設定になっていた。
バーコードリーダーの設定は私がやったもの。アイテテテ・・・手が滑ったらしい。
２．プログラムのバグが見つかった。
仕事でかかった経費をジョブ番号に振り分ける操作画面で、受注ジョブの原価として割り当てるもの以外の番号、すなわち社内の共通費とすべき特殊なジョブ番号を指定するとエラーになる。
明らかなプログラムのミスで、月末〆切が迫っているので特急でパチ当てをしてもらった。
2003.07.17
本日のトラブル：
１．若手のＹ君、エミュレータのウィンドウが開かないという。見ると最小化したウィンドウがタスクバーから元のサイズに戻せない。そして気付いたのが、他のソフトを起動するとメモリ不足のエラーが出る。なるほど、彼のWin98マシンのリソースは16%と、これはもうアウトである。
しかしいきなりリブートすればホストとの接続が異常終了して大変なことになる。従ってWin98がコケないように順次他のアプリを終了して、何とかエミュレータの窓が開くようにし、ホスト接続を正常に切ってからリブートした。
その時気付いたのが、「付箋紙95」でデスクトップに付箋をベタベタ貼っていること。試しに起動時のリソースを確認すると46%である。これでは２、３個窓を開ければすぐにパンクする。そこで「付箋紙」を終了させると11%増加した。時間がないのでこれ以上の常駐ソフトの追及は止めたが、そうでなくてもリソース食いのWin98、「付箋紙」はお薦めしないソフトである。
２．上流側のサポート体制が不十分なままシステムが稼動したため、上流側の不慣れな操作が続発している。おまけに自分達内部のデータの作り方や完成したデータのリリース方法までこちらに聞いてくる。一人を撃退してもまた別の人間が同じことを聞いてくる。
こうなった原因は二つある。
一つは事前の教育が不十分であったこと、特に「陸蒸気システム」とは違い、完全にデータベースが分離されていることの認識をきちんと説明していないのである。
二つ目はこのシステムの分離と絡むのだが、以前は同じサーバー、同じデータベースだったために、上流側のデータミスや操作の誤りを全部こちら側で裏技としてリカバーするという最悪の方法が蔓延していて、「言えば何とかしてくれるだろう」という甘えと無理解がそのまま引き継がれたのである。「のぞみシステム」では間違ってリリースされたデータはこちらでは絶対に改変できない。それを訂正するには上流側でデータの改正をかけるしかないのである。それを説明しても納得できない顔をする。人によっては「じゃあどうすればいいの？」と聞いてくる。それに対する答えは一つ。
「データ改正の手順はそちらのキーマンに聞いてよ」
2003.07.15
本日のトラブル：
１．昨日の２件を解決。ところがまた伏兵が・・・
２．突然プリンターの電源がまとめて落ちた。あ"、である。ブレーカー丸ごと切れたので、関連のＰＣとＨＵＢも落ちた。確かに今月からプリンターを４台増やしたのでかなり負荷が高くなっていることはわかっていたが、２週間以上経っているのでまったく気にしていなかったのである。
そして過負荷の原因を追求していると、思わぬことに気が付いた。何と６００Ｗもあるコーヒーメーカーが同じ回路に繋がっていたのである。こりゃ落ちるはずだ。
2003.07.14
本日のトラブル：
１．ホスト用プリンター駆動ＰＣがまた一つ壊れた。今度は液晶の不良で、モザイクが走り回る感じである。とりあえず何回か叩いて（荒っぽいが、これが最適）元に戻すがすぐにまたおかしくなる。明らかに液晶が頓死寸前である。
隣の職場で眠っているＰＣがないか聞こうとしたが、壊れたのが定時過ぎだったので知っている人間は既に帰宅。明日助けを求めるつもりだ。イカれたＰＣはそれまで電源の入れっぱなしにしてある。
２．「のぞみシステム」の番外ルーチン編が出来たので、それをインストールしに来たＳＥが電話を掛けてきた。「あの〜、これWin98でないと動かないんですけど・・・」
実は山陽新幹線の博多−博多南間のようなちょっとした拡張プログラムを、特定の人間に操作してもらうために開発が進み、これも８月から運用する手筈になっていた。ところがこいつはサーバー系の、それも恐ろしくメモリーを食うタイプで、ユーザーが現在使っているWin95ではとても処理しきれないということがわかったのである。
しかし急に言われても・・・これは困った・・・と考えていたらふと思いついた。
ちょうどスキャナとか外付けＨＤを繋いでいる共用ＰＣがWin98なので、これをユーザーのWin95と入れ替えることである。今日のところはＳＣＳＩカードだけを取り外し、明日本体を抱えて（コンパクトモデルなので軽い）ユーザーのところへ走る。
ああしんど。
2003.07.11
本日のトラブル・・・ではない。
今日は情シスに来て貰ってBusiness
Objectをインストールした。「のぞみシステム」はホスト機なので重い作業は禁止。というよりもオンラインには２分の監視タイマーが入っていて、時間がかかるルーチンは最初から組んでいない。だから、検索やレポート類は一旦Oracleサーバーにデータを落としてからBOで閲覧するのである。しかしこのBOというソフトはやたら高い。性能がいいだけにシェアも高く、独占価格でしっかりと金をむしり取られる。
それにしても１ライセンスが'ン十万円'となると全ユーザーのＰＣには渡らず、部内では私を含めた５台のみとなった。
2003.07.09
本日のトラブル：
１．何故か画面がクリアされてしまい、それを解消するのに情シスサポーターに怒られるのを覚悟でホストとの接続を切り、その場を逃れた。当然のごとく「確信犯」であることを指摘され、ひたすら謝った。
２．たった１００ｍほどしか離れていない別棟事務所からＦＡＸで質問を投げてきたアホがいた。掲示板に書き込むよう指示したが、タイトルにメールアドレスを書くなど、チャランポランだったので修正を指示。しかし本人は反省の色なし。
2003.07.08
本日のトラブル：
１．漢字モードのままバーコードリーダー入力していて、「動かない」とわめくヤツ。
２．本人のせいではないがＰＣがフリーズしてしまい、ホストとの接続が一時おかしくなる。
３．ユーザーＩＤを間違えてログインしたためにシステムがこれまた不穏な動き。この不具合は近日中に治す予定。
４．新規データ入力画面で、入力データのチェックが厳しすぎて次に進めなくなった。これも不具合だが、入力した本人に事情を聞いてのけぞった。「検索をしようとしてうまくいかないので入力画面に入った」という。「をいをい、その入力画面は金額も入るやつやないか！ そんなもんを検索に使うたらあかんがな」
ということで関係者全員に注意喚起のメール。犯人の名前は伏せたが、知る人ぞ知る嫌われ者である。
2003.07.07
「のぞみシステム」が稼動を始めてから１週間、一部プログラムのパチ当ては行なったものの、何と一度もシステムのエラーとかハングアップは発生していない。「新幹線システム」での運転実績がものをいったようで、それをベースにしたシステムだから安定していて当然とも言えるかも知れぬ。
トラブルは運用方法をきちんと徹底していなかったのが主な原因、それも上流での教育不足などの問題をこちらに振ってくるケースが後を絶たない。
ＰＣが２台壊れたのはふいの交通事故。原因はシステムではない。
ということで、まずは順調な滑り出しだ。今後のヤマ場は大量のデータのやりとりが行なわれる月末と期末である。
2003.07.04
今日もまた１台壊れた（爆）
これもまたＶＢＣｏｒｐが原因のようである。特にロースペック（CPUが100MHzあたり）との相性が悪いようだ。従い、5577プリンター専用のＰＣからはＶＢＣｏｒｐを全てアンインストールした。
−−−−−−−−−−
ここに来て、すさまじい要求が経営幹部から出た。つまり「のぞみシステム」の基本的コンセプトである「データの共有化」をやめてくれというものである。どういうことかというと、関係する事業部間での取引になった場合、データを社外にリークされて、競争関係にある売る側の事業部が社外よりも不利になる危険性があるというのである。
大企業の幹部がする発言とは思えない、社内に対する不信感丸出しの発想である。もしそのような社外へのリークをするなら、それは社内の機密事項の漏洩として、処分に値する。
幹部とあろうものがこんなさもしい猜疑心を社内に向けるとは思わなかった。もちろんプロジェクトを推進してきたメンバーは、私を含めて怒り心頭である。
2003.07.03
ホスト機からの印刷を普通のプリンターへ出力するのには特殊な環境が必要になる。端末ではWindowsPCで動く3270エミュレータを動かすように、プリンターも5577エミュレーションモードで動くプリンターが要る。
ところが市販されているA3/A4サイズのプリンターでこの5577エミュレーションモードを持っているのは、何と京セラ１社しかない。キヤノンもリコーも開発すると言いながら、未だに実現していない。出荷台数が少ないだろうからコスト競争力がなく、今更開発する気もないといったところか。京セラの独占を崩すような雰囲気はまったくない。
おまけにこのプリンターはTCP/IPのネットワークでは使えない。ホスト機のゲートウェイ接続に対応できないので、一旦ＰＣで信号を受けてもらってから、ローカルプリンターとして動く。だからホストからの印刷を行なうにはＰＣとプリンターが必ず１組いるのである。当然ＰＣはWindows95の超オンボロで十分間に合う。
これだけ前置きしておいて、今日のトラブルに入る。
午前中は何事もなかった。ところが午後に入ってユーザーの一人が「印刷がおかしい」と言ってきた。一昨日のオーバーレイ問題は解決したのに・・・と思ったが、今度はデータ部分がでたらめに打たれ、なおかつ１枚でいいものが３枚に亘っている。再度出力を試みるが同じこと。それでふとプリンター駆動用ＰＣのディスプレイを見ると、目が点になった。「Spool32.EXEが不正な処理を行なったために・・・」という赤バッテン付きメッセージが出ているではないか。
ＰＣを再起動しても変わらず、ということはＯＳがやられたとしか言いようがない。しかしこの古いマシンは親元知らずの流れ物だけにリカバリＣＤはなし。隣のものからSpool32.EXEをコピーしようとしたら、常時動いているファイルのために上書きは拒否された。
仕方なく、別の行先が決まっていた余りもののIBM製Windows98ノートマシンを取り出し、代役として動かそうとした。ところがこちらもこちらで、起動中に電源が落ちる。何度も試みるが遂にはＢＩＯＳで引っかかってまた落ちる。そのうち、急に臭いがすると思ったらバッテリー付近から白い煙が・・・
慌てて電源コードを抜き、火事だけは防いだが、完全にお手上げ状態になった。
この時点で一旦冷静になるために、情シスに電話をして助けを求めた。その結果、スプールがおかしくなったマシンの「ウィルスバスター」を外すと解決するという話を聞いた。ウィルスチェックのために印刷スプール信号を横取りするので、印刷がタイムアウトを起こすらしい。そこで「ウィルスバスター」をアンインストールするが効果なし！
もうガックリである。しかしあることを思いついた。最後の望みである。現在職場の１名が長期出向中で、彼のＰＣが埃をかぶったままになっている。それを借りるべく電話を掛けて事情を話し、ＯＫを貰った。もう必至で環境のセットアップをし、プリンターを繋いで印刷テストをした。結果は成功、ヤッタ〜〜〜！！である。
しかしこれで２台のＰＣが壊れ、半日がつぶれた。脱力感が漂う。ハァ。
2003.07.02
１日目の上流側データが数十件流れてきた。ところが肝心の紙が回って来ない。仕事の性格上証拠としての紙が必要だからである（但し電子決裁ということで捺印は不要）。ところがこの紙の種類と部数を巡って上流側の運用が徹底されなかったために混乱。上流側キーマンは掲示板でアナウンスしていたが、見ていない連中に限ってわめく。こうなると収拾がつかないから「上流キーマンに聞いてくれ」と門前払いで急場をしのいだ。
一方のこちら側でも印刷がうまくいかないことが判明。原因はエミュレータソフトのパチ当てが必要だったものが、私のところへ連絡が来ていなかったためである。慌てて４台分のパチ当て実行。コノヤロー。
もうひとつ忙しかったのは、こちら側の運用手順を掲示板に上げる作業とＱ＆Ａ掲示板の準備。でもこちら側でも掲示板を見ないやつはまったく見ないだろうなあ、とひとりごと。
それにしても上流側から自分達の問題をこちらに聞いてくるヤツのなんと多いこと。予想はしていたが、火の粉は払わねばならない。実はそのために上流システムの使い方を会得しており、さらにすべてのＩＤとパスワードを貰っているのである。基本的には上流側の問題は受け付けないという姿勢なのだが、インターフェースの関係やデータ変更できる条件が複雑にからんでいるために、こちらが撃退できるだけの情報を知っておく必要があるためである。
2003.07.01
午前１０時から本番がスタートした。基本的な問題は発生せず、まずはめでたしめでたし。
ただしマイナーな問題が２点発見された。
ひとつは本番用マスターデータを追加しようとしたあるユーザーが間違ったＩＤでログインしてしまい、さらにその直後のリカバリーコマンドもこれまた間違えて、その端末とホストの接続がおかしくなった。
即座に本社情シスへ連絡、接続をリセットしたのでシステムのハングアップだけは避けられた。
ただ、この時に判明したのが、工場サイド情シス担当者のでたらめな仕事ぶり。割り当てられた端末番号の設定がでたらめなことがわかって、慌ててデータを変更した。設定をやったのは工場からも本社からも嫌われている男で、二言目には「それは俺の仕事じゃない」と言い、常に非協力的で有名なのである。またか、という感じだ。
次は上流側で、必要なデータの一部が印刷されない。原因は印刷オーバーレイから該当部分の変数定義が丸ごと抜けていたためである。今夜のうちにプログラマーが訂正をかける。
2003.06.30
本日で新幹線・陸蒸気システムの新規起票が終了した。以後は変更か取り消しのみとなる。新幹線システムはプログラムを変えて新規起票をできないようにしてしまうが、陸蒸気はプログラムを改変できる人間がいないためユーザーの良心に頼るしかない。
「のぞみシステム」は明日午前１０時から運用開始される。
2003.06.26
「のぞみシステム」ハード・ソフトのインストールがすべて終了した。後は本番を待つ。
だが、ここに来て上流側との運用調整についてまたもやトラブルが起こっている。
簡単に言うと、「のぞみシステム」のフレキシビリティーに乗じて、上流側が意図的に、本来あってはならない処理手順を密かに輸入しようとしていることが判明した。
例えば、１枚の買入伝票では１つの発注先を固定するのが常識である。ところが都合で複数の発注先へ分割発注できるようにしている「のぞみシステム」の機能に悪乗りして、買入伝票を最初から複数の発注先を指定しようとしていた。可能だからといってそれを常態化してしまうと運用する側は大混乱する。１枚の伝票がどれだけの会社と結びつくのか、データの見た目だけでは判断ができなくなるからである。
明日の午後はその類の運用について激論になりそうだ。
はっきり言って、緊急避難的ルーチンを常識にしてしまうと本末転倒になる。運用するのは人間だから、そこには人間の都合が優先することもあるが、自分「だけ」の都合をシステムに密輸入するのは許せない。もしそんなデータが来たら受付を拒否する、というのが「のぞみシステム」側ユーザーの姿勢で一致した。
2003.06.18
部内教育が終った。これで大きなイベントは終わりである。
それにしても、予想通り「おっさん」ユーザーは見事なパフォーマンスを見せてくれた。初っ端からホストエミュレータの起動コマンドを間違えてしまい、「動かない」と手を上げる始末。漢字変換もド下手の見本で、モタつくこと夥しく、時間割はどんどん遅れた。どうしようもないので、カリキュラムの一部を少しづつ割愛し、自習時間を多く取るようにして、それ以外のユーザーの練習ができるようにした。
それから６月６日に書いた「陸蒸気組」の直接の上流は、まだ運用が徹底せず、ユーザー教育もなおざり、担当者レベルも依然として女性に丸投げでソフトのインストールもしていないという噂を耳にした。甚だしいのは、子会社からも動かせるようにするはずなのだが、ソフトが置いてあるサーバーにアクセスできないまま放置されているという。そして肝心のユーザー教育も、最後の組は本番がスタートしてからの７月２日にやるという。ただただ唖然とするばかりだ。
こんな調子では、上流自身のソフトの質問が下流にまで来ることは必至だ。もちろんこちら側は「知らぬ存ぜぬ」で門前払いを食わせるつもりだ。部内にも「相手にするな」と指示を出した。
2003.06.14
本番まで残り約半月。私が担当する本番データの準備が終った。
しかし運用方法についてまたぞろ抵抗勢力が難癖をつけた。特に下流の部署の中で「経理」の管理職が「今までの業務手順を少し変えることや、新しい作業をやらされるのは絶対反対」と好き勝手な要求をあれこれ持ち出したのである。中でもいちばんひどいのは、一部の特殊なジョブ番号の管理を放置してきたことを頬かむりして、新システムにはすべての番号の登録が必須になったことに「そんな『抜け』はどこの工場でもやっていること」と居直ることまでやってのけたである。
さすがにこれには私も怒った。「放置するならどうぞ。文句が出たらそちらに振るからね」と。
本来なら経理とは昨年のうちに詰めを行なうつもりでいた。ところが忙しさを理由に話し合いをずっと延ばしてきたのである。それを実際の操作の説明会を行なったら途端に文句を並べ出したのである。担当者レベルとは仲が良かったが、昔からいけ好かない人間だったこの管理職、口も訊きたくないヤツである。
さて、来週は最後の部内教育。インストラクターは私で、教材データやマニュアルの準備も終った。ただひつだけ心配なのは、相変わらずキーボードと親しめない「おっさん」ユーザー数人で、なかなか前へ進めずに教育の時間割が遅れることである。
再来週は情シスが本番前のマスターファイルの整備やテストデータの消去などに忙しいため、一切の操作が禁止される。
2003.06.06
本番に向けての準備が着々と進んでいる。ところが今週になって思わぬ伏兵が出現し、火消しのために走り回る事件が起こった。
ひとつは、今頃になって「陸蒸気システム」のローカルルールを復活させようという話が再燃したことである。「のぞみシステム」はそもそも統合化のために出発したのであり、マイナーなローカルルールや手順は廃止して、代替手段で乗り切るという共通化の思想で貫かれた。それを最初から説明してあるのに、再び「何とかしてくれ」と言われてもどうしようもない。２件復活の話が出たが、一蹴した。
もうひとつの問題は、上流側システム、それも「陸蒸気組」の直接の上流にあたる連中の教育と普及が遅れていることである。いちばんひどいのは、今までＤＯＳ専用端末での操作をほとんど女性に任せっぱなしにしていた悪習を受け継いで、折角作った個人マシン用カスタムアプリをインストールしないまま放置していることである。要するにデータのＩ／Ｐを自分自身でやりたくないということを露骨に表明したのである。おまけに各部署の上司の連中もまったく啓蒙する意志がない。これではシステムが泣く。
これを聞いた経営幹部が本気で心配し始め、必要なら自分が乗り込んで陣頭指揮をすると言い出した。こちらの下流側は再来週に全員の操作教育（私が講師になる)を行なう。ホストエミュレータのインストールはかなり進んだ。本番データの整備もあと少し。残るは運用手順の徹底と上流側とのすり合わせである。
2003.05.28
ユーザー教育の２回目が済んで、これで今月の主なイベントは終った。これからは各地での巡回教育が行なわれる。来月に入ると私は「陸蒸気組」の「子供」をアシスタントに従えて「孫」達の教育を行なう。
と同時にマスターデータの整備、ハード・ソフトのインストール、特にホストエミュレータのインストールと設定をやらねばならない。
本番まで残すところ１ヶ月と数日。いよいよプロジェクトは佳境に入る。だが、今日はプロジェクトチームとＳＥとで大議論になってしまった。金にまつわる部分で、金額変更のために一時的に支払金が発生しない状態にすることに「危険すぎる」とＳＥが反対したのである。だがこれがないと上流側のデータ変更に支障が出る。それで揉めたのだが、当月内に必ずデータを復活させるという条件で受け入れて貰った。
本番直前で、なおかつ種々のテストを行なってもこのような問題が出る。だから電算システムの開発は恐ろしい。しかしこれでもまだいい方だ。「新幹線プロジェクト」の時はいきなり本番に入ったため、直後の数ヶ月で１００件以上の「虫潰しリスト」を作り、その後もパチ当てを繰り返して、安定稼動まで２年かかった経験がある。今回ははるかに少なくなるだろう。
2003.05.16
ユーザー教育の１回目が終った。中でも驚いたのが「陸蒸気組」の２人で、他の生徒と比べてずば抜けて理解が早かった。もともと私の推薦で選抜チームに加えたのだが、いちばん文化の落差が大きいので心配していたのである。しかし何よりも若いし、実務にかけてはさっさとこなすタイプなので注目していたのである。
だがひとつだけ困った話が出てきた。ウチのメンバー２人の内の一人が月末に行なわれる２回目の教育と出張が重なって、出席できないことが濃厚になったのである。講習の内容は今回が新規データを単純に処理する方法のみなのだが、次回は上流からのデータ変更をどう受け入れるか、またはルール上変更できなかった場合の上流からのクレームをどう反撃するかという応用問題をやることになっている。もしこれを外したら「孫」を指導できなくなるので大変なことになる。だから上司には出張させないようクレームすることにした。
ところで同時に行なった上流・下流とのデータの受け渡しだが、上流からの受け入れ以外は悲惨なものになった。特に下流にはまったく流れず、上流には業務上こちらで書き換えたデータを返すことになっているのだが反映されず、と無残な結果。ＳＥは原因究明のために休日返上となりそうで、頭を抱えている。
2003.05.14
１００人近いユーザーの中から十数人を選んで教育を行なうことになった。今日はその１日目。さすが選ばれた人間だけあって、一度説明すると後は自分で解決しようとする。
これで「子供」達が育っていく。しかし問題なのは一般ユーザー、すなわち「孫」達である。とりわけ話を聞かない「糞孫」には手を焼くことになるだろう。だから「じぃ」は安心できない。
これから週末まで「子育て」が続く。
2003.05.11
いよいよ今週は完成版「のぞみシステム」のテストとユーザー教育を行なう。そのために私をはじめとするプロジェクトメンバーは１週間、事務所に缶詰であれこれ作業をすることになった。中でもいちばん大変なのは上流・下流とのデータ交換で、正しいデータが渡るかチェックしなければならない。
2003.04.27
本番スタートが１ヶ月ずれて７月１日になることが決まった。
とにかくやっと本番環境が整ってデバッグがスタートしたばかり。もし６月だとすると１ヶ月でデバッグ・パチ当て・ユーザー教育をやることになり、これはもう物理的に無理である。そこで関係者の合意を得て幹部に報告、延期は「しゃあないなあ」との回答を得た。
現在私の机からホストにアクセスできるようになり、時間を見つけてせっせとテスト、掲示板であれこれやりとりをしている。先日はＳＥ、下請プログラマーが１ヶ所に集まって虫取り作業。私は３個の手直しと１個のバグを見つけた。バグはエラールーチンが正常に機能しないことであった。
さて、ゴールデンウィークであるが、私など実務サイドは休み。しかしＳＥとプログラマーはそれまでにリストアップされた手直し作業で忙殺される。ご苦労様である。
2003.04.18
「陸蒸気組」に対する２回目の説明会をやった。今回は１回目と違い、本番が迫ってきたので危機感があったのか割合とシビアな質問も出た。デモも本番環境そのままだからどこが問題かもわかり易くなった。
しかし１人だけ困った人が出た。上司のＦ氏で、原則論ばかり壊れたレコードのように喋り、時間を無駄にした。以前から個人的にも「ホストだから検索機能は別の世界で処理します」と説明してたのに、大勢がいる前で「問題だ、問題だ」と再び持ち出す始末。おまけにこの御仁、今までの説明会にも一度も出席せず、言いたいことがあるなら別途掲示板にでも書けばいいものを、公開の場でやたらスタンドプレーをする傾向がある。
そして本来ならルールとしては禁じられているが、実務上は使わざるを得ない方法をルーチンに組み込むことにも、再びケチをつけた。私としてはもう始末に負えない。もはやこれまで、「裸の王様」にして彼が言う「禁じ手」をそのまま使えるようにし、紙の上の規定にあろうがなかろうが、ユーザーにはその操作を教えることにした。そうでないと仕事にならないからである。
2003.03.29
本番も次第に近くなり、出来上がったデモ版に対してコメントをつける作業が始まった。しかしところどころで最初計画したイメージとかけ離れた部分が見えてきて、どうしても仕様変更をせざるを得ない部分が出てきた。
その中でもっとも驚いたのが、新幹線システムを作ったＳＥと私が、開発から７年も経ってからまったく認識していなかった特殊なルーチンが存在することに気付いたのである。
そんな状態だったから当然のぞみシステムには反映されていない。あわててそのルーチンを普段使っている担当者に問い合わせたら、「これを外されたら仕事にならないし、のぞみシステムは基本的に新幹線システムを引き継ぐと聞いているので外さないでくれ」と至極当然のことを要求した。さあ大変である。
おまけに、何故か陸蒸気システムには全く同一の機能が存在しており、プロジェクトの当初には「別のやり方で処理してくれ」と、いやがる相手を私が説得していたのだからこちらも真っ青である。
次回の会議では何とかそのルーチンを組み込む方向で（ＳＥも「しゃあないなあ」という態度である）解決することを提案するが、いやはや１年かかっても抜けがあることに冷や汗をかいている。
2003.03.06
やや不満は残るが、PowerPointによる各事務所でのプレゼンテーションをやった。ところが意外な反応に関係者が首をかしげている。
まず私の地元の「陸蒸気組」であるが、話を黙って聞いているだけで質問がほとんど出ない。本来なら旧システムとはまったく違う操作や画面になるので、相当な違和感を感じるものと思っていたが、完全に肩透かしを食らった。一説によれば、皆コンピュータについての知識が低くて、言われるままにキーを叩くことしか知らないために何の話をしているのかわからないのではないか、ということらしい。しかしこういう連中は実際に使い始めてから死ぬほど文句をつけるか、陰口をたたくのではないかと非常に心配している。
もうひとつ困ったのは、「のぞみシステム」の土台になった「新幹線システム」を使っている連中（これは私が前にいた事務所の仲間である）が、次々とクレームをつけたことである。それも単純に「今までのキー操作と違う！」ということばかりで、下らない抵抗勢力と化したのである。
他の事務所の連中と統合するのだから、当然どこかで妥協したシステムに変更せざるを得ない。私も「新幹線システム」を使ってきたから、この線までは譲っても支障はないというスタンスでプロジェクトを進めてきたつもりだった。そのお膝元の連中がまさか自分達のやり方に最も固執する勢力に変質するとは夢にも思わなかった。この事実に、私と「新幹線システム」の時代から開発をやってきた情シスのＳＥは愕然としている。
2003.02.20
まだ作成途中ということだが、いくらかのルーチンができたのでデモをしてもらった。ところが完成しているはずの部分でも画面が切り替わるたびにどこかエラーが出てしまう。実は開発担当ＳＥもソフトハウスから貰ったデモ版を動かすのは初めてだった。動かす前のマスターファイルを作るのに精一杯で、テストを兼ねて我々プロジェクトメンバーの前で披露することになったのであった。
本来ならデモ版を下げて各事務所でのプレゼンテーションをやるつもりであったが、どうやら画面のハードコピーを使ったPowerPointによる説明会になってしまいそうだ。
一方の印刷問題で経理が帳票減らしに合意した。驚いたことに今までBuisiness
Objectの存在すら知らなかった。しかし画面を見て納得したようだ。
2003.02.01
確定仕様書と画面遷移図のチェックが終わり、画面レイアウトも完成、２月末にはウチのホストに移植してテスト環境が整う。
その一方でいよいよ実際のマスターデータをユーザーサイドで作るのが忙しくなった。その際、困ったことにユーザーがExcelで編集したデータをホストに入れる作業が手間取ることが問題になった。サーバー系とホスト系の相性はすこぶる悪い。だからエミュレータでコピー＆ペーストできる程度のデータ数ならいざ知らず、数千のデータを転送するには特別にバッチソフトを作ることになるのである。これを情シス担当者が予定外の作業として快く思っていない。
また別途月報関係のホスト出力による帳票を削減する話も並行してやっている。印刷は馬鹿にできない。ホストのＣＰＵを使うのでその料金がむしりとられているからである。だからホストデータを別のサーバーＤＢに落としてからBuisiness
Objectで画面による検索・印刷に切り替えるのである。ただ帳票が減ることに経理が抵抗している。特に「陸蒸気組」の経理は「今までと同じ」ということに固執する極端な「抵抗勢力」なので、仕事のやり方まで変える新プロジェクトにいやな顔をしている。もっとも上からの強権発動には極めて弱いのでそこから攻め落とす手を使うつもりでいるのであるが。
2003.01.13
予定通り、確定仕様書と画面遷移図、さらには実際の画面レイアウトが９０％完成、ワーキンググループによる承認作業も終った。月末には残りも完成させていよいよプログラム作成の実作業が始まる。
２泊３日の集中作業で各メンバーはへとへと、おまけに使った会社施設の暖房がほとんど効かず、防寒完全装備となった。原因はエアコン能力の不足と、使った建物の作りがひどく、地面の上に打ったコンクリートに直接Ｐタイルを貼った床であるために、足元がまったく暖まらないのである。次回は絶対に別の部屋を使わせろと管理者にねじ込んだ。
2002.12.12
「虫つぶし」もほぼ終わり、いよいよウチのＳＥと外注先のプログラマーによる確定仕様書作りが始まった。
年末に初稿が完成したあと、我々が年明け早々に画面遷移図と操作・エラールーチンをチェックする段取りとなった。また並行してこちらがマスターファイルの具体的データを順次完成していく。
それとともにいよいよユーザーのリストアップ、端末用ハード・ソフトの数のカウントも開始した。ところがここに来て一抹の不安を感じさせる出来事が起こった。何かというとＷＡＮ回線のトラフィック量に対して回線がまだ細いような印象を受けるトラブルがあったのである。
ちょうど１年前ウィルスバスターＣｏｒｐを入れた時、パターンファイルのクライアント側更新に回線がパンクしたことを機に１ＭＢ／ｓ（ひょっとして１．５？）と太くしたのだが、先日のパターン更新でまたもや回線がパンクしたのである。そもそもの原因はトレンドマイクロからのパターン４０９が差分ファイルではなくてフルパックで送られたために転送量が異様に増えたためであるが、それでも大渋滞を起こしたのである。慌てたトレンドマイクロからは急遽差分にした４１０が送られた来たのだが、「のぞみシステム」が本格的に稼動したら、ホスト・サーバーなどの基幹ハードがある神戸地区からのＷＡＮ回線のトラフィック量が急増するはずであるから、今のままでは本番でパンクしてしまってシステムが動かなくなる可能性も出てきたわけである。
私の素人考えだが、ＷＡＮは３ＭＢ／ｓ以上必要だと思うのだが・・・
2002.11.14
今月の「延長戦」討議が終った。しかし来月も、そしてまた来年も延長戦が続き、そのまま本番突入ということになる可能性も出てきた。
いわゆる「虫つぶし」で毎回懸案事項を解決するのだが、その度に新しい関連事項の「虫」が見つかるのである。もうこれはもぐらたたきに似た泥縄状態で、いつ終るかゴールが見えない。そんな中、今回は本番スタート以降、運用に関する体制作りをどうするかを決めなければならいということがわかってきた。
しかしこれはまた頭が痛い。というのも明らかに私の負担がどっと増えるのは必定だからである。でも逃げられない。
さて、スタート後のサポート体制もそうだが、今の討議もなるべく掲示板を使って討論することを提案した。顔をつき合わせて討議することも必要だが、仕様書関係のたたき台は掲示板で先にコメントをつけてから討議にかけるほうが効率的だからである。
2002.11.08
「延長戦」はまだ続いいて、今月も缶詰討議が必要になった。
そしてその討議が来週開かれるという矢先に「新幹線システム」に「穴」があることがわかって、ちょっとした騒ぎになっている。
もともと新幹線組と陸蒸気組の仕事の内容はまったく違っていて両者の現場サイドでは今までまったく没交渉だった。ところがちょっとした経緯から新幹線組で余った部品を陸蒸気組で使うことになり、倉庫に保管してあった部品を持ち出して、その原価を陸蒸気組のジョブ番号へ振り替えることになった。そしてそのために新幹線システムを動かして手続きを行なった。しかし・・・
データの転送は行なわれず、原価データはどこかへ消えてしまったのである！！？？！！？？
原因は新幹線、陸蒸気両システム間を繋ぐプログラムが存在しなかったことと、連携できなくするためのエラーチェックがなかったためである。というか、そういうことがあり得るということを想定していなかったため、対策など最初から考えられていないという「穴」があったのである。
当面の処置としては、一筆を経理に書いて原価振替を依頼することになろう。だが「統合のぞみ化プロジェクト」にはこの点の解決策を反映しなくてはならぬ。
こういう問題に対してコンピュータシステムというのは面倒である。たとえ数年に１回しか発生しない操作でも、そのことを考慮に入れなくてはならないからである。こういう虫つぶしはこれからも続く。
2002.10.12
「統合のぞみ化プロジェクト」も後半戦に入った。これからシステム開発チームの仕事が本格化する。従ってユーザーによるワーキンググループの仕様確定作業は最終盤、今月末で会議の延長戦は終了する、というか終らねばならない。というわけで今月後半には３日間連続の缶詰討議を開催する羽目になった。追い込みの受験勉強のようで若干緊張している。
2002.10.06
突然の上からの意向に対しては、さすがに関係者が猛反発した。当たり前である。中には周囲から吊るし上げを食らうので止めてくれ、との悲痛な声もあった。
結局時間がかかって納期に間に合わないと思われる一部の改良ルーチンだけを後から開発する、という線で落ち着きそうだ。
しかしこの話は精神衛生上非常に良くない。
2002.09.27
夕方になって突然裏情報が入ってきた。
何とプロジェクトの事業部側情シス担当部長と本社情シス関係者が「時間も金もないから帳票だけ手直しして、新幹線システムをそのまま使いたい」と言い出したのである。開いた口が塞がらないと同時に、やる気を失わせる発言である。
よくもまあこんな発想が出来るものだ。こんなごまかしをやるなら最初から何もせずに新幹線システムを他の事業部に強権で押し付けたらいい。何もわざわざワーキンググループを作って検討する必要なんぞないではないか。
実は約７年前、新幹線システムを作るときに私も一部参画したのだが、その時も副社長に立ち上げ期限を報告したからその日は死守せよということで一部ルーチンは未完成のままシステムが走り出し、後でパチ当てを繰り返したためにひどい目に遭った苦い経験がある。しかし今回はもっと悪辣だ。要するに「靴に足を合わせます」どころか、「靴に足を合わせろ！」と言っているのと同じだからである。
2002.09.25
帳票類のレイアウトの仕事は大変時間がかかる。従って延長戦が続き、このままでは１０月でも終らない可能性も出てきた。しかし情シスの担当者は早く決めろと言う。何で帳票類ごときで・・・と思ったが、作業の途中で処理手順の抜けが見つかることが多いというのが彼の主張で、そして見事にそれは的中した。餅屋は餅屋、さすがである。
とは言いつつ、長いダラダラ坂を登らされているようで、途中でちょっと一休みしたいのだが、タイムアウトでゲームオーバーなどとは冗談でも言えない辛い日々が続く。
2002.08.29
しつこいようだが「陸蒸気組」の体質の話で、今度は情シスの担当者がのけぞってしまった。それも２つの話を聞いてからである。
ひとつは「陸蒸気組」幹部が、「のぞみプロジェクト」に対してジョブ番号のデータを渡すシステムが必要に（現在は手入力）なったのに、「そんなもんいらん！」と言い出したことである。「陸蒸気組」以外は既にこの営業が使うシステムを導入しており、毎日更新データを「のぞみシステム」に自動転送させて省力化するにはぜひ必要だったのである。ところがこのドアホ幹部は億単位の金を使って進行中の「のぞみシステム」のことを知ってか知らずか、僅か年間４００万円しかかからないものを「不要不急」とケチることに執心しているのである。
なんとか周囲が説得するようだが、歴史的に染み付いた体質の典型をまたもや見ることとなった。
もうひとつは「陸蒸気組」の上流。流れて来る噂では、上流システムを動かしているオペレーターのボスがこれまた難物で、システム更新にあたって今の画面構成や入力項目のひとつひとつにまで「今までと同じにしろ」と固執するらしい。
情シス担当者は、「新車を買ってシフトレバーやハンドルの形から位置まで前と同じにしろ」と要求するのと同じではないか、とボヤくことしきりであった。
2002.08.20
今日はまたもや「陸蒸気組」の体質を示す話を聞かされた。実は「陸蒸気システム」の蓄積データを利用した検索ソフトが数年前に入っていて、これが意外と重宝している。しかしである。話をつぶさに聞くと一部調べたいデータが入っていないのである。何故そんなことになっているのか関係者に聞くと、またもや「靴に足を合わせている」という答えが返ってきた。つまり限られた予算で買ったサーバーの容量に合わせて入れるデータの種類を決めたというのである。
本当にここの事務所は発想がすべて逆立ちしているし、おまけに文句があっても上に対しては絶対服従する風土が満ちている。まるで戦前の軍隊のようだ。
「統合のぞみプロジェクト」の集中討議は８月末までにあと２回また開かれる。その後はスポットになりそうだが、場合によっては延長戦もあるかもしれない。情シスの開発担当者は真剣に取り組んでおり、システム側から見た虫つぶしを必至でやっている。彼を殺すわけにはいかない。限られた残り時間、途中ででとんでもない問題が出ないよう頑張っているからだ。
2002.07.12
泊り込みの討議がまた開かれた。８月一杯までは月３回のペースで会議が開かれる。
今回は思わぬどんでん返しがあった。統合するはずだった下流側システムは独自路線で走ることになったのである。部署間の歩み寄りがなされず、「俺は俺、お前はお前」になってしまった。そのため、こちらからの中継システムから４種類のデータを送ることになった。開発担当のＳＥは呆れていた。
一方、こちら側ではコンセプトをほぼ決定し、マスターファイルの中身の決定や帳票のフォーマットなど力仕事が中心になる。
2002.06.28
一応スペックの基本機能の部分は決定した。そして同時に上流・下流側のシステムも統合化が決定し、これで来月からは詳細なフィールド定義やマスターファイルの内容を決めていくことになった。
だが、ここでひとつ逆転満塁ホームランが飛び出した。何と新システムのデータ移行ができなくなって、新旧システムが並行して運転されることになったのである。原因は下流側のシステムにこちら側のデータ履歴を持たないことがわかったからである。つまり旧システムはこちらで変更したデータを作成した上で必要なデータだけを渡す仕組みになっていたのだが、新システムは変更された後の生データを出すだけなので、差分データを発生させるための移行前のデータが存在しないのである。
まさか、こんなことになるとは・・・
2002.06.20
スペックの詰めが終盤に差しかかると同時にデータ移行をどうするかの話に進んできた。データコンバートの問題は本社情シスから「今からやらないと後で大問題になるよ」との提起があったものである。「陸蒸気」側としては基本的に移行したいとのスタンスで望むことになったが、５月２３日で書いた分室にコンバートの希望を聞いたらまたもや開いた口が塞がらない回答が来た。
実は分室が秋にこちらへ集約移転する話が持ち上がり、そうなると彼らは「飛脚システム」（あえてそう呼ぶほど古い、約３０年前のシロモノ）→「陸蒸気システム」→「のぞみシステム」と、目まぐるしく変わるために混乱するだろうと気遣って質問を投げた。ところが分室の管理職から返ってきた答えは、
「問題が複雑なので（何が？）情シスに一任（他人事かお前は！）します」
と、またもや投げやりな態度を示したのである。もうどうにもならん、この連中は _(++)/
2002.06.18
現有の「新幹線システム」と、それがどのようにバージョンアップされるかのグループ内での説明会を行なった。１ヶ所だけ想定していた処理ルーチンとは違う要望が出ただけで、予期していなかった質問とかリクエストでもめることはなかった。
同時に上流側からの要求項目がメールで届いたが、いずれも回答済みだったはずの内容ばかりで、中には「何故システムを変えるのか」などというお先真っ暗の質問も入っていた。速攻でこれまでのいきさつを再度書いたのは言うまでもない。こういう質問には繰り返し、かつ早めに反応しないとまずい。後でブツクサごたくを並べられても対処できないからである。
明日は再びワーキンググループの討議になる。しかし最近憂鬱に感じる事がある。原因は「陸蒸気システム」のみならず、今の事務所で使っている種々のシステム、ＯＡ化のレベルなどが全社的に見てあまりにも遅れていることを痛感させられるからである。
まず「陸蒸気システム」自身が１２年も更新されていなかったことを筆頭に、受注したジョブ番号の受注情報・原価を管理するシステムが全社的には１０年くらい前からほとんどのところに入っているのに、未だにカードに手書きだとか、目に余るひどさだからである。先日は電子出勤簿兼工数管理システムが導入されていないことで、他のメンバーから笑われた。
歴代の担当重役と総務・管理関係者がＯＡ化に徹底して消極的で、ＰＣを触るのは「遊んでいる」ことと同列の扱いしかせず、予算をケチってばかりいたためである。
2002.06.12
先月あたりから泊り込みでの「のぞみシステム」のスペック討議が続いている。６月末で基本構想を完成しなければならず、ワーキンググループメンバーは必至の思いで作業を続けている。しかし・・・
関係者の努力をよそに、上流・下流側双方には緊迫感がない。というのも両者の管理職には「統合化しなくてもいいじゃない」という声がチラホラ出ており、それで積極的に動こうとしていないのである。それ以来「のぞみ化プロジェクト」を推進している幹部は説得に走り回っている。そもそもこの話は重役にも説明し、統合化をするべしとの指示と承認が既になされているのに、上流・下流側にはそれがまさか自分の身に降りかかるとは思っても見なかったらしい。しかし中心部分のシステムを変えるのだからインターフェースが影響を受けないわけがない。そのあたりの認識の低さがこれまた足を引っ張る。
2002.06.03
今日陸蒸気システムの上流側まとめ役と話をしてまたまた驚いた。
そもそも陸蒸気システムを変更する話が関係者に十分伝わっていないうえに、彼らの大半はデータのインプット作業について何の興味も示さないというのである。しかし理由を聞いて納得した。
簡単に言うと、端末の操作は女性アシスタントに丸投げしているので気にならないのである。
データのＩ／Ｐが専用端末であることも災いしているのだが、本来なら各人がＩＤカードを持って必要なデータはその本人が入れないといけない。しかし実際はＩＤカードさえも女性アシスタントに渡すという完全なルール違反を、それも長期間続けているのである。
新システムでは個人ＰＣからの入力となるが、そういう輩はデスクトップから入力すべきＩＤとパスワードさえも再び女性アシスタントに渡してしまうのだろう。こういうセキュリティーの「セ」の字もない連中に限ってシステムが出来上がってからあれこれイチャモンをつけたがる。ホンマニ、どついたろか！
2002.05.23
作業ルーチンの洗い出しということで、事務所とは別のところにある分室に電話して、ここが使っている陸蒸気よりもさらに古いやり方でホスト機を使っている連中の作業ルーチンのパターン（一応同じとは聞いていたが）を教えてくれるように頼んだ。
しかし返ってきた答には正直びっくりした。
A)出来上がったシステムで作業する
（出来上がった靴に足を合わせます）
B)困ったことが起こったら、マニュアル対応する
（本件に限らず多少なりとも発生するはず）
という考え方で行きたいと思いますので、ご依頼の資料はお出ししない事にしたいと思います。
冗談ではない。自分たちがやっている定型的作業がはっきりしなければそもそも電算化など無理である。それを「出来上がったものに合わせる」というのでは議論にならない。おまけにもしメニューに存在しないルーチンが出てきたら泣きついてくるのは目に見えている。もし手作業になったら下流に対してのデータに洩れが発生して大問題になることは必至である。
こんな連中を相手にすることになるとは思わなかった。
2002.05.22
一泊して缶詰状態の打ち合わせを行なった。一つの結論として「新幹線システム」のバージョンアップという線が打ち出された。予想通りである。
私としては手馴れているシステムだけに歓迎である。だが他のシステムを使っている人たち、特に身内で「陸蒸気システム」使っている連中に納得して貰うことが急務となった。これが一番気を使う。
幸いにも「陸蒸気システム」はコケたり、文字化けを起こすことなど日常茶飯事で、そういう下らない事に神経をすり減らしていたから基本的には喜ばれるものと期待している。ただ、難点をひとつだけ挙げれば、サーバーだけの一気通貫からホストとサーバーに分離されるために起こるデータのマッチングの一日遅れで、これは不満が出るかもしれない。
明日から新幹線にはないルーチンをどう取り込むかの洗い出しとその解決方法の検討に入る。
2002.05.17
次の打ち合わせのために準備作業をし始めたが、悩ましいことに突き当たった。当たり前のことではあるが似た仕事で似たシステムが４つとは言え、やはり微妙に違うのである。前回現状のシステムを互いに紹介し合って比較作業を始めたらあちこちでそういった違いを発見した。特に作業手順の分類がバラバラなのは厄介である。おまけに分類を統一するとなるとこちら側の関係部署まで巻き込んで手順が変更になることを周知徹底しなければならない。
とりあえずは共通した作業ルーチンを整理し、各事業部から要望や改善を持ち寄ることで進めることになった。それが済んだら次はフィールド定義の共通化である。
それにしても手間がかかる。若いときＤＢを作った経験では自分ひとりの作業だったのでいきなりコーディングに入っても良かったが、共同作業では歩調を合わせないと大変なことになる。とりあえずいくつかの提案スレッドを掲示板に上げた。それもワーキンググループ向けとこちらの事業部内部に向けてのものとの２種類である。どちらかのペースに合わせるなら簡単だが、調整しながらでないといけないので手間がかかる。
2002.05.09
ワーキンググループの第１回会合が開かれた。現在４つもあるシステムの概略紹介、今後のスケジュールについて打ち合わせをした。
実務レベルのメンバーの他に顔見知りのＩＴ推進担当部長が加わっているのだが、彼の頭にはやはり現在の新幹線システムがあるようだ。というのも現状での最も安定し進んだシステムで、廉価かつ短期で完成できる見通しがあるからである。だが最大の難点はサーバー系とホスト系の混在とともにホスト系のＤＢが陳腐化し始めていることである。もしこれを最新のＤＢに変えると金も納期も大変なことになると予想されている。
次回はそのあたりを含めて泊り込みの論議をやることになりそうだ。
2002.04.25
連休明けに「統合のぞみ化プロジェクト」発足後、第１回のワーキンググループの会議が開かれることになった。議題はとりあえず各事業部での現状報告で、まず互いのシステムを知ろうということである。うまくいけば土俵をどうするかの合意が出来るかもしれないが、可能性は低いだろう。だがこれだけははっきりしている。「陸蒸気システムは共通の土台にはなり得ない」
2002.04.18
やはり話は本当だった。概算でも１億円は下らないプロジェクトにエスカレートすることは必死なのにどういうつもりだろう？
おまけにスケジュールとしては７月くらいから準備作業で、８月に重役の最終的決裁というから呆れる。おまけに金額を聞いたらドタキャンされてしまう可能性だって否定できない。
しかしこちらとしてはそんな悠長なことをされては大変なことになる。ＧＷ明けに詳細な方針のための会議が予定されていて、私もメンバーとして加わるのだが、どういうシステムになるかはともかく一刻も早い決断を催促するつもりである。陸蒸気組の溜息を背中で聞きながらこの先どういう方向になるのか、私もちょっと苛立たしくなってきた。
2002.04.16
今日上司からの内輪話としてとんでもない話を聞かされた。
「のぞみ化プロジェクト」を他事業部との共同開発に切り替えろと、上層部が言い出したらしいのである。いわばＪＲ各社の共通設計にするようなものである。それも現在４種類のシステムが走っているのにである。スタートは来年４月。
えらいことになりそうだ。来年４月だともう走らなくてはならない。しかし４つのシステムの綱引きになることは疑いもなく、私の見解としては今使っている「新幹線システム」が出来がいいだけに、それを中心とするのだろうがホスト機である上に土台になっているデータベースが陳腐化しかかっているからこれは厄介になるだろう。
統合化の話は当初から危惧していたが、上層部が話に割り込み始めたら簡単には引き下がるまい。あさって上層部のスタッフが来るので真意を確かめようと思う。
2002.04.10
Ｆ社との再度の打ち合わせ。導入スケジュールとしては５月より設計開始、、盆休み前に完成・・・と行きたい旨の希望を伝えた。もちろんそこからの遅れは覚悟した上での話であるが。
設計工数は３種類に分けて一画面いくらということで計算することを合意。
最大の難関はシステム仕様書であるが、現有のマニュアルとフィールド割付表だけで十分との回答。ほっとした。私としてはいきなりコーディングということしかやったことがなく、フローシートを書くという経験がまったくなかったからである。何しろ現在のＤＢはＰｒｏ−ＩＶという変なソフトで、作った本人は既に退社してソースは不明。情シスのハイレベルのＳＥでさえ読めなかったというものだけに不安があったが、現有の書類だけでもいけるとＦ社の担当は断言した。
今月末までに私のほうからバージョンアップする部分をリストアップして提示することを約束した。それから約１ヶ月で画面サンプルを作るという。いよいよ車輪は回りだした。
2002.04.04
金曜日の会議が急遽変更になって今日開いた。
私の予想通りの問題点が指摘された。それほど複雑な処理をしているシステムではないので、当然といえば当然。
それにしてもびっくりしたのは１０年使っていて安定しているはずなのに時としてデータが狂うことがあること。悪いことに当時の開発担当は既に会社を辞めていて何が原因か不明。特定のルーチンで発生するようなのでプログラムのバグとも思えるのだが、未だに虫取りができていないとはとても思えない。もっともハード・ソフトともに更新するので再現することはあるまいが。
来週はＦ社との打ち合わせ。
2002.04.02
決算も終って落ち着いたので関係者を集めて現システムの不満を語って貰うことにした。金曜日に会議を開くつもりだが、実は陸蒸気システムを触ったこともなければマニュアルも読んだことがない。慌ててマニュアルを読み出した。
簡単なデータベースだし普段の仕事の流れを知っているので苦労はしない。おまけに１本のデータベースだけを使っていて他のファイルとのリレーションを組んでないだけに例外処理が非常に弱いことがわかった。
細かいことはこれから詰めるが、前回も書いたように「そんなことができるわけがない」との先入観を捨てて貰うことに注力しないといけないようだ。
2002.03.26
見積をしてもらったＦ社から電話があり、こちらの態度を打診してきた。ちょうど決算の時期でもあり、４月に入ってからもう少し詳しい話をしようかということになった。
掲示板に対する書き込みは非常に少ない。その原因に陸蒸気で１０年も慣れているせいか、世の中にはもっとすごいものが走っているということを知らず、もっと高いレベルのデータ処理ができるということに思いが至らないらしい。
2002.03.07
掲示板にスレッドを立ててから１週間、やっと１つ目の書き込みがあった。
だが中にある用語はその人物だけしか理解不能なものばかり。多くの質問を投げかけることになった。
2002.03.06
先月２７日の打ち合わせをもとに見直した見積書を受け取った。ところが数字に間違いがある。
何しろ自分で認める「コンピュータは詳しくない」営業。しかし社内で作った数字くらいちゃんとチェックせんかいっ！
本命視している会社なのに、これでは・・・不安が頭をよぎる。
2002.02.28
部内の掲示板に新システムに関するスレッドを立てて意見募集を始める。
2002.02.27
新しいシステムの見積を頼んだＦ社（富士通ではない）を呼び、いろいろ質問をした。
概略としてはSQL2000サーバーにデータベースを入れ、Windows2000サーバーにウェブプログラムを入れてクライアント機とはイントラネットを通じて交信する。クライアント側からはインターネットエクスプローラーでHTTPSプロトコルによる操作。クライアント機は約１００台。蓄積されたデータの一部は定期的に本社のホスト機に転送される。
費用は数千万円。
