次期基幹システム(5)-運用テスト続報

　＊このブログでの描かれているやり取りは、実際に行われたものと若干の相違があります。これは、記憶違い、わかりやすさのための修正、若干の脚色によるものです。

　次期基幹システムの運用テスト終了まで1週間となった昨日、関係者を集めた会議を開催し、残り僅かとなった期間における運用テストの進め方について説明しました。

　この前日、今回の開発を委託している会社の主要メンバーと私は、我が社の会議室で約2時間にわたる議論を行いました。議論のテーマを掻い摘んで話すと、テストをなかなか行おうとしないユーザーを、いかにすれば動かすことができるか？　ということです。難しいですね…　人の意識を動かすというのは…　しかし、期日は迫っています。次期基幹システムの稼働をさらに延伸することなど、議論の余地もありません。

　最初に議論された策は、より強力な業務命令を下す、というものですが、これには私が気乗りしませんでした。確かに怖い上司から「やれっ！」と命じれば、ほとんどのユーザーが手を動かし始めます。しかし、「脅し」では、場当たり的な対応により本当に必要なことが失われてしまう可能性が高くなります。つまり、とにかくテストの仕様書と成績書さえ提出してしまえばいい、という「ずる」によって、実態を伴わない見せかけのテストが行われてしまうリスクです。

　我々開発サイドが支援できることはないだろうか？　これはそれほど長い議論にはなりませんでした。既に説明は尽くされ、サポートの窓口を用意し、委託会社のSEが我が社に常駐している中で、果たしてこれ以上何があるのか？　ユーザーの主体性がすべてと言っても過言ではない運用テストにおいて、今以上に魅力的な支援策は、確かに見つけにくいものです。

　「んぅーん…」と空気が淀んだ時、私はユーザーの心理を想像しながら口に出して描画してみました。
　「自分の怠慢により成すべきことをやっていないことは、おそらく自分自身が一番よく知っていることでしょう…　自分は、自分の真実を知る唯一の存在なのですから…　関係者が集まった会議の場で、進捗が思わしくないと報告されれば、犯人捜しが始まるかも知れない。そうなれば言い訳を考えなければ…　しかし、言い訳もそう簡単ではないと気付くはずです。開発側は、議事録や操作ログなどさまざまなデータによって武装しているので、そうしたものとの不整合を指摘されたら…　思いつきの嘘で通じる相手ではない…　困ったなぁ…　どうしよう…」
　私は、もしこんな立場だったら私たちに何がして欲しい？　と尋ねてみました。
　「やはり助け船が欲しいのでは？」
　「そうですよね。では、どんな助け船？」
　開発サイドの支援策は尽きている、と前段で議論しました。やはり、直球しかないのでしょうか？　つまり、運用テストの重要性を説き続ける…　しかし、それはもう十分にやってきたことです。

　議論が尽きたかに思えた時、営業担当が口を開きました。
　「グループウェアで各自の予定を把握しているのだから、空き時間に様子を見に行くとか…　ダメですかね？」
　これがもしもアニメだったのなら、営業担当のセリフの後に、私の頭にエクスクラメーションマークの表示と「ピンポーン」という効果音が鳴ったでしょう。ブレイクした瞬間です。
　私は訪ねました。
　「全業務を支援するためには何人のSE（今回のシステムのシステム化業務設計者）が必要？」
　「4人です」
　「来週1週間、その4人を終日我が社に待機させることは可能？」
　「何とかします」
　「ではこういう案はどうだろう」
　私は続けました。
　「まず、SEを4人、終日我が社に待機させ、すべての業務に対して支援できる体制をとる。そして、ユーザーの予定をグループウェアで確認し、空き時間になったら当人のもとを訪れる。つまり、空き時間が生じるたびに催促を受けるわけだ。これは非常に強いプレッシャーになる。まさに借金の取り立てと同じ。この取り立てから逃れるための手段はただひとつ。返済計画の作成とその確実な履行。催促がたまらないと思えば、自ら何らかの解決策を提案し、またそれを実行していくのでは？　さらに、まったく資金繰りのあてがないのなら、どうしたらいいでしょう？　と相談してくるはず。ないものはない、と開き直る人には法的措置、すなわち強力な業務命令（怖い部長の怒鳴り声）によって強制執行する。また、先ほどの助け船が必要なユーザーも、個別に開発サイドと対話できるので、救済されるのではないか？　どうだろう？」

　これがベストとは思っていません。しかし、議論の時間をそう長くとることはできません。この議論に参加したメンバー全員の合意によって、このやり方が採用されました。

　翌日の午後、システム開発の関係者全員が集まる会議が始まりました。私はマイクを片手に、まず、これまでのプロセスを振り返ることから語り始めました。プレゼンテーションのストーリーはこうです。

1. 事実を振り返り、開発側の正当性をアピールことによって、ユーザー側の不当性を暗に示すことで一旦、悪玉ユーザーを追い込む。
2. テスト成績書から定量的な実施状況を示し、全体に危機感を醸成する。
3. 本稼働のための必須条件を示すことで、 明確なゴールがあることを明らかにする。つまり、成すべきことをやりさえすれば解決する問題であることを理解させる。
4. 具体的なやり方を教える。

　そして、最後。最も重要な点は、これは押しつけではなく、ユーザーにはいつでも主体性を取り戻せるチャンスが与えられている点を強調することです。つまり、先の例えである「返済計画の作成」を行えば、我々は「その確実な履行」を見守るだけであることを理解してもらうことです。

　約40分。思ったよりも早く会議は終了しました。
　手応えはありました。
　この施策の成否は？　答えは来週早々に出始めます…

続く…