忙しい日に読み返す仕事本: 『イシューからはじめよ』
仕事が忙しくなると、考えるより先に手を動かしたくなる。そして、それらは一つ終わらせても、すぐに次のタスクが出てくる。
そんな日には、朝からずっと動いていたはずなのに、仕事を終えるころになって、「今日、本当に前に進められたものは何だったんだろう」虚無的に感じることがある。
でも、何もしていなかったわけではない。むしろ、いつもより(?)かなり働いている（はず）。それでも、重要な問題が前に進んだ感覚がない。
そういうときこそ、僕が読み返したくなるのが、"王道"とでいえよう、
安宅和人さんの『イシューからはじめよ』だ。
忙しくなるほど、問題を解き始めてしまう
IT企業で仕事をしていると、解かなければならないように見える問題が次々に現れる。
システムの不具合
手作業のオペレーション
他部署から新しい要望
ベンダーから確認事項
でも、、、
将来を考えると、アーキテクチャも見直したいし、チームメンバーの案件も確認しなければならないし、案件同士の橋渡し、上司への釈明などいろいろある。
そして、どれも無視していいわけではない。
ただ、すべての問題を同じ重要度で扱ってしまうと、時間はいくらあっても足りない。
忙しいときほど、「何から手を付けるか」ではなく、「目の前に来たものから、とにかく終わらせる」という進め方になりやすい。これは僕以外でもよくあることだろう。
僕自身も、タスクが多い日は、一覧の上から順番に消していくことがある。細かいタスクが何個も完了すると、少し仕事が進んだ気持ちになる。けれど、その日の終わりに残っているのは、最初から本当に考えなければならなかった大きな問題だったりする。
この本を読むと、問題を解く能力だけでなく、どの問題を解くのかを見極めることの重要性を思い出させてくれる。
すべての問題に、今答えを出す必要はない
『イシューからはじめよ』では、世の中に存在する多くの問題の中から、今、本当に答えを出すべき問題を見極めることが重視されているように思う。
本当に答えを出すべきで、なおかつ答えを出す手段がある問題はごくわずかだ。（でもそういうものこそ、さまざまな壁にぶち当たってしまうのが今日この頃の僕なのだが笑）手当たり次第に問題を解こうとすると、重要な問題に十分な時間を使えなくなる。
この考え方は、頭では理解しやすい。でも、実際に使うのは意外にも難しい。
目の前のこなせるものからこなしていきたくなる。自分が解決できそうな問題であれば、なおさらだが、解ける問題と、今解くべき問題は同じではない。
例えば、システム上の小さな不便を改善する案件があったとする。
技術的にはすぐに直せそうで、利用者からも要望が届いている。このとき、すぐに実装方法を考え始めるのではなく、一度立ち止まる。
そもそも、どの利用者が困っているのか
どれくらいの頻度で発生しているのか
本当にシステム改修が必要なのか
運用変更で解決できないか
今後予定している別の改修と重複しないか
この問題を解くと、何が大きく変わるのか
こうして考えてみると、最初に見えていた問題とは別のところに、本当に考えるべき論点があることも多い。すなわち、ただ直せばいい、という脳死状態から抜けられる。
問題をすぐ解くのではなく、問題の置き方から疑ってみる。
この一手間が、忙しいときほど抜け落ちる。本当に忙しい時の自分に言い聞かせたい。
「何を作るか」より、「何を変えたいか」
開発案件では、最初から作るものが決まっているように見えることがある。
管理画面に機能を追加する
APIを新しく作る
手作業を自動化する
データを取得できるようにする
既存のシステムを改修する
しかし、これらは"解決策"であって、必ずしも"イシュー"ではない。
例えば、「管理画面に新しい機能を追加したい」という案件があった場合にそのまま受け取って、画面設計、APIの設計、リソース問題などの具体的な話になる。
そうではない。その前に考えるべきことがある。
なぜ、その機能が必要なのか。
今は何ができず、誰が困っているのか。
その機能が追加されると、どの業務がどう変わるのか。
のような話から始めてみると原点回帰して、さらに楽になるのかもしれないし、既存のものでいいのかもしれない。あるいは、システム改修ではなく、業務フローを整理するだけで解決するかもしれない。
「何を作るか」から始めると、依頼されたものを正確に作ることがゴールになる。
「何を変えたいか」から始めると、作らないという選択肢も含めて考えられる。
この違いは実はかなり、めっちゃ、超大きい
タスクを減らすより、考える対象を減らす
忙しいときには、タスク管理の方法を変えたくなる。
ただ、新しいツールを使ったりして、タスクをどれだけきれいに並べても、不要な問題まで抱えていれば忙しさは消えない。
この本を読んでから意識するようになったのは、タスクを効率的に処理することよりも、そもそも考える対象を絞ることだった。
例えば、案件が複数並んでいるときには、次のように考える。
今答えが出ることで、最も状況が変わるものは？
別の判断の前提になっているものは？
今答えを出さないと、後から選択肢が減るものは？
誰かが困っているように見えて、実際には影響が小さいものは？
今はまだ情報が足りず、考えても答えが出ないものは？
全部を進めようとするのではなく、一つ答えを出すことで、他の問題も整理されるものを探して、そこにされ注力すれば、タスクを十個終わらせるより、仕事全体が大きく前に進むことがある。
仮説を置くと、調査が終わるようになる
僕は、最初に粗くても仮説を置く。
例えば、
原因は、アプリケーションの実装ではなく、外部サービス側の仕様変更
あるいは、
今回必要なのは全面的な改修ではなく、既存処理の責務を分離すること
仮説を置くと、確認すべき情報が変わる。目的を置いてそれに沿った方向にすることで説得性も行動の意図も見えるようになる。
その結果仮説が正しいか、間違っているかを判断するために情報を集めることができる。そうすると、調査の終わりが見えやすくなる。
『イシューからはじめよ』では、問題を見極めた後も、仮説を起点にイシューを分解し、必要な分析やアウトプットを設計していく流れが扱われていた。
調査量を増やすことより、何を確かめたいのかを明確にすることがいいのかもしれない。これは、技術的な調査だけでなく、企画やチーム運営でも使える考え方だと思う。
重要な仕事ほど、最初はタスクに見えない
厄介なのは、本当に重要な仕事ほど、分かりやすいタスクの形をしていないことだ。エンジニアでいえばチケットやIssueに切るほどでもないようなタスクなのだ。
それらは
このプロジェクトで本当に解くべき問題は何か
今のアーキテクチャを維持してよいのか
チームのどこに属人化があるのか
今後増える案件に、現在の体制で対応できるのか
自社で持つべき領域と、ベンダーに任せる領域はどこか
といった問いで、プロジェクト中はずっと付き纏い、もっと言えば終わっても出てくる問題だ。
期限も曖昧で、誰かから催促されるとは限らない。そうなると、目の前の作業が増えると後回しになってしまう。。しかし、本当に状況を変えるのは、こうした問いに答えることだったりする。
忙しい日にこの本を読み返すと、自分が簡単に終わらせられる仕事へ逃げていないかを考えさせられる。
この本は、仕事を速く終わらせる本ではない
ここまで、結果的には効率的になるような文言で『イシューからはじめよ』をまとめてきたが、単純な時短術やタスク管理の本ではない。
仕事を速く片づける方法だけを求めて読むと、少し期待とは違うかもしれない。
むしろ、
その仕事は、本当に今やる必要があるのか。
と、手を止めさせる本だと思う。忙しいときに立ち止まるのは、少し怖い。焦りもあるし、タスクはこなしているように見える。ただし、それは感覚なだけ。
本来考えるべき内容やその時間は、外から見ると何も進んでいないようにも見える。それでも、間違った問題を速く解いても、仕事の価値は高くならない。
この本が扱っているのは、解の質だけでなく、答えを出す価値がある問題を選ぶことで、価値あるアウトプットにつなげる考え方だ。
忙しい日にこそ、最初に一つ問いを置く
この本を読んだからといって、忙しさがなくなるわけではない。突発的な対応もあるし、すぐに処理しなければならない仕事もある。すべてのタスクについて、じっくり問題設定をする時間もない。
それでも、仕事を始める前に一つだけ問いを置くことはできる。
今日、答えを出すことで最も状況が変わる問題は何か。
あるいは、
今からやろうとしていることは、問題を解いているのか。それとも、解くべき問題を見極めているのか。
この問いを入れるだけで、朝一番に開く資料や、最初に声をかける相手が変わることがある。僕自身、気がつけば目の前のタスクを処理することに集中してしまうからこそ、何度も読み返す。
忙しいときほど、速く走り始めるのではなく、どこへ向かうのかを先に考える。
『イシューからはじめよ』は、その当たり前だけれど難しいことを、何度も思い出させてくれる一冊だ。
今回紹介した本
『イシューからはじめよ――知的生産の「シンプルな本質」』
Amazonで確認する：
