
帰納的な推論 と 発見的な推論(アブダクション) は、私たちがソフトウェア開発の現場/実務で(知らず知らずにでも)駆使している思考の形です(それどころか日々の暮らしでも使っています)。
それほど“自然な”思考の形ですが、どんな考え方で、どんなところに注意すると質の高い思考ができるのか、基本知識を押さえておくと実務のレベルアップにつながります。
<実務三年目からの発見力と仮説力 記事一覧>※クリックで開きます
今回は仮説の検討を支援するのに使える図式化表現(表記法)をいくつか紹介します。
図式化に馴染んでいる人はいつも使っているものや気に入ったものを応用すればよいのですが、ふだんあまり図を描かない人は参考にしてみてください。
もちろん、ここに挙げた以外にもアブダクションを支援する“ツール”はたくさんあります。自分に合うものを探しましょう。
なお、紹介では概要のみ記しています。詳細は当該表記法の文献等に当たってください。
グラフ、ツリー、フロー
グラフ
○(丸)を描いて、○と○を線で結んだだけの図(図8-1)も、グラフと呼ばれる立派な図形です(「グラフ」は数学の用語)。
○を ノード や頂点、線を エッジ や辺と呼びます。(念のため、ノードは○(円形)でなくても問題ありません)
エッジでつながれたノードの並びを 経路 と呼びます。
図8-1の(b)のように、辿っていくと始点に戻る経路は 閉じている(閉じた経路) といいます。

矢印のついた線を使うと、向きのあるグラフ(有向グラフ)になります(図8-2。矢印がない図8-1は 無向グラフ)。
有向グラフでは、経路は矢印の向きに従います。
順序や依存関係、原因・結果の関係などを表わすのに都合がよいです。

問題となっている事象やその原因(候補)、付随する事象などをノードにして、エッジでそれらを結べば、「原因と結果の関係を示す図」の出来上がりです(図8-3)。
考え始めや、考えがまとまらない時などは、事実を集めながらこんな図形でも描いて眺めてみるとよいでしょう。
問題の特徴が見えてきたり考えるべきことの焦点を絞れたりして、別の図式化の方が適しているならそちらに切り替えればよいわけです。

ツリー
ツリー(木)、樹形図 も誰もが知る図式でしょう。
ひとつのノードを“根っこ(ルート、root)”として、ルートから他のすべてのノードがつながっているように表した無向グラフです(図8-4)。
- 閉じた経路はない
- ツリー上の任意のふたつのノードをつなぐ経路はただひとつ
図8-1 (b)、図8-3はツリーではありません。

ツリーはノード間の階層関係(親・子、上位・下位など)を表すのに向いています。
- 構成要素や概念を段階的に詳細化する
- 主題(ルート)を特定の観点に沿って掘り下げる
- 主題から発想を漸進的に広げていく
ソフトウェア故障の説明仮説の検討では、故障(結果の事象)をルートに据え、原因として考えられることを枝から葉に向かって書き出しながら詳細を考える、といった使い方ができます(図8-4a)。
注意点としては:
- ひとつの階層で挙げる事項の観点を統一する
(たとえば、事象の種類、発生部位、etc.) - ひとつの階層で挙げる事項の見落とし・重複がないようにする
- 枝や葉で挙げる事項が階層関係を飛び越えないようにする
(あるノードの子ノード(以下)に、そのノードの親/上位の項目を書かない)

ツリー系の表記法にはロジックツリー、マインドマップなどがあり、それぞれに適した用途や描き方があります。
フロー
原因から結果に至る筋道を描くなら、これもおなじみのフロー図があります。これもグラフの親戚です。
グラフそのままとしても描けますが、
フロー系の表記法にはアクティビティ図、フローチャートを始め、表現力が高いものが多くあります。

フロー系の表記を利用する場合には、「ソフトウェアの実行の詳細な流れや動作」に注意を奪われないように気をつけましょう。
「原因から結果に至る過程」と「ソフトウェアの詳細な動作」は一致しないこともよくあります。
連関図
事象間の因果関係の解明を支援するための図式化表現に連関図があります(図8-6)。
(連関図は新QC七つ道具のひとつです)
- 結果事象(解決したい問題)に多くの事象(原因)が関係しており、事象どうしの因果関係が複雑と見込まれる状況で、
- 事象間のつながり、因果関係を図示し、全体を俯瞰しながら主原因を検討する場合に適しています(プロセス改善時の原因分析など)。

注意点としては:
- 結果事象に直結するノードには一次原因として、事象を引き起こした直接の原因を配置する。
一次原因に抜け漏れ・重複がないようにする - 一次原因から、それを引き起こした原因という風に、結果から原因を逆向きに考える
- 原因から結果へのつながりをよく考える(ひとつの原因から複数の結果、複数の原因からひとつの結果)
- 主原因(支配的な原因や、対策を打つべき原因)が必ずしも末端のノードにあるとは限らない。
問題が生じても、それを無化したり回復する仕組みを設けて対処すればよい場合もある
続きを読むにはログインが必要です。
ご利用は無料ですので、ぜひご登録ください。