こんにちは。小久保です。

突然ですが、皆さんは仕事をする上で電話とメールをどのように使い分けているでしょうか？　特に何も意識せずに使用している方も多いと思います。

しかし、しっかりと使い分けることは、有意義に仕事を行う上で意外と重要なポイントとなります。そこで、私なりの考えを今回は紹介します。

まずその前に、ライブドアはインターネット企業のほとんどがそうであるように、「圧倒的メール文化」であることを前置きしておきます。社内の連絡がほとんどメールベースで行われ、私も慣れるまで苦労した覚えがあります。ただ、メールを多用したディレクター業務に慣れてきても、やはり口頭で話すべき内容については使い分けが必要だと感じています。


【01】電話とメールのそれぞれの利点
ここで改めて、メールの利点と電話の利点を整理してみましょう。


【メールの利点】
・相手とのやりとりの記録が残る。（エビデンスとしての効力がある）
・ログが残るためやるべきことを忘れない。
・メーリングリストを利用することにより複数の関係者と情報共有が出来る。
・相手の仕事を中断することなく、用件を伝えられる。


【電話の利点】
・細かいニュアンスが伝わる。
・会話のキャッチボール（往復）がはやい。
・相手を逃がさない。（メールは読まれない恐れもある）

以上を踏まえると、電話の方が適しているケースというのは主に以下のようなものが挙げられます。

(1)急を要する確認のとき　→当たり前ですが、大切なことです。
(2)謝罪する場合の1次連絡　→まずは口頭で謝るべし。
(3)回答を催促するとき、確実に用件を伝えたいとき　→メールは読まれなかった時、意味がありません。
(4)ややこしい調整や交渉をするとき　→文章だけでは伝えられない説明が可能になります。

この中で(1)〜(3)は基本としてしっかり心がけておきたいポイントです。
(4)についてはもう少し詳しく説明します。


【02】ややこしい交渉にメールは向かない！
具体的なケースを例にお話します。例えば何かしらの契約条件の交渉を行っていたとします。先方から条件が出てきましたが、そのままの内容では承諾することはできません。そこで、以下のポイントにおいて交渉の余地があります。

・金額の交渉が可能か？
・契約期間の交渉が可能か？
・独占契約の条項を盛り込めるか？
・トライアル期間を設けることは可能か？

このように交渉すべき項目が多岐にわたる場合、メールで書こうとすると以下のようになります。

【メールの文例】
「契約期間を○年に延長することにより、金額を○万円にすることは可能でしょうか？　またその場合に、独占契約の条項を盛り込むことは可能でしょうか？　もし上記が難しい場合は一旦契約期間を○ヶ月にしていただき、その時点で再度契約条件を交渉するという対応は可能でしょうか？」

このように、相手にとって非常に回答しにくいメールになってしまいます。そして、おそらく先方からこのメールに対する回答をもらえたとしても1回読んだだけでは話がまとまらず、メールを何往復もすることになります。また、最悪の場合は着地点が決まらずに険悪な雰囲気になってしまうかもしれません。


【03】電話での交渉術 〜相手の真意を探れ！〜
一方、以下の例を電話で交渉する場合はどうでしょうか？　まずこの条件において、どれが先方にとって譲れない点なのかを探りながら、臨機応変に話を進めることができます。


【電話での会話例】
自分「あーもしもしー、例の契約の件なのですが、条件的にちょっと調整していただきたいのですが、御社としては金額面や期間的なところはどこがマストな条件でしょうかねぇ？」
先方「んー…。弊社としても契約期間を長めにしていただけるのであれば金額の調整は可能なんですが…」
自分「なるほどー。それでは○年契約で○円ってのはどうでしょうか？」
先方「えーと、さすがに○円まではちょっと厳しいですねぇ…。○円ならなんとかいけますが。」
自分「なるほど…。それでは○円で独占契約にしていただくってことは可能ですか？」
先方「いやいや、独占はさすがに厳しいですよ！」
自分「そうですか…。では、一旦契約期間を○ヶ月にして、トライアル期間として○円ではどうでしょうか？」
先方「その後の条件は○ヶ月後に再度調整するという感じですか？」
自分「そうですね。」
先方「分かりました。その内容で社内調整してみます。」
自分「よろしくお願いします。それでは今お話した内容を念のためメールでお送りいたしますのでご確認ください。」
先方「かしこまりました。よろしくお願いします。」

