私の大学時代の指導教官 (Prof. Nikolay N. Mirenkov) は、このようなフレーズをよく口にしていました:

これは要するに、「間違えて欲しくない操作を受け付けるシステムは、そもそも間違えることができないようにするべきだ」という主張です。

ソフトウェア工学において、ユーザインターフェイスの設計は重要な研究課題のひとつ。 人間工学などの観点を取り入れ、それを使う人間にとって、より負担の小さい、「自然な」システムを作るための知見や方法論が積み重ねられています。 例えば、「フールプルーフ (バカ避け)」と呼ばれる設計思想などがここに含まれます。

ところが、現在のIT産業の現場を見渡してみると、こうしたソフトウェア工学の概念あるいは技術が未だ充分には浸透していないように観察されます。 顧客に向けて便利で快適なシステムを提供することに腐心する一方で、自分たちの日々の業務に関しては、時代錯誤的とも言えるほどに原始的で不便な仕組みが採用されている現場は意外に多くあるもの。 これぞまさしく「紺屋の白袴」というやつです。

一日の終わり、あるいは週末や月末といった業務の節目にあたるタイミングごとに、作業レポートなどの定時報告の提出が求められている職場は多いのではないでしょうか。 大抵の場合、そうしたレポートの書式はテンプレートファイルなどによって定められているものの、前回提出したファイルをコピーして必要な部分を書き換えたものを今回分として提出する、といった運用がなされています。

そうなると、レポート提出に際してまず行われる操作は、ファイルのコピーとリネーム。 次いで、ファイルを開いて、ヘッダ (あるいはフッタ) 部分に記載されている日付の修正、といった具合になるでしょう。 日付だけでなく曜日の記載もあれば、そちらも手動で修正する必要があるかもしれません。

さて、この作業こそが「誤りを犯すチャンス (chance to make mistake)」のひとつである、ということに、読者の皆様はお気付きでしょうか。 月をまたいだときに、「日」の部分は "01" に戻したものの、「月」の部分を直すのを忘れてしまう。 (ディレクトリが月ごとに分かれていると、ファイル名の重複などが発生しないため、その場で気が付かない。) あるいは、前週の金曜日から土曜日, 日曜日と二日の休みを挟んでいるのに、その翌日である月曜日の日付が一日分しか進んでいない、といったミスには殆どの人が遭遇したことがあるでしょう。

上記のようなコピペ運用に加えて、同じ情報を何度も入力させることもまた、誤りの発生源となります。 私は以前、自分の勤務時間を毎日4ヶ所に入力しなければならない現場に入ったことがありましたが、それぞれの入力ファイル/画面上での配置や書式が異なっていたため、食い違いなくデータを記入するために (それなりに) 神経を使いました。 各作業員が留意に努めて、一日あたりの記入ミス発生率を0.5%まで抑えたとしても、20人がいれば、そのうちの誰かが間違える確率はおよそ一割。(1 - 0.995²⁰ ≅ 0.095) 平均すれば10日に一度は集計にエラーが紛れ込む計算になります。 実際、そうしたトラブルはたびたび発生し、ミスをした人への「注意」や「指導」が頻繁にオフィス内を飛び交っていました。

そもそもの問題は、「食い違っては困る」大切なデータを「食い違った状態にできる」業務フロー/システムにあります。 そうしたデータは本来、ただ一度だけ「マスタ」として入力させた上で、出力や集計の用途に合わせて「加工」して使うべきもの。 そうすれば、プログラムにミスがない限り、複数の帳票上で数値が食い違うような事態は起こりません。 プログラムのミスもしばしば発生はしますが、一度修正してしまえば、次からは気を付ける必要そのものがなくなるというのが素晴らしいところです。

そしてまた、そうしたデータの入力・加工をシステムによって支援させることには、ミスの発生を防ぐだけでなく、その作業を行った人間だけが持っているデータ (作業内容や申し送り事項, 所感など) の記入にユーザを集中させる効果もあります。 人間の労力は、人間にしかできない (コンピュータにはできない) 生産的な活動に振り向けるべきでしょう。 コンピュータにできるようなことは、コンピュータにやらせておけばよろしいのです。

また、このようなレポートファイルの配置にも問題が潜んでいます。 同じ部署に所属する鈴木氏と須藤氏の日報および月報のファイルがおかれるディレクトリの構造は色々と考えられますが、例えば以下のようなディレクトリ分けがなされていると考えてみてください。

鈴木氏:

/開発部/第二開発課/鈴木/日報/2014年/05月/2014-05-12.txt

/開発部/第二開発課/鈴木/月報/2014年/2014-05.txt

須藤氏:

/開発部/第二開発課/須藤/日報/2014年/05月/2014-05-12.txt

/開発部/第二開発課/須藤/月報/2014年/2014-05.txt

こうすると、各社員は自分の名前の付いた単一のディレクトリ以下だけを管理すれば良いので、提出すべきレポートの種類が増えたとしても、負担の増加は比較的小さく抑えることができます。

しかし、その一方でこれを取りまとめる集計者の立場 (これらのレポートファイルは前節で述べたような自由記述が可能な形式であるため、プログラムによる自動集計は行われていないものと仮定) から見るとどうでしょうか。 各員のレポートを横断的にチェックしようとすると、それらのファイルが格納されたディレクトリの間の距離 (移動に要する操作の回数) が長くなってしまうことは容易に予測できるでしょう。

そこで、集計者の手間を省くため、ディレクトリを分けを次のように変更したとします。

日報:

/開発部/第二開発課/日報/2014年/05月/2014-05-12-鈴木.txt

/開発部/第二開発課/日報/2014年/05月/2014-05-12-須藤.txt

月報:

/開発部/第二開発課/月報/2014年/2014-05-須藤.txt

/開発部/第二開発課/月報/2014年/2014-05-鈴木.txt

すると今度は、各員が各種レポートの記入や管理のために移動するべきディレクトリ間の距離が増えてしまいました。 しかも、このファイル配置の問題はそれだけではありません。 鈴木氏と須藤氏を含む第二開発課のメンバが各自の日報や月報のファイルを同じディレクトリ内に置くことができるようにするためには、そのディレクトリに対する書き込み権限を全員に与えることになります。 そのため、鈴木氏が須藤氏の名前でファイルを作成したり、須藤氏が作成したファイルを削除したりといった操作も可能となってしまいます。

全員のレポートファイルを Excel ワークブックにまとめ、各メンバが自分の名前が付いたシートに記入していくといった運用もしばしば見られますが、この場合も同様に、他人のデータを自由に閲覧・編集できてしまうという問題が発生。 さらには、一人が記入している間はファイルがロックされてしまい他のメンバが記入を行うことができない、編集操作の衝突によってデータが喪失する、といった事態が頻繁に起きることにもなります。

こうした不正・不都合な操作は、悪意を持って故意に行われるだけではなく、むしろ単純なミスによって引き起こされる場合が殆ど。 しかも、運用手順 (ディレクトリ移動などの操作) が複雑になればなるほど、そうしたヒューマンエラーが発生する余地は大きくなっていきます。

10年前は、こうした業務上のレポート類が紙ベースでの作成・提出が課せられる現場が多く、「そんなものメールで送ればいいじゃんかよ」などと思ったものですが、現在ではメールによるレポート提出が当たり前に行われるようになっているわけで、IT業界もゆっくりとではあるものの進歩している様子。 しかし、ひとつの問題が解決されると、また新しい不満が出てくるのは技術者の習いでしょうか。 今は逆に「もういい加減に電子メールでのレポート提出は止めてくれないかな」と思っていたります。

電子メールは、形式に制約のない、人間が読んで理解するためのテキストをやりとりすることを想定して作られたプロトコルであり、プログラムなどによって自動的に処理されるようなデータを扱うには基本的に向いていません。 (一般的な電子メールクライアントを使用する場合は特に。) システムからリマインダやアラームなどとして自動送信されるものは別として、電子メールがルーチンワークとして送信される状況があるとすれば、それは業務フローの設計に不備があることを示しています。

もしあなたが毎日、しかも一日に何通も同じ宛先に向けて、規定された書式の表題・内容でメールを出しているのだとすれば、それは明らかに省くべき労力。 先に述べたような日付部分の修正でミスをしたことはないでしょうか。 新しく加わった担当者のアドレスの追加を忘れたことはないでしょうか。 目視で内容を確認しながら修正するのにどれだけの時間がかけられているでしょうか。 そんな不便で不確かなテクノロジーにいつまでも依存していられるほど、あなたは暇ではない筈です。

こうしたエラーの殆どは、適切にシステム化することでその発生頻度を劇的に減らすことのできるもの。 それにも関わらず、なぜ多くのIT企業は未だに非合理的・非効率的な業務フロー, 業務ツールを採用しているのでしょうか。 その理由として必ずといってよいほど挙げられるのが「コスト (費用)」の問題です。 曰く、

• 「グループウェアやERPパッケージを導入する予算がない。」
• 「社内システムを作っても売上にならない。」
• 「業務効率をシステム化によって改善しても、その投資に見合うだけの売上の増加が見込めない。」

確かに、企業が営利を追求するものである以上、コストの問題は無視することのできないもの。 しかしながら、私にはこうしたコスト論の多くが「コスト」あるいは「ベネフィット (利益)」として認識しているものの範囲が狭いように思えてなりません。

私が見てきた範囲でも、「最初は大変かも知れないが慣れれば問題ない」「担当者がきちんと注意すればよい」と語るマネージャが幾人かいました。 しかし、慣れるための手間と時間もまた「コスト」であることを忘れてはいないでしょうか。 しかもそれは、一度支払えば終わりのイニシャルコストではなく、人員が追加されるたびに発生するランニングコスト。 また、人間は誰しも注意力・集中力を必要とする作業をこなせば、精神的にも肉体的にも疲労するもの。 疲労した状態では作業の質も効率も避けがたく低下するわけで、その損失も「コスト」に含めて考えるべきでしょう。

こうしたコストは、会社が成長し、従業員の数が増えれば、その分だけ大きくなっていきます。 そうした事情を考え合わせれば、一度に業務のすべてをシステム化するほどではなくとも、可能な範囲で持ち出しの投資をしても損はしない筈。 というよりも、人数が少なく小回りが利くうちに始動しておかなければ、将来に禍根を残すものだろう、と私は考えています。

とは言ったものの、実は前節で挙げたシステム化への投資例のうち、グループウェアやERPパッケージの導入は、個人的にあまりお勧めしません。 その理由は色々あるのですが、一言にまとめると「ソフト屋なんだからそれぐらい自分 (たち) で作ってみろよ!!」といったところ。 詳しくは次回 (とは限りませんが)、「内製のススメ」というタイトルで語ってみようと考えています。

関連項目

• アカウントと権限
• 「管理」は楽じゃない
• 内製のススメ