ゴールデンカムイに学ぶドメイン知識
結論
ドメイン知識は猟師が持つべき獲物や山の知識。老練な猟師は知識を多く持つ。
山は侮ると簡単に人が死ぬ。知識がないと簡単に死ぬが、あれば死にづらくなる。
獲物に対する敬意と知識を持て。
ゴールデンカムイis何
主人公杉元が冬の北海道で動物と戯れながら金塊を探す漫画。当然金塊狙いの敵もいる。
とりとめのない前振り
ドメイン知識が必要な理由のメタファをよく考える。
昔は地図や路線図だと思っていた。
スマホや検索禁止縛りで目的地に行くなら、事前情報なしと、地図があるのでは全然違うでしょう？って。
ただこの説明はよくない。
状況は流動的だし、常に全てを知ることはできないからだ。
地図は比較的静的で全ての情報が網羅的に載っている。
完全じゃない、動的だから、知る必要がない、ではない。
だからこそ知る必要があるし、知らないと「３年かけたプロジェクトがなんの成果も得られず撤退」みたいな無残な状況になる
このメタファを考えついた。
ドメイン知識は山の知識
ゴールデンカムイって漫画があって、山の中で金塊探しながら野生の動物と戯れる漫画なんだけど、この漫画とにかく人が死ぬ。
それも人間同士じゃなくて動物によってが半分くらい。
知識がないと死ぬ
動物に関する死因としては
「熊の巣穴に気づかず手を出して死亡」
「熊の頭を銃で撃つも分厚い頭蓋骨で全く効かず反撃されて死亡。熟練した猟師は絶対に熊の頭は撃たない。効かないから。」
という知識の不足に由来するものが多い。
知識があるからこそ断片的な事象から事実を割り出せる
足跡を追った猟師が途中で足跡が雪原の真ん中で途切れていることに気づく。これは戻り足と言って自分の足跡を踏みながら一旦戻り、途中で笹薮の中に飛び込むことで成り立つ。
相手を撒くためだったり、相手を後ろから襲うために用いる。
道を歩いていて、ある場所で不自然に障害物で通行可能な場所が狭められていたらそれは罠だ。
狐やウサギを取るためのトリカブト毒矢が仕掛けられているから通ってはならない。
知識があればより多くの情報がわかる
熊が入れるくらいの大きな巣穴があって中に冬ごもり中の熊がいるかいないかは巣穴の入り口に近づけばわかる。
冬眠中ならうるさくしなければおきない。
入り口が生臭かったりつららがあれば、なかに熊がいる。
知識があれば危険を避けられる
ヒグマは巣穴に飛び込んだものを襲うことはない。
作中でそれで危機を逃れたケースがある。
現実での応用
なにかの断片的な事象を見かけたときにドメイン知識があれば仮説が立てられる
一例：特定の指標が低下している。なぜか。
仮説：ユーザーのあるセグメントが他サービスに流出した。ユーザービリティの相対的劣化のため。
重要なのはドメイン知識があれば断片的な情報からより多くの情報を得て、事態を推測できる、って話
なんかまとまらないけどこんな感じで考えている。
セグメント毎の行動パターンの違い
前回のリリースレビューを行ってわかったんだけど、セグメント毎にマインドや期待、行動が異なるというのは分かっていた。
今回の結果を見て、さらにユーザーのセグメント毎に、プロダクトに求める親切さは異なると思った。
換言するなら、親切さを変えれば訴求セグメントを広げられるからユーザーのボリューム拡大に寄与した。
イノベーター理論でわけて例えるなら
イノベーターはどこからかαのブログ記事や小さいリリース告知を見て向こうから寄ってくる。説明書がなくても買う
アーリーアダプターはイノベーターのブログやメジャーなサイトのリリース告知を見て寄ってくる。英語の説明書があれば買う。分からなければググる。
アーリーマジョリティは日本語の説明書がないと買わない。主要な販売チャンネルで売りだすようになると彼らにも届くようになる。
レイトマジョリティは１ヶ月間の返金保証サービスをつけないと買わない。広告が自分の目に入るようになってようやく買う感じ。
ラガードは知らん。狙ったことがない。理由をつけて買うのを渋り、最後の最後に買うんじゃない？
ユーザビリティエンジニアリング(ユーザエクスペリエンスのための調査、設計、評価手法)
Amazon.co.jp： ユーザビリティエンジニアリング(第2版)―ユーザエクスペリエンスのための調査、設計、評価手法―: 樽本 徹也: 本
という本を読んだので読書感想文。
ユーザーの期待に関して書いている。
リーンの「ユーザーの期待を理解している人が実装するべき」の概念に合致しているので読んだ。
ユーザビリティ？スタバでしょ？という話ではないので是非読んでほしい。
大事なこと
だいたいこれだけでいい。
ユーザービリティは
誤： 使いやすさ。あればいいけどなくてもいいもの。
正： 効率。ユーザーの投入コストに対するリターンの効率。
ユーザーのリターンとして期待されるものを正確に把握しないといけない。
スタバはユーザーの期待を「オサレな雰囲気と優雅なコーヒータイム」と理解し、それを得られる空間を実装した。
「スタバでドヤリングしオサレな自分に酔う」というけど、そもそもユーザーが求めているのは「ドヤリングできるオサレなカフェ」なのだ。
本文中にはないけど、アパホテルの広いベッドと大型テレビと大浴場というのは宿泊客の「ユーザーの期待」を理解した実装だと思った。
同様にセブンイレブンのセブンコーヒーも、「缶コーヒーよりおいしいコーヒーをさっと買いたいが、寄り道などの余計な時間コストは払いたくない。値段も４ドルも払いたくない。オサレな空間も求めていない」というユーザーに対し、朝や昼にコンビニによったときに提供することで見事にユーザー期待に応え、高いユーザビリティを実現しているように見える。
スタバの成功例として、ユーザビリティの高さは味のよさなどよりユーザーにわかりやすく、差別化しやすく、高いフィーとして現金化しやすいとしている。
ここで注意してほしいのは、ユーザーの期待に対して高効率で応えるサービスを提供することで高いフィーを獲得できるという話であって、
「スタバみたいなオサレなサロン感のあるサービス」を提供すれば金になるって話ではない。
また、それを期待していないユーザーに対して「オサレなサロン感」を押し出しても金を取れるわけでもない。ユーザーの期待に沿っていないからだ。
ユーザーの期待をどう理解するか？
数値から読み取る方法とユーザーにインタビューして聞き出す方法を書き、特にユーザーからインタビューする方法について詳しく書いている。
文面の半分程度を割いているが、実際詳しい。
(初学者ならとっかかりとして是非読むべきだと思う。浅く広くよくおさえている。)
総括
ユーザービリティという誤解されがちな言葉を扱っているが、「ユーザービリティ＝ユーザーの期待に対する効率」というのが理解できたので、良い本だったと思う。
株式会社はてなに入社しました
株式会社はてなに入社しました 入社金は割増で６万円でした
サービス開発を迷走させるコツ
この記事は アジャイルCasual Advent Calendar 2014 - Qiita の23日目です
ネタが足りないのでこの前聞いた話をまとめて埋め草にしようという魂胆です
情報を集めない
- ビジネス判断を行う際には、判断材料として情報が必要です。
不足があるとその部分を「勘と経験」で埋めます - また、情報をむやみに集めすぎると重要な情報がそうでない情報に埋もれて有効に活用できなくなります。
ローマ初代皇帝が元老院の定数を倍に増やしたことでに(彼の目論見通り)元老院の力が弱まったことに似ています。 - 重要な情報と、そうでない情報とはなにか、を定義しないこともこの傾向を加速させます。
ドメインを理解しない
- ドメインとはどういった構造をしているか？
ビッグプレイヤーが存在しないとしたらなぜ存在しないのか？
ユーザーやニーズの所在や構造をモデル化しているか？
…これらを行うためにはドメインへの理解が必要です - ドメインを理解しない人間が考えた施策はだいたい外れる可能性が高く、また当たってもヒットの大きさが足りないケースが多くなります。
- ヒット率の高さを補うために、ドメインを理解する代わりに世間的にはやっているサービスを表面的にパクった機能のリリースが志向されます。
ヒット率の問題は補えますが、代償としてより無軌道にサービスが肥大化し始めます。
ビジョンを定めない
- インセプションデッキで定義される内容、英語で言うStrategyやPrincipleの部分を定めません。
- 結果として、「なぜこの機能はリリースされるのか？そうすることでユーザーのどういう利便性が向上し、どういった利益が得られるか？」というシナリオがメンバーの中で理解されず、「指示された機能をよくわからないまま実装する」という状態に開発者が陥ります
そういった状態で実装された機能は利用品質が低く、イケてなくて、ぼやっとした機能になりがちです。
想定通りのパフォーマンスを発揮し、コスト以上に利益を回収できる確率は低下します。 - メンバー間でサービスに対する理解が共有されないため、サービス開発の迷走の火種になります。
- 結果としてサービスがヒットしたとしても機能追加を繰り返すほどジェンガのように不安定で無秩序な状態に陥り、乱脈なサービス開発ゆえに後進サービスに陳腐化される可能性が高まります
思いつきにすがりつく
- 偉い人の思いつきが、十分な洗練を経ずに企画から実装、リリースが急がされます。
これは「なぜこのサービスが伸び悩むのか」という問題を「この機能がリリースされればすべての問題は解決される」と思い込むことで「この機能をどうすればリリースできるか」という問題にすり替えることを目的としています。 - ユーザーの「xxができたら使うのに」という声に安易に従います。
これは上記3つの合わせ技で「なにをすれば改善できるのか」が判断できないので、ノイジイーマイノリティや誰かの無責任な一言に追従してしまうのです
HITしなかった機能を無思慮に放置する
- リリースしたもののほとんど使われなかった機能はあると思います。
こういった機能は「Closeする」という決断をされぬまま、維持するためのコストがかかり続けます。
このコストは多くの場合可視化されず、それでいてそれなりの額が他で稼ぎ出した利益や他に回されれば多くの利益を生むであろう資源を食いつぶしながら存続します。 - これらを防ぐには「撤退条件」や「成功条件」、「存続意義」を定めておくのがコツです。逆にやりたければこれらは定めないほうがよいでしょう。
俺たちのペアプロ戦記
論旨
従来のやり方
私のチームはそれまでこんな感じでタスクを進めていました。
- タスクの終了条件を決めてアサインされる。
- タスクの仕様を説明される
- プログラムする
- レビュー受ける
問題点
ところが新プロダクトの開発を上のフローで進めるうちに、問題点が噴出しました
聞く側
- プログラム中に細かいところを何度も聞きにいくのが面倒くさい
- 確認待ちで作業が止まる
- レビューが帰ってくるまでの待ち時間が長い。
- 帰って来た頃には半分くらい忘れている
- レビュー待ちの間に別のタスクを始めるので仕掛中のタスクがどんどん増える
- レビュワーの指摘でタスクの仕様が変わる事がある その場合タスクが振り出しに戻る
聞かれる側
- 何度も聞かれて作業が中断される
- 聞くなら一回にしてほしい
- レビュー依頼の件数が際限なくたまる
- すこしでもレビューを貯めてしまうと、レビュー待ちしている人が別のタスクを始めてまた積んでいくので、レビュー待ちが複利で増える
- merge間隔が開く
- レビュー未了だとmergeできないため、 main branch から孫ブランチやひ孫ブランチが発生する。
- 疑問点や質問を書いたり、細かく指摘を繰り返すレビューラリーが増える
問題の被害が無視しがたいレベルであり、作業スピードを悪化させました。 これでは目標リリース日までにリリースできません。 リリースできない場合、社長は激おこになり、我々はユーザーにその辺りの街灯に高く吊るされます
移行経過
我々はこれらの問題を解決すべく、いくつかのプラクティスを導入しました
- 最初の段階でgithubのIssueで話し合うようにした
=> 要件が固まるので質問に行く頻度が減った - それでも話がまとまらない場合はホワイトボードで話し合った
- レビュー依頼したときに以下の事をすることでレビューの回数と時間を圧縮
- レビュー依頼時に背景知識について5分程度で説明
- 重点的に見てほしい場所をdescriptionに記述
- 横に座ってリアルタイムでレビュワーの疑問点や指摘に応える
プラクティスを順次導入する事で作業スピードは改善し、徹夜や終電を連発しましたがなんとかプロダクトを期日までにリリースすることができました。
最終的に
リリース後、別の開発で上のプラクティスを洗練させた結果、以下のプラクティスにたどり着きました。
- 特定のタスクに対し、ホワイトボードの前に二人が座ってホワイトボード前と端末前を行き来しながらペア作業すれば以下の3つのフェーズをフィードバックを受けつつ高速に回転させられる。
- 仕様策定
- 実装
- レビュー
- タスク粒度が大きくても比較的とても短時間で完了できるため、二人が拘束されたとしても一人ずつ作業するより生産性が高い事が分かった。
- 副次効果として、メンバーが密度の高い作業をこなすと短い時間で相当疲労するため、帰宅時間が早くなった。
これはなにかに似ていないでしょうか。
そう、ペアプロです。
ペアプロがなぜよいかが心で分かりました。
この瞬間私はペッシになりました
