その４４ 今抱えている問題に当てはめながら過去の反省をしよう！

事務所でユーザテスト（４月にリリースするシステム改善の確認のために実際に端末操作を行ってもらうこと）を行いました。

パパの場合は、たまたまユーザが同じ組織の人ですが、一般的にはシステムの発注者である「お客様」にテストしていただくことを指します。

このユーザテスト（パパの組織では最近オーナテストと呼んでいます）の目的は、

●システムの構造、プログラムの中身を一切無視して、「お客様視点」で自由にシステムを触ってください。
●そのうえで、何か不都合なものがあればご指摘ください。

という内容です。

ところが、最近ではこれらの目的に加えて、

●システム開発者がきちんと発注者の意図に沿った内容でシステムを構築したことの証跡

という意味合いが強くなってきています。

ユーザテスト自体は、違う切り口での確認という点でシステムを動かしてもらえるので、とても有効だとは思いますが、その裏に見え隠れするセクション間の責任の所在の明確化については、何か中途半端で意味がないように思えます。

突き詰めていくと、システムトラブルは、最終的には所詮システム開発者の人為的なミスに帰結できます。

ただし、「人為的なミス」につながった原因は、単純ではなく、ほとんどの場合ユーザ側にも何かしらの要因があります。

しかしながら、トラブル（障害）が発生した際には、ユーザ側の責任は曖昧であるが故に立証が難しく、直接的であるが故に立証し易い人為的ミスであるシステム開発者側に責任を負わされることが圧倒的に多いのです。

なので、極論を言うといくら証跡を残しても無駄です。

唯一、証跡を残すことに意義を見出すとすれば、「仕様が曖昧だったからシステムの作りが悪かったのだ」ということを発注者側に反省して、次回以降に同じ過ちを繰り返させないことですが、システム障害として処理されてしまったことについて、次のプロジェクトのことで頭がいっぱいのユーザが相手にしてくれるはずもありません。

そもそも、障害を出して後に自己保身して何になるのでしょうか？

いかに、障害を素早く収束して、被害を最小限に食い止めるかができれば、よいはずです。

だいたい、少しでも痛い目にあえば、誰だって反省をして、次回のシステム開発時には同じ失敗を繰り返さないように注意します。

でも、最近は品質管理の名の下に、当事者以外の人々が、報告書だの、再発防止策だの、を要求してきて、挙句は懺悔のレビューを収集し、その場で、理想に満ち溢れた防止策をの賜われるのを頭をうな垂れながら聞かなければならないのは、非生産的な時間の過ごし方の極みです。

で、あれば、次のプロジェクトの中で、過去の失敗を活かすことを考えるべきです。

「賢者は歴史から学ぶ」という言葉が示すように、歴史からモノを学ぶのは重要ですが、過去の事象を現代の問題点に応用できなければ、ただの物知りです。

パパが携わっているシステム開発という仕事においても、過去の事例研究で満足せずに、その反省をどのように次のシステム開発時に活かしたかを検討するのに時間を割くべきです。

日本は、ホワイトカラーの生産性がとても低いそうです。

これを改善するには、過去の反省を、今起こそうとしている行動に直接的にフィードバックするような発想が必要であるように思えます。

本日のパパからのメッセージは、

「今抱えている問題に当てはめながら過去の反省をしよう！」

です。

反省即応用といけばよいですが、どうも過去の反省で終わってしまうことが多いです。

なぜ、現在抱えている問題に応用できないかと言えば、タイムラグがあり、反省したことがどんどん薄れていってしまうためです。

反省というネガティブな気持ちをパワーに変えて、次の行動でよりよい結果をだすよう、とことん合理的に考えましょう！