手に入れたいITシステムの全体像や要件を提示して、開発会社に具体的な提案を依頼するための資料のことをRFP(Request For Proposal)と言います。RFPに記載する内容をまとめると、この５つに大別することが出来ます。
- システム化の背景
- 解決したい課題と現状
- システムに必要な機能
- スケジュールと予算
- 納品物 / 契約形態
これらをまとめ上げて開発会社とコミュニケーションを取れるレベルに持っていくのは、簡単なことではありません。RFPで記載頂いているのは「こういったものが欲しい」という要求であり、我々システム開発を行う立場の人間が見積で必要なのは「要件」だからです。この違いは非常に大きいので、詳しく説明します。
似ているお話として、注文住宅を作るときのことを引き合いに出します。｢リビングは12帖以上｣｢書斎が欲しい｣「床の木からぬくもりを感じたい」というようなリクエストが｢要求｣です。それに伴い、｢間取りはこうします｣｢構造材はこれで、壁にはこんな塗料を使う｣というのが、「要件」です。要望を実現するための要件を固めることが出来て、初めて「その要件を満たすためのシステム像はこうである」と決定することが出来ます。要求と要件の間には、かなり大きな溝があります。
RFPで書かれた要求が要件とリンクしてないとその溝を埋めるコストが大きくなり後工程に影響があるのは間違いないのですが、それを指摘した所で「要件定義」をきっちりやるのは難しいままです。
なぜ難しいかといえば、ソフトウェアの期待値の検証は使って運用しないと検証できないからです。しかし、モノを作るのには予めレシピを決める必要があります。家を作るのに作りながら図面を変えるわけにはいかないのと同じです。しかし、ソフトウェアの場合は「あーその間取りだと生活動線として不便だから、こうして欲しい」という話がとても多く出ます。
家具の配置を変えるように簡単には行かないのは、プログラムは「この場合は、こうする。次はその結果を使って、この計算をする」という前後関係が密接に絡み合う命令の集合体のため、前後関係や前提が狂ってしまうとやり直しになることが往々にしてあるためです。
「間取りの変更はどうしても起こり得る。自社にフィットする仕組みを作るからこそ、業務アプリケーションは成果を出せる。でも、後からプログラムを直したり手戻りが発生したら質は落ちる。プログラム開発を極小化して、自社独自の仕組みを構築できる術はないか」を創業からずっと模索し、1つの答えとして、kintoneによるシステム内製化支援を開始しました。
常に最新版にメンテナンスしてくれる既成の車に乗っていこう
ほとんどの業務アプリケーションが、SaaSとして提供されるようになりました。とりあえず使ってみることが何でも出来る時代に、RFPを細かく書いて要求事項をキッチリまとめた「硬直的なフロー」を回していくのは難しいと思っています。そういった過程を経て業務アプリケーションを導入するケースが減るからです。業務アプリケーションを、独自のプログラムをゴリゴリと開発して作ってしまうのはコストもリスクも高くなります。
kintoneを活用しているのは、「常に最新版にメンテナンスしてくれる既成の車に乗って、自分が行きたいところへ行けるから」です。この最新版にメンテナンスしてくれる、というのが重要です。常に最新版にメンテナンスしてくれ、独自の仕組みを作ることが出来るプラットフォームを活用しない手はありません。もちろん、既成のものなので制約はありますが、ゼロからコードを書いて業務アプリケーションを作るのは、多くの中小企業にはおすすめできない選択肢です。費用対効果が悪いからです。
独自でプログラムを開発する場合は「画面」「データ」「機能」について全て細かくリストアップしていかねばならず手間も時間もかかります。また、これがいちばん重要なのですが、コードを書いたときから陳腐化が始まります。会社の事業環境が変化するためです。その時に「これを直して、それを直して」とツギハギで直していくと「ポンコツのカスタムカー」が出来上がってしまいます。これを乗りこなすのは運転スキルが求められ、属人性が強くなってしまいます。もちろん、カスタムしたことでパワーが出ることもありますが、乗りこなすまでが大変です。
kintoneの良い点は、アプリを作ることしかできないが、工夫次第で独自の仕組みを作ることが出来ることです。事業会社の業務を支えるのに必要なバックボーンは、これだと考えています。
まず、使いこなせるITを手に入れませんか？
お問い合わせをお待ちしております。