「イシューからはじめよ」の感想を最近の状況を添えて

「イシューからはじめよ」という本を読みました。
「生産性向上」、「努力の量は関係ない、結果が全てだ」
冒頭はこういうキーワードで僕の思想と通ずるところもあり、引き込まれた。

この本が書かれるきっかけとなった著者のブログ記事はこちらです。
【参考】圧倒的に生産性の高い人(サイエンティスト)の研究スタイル – ニューロサイエンスとマーケティングの間 – Being between Neuroscience and Marketing

イシューとは

この本の主題である、イシューというのは、「解くべき課題」のことで、問題を解決するために、どうこうする前に、これは本当に解くべ問題なのかということを見極めようという話。

「イシュー度」と「解の質」という2軸をとったとき、まず最初に「何に答えを出す必要があるのか」を考え、イシュー度の軸を進め、その後、「そのためには何を明らかにする必要があるのか」を考え、「解の質」の軸方向に進むように心がける。
わざわざこれを言うのは、大抵の場合は逆の順番で取り組まれることが多いから。
そうすると、数撃ちゃ当たる戦法になり、結果を出すことに非常に効率が悪くなってしまう。

プロセス

おおまかな手順は以下の通り。

  1. 解くべきイシューを見極める
  2. イシューを解けるところまで(次の行動が起こせるまで)分解する
  3. ストーリーの流れを整理する

イシュードリブン

最初の難題は、「強い人」と話せる環境を作れるかどうかだ。
自分が老練な経験者ならそれでいいが、僕みたいな雑魚の場合は、知識や経験面で、「この人こそ」と思える人に出会っている必要がある。
それは上司だったり、教授だったり、Twitter界隈にいるエンジニアの人だったり、本の著者だったりするんだろう。
そういう人と話をして、これが本当に解くべきイシューかどうかを見極める必要がある。

仮説ドリブン

第2章には仮説を立てることについて書かれてある。
答えを出すべき問題を仮説を含めて明確にする必要がある。

良いイシューの3条件

1.本質的な選択肢である
選択次第で状況が良くも悪くも大きく変わるもの。
これがイシューだ、と思ったらまずはその主語を考えてみて、この主語が誰にでも当てはまるような普遍的なものの場合、それは本質的なイシューではない可能性が高い

2.深い仮説がある
「よくわからんけど、とにかくやってみよう」の精神で猪突猛進するのではなく、まず最初に仮説を設定する。
それも、ただの仮説ではなく、その仮説そのものが常識と反するようなものである。
このような深い仮説を立てることができれば、それが検証されたとき、ここには価値を生むことに納得できる

3.答えを出せる
「インパクトのある問い」ではあるが、「答えを出せる見込みがほとんど無い問題」は良いイシューにはならない。
これはこの問題を分解することで、答えを出せるようになるかもしれない。

所感

何か問題に立ち向かうときに念頭に置くべきことはこの本の最初の方に書いてあること。
これらを頭に入れておき、実際にどうアプローチすればよいのかが後半に書かれている。

今の状況がそこまで逼迫しているわけでもないので、後半はしっかり頭に入らなかった。
僕が今後このような状況に直面したときに、再度この本を読んで、リアルタイムで行動に移せたらいいなと思った。

と言っても、現状でも活かせるものはいくつかある。
いつまでにどこまでを完成させるべきかを毎週話し合っているが、これらを決まった時間内に解決するためには無駄なことをしている隙はない。
躍起になって行っているこの作業は、実は本質的に無意味だったということにあとから気づいても困る。

なので、自分の中で今日はどんなふうに作業を進めていくべきかを考えるが、ここでこの本に書かれている考え方が活かせると思う。

「集中力がない」、「一つの作業を長時間するのが得意でない」という性格も手伝って、僕は生産性の向上というのはここ半年間くらいの大きなテーマだったりする。
これを適えるためには、そもそも取り組み方を変えないといけないのかも知れない。

あと、感じたのは、僕はMECE的なのが不得手だということ。
潜り込んだところにある課題に気付くことができなく、作業をやりながら「あ、ここにも問題あったな」と気付くことが多い。
これは結構問題で、工数の見積もりができない。
ここは対策する必要がある。
最初に考えるべき論理構造、場合分けを、隈なく重複なく列挙できるようになろう。

最近、仕事として本格的に開発を始めて思うのは、プログラミングというのは、
「くそー、わかんねえww」っとなって調べ、試す、調べ、試す、たまに聞く、を繰り返し、
「うごいた!!!!!!いやっほう!!!!」と喜び、動かなかった理由を理解し、
その喜びも束の間、少し進めれば、「くそー、わかんねえww」に再度ぶち当たる。

つまり、手を動かしてコーディングしている時間よりも、何かを考えたり、何かを読んだりしている時間のほうが圧倒的に多かったりする(フェーズにもよると思うけど。)
そこで、この調べ、試す、の繰り返し部分も実はもっと短縮できるのかも知れない。
知識の欠陥の補充ももちろん必要だが、そもそもの思考プロセスで改善できることも多々ある気がしている。

いつか、良いタイミングでこの本を読み返そうと思う。
例えば、研究するとき、何か事業を始めるとき、データ分析や技術的な調査をするとき。
そして、それらを発表するとき。

後半の内容は、今この記事を書いてる時点では、早急に必要なわけでもない気がした。
今重要なのは、目の前の課題を解決するための情報をいかに多く取り入れられるかと、基礎力で、さらにそれに挑むこと。
今はそれに注力してる。


コメントを残す