と、このようにスムーズに進行すれば、5分で終わります。このように相手とのやりとりを繰り返しながら交渉を行うような場合は、メールではなく口頭の方が圧倒的に早く解決することが多いです。仕事ができる人ほど「これは電話で伝えたほうがいいな」ということを感じとって、上手に使い分けているのではないでしょうか。

また、最後に確認のメールを送るとしておりますが、「証拠を残す・情報を共有する」ためにも、非常に大事なことです。口頭で決めたことは、後から「言った・言わない」の議論になりがちです。必ず最後に確認のメールをするといった癖をつけましょう。

【04】まとめ
今回の話をまとめると以下の2点になります。

・ややこしい交渉は電話で話しましょう
メールだけに頼りすぎると話がこじれる場合が多いです。さらに重要な場合は実際に会って話し合いをしましょう。

・口頭で決めたことは、後で必ず確認のメールを投げましょう
その際に電話での決定事項を関係者にも周知しておきましょう。


今回の例は社外交渉でしたが、社内でも同様にメールではなく口頭で伝えたほうがいいケースがあります。臨機応変に使い分けて、上手に立ち回れるようにしましょう！

このような基本的なスキルは、できる人は当たり前のように実行しているので、改めてそのすごさに気づかないものなんですよね。

ライブドアでは、むずかしい交渉もさらっとやってのけるような交渉上手なWEBディレクターを募集しております。

こんにちは。ライブドアでモバイルサイトを担当している伊藤です。モバイルの世界では、モバイル特有のサイト構築に関する技術や、PC のものをモバイルコンテンツ向けに作り直した技術が使われていて、ほとんどの仕様がPCと異なります。今回はその中のひとつである「Flash Lite」について書きます。

モバイル向けの「Flash」である「Flash Lite」は、ところどころで使われはじめているものの、本格的に使われるのはまだまだこれからというのが現状です。ただ、活気を帯びてきている技術の一つで、昨年末、新しいバージョンの「Flash Lite 3.0」が発表されたことは、今後モバイルサイトにおいて大きな意味を持ってくるでしょう。そこで、モバイルディレクターとして最低限、知っておきたいと思うことをまとめてみました。

【01】「Flash Lite」とは

「Flash Lite」はバージョン1.0からはじまり、1.1〜2.0〜(2.1)〜3.0とバージョンアップされており、最新版は2007年11月に発表された「Flash Lite 3.0」です。バージョンアップする度に、できることは増えてきていますが、PC版「Flash」に比べるとまだまだ厳しい制約があります。

※以下、「Flash Lite XXX が搭載されている端末」を「Flash Lite XXX端末」と呼びます。

【02】対応機種について

「Flash Lite」は携帯のキャリア・機種によってバージョンが異なるため、仕様決定には配慮が必要です。ディレクターとしては、どういう対応を取るのか悩むところで、

・3キャリア向けのサイト
・DoCoMo のみのサイト
・au のみのサイト

という分類や

・「Flash」がメインコンテンツのページ
・あくまでメインコンテンツは他にあって、「Flash」はサブコンテンツとして投入する

という分類によっても対応は異なりますが、基本的には下のどちらかの対応になるかと思います。

A:特定のバージョンのみに対応する
（他のバージョンの端末を非対応端末とする）

１）「Flash Lite 1.1」のみ対応

「Flash Lite 1.1」は現状では最も対応端末が多いので、「Flash Lite 1.1」で作ることが一般的です。User Agentで判定をかけて、非対応機種の場合(この場合Flash Lite 1.0端末)、非対応エラーページに遷移させます。

★対応端末：「Flash Lite 1.1、2.0、3.0」端末
★非対応端末：「Flash Lite 1.0」端末
※「Flash Lite」は、上位互換があるため、「Flash Lite 2.0」が搭載されていれば、1.1も1.0も動きます)

２）「Flash Lite 2.0」のみ対応

