$shibayu36->blog;

クラスター株式会社のソフトウェアエンジニアです。エンジニアリングや読書などについて書いています。

「イシューからはじめよ」再読

最近仕事で「やるべきと思うこと」が溢れてきて良くない傾向になっていたので、「本当にやるべきこと」を見極める方法を知りたく、昔読んだことのある「イシューからはじめよ」を再読した。

良いこと言っていると思いつつ、なぜか自分に落とし込めてない。前も同じ感想を抱いた気がする。なんだろうな、結局この本から自分の納得の行くアクションが抽出できていない。100個問題っぽいものがあったら2~3個しか今の段階で解くべきものはないからそれを見つけろという意見は分かるが、見つけるためのアクションが咀嚼できてない。困った。

【13:30追記】
課題のどれからやるべきかを決める方法を悩んでいたけど最近のISUCONの時のやり方が参考になりそうだと思った。

ISUCONは改善すべきポイントは無数にあるが、実際には一番ボトルネックになっているところを解消しないとスコアは上がらない。前回やったときはまず全体像を眺めてこの辺を改善すべきというリストを作って、その後この中で一番効きそうなものから取り組んでいった。効きそうかどうかはアクセスログやクエリ分析、サーバ負荷状況から推定した。

つまり

  • 課題リストを作る
  • リスト内の比較で重要度を決める
  • 重要度がすぐに分からないところを定量的に分析する

という感じだろうか。

読書ノート

  • 生産性の定義は組織論と同じだな 220
    • 「どれだけのインプットで、どれだけのアウトプットを生み出せたか」
    • 生産性 = アウトプット / インプット = 成果 / 投下した労力・時間
  • 「イシュー度」とは「自分のおかれた局面でこの問題に答えを出す必要性の高さ」、「解の質」とは「そのイシューに対してどこまで明確に答えを出せているかの度合い」。この組み合わせでバリューのある仕事かどうか決まる 256
  • 今取り組むべきタスクはほんの少ししかないというのは、いすこんのボトルネックと近いなと思った
    • 問題かもしれないものが100あったら、本当にやるべきものは2~3個
  • イシューを言葉で表現するときは、主語と動詞を入れ、「WHY」より「WHERE」「WHAT」「HOW」を重視し、比較表現を入れる 523
  • 良いイシューとは、先の方向性に大きく影響をあたえ、深い仮説があり、答えを出せるもの 545
  • 新しい構造でイシューをとらえる 684
    • 共通性の発見、関係性の発見、グルーピングの発見、ルールの発見
  • 仮説を立てるためにはユーザーに会うなど一次情報の収集にこだわる。書籍など二次情報は一面的にしか情報がない 752
  • イシューが見つからない時のアプローチ。変数を削る、視覚化する、最終形からたどる、so whatを繰り返す、極端な事例を考える 856
  • 組織なら目指すべき姿とギャップを考えるとよさそうと思った 895
  • だから何?を繰り返し、イシューの曖昧さをなくす 934
  • サブイシューを洗い出すときは何がわかれば意思決定ができるかの視点で見る。これはKPI分解で施策検討ができるようにするというのと話が同じと思った。 1150
  • 分析は、どんな分析結果が欲しいのかを起点に考える。データをただ眺めるのではダメ。 1327
  • 分析とは比較であると考える。たしかにサービスの戦略を考える時も、他と比べて何が弱いかとか、どの数値が意図せず低いかみたいなの考えた 1363
  • 分析をしたいときは先に問いを立てようと思った
  • 比較には、比較、構成、変化という三種類しかない 1377