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

Tweet

Pocket

IT導入を行うにあたって、非常に多いのが「カタログや画面、説明を聞いていたらこのソフトやシステムで問題ないと思っていたが、実際に納品されたものと使ってみると使いづらかった。期待したものではなかった。」という失敗談です。

そういったすれ違いを可能な限り少なくするために、ITシステムを導入するために何をどう考えなければならないのかを解説します。

まずは「ご要望」から始まる

そのシステムでやりたいこと / 期待する成果が、要望です。簡単に言えば「こうなれば良いなぁという希望」のことです。多くの場合は「ふわっと」しています。

要望がキチッと整理されていることは極めて稀です。あの方向にピンが立っているからあっちに向かって行けば良いとは思うのだが、ぐらいの確度です。

要望については、「言葉には出ないコミュニケーション」を上手く取る必要があります。ITについてはお詳しくない方がほとんどですし、言葉に出来ないことを要望としてぶつけてこられますので、そういった「もやっと」したものを明確な形をつくって「見える化」してあげる、というプロセスが必要になります。そのため、対面でのお打ち合わせの時間が必須になります。

実現したい要望のやり方を決めるのが要求

ふわっとした要望が、既にお客様内部での検討が完了して明文化された状態になっていれば、要望が「要求」になります。要望はあくまで希望的観測という側面がありますが、要求になると「課題を成し遂げるために、何をしなければならないかを決めた」状態になります。その１つとして、ITの活用を行う・システム導入をするというのが選択肢に上がります。

要求を満たすシステムの全体像＝要件

要件は「どんなシステムを作るかを決定(合意)する」ことがゴールです。どういった機能があれば、要求を達成できるのかを決めるのが要件定義という工程です。「利用者は、そのシステムで何を実現したいのか」を深掘りして、何度も打ち合わせを行って決めていくものです。

お客様の要求を満たすために、システムがやらなければならないこと及びその設計や振る舞いを規定する必要があります。それを要件と言います。ITシステムの全体像と言って問題ないでしょう。

この要求をキチンと導き出すのは、実に難しい作業です。

要求と要件をすり合わせるのに時間がかかる

「どんなシステムを作ればいいですか？」という質問を馬鹿正直にしても、判断材料がないのであれば、あまり意味がありません。要件を決める際には、多くの判断材料を提案していく必要があります。

また、ユーザーが「こういう機能がほしい」と仰ったことも、詳しく話も詰めていくと違った機能を提供するのが正解な時もあります。お互いが認識している問題意識や課題が正しいかの裏を取りながら、「この要求で解決したい課題はXXX。であれば、この画面の機能はYYYが実現できないと。」というようなやり取りを、延々と繰り返します。

要求と要件のあいだを詰めていく作業を、ゴルフのコースマネジメントに例えています。１つ１つの要求がコースです。問題なのは、ティーグランドに立った時にキャディさんから渡された情報には、ピンはあっちぐらいの図です。ティーショットを打つしかありません。ボールを打たないとコースを攻略できません。こちらから提案や質問をすることで(時にはOBになったりしますが)、やっとコースの全体図が見えて、どの位置にピンがあるか見えてきます。

コースの全体が見えてきたら、今度は逆に「ピンからティーまでのコースマネジメント」を考えます。逆算をして、キャディー(ユーザー)とプレイヤー(私)が、コース攻略の戦略や手順について合意します。こういった流れを経て、要件の妥当性を詰めていきます。

何故この作業を繰り返すかというと、システムは仕様が全てだからです。どういった画面がありどんな情報が表示され、ユーザーの操作(クリックやキー押下等)があったら、どういう処理を実行しなければならないのかを、細部に詰めて行かなければシステムを実装することが出来ないためです。

これは本当に細かい作業の積み重ねで、本筋から言えばそこまでの検討が終わって初めて、制作料金を提示することが出来ます。システム開発における見積作業は、かなりの時間と手間がかかるものなのです。

UIプロトタイプで検証

システムというのは、動かしてみて初めてわかることが非常に多いです。これはプロでも同じ。「この情報が欲しいのではない」「この操作は意図したものじゃない」「この使い勝手は分かりにくい、使いづらい」などは、カタログや機能一覧では判断しきれません。

ざっくりとした例えですが、洋服を買う時に試着してみると全然イメージと異なっていた、というのと同じようなものです。洋服は買ってみないとわかりません、ショーケースから眺めるだけではなく、着心地、素材感、メンテナンス方法、デザインの違い等は、体験を通して学びます。そういった経験を積んでいきますと、自分では全く来ないような洋服を他人に勧めても、たぶんこれがお似合いです、と提案できるようになります。

それでもなお、その提案内容が正しいかどうかは「おすすめできる洋服」を別途用意しなければならないのがミソです。その為、システムが本当に要求答えているかどうかを検証するには、UIプロトタイプを作ります。簡単に言えば、デモです。このデモはガッツリ作り込むのではなく、最低限必要な情報や部品だけを配置することが重要です。「こういう画面でこんな操作ができて、次の画面に行くとこうなっていればいいんですか？」という意思疎通が図ることが目的です。

PoCを行ってから、システムを作ろう

要求がシステムで満たされているかを検証するには、試作品を作るしかありません。その試作品を使って検証することを、PoC(Proof of Concept)と言います。コンセプト通りの商品やサービスになっているかを検証する作業です。プロジェクトが始まってからでは遅いですし、失敗の多くは「コンセプトが間違っていた」ことです。

御社の中でPoCが出来ていない状態で、RFPを作成したりプロジェクトを開始してしまうことは、可能な限り(ほぼ絶対と言ってもいいです)辞めて頂きたい。

本当にこのITシステムが正しいのかは、御社でなければ判断できません。その為に必要なPoCの時間は必ず取って頂きたくお願い申し上げます。

おすすめ記事

最後までお読みいただきありがとうございました。
こちらの記事にご興味を持っていただいた方には、こちらの記事もおすすめです。

IT戦略・IT企画の無料相談(ディスカッション・パートナー)をさせて頂きます

単体テストや結合テスト等のシナリオ作りのヒント

RFPで正確な見積もりを出すのは極めて困難

ITプロジェクトの失敗理由の９割は、プランニングの失敗

執筆者について

著者

(株) クオリティスタート 代表取締役

湯本堅隆(YUMOTO Michitaka)

略歴

1979年生まれ。ISPの電話サポートのアルバイトをきっかけにIT技術に興味を持ち、2003年にアイ・ティ・フロンティア(現タタ・コンサルタンシー・サービシズ)に新卒で入社。

SIer在籍期間からブログ「GoTheDistance」でSIerを巡るIT業界のあり方・エンジニアのキャリアについて記事を書き、累計はてなブックマーク数40,000を超えるブログになりました。

「ITを使いこなしたいなら、ユーザー企業は内製すべき」と主張しているうちに、2009年から雑貨卸の有限会社 エフ・ケーコーポレーションで内製化を1人で担当するはめに。メーカー送料ロットのない雑貨卸というビジネスモデルをITシステムを実装することで確立し、経済産業省が主催するIT経営実践認定企業に選ばれました。

「システムを作る人材や会社」はあっても「何が正しいITシステムなのか」を事業会社の立場で考え、デザインできる人材が枯渇している。

この課題を解決したいという思いから、会社を創業しました。

重度の野球好きで、東京ヤクルトスワローズのファンです。