「Flash Lite 2.0」はDoCoMoで対応していないので、「Flash Lite 2.0」のみを対応とすることはほぼありません。

★対応端末：「Flash Lite 2.0、3.0」端末
★非対応端末：「Flash Lite 1.0、1.1」端末

３）「Flash Lite 3.0」のみ対応

現在はあまり使用されていませんが、「Flash Lite 3.0」の機能を活かしたコンテンツが出てくるとこのパターンが増加するでしょう。

★対応端末：「Flash Lite 3.0」端末
★非対応端末：「Flash Lite 1.0、1.1、2.0」端末

４）「Flash Lite 1.0」のみ対応

「Flash Lite 1.0」はDoCoMoの一部機種でしか使われていません。機能制限が多く、サイズ制限もほとんどの機種で20KBまでと厳しいため、使用されることはほとんどありません。

★対応端末：「Flash Lite 1.1、2.0、3.0」端末
★非対応端末：なし

B:「Flash Lite」各バージョン別に処理を分ける

「Flash Lite 2.0」端末なら2.0のバージョンを、「Flash Lite 1.1」端末なら…。という具合に各バージョンに最適化されたものをUser Agentで判定して機種ごとに振り分けて表示(ダウンロード)させる方法です。

「Flash Lite」はバージョンが異なれば、使える「ActionScriptのバージョン」も異なりますし、ほとんどの場合、サイズ容量もかなり違います。その、各バージョンごとにページを用意するのに等しい手間がかかるので、特別な事情がない限りはこの方法はとりません。ただ、3キャリア向けではなく、au 向けのみのサイトだと、「Flash Lite 2.0」と「Flash Lite 1.1」を作って、それぞれ振り分けるという方法は時々使用されます。

※最後に各キャリアの対応機種をまとめてみました(2008年1月15日現在)。



DoCoMo は基本的に FOMA 端末以上を想定し、505i、506i、900iシリーズのみ「Flash Lite 1.0」、その他は「Flash Lite 1.1」、905iシリーズだけが「Flash Lite 3.0」です。
※「Flash Lite 2.0」を飛ばして、いきなり3.0になっているところからもモバイルサービスの進化の速さを感じさせます。



au は基本的に WIN端末以上が対応で、比較的新しい端末が「Flash Lite 2.0」、それ以外は全て「Flash Lite 1.1」で「Flash Lite 1.0」はありません。



SoftBank も au と同様で新しい端末が「Flash Lite 2.0」、それより古いものが「Flash Lite 1.1」で「Flash Lite 1.0」はありません。


【03】「ActionScript」に関して

「Flash Lite」の各バージョンでできること≒「ActionScript」の各バージョンでできることです。ですから、「ActionScript」の各バージョンで何ができて何ができないのかを把握しておくと、

「カレンダーFlash 作ろうと思うんだけど、fscommand2( "GetDateDay" );で日付情報を取得し、変数に格納すればいいから、『Flash Lite1.1』以上なら出来そうだね」

というようなことがわかります。
ディレクターとしては実際に「Flash」を操作するわけではないにしろ、「ActionScript」を知っておくと企画設計がスムーズです。日付情報の取得・音量の取得・バイブレータの ON/OFF などができる fscommand2 などいくつか重要なものを押させておくだけで随分違うと思います。

基本的に「Flash Lite 1.0」、「Flash Lite 1.1」は「ActionScript 1」、「Flash Lite 2.0」、「Flash Lite 3.0」は「ActionScript 2」ですが、同じ「ActionScript 1」でも「Flash Lite 1.1」と1.0では使える「ActionScript」が異なったりするので注意が必要です。


【04】「Flash Lite」の利用のされ方

１）「Flashゲーム」、「Flash待ち受け」などコンテンツとしての利用

現状ではコンテンツとしての利用が半分以上を占めているのではないでしょうか。モバイルのゲームにおいて、「Flash Lite」は本当によく使われています。

２）UI での利用

アクロディアの VIVID UI、着せ替えツールなどで使われているような、携帯のUI(ユーザーインターフェース)での利用です。今後はこの利用が増えていくでしょう。

