IT導入/要件定義の前に、PoCの時間を取ってもらえませんか？

IT導入を行うにあたって、非常に多いのが「カタログや画面、説明を聞いていたらこのソフトやシステムで問題ないと思っていたが、実際に納品されたものと使ってみると使いづらかった。期待したものではなかった。」という失敗談です。そういったすれ違いを可能な限り少なくするために、ITシステムを導入するために何をどう考えなければならないのかを解説します。

「要望」と「要件」がもたらすギャップ

システムを手に入れる過程は、注文住宅を作る過程によく似ています。

1. リビングは12帖以上
2. 書斎が欲しい
3. 床の木からぬくもりを感じたい
4. 寒がりなので断熱効果を高めたい

これが要求、つまり成し遂げてほしいことです。使う人が作る人に対して、伝えるべきことです。

これに対し「要件」というものは、こういうことになります。

1. 12帖のリビングにするために、書斎の場所は収納になるが良いか？
2. 断熱効果を高めるための素材はこれでいいか？
3. ぬくもりを感じたいのであれば床暖房あるといいと思いますが、どうか？

成し遂げてほしいことに対して、それを担保する環境づくりが要件です。

要件を決める必要があるのは、プログラムを作る準備作業として必要だからです。プログラムを作るには、予めレシピを決める必要があります。これを仕様といいます。家を作るのに作りながら図面を変えるわけにはいかないので、予め仕様を決めて合意してから、開発を行います。

しかしながら、注文住宅と違ってソフトウェアの場合は「生活動線として不便だからすぐ直して欲しい」というお話がとても多く出ます。これがそう簡単にできないのです。プログラムは「この場合は、こうする。次はその結果を使って、この計算をする」という前後関係が密接に絡み合う命令の集合体のため、前提が狂ってしまうと今までの工程が無駄になってしまうことが多いからです。

要件定義が重要であるという指摘は、要求を伝えるだけじゃなくて、”システムが出来る前から”作り手が言っているレシピの内容についても理解を深めましょうね、という話でもあります。要求を要件に翻訳するのは、なかなか難しい作業です。

ソフトウエアの期待値を正確に見積もるのは無理

このように、業務システムの作り手とユーザーのギャップ、要求と要件のギャップが発生する理由は、ソフトウェアに対する期待値の検証は使ってみる以外に術がないからです。

何度も業務システムを作った経験がある私どもは、システムを作る前から導入後の姿をシミュレーションすることが出来ます。作った後にこういう業務に変わって、オペレーションはこう変わるから期待通りだな、というシミュレーション。でも、普通のユーザーさんにそれを求めるのは、なかなか出来ません。

試作品を作って検証することを、PoC(Proof of Concept)と言います。コンセプト通りの商品やサービスになっているかを検証する作業です。プロジェクトが始まってからでは遅いですし、失敗の多くは「コンセプトが間違っていた」ことなので、試作品を用いて仮説検証を行うべきである、と思っています。

そんな仮説検証にうってつけであるのが、サイボウズ社のkintoneでした。

もちろん、既成のものなので制約はありますが、ゼロからコードを書いて業務アプリケーションを作るのは、多くの中小企業には難しい選択肢です。社内業務で行うことの多くは、クラウドでカバーすることが出来るようになりました。常に最新版にメンテナンスしてくれる既成の車に乗って、行きたいところへご一緒できればと思います。