ある勉強会で、実体験に基づいた現場主導のシステム開発につき話をしたことがあります。
話しの中で挙げた幾つかのポイントを紹介します。
現場からの要求を反映しているか
机上から現場を推測したり、通り一遍のヒアリングで済ませて決めた仕様で作られたシステムでは十分な効果を発揮しないことは
知られています。なんとかまとめた仕様でもスクラッチで開発するならともかく、それに見合うパッケージを導入して済ませるようでは効果を発揮しないというかできないのは言うまでもありません。システムの開発と運用を成功に導くためには、システム化対象業務の現場の観察と彼らからのヒアリングが必須です。現場とは、病院を例にすれば、とかく診察業務が中心となりがちですが、受付／検査／会計／手術／病棟／薬剤／給食など多岐に亘る現場があり、これら部門間を行き交う情報の出どころ、利用先、利用する目的、タイミングなどをもれなく聞き出す必要があります。謂わば情報の戸籍謄本のようなものです。
関係する全ての現場からの漏れなく要望を吸い上げるには、システム構築の主旨が理解され、自発的な協力が得られるような雰囲気が醸成されていることが求められます。良い雰囲気が醸成されていると、現場から忌憚のない要求が出てくるようになりますが、現場にとってはあまりに馴染みすぎていて、仕様として出てこないものもあります。それらが分った時、可能な限り吸収できる柔軟な構造のシステムであるように作りますが、自ずから限界があります。そこが、柔軟性のある紙と鉛筆での作業と、教え込まれたとおりにしか動けないシステムの違いです。おっと、大きなポイントを忘れていました。それは、現場重視ではあるものの、現状のやり方に合わせるのではなく必ず、BPRを行うということです。
仕様が絞り込まれているかどうか
①いつ誰がどのような場合に使うことを前提とした機能なのかを吟味したか
②想定する使用シーンが希にしか起きないものか
③日常的に起きるものか
④頻度は少なくても重要度が高い機能なのか
の区別を行い、不要不急の機能によって仕様が膨らまないようにしなければなりません。ただし、ドロップせずにシステムに乗せておかないと、乗せなかったために全体が足を引っ張られる機能もあることに注意する必要があります。また、諸要求が五月雨的に出てくることも想定されます。この取り扱いルールを明確にしておかなければ何時までたっても仕様が定まらず、工期は延び、費用も膨らみます。しかし、仕様をフィックスした後に出てきた要求がシステムの根幹にふれるものであった場合には、杓子定規にそれを切ることはできません。期間を延ばす、優先順位の低い機能を次のバージョンに回すなど、臨機応変な処置が必要になります。
スケジュールに無理はないか
専門家ではないユーザが主導してプロジェクトを進める時に気をつけるべきは、スケジュールに無理はないかです。実行可能なスケジュールになっているか否か。根拠となる体制、要員、技術、経験、難易度は十分検討したか？イベント毎に実施するレビューも入っているか、レビュー要員は適任か、レビュー方法は明確かなども盛り込んでおかなければなりません。もちろん、機能、性能のテストも十分な時間を費やすべきです。特にテストは、全てのパスを検証できるデータの作成とテスト環境の実現がポイントです。これを疎かにすると稼働後に問題が発生します。無理な仕様、スケジュールで進むことは、最初から難破することが分かっている船出、最も危険なものです。しかし、危険なのか、ぎりぎりセーフなのか、余裕があるのかの見極めは難しく、経験、先見の明、それに文殊の知恵が必要になります。最も重要なのはスケジュールの進捗管理で、忌憚のない報告ができる雰囲気があり、その事実を全員で共有し、リーダが精神論でない適切な判断と対策を行えるか否かです。最大限努力しても稼働後に問題を起こす可能性が予想されれば、見栄を張らずに稼働時期の延期を行うべきです。それができずに稼働後に大きなトラブルが頻発したのが、みずほ銀行です。なお、みずほ銀行については既にいくつものブログを書いているので、そちらを参照してください。
※質問はosugisama@gmail.comにどうぞ！
※リブログを除き、本ブログの無断転載、流用を禁じます。