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

Tweet

Pocket

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ただ、当社は一歩進んで「仮説検証から一気に業務アプリケーションを作ってしまう、その工程を可能な限り短縮してしまおう」と考えるようになり、kintoneを活用したシステム内製化支援を開始しました。これにより、要望〜要求〜要件定義〜設計〜実装〜デリバリ(仮説検証)が高速に回せるようになり、皆さんでも手を入れることが出来るITが手に入るようになります。

kintoneを活用しているのは、「常に最新版にメンテナンスしてくれる既成の車に乗って、自分が行きたいところへ行けるから」です。

この最新版にメンテナンスしてくれる、というのが重要です。常に最新版にメンテナンスしてくれ、独自の仕組みを作ることが出来るプラットフォームがあるなら、それを使いこなすべき。もちろん、既成のものなので制約はありますが、ゼロからコードを書いて業務アプリケーションを作るのは、多くの中小企業には難しい選択肢です。社内業務で行うことの多くは、今であればSaaSやkintoneなどを使えば、カバーすることが出来るようになりました。常に最新版にメンテナンスしてくれる既成の車に乗って、行きたいところへご一緒できればと思います。

kintoneによるシステム内製化支援の話にご興味のある方は、以下のお問い合わせボタンよりお気軽にお問い合わせください。

お問い合わせはこちらから