すのふら

すのふら

日々の備忘録

思考を整理して問題を洗い出すための技術を学んだ『考える技術・書く技術』を読んだ

下に人が増えてきてなんとなくそう思ったではなくて、もうちょっと課題を奇麗に棚卸したり他の人に伝達するのかということを考えているので、まずはこの本だろっていうことで読んでみた。

考える技術・書く技術―問題解決力を伸ばすピラミッド原則

考える技術・書く技術―問題解決力を伸ばすピラミッド原則

全体の構成としては大きく3点。

  1. 書く技術
  2. 考える技術
  3. 問題解決の技術

この本は基本的な考えとしては

  1. 各メッセージは一つの考えの下にピラミッド構造である
  2. どのレベルであれメッセージは下位グループの要約である
  3. 各グループのメッセージは常に同じ種類である
  4. 各グループ内のメッセージは常に論理的に順序つけられている

というもの。


概論を書いてから例を示して、そこから一つの要素ごとに詳細に記載されていて、割と親切に書いてくれていると思った。
例を2、3個挙げて説明を書いてくれるので全然わからないみたいなことにならなかったかなー。

第一章の書く技術で躓いてしまうと結構後半きついので、第一章はなんとなくでも全体像はちゃんと把握しておいたほうがいいかも。

親切に書いてくれるんだけど、例のページが結構多かったり色々なパターンを書いてくれているからか時々度の話をしているのかよくわからなくなることもあった。
前頁に戻ったり、今どの話を読んでるんだっけと理解するのにかかってちょっと読むのに時間がかかった。

状況→複雑化→疑問とピラミッド構造がどう紐づくのかよく分からず、第一章に戻ったりした。


本自体はかなり面白くて、第三章の問題解決の技術はなんとなくいつも思っていることが明記されていて、なるほどなって思った。

  1. 問題がありそうか(あるいは改善の機会がありそうか)
  2. 問題はどこにあるのか
  3. 問題はなぜ存在するのか
  4. 問題に対し何ができるか
  5. 問題に対し何をすべきか

この5点って普段仕事していても結構聞かれたり判断する内容だったりするので、面白く読めたかなーと。

以下、付箋張っていたところをまとめたメモ


ピラミッド構造の考え方

ピラミッド構造をいかに早くやるかという点において、思考の整理をしなければならないけどそれも含めピラミッド構造に盛り込んでしまおうというアプローチは手っ取り早くていいなと思った。

PMO向け顧客向けに資料作っているときも、1シートにメインメッセージひとつあって、それにたいしてぶら下げて理由を説明していく。
また次回に向けた障害の棚卸するときも、どこを修正すべきか障害から想定していく必要がある。

それってトップに主題があって、その下にぶら下がる「何故なら」が複数個ぶら下がっている。

そのぶら下がっている「何故なら」は、主題に対しての事実→疑問に至る出来事→疑問→主題の流れからやってきている。

f:id:snofra:20180123064332j:plain*1

ざくっとした例としては、
テスト実施中に障害が発生した
(主題に対しての事実)

次回は同じような障害は発生させないようにすべき
(疑問に至る出来事。え?なんでそう思うの?みたいなところ)

どのように障害を直すべきか?(どのような障害が発生したのか?)
(疑問)

手順書の修正をすべきだ
(主題)

障害A、障害B、障害C……
(何故なら)


「主題に対しての事実」と「疑問に至る出来事」は経験的にPMOとか顧客サイドに言われそうなところを想定するのがいいのかなーと。

これちゃんとしている人はある程度は、特に疑問に至る出来事というか、なんでそう思うの?って言われたときにちゃんと想定しているので、ここは重視して考えるべきなんだなって思う。


「何故なら」の部分は重複なく漏れがないようにMECEで体系化しないといけない。

これが漏れると、手順書のここは奇麗になったけど他が適当のままだったみたいになりかねない。

障害もたまたま発生しなかったのものもあるので、現在起きている障害から「テストデータ作成」なのか「テスト実施」なのか分類分けしておかなければならない。
ふたつの要素が重複しているものはきちんと分割してピラミッド構造にはまるようにしてあげることが必要。


問題ってなにか

今まで障害等で判断する基準はこの5点だったなと思う。

  1. 問題がありそうか(あるいは改善の機会がありそうか)
  2. 問題はどこにあるのか
  3. 問題はなぜ存在するのか
  4. 問題に対し何ができるか
  5. 問題に対し何をすべきか

問題って、テスト実施中に障害が発生した(主題に対しての事実)なんだけど、これって結局何か期待に対してうまくいかなかったという状況であって、じゃあ何を期待していたんだっけ?みたいなことを考えてみる必要がある。

テスト実施していた時も何かしらの期待結果があるんだけど、何かしらの問題があってそもそもどうあればよかったんだっけ?からスタートするのでわかりやすい。

①じゃあ今の何が良くなかったの?(R1)
 →テストデータorオペレーション
②代わりにどうなっているといいの?(R2)
 →想定結果の通りに結果を出す
③R1とR2の解決案
 →テストデータを直すorオペレーションを見直すべき
④じゃあテストデータを直すために「どうするのか」

このどうするのかは上のピラミッド構造の「何故なら」に置き換わってどうするのかで考えていく。