「鈴木先生、システムベンダーが開発に入ってから時間がたつのですが、その間私たちは待つだけなのですか？」とは、以前スポットで相談にいらっしゃった社長さんの質問です。その時はまだ構想も立てる前の軽い相談だったのですが、少しご無沙汰している間にシステムを自社向けに開発する段階まで行ってしまった様で、私もびっくりしました。

聞けば、基本的な機能要求のヒアリングも終了し、要件定義段階を経て、要件定義書を確認したところ、「しばらく設計と開発をするので、その間は都度質問に対応してください」と言われたとのことです。まだ開発作業の正式見積書が出ていないとのことでしたので、即決で「見積書が出た段階でいったん立ち止まる様に」ご指導申し上げ、胸をなでおろしました。

ここで何が問題なのか？ですが、この会社では「書類以外のものを何も見ていない」ことが非常に危険だからです。

このコラムでも何回かお話していますが、システムを構成するソフトウェアは形が見えません。外見も無いし、触るものも無いものです。通常、機械や設備であれば、外観を眺めることもできますし、触って機能を確認することも可能です。ところがソフトウェアの場合は完成する前は何も見えません。開発者によっては、画面構成などを要件定義段階で提示してくれる人もいますが、そうでないやり方をする会社もあります。その場合は、言葉で綴られた“機能“を読み込んで頭の中で想像するしかないのです。

この会社の場合は、部分的に画面構成案を提示されていましたので、まだ少し頭の中にイメージができるようになっていましたが、「システム＝業務プロセスをつかさどるもの」ですから、断片的に機能をイメージできるだけではまだ情報不足です。ましてや、システム導入後の業務プロセスがどう変化するのか具体的に明文化できていない場合は、断片的な機能把握だけで業務プロセス全体を想像することは不可能です。このまま進めると、場合によっては全く実用に供することができないシステムが完成してしまう可能性もあります。私はそのような不幸な会社をいくつも見てきました。

そこで、社長に「少し遠回りで出費が増えたとしても、モックアップかプロトタイプを作ってもらって、機能全体を確認する」様にアドバイスしました。これらの手法についてここで述べ始めると長くなってしまうので割愛しますが、これらは一言でいえば「ソフトウェアの模型」です。たとえ動作しない模型であっても、「ここにこれを入れて、このボタンを押すと、計算された結果がこちらの画面でこのように表示されて、このような伝票が出力できて・・・」という一連のシステムとしての動作の側面を垣間見ることができ、どのような業務プロセスになるのか、どのような使い勝手になるのか、ベースを確認することができるのです。

別の言い方をすれば、幼い子供にままごとセットを買ってあげるのと同じです。子供はままごとセットの食材をおもちゃの包丁で切り、おもちゃの鍋に入れて調理する、といった、調理のプロセス（≒業務プロセス）を体験できます。おもちゃの包丁（切る、という機能）を使う子供の横で、大人が「包丁を手に当てると手も切れちゃうよ～」とそっと言って包丁の危険性を教えることもあるでしょうし、火の危険性を教えることもあるでしょう。そのような疑似体験を通して、子供は調理全体のプロセスの中での注意ポイントも把握できますし、切った食材をきちんと整理しないと散らかる、といった課題（≒業務課題）も把握できます。もしも、切った食材を入れるボウルがセットの中になければ、「入れるものが欲しい」と言ってくることもあるでしょう。ボウルが無いと調理（≒業務）が進まないことに気が付くからです。

少し例えが幼稚すぎたかもしれませんが、子供はままごとセットを使って調理プロセスを把握することができるのと同様に、企業はモックアップやプロトタイプを使って業務プロセスを事前に把握し、これから導入しようとしているシステムの問題点や課題を洗い出すことができるのです。

このモックアップやプロトタイプについては、コストが増大することもあってＩＴ業界全体で軽視ぎみですので、システムベンダーから提案されない可能性もあります。書類だけでシステムの機能を把握することは、どんな専門家でもほぼ不可能です。「作った、動いた、使えなかった」を避けるためにも、絶対考慮頂きたいポイントであることをぜひご理解いただければと思います。