「定時で成果」を読んだ。
その中で、仕事を「未知と既知」に分ける、という考え方がシンプルで、明確で使いやすいな〜と思えた。
同時期に、「システム開発と『具体と抽象』」と「鬼速PDCA」も読んでつながる部分がありそうだなと感じたので整理する。
PR🛒定時で成果AmazonPR🛒システム開発と『具体と抽象』AmazonPR🛒鬼速PDCAAmazon
既知をみつける
手が止まるのは、だいたい未知のまま着手しているから。
未知のものも分解していけば、既知のことが見つかることがある。
既知のことは経験を活かしてやれば良く、未知のものに対して対策していく。
分解しないと既知を見つけることは難しくて、荒い状態からこれは既知だとして手を付けられるのであればよほどいつもと同じ型のタスクであるか、抽象的な状態から全容を掴むだけのスキルがあるかのどちらかでは。
後者の場合は、たぶん困っていないと思う。
既知をみつける作業
- 仕事の5要素（目的・インプット・成果物・関係者・効率や進め方）で埋めていく（定時で成果）
- 一段目だけMECEを意識して、切り方が難しければプロセスで切る（鬼速PDCA）
- 要因が見えないときは、縦に深く掘るより横。だいたい視界の外にある（鬼速PDCA）
分解しても既知が出てこない時
課題を細分化しても解決策が見えないときは、課題設定そのものがズレている可能性がある。
以下あたりがポイントになりそう。
抽象度を上げて本質を見分ける
（具体と抽象本に記載のあったサーバー容量の話でいうところの）「サーバー容量を増やしたい」という具体的な依頼に対し、一段抽象度を上げて「本当に困っているのは何か（＝容量不足）」を見直すことで、「発生量を抑える」といった別の解決策が見えてくる。
未完成の具体物で認識をすり合わせる
人は抽象的な論理だけでは判断できないので、アジャイルやプロトタイピングのように、未完成の具体物を早くぶつけてフィードバック（「そうじゃない」という反応）を得ることで進むべき方向が明確になる。
未知の仕事に対処する
未知への対応としては、以下のあたり。
- その仕事は分解しきっているか？
- より分解していくための手法を知る
- 分解を手伝ってくれる仲間を探す
- 未知の仕事、既知の仕事に対する進め方、時間のかけ方、役割分担を決めておく。
- 想定や仮説をたてる
- 何を期待されているのか、何を求められているのか
- 助けてもらう
未知・既知にかかわらず、どう対応するのか決めておくところが良い。
未知の仕事に対しては、気づくとただ悩んでしまって、何も進んでいないということがよくある。
「鬼速PDCA」に、要因を精神面に求めると、なんとなくひと段落した感じがして思考が止まってしまう、という話があった。
悩んでいる時間は、だいたいこれだと思う。
とにかく早く回して、間違っていたらやり直せばいい、というほうが向いている。
組織知としてためていく
そして、最後に振り返りをして、未知から既知に変わったことを知識としてまとめておく。
そうしたら組織知となって、組織としてできることが増えていく。
できることが増えるだけじゃなくて、既知が増えたぶん、新しい未知に取り組む時間ができる。
自分の知っていることをためていく、と思うと本当にこれ必要かな？と思うことがあるけれど、組織にとっての「既知」を増やしていくとすると、シンプルに考えられそう。