家富正幸こんにちわ、家富です。
なぜシステム開発の見積もりは高くなってしまうのか？
今日はWordPressを含むシステム開発について、仕様書、要望書などの書類などが如何に重要か？
そして妥当な金額に導くための仕様書のつくり方についてお話しいたします。
システム開発の見積もり「よくある勘違い」
よくシステム開発（サイト制作）のお見積もりをいただく際に、
「このサイトと同じで」
「このシステムと似たような物」
「完コピで」
と言われる方がいらっしゃいます。
参考で送っていただいたサイトを実際に見てみると、オリジナルのイラストやアニメーションをふんだんに使っていたり表面上ただのコーポレートサイトのように見えるけど内部は非常に複雑な会員管理システムが動作していたり・・・。
ウェブサイトは、サイト毎にオリジナルの特色や、また表面上からは確認出来ないような内容があるため、具体的に何をどのようにお客様が気に入られたのか、なんとなくでしか判断をすることが出来ません。
私たちはシステム開発に通じているので、なんとなくイメージされていることはわかるのですが、やはりそれは「なんとなく」であって、具体的にお客様のやりたいことを完全に把握できるものではありません。
過去にあった見積もりに関する相違
「このサイトと同じシステムがほしい」
といったお問い合わせをお客様からいただき、そのサイトを確認して、実際に概算のお見積を出したことがありました。
概算のお見積金額にお客様は納得いただき、実際の発注につながるというところで、詳細な詰めのため、具体的にお会いすることに。
そこでお話を聞いていると、「ん？そんな機能あったっけ？」という話がぼろぼろ出てきます。
色々とお話を確認していくうち、お客様がそのサイトに存在しない機能を、「他のサイトでは使えるから、このサイトにもあるだろう」ということで、想定していたというものでした。
そこで出てきた仕様を含めてみると、お見積はうなぎ登り。
結局、予算が足りずにお話はなくなってしまいました。
こうした相違があると、双方が貴重な時間を無駄にしてしまいますし、とてもやるせない気持ちになってしまいます。
やりたいことを明確化し、概算見積もりを依頼する
上記のようなことが発生する、一番の問題を一言で言ってしまうと、「お客様自身がやりたいことが明確ではない」ということです。
要は「自分自身が作りたいサイト」において、「何をどのようにしたいのか」というポイントが、定まっていないのが大きな問題なのです。
まだまだ予算取りも出来ていない状態では、「このサイトみたいに作ってね」と一言でお願いしてしまったほうが、非常に簡単です。
しかし、その一言だけで、サイトの裏側まで含めた機能を確認できるのは、そのサイトの管理者くらいでしょう。
たとえば「このサイトみたいに」というのが「見た目」だけであるならば、割とそれだけでも通じたりします。
テイストなどは、画面イメージや参考サイトが、非常に役に立つからです。
ただ、システム開発となると、まず通じることはありません。
システムはその使い勝手や内部機能など、目に見えない部分でも大きく作り込まれていることが多く、開発を希望されたお客様の希望に併せて、作り込まれているポイントが多く、それを「見た目」だけでパッと判断することはできないからです。
また、システムの見た目を確認するにしても、「ログイン」しないと確認できない機能なども有り、そういった裏側の部分まで判断するには、
- 動作しているサーバーの情報やミドルウェアの情報
- 何をどのように処理するシステムなのか
- 管理者はシステムを使って何ができるのか
- 会員登録したユーザーは何ができるのか
- 会員ユーザーのログイン情報
といったことが、最低限どうしても必要になってきてしまいます。
結局のところ、「依頼するのが簡単だから」といった理由が大半で、ご依頼するお客様自身も「何をどうしたいのか」明確にはわかっていないケースが多いのです。
具体的にやりたいことが明確化していないため、参考サイトを指定するくらいしか方法がなく、その先のやりとりの中で、「あれっ、こんなにやりたいことが多かったのか」「予想以上の規模になってしまった」ということが発生し、結局のところ予算の関係などで、頓挫してしまうのです。
仕様書とは、自分がやりたいことを相手に伝えるための書類
では、上記のようなケースにならないためには、どうしたらいいのか？
そこで出てくるのが、「ドキュメント類」と呼ばれる、仕様書などの書類となります。
仕様書などというと、めちゃくちゃ分厚い紙の束が、青いファイルに挟まっていて、専門用語の羅列が並んでいる・・・といったイメージを持たれている方も多いと思いますが、そうではありません。
ここでいう仕様書とは、自分自身が「何がしたいのか」を、まとめた「要望書」のようなものです。
いわゆる技術者が作る、システムの「仕様書」とは若干テイストが違います。
要は自分がやりたいことを、相手に伝えるための書類です。
ですので、フォーマットなどは特にありません。
端的に言えば箇条書きの要望を書いた物でも、それは立派な要望書です。
全く想像も付かない！という方は、先ず「ほしい」と思ったウェブサイトの構造を、紙に書き出してみることから初めて見ましょう。
「こんなページがほしい」「こんな機能が欲しい」といったことを書き出すうちに、まずはサイトの構造が明確化してきます。
そこでサイト全体のページ数や、必要な機能がわかってきたら、次に「ページ毎の機能」をまとめてみます。
各ページ毎に「こんな機能が必要だ」「こういうボタンがあって、押すとこのページに」といった、簡易的な設計をしてみるのです。
こうすることで、サイトの全体が見渡せるだけではなく、各ページ毎に細かく考えていくことで、自分自身の頭の中も整理でき、「やりたいこと」が明確化するのです。
その程度まで明確化された要望なら、私たちも80％以上の確度で、金額を算定することができるようになるので、その後のお話も非常にスムースに進みます。
また、開発後も「こんなんじゃなかった」という仕様の不整合なども少なくなり、より正確なシステム開発が可能になります。
▼仕様書の書き方に関する参考記事（外部記事へリンク）
http://qiita.com/ko1/items/9f5f1a2683ea54f12362
さいごに
どうしても初期の初期ほど、手間をかけずに「おおまかな金額が知りたい！」ということは多いと思います。
ただ、エンジニアもエスパーではないので、その「やりたいこと」を、参考サイトだけで読み取ることは非常に難しいです。
結局、最初の手間をちょっと省いたがために、金額が全く違う見積もりがでてきてしまったり、開発の際にトラブルが起きたりと、負のサイクルにハマってしまうことになります。
最初だからこそ、まずは自分自身の考えを、ドキュメントにまとめることからはじめてみましょう。
まずはサイトに必要なページと、そのページに何が必要かといった、簡単なものからで大丈夫です。
私たちはある程度システムを知っておりますので、「何がやりたいか」が明確になっていれば、それに付帯するリスクや、開発に関わるコストなどが試算できるので、より正確になお見積やご提案ができるようになります。
正確な金額がわかれば、「この部分は予算に会わないから削除」「もう少し機能が追加できる」といった判断も出来ます。
双方が満足するために、意思疎通のための手段として「仕様書」が必要になるのです。