「イシューからはじめよ」という書籍の輪講で、一章の前半を開発に役立つような形でまとめました。

1. 開 発 の 本 質
チ ケ ッ ト 数 を 1 / 1 0 0 に す る 方 法
f r o m イ シ ュ ー か ら 始 め よ
@icoxfog417

2. 1
「登録されているチケットをすべて消化したら、あなたの開発してい
るサービスはユーザーから賞賛を受けるようになるか？」
この問いに自信をもってYesと答えることができなければ、本文書はあ
なたの役に立つと思います。
この文書は「イシューからはじめよ―知的生産の「シンプルな本
質」」を基に書かれています。もし興味がわいたら、ぜひこちらも参
照してみてください。
※なお、本文書でいう「チケット」は機能に関わるもので、バグ修正などを除きます。

3. 2
 開発の「価値」の本質
 仮説ファースト
 「価値」を生むチケットの3要素

4. 開発の「価値」の本質

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

6. 5
解の質
問いの質
High
Output
問いの質：解決する価値のある問題か
解の質：問題を少ない工数で解けるか
「アウトプット」というと、解の質が
クローズアップされることが多いが、
問いの質(=イシュー度)こそが重要。

7. 6
最新の手法で頑張ってパフォーマンス上げました！
ありがとう。ユーザーの離脱度は下がったかな？
さあ・・・(俺の考えることじゃなくね？)

8. 7
解の質
問いの質
「問いの質」が低い問題をいくら解き
つづけても、「本当に解決しなければ
いけない課題」は残り続ける。
逆に、「問いの質」が低い問題はいく
らでもある。その解決に集中したり小
難しい手法で解いていても、満足感は
あるがアウトプットは出ない。これは
犬の道(あるいは社畜道)と呼ばれる。
Low
Output
High
Output

9. 8
解の質
問いの質
ただ、最初から高い質の問いを定義す
るのは難しい。
徐々に問いの精度を高めていくことで、
高いアウトプットへとたどり着く。
Low
Output
High
Output

10. 9
「解く」前に「見極める」
f r o m イ シ ュ ー か ら 始 め よ 一 章 章 題

11. 仮説ファースト

12. 11
「問いの質」を高めるには、まず仮説を立てることが重要になります。
×：パフォーマンスを上げる
○：アクティブユーザーを増やすには、トップページの表示速度を0.5
秒以内にする必要がある

13. 12
仮説とは、「解答の予測」です。そのため、以下の要素を備えている
必要があります。
 解答を提示する
 証明に必要な分析が明確である
 分析結果から、真偽を明確にすることができる
「何に答えようとしているのか」をチーム内、また作業を依頼する側/
される側で共有しておくのが重要です。

14. 13
良い仮説は、以下の点が明確です。
 WHERE: 何を目指すのか
 WHAT: 何がターゲットなのか
 HOW: どうすれば達成できるのか
アクティブユーザーを増やすには、トップページの表示速度を0.5秒以
内にする必要がある
WHERE WHAT HOW

15. 14
大胆に踏み込み、言葉にする

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

17. 16
良い仮説を基に実際のチケットを作成します。この時、本当にこのチ
ケットの解決が価値を生むのか、という点について3つの評価ポイント
があります。
 今後の方向性に影響を与えるか
 今まで明らかになっていない法則性を提示しているか
 答えを出せるか(検証可能か)

18. 17
「もしxxだったとしたら、今までの改善策を見直さないといけない」と
なるようなものが、方向性に影響を与えるものになります。
ある機能を実装するということは「HOW」の部分になります。それによ
り証明されるWHERE/WHATの真偽が今後のチーム開発の方向性に影響
を与えるものになっているか、という点が重要です。
今後の方向性に影響を与えるか

19. 18
機能の実装により、今までにないような法則性を見つけることができれ
ばサービスの改善に大きく役立ちます。
法則性の例: AとBが同じグループである(同族関係)、Aがこう変換すると
きBはこう変換する(相関関係)など
「今までにないような法則性」とは、言い換えれば常識を否定するよう
な法則性です(メニューは上よりも下に表示すべきだ！とか)。常識を打
破するような法則/関係性を示せる開発は、良い開発になります。
今まで明らかになっていない法則性を提示しているか

20. 19
開発した結果答えが明確なる必要があります。「効果があったのかな
かったのか、どちらともいえない」となる場合良い開発ではありません。
 証明する手立てがない
 手だてがあっても、自分たちには技術的/データ的に不可能
こうしたパターンは、たとえ「今後の方向性に影響を与える新しい法則
性」を示唆していても良い開発にはなりえません(例：コンパイラに手
を加えれば・・・ｺﾞｸﾘ など)。
答えを出せるか(検証可能か)

21. 20
「今本当に答えを出すべき」かつ
「答えを出す手段がある」問題は
全体の1%ほどにすぎない

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

23. 22
Have a Good Development!