makoto_fujimotoのblog

株式会社進角
代表 藤本信のブログです
どうぞよろしくお願いします

カテゴリ: IT営業

Web上で車のカラーリングやオプションをカスタマイズしてリアルタイム表示しながら見積もりが出来たり、スポーツ用品のオーダーメイドなどができるシミュレーターアプリがあります。開発ソリューションとして古くはShockWaveあたりを起源としてFlashでスタンダード化し、最近はiOSへの互換性を考慮したJavascriptが主流となっています。また各スマホなどに特化したネイティブアプリ形式の開発手法があり、かれこれ10年以上の歴史があります。

導入にはパッケージ(クラウド型もある)を利用したりフルスクラッチで開発する必要がありますが、いずれも高機能であるがゆえ高価なので、費用対効果について十分検討する必要があります。

せっかく導入しても利用されず陳腐化することを避ける為にも導入のメリットとデメリットについてまとめてみましたので参考にしてください。

メリット
1. Web上でオリジナルデザインが出来て完成形がイメージできる
2. アプリを操作すること自体に楽しみがある
3. 費用がすぐに分かる
4. 接客やヒアリングが省略されるので業務が効率化される
5. 24時間365日注文を受け付けることができる
6. 商品への愛着が強くなったりカスタムオーダーサービスのPRになる

デメリット
1. シミュレーション完成までにある程度の専門知識とセンスと根気が要求される
2. アプリが動作する環境に制約がある
3. イニシャルコストと更新コストが高い
4. 技術的な制約があり完全にはリアルの注文と同じことを実現できない
5. 素材入稿や試作が必要な場合がありシームレスなワークフローには出来ない
6. 単価が低かったり数が少ないと収益性が悪い
7. お客さんが思っているイメージと出来上がった商品が違う可能性がある


http://www.goldwin.co.jp/champion/cgi/3dsimulation/teamwear.html

ちなみにこちらの事例はチームウェアのシミュレーターですが、操作してみて感じるのは、エンドユーザーにここまで細かい選択を任せるのは非現実的ではないかと言うことです。リアルに近い注文をWebで実現できるのは良いですが、これでは逆にオーダーに精通した専門スタッフが接客しながら操作するのがやっとのツールになってしまっていないでしょうか。

特に上記のメリット4については販売側の合理性を取り入れると逆に顧客に対して不親切になってしまう可能性があるので要注意です。あと個人的にはこれらのシミュレーターに触れてもあまり目新しさを感じなくなってしまったので販促に繋げるにはよほどのユーザーエクスペリエンスの提供が必要だと思います。

私たちが日常的に交わしている言葉の中に語源が魚釣りにまつわるものが意外と多くあります。また常用されることは少ないですが、魚釣りにまつわる諺(ことわざ)なども日常の出来事を暗示してものが多くあります。これらは何気なく使用されていますが、実際の魚釣りを体験しているのと、いないのでは文脈の伝わりが段違いになると思います。ですから魚釣りをできるだけ若いうちに体験しておくことを僕はおススメします。

【ポイント】
魚は海や川の中を均一に泳いでいるわけではなく、餌が豊富だったり外敵に襲われにくい場所や水深に偏って生息しています。このような特定の場所を見つけるには日々の情報収集や創意工夫、そして場合によっては餌付けや物量作戦が必要となります。ビジネスにおいてはポイントを見つけたり活性化するのがマーケティング活動と言えますね。

【一本釣り】
カツオの一本釣りが有名ですが、一人の漁師が一本の竿と針で魚を一匹ずつ釣り上げるという潔い釣りです。余計な試みをせず、狙いを明確に定めて集中して狙うという戦術です。

【海老で鯛を釣る】
これは少ない投資で大きな見返りを得ることの例えですね。たまに安物の仕掛けでいい加減に糸を垂れていたら思いがない大物や高級魚が釣れるこがあります。仕事でたなぼた的な成果が出ることもたまにありますね。

【こませ(撒き餌)】
ポイントを狙うのではなく、集魚効果の高い細かな餌を自分の釣りやすい場所にばら撒いて、おびき寄せられた魚を集中的に釣り上げる能動的な方式です。チラシや試食やクーポンなどの一般的な広告手法ですね。

【ごぼう抜き】
この語源は魚釣り用語ではなく、実際のごぼうを収穫する際に一か所を引っ張ると一気に全体が姿を現す様をとらえたものだと思いますが、魚釣りでもよく使われます。通常魚がかかったら取り逃がさないように慎重に竿を操って糸を手繰り寄せ、大物であれば最終的に網などを用いて取り込みますが、躊躇せず一気に竿の弾力と糸の強度を頼りに魚を水中から引っ張り上げる行為です。

【逃がした魚は大きい】
失ったチャンスは大き目に見えるものです。また「あと少しのところで・・・」という言い訳をしてしまうのはオトコの性ですね。

【見える魚は釣れない】
釣り場の透明度が高いと泳いでいる魚が見えることがあります。しかし不思議なことに、そこに仕掛けを投げても魚に見向きもされず釣れないことがむしろ多いのです。これは透明度が高いゆえに相手(魚)からも釣り人や敵の様子が良く見えて警戒している状況にあるのです。

--2014.5.22加筆

【スレる】
エサをたくさん与えられてお腹がいっぱいになったり、ルアー(疑似餌)がひっきりなしに投げ込まれるので興味を失ったりエサじゃないことがばれて簡単には釣れなくなってしまった状態です。こんな時はあきらめて釣り場をしばらく休めるか、違ったエサや仕掛けで魚の興味を引く必要があります。

Windows系VPSサーバのレンタルサービスを行っているところは あまり多くないのですが以下のようなものがあるようです。

使えるねっと
http://www.tsukaeru.net/smb/vps/
シルバー 1,880円~ (Windows Server 2008R2)

GMOクラウドVPS
http://vps.gmocloud.com/service/
スモール 2,980円~ (Windows Server 2008R2)

ちなみに主要各社の調査状況

CPI :なし
ファーストサーバ:なし
お名前.com :なし
GMO(旧アイル) :なし
さくら :なし
ビットアイル :なし

営業担当者にとって、システム開発の見積もりはけっこう頭を悩ませるんじゃないでしょうか。要件や仕様書が専門的だったり不十分だったり、引き合い段階では未確定な要素が多かったりします。しかも、顧客想定から大きく外れると受注できなかったり赤字になる可能性も高く、概算とは言えいい加減な数字は出せません。

ちなみに見積り依頼があった際、プログラマーに「工数計算しといて」などと丸投げし、やっと上がってきた工数に対して鉛筆をなめて出したりしていませんでしょうか?これだと顧客が「今すぐ概算をくれ」と言っている状況では時間がかかって心象がよくありません。

そんなことをせずに、開発に直接タッチしない営業担当でも比較的精度の高い概算を算出できる方法があります。

それはデータベース(テーブル)の数だけを推測する方法です。

なぜかというと、データベース(テーブル)数というのは入出力(画面等)の数と概ね相関しており、当然工数も相関しているからです。部屋の数と出入口、窓の数、照明数などが相関しているようなものです。この際「いやいや、面倒な仕様だったら想定以上にかかるぞ」という制作現場のごもっともな意見はとりあえず無視します。

データベース数を推測するのはある程度のセンスを必要としますが、たとえばECサイトであれば最低限、商品マスタ、売上情報、顧客情報の3点が推測できます。少し複雑になると商品マスタ、在庫情報、売上情報、仕入先マスタ、リコメンド情報、ポイント情報、顧客情報など7点以上になったりしますが、切り口さえわかればエンジニアじゃなくてもそれほど難しい行為ではありません。

データベースの数が推測できたら、あとは基準となる単価を掛けるだけで概算見積りは完了です。

これだったら電話口で即答できる可能性もあります。

仮に1データベースあたりの単価を30万円とした場合、テーブルを3つ使用したシステムは概算で90万円という単純計算になります。この事前の単価設定プロセスにおいては"諸般の事情"や"比重"を加味してあげれば制作現場から怒られることも避けられます。ただし市場価格については堂々と営業・経営マターで設定すればよいのではないでしょうか。

もう少し具体的な係数を使って算出してみましょう。
①データベース数:5
②単価:30万円
③設計費係数:0.1
④間接費係数:0.2 (制作進行管理、デバッグ、現調、経費、営業管理費など)

①×②+(①×②×③)+(①×②×④)=195万円

この算出方法はデータベースを使用するシステム案件に限ったものですが、概算を即答するコツは制作者や外注に積算させなくても、単純な数を推測するだけで算出可能な根拠をあらかじめ作っておくことだと思います。

余談ですが、建築業界は概ね床面積とグレードで施工価格が決まるそうです。

事業会社がWebサービスを計画している場合、専門のSI業者などから提案や見積もりをもらう為に、できる限り詳細で将来発生しうる事象を見越した要件を伝える必要があります。この資料をRFPすなわち提案依頼書と言います。
以下の例は比較的汎用的な内容となっていますので参考にして頂ければと思います。


-----------------------------------------------------

本要件定義は、○○○情報端末(以下「情報端末」という)をプラットホームとする○○○サービス(以下「サービス」という)を提供するにあたり、安定したサービス運用とコミュニケーション活性化を実現するインフラ環境の与件をまとめたものである。

  1. 想定環境

    情報端末数:最大○○万台
    常にアクティブ※な情報端末の割合:○○%
    最大サーバアクセス:瞬間コネクション○万Connect
    最大Webヒット数:○○○○万hits/日
    最大メール送受信数:○○万件/日
    最大投稿数:○○万/日

  2. データセンター
    運用担当者が営業時間帯において1時間以内に移動が可能な立地にあり、耐震・防火設備、熱対策、入退室管理、入出庫機器管理、ID認証、監視カメラ、手荷物検査、施錠可能ラック、追加電源対応、停電対策、津波・浸水対策が施されており、工具・モニタ・キーボード貸与、一次保守(リセット、ランプ確認、ケーブルメンテ)、24時間保守要員が常駐し対応が可能なこと。

  3. インターネット回線
    最大○○○Mbpsの回線速度とし、SLAあるいは相応の安定した可用性と帯域実績があること。独自IPアドレスを○○個以上取得する。情報端末に容量の大きなファイルを一斉配布する場合は外部のCDNやクラウドサービスを活用することも想定する。

  4. ファイアウォール
    WANとの接点にWAF(Web Application Firewall)型のアプライアンス装置を設置し、SQLインジェクション、XSS等アプリケーションレベルでの攻撃防御に対応する。

  5. ロードバランサ
    Webサーバの各種指標による負荷分散と障害時の自動切り離し機能を基本とし、各種クライアントに対応したセッション維持機能持つL7対応の機器を想定。また容易にWebサーバの増設・保守に対応できるもの。

  6. スイッチ
    サーバ機器等のネットワーク接続に用いるスイッチは、L2以上のインテリジェント型とし、ギガビット1000BASE-T、ポート毎のパケットバッファ搭載を満たす機器とする。

  7. OSおよびミドルウェア
    LAMP構成を基本とする(データベースはPostgreSQLも可)。サービス公開時点においては最新安定版かつ既知の脆弱性・バグ対策済みのバージョンとし、運用時は容易にパッチ適用対策が可能な構成とする。

  8. サーバ構成
    サーバは用途別に構成し、機能及び負荷、メンテナンス等による干渉を避けるようにする。機能の追加・改修やコンテンツの事前確認用としてステージングサーバ環境を用意する。Webサーバは将来アクセスが増加した際、容易に台数の増加が可能な構成とする。データベースサーバはハードウェア増強によるスケールアップに対応できる機器とする。

  9. データベースサーバ
    より安全性の高いネットワークに設置し、外部から直接アクセスできないようにする。障害対策として冗長化構成とし、同期型レプリケーションを行い、速やかなサービス復旧が可能でデータ毀損の発生しないシステム構成とする。

  10. サービス側のシステム要件に備え、DBMSに全文検索機能を実装する。

  11. Webサーバ
    一日最大○○○○万hits、○○○万pvのサーバサイドスクリプト含むHTTP(S)リクエストの処理が可能な構成に最適化し、負荷分散・障害対策も考慮する。

  12. ストレージサーバ
    ユーザコンテンツの格納先として、1アカウントあたり○○○MBを上限とする領域を確保し、使用率は最大○○%を想定する。将来の拡張を想定した論理設計を行う。障害時のリカバリ対策として冗長化構成とする。

  13. その他サーバ
    各種用途に特化したハードウェア性能と最小限のミドルウェア稼働やアクセス制限を構成して最適化する。

  14. バックアップ
    ハードディスク障害発生に備え、ユーザコンテンツファイル、ログ、データベース、コンテンツ、プログラム等を日次でフルバックアップを実施し、データベース、コンテンツ、プログラムについては過去○世代保持できるようにする。

↑このページのトップヘ