DEVELOPERS BLOGデベロッパーズブログ
- HOME >
- 牧山 直紀のデベロッパーズブログ >
- ポータルサイト・マッチングサイトの構築に関するあるべき見積もり方法
牧山 直紀のデベロッパーズブログ
- 氏名
- 牧山 直紀
- 役職
- 代表取締役
- 血液型
- O型
- 出没
- 主に南国
- 特色
- サメが好き
- 2016/06/02
- WEBメディア運用事業の開始します
- 2015/11/25
- オウンドメディアとは?構築費用、作り方、運用などに関して解説
- 2015/10/08
- ポータルサイト・マッチングサイトの構築に関するあるべき見積もり方法
最近作りかけのポータルサイト・マッチングサイトの改修のご相談をよくいただきます。今月はまだ8日なにのも関わらず、すでに2件ほどご相談を頂いています。
作りかけのサイト改修に関しては、ほとんどが以下のようなケースになります。
他のベンダーさんに発注して構築をしていたが、途中で予想していたものが出来そうにないことに気づき、ベンダーさんと揉めて開発が止まってしまい、ただせっかく途中まで構築しているので、続きは他のもっと安い会社でやってほしい。
しかしこういったケースのほとんどが、途中まで開発したものは一旦捨ててしまいゼロから他社で構築する。かまたは、開発をあきらめる。といった結果に落ち着きます。
以下実際に最近いただいたクライアントAさんのご相談を紹介してみます。
クライアントAさんより弊社に見積依頼が発生
↓
お見積りを提出
↓
競合より20%ほど割高という事で他社に決定
↓
他のベンダーさんにて構築していたが、思ったような出来ではなく、追加構築をそのベンダーさんに依頼
↓
そのベンダーさんに追加構築を断られる
↓
どうにもならなくなり、最終的に弊社にその部分のみの構築が出来ないか相談のお電話を頂く
他のベンダーさんが構築したプログラミングに手を入れるべきかどうかの判断のため、システム概要を見せて頂きましたが、結局拡張できるような作りではないため、デザインのみを利用して弊社のパッケージにて再構築する提案をさせて頂きましたが、予算をすでに使ってしまっており、サイトの構築自体を断念する、という結果になってしまいました。
一見、拡張性の低い設計をしたそのベンダーさんが悪いようにも聞こえますが、それだけではありません。
まずクライアントAさんは、細かな機能要件をベンダーさんに確認せず、サイトの構築依頼を丸投げしてしまっていたのです。当然ですが、こんな感じのサイト、というのはもちろん話しているのだと思いますが、こんな感じのサイト、というふんわりしすぎたイメージだと、受け取る側によって大きく必要な要件が異なってきます。
例えば、美容室を検索できるサイトを作って、と依頼があった場合、
美容室の検索なら、ワードプレスでさくっと作っちゃおう。という判断も出来れば、逆に、美容室の検索という事は、検索対象となる美容室が自身で情報を編集できた方が良いのだろうか?と深堀して考えることも可能です。
確かに弊社のお客様でも、あまりに丸投げな要件がぽ~んっと飛んできて、こんな感じで作っておいて、ということもあるのですが、勝手に要件を決めて作り、後で「こうなると思っていた」となってしまえば、今回と同じ結果になってしまう事が分かっているため、当たり前ですが、構築する内容の事前確認を出来る限り行うようにします。
弊社の場合、例えば美容室のポータルサイトを作りたいというざっくりとした依頼を受けたらまず、クライアントに合うか、電話などして、要件をしっかりヒヤリングしたうえで、その要件に合致する見積りを作成します。またその見積りだけだと内容が分かりにくい場合もあるので、見積もりにプラスして、
■構成図
(サイトマップと呼ばれるそのサイトを構成するページをすべて洗い出した図)
■登場人物
(どんなユーザが存在して、それぞれマイページが存在するのか?)
■登場人物ごとにそれぞれ出来る事
■主要機能の流れ
など(規模や内容によってプラスする提出物もある)を必ず提出するようにしています。
このケースで言えば、上記事項をすっ飛ばしてしまっているため、お互いが「こんな感じになるだろう」という曖昧な予想のまま制作物が完成し、結果、クライアントAさんの意図していなかったものになってしまったという流れです。
弊社が行っている上記の見積もりの流れが、100%完璧ではないにしろ、正確な見積もりを作るだけでなく、その見積りがどのようなページ、機能を含んでいるかをクライアントが理解しやすくすることに貢献はしており、結果クライアントからは見積もりが分かりやすいとよく言っていただけます。
上記の見積もりの流れは弊社独自のものです。ベンダーさんごとに得意とする分野は異なります。システムが入らない企業サイトなどを得意としていれば、おそらく構成図と見積もりだけで十分にクライアントにも内容が伝わるでしょう。
弊社が上記の見積もりの流れをて徹底しているのは、ポータルサイト、マッチングサイトの場合、登場人物が多くなるサイトが多く、ページ数も多い。そうなれば見積もりの内容も細分化され、よりクライアントには理解し辛いものになります。
それはそれでトラブルの原因にもなるため、この流れが完成したとも言えます。
もし現在ポータルサイトやマッチングサイトの構築を考えている方で、このページを見ていただいているのであれば、ベンダーさんに見積もり依頼をする場合は、こんな感じのサイトを作りたいので、概算見積りをお願いします、と伝えるだけではなく、
・サイトの概要(できるだけ細かく。概要が固まっていない場合は、合うか電話などで、概要を固めるところから相談してみる)
・登場人物
・登場人物ごとにそれぞれ出来る事
・主要機能の流れ
をベンダーさんにしっかりと伝えたうえで、見積もりの際に、簡単な構成図(サイトマップ)を提出してもらいましょう。(まぁ、ほとんどの方がそうすると思いますが、、、)そして出来れば、見積もりと、構成図を照らし合わせて、その内容が、ベンダーさんに伝えた内容を加味して作られているのかを確認しましょう。
もちろん概要は、ベンダーさんに色々と相談してから固めたいという方も多いので、それはそれでしっかりとベンダーさんに話を聞いてもらうべきです。そこから、上記事項を固めていきます。
弊社の場合、美容室を検索できるサイトを作りたい、というご相談があった場合、まず合うかお電話などで詳細(サイトの概要をより詳しく、登場人物、それぞれ出来る事、主要機能の流れ)をお聞きして、以下をお見積り、構成図と合わせて提出しています。
サンプルという事で、かなり省略しておりますが、ご了承ください。
---------- 【サイトの概要】 ----------
サイト訪問者が美容室を検索して、予約ができるサイト
---------- 【登場人物】 ----------
サイト訪問者(マイページ有り)
美容室ユーザー(マイページ有り)
運営管理者(マイページ有り)
---------- 【それぞれ出来る事】 ----------
▼サイト訪問者
・サイトのコンテンツの閲覧
・会員登録
・ログイン
・美容室の検索、予約
・マイページにて登録情報の編集
・マイページにて予約済みサロンの確認
・マイページにて退会
・ログアウト
▼美容室ユーザー
・美容室ページの編集
・フォトギャラリーの管理(登録、編集、公開非公開など)
・スタッフの管理(登録、編集、公開非公開など)
・クーポンの管理(登録、編集、公開非公開など)
・予約の確認、管理
・課金内訳の確認
・ログアウト
▼運営管理者
・ユーザーの管理(編集、公開非公開など)
・美容室の管理(登録、編集、公開非公開など)
・フォトギャラリーの管理(登録、編集、公開非公開など)
・スタッフの管理(登録、編集、公開非公開など)
・クーポンの管理(登録、編集、公開非公開など)
・カレンダーの管理(登録、編集、公開非公開など)
・予約の管理(登録、編集、公開非公開など)
・課金内訳の管理(登録、編集、公開非公開など)
---------- 【予約の流れ】 ----------
サイト訪問者が美容室を検索して、気に入ったサロンがあれば予約
↓
予約通知メールがサロンに送付される
↓
サロンが予約内容を確認して問題なければマイページから承認
↓
予約確定通知がユーザにメールにて送付(この時点で予約課金発生)
その後の日時の変更はサロン側にて予約の管理から行えるようにする。
やりとりは予算圧縮のためサイト内でのメッセージ交換機能などは
作らずに、メール、電話にて行っていただく。
---------- 【カレンダーの管理】 ----------
サロンは、予約が可能な日時を、マイページの
カレンダー管理から登録することができる。
曜日、日時、期間などを指定して、あまりサロンに
負荷をかけずに、予約日の管理が一括に行えるようにする。
---------- 【請求の流れ】 ----------
運営者のマイページに、サロンごと、月ごとの請求額及び
内訳を閲覧出来るようにします。
また同じく、サロン側のマイページでも、課金の内訳を
月ごとに閲覧出来るようにします。
などなど、通常は、上記の内容をさらに掘り下げて、
提案事項とします。
あくまでも初期の提案事項ですので、ここから打ち合わせを重ね、さらに機能の詳細を詰めていき、より正確な内容にして、最終的にどこまでを機能化するか、どれほどの予算で落ち着けるかを決定していくのです。
ですので、実際に受注に至るまで、ステップが長いのであります。
当然クライアントさんの中には、最終ステップの段階で、他のベンダーさんにも見積もりをしたいという要望もあります。
その場合弊社では、弊社が作成した構成図や要件など、すべて他のベンダーさんに開示をしていただくようにおすすめしております。全く同じ機能要件で、ほかのベンダーさんがより良い提案が出てくるのであれば、それはそれで、良いことだと思います。
話は戻りますが、上記で紹介したクライアントAさんの場合は、弊社が提出していた要件すべてをその業者さんに提示した上で見積をしていれば、今と同じ結果にはなっていないはずです。
投資したお金も戻ってこない、時間も当然戻らない、そして手元には何も残らない。たとえ契約書を交わしていても、見積もりの段階で、どんなものを作るかを明示している要件書がなければ、支払ったお金がもどってくる可能性は低いです。
そんな悲しい過ちを犯さないためにも、発注者になる方も、上記を参考に多少は知識武装して、ポータルサイト・マッチングサイトの構築に望んでいただければと思います。
関連エントリー
- 2014/10/07
- ウェブメディア・ポータルの成功事例
- 2014/06/26
- 電力小売りの自由化に伴いポータルサイトを作ってみては??
- 2014/05/21
- 過度な構造的SEOもやりすぎはNG!!
- 2014/03/21
- 低価格でマッチングサイト・ポータルサイトの構築も出来る!
- 2014/01/20
- アナログが必要不可欠なマッチングサイトのビジネスモデルもある
- 2013/12/15
- クラウドソーシングの構築に関して
- 2013/07/19
- ポータルサイトのアイデアを一つ
- 2013/06/27
- ポータルサイトは運営管理側CMSが必要不可欠
- 2013/06/10
- マッチングサイトの課金モデル
- 2013/05/29
- ポータルサイトのパッケージ利用のメリット・デメリット
- 2013/05/23
- ポータルサイト作り方
- 2013/05/20
- 検索サイトを運用する上で気をつけるべき0件表示対策
- 2013/05/14
- 求人サイトにおける成約の把握機能「お祝い金」
- 2013/05/07
- マッチングサイトのデザインの在り方
- 2013/05/01
- ポータルサイトの成功事例よりも失敗事例から学ぶ
- 2013/04/30
- 質が伴わなければ意味が無い⇒プロテインとSEOの関係
- 2013/04/16
- ポータルサイトの設計:多機能が故にユーザを遠ざけてしまっている
- 2013/04/15
- 求人サイト、人材マッチングサイトのビジネスモデル
- 2012/12/19
- マッチングサイトはオープンソースでは妥協の産物になる可能性が高い
- 2012/12/05
- マッチングサイトとポータルサイトの違い
- 2012/11/13
- ウェブメディアを運営する上での成功するかしないかの分岐点
- 2012/10/31
- 自社サイトをポータル化するメリット
2020/12/15
2020/11/12
2020/10/05
2020/09/11
2020/08/03