３）サイトトップページでの利用

各キャリアのトップページ・トップメニュー(iMenu、au oneなど)、一部のCP(コンテンツプロバイダー)が運営している公式サイトの TOP ページに見られる使われ方ですが、サイト TOP ページに「Flash Lite」を使っているパターンです。

単純に TOP ロゴをFlashロゴにしている例はいくつも見られますが、こういう形での利用はまだまだ少ないです。例として、「お笑いTV」というサイトの QR コードを載せておきます。

「お笑いTV」


＜メリット＞
・サイト全体に統一感が出て見栄えが良く、ユーザーが使いやすい。
・画像表示が早い。

サイト TOP で画像をいくつも置くと、画像の読み込みに時間がかかってしまいますが、「Flash」で表示させる場合は画像を一つ一つ読み込まなくていいので表示速度が早いというメリットがあります。

＜デメリット＞
・UID (固体識別情報)などのパラメータの引き継ぎなどができない。

各キャリアのトップページ・トップメニューではできていますし、システムで対応すれば不可能ではありませんが、基本的にはできないようです。

・手間がかかる。

HTML/XHTML で作る場合と比べると、更新する際など時間がかかり、確認に手間がかかることがあると思います。

・SEO (Search Engine Optimization) 的に不利。




【最後に】今後の「Flash Lite」はどうなるか

今後「Flash Lite」の使われ方において、ポイントとなるのは「Flash Lite 3.0」でできるようになった　Flvファイルの再生機能を活かした動画との組み合わせでしょう。「Flash Lite 3.0」搭載端末は DoCoMo の905iシリーズのみですが、au、SoftBank でも2008年春モデルから「Flash Lite 3.0」搭載端末が出てくるでしょうし、将来的には「Flash Lite 3.0」が主流になっていくと思います。

現在は、モバイルコンテンツの動画再生というと、「iモーション・着ムービーで、avi から QuickTime で 3gp とか 3p2 とか aac に書き出して…」という形ですが、画質が荒い上にサイズ制限がきついという難点、 PC での動画サイトのほとんどが Flvファイルで再生・保存されていることを考えると、今後はモバイルコンテンツでの動画再生＝Flvファイルで、という流れになっていくのではないでしょうか。


モバイルの世界はサイズの制限に苦しんだり、機種対応で悩んだり、の一方で、速いスピードでできることが増えていくやりがいのある世界です。ライブドアでも新しい技術を積極的に取り入れて、面白いサービスを生み出していきたいと思っています。

ライブドアでは、「今までの常識にとらわれず新しいことにどんどん挑戦していきたい！」という貪欲なディレクターを募集しています。


一部誤りがありましたので、本文中の表記、画像などを修正しております。

こんにちは。『livedoor Blog』担当の早岡です。

どのサービスにおいても開発・運用の「タスク優先順位」が存在します。サービスの規模が大きくなればなるほど、ディレクターはタスクの“交通整理”に頭を悩ますことになります。今回は『livedoor Blog』を開発・運用していくにあたって、私がどの様な形でタスク整理をしているかを書きたいと思います。

■プロジェクトの種類を分ける。

『livedoor Blog』のプロジェクトは大きく３つのタイプに分類されます。

(1) 収益重視のプロジェクト
　コンテンツ連動型広告や、他媒体とのタイアップなど「お金に直結するタスク」がここに含まれます。

(2) ユーザー満足度向上のためのプロジェクト
　「どういう機能を追加すればもっと便利になるか」「ユーザーの要望に応えるにはどうしたらよいか」といったタスクがここに含まれます。
　
　※現在は「fixdap」というBTS（Bug Tracking System）サービスを利用して、livedoor Blogへの要望・アイデア募集を行っております

(3)サービスを持続させるためのプロジェクト
　ここはサーバ関係など、主にインフラ面が該当します。5年、10年続くサービスを開発するためには常に考慮すべき部分です。

これら３つの大きな柱の下に、各種タスクがぶらさがっているわけですが、いかにバランスよく、かつ、適切なタイミングで遂行できるかは、ディレクターのさじ加減が重要になります。

