開 発 の 本 質 チ ケ ッ ト 数 を 1 / 1 0 0 に す る 方 法

f r o m イ シ ュ ー か ら 始 め よ

@icoxfog417

1

「登録されているチケットをすべて消化したら、あなたの開発してい

るサービスはユーザーから賞賛を受けるようになるか？」

この問いに自信をもってYesと答えることができなければ、本文書はあ

なたの役に立つと思います。

この文書は「イシューからはじめよ―知的生産の「シンプルな本

質」」を基に書かれています。もし興味がわいたら、ぜひこちらも参

照してみてください。

※なお、本文書でいう「チケット」は機能に関わるもので、バグ修正などを除きます。

2

開発の「価値」の本質

仮説ファースト

「価値」を生むチケットの3要素

開発の「価値」の本質

4

開発にかけた時間

アウトプット

価値＝かけた時間に対して、どれだけアウトプットを出せたか

5

解の質

問いの質

High Output

問いの質：解決する価値のある問題か

解の質：問題を少ない工数で解けるか

「アウトプット」というと、解の質が

クローズアップされることが多いが、

問いの質(=イシュー度)こそが重要。

6

最新の手法で頑張ってパフォーマンス上げました！

ありがとう。ユーザーの離脱度は下がったかな？

さあ・・・(俺の考えることじゃなくね？)

7

解の質

問いの質

「問いの質」が低い問題をいくら解き

つづけても、「本当に解決しなければ

いけない課題」は残り続ける。

逆に、「問いの質」が低い問題はいく

らでもある。その解決に集中したり小

難しい手法で解いていても、満足感は

あるがアウトプットは出ない。これは

犬の道(あるいは社畜道)と呼ばれる。

Low Output

High Output

8

解の質

問いの質

ただ、最初から高い質の問いを定義す

るのは難しい。

徐々に問いの精度を高めていくことで、

高いアウトプットへとたどり着く。

Low Output

High Output

9

「解く」前に「見極める」

f r o m イシューから始めよ 一章章題

仮説ファースト

11

「問いの質」を高めるには、まず仮説を立てることが重要になります。

×：パフォーマンスを上げる

○：アクティブユーザーを増やすには、トップページの表示速度を0.5

秒以内にする必要がある

12

仮説とは、「解答の予測」です。そのため、以下の要素を備えている

必要があります。

解答を提示する

証明に必要な分析が明確である

分析結果から、真偽を明確にすることができる

「何に答えようとしているのか」をチーム内、また作業を依頼する側/

される側で共有しておくのが重要です。

13

良い仮説は、以下の点が明確です。

WHERE: 何を目指すのか

WHAT: 何がターゲットなのか

HOW: どうすれば達成できるのか

アクティブユーザーを増やすには、トップページの表示速度を0.5秒以

内にする必要がある

WHERE WHAT HOW

14

大胆に踏み込み、言葉にする

価値を生むチケットの3要素

16

良い仮説を基に実際のチケットを作成します。この時、本当にこのチ

ケットの解決が価値を生むのか、という点について3つの評価ポイント

があります。

今後の方向性に影響を与えるか

今まで明らかになっていない法則性を提示しているか

答えを出せるか(検証可能か)

17

「もしxxだったとしたら、今までの改善策を見直さないといけない」と

なるようなものが、方向性に影響を与えるものになります。

ある機能を実装するということは「HOW」の部分になります。それによ

り証明されるWHERE/WHATの真偽が今後のチーム開発の方向性に影響

を与えるものになっているか、という点が重要です。

今後の方向性に影響を与えるか

18

機能の実装により、今までにないような法則性を見つけることができれ

ばサービスの改善に大きく役立ちます。

法則性の例: AとBが同じグループである(同族関係)、Aがこう変換すると

きBはこう変換する(相関関係)など

「今までにないような法則性」とは、言い換えれば常識を否定するよう

な法則性です(メニューは上よりも下に表示すべきだ！とか)。常識を打

破するような法則/関係性を示せる開発は、良い開発になります。

今まで明らかになっていない法則性を提示しているか

19

開発した結果答えが明確なる必要があります。「効果があったのかな

かったのか、どちらともいえない」となる場合良い開発ではありません。

証明する手立てがない

手だてがあっても、自分たちには技術的/データ的に不可能

こうしたパターンは、たとえ「今後の方向性に影響を与える新しい法則

性」を示唆していても良い開発にはなりえません(例：コンパイラに手

を加えれば・・・ｺﾞｸﾘ など)。

答えを出せるか(検証可能か)

20

「今本当に答えを出すべき」かつ

「答えを出す手段がある」問題は

全体の1%ほどにすぎない

21

チケットの数は1/100になる

22

Have a Good Development!