少し邪(ヨコシマ)かもしれないが・・

業務で「情報を共有する」という場合、昔ならAccessでというのもあった。今だとバックにフリーのDBとか用意してWebブラウザでやったりするものも多い。ASPのサービスなんかもそう。

ただ、ブラウザはその名の通りブラウジングするところから始まっており、閲覧には便利だが入力や編集という点では使い勝手がよろしくない。表形式のデータを見て、更新するならやはりExcelなどの表計算ソフトが便利である。

実は、過去に業務の進行管理をするシステムをExcel＋DBで作ったことがある。業務としてはルーチンワークのもので、仕入れたモノ（すべて一品もの）がどこにいくらで売られ、ということを管理できるものだ。月に数万件のデータ入力と閲覧をこなしていた。あのときの技術を使えば今回やろうとしていることのほか、ブラウザで扱いにくい一覧形式の編集を担うソリューションとして提供できる。

これ、汎用的に使えるよう、つまり、ユーザーの好みに応じて項目を指定できるものを生成できてしまうようなものとして提供したくなってきた。Frameworkよりもやる気が出ている。
しかし待て。これをやるには、これ向けでもいいからFrameworkを作りながらの方が後々ラクだ。

ということで、Framework作成を行いつつ、作りたいモノを作ることにした。みんなが使えるモノという視点より、私が使いたいもの、という視点でまずは進めていく。

1/24 α版リリース予定

構造をどうするか、云々を考えるとなかなか公開するのに躊躇したが、走りながら考えることにした。
今週末は別件があり、それを片付けないといけないので、その翌週、翌々週に作業を進め、α版を出そう。

予定より遅延して申し訳なく思う。が、この期限は何としても守ろう。

業務が分からないときは寸劇をしてみる

エンジニアは想像力が乏しいのか、業務のシステムでもすぐ技術で考える。

例えばこんなこと。
・氏名漢字を入力する際、フリガナを同時に入れて欲しいと言う要望に対し、「ふりがなが必ずしも正しく入る訳ではないのでできない」という回答を用意する。100%うまくいくはずないが、八割程度はそれで対応し、残りを訂正することで対応することが必要なくらい、業務をしている人は分かっているということが理解できていない。
・社内ヘルプデスクで、電話はすぐに出るがメールは３時間に１度のチェックとする、と定義する。メールと電話が重なると困るから、とのことだが、電話は割り込みでその場で対応が必要だが、メールはそうではない。よく分からない業務設計になっている。

これは、「経験がない」からに尽きるのだと思う。

そんな時、実際にどうなるか、試せるなら試せばいいが、状況が読めない場合は数人で役割分担をしてシミュレーションという名の寸劇を演じてみるとよい。
テレビで見たことがあるが、営業開始前のホテルやコンビニでよく行われる教育手法のようだが、これを実施することで運用ルールで済むこと、システムが甘いところ、想定していない動きがされていること、などが顕在化するだろう。

いくらアタマで考えても気がつかないことを気付かせてくれるきっかけにもなり、視野を広げるにもいいだろう。特に経験のない業務システムの場合はやって損はないだろう。