2012年6月アーカイブ

商用利用が無料のものがあるのに何で有償の、しかも数十万円もライセンス料をかかるものを利用するの?

誰が言ったとかいう話しではなくて。こういう風潮というか、考え方があって、それはそれで一見もっともなように思えるんですが、勉強会の告知を兼ねて少しばかり考えを書いておきます。

でも結論は先に。PowerCMSやりませんか? 構築のマーケットがありますが、スペシャリストが足りません。

まー、これ↓から3年経つんですが、この時導入数(ライセンス出荷ベース)150、現在500超えなので、この時に話した内容ですが、今も同じこと言ってるんだよなーってことで...

ウチの会社ではPowerCMSという商用のCMSパッケージを開発して提供しつつ、サイトへの組み込み(CMS構築)を受けています。PowerCMSは数十万円〜という価格帯なので(エンタープライズ向けCMS、という標題からすると、逆に安いほうに類別されるのですが)、単体のMovable Typeなんかと比較すると金額は張ります。でも、これをマスターするメリットがあります(と、僕は思っている)。

エンタープライズ向けCMSを選択するメリットとは?

指名での発注がある

「PowerCMSでお願いします」ってケースがあります。少なからず。
自分たちが提案主体で、クライアントからのCMSの指定がない場合、確かにツールは何でもいいよね、って考え方もありです。ユーザーやでき上がったサイトにはCMSなんて関係ないよね、という考え方です。この場合、自分たちの利益を最大化するためにできるだけ原価が低いもの、無償のものをベースにできると嬉しい筈です。でも、エンタープライズ向けCMSの場合は、その機能や導入実績、サポートなどの面から、指名での発注があるのです。

専任サポートによる対応 / パートナーとのエコシステム

CSS Niteの国産CMS特集の際に「ウチは、サポート」と言ったと思いますが、あの頃以上にここには力を入れていて、今はサポート専任スタッフを置いています。そして、パートナー制度。これも有償登録制です。有償故にこれもサポートチームが全力でケアするようにしています。ただ、このパートナーについては単に当社がケアするにとどまらず、クライアントから依頼があった時に弊社から仕事の紹介とか、あるいはパッケージとしてPowerCMSの採用を決めた後に「さて、どこに頼もうか」となるわけです。冒頭の「指名での発注がある」と同様、PowerCMSのスペシャリストはそこで仕事が生まれます。実際のところ、複数構築経験のあるSOHOパートナーさんなんかは複数の案件の依頼が集中しているようなところもあります。

案件価格帯を変える / 受注のルート(市場)を変える

サイト構築、CMS構築って数万円〜数十万円の仕事から、数百万、数千万の仕事まで本当にマチマチですが、PowerCMSは数十万のパッケージですから、数万円〜数十万円の案件で採用されることはまずありません。と、いうことは数万円〜数十万円の価格帯で勝負している人は、もうひとつ上のボリュームの案件中心にできるわけです。有償ライセンス前提でのサイト構築ですから、「必要なものにコストをかける」意識はあるお客さまということも言えます。そこで仕事ができるようになる可能性があります。

また、PowerCMSもCMS選定で競合する時もあって、WordPressとかも競合で出てくるんですが、この規模になると、もう数十万のライセンス費なんて誤差の範囲です。商用、サポート有り、長くサポートできることが前提でビジネスしていますから(PowerCMSでは4年半前のバージョン1.xについてもまだサポート続けています)、そういった面の安心感もあると思います。

敢えて"そっち"で勝負してみる

上記の章と被りますが、別にPowerCMSでなくてもいいんですが、例えばN○○ENとかT○○mS○○eとかHea○○Co○○とか、そっちの構築が得意なフリーランスの人とかってあんまり聞かないんですが、そこアピールすれば違う市場の仕事をとりにいけるってことですよね。そこに好き嫌いはあると思うんですけども。それでも、どうしてもデフレスパイラルに陥ってしまってどんどん制作単価が下がって行ってない? って感じている人にとってはそこへ参入することを検討する余地はあるんじゃないかと思うわけです。

ということで、再度告知です。CMS構築、Movable Type経験あり、これから新たな領域にチャレンジしたいと思っている方は是非!!

何ごとも100%はコスト高、トラブルのもと。70%のコストで80%の約束をして90%のサービスを提供するほうが、100%の約束して苦労したりトラブるより、結果として互いがハッピーになることが多い。不思議とそっちの方が利益があがるんだなこれが。

Web2.0の時(いつだよw)に、βでも良いからリリースして改良していくみたいな手法が取り上げられたけども、例えば受託開発案件なんかでβ納品なんかしたら問題ですよね。それでも80%をゴールに設定するような考え方も役に立つというか、使えるんじゃないかと最近思うんですよ。

CMSなんかのWebシステム構築の場合、顧客の要件を100%満たすことを前提に設計を行った場合、たいてい100%を実現するために壁になる部分、つまり、実現が困難な10%とか20%の部分が(大抵=経験からね)出てきます。この10〜20%が実はやっかいで、要件(ボリューム)としては10〜20%だけど実現の敷居は高く工数も高い、つまりこの部分(実現のネックになりそうな10〜20%部分)を削るとコストはそれ以上に下がります。そしてトラブルの発生率も大きく下がります。

もちろん不完全なものを納品するわけにはいかないので、プロジェクトの設計や契約の際に、この部分を削ってスタートさせたらいいんじゃないの? ってことです。

ただでさえ仕様変更や要求の追加って日常茶飯事のように出てくるわけですから、そういう提案をすることも、アリだと思うんです。例えばパッケージ製品の標準機能で8割要件を満たせる場合、残りの20%のカスタマイズを仕様から一旦外してしまって比較的容易に実装可能な8割をゴールとする。トラブル発生や実現難易度の点から、8割の機能でも見積りはもっと下がるでしょう。

500万円の仕事だとして、20%以上、というと100万円以上売上げが減るわけで、こういった場合、多くの会社では100%、500万円で受注しようとするんじゃないかと思うんですが(そもそも顧客が望んでいることなんだから、それに極力応えようとする姿勢はある意味まっとう)、誰もトラブルを望んじゃいないし、デスマが好きな人なんていないですよね。

佐渡先生wも「百里の道を行くときは、九十九里をもって半ばとせよ」と言っていますが、受託開発なんかで最後の1割、納期前に最後まで残っているバグ潰しとかってたいがい無理をした部分、無理な実装、強引なカスタマイズとかってケースが多い。

ということで、冒頭のツイートのような考え方になるんですね。要件を80%に絞り、ネックになりそうな20%を思い切って削る、そして30%の予算を浮かす。この30%を以降の改善に回して行けばいいのです。その頃はやりたいことが変わっているかもしれないし、軌道修正の予知を残すといった観点からもこれは効果がある筈です。あるいはゆとりができた分10%の性能/信頼性向上をめざすこともできる。結果として満足度が高まるってこともあるはずです。

ザッカーバーグの Done is better than perfect

ハッカーはすぐに全てを良くしようとするよりはむしろ素早くリリースしたり、より小さな反復から学ぶことによって長期的に最高のサービスを作ろうとします。このことをサポートするために、我々は与えられた時間で何千というバージョンのFacebookを試すことのできる構造を作り出しました。我々は社内の壁に「完璧を目指すよりまず終わらせろ - Done is better than perfect -」と書いて仕事に取り組んでいます。

まず終わらせること。サクッとやっちゃえ! みたいなことですよね。受託でなくてサービスだからできる考え方だとも言えますが、受託の場合でもそもそも80%の仕様で契約して、そこをサクッとやっちゃいましょうよ、ということです。

ちなみに、この考え方はケースバイケースではありますが、他の考え方にも応用できると思います。

  • 1日の仕事を100%目一杯でなく、80%程度に調整しておく。阻害要因となる部分について、そもそも断ったり役割分担するなどしてその日のタスクから外してしまう。
  • 余裕を持った20%を品質や機能、信頼性向上のために充てる。もしくは不意のトラブルや仕事のバッファとしておく。

とかね。でも、一番難しいのは「捨てる」「断る」ってことなんですがね。少し勇気を持とうってこと。その方が結果的にハッピーになれることも多いんだよ。

少し前になりますが、河野 武さんのセミナーに行ってきました。大阪ではなかなかないよ、ってのと(後の懇親会で伺いましたが最近京都に越してこられたとのこと)、Facebookで色んな方が勧められていたのがきっかけです。ちなみに河野さんは2005年から2007年までシックス・アパート株式会社のマーケティング担当執行役員をされています。2007年って実は僕の会社がMovable Typeの拡張CMSソリューションPowerCMSをリリースした年で、それからシックス・アパートさんとはセミナー何かでご一緒させていただくことが増えたのですが、ちょうどそのタイミングで退職されていて、入れ替わりで実はお会いするのははじめてだったりするのでした。

当日は講演を聞きながら「#oreore_hashtag」(オレオレハッシュタグ!w)をつけてTweetしてました。リンクはこちら。また、スライドについては河野さんのサイトでシェアされています。

「最高」か「最安」か「最愛」か

「最高」か「最安」か「最愛」かという話しはとても明快でわかりやすくて、「最高(Appleストア)」「最安(ヤマダ電機)」に勝つことはできる? という問い(できないよね、っていう誘導尋問的w)に対して「最愛」しか生き残れないよね、という話しをされました(最愛の例としてはジャパネットたかた を出されていました。河野さん的にはジャパネットたかたについてはリサーチ中と話しておられましたが)。

「最愛」というコンセプトには共感できるしその通りだとは思います。ただし第二部のアクティブサポートの話しからもわかるように、モノを売る企業、メーカー、大企業に対して、例えばアルファサードのような中小企業、且つ、労働集約的な受託業務部門(いわゆる人が提供するサービス)が相応の業務比率を占める企業では、必ずしも最高、最安を目指すことをあきらめる必要もないな、という感想を持ったことも事実。

どういうことかと言えば、我々のような業務では、実は常に最高、最安というポジションによって選ばれている面があるからです。

CMSで最高

という単純比較ではなく、

CMS × エンタープライズ系の機能 × 静的パブリッシュ可能 × 国産 × 有償サポート有、の中で「最高(最安)」

他にも「関西にサポート拠点のある」とか、様々な条件の掛け合わせて最高や最安は決まります。例えば「6月〜8月にカスタマイズの人的リソースを確保できる」みたいな、製品には直接関係のない条件を掛け合わせた中での最高もしくは最安。

ソーシャルメディア全盛の時代、これからは「最愛」だよね、と単純な頭で考えるのではなく、当然ですが、我々がどこで戦いどこで選ばれているのかをちゃんと定義できてなければアクティブサポートにしてもどう取り組むかの方向性が決められない。そういうことをちゃんとあわせて考える必要があるんだろうな、と思った次第。

大切なのはバランス。取り組むべきはサポートデスクか営業か、はたまた...

ツイートにも書きましたが「お客さんは友だちじゃない(距離感重要)」という言葉は非常によくわかる。空気感がわからないとすぐに炎上したりするのがTwitterなんかのソーシャルメディアだし。僕は炎上経験者wなのでそのへんのバランスは何となくわかるつもりですが、ソーシャル慣れしていない担当者(しかも企業アカウントでの発言は個人のそれとも違うわけですし)には難しいところもあって、そのあたりを何とかするのが河野さんなんかのお仕事なのでしょう。

講演の中で「営業がアクティブサポートすると行き過ぎる」「サポートデスクがアクティブサポートすると引き過ぎる」みたいな話しがあって、これも僕は実感としてよく分かる。ウチの場合、製品導入前の問い合わせのやりとりなんかで、技術的な内容をサポートに引き継ぐことが良くあるんですが、どうしてもサポート担当としてはリスク考えてしまって(導入決まってもトラブルや問い合わせ殺到したら自分がしんどい思いをする、但しそれだけだと売れない)、逆に売らんかなの営業が対応すると「大丈夫です! 買ってください」的な方向に行く。僕は、アクティブサポートを担当する人の立ち位置としては「広報」なんかどうだろうと思いました。営業でもなく、サポートでもなく。行き過ぎてもいけなくて、引きすぎてもいけない。そのあたりのバランスをとれるポジションの人が担当するのがいいのかな、と。

以下の事例なんかでも、営業やサポートデスクっていうより広報やマーケティング的な色合い強そうだし(必ずしもアクティブサポートの事例というわけではないですが)。

ソーシャルメディア活用の効果測定(KPI)

一般的にKPIの設定が悩ましいソーシャルメディア施策ですが、ローソンは明確でした。

  1. ローソントップページへ流入数
    ソーシャルメディアから自社サイトへの流入数
  2. ローソン公式アカウントからのリーチ数(現在81万人)
    ソーシャルメディアのリーチ数(100万人が目標とのこと)
  3. CRM Consumer Generated Merchandising
    ソーシャルメディアにあるお客様の言葉を収集・分析し、商品開発、商品改変に活用する
  4. 来店数、購買数
    クーポン系施策では、クーポン活用時の併売率を見る

零細・中小企業のアクティブサポートは社長自らが行うべき

これは僕の持論です。やっぱり責任をとれる立場の人でないと思い切って行動できないし、企業レベルから考えても専任を置くのは難しい。兼任、+の業務ではなかなかうまくいかんのじゃないかと思う。アクティブサポートはそれなりに負担がかかる(物理的にも精神的にも)。そもそも、会社の風評や製品へのネガティブな印象なんかを一番気にしているのは誰か? 社長だしね。それに、効果が実感できれば継続すればいいし、できなければやめればいい。

オープンな場で解決できるものはオープンな場で解決した方がいい

例えば、下記のような発言があった時、このまま例えば「何でこれができないんだろう...」的な方向に行くのはやっぱり嫌なので、本来はサポートの方へ投げて欲しいな、と心情的には思うわけです。ちゃんと有償製品で専任のサポートを置いているので。

Twitterの発言:PowerCMS3のメニューに「ブログ記事→グループの管理」と「グループ→ブログ記事/ページ」の両方があって、中身が違う件。マニュアルによると、後者は過去バージョンとの互換性のための機能らしいのですが......ものすごく紛らわしいのでメニューから消したいです......。

でも、サポートに投げてください(要は、問いあわせフォームやメール等、クローズな方で解決したいです)、ではなく、オープンな場でちゃんとケアできて課題が解決したら、そのやりとりは不特定多数の人の目に触れることになります。同じ解決できるのであれば、オープンな場で解決すべきだと思います。

Twitterでの返信:mt-config.cgi に HideMenus objectgroup:entrypagegroup などと書くと(複数消す場合はカンマ区切りで)特定のメニューを非表示にするプラグイン書きました。 :さらにその返信:@junnama なんという対応......! ありがとうございます。

セミナーの感想、というより自分の雑感みたいになってしまいましたが。ま、いっか。

Facebook

Twitter

このアーカイブについて

このページには、2012年6月に書かれたブログ記事が新しい順に公開されています。

前のアーカイブは2012年5月です。

次のアーカイブは2012年7月です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

Powered by Movable Type 6.2.6