SAASQuanto para ao modelo por 2012Mercado de 800.000.000.000 YenTorna-se, ele parece.(Verdade?.)
Se nós supusermos que isto é, (fora de linha convencional) o piche de Venn que faz a venda do software do pacote instala o software do pacote ao usuário, aquele que se pensa se ao HTML conversos justos a parte dianteira, como o ambiente desktop ele não é oferecer os vários serviços que se ocupam da rede na mesma maneira outra vez ao usuário.90年代後半に盛り上がったASP時代が再び到来するようなもでしょう。
ネットワークを介してサービスを提供するとなれば、これはもはや非OS依存型のサービスになるので、Windowsの存在はどうなるのやら..。
最終的に、デスクトップに残るアプリケーションは、インターネットとメールだけになってしまうのでしょうか。
これを私の業界に当てはめて考えてみると次のような構図が見えてくる。
ウェブデザイン
ウェブデザインはクリエイティブな感覚が必要とする人間味あるサービスであるため、ソフトウェアとすることは難しい。ウェブデザイン自体の作成方法や作成技術は進化するかもしれないが、デザインを考案するクリエイティブな部分はどんなに時代が進もうとソフトウェア化できないのでSAAS化されることはありえない。
ECサイトの運営形態
ECサイトのソフト自体は自社サーバにインストールする自社運営型とモール型(楽天やYahooなど)の両方にそれぞれのメリットがあるため、今後も同時に進行されると思われる。これは今とそんなに変わるものではないと思われる。
ECサイトの販促系機能
ECサイト構築ソリューションとして、広告、アフィリエイト、アクセス解析、動画配信、アンケートフォーム、ヘルプデスクなどの各機能を補完すること自体が無意味なものになっていき、これらの機能ははいずれも全てSAAS化またはプラグイン(機能保管モジュール)化され、すべてが月額制で利用できるようになる。
受託システム開発だと、要件定義を出す側も、それを受ける側もそもそも共通言語を使ってだれも難しい話し合いなんかしたくない。日本にはいまだに共通のフォーマットがないから、プログラマと発注者でお互いが同じ言語感覚で話し合うことなどしたら、喧嘩になりがち。
受託はバージョン管理も、バグ管理も全てにおいて手間がかかる。受託がなくなることはなくても、受託を発注するプロセスやそのフローが何かSAASモデルによって改善されたらいいなと願ってます!
ECサイトの販売・顧客管理系機能
ここは、大幅に変更される可能性の秘めた領域だと思う。もっともベンダーの参入が多いと思われる。
現状のデスクトップアプリケーションで管理している受注管理や販売管理ソフトはすべてネットワークを介してサーバで管理されることになるだろう。業務系ソフトをSAAS化することにより、エンドユーザーは注文の編集やキャンセルを行いたいときに、メールや電話で連絡するのではなく、ログインをして自分の注文状態を確認し、自由に注文変更やキャンセルができるようになる。
懸念事項としてSAAS化することで全データをネットワークの向こうにあるサーバに保存することの抵抗感やセキュリティー不安の問題がある。
2重、3重のバックアップや、99.9%のアップタイムを保持できるだけの保守体制基盤作りにSAAS業者はコスト増を強いられ、この部分がSAAS化産業の成長の鍵になると思う。データセンターやセキュリティー系ベンダーがSAAS化を促進できるだろうか。専用サーバのホスティングサービスはホームページのホスティングから、データ保管のホスティングサービスに変化するのだろうか?
顧客サポート系機能(ヘルプデスク)
電話対応、メール対応などの顧客対応履歴を含むカスタマーサポートに必要な機能はSAAS化される。ホームページに必要なフォーム機能は、すべて月額制で利用できるようになる。
Tags: SAAS
約年間6万円で、意外にもサーバ障害時に保険的役割を担ってくれるソフトウェアがあったのはご存知でしたか?
データセンターに設置して、保守契約を結んでいれば話は別ですが、
そうでない場合、特に自宅や社内でサーバ機を設置している企業や個人にとって、寝ている間におこる障害が悩みの種であることは間違いないはずだと思います。
これを解決するにはサーバ系ベンダーとの保守契約やデータセンターレベルでの保守契約となるとおもんですけど、その額や高額になることがあります。サーバ1台の24時間オンサイト、オフサイト監視・一時対応、OSレベルでのセキュリティーパッチ更新、までやると最低でも月額5〜10万円程度でしょう。
サーバ費用以外に、これは痛たたたた…。
そこで、
ベンダー系のガッチリした保守までとはいかなくとも、もサーバに障害が発生したときにソフトウェアレベルで自動的に復旧してくれたらなんていいだろう。そんなソフトは果たしてあるのか?
実は弊社がサーバ管理ソフトとして販売しているcPanelでできてしまうんです!
この機能はサーバ管理者しか知らなくて、今まではホームページに紹介することはありませんでした。
今回cPanelのページに、サーバ保守系のページを新たに作成し、サーバ保守に対しする格安なソフトウェアとしても利用いただけることがわかったのでこの際、社内のサーバ保守にご活用ください。
今までスカイプというツールを社内部のコミニケーションツールとしての利用目的で使っていましたが、昨日からウェブサイトにもオンラインステータスを表示し、本格的にスカイプをお問合せのフロントラインとして使い始めました。
遠方や海外にお住まいの方で、対面での新規打ち合わせが現実的でないお客様はこちらをのページをどうぞ。
IT製品の場合、画面を見ながらサポートや商品の説明をしないと、相手に本当の理解は伝わりずらい。
お互いが同じ画面を見ながら、音声付で説明し、一緒に動作を体験することが、最も効率的な商品説明になると思います。
それにはスカイプがとても便利だと改めて感じます。
URLを直接送ったり、画像ファイルを送るのにもドラッグ&ドロップでできるので、これが電話だとURLを説明したりするのにも一苦労。。。
お問合せのページは次の通り。
新規のお客様の場合はこちらのような画像が表示されます。オンラインの場合、スカイプのオンラインボタンをクリックするだけで使えます。

サービスをご利用中のお客様はサポートセンターのページで部署を選択するときに、スカイプボタンを新設したので、直ぐに回答を求めたい時には役に立つと思います。

今回書いた海外、遠方のお客様をスカイプでサポートするという件ですが、会社案内のデジタルスタジオでは… にも追加しましたので、今後遠方のお客様にはぜひ活用いただければと思います。
世界中のありとあらゆるコンテンツサービスにおいて、時差はますますなくなってきたと思う。
アメリカ発のベンチャー企業が何らかのWEB2.0的サービスを公開したとすれば、その1ヶ月後、2ヶ月後には日本の品質で同じサービスが生まれる。サー ビス品質(顧客サポート、画面デザイン、説明補足)は異なるものの、アイディアやロジックは全部アメリカ生まれのものになる。違うのは日本人の品質に直す 必要があるだけだ。 (more…)
最近ブラウザが新しくなったこともあり、Eコマースサイトのウェブサイトを徘徊しているとたまに、SSLの有効期限切れウェブサイトやSSLにインストールされたドメイン名とウェブサイトのドメイン名があっていなかった為にエラーが表示されたり、またウェブサイト上のあらゆる所に不適切と思われる個所がいくつか見つかったりするものです。
特にEコマースに関しては、自分が制作するサイトと比較しながら見てしまう癖がありますが、少なくとも確認したほうがいい事項があるので今回紹介しておきたいと思います。
1.コピーライトの日付が古い
ユーザーは意外にフッター領域にある Copyright © 会社名< 開始年” の文字列を見ることがあると思います。
この”年”の部分が古い場合(たとえば1995 - 2005)、
・このホームページに掲載されている情報は確かか?(正しいのか)
・この会社は本当にビジネスをやっているのか?
コピーライトの日付が古いだけでユーザーはウェブサイトを疑ってしまう可能性があります。
解決策
PHPプログラムを利用すると次のように書ける。
1995年から開始している場合
Copyright © 1995 - <?=date(”Y”)?> 会社名
次のように表示される
Copyright © 1995 - 2008 会社名
2.SSLがドメイン名と一致していない
SSLがドメイン名と一致していない場合、これは致命的です。IE7、Firefox3のどちらに関してもSSLのインストールしたドメイン名と実用しているドメイン名が違っていたり、SSLの有効期限が切れている場合、下記のような画面が表示されてしまう。

ユーザーがこの画面を見た時、もしかしたら以下のことを想像してしまうだろう。
・フィッシング詐欺にあったのか?
・インターネット回線のトラブルにでもあったのか?
・パソコンが壊れてしまったのか?
ここでこのユーザーはブラウザを閉じることは間違いない。今すぐSSLが正しくインストールされているかどうか確認しておこう。
3.配送方法、決済方法に関する視覚的表示(バナー画像等)をしていない
どのような方法で支払ができるのかをすべてのページに表示すべきです。ユーザーは会社案内やFAQのページなどは実はほとんど見ないです。
商品をクリックしたら、後は購入完了まで一直線にクリックするだけだ。その過程でユーザーが考えることは次の3つくらいしかない。
・何日で届くの?(納期について)
・送料はいくら?(送料について)
・支払方法は何?
クレジットカードのロゴマークや配送業者のロゴマークがあればユーザーは視覚的に理解でき、支払手続きをスムーズに進めることができる。
4.「カートに入れる」などの各ボタン類のデザインへの配慮
ウェブ2.0の流行があってか、ウェブサイト上に置かれるボタン類や素材になんでも影を付ける傾向がある。これはこれでウェブサイトを美しくしていることに違いはないが、ユーザーがそれをボタンであることを認識できないことがある。
そのボタンがどのような目的で存在しているのかをもう一度考えてデザインする必要がある。
ウェブ2.0系のウェブサイトではAJAXについても多用されている。ユーザーがAJAXのアクションを実行したときに、Loaddingしてページを読み込みしていることがわからないとユーザーはその先にあるページを見る前にページを閉じてしまうことがあるかもしれない。
これもAJAXを利用している場合(特にデータ量が多い読み込み)は改善する必要があるだろう。Loadingアイコン素材はこちら
5.貧弱なサイト内検索
Googleは今やとても有名で誰もが使う検索エンジンです。これはGoogleの検索能力の高さが証明しています。また1秒以内に結果をはじき出す高速性も重要です。
サイト内検索機能で、ユーザーがミススペルをしたときに補完語を表示できる機能はありますか?
もしない場合はGoogleをサードパーティーとしてサイト内検索に使うか、それに代わるサードパーティーを探すべきです。
今やユーザーはGoogleが示す「検索する」という傾向にあると思います。
理由は以下の通り。
cakeや他のフレームワークにあるような自動生成やORMなどは確かに魅力的だが、どれもそれをまたフレームとしてつくれる要素を残した中途半端というか、フレームワークっぽくないところが逆にプログラムの組み手にとっては自由度があって良かったりする。
その中途半端な部分を独自に自由に組み立ててたり、特定の必要機能だけをスポットで使ったりできるのは骨太フレームワークに比べた時、最初の開発に一時的に時間はかかるものの、自分で書いているので迷路入りすることはまずないだろう。
つまりフレームワークのスクリプトの依存度は少なく、自分で書いたコードの範疇で自己解決を見出すことができそうだとZend Frameworkは判断した。
一方cakeやsymfonyを採用した場合、開発スピードを早めたり、余分なコードを書かなくて済んだりと初期開発時のメリットや、第3者が介入してもコードの体裁は保たれるものの、迷路入りした時の自己解決において最終的にフレームワークそのものを理解する必要があったり、フレームワークの外に出たい時に(例えば外部のjavaやaspと連携など..)ドキュメントを1から読み返したりとなると、フレームワークの皿の上で踊らされているスクリプトになってしまうと判断した。
フレームが頑丈すぎて一度操作し始めたら、何を動かしていいかわからなくなってしまう。行きたい所に行けない。フレームワークの呪縛にかかってしまうという懸念がどうしても取り除けなかった。
これもPGのセンスや感覚なので十人十色だと思うが。
入口がPHP4から入ったものとしてのあくまで結論です。
先述した『中途半端というが、フレームワークっぽくないところ』が将来やりたいことを実現するときに苦労はあるが、自分で書ける要素が残っているし何より自分で書いたコードの方がアドバンテージがある。(単なる自己満にすぎないが)
GoogleやIMBがスポンサーになってたり、PHP本体の開発を手がけているZENDがサポートしているのもプラスファクターになっている。
では、Zend Framework一本でコードを書いていきます!
簡単に今後のフローを説明しておくと、MVCのロジックにデータベース、ビュー、スクリプトを全部分解して再度コーディングです。
その後、LiveCommerceで独自に開発したクラスライブラリーやファンクションをZend Frameworkの中にインクルードして両方のスクリプトが利用できるようなイメージで再開発する予定です。
本日、弊社で販売中のヘルプデスクeSupportのさらに分かりやすく、どうしてこんなに使うのかを書いた記事を新たに追加しました。