2009年6月17日水曜日

[37signals] 注意書き:目的を明確に

(原文: Reminder: Know what you're measuring)

昨日Davidと私は、カスタマーサポート/カスタマーサービスの状況について把握する為に Sarah と Michael をまじえて、ちょっとした打ち合わせを行った。最近我々はカスタマーサポート/カスタマーサービスを Gmail から HelpSpot へと移行したのだが、この変化がどう思われているか興味があったのだ。つまり、ワークフローはどうか?学ぶべき事はあったか?といったことだ。

なぜ移行したのか?

HelpSpot へ移行した理由のひとつは、要望及び問題点が最も多かったジョブトラッキング(訳注: 進捗管理表のようなもの)について改善するため、というものだった。カスタマーサポート担当者から「みんなにとって、今週ぶんの進捗ファイルをアップロードするというのはしんどいことなんです」という発言が出る事があるかもしれないが、この「みんな」というのがくせ者だ。2人なのか? 10人なのか? 何ダースもの人なのか? アプリケーションに変更を加えればサポート需要や顧客の苛立ちを減らせるのか? Gmail ではこういった点についての詳細は把握出来ないが HelpSpot なら可能なので我々は移行したのだ。

知ると学ぶは別物

昨日の打ち合わせでわかったのは、我々は詳細について漏れなくトラッキング(訳注: ここでは、顧客アクションの詳細に関する動向調査と言った意味)する事が出来るようになったが、そこから何も学んでいないということだった。何故こんな事に? 我々はトラッキングの為のトラッキングをしていたにすぎず、何かを学び取る為にトラッキングをしていたわけではなかったからだ。実際のところ、なぜトラッキングをするのかを把握しないまま作業を続けていた。なぜこんなことになったかというと、えーとだな、惰性というものは強い影響力を持つからなんだ。今回の件は、真に必要なことがあるにも関わらずそれを放ったらかして組織運営を進めてしまうことがあるのだという事を目の当たりにしてくれたので、良い勉強になった。

我々の行ったカテゴリとタグの拡張およびカスタムフィールドとプルダウンメニューの導入は我々に多くのレポート然とした情報をもたらしてくれたが、真に役に立つ情報をもたらしてはくれなかった。洞察無き情報はゴミだ。我々が手に入れたのがそれだ。山ほどの。

シンプル性へと立ち返る

といった経緯があって、我々は全てを御破算にすることにした。舳先をシンプル性に向けよう。企業として我々が犯した全ての過ちは、あまりにも多くの事をやってのけようとした点にあるわけで、われわれの力不足が原因というわけじゃない。というわけで今回の教訓を、どうやってサポートリクエストのトラッキングを行うか、という問題に当てはめてみよう。

真に意義があるのは何か?

リクエストの全てについてきちんと分類するのではなく、ごく大雑把に分類するようにしてみる。そのため「マイルストーン>編集>他のプロジェクトにマイルストーンを移動するには?」といった複数階層を持ったカテゴリ全てについてではなく、このカテゴリ階層でいうところの「他のプロジェクトにマイルストーンを移動するには?」カテゴリについてのみトラッキングするようにした。「マイルストーン」「編集」カテゴリでトラッキングする意味なんて無いからだ。階層構造や UI 構成に関する拡張なんて必要なかったのだ。トラッキングする意義があるのは「質問/問題点の報告」という肝心要のところだけだったのだ。

基本戦略は「質問/問題点の報告」が生じた際には「質問/問題点の報告」の内容を言い換える形で新規の長いタグを生成するというものだ。そしてタグと大体同じ内容の「質問/問題点の報告」が他に生じた場合はそのタグでまとまることになる。こうすることでカウントをまとめるとともに「パスワード変更はどうやればいいの?」「プロジェクト間で情報を移動するには?」といった質問をする人が何人いるのかを根本的に把握する事が出来る。

やろうと思えば、今週良く出た質問トップ10といったシンプルなレポートを我々に提出させることも可能だ。同様に、先週のトップ10は? 何かパターンがある? 増えたのは? 減ったのは? というのもありだ。これによって、では我々はどんな手をうつべきか?という行動基準が得られるようになった。前はどうだったかというと「マイルストーン」タグで60個の質問が出ているといった数字は把握出来たものの、我々がその数字を元にどういった行動を起こすべきかという判断には役立たなかった。だが今や「いっぺんに10個以上のマイルストーンを追加するには?」という質問が23個、「プロジェクト間でマイルストーンを移動出来る?」という質問が21個、「マイルストーンに時刻設定出来る?」という質問が16個といった状況が把握出来るようになった。これでようやく顧客の声から何かを学べるようになったのだ。

自明は不明

自明だと思われる事も再検証すべし。我々もスタート時点からそうすべきだったが、他の多くの物事と同様、この再検証作業はほったらかしにされてしまった。今回の新しいツールはあらゆる種類のジョブトラッキング用オプションを備えていた。カテゴリ・タグ・カスタムフィールド・検索・等々。我々はこの新しいツールに夢中になってしまい、結果、熱心に作業する事と優先して作業するべき事を混同してしまった。作業に忙殺されるだけで、何ひとつ学び取っていなかった。

ということで注意書き:目的を明確にせよ。データの為のデータは知的訓練という点においては楽しいものたりえるが、それが実用性のあるものになるのは諸君の吟味を経たあとなのだ。


訳者コメント:
Know what you're measuring. は逐語的には「何を測定しているかを知れ」なのですが、ぴんと来ないので「目的を明確に」と意訳しました。

2009年6月13日土曜日

[37signals] まず計画を立てなきゃというのは間違った考え方だ

(原文: The planning fallacy)

デンバー国際空港やボストンの The Big Dig(訳注: 高速道路網を地下トンネルに置き換える都市再構築プロジェクト)といったプロジェクトが何年も遅滞したり数十億ドルの予算にふくれあがるのを見るにつけ、これだからお役所的なやり方は無駄が多いし時間もかかりすぎるんだ、と我々は批判する。だが、プロジェクトを台無しにするような計画立案を行うのは巨大組織や国家機関に限らない。誰もがその愚を犯す。これが "plannning fallacy" というものだ(訳注: まず計画ありきといった感じの誤った認識のこと)。我々は、物事について計画を立てることが可能だと思い込んでいるが、実は計画を立てるなんて不可能なのだ。

調査によると、人に「それは現実を見据えた上でのシナリオか、それとも希望的観測に基づいたトントン拍子で進むシナリオか?」と問うのは無意味だということが明らかになっている。どっちみち出てくるのはトントン拍子に進む方のシナリオだけだからだ。これは案件の大小を問わず成り立つ。

我々はなかなか現実的になれない。計画通りに物事が進むと思い込んでしまうのだ。予期せぬ病気・ハードディスクのクラッシュ・マーフィーの法則的諸々を計算に入れて考えるなんてことは絶対にしない。

もし諸君が大げさな事前計画というものに全幅の信頼を置いているのであれば、これはすなわち諸君が諸君自身を偽っているという事に他ならない。まぁ「自由になれる」という良い側面もあるけどね(訳注: 計画という絵空事によって、現実を直視するという苦役から解放されるという皮肉か)。ものごとの進捗を遅らせ君が現実的になることを妨げるこのやっかいな計画作業というものは大概、時間の無駄だ。だからそんな作業は飛ばしてしまえ。もし諸君が本当にプロジェクト遂行に要する時間と開発資源を見積もりたいのであれば、まずは手を付けてみる事だ。


訳者コメント:
37signalsの記事を読む場合に限らないのだが、ものごとには必ずdarksideとlightsideがあるということはしっかり認識しておく必要がある。

この記事は一見、計画というものを全否定しているように思われるかもしれないが、そうではない。世間一般が計画というもののlightsideしか見ていないことに関し、きちんとdarksideを、すなわち計画というものが現実逃避の道具になってしまったり、プロジェクトの足枷にしかなっていなかったり、計画と遂行が本末転倒しているといった例を紹介しているだけの事だ。

また、lightsideとdarksideが不可分であるという事も認識しておく必要がある。メリットだけ得てリスクは切るなんていう御都合主義などありえない。

2009年6月10日水曜日

[メモ] IEは原則としてサポート外とする

マスというか「烏合の衆」を相手にしていられるほどヒマじゃないんでね。

サポート比重としては
Firefox > Safari > Chrome > Opera
でいく予定。

2009年6月5日金曜日

[メモ] 案の定

[CNET Japan] 絵文字が開いてしまった「パンドラの箱」第4回--絵文字が引き起こしたUnicode-MLの“祭り”

このエントリに記されている状況を見て「これだから西洋中心主義は!」などと的外れな主張をする似非愛国者が出現するんでしょうな。それ以前の問題でしょw

本件に関しては
[一言居士] やめとけ。諸君のやろうとしているのは漢字の再発明だ。
に書いた通り。ちなみにヘタレな私にしては珍しく、このエントリではトラバを付けたのですが、すぐに外されました。あれですか、不都合な真実ってやつですかw

絵文字そのものの是非に関する議論も無しに「まず標準化ありき。リーダーシップさえ手にすりゃ、あとはこっちのもんだぜw」で突っ走ったGoogle(というかもしかしてGoogle Japan?)の迎えるクライマックスや如何? というわけで次回に期待大であります。

2009年6月3日水曜日

[メモ] Project Natal

Xbox.com | Project Natal:

なるほど。Xboxがエロゲに手を出している理由は、こんな先行開発があったからなのか。Natalを差別化要素としてエロゲプラットフォームを制覇するという目論見に違いない。

該分野においてはビジュアル表現だけでなく入力デバイスの変革が重要である事をいち早く認識したMicrosoftは、リアルタイムモーションキャプチャーによりまさにnatalな状態でのプレイを可能にする。

コントローラ等の夾雑物を介する事のないエロゲプレイを実現することで対象との一体感を劇的に高めることが可能である、というMicrosoftの先見の明には感服するほか無い。

なお、モーションキャプチャについては特に腰部分について精度が求められると予想されるが、サッカーのPKを再現している部分を見る限り、問題はなさそうである。

天下のMicrosoftのことだ、Natalの適用はゲームに留まらず、現在のコンピューティングにおいてないがしろにされがちな「身体性」の復権を視野に入れ、あらゆるプラットフォームにおいて推進される事であろう。


って、厨房じゃないんだからさ、いいオッサンがこんな妄想垂れ流してどうすんだよw

で、真面目な話、期待しております。

私自身は「ゲームとは目を開けたまま見る夢」という理想形がありますので、身体を動かすなどもってのほかなのですが、Natalの根本にある「人間に備わったファンクションそのものをI/Oデバイスとする」というコンセプトは、神経接続を始めとする未来のコンピューティングにおけるキーパーツへとつながる可能性を多く含んでいます。Windows 7 なんてどうでもいいから、こっちを進めてくださいよ。Bingも発表時点で「波」に押し流されちゃいましたしw

それにしてもMSって、こういった反主流的(というか社内outsider的)取り組みしか見るべきものがなくなっちゃいましたね。

でも、それって実はいいことなんすよ。我々にとってもMSにとっても。

[Geek And Poke] 麦茶噴いたw

[Geek And Poke] Parenting In Post-2.0

2009年6月2日火曜日

[メモ] クロサカタツヤ氏のエントリにニヤリ

[CNET Japan] twitterヒッチハイクガイド

内容もさることながら、最後の部分に思わずニヤリ。これってどうみてもこれへの当て付けだね。自分の思い通りにならないと言って駄々をこねているだけの御仁にとって、このクロサカタツヤ氏のエントリは良い刺激剤となること請合。

それはそうと、なんで銀河ヒッチハイクガイドなんだろ? これがCNET Japanでは42番目のエントリになるからかな、と思って数えてみたがそうではないようだ。

「毎日ピリピリしている」自分と「ぽかんと口を開けて突っ立ったまま、事態が無事に自分の上を通り過ぎていくのを待っている」アーサー・デントを対比しているのかなあ、とか、ダグラス・アダムスの命日は5月11日だったなあ、でもその日の近辺には別エントリが既にあるしなあ、とか考えてはみたんだが、結局のところ謎である。