「イシューからはじめよ」感想

各所でオススメされている、「イシューからはじめよ」を読み終わりました。

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

総評: +2 (超オススメ！)

「解決すべき問題を絞り込む」ということが重要なのは頭ではわかっていても、なかなか実践できないもの。本書では、「生産性を上げる」というモチベーションから必要なステップを述べ、その具体的な取り組み方と論拠を解説しています。根幹を成すのは「問題の絞り込み」で、ここについては詳細に、かつ簡潔に述べられています。

最後にも述べますが、エンジニアにとっても重要だと感じる点が多く、特にソフトウェア開発の幅広い範囲を担当している方にはおすすめできる本だと思いました。

各章ごとに重要だと思ったポイントと、エンジニア視点での「守らなかったら何が起きるのか」という架空の失敗例も添えていますので、想像しながら読んでみると面白いかと思います。

はじめに

生産性を上げるには、「何に答えを出すか」のブレなさが重要

この本の主題、すなわちイシュードリブンにしよう、ということ。後の章で詳細が出てくるため、ここでは提起のみ。なお、「生産性」と聞くと思い浮かぶ「あるタスクをこなす速さ」は、生産性向上の一因ではあるが全てではない。

エンジニア的失敗例: 誰も使わないツールを素早く完璧に作っても、生産性は低い

悩まないで考えよ

• 悩む: 答えが出ない前提
• 考える: 答えが出る前提で答えに近づくよう論理を組み立てること

しばらく真剣に考えても埒が明かないなら、悩んでしまっているかも。答えは何か、答えに近づくよう論理を組み立てられているか、休憩して振り返るのも重要。「あ、今悩んでる」と自覚できると良い（訓練が要る）。

エンジニア的失敗例: 長時間ある問題の解決策を考えて（悩んで）いたのに、答えに全く近づいていなかった。実は解決すべき問題は違うものだった（競プロあるある）

序章

生産性はインプットに対するアウトプット

低インプット高アウトプットにすればするほど、生産性は高い。インプットはかけた時間や労力なので分かりやすいが、高いアウトプットとはなんだろうか？という議題は次に続く。

エンジニア的失敗例: 1年かけて当時の先端技術で電卓アプリを作っても、生産性は低い

仕事の価値は、「イシュー度」と「解の質」の二軸で定義される

アウトプットが高い = 価値の高い仕事をした、と定義している。そして仕事の価値は、「イシュー度」と「解の質」の2つで決まる。

• イシュー度: 自分のおかれた局面で、この問題に答えを出す必要性の高さ
• 解の質: そのイシューに対して、どこまで明確に答えを出せているかの度合い

エンジニア的失敗例: リリース直後のサービスのAPIで処理が遅く、原因はメモリのスワップアウトにあることがわかった。半年かけてアプリケーションコードにカリカリのチューニングをし、なんとか必要な速度を取り戻した。が、ユーザー数の増加に依存せずフレームワークが消費していただけだったので、インスタンスのメモリを少し増やすだけで良かった

仕事の価値を上げるには、まずイシュー度を上げる

解の質を上げてからイシュー度を上げようとすると、イシュー度の低い仕事を多く取り組まないといけない。その結果かかる時間が増え、数打てば当たるなんてことは無くモチベーションが下がり、解の質も下がる。

そのため、まずイシュー度を上げる（問題を絞り込む）ことに専念する。十分な検討時間を用意し、解を出してフィードバックを受けることで、解の質が上がってゆく。

なお、イシュー度を考える際には、「解きやすさ」「取り組みやすさ」を度外視することが重要と述べられている（ついついこの辺でフィルターしてしまいがち）。

「正しい問題」に集中し、「正しい訓練」をすることが重要（……と言葉で言うのは容易いが、できてないことは多いよね……）

エンジニア的失敗例: いずれは大人気スマホアプリを作りたいと思い、様々な技術や言語を使ってToDoアプリを作り続けてきた。結果、人気のスマホアプリを作れるようにはならなかった

一章

イシューを見極める

問題はまず解くのではなく、「何に答えを出すのか」を見極めることから始める。 その分野に詳しかったり、知識を持っている相談相手を持つことも重要。

見極めの際は、ふんわりとした所で止めず、スタンスを取って具体的な仮説を立てる。

• ✗「aaの利用者はどうなっているか？」
• ○「aaの利用者は縮小傾向にあるのではないか？」

エンジニア的失敗例: 月額制のサービスで「ユーザー数が減ってるから対策して！」と言われたため、広告を打ったりLPを工夫したりして新規ユーザー数を増やした。しかし、実は継続率に課題があり、継続するユーザー数が増えず広告費を上回る売上は上がらなかった

イシュー・仮説は必ず言葉にし、ブレを減らす。

• 主語・動詞を入れ、曖昧さをなくす
• Whyではなく、What/Where/When
• 比較表現を入れる

エンジニア的失敗例: 「レスポンスタイムがなぜ悪化したのかを考えよう」

よいイシューとは

• 本質的な選択肢
  • = 今後のカギとなる問い
• 深い仮説
  • 常識・思い込みの否定
  • 新しい構造での説明
• 答えを出せる
  • 現在の手法で答えを出す見込みがなければ、取り組んでもアウトプットは無

よくないイシュー

• 本当は答えを出す必要のないもの
  • 「なんちゃってイシュー」という名前がつけられている
• 主語が変わっても成り立つ
  • 十分に絞り込まれていれば、主語に限定されたイシューになるはず

エンジニア的失敗例: ユーザー数が減少していたので、UI改善のため大規模なコードの書き換えをした。しかし、後ほどユーザーヒアリングをしてみると「不要な通知が多すぎる」という点が問題であり、リニューアルでは改善していなかった （なんちゃってイシュー）

イシューを決めるための情報収集

• 一次情報に触れる
• 基本情報（常識）を知る
• 集めすぎない、知りすぎない
  • 知識は増えるが、知恵は知識の一定量を境に鈍化する

それでも決まらない場合、以下の手法が使える。

• 変数を削る、固定する、具体化する
• 視覚化する（絵を書いたり、プロットしたり）
• 最終形から逆算する
• 当たり前のことしかイシューに挙がらない場合、「So what?」を繰り返す
  • いわゆるなぜなぜ分析
• 極端な事例を考え、キーとなる変数を探る
  • ユーザー数が1/10になったら……？など

エンジニア的失敗例: 社内から「○○なツールが欲しいという声がXX部門で上がっているので作ってくれ」と言われた。その通り作ったら、XX部門では使いものにならないと言われ、また仕様策定から始まった

二章・三章

解の質を上げるため、イシュー分析をする

下記を書くことでイシュー分析をしている。

• ストーリーライン
  • イシューの分解
    • 「収集した大量のデータから意味合いを考えてストーリーを作る」……のではなく、「仮説が正しいとした場合、どのようにそれらは検証できるか」を考える
    • 「答えが出せるサイズ」で、本質的に意味のある固まりに分解
    • 下記の型が有効
      • Where/What/Howの3つに分解
      • 最終形から逆算する
  • ストーリーの組み立て
    • 前提の共有 / イシューの定義 / 各イシューへの回答 / 目指すべき方向
    • 脚本・ネームづくりに当たる作業
    • 下記の型が有効
      • Whyの並び立て: 最終的なメッセージに対する理由を並列する
      • 空・雨・傘: 課題の確認 / 課題の深掘り / 結論、という流れで結論を補強する
• 絵コンテ
  • 適切な比較の軸を作る
  • 具体的な数字を入れる
    • 差 / 変化 / パターン、のいずれが欲しいのかを考え、図とする
  • データの取得方法を記載する

これらは検討が進むに連れどんどん書き換える。

エンジニア的失敗例: チームAはユーザー数推移や行動ログなどから、パフォーマンス低下の原因を推察した。これには時間がかかり、真の原因を見つけるまで数か月かかった。一方、チームBでは「ユーザー数増加に比例したメモリを消費している」などの仮説を立て、それを検証するためのタスクづくりやデータを集める方式を取り、より短時間で原因を突き止めた

エンジニア的失敗例: 現在のトラフィックを捌くには、インスタンスタイプを一段階上げなければいけないという結論に至った。が、ストーリーラインを組まずに結論を伝えたところ、必要性が認められず予算が降りなかった

エンジニア的失敗例: 絵コンテを書かずに各モジュールのベンチマークを取ったため、細かすぎる値や関係のないデータを省いていいかわからず、結局必要な値は取っていかなかった

四章

絵コンテからの分析

絵コンテをもとに分析をし結果を出すフェーズ。 下記に気をつけるとやりやすい。

• サブイシューの中で重要なものから取り掛かる
  • 「前提」や「洞察」
• 「答えありき」での分析には注意する
• 予めおおよその値を推定しておくとスムーズ
• 手法に固執しない
• 必要な完成度を見極め、やりすぎない
  • 完成度を上げるには、1つ1つを丁寧にするより、手早くまとめてもう一周する
  • スピード重視

エンジニア的失敗例: 社内用ツールの開発で、モジュール単位の実装をするフェーズに入った。優先度付けやスケジュールを決めずに開発を始めて、しばらくして各モジュールの担当に聞くと、「他で使われることのない部分をライブラリ化している」「メモリ消費量は極めて少ないが可読性が皆無なコード」「やたら高機能なUI」などが散見された。結合テストはボロボロで、結局運用までに1年かかった

五章

これまでの結果をもとにして、うまく論文やスライドに落とし込む方法。

• 受け手（読み手）は「賢いが無知」だとする
• 本質的でシンプルなもののみに絞る
• ストーリーラインを洗練させる
  • 論理の確認 / 流れを洗練 / エレベーターテスト（ピッチ）に備える
• チャートを洗練させる
  • イシューに沿ったメッセージ / 軸を洗練 / メッセージに即した図

エンジニア的失敗例: コンテナによるクラスタリングで生じるコストの削減を割合で示し、開発上の利点とともに経営陣に説明した。が、どれくらい経費が減るのかがあまり伝わらず、結局採用されることはなかった

まとめ

体系だった説明がされており、非常に分かりやすく主張がまとまっています。また、筆者はトップティアのコンサルタントであると同時に生物学者でもあることから、類する本には無い新たな視点や解釈を与えてくれています。

本の構成もわかりやすく、順番に辿ることで1つの課題に答えを出し結果をまとめるまでの手順を体験できます。また、要所要所に「イシューはぶれてないか？」と確認を入れてくれるので、重要なことが繰り返し刷り込まれます。

エンジニアも問題解決をするという仕事柄、共通する・身につまされる・体験したことが多く存在します。上記の失敗例は架空の話ですが、エンジニアが読むと様々な例が頭をよぎるかと思います。

そしてこの手の本の宿命、言うは易く行うは難し。この本では最後にこの事についても述べられています。学んだことは実際に適用して経験を積んでいくことが肝要ですね。

少しでも気になった方は、ぜひ読んでみてください。Kindle版もあります。

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