サービス開発を迷走させるコツ

この記事は アジャイルCasual Advent Calendar 2014 - Qiita の23日目です

ネタが足りないのでこの前聞いた話をまとめて埋め草にしようという魂胆です

情報を集めない

• ビジネス判断を行う際には、判断材料として情報が必要です。
  不足があるとその部分を「勘と経験」で埋めます
• また、情報をむやみに集めすぎると重要な情報がそうでない情報に埋もれて有効に活用できなくなります。
  ローマ初代皇帝が元老院の定数を倍に増やしたことでに(彼の目論見通り)元老院の力が弱まったことに似ています。
• 重要な情報と、そうでない情報とはなにか、を定義しないこともこの傾向を加速させます。

ドメインを理解しない

• ドメインとはどういった構造をしているか？
  ビッグプレイヤーが存在しないとしたらなぜ存在しないのか？
  ユーザーやニーズの所在や構造をモデル化しているか？
  …これらを行うためにはドメインへの理解が必要です
• ドメインを理解しない人間が考えた施策はだいたい外れる可能性が高く、また当たってもヒットの大きさが足りないケースが多くなります。
• ヒット率の高さを補うために、ドメインを理解する代わりに世間的にはやっているサービスを表面的にパクった機能のリリースが志向されます。
  ヒット率の問題は補えますが、代償としてより無軌道にサービスが肥大化し始めます。

ビジョンを定めない

• インセプションデッキで定義される内容、英語で言うStrategyやPrincipleの部分を定めません。
• 結果として、「なぜこの機能はリリースされるのか？そうすることでユーザーのどういう利便性が向上し、どういった利益が得られるか？」というシナリオがメンバーの中で理解されず、「指示された機能をよくわからないまま実装する」という状態に開発者が陥ります
  そういった状態で実装された機能は利用品質が低く、イケてなくて、ぼやっとした機能になりがちです。
  想定通りのパフォーマンスを発揮し、コスト以上に利益を回収できる確率は低下します。
• メンバー間でサービスに対する理解が共有されないため、サービス開発の迷走の火種になります。
• 結果としてサービスがヒットしたとしても機能追加を繰り返すほどジェンガのように不安定で無秩序な状態に陥り、乱脈なサービス開発ゆえに後進サービスに陳腐化される可能性が高まります

思いつきにすがりつく

• 偉い人の思いつきが、十分な洗練を経ずに企画から実装、リリースが急がされます。
  これは「なぜこのサービスが伸び悩むのか」という問題を「この機能がリリースされればすべての問題は解決される」と思い込むことで「この機能をどうすればリリースできるか」という問題にすり替えることを目的としています。
• ユーザーの「xxができたら使うのに」という声に安易に従います。
  これは上記3つの合わせ技で「なにをすれば改善できるのか」が判断できないので、ノイジイーマイノリティや誰かの無責任な一言に追従してしまうのです

HITしなかった機能を無思慮に放置する

• リリースしたもののほとんど使われなかった機能はあると思います。
  こういった機能は「Closeする」という決断をされぬまま、維持するためのコストがかかり続けます。
  このコストは多くの場合可視化されず、それでいてそれなりの額が他で稼ぎ出した利益や他に回されれば多くの利益を生むであろう資源を食いつぶしながら存続します。
• これらを防ぐには「撤退条件」や「成功条件」、「存続意義」を定めておくのがコツです。逆にやりたければこれらは定めないほうがよいでしょう。