利用系システムの開発を成功させるには

未唯へ。日曜日に５時半に起きた反動と、久しぶりにバス停までの２５分歩いたので、かなりしんどいです。仕事の方は、怨念（思い）をこめて、マニュアルを作っています。

利用系システムの開発に課題が出てきているようです。テスト段階の不具合が自然に耳に入ってきます。上層部がそれに気づいたみたいです。この場所に座っていれば分かるのに、多分違う方を見ているのでしょう。

二つの異なる文化からなる、システムの開発を成功させるためのファシリテーションが必要です。

Ａシステム：オフコンから作り上げてきたシステムで、仕事の手順に沿って、全てのインプット・アウトプット・処理を記述してあります。ワークフロー通りに仕事をしていれば、従来からの仕事は全てできます。

Ｂシステム：業務改善にから発展してきたシステムで、ウェブで対応していく開発です。現場へシステムを持ち込んで、仕事の仕方を直しながら、その場で最適なシステムに作り上げる方法です。

この二つをドッキングして、システムテストした時の想定を次に述べます。Ａシステムのテスト担当者は、“全ての”ワークフローに基づいて、全てのインプット・アウトプットを求めます。それで連携テストに掛かろうとします。それに対して、Ｂシステムは機能をベースにするので、仕事のワークフローは要件書だけです。Ｂシステム側の担当の言葉だけでイメージします。

この場合、Ａシステムからの評価は「何もできていない」ということになります。ここに利用者が入り込んでいれば、具体的コンテンツを想定して、それなりの評価ができるが、Ａシステム側は“全てのワークフロー”のテストだけを行ってきたので、知恵が働きません。これでは先に進めません。

これを回避するには、事前のファシリテーションが必須です。そのタイミングがあったが、それぞれに任せるということと、やはり作ってみないと分からないということで、曖昧なまま来てしまった。

ファシリテーションの中身は、Ａシステムのワークフロー型では利用系システムの限界であることを示すと同時に、Ｂシステムの機能を確認するにはユーザーを巻き込むことであることを告げることです。

ちなみに、ポータルはＢシステムの範疇にあります。ウェブ的な機能を開発し、それをコンテンツを持つユーザに直接働きかけることにしました。