(1)のような収益直結型タスクは、売上げが目に見えてわかるため、ついつい目先の利益を追い求めて、飛びついてしまいがちです。
しかし、「ただ、儲かればいいのか？」と言うと、そういうわけではありません。

すべてのサービスは、ユーザーあってのものですので、ユーザーが満足してくれるようなタスクを進行させていく必要があります。さらに、潤滑なサービスを維持するためには随時メンテナンスをする必要もあります。

そこで、「じゃあ、どれが一番優先すべき事項なの？」という疑問が当然生じてきます。

よくある失敗は、「ディレクターの中では何となくタスクの優先順位は決まっているのだけれども、それが開発・営業スタッフに伝わっていない」といった状況。明確な優先順位が決まらないから、タスクがどれも中途半端になる･･･といったこの悪循環を避けるためにも、各タスクの順位を整理する必要があります。


■タスクの種類を色分けでわかりやすく。

タスクの優先順位を付ける際、私は「視覚的に整理する」ことを心がけています。



この表では、
オレンジの部分が「ユーザー満足度向上のためのプロジェクト」
灰色の部分が「収益化のためのプロジェクト」
ピンクの部分が「サービスを持続させるためのプロジェクト」
と分類されています。
※未公開の情報も含まれているので、あえて見づらくしています。ご了承ください。

各プロジェクト内のタスク進行期間、状況などを簡単に書き込み、「いま何が動いているか」をわかりやすくすることによって、全体のリソース管理や次フェーズの予定が立てやすいようにしています。

ディレクターもプログラマーも、『livedoor Blog』以外のサービスを平行して担当しているため、ほかの担当者とリソース調整の話をする必要があるのですが、その際、詳細を説明しなくても「この時期が忙しいです」「このタスクを優先したい」と表を指し示せば話が早いです。

また、先ほど述べた「３つの柱」をバランスよく進められているか、ということも一目でわかりますので、特定の分野に開発がかたよるということもありません。

定例で行われるミーティングでは、この表を基に「じゃあ、次はこれをやりたいね！」という提案や、「この辺を頑張った方がいいんじゃないか」といった反省を含め進行します。
（細かいタスク毎の進行管理は社内BTSやメールなどで行っています）

■まとめ

『livedoor Blog』の開発には多くの人が関わっています。
それだけに全体のタスクがどうなっているか、目指している方向性にブレはないか、などをメンバー間で常に共有しておく必要があります。
もちろん、タスクの重要度は時と場合によって常に変化するものですし、突発的なタスク（障害対応など）が発生し、全体のスケジュールに影響を及ぼすこともあります。だからこそ、細かい文字の羅列したスケジュール表よりも、パッと見てわかる視覚的に整理された表が必要とされるのではないかと思っています。

サービスの開発・運用のスケジュールを決めるのはディレクターの仕事ですが、ディレクターの意見だけで決定するのではなく、開発スタッフの意見も大切になります。
特にプログラマーからは「このタスクとそのタスクは一緒に作業すると効率がよい」といった意見が出ることがあります。その為、ディレクターだけでスケジュールを考えるよりも、良い結果が生まれることが多いです。
求められるのは「全員がわかりやすいようにタスクを整理しておくこと」であり、それはディレクターとして重要な役割のひとつであると言えます。

タスクの整理方法には、様々な種類がありますが、もし「これは便利！」という方法があれば是非教えてください！

こんにちは、フレパ担当のandyです。
今回は、「livedoorのディレクターに聞いた！ 自分が勉強するために読んだ本・雑誌」をまとめてみました。
何から勉強すればいいのか分からない人は、まずとっかかりとして手に触れてみてはいかがでしょうか。


【WEBディレクション】
だから、Webディレクターはやめられない―できるWebディレクターの成功戦略

思わずうなづいてしまう体験談が満載です。初心に戻りたい時に読むと効果抜群。
できるウェブディレクターが日頃何を考えて生活しているのかが分かります。


Webディレクション教科書

ウェブサイトを作る上で基本的な事をまとめた入門書。
オススメ本の紹介など、まさに教科書。



プロジェクト始動からサイトの設計・構築まで Webディレクション標準ガイド

