実験結果の考察

表^5.6: 進捗状況の入力

用度係到着 発注 納品 合計 入力回数 ^{10 5 5 20} 入力件数の合計 ^{53 48 36 137}

入力件数の合計

入力回数 ⁽件⁼入力^{) 5.3 9.6 7.2 6.9}

入力回数

アクセス回数^{(%) 41.7 20.8 20.8 83.3}

入力回数

実稼働日数⁽回⁼日^{) 0.46 0.23 0.23 0.92}

表^5.4 を見ると、発注者は⁴日に一度くらい進捗状況を問い合わせている。表^5.5から は、実験期間中に⁵件の用度品目の発注があったことがわかる。表^5.6 では、進捗状況を 入力するために¹日¹回弱^WWWサーバにアクセスし、¹回のアクセスで⁷件程度の伝 票について進捗状況を入力したことがわかる。

5.4.1

ログの考察

第⁴章で示した研究費執行管理システム第¹版の業務の流れとは異なった流れで処理 が進んだケースがいくつかみられた。以下のようなケースである。

(1) 実際にものが納品されてから伝票を発行することがあった。

(2) 進捗状況の入力洩れがあった。

(3) 研究室に実際にものが届いた日⁽納品された日⁾より進捗状況として入力された日付 が遅いことがあった。

(4) 発注のメールに型番の間違いがあり、用度係からの連絡・担当の学生からの解答・

用度係での訂正に時間を要した。

(1)のケースは、緊急に必要になったもの⁽在庫品目⁾を伝票を発行する前に手渡したと いうものである。本来ならば、「伝票の発行 → 発注 → 納品」という順序で進むと定義さ れている処理が「納品 → 伝票の発行」という順序で行なわれた。備考欄に「既に手渡し 済み」というコメントをつけた伝票を回覧して対応した。一般のワークフロー管理システ ムでは、このようなワークフローの定義と異なった順序で処理が進むという例外には対処 することができない。

(2)は、作業者が進捗状況の入力という電子的な世界への情報の入力を忘れたものの、

実世界では通常と同じように伝票が流れ処理されたケースである。

(3)も⁽²⁾と同様に、作業者の電子的な情報の入力が実世界のものの動きと完全に同期 していないというケースである。しかし、この場合も、進捗状況の入力の遅れは実世界の 作業に影響がなかった。

一般のワークフロー管理システムでは、⁽²⁾や⁽³⁾のようなケースは、処理を忘れたと ころで業務の流れが止まり先に進まなくなってしまう。

(4)の場合、必須項目の間違いではないため機械的にチェックされずに伝票が実世界を 移動して発注の段階での作業者のチェックで間違いが見つかった。その後、発注者と電子 メールで連絡をとって訂正した。これは、第²章で例として示した^Flowmateの差戻しの 機能に相当する。

以上のように、このモデルでは、既存のワークフロー管理システムで提供されている例 外処理に相当する機能に加えて、ある種のより現実的で突発的な例外を許容している。

5.4.2

インタビュー結果

先に述べたように、システムそのものに対する評価、システムが生み出す成果物に対す る評価、システムの運用に対する評価という³つの観点から質問を行った。

システムそのものに対する評価項目として、表示の見やすさ、入力の手間といったユー ザインタフェースや処理速度などシステムの操作性に関する質問と個々の機能が役に立っ たかどうかという質問を行った。システムが生み出す成果物については、進捗状況の問い 合わせ結果などシステムから被験者に表示される情報の有用性を質問した。システムの運 用に対する評価としては、今後、これらの機能を運用する範囲を広げるとどうなると思う かという質問を行った。

今回の実験は、実世界ワークフロー管理システムの機能の有用性を評価することを目的 としているため、システムが生み出す成果物に対する評価が特に重要になる。

発注者に対する質問の回答

WWW からの用度品目の発注は使いやすかったようである。実験期間中、⁵回の用度 品目の発注があったが、すべて^WWWからのものであった。

進捗状況の問い合わせの結果については、一度に表示する件数が多いとわかりづらくな るという指摘があった。

作業の進捗状況を^WWW上で参照できる機能は非常に役に立つという回答だった。こ れは、いままで電子メールを出したり問い合わせの電話をかけたりして行い、回答を得る までに時間がかかっていた進捗状況の問い合わせをそのような手間をかけずに簡単にでき るようになったということに対する評価である。

また、今後これらの機能が導入されると役に立つだろうという回答を得ることができた。

作業者に対する質問の回答

発注の期限と納品の期限の表示の方法に対する意見、進捗状況の表示に対する意見が あったものの、システムそのものの評価という点ではよい評価を得ることができた。

次に、システムの成果物に対する評価について述べる。

今回の実験では、作業の進捗状況を入力する際、まだ終了していない作業を一覧表とし て表示し、そのなかから終了した作業を選んでチェックするという方法をとっている。こ のとき表示される終了していない作業の一覧表は役に立ったということだった。

発注者に対して作業の進捗状況を表示する機能を導入したわけだが、この機能を導入す る前と比較して、発注者からの進捗状況の問い合わせの件数は変化しなかった、という回 答であった。

このシステムの運用範囲が広がった場合どうなるかという質問に対しては「⁽作業の進 捗状況を入力することによって生じる⁾ 利益より負担のほうが大きくなるだろう」という 回答である。

この結果について、前節に示した^WWWサーバへのアクセスのログ、システムそのも のに対する評価、システムの成果物に対する評価と合わせた考察を試みる。

表^5.6 によると、作業者は¹日約¹回ずつ^WWWサーバにアクセスし¹回につき⁷件 程度進捗状況を入力した。しかし、システムそのものに対する評価の結果を見ると、入 力の手間など個々の機能に対する負担はあまり感じていないようである。さらに、進捗状 況を入力する際に提示される、終了していない作業の一覧表は役に立ったという回答で あった。

システムの運用範囲が広がると、サーバへのアクセスの回数や一度に入力する件数が増 加する。また、この作業に対する利益として想定していた、発注者からの進捗状況の問い 合わせの減少がみられなかった。

これらから、個々の作業に対する負担は感じなかったものの利益となるような情報を数 多く得られなかったので、このような回答になったのではないかと思われる。

このように、進捗状況の入力という作業の負担を強いるシステムであることから、実際 の運用を考えるときには、作業者の負担と作業者が得ることができる利益のバランスを考 慮し、使いやすいシステムを実現する必要がある。

第

章