他にない、上質なITを

Column

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


Pocket

手に入れたいITシステムの全体像や要件を提示して、開発会社に具体的な提案を依頼するための資料のことをRFP(Request For Proposal)と言います。RFPに記載する内容をまとめると、この5つに大別することが出来ます。

  1. システム化の背景
  2. 解決したい課題と現状
  3. システムに必要な機能
  4. スケジュールと予算
  5. 納品物 / 契約形態

これらをまとめ上げて開発会社とコミュニケーションを取れるレベルに持っていくのは、簡単なことではありません。RFPで記載頂いているのは「こういったものが欲しい」という要求であり、我々システム開発を行う立場の人間が見積で必要なのは「要件」だからです。この違いは非常に大きいので、詳しく説明します。

似ているお話として、注文住宅を作るときのことを引き合いに出します。「リビングは12帖以上」「書斎が欲しい」「床の木からぬくもりを感じたい」というようなリクエストが「要求」です。それに伴い、「間取りはこうします」「構造材はこれで、壁にはこんな塗料を使う」というのが、「要件」です。要望を実現するための要件を固めることが出来て、初めて「その要件を満たすためのシステム像はこうである」と決定することが出来ます。

要件の検証は、UIを作ることで行う

「こういうものが欲しい」という要求を固めていくのが我々ITのプロがやらねばならないことですが、要求を「どうやって実現するか」を正確に決定するには、デモを作ってみるしか無いのが実情です。ICONIXプロセスというシステム開発設計論では、まず「GUI StoryBoard」を作ることから始めます。画面イメージを作って、それらを紙芝居的に動かせるものです。

建物を作る時に、建物の外観や室内を立体的な絵にしたものを起こします。パースと言われるものです。 一定の図法によって描いた図を使い立体的に表現することで 、図面などではわかりにくい全体のイメージを表現して、完成図のイメージを共有します。それと同じことをシステムの世界では、GUI Storyboardになります。デモやプロトタイプと言われるものです。

当社が業務システムを構築する際、もっと言えばお見積もりを提示する際には、このプロトタイプを必ず制作します。これをシステム化するとしたら幾らかかります、という正確な金額を提示するために絶対に必要だからです。それがないのに値段の根拠を示すのは、非常に不確実な根拠を元に提示することになります。

解決したい課題と現状を色濃く、細かく

最も確実というか失敗の少ない方法は御社側でプロトタイプを作る工数を割いて事前検証を行うことですが、その時間やリソースを裂けない場合もあるかと思います。その際、RFPで最も濃く書いて頂きたいのは、実作業レベルでこういう問題が発生しており、システムにこういう機能を搭載して解決したいという狙いです。

在庫管理を行うことが目的であれば、現在どうやって在庫管理を行っているのかを図解して頂く必要があります。下記のようなシンプルなもので構いませんので、登場人物とシステムや帳票類がわかるようにして下さい。

○○部が行っている在庫管理のあり方は〜 という箇条書き形式では何も伝わりませんし、深刻度や特異性を確認することが出来ません。全体像を表現するのには、言葉だけでは伝えきれません。

在庫管理と一言にいってもどういう管理の流れを作りたいのかは会社によって違います。単純に棚卸を簡素化したいので商品にバーコード(QRコードを発行できるようにしたいのか、在庫数の変動によって自動発注を行いたいのか、バックオーダーの数を正確に把握してどれぐらいの原材料が必要なのかを逆算したいのか。これらが全く違うお話であることはご理解頂けると思いますが、RFPには「在庫管理が自動でできること」ぐらいに丸められているケースが散見されます。

取引単位の損益把握を行いたいというのもよくある話ですが、何を持って「原価」とするかによってシステムに乗せる粗利計算のろ軸が異なってしまいます。物売りの場合は商品の売値から原価を引けばいいだけ、とは限りません。商品の製造時期によって原価が違う(為替の関係で)こともあります。ビルメンテナンスのような、作業員を派遣するタイプの場合は人件費や間接費も原価として載せる必要があるでしょう。

業務(実作業)レベルの現状認識が不足していると、立てた問いが間違ってしまいます。その意味が伝われば幸いです。

帳票から逆算して現行業務の全体像を掴む

当社は「ITアドバイザリー」というITコンサルティングをさせて頂いています。御社がIT化しようといしている企画書やRFPに対する助言、システム業者に対する見積もり額の妥当性診断などがメインです。

ITアドバイザリーのお仕事をさせて頂くにあたり、現行業務の全体像を理解することから始めます。どの作業をどうやってシステム化すれば最大の成果が出るのか、RFPはそういった道筋を説明できる資料になっているのかを検証するためです。大変失礼な言い方ですが、RFPを精査する立場であれば、御社がRFPで提案依頼を行っている内容を鵜呑みにするわけには参りません。

精査にあたり、業務フローを重要視しません。内製している工場の生産工程のように複雑で入り組んだ計画を持って稼働しているのならまだしも、多くの会社の業務プロセスは似通っています。「引合→見積→受注→納品→請求→回収」という大きな流れがある中で、何が違うかと言えば管理している情報の流れです。それが端的に現れるのが帳票です。

帳票はある業務の成果物であることが多いので、帳票を並べて検査するだけで業務の流れや、業務上のイレギュラーの有無、正しい帳票であると判断できるチェックポイント、作業時間が増大しているであろう点などが類推できます。帳票を出力するまでの流れを精査することで、現状業務におけるIT活用の実態も窺い知ることが出来ます。

帳票は雄弁に業務内容を語ってくれますので、帳票という現場のオペレーションの視点から、視点の位置を上に上げて業務の全体図を掴んで整理する。そういうやり方を取っています。

RFPよりも、プロトタイプに重きをおく

当社はMOD99という業務システムに特化した独自の開発方法論を持っており、その中で画面イメージをExcelで作ることが出来るツールを持っています。我々はRFPを精巧に作ることに重きを置きません。それに1ヶ月かけるのであれば、我々に1ヶ月のお時間を頂きヒアリングをさせて頂いて実際にお使いになるシステムの利用イメージを固めて頂き、「ブレがないシステムの全体像」を共有することに重きをおいています。その上で、ご予算と期間に収まるものかを、我々が判断させて頂いています。

RFPを作ったのに上手く行かなかった、業務に詳しい人間をアサインしたのに開発が頓挫した・・・そのようなお客様からすると、当社のやり方は非常に合理的に映ります。業務システムの導入をご検討の際に、私共のご提案にも耳を傾けて頂ければ幸いです。


おすすめ記事

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

執筆者について

著者

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

湯本堅隆(YUMOTO Michitaka)

略歴

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

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

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

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

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

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


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