こちらも、教科書的内容。
1つのテーマに対していくつかの具体的な考え方、事例やサンプル書式を紹介してあり、『Webディレクション教科書』より実践向きの内容となっています。


【デザイン】
Webデザインユーザビリティ (ウェブクリエーターズバイブルシリーズ)

若干情報が古いが、ユーザビリティを考えるための入門書。
イラストが多くて分かりやすいです。


ディフェンシブ・ウェブデザインの技術―「うまくいかないとき」に備えたデザイン、「上手に」間違えるためのデザイン (Web designing books)

なじみ深いサイトの良い例、悪い例を取り上げています。
デザイナーの為のデザイン本というより、ディレクターがデザインを依頼する際に役立つ本です。


【文章】
記者ハンドブック -新聞用字用語集 第10版-

新聞用語の基本的なルールがまとめて収録されています。
「迷ったら、ひらがなで書け」など、意外と知らなかったコツも勉強になります。


【サーバ】
これならわかるサーバ 入門の入門



【モバイル】
モバゲータウンがすごい理由 ~オジサンにはわからない、ケータイ・コンテンツ成功の秘けつ~

PCサイトとケータイサイトの相違点など、人気サービス関係者のコメント付きで分かりやすく解説されています。


【雑誌】
MdN (エムディーエヌ) 2008年 01月号 [雑誌]


足りない知識はまず本を読むことで補完し、吸収している人がライブドアでは多く存在します。広く知識が求められるウェブディレクターですが、自分の弱点を見つけて少しずつ克服していきたいですね。
ライブドアでは「本読むどころか、本書きました」というディレクターを募集しています。

こんにちは、ディレクターBlog言いだしっぺの櫛井です。
最近は色々な方に「ディレクターBlog読んでますよ！」と言われるようになってきました。ありがたいことです。

2007年も残すところあと3日となりました。来年から新人社員として会社に入ったり、転職などで、環境が変わったりするという方も多いのではないでしょうか。
今回は、普段あまり“ノウハウ系”の記事を読まない友人たちに言われた「あの記事よかった！　参考になった！」というエントリをいくつかご紹介してみたいと思います。私が書いた記事が多く見えるのは気のせいです。

4つのステップで作る webサイト開発のスケジュール作成
「これはどんな職種でも使える！　ありがとう！」とよく言われました。
どういたしまして。

枯れた技術で社内を潤す　IRCを使おう！
IRCという存在を知らない人も結構いたようで、使い始めようと思ったり
「社内の導入手引きにリンク入れさせてもらったよー。」などと言われました。
ありがとうございます。

モバイルサイトのスピード構築術
「今までこういう形で仕様書を公開しているのを、見たことが無かったから参考になった！」とえらく褒めちぎられた覚えがあります。褒められると次回も頑張りますのでもっと応援すると良いと思います。

livedoor ウェブディレクターの“OJT”を考える
「livedoorの人がなんでタフなのかわかった気がするわ…。」と、良いのか悪いのかよくわからないコメントを沢山いただきました。

デジハリでは教えてくれない（かもしれない）、Webディレクターの基礎知識
「1つ1つ調べるのはメンドウだったから助かりました。」と言われました。
ちなみに、佐々木さんはイケメンですよ。

「エンジニアは魔法使い」という幻想
エンジニアをしている方からの反響がとても大きい記事でした。エンジニアとうまく付き合っていけるディレクターが増えるのは会社関係なく嬉しいです。

サーバの種類とDBサーバ超基礎入門
実は、自分がきちんと理解出来ていなかったところの確認のための資料だったんですが「資料がとにかくわかりやすい！」と評判でした。図解サイコー！


最近よく思うのは、「やっぱりBlogっていいなー。」ということです。私が数ヶ月前に書いたエントリを見つけて「これは参考になる！」と興奮しながら話しかけられたことは過去に何度もあります。
Blogの利点として

1）記事ごとにパーマリンクがあること
2）そのリンクに対して閲覧者が評価することが出来るサイトが色々あること
3）評価によって、公開日時に関わらず沢山の人の目にふれること

という流れがあるからでしょう。よくも悪くも「いつでも再注目される可能性を秘めている」という点もけっこう好きです。

「webディレクター」という職種以外にも沢山の方に読まれている当livedoorディレクターBlog。2008年も腐らない記事を目指して執筆者一同頑張りたいと思いますので宜しくお願いいたします。今年も1年お疲れさまでした。

こんにちは、livedoor のプロデュースグループでモバイル事業を担当している津元です。今回は非公式ケータイサイトの課金について書かさせていただきます。

その前に、公式サイトとは何かをご説明いたします。公式サイトとは、ケータイキャリアが公式に認めているサイトという意味を持ちます。以前の記事で、公式サイトに登録されるメリットを書きましたが、そのなかに「キャリアの情報料回収代行サービスを利用でき、容易に課金できる」というメリットがありました。

皆さんも使われたことがあると思いますが、4ケタのパスワードを入れるだけでコンテンツなどの購入ができ、支払いは毎月の携帯料金と一緒になります。これはケータイユーザーにとって他の決済手段（銀行振込、クレジットカード、電子マネー、コンビニ払い等）に比べると非常にハードルが低く、モバイルコンテンツ市場がここまで大きくなるうえでも重要な役割を果たしました。

一方、非公式サイトはどうなのかといいますと、公式サイトのような課金方法は利用できないため、さきほども述べた銀行振込やクレジットカード、電子マネーが主流です。ただ、105円や315円などの小額決済をするためだけに各種情報を入れるのは、余程バリューのあるコンテンツでないと厳しいですし、そもそも10代だとクレジットカード持ってないユーザがいたり、おしなべて課金しづらい状況があります。とはいえ、ECサイトでのショッピングとなると話は別ですが、これはまたいづれお話しましょう。

そんななか、ドコモの回収代行サービス『ケータイ払い』サービスが登場し、各社が続々と導入し始めているようです。このサービスはもともと『DoCommerce』という名称で試行していましたが、その後『ケータイ払い』に名称を変更し現在にいたっています。もともとの名前からもおわかりの通り、主に ECサイトでの利用を想定したものです。


＜『ケータイ払い』概要＞
・4ケタのiモードパスワードを入れるだけで利用可能（=公式サイトと一緒）
・携帯料金と一緒に請求（=公式サイトと一緒）
・上限額　10,000円/月
・従量課金（=ショット）の課金のみ
・料金延滞がない（iモード付加機能使用料などの支払いを直近2ヶ月連続で期限
内に支払っている）ユーザのみ利用可能
・債権は加盟店からドコモが買い取り（=公式サイトの回収代行よりは手数料高？）


公式サイトのものとはいくつか異なる部分もありますが、「4ケタのパスワードだけでコンテンツや商品を購入できる」といういちばんのメリットは同様です。ですが、ショットでの課金しかできないのがデメリットとしてあります。たとえば3か月や6か月コースなどパッケージで対応するしかない状況です。

この『ケータイ払い』ですが、ドコモは過去にそれほど積極的に展開していなかったのか、導入しているサイトは少なかったのですが、最近は積極的に働きかけているようで、それに伴い審査の方も柔軟になってきているようです。また、今までは ECサイトが多かったのですが、コンテンツやサービスの課金手段としても導入しているサイトもあり、それに伴い、にわかに注目され始めています。導入しているサイトですが、ECサイト以外で有名どころとしては以下のサイトがあります。

＜『ケータイ払い』導入サイト＞
・ケータイハンゲーム（ハンコイン購入）

・モバゲー（プレミアムアバター購入）

・モバオク（月額有料会員の決済）

・ニコ動、ヤプログ、アットゲームス、コルムオンライン、MOOCS Mobileなどなど


上記はほんの一部でして、パソコンで対応しているサイトも多く、そちらも含めるとかなりの数にはなります。売上へのインパクトでいうと、相対的には伸びた会社が多いと聞きます。

弊社は、『ケータイ livedoor』をはじめ非公式サイトを持っており、そのなかでは『livedoor ウォレット』という事前にクレジットカードや請求先情報などを登録しておけば基本的にはボタンひとつで購入できるサービスもあるのですが、ウォレットに対応しているサービスが少ないこともあり、あまり利用されていない現状があります。そこで、ユーザーからの要望もあり、現在『ケータイ払い』導入の準備を進めています。

今までは課金すること自体のハードルが高かったので、実現したくてもできない部分がありましたが、『ケータイ払い』を利用し、有料メニューを作ることで高機能化を図り、結果的にユーザーの皆さまが満足していただければと考えています。

なお、他キャリアはというと、au は『まとめてau支払い』、ソフトバンクは『S!まとめて支払い』と、同じようなサービスを展開しております。ただ、『まとめてau支払い』は審査があるのと同時に実装に工数がかかります。また、『S!まとめて支払い』は利用できるのが公式サイトのみで、そもそも最初から非公式サイトは NG といった感じで、3キャリアまとめて導入できないのが痛いところです。

今後はキャリア課金だけでなく、Edy、Suica など Felica を利用して、非公式サイトでもカンタンにシームレスで決済できる仕組みなどが出てくると良いのですが……。ちなみに、現在でも『Mobile Edy』というサービスありますが、メールを受信してからアプリ起動しなくてはならず、利用にワンクッションはさむ形になるのでシームレスに使えないです。

弊社では、このような現実的な課金の仕組みを使ってマネタイズしていくことも重視しております。弊社で持つ媒体と相性の良いコンテンツやサービスをお持ちの会社さまがいらっしゃれば、ぜひお声をいただければと思います。

こんにちは、『livedoor Blog』担当ディレクターの久野（くの）です。私は大学時代にプログラミングの勉強を少ししていたこともあり、現在も趣味でウェブ関連のプログラミングをやっています。仕事以外でプログラミングをすることを「ホリデープログラミング」と呼び、それをテーマにしたブログも多くあります。私の場合、ホリデープログラミングで作成したものを業務で活用することもあります。

いままでも『livedoor ディレクター Blog』で便利なツールを紹介してきました。しかし、適当なツールやウェブサービスが見つからないときや、自分用にカスタマイズしたいときに、ごく簡単なものですがプログラムを書いて自作しています。

ツールをプログラミングで自作するメリット

■プログラムについて勉強できる
どのようなウェブサービスでも、必ずその裏ではプログラムが動いています。実際にプログラムを書くのはプログラマーなどの開発者ですが、ウェブディレクターとして、どういうプログラムがどのように動作しているのかを把握しておくことは悪いことではありません。そういった知識は、デバッグ作業のときにも、エラーが出ている原因を突き止める助けになります。

ちなみにライブドアでは、ディレクターでもすべてのサービスのソースコードを読むことができます。プログラム言語は記述の仕方などが似通ったものが多いので、どれかひとつでも覚えておくと、違う言語のプログラムでも、どういった動きをするのかある程度わかると思います。

■融通・応用がきく
自分でプラグラムを書いているので、後から細かく修正したり、データ出力の方法を変更したりと、既存のツールではできなかかったことがいろいろと可能です。また、他に新しくツールを作ろうとしたときに、以前作ったもので共通化できる部分は活用し、プログラムの手間を省くこともできます。

プログラミングで参考にするサイト

参考書を読みながらプログラミングしていれば問題が発生することはありませんが、いざ自分で考えて作ろうとするとエラーが出て、意図した通りにプログラムが動かないということがあります。そんなときに利用できるサイトをご紹介します。

Google Code Search

公開されているソースコードから検索することができます。膨大な量のソースコードがインデックスされているので、同じような動作をさせるプログラムはたいてい見つかります。

codeなにがし

どのようにプログラムを書けばいいか質問すると、詳しい人が答えてくれるQ&Aサイトです。また、活用できそうなノウハウも多く投稿されています。

livedoor Blog

作ったものや作り途中のものでもブログ上で公開して、広く意見を求めてみるのもいいかもしれません。より効率的な方法やいいアイディアなどをコメントしてもらえることもあります。

プログラミングというと難しいイメージを持っている人もいるかもしれませんが、PHP や Ruby、Perl などの入門本を一冊買って、まずは始めてみてください。ライブドアでは、BASIC だってバリバリ書けるというディレクターも募集しています。