【第8回】視覚化して考える｜実務三年目からの発見力と仮説力

帰納的な推論 と 発見的な推論(アブダクション) は、私たちがソフトウェア開発の現場/実務で（知らず知らずにでも）駆使している思考の形です（それどころか日々の暮らしでも使っています）。

それほど“自然な”思考の形ですが、どんな考え方で、どんなところに注意すると質の高い思考ができるのか、基本知識を押さえておくと実務のレベルアップにつながります。

＜実務三年目からの発見力と仮説力　記事一覧＞※クリックで開きます

今回は仮説の検討を支援するのに使える図式化表現(表記法)をいくつか紹介します。

図式化に馴染んでいる人はいつも使っているものや気に入ったものを応用すればよいのですが、ふだんあまり図を描かない人は参考にしてみてください。

もちろん、ここに挙げた以外にもアブダクションを支援する“ツール”はたくさんあります。自分に合うものを探しましょう。

なお、紹介では概要のみ記しています。詳細は当該表記法の文献等に当たってください。

グラフ、ツリー、フロー

○(丸)を描いて、○と○を線で結んだだけの図(図8-1)も、グラフと呼ばれる立派な図形です（「グラフ」は数学の用語）。

○を ノード や頂点、線を エッジ や辺と呼びます。（念のため、ノードは○(円形)でなくても問題ありません）

エッジでつながれたノードの並びを経路と呼びます。
図8-1の(b)のように、辿っていくと始点に戻る経路は 閉じている(閉じた経路) といいます。

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

問題となっている事象やその原因(候補)、付随する事象などをノードにして、エッジでそれらを結べば、「原因と結果の関係を示す図」の出来上がりです(図8-3)。

考え始めや、考えがまとまらない時などは、事実を集めながらこんな図形でも描いて眺めてみるとよいでしょう。
問題の特徴が見えてきたり考えるべきことの焦点を絞れたりして、別の図式化の方が適しているならそちらに切り替えればよいわけです。

ツリー(木)、樹形図 も誰もが知る図式でしょう。
ひとつのノードを“根っこ(ルート、root)”として、ルートから他のすべてのノードがつながっているように表した無向グラフです(図8-4)。

図8-1 (b)、図8-3はツリーではありません。

ツリーはノード間の階層関係（親・子、上位・下位など）を表すのに向いています。

ソフトウェア故障の説明仮説の検討では、故障(結果の事象)をルートに据え、原因として考えられることを枝から葉に向かって書き出しながら詳細を考える、といった使い方ができます(図8-4a)。

注意点としては：

ツリー系の表記法にはロジックツリー、マインドマップなどがあり、それぞれに適した用途や描き方があります。

原因から結果に至る筋道を描くなら、これもおなじみのフロー図があります。これもグラフの親戚です。

グラフそのままとしても描けますが、
フロー系の表記法にはアクティビティ図、フローチャートを始め、表現力が高いものが多くあります。

フロー系の表記を利用する場合には、「ソフトウェアの実行の詳細な流れや動作」に注意を奪われないように気をつけましょう。

「原因から結果に至る過程」と「ソフトウェアの詳細な動作」は一致しないこともよくあります。

事象間の因果関係の解明を支援するための図式化表現に連関図があります(図8-6)。
（連関図は新QC七つ道具のひとつです）

注意点としては：

結果事象に直結するノードには一次原因として、事象を引き起こした直接の原因を配置する。
一次原因に抜け漏れ・重複がないようにする
一次原因から、それを引き起こした原因という風に、結果から原因を逆向きに考える
原因から結果へのつながりをよく考える（ひとつの原因から複数の結果、複数の原因からひとつの結果）
主原因（支配的な原因や、対策を打つべき原因）が必ずしも末端のノードにあるとは限らない。
問題が生じても、それを無化したり回復する仕組みを設けて対処すればよい場合もある

ソフトウェアの故障や不具合でも、複数の要因が絡み合ったり連鎖したりした結果であることはしばしばあります。
特に人的要因が絡んでくる場合にはこの図式化は適しています。