クラウドサービスの種類

最近ではクラウドという言葉がいろいろな場面で使われていますが、クラウドもサービスレベルによっていくつかの種類に分かれます。

クラウドと言うと、データを自分のパソコンではなくインターネットを通じてサーバに保存するものというイメージですが、サービス提供者側からの視点でどこまでのサービスを提供するかによって異なります。

まずは、GmailやブログのようにWEBアプリケーションまで含んだサービスをSaaS（Software as a Service）と言います。

ちょっと昔だとASP （Application Service Provider）と呼んでいたりもしました。

続いて、アプリケーションを開発する実行環境を整えたものをPaas（Platform as a Service）と言います。

OSからミドルウェア、フレームワークなど、開発に必要な環境が既に整えられているサービスとなります。

GoogleのGAEや、セールスフォースのForce.com等があります。

最近増えつつあるのが、このPaasに共通で使われてるような部品まで整えられているBaaS（Backend as a Service）です。

バックエンド機能を提供しているもので、プッシュやメッセージ機能などモバイルアプリに特化しているものが多く、ニフティクラウドやkiiクラウドなどがあります。

クラウドと言えばAWSを思い浮かべますが、WEBサーバやDBサーバなどハード、OS、ミドルウェアを用意したものをIaaS（Infrastructure as a Service）と呼びます。

レンタルサーバもこのレイヤーに分類されます。

また、ファイルストレージのみの利用であるiCLoudなどはこちらに分類されます。

ビジネス用途で最近少しづつとりいれられているのがDaaS（Desktop as a Service）で、OSレベルもクラウド化してしまうものです。

OSをクラウド化するとクライアントPCは通信と画面表示出来ればいいので、性能が低いもので充分となりこういった端末をシンクライアントと呼ばれDaaSと一緒に話が出ます。

DaaSに関しては、少しカテゴライズや用途が異なりますが、それ以外のサービスを選択する際には提供するサービスや機能から考慮する必要があります。

また、最近ではいろいろ組み合わせたハイブリッドの形も多いので、まずは概念を理解する事が重要です。

ご訪問ありがとうございます。
応援のために１日１回クリックお願いします。
↓　↓　↓

人気ブログランキングへ

問い合わせ窓口

サイトを運営する上で、マーケティング上でも顧客満足度上でも大変重要なのが、問い合わせ窓口です。

問い合わせ窓口はサイト規模によって、電話で受け付けていたりメールで受け付けていたり、最近ではチャットでのサポートまであったりします。

この問い合わせ窓口が何故重要かと言うと、ユーザーとの接点で購入などのコンバージョン以外にあるのがこの問い合わせ窓口だからです。

問い合わせ窓口には、いろいろな質問・意見やクレームなど問い合わせ来ます。

ですが、この問い合わせ窓口の位置付けがクレーム処理と思っているのと、いろいろな意見を頂く場と考えているのとでは大きく異なります。

問い合わせの中には、新しい商品開発のアイデアや満足度を上げるポイントへの道しるべがあったりします。

また、クレームがおおきければ大きいほど、真摯に対応する事で逆にフアンを増やす事も出来ます。

この問い合わせ窓口の対応如何によって、ユーザーからの見られ方が大きく異なります。

まず、問い合わせ対応で重要なのが返信の早さです。

メールでの問い合わせの場合にすぐに返信しなかったり、電話での折り返し対応が遅れると、対応そのものが間違っていなくても満足度が大きく下がります。

確認に時間がかかる場合にはその旨と目処を連絡したり、目処の時間から遅れる場合にもその連絡を素早くする事が大切です。

また、指摘や意見をいろいろもらう場合に、企画会議にはそのリストを抽出してそこから取り入れたり、取り入れた場合にはユーザーにフィードバックすると大変喜ばれます。

例え、連絡から半年や1年経過していても、自分の意見が取り入れられた事にユーザーは大変満足してくれますので、フィードバックする事でフアンも増やしていく事が出来ます。

このサポートセンターに対して、重要視しているかが如実にあらわれるのが、どれだけ投資しているかです。

システムに対する投資は、目に見えやすいため積極的に投資しますが、問い合わせ窓口をコストと考えていては満足なサービスが提供出来ません。

過剰に投資する必要はありませんが、返信が遅れたりするほど人員が不足している状態であったり、教育ができていない状態は改善する必要があります。

ご訪問ありがとうございます。
応援のために１日１回クリックお願いします。
↓　↓　↓

人気ブログランキングへ

スクラムとは

アジャイル開発のもう一つの問題は、ウォーターフォールに比べて開発における人員体制や、作業の動きもマインドも異なるため、ウォーターフォールに慣れているメンバーの考え方を切り替えるのに再教育が必要となります。

アジャイルにおける開発手法として代表的なものがXPとスクラムです。

XP（エクストリームプログラミング）とは、少人数の規模の開発に向いており、メンバー個々の責任を重視するものです。

開発を1～2週間程度の短い期間で設計/実装/テストを繰り返し（反復）行い、未完成なシステムを徐々に完成形に近づけていくやり方です。

また、開発自体も一人ではなく実装とチェックの二人で行うペアプログラミングを基本とします。

ソースコードはチーム全員で共有し、誰でも変更する事が出来ますが、責任をチーム全員で持ちます（共同）。

求める機能のコンセプトを短い文章でストーリーに起こし、無駄を省いて今必要な機能だけのシンプルなもの（YAGNI：You aren't going to need it ）にし、内容についてはチームで合意をしながら進めていくやり方です。

各個人個人の責任を重視しながら、チーム全体で共同・合意し調和を持つ事でバランスを取っています。

もう一つのスクラムですが、こちらはチーム全体で開発を推進していく開発手法です。

イメージとしては、ラグビーでスクラムを組むようにチーム全員が一丸となって推し進めて行くものです。

そのため、チームをまとめるスクラムリーダーは引っ張って行くというより、困った際にサポートしたり調整したりする役割に重きを置く事で、メンバーに主体性を持たせながら進めます。

まず、機能や技術的改善要素に優先順位を付け、その中から優先で1ヶ月程度行うタスクを抜き出してタスクボードに書き出します。

そこから各フェーズに分けて実行していくのですが、大枠では各フェーズの担当を決めて、手が余った際には人員が足りていないフェーズに入りフォローします。

つまり、自主的に各フェーズが効率化されるように人員がフレキシブルに移動する事で全体が最適化されます。

ですので、各メンバーが自律的に動かなければ成り立たず、今までのリーダーが仕事を割り振って行うスタイルと大きく異なります。

これらアジャイルでは、品質管理もドキュメント管理もウォーターフォールとはやり方を変えていかないといけないのですが、まだまだ成熟されていないワークフレームなため、確固たるものはなく独自アイデアを出しながら状況に応じて進めなくてはなりません。

ですが、時代背景も変わっており、心ならずともその中に入っていくしかしょうがない状況となっていますので、前向きに捉えて自社の商品がどのような仕組みやワークフレームで開発するのが適しているか考え、様々な手法を取り入れていく必要があります。

ご訪問ありがとうございます。
応援のために１日１回クリックお願いします。
↓　↓　↓

人気ブログランキングへ

アジャイル開発

では、実際の開発手法がどう変わっているかなのですが、以前の上流工程から下流工程を順序立てて行う手法をウォーターフォールと呼んでいます。

水が上流から下流に流れる様子を模してそう呼んでおりますが、システム開発のほとんどがそうでした。

認識の相違やコミュニケーションロス、引き続きも出来るようにドキュメントをしっかりと作成して、また大規模なシステム開発だと工程によって人員の割り振りをしていました。

それに対して、完全なシステムを一気に作るのではなく段階的に作ってはリリースし、リリースしたものを短いサイクルで改善していく開発手法をアジャイルといいます。

また、それとは別で簡単に動く製品モデルを作成し、使い勝手や動作を検証しながら開発していく手法をプロトタイピングといいます。

最近では、この違った開発手法を組み合わせながら行っていくのがトレンドとなっています。

例えば、新規開発の際はウォーターフォールを基本としながら、各工程毎にアジャイルを取り入れ反復し、デザイン制作工程のみプロトタイピングでプログラミングを埋め込んでいないデザインテンプレートをリンクで繋げて使用感を確かめて、微調整していくといった感じです。

新規開発が終わった後は、アジャイルで短いサイクルの改善・改修を繰り返していきます。

アジャイル開発の問題は大きく2点あります。

1点目が契約の問題があります。

アジャイル開発では、プロジェクトマネージメントでいうスコープやリスク管理が難しく、明確な定義が出来ないため見積りの精度が低くなります。

そのため、システム構築単位の契約である請負ではなく、人員リソースに対する支払いである準委任契約にして、かかった時間相当の支払いをする形でないとトラブルが増えてしまいます。

そうなると、時間相当へのコストになりますので、発注先企業は良い人材を指名買いとなる傾向になります。

本来であれば内製化していればその様ないざこざはないのですが、ベンダー先に外注する比率が多い日本では上記の問題があり、なかなかアジャイル開発が進みにくい傾向にあります。

ですが、世の中の流れに応じて動いていかないと、サービス展開の上でも競合対策の上でも遅れを取ってしまうので、いかにその課題に向けて取り組んでいるかが鍵となります。

2点目の問題は次回に続きます。

ご訪問ありがとうございます。
応援のために１日１回クリックお願いします。
↓　↓　↓

人気ブログランキングへ

開発手法

開発はものによって、大規模になると何十人のメンバーが数ヶ月かけて行うものあり、ここ最近では開発の手法にも新しい動きが出ています。

開発に関しては、プロジェクトマネージメントで細かく管理する事によって、進捗や品質に大きな違いが出ます。

ところが、ここ最近では細かく管理しても思うようにいかないケースが出て来ています。

その背景感から話をすると、そもそもシステム開発をする際に、以前は多くのものが企業向けでした。

企業が人で行っていた処理をコンピューターに行わせる事によってコストを下げる目的と、マーケティングやマネージメントのためにデータを集計して経営戦略に使用する目的などで投資してシステム開発をしていました。

以前の暮らしを考えればわかりますが、ユーザーインターフェイスを日常の私生活で見かけるのはATMくらいでしたが、パーソナルコンピューターが発達しWindowsやインターネットブラウザが出来てから少しづつ増え始め、ADSLなどでインターネットを使用する機会が増えてから爆発的にユーザーインターフェイスを使用する回数が増えました。

では、企業向けと一般ユーザー向けシステム開発で何が違うのでしょうか。

企業向けのシステムでは、少々使い辛くても使い方を指導すれば使ってもらえるというものでしたが、一般ユーザー向けのものは使い辛いと全く使ってもらえないという特性があります。

また、使ってもらえないという事がビジネスの根幹となり、企業の成功と失敗がユーザーインターフェイスの作り方によって決まってしまう場合があります。

例で言うと、飛行機業界のLCCで先駆け的な存在であるエアアジアがそうです。

そもそもLCCとは出来るだけコストを抑えるために、人的リソースを極力削減するために予約はインターネットで行う手法を取っていました。

ところが、このエアアジアの予約サイトの使い勝手が悪かったり、割引セールをした際にユーザーが集まり過ぎるとサーバがダウンするなどシステムが不安定であったため、思ったように集客が出来ず搭乗率が上がらなくなり、一旦日本から撤退するという事態になりました。

それだけではなく、最近急成長マーケットのアプリでは、話題性もありますが操作性の素早さが売りですので、ユーザーインターフェイスやシステムの動作でダウンロード数やアクティブユーザー数に影響が出るためビジネスに直結します。

また、個人ユーザー向けのサイトが増えただけでなく、最近では技術発展が目覚しく、データベースの種類や新機能、新サービス、開発フレームワークなど、様々なところで新技術が取り入れられるという中で、競合対策も含めてそれらを取り込んだ形での開発という事を余儀なくされています。

そうした中では、前例がない事も開発では起きてしまい、想定外の事態のために要件や仕様変更を余儀なくされたり、その上デザイン変更という事も起きたりします。

そこで、システム開発の流れを概要からきっちり決めて、詳細に落とし込むというやり方を変えていかなければならない事態となってきました。

開発手法の具体的な変化については次回に続きます。

ご訪問ありがとうございます。
応援のために１日１回クリックお願いします。
↓　↓　↓

人気ブログランキングへ