OJTコーナー

パートスタッフのレクチャーを受ける（1）　〜基幹システムのトラブル〜　の続き

すべり出しは順調。続いて彼女は印刷専用のファイルの設計に入りました。この調子だと設計作業も早く終わるかもしれないので、次の仕事も用意しておかなきゃと考えていました。 ところが、その後弊社がe-learning展に出展することやサイトの10万アクセスのイベントを企画していたことで、人手が不足していました。そのため彼女にも、挟み込みでそちらの仕事も請け負ってもらうことになりました。 印刷専用ファイルの完成が遅れてしまうのは仕方なかったのですが、時間を調整しながら併行してやってくれているようだったので、そのうちでき上がるだろうと思っていました。 ところが、7月中旬が過ぎても完了報告があがりません。みんなが完成を待っている状態だったので、さすがにちょっと気になりはじめました。ですが、私は不在のことが多いし、フロアも違うのでなかなか話す機会がありません。 やっと何かのついでのときに「印刷用のファイルのほうはどうなってる？」と聞いてみたところ、「はい、それもやっているんですが......。伊藤さん、これは簡単だって言われてましたよね」と聞き返されてしまいました。 「うん。そんな面倒じゃないはずだよ」 「う〜ん......、じゃあ、もう少し考えてみます」 何か迷っているようではありましたが、その場は時間もなかったので、そんなやり取りだけで済ませてしまいました。

8月半ばになってもまだ完了報告があがりません。その間、挟み込みで入った仕事のほうは次々完成させてくれていましたので、生産性が低いというわけではありませんでした。また、ときどきそっとパソコンの画面を遠目にのぞくと、ファイルの設計にも取り組んでくれているようでしたので、待つしかありませんでした。
しかし、最終出勤予定日が近づいてきていたので、さすがに「今、どこまで完成してる？」ときいてみました。すると、完成のメドは立っているようではあったのですが、開発状況を簡単に説明してもらうと唖然としてしまいました。
私がイメージしていたのは、印刷対象に抽出したデータを標準的なインポート機能で取り込んでくるだけのものでした。ところが彼女が作ったものは、取り込み作業をスクリプトで制御してあり、そのために取り込み前と取り込み後に複雑な処理がかませてありました。
確かに機能としては成立しています（また、プログラミングの定石なのかもしれません）。しかし、そういう面倒な方法を用いる必要があるとはとても思えません。こんなことやってるから時間がかかっていたんだ、と思いましたがそれはぐっと飲み込み、「なぜそういう方法をとったの？」ときいてみました。

「いや、最初は簡単にやってたんですが、あとでいろいろ考えて、こっちのほうが確実かなと思って......」と要領を得ません。この場で簡単に説明できない理由があるのかなと思いつつも、それ以上の説明は求めませんでした。出勤予定日があと数日しかないため、ここで詳しく説明を受けても今さらやり直しを指示するわけにもいかないからです。
そこでは「よく考えたね」とねぎらいの言葉が口から出ましたが、ちょっと白々しいほめ方だったかもしれません。
実際、そのスクリプト自体は発想も面白いし、非常に良くできていました。私だと思いつかない方法です。
しかしそれにしても、「まるで横浜から渋谷に行くのに、北京経由で行くようなものだ」と思えてしまいました。

また、彼女にやってもらう作業は、データを取り込んで印刷準備をするところまででよかったのですが、実際は複数のレイアウトごとに印刷する処理までが自動化されていました。印刷するものは、送付ラベル、ハガキ、一覧表が数種類ずつ、さらに案内文などの定型差し込み文書が数種類です。これらのレイアウトの切り替え、用紙設定の変更などを考えると確かに自動化されているほうが便利です。
しかしあまり自動化しすぎると「各自が自由にレイアウトを追加修正できるようにする」というねらいを満たせないのではないかという心配もありました。
そうはいっても、処理の手順はともかくファイルの機能はすべて満たしています。最終出勤日までもう何日もないこともあり、今の延長で仕上げてもらうことにしました。
ただ、操作画面がわかりづらい部分があったので、そこだけ「こうしたら」とアドバイスをしておきました。

予定していた最終出勤日がきたとき、まだ少し不具合が残っていましたが、彼女は出勤日を延長して最後まで仕上げてくれました。また、ファイルの使用方法や新たに必要なレイアウトが増えたときの追加手順などもマニュアルにまとめ、他のメンバーに案内してくれました。
ただ、本来であれば、ファイルの構造がどうなっているのか、どんなスクリプトを作ったのかなど、私が引き継ぎを受けておくべきところだったのに、お互いに時間がなかったこともあり「あとで中身を見ておくからいいよ」と言って引き継ぎをせずに済ませてしまいました。

そして彼女はSARS禍ではじまった長い夏休みを終え、北京に戻っていきました。
私はその後も相変わらず日常業務に追われていて、そのファイルを細かく点検できないまま時が過ぎていきました。他のメンバーは、使いはじめ多少戸惑いもあり、いくつか私に質問も出てきたのですが、それなりに便利に使えているようではありました。
ただ、私が早く中身を理解し、質問や不具合が出たときに判断や修正ができるようになる必要はありました。また、今後そのファイルを維持管理する担当者を決め、私から引き継いでおくべきだとも感じていました。

そうしたある日、北京からメールが届きました。北京に戻ったばかりなのに、ビザの関係で 出国命令を出されてしまったというのです。このさい一旦フランスに行くつもりだけど、そこでお金を使い果たすので、その後日本に戻って2、3週間またパートで働きたいということでした。
仕事はたくさんあるので来てもらうことにし、ついでに例の印刷専用のファイルについても、必要な手直しをやってもらおうと考えました。

手直し個所を指定するには、私自身がファイルの中身をきちんと理解する必要があります。そこでやっと重い腰を上げ、ファイルの中身を点検することにしました。
ファイルメーカーProの場合、「フィールド定義」というところを開くと、だいたいどんな処理をやっているファイルか見当がつきます。ところがこのファイルには、似たような名称のフィールドがたくさん存在し、フィールド自体にはあまり関数も使われていないので、何のためのフィールドなのか確認できません。ただし、このファイルでやりたい機能を実現するには1、2カ所やっかいな部分があるはずなので、それをクリアするためにこうなったんだな、という程度の推測はできました。

フィールド定義に関数が少ないということは、スクリプトで制御させているはずだと思い、今度はスクリプトを確認しました。すると、こちらでは複数のスクリプトが入れ子状態になっていました。1つひとつ追跡していけば何をやっているのかはわかるのですが、時間もないため、これは聞いたほうが早いやと思って、その場は断念してしまいました。

パートスタッフのレクチャーを受ける（3）〜原因の所在〜 　に続く