「1日の答え」

昨日で本業は、仕事納めをしたので今日から冬休みに突入した。

今年を振り返るというわけではないが、今年はコンサルっぽい本を結構読んだ気がしている。
いわゆる「課題解決」みたいなのは苦手ではなかったがもっと再現性のある形で手札として使えるようにしたいと思ったのがきっかけだったかもしれない。
コンサルっぽい本というのは補足としておくと例えば、イシューからはじめよ (これは今年読んだわけではないが) のような本を指す。

その中でも 完全無欠の問題解決 という本は今年読み返す機会も何回かあり、特に印象的だった 「1日の答え」 という考え方についてメモを残したい。

この言葉が登場するのは、第4章の「作業計画を立てる」の中で以下のように本文中では述べられている

プロセスのどの時点であっても、問題について今知っていることを述べることで、思考が非常に明快になる。これはどのような理解が生まれつつあるのか、答えと私たちの間にはどんな未知のものが立ちはだかっているのかを明確にするのに役に立つ。私たちはこれを「1日の答え」と呼んでいる。

自分はコンサルの人間ではないが、これを自分の環境に置き換えて解釈するとつまりは 「常に何が課題なのかを言語化すること」 と言っているのだと思う。言い換えると 「あなたから見て現状のプロジェクト (ここはチームでもコードベースでもプロセスでも対象はなんでも良い) の課題はなんですか?」 と誰か (例えばマネージャーとか同僚とか) から突然聞かれたとしても答えることができる状態にしておこうということなのだと捉えている。

一見すると常に何かしらの仮説を持った上で行動していこうと主張している イシューからはじめよ と同じようなことを言っているのだが、 「1日の答え」 はより具体的に 「今得ている情報の中での局所的な最適解でもいいから仮説として成立するほどの言語化をせよ」 と言ってるように聞こえた。

改めて考えてみると、確かに現代において任意の事柄に対して「全ての情報」を得るということは不可能に近いだろう。
ある集団の中で一番詳しいくらいはあるかもしれないが結局上には上がいるし、その上の人でさえ例えばプロジェクトやプロダクトに途中から参画していたりするわけなので歴史の一部分しか切り取ることはできない。

となった時にこの 「1日の答え」 というのを持ち続け、更新し続けたものというのが自分がその時点で出し得る最良のアウトプットということになる。

この考え方に至ってからは、「課題」を考えたり深堀りするときに 「誰にいつ聞かれても何が課題だと自分は思っているのかを言語化を試みてみる。言語化できないと感じる部分はきっと無意識的に情報が足りないと感じている部分だろうからその情報を知ってそうな人に聞きに行こう」 という行動を割と癖として実行できるようになってきた。
その結果あんまり、「解決の糸口が見えない」とか「道が開けない」と思う場面が圧倒的に少なくなった。

冒頭でも書いたように課題解決が苦手というわけではないので、もちろんこれまでも自然とそういう行動をしていたのだろうけれど意識的に再現性を持ってこの行動を取れるようになったのは大きな収穫だったなとこの1年感じたのであった。

というわけでクリスマスケーキをこれから受け取ってくる

(追記)
「1日の答え」 の「1日」がキャッチーなので毎日そういう時間を設ける必要があるのか?というコメントをもらったので自分の考えを補足したい。

個人的には、この「1日」は「常に」とか「継続的に」くらいの意味だと思っていてどちらかというと、課題を常に言語化できていると以下のような場面においての現在言語化しているものとの ズレ を早期に察知することができるという部分が非常に重要だと感じている

また課題の粒度に関しても「Pull Request を作っている最中にリファクタリングしたい箇所が出てきた」という1日以下の短期のものから「人数が徐々に増えていることによって組織の役割の再定義が必要」という到底1日ではズレが修正できないようなものまであると考えている。

なので補足するのであれば 「ありとあらゆる粒度の課題について仮説を持ち続け、情報が増えたり、アクションを実行する中で少しでもズレを察知したのであれば立ち止まって言語化を試みて仮説をアップデートし続ける」 ことが重要という解釈をしている。