動機
- ソフトウェア開発プロセス内で要件定義のレビューの通り具合が悪いので改善したい
- チーム全体のテクニカルライティング力を向上させるために、横展開出来るスキルを身に着けたい
2 章 考えをカタチにする
3 章 ピラミッドを作る
論理的思考の基本
帰納法は複数の前提から一つの結論を論理的に導き出す思考法。この時の結論は推測になる。複数の前提から導き出すということは、前章で話した「グループから要約メッセージを探す」ために使えそう。
前提には「同じ種類の考え」が並ぶ。「同じ種類の考え」とは、
- 主部が同じ -> 述部を推測
- 述部が同じ -> 主部を推測
- 意味するものが同じ -> 意味するものが結論となる
の 3 パターンがある。それぞれの考え方で推測できるものが変わる。正しく結論を推測出来ているかどうかは、結論と前提を接続詞を使って繋げて読んでみると良い。「なぜならば」や「具体的に言うと」のような接続詞で繋げられないなら、構造を誤っている可能性がある。
また、同じ接続詞で繋げられる前提は同じグループに分けられる可能性がある。
演繹法とは、絶対に決まっている前提を基に結論を導き出す考え方。例えば、「馬は哺乳類だ」「哺乳類は心臓が一つある」という前提から「馬の心臓は一つだ」のように考える。
ビジネスの世界で絶対に決まっている前提というのがあまりないので帰納法が使われることが多い。正しいと思っている前提も実は間違ってしまっていることもある。例えば、過去は成り立ってはいたが現代では成り立たないようなもの。
演繹法では前提を「本当に正しいと言えるのか」と自問するのが良い。
ピラミッドはトップダウンで考えるくらいがちょうどよい。トップダウンで考えるということは、読み手の Q を想像し、主メッセージを仮置きするという事。そうしておけば根拠を集めやすい。集めたうえで主メッセージが誤っていれば修正すればよい。考える過程ではトップダウンとボトムアップを行ったり来たりするのが良い。
ピラミッドの縦は「論理の帰結」を表し、横は「論理付け」を表す。
4 章 文章で表現する
OPQ 分析により読み手の目的を明らかにするところから始まるのだけど、これはテクニカルライティングでどう応用出来るのだろうか。この書籍では何かしらの調査依頼があって、その報告書としての文章をまとめるシナリオが想定されている。でもエンジニアってそういうパターンあまりないかもなぁ。
例えば、インシデントの影響範囲を知りたい、プロダクト改修の影響は範囲を知りたい、とかはまぁあるだろう。でも直近抱えているのは要求定義と要件定義のライティングで、それって誰かに依頼されてやってるわけではないからなぁ。
アーキに共有する内容としては、
この辺が伝わればよかろうと思ってやっているが、果たしてどうなのだろう。これらをピラミッドの構造のように分析できていると思ったことはない。開発プロセスの各段階で要求される成果物に対する目線合わせをしてくださいって事なのかもしれない。
「しりてが」接続詞は意識的にやめる。
普段から大なり小なりの調べ物はしているので、OPQ 自体は無意識にやっているはず。あとはこれを人に伝えるって事を目的に実践してみたいな。ブログなり技術調査なりで。
