全4946文字
PR

 このモデルは『業務別データベース設計のためのデータモデリング入門』(渡辺幸三著、日本実業出版社)で提唱された表記方法を使って記述している。この本は私が基幹システムの内製に挑戦するきっかけとなった名著である。

 設計の根幹を見直し、それに合わせて、いったんつくったシステムのうち、工程管理のプログラムとマスタテーブルをつくり直し、関連する他のテーブルの参照方式も改めた。在庫管理の画面も変えたがそもそも完成度が高くなかったので変更の手間はそれほどではなかった。それ以外はここまでにつくってきたものを利用できた。

システムを押し付ける態度になっていた

 開発が行き詰まった理由の2番目は孤軍奮闘しているうちに、システムを押しつける態度に私がなってしまったことだった。開発が遅れ出したこともあり、見切り発車のような形で開発し、現場に提供するようになってきた。

 プロジェクトメンバーのうち、営業事務2人、製造事務2人、総務(経理)1人に利用者の代表として、できあがった機能を使ってもらうのだが「こういう状況ではこの画面のこのボタンを押してください」と私が一方的に説明することが多くなった。

 しばらく使ってみた5人から「ここが使いにくい」「業務と合わない」と指摘があった場合でも、言われた部分をとにかく修正し、「直しました」と返すだけになっていた。開発者の私と利用者の間のやり取りがそっけないものになり、システムとしての質がなかなか上がっていかない。

 事務職の5人、アシスタントに入ってくれた旧システムの管理担当者1人、6人とも女性であった。彼女たちは優秀であり、業務を熟知していたし、協力もしてくれたが、開発がうまく進まなくなると、どうしても事務職対開発者、女性対男性という構図に陥りがちだった。

 本業をそれぞれ持ちながらシステム開発にも付き合ってくれている彼女たちに「困っているのでなんとかなりませんか」と素直に助けを求めにくい雰囲気もあった。また、男性になら気楽に言えるが女性に言いにくいこともある。旧システムの開発会社から当初きてもらったアドバイザーも女性だった。つまりチームに男性は私しかいなかった。

打開策は業務マニュアルを書く専任者の配置

 設計方針を見直し、仕切り直すにあたり、マニュアルを書く専任者をプロジェクトメンバーに入れてもらった。九州にいて営業を担当していた同僚である。私がいた大阪本社とは離れていたが同年代ということもあり、出張の際に飲みに行く程度の付き合いをしていた。たまたま彼が転職を考えていることを知り、上長を通じて開発を助けてもらえないかと私から頼んだ。

 彼は社内の事情に一通り通じていたし、前職でPCパーツ販売店にいたことからPCにも詳しかった。幸い、私の希望が通り、彼は転職活動をしばらく延期してくれることになった。

 何をどう手伝ってもらうかについて彼や他のメンバーと相談し、マニュアルをつくり直してもらおう、という話になった。それまでは私がシステムを開発し、マニュアルも書いて現場の人に渡していたが「これを見てもさっぱり分からない」と言われていた。