この記事は、英語ブログエントリ"How to make it better ? - Extracting implicit knowledge via GSN"の日本語訳です。
 -あまりうまくない「かぶと」-折り紙をうまく折る
折り紙には上手い人とそうでない人がいます。また、外人に折り紙を教えると、手順はうまく伝えることができても、あまり奇麗にできることはありません。折り紙をうまく織るには、「ここは角がしっかり合うように気をつけて」などというコツをうまく伝える必要があります。
ソフトウェア開発においてドキュメント、コード、報告書などをレビューしていても、同じ悩みがあります。作成する手順、プロセスだけではだめ。この小記事では、折り紙を例題に、このあたりのことを考えてみたいと思います。
折り紙の「かぶと」１つ１つのステップは難しくありません。でもステップにはコツやポイントがあります（暗黙知と呼ばれるものですね）。これらが最後の出来映えを大きく左右するのです。料理に似ていますね。レシピには「材料」と「手順」が書かれていますが、 料理が上手な人はそれ以上のことを知っているようです。
 - この違いはどこからくるのか -GSN を使って手順とコツを同時に記述する
デンソークリエイトの小林さんが、GSNを使って折り紙を折る手順を書きながら、同時にこの「コツ」を書いて行くという手法を試しています。これを、「かぶと」の例でやってみます。
 -「かぶと」をうまく折るGSN -GSN(Goal Structuring Notation)は議論の構造を可視化する手法です。エンジニアリング領域では、機能安全のセーフティーケース（ISO61508, ISO26262等）において「このシステムは安全ですよ、なぜかというと、、、」と主張を指示する議論構造と証拠を示す記述などに使われます。（詳しくは「GSN解説」などを参照）
では、この「折り紙GSN」を解説してみます。
- ゴールは「奇麗なかぶとを折る」こと。トップの黄色の ■ ゴールノード (G1)で示している。
- トップゴールはステップ毎のサブゴール(G2-G9)に分解される。サブゴールも黄色 ■で、この「分解戦略」を、青色の ■ 戦略ノード(S1)で示している。
- 各サブゴールの結果は緑の■ 証拠ノード(Sn1-Sn8)で絵として示している。
- そして、Tipsというかノウハウというか「コツ」が、ピンクの ■ 文脈ノード (C1-C5)として、キーとなるステップに書き加えている。
技術レビューにGSNを活用
折り紙のGSNを作る際には、同僚たちに折り紙を折ってもらい、それぞれのステップで「気をつけていること」を聞き出したそうです。手順の背後にある、この知識（「気をつけていること」）が折り紙の出来映えを大きく左右するのです。そしてそれを、抽出して、明文化しています。
小林さんはGSNを使って、社内の ソフトウェア開発におけるレビュープロセスを改善したい と考えています。この折り紙の例は、ソフトウェア開発にどうやってマッピングできるでしょうか？
開発プロセスを作って行くこと、その過程でノウハウを抽出すること、そしてそのノウハウを再利用可能な形にし、社内の資産にすること。
これをGSNを使ってトライしているのです。
詳しくは、次のYouTube３分ビデオをどうぞ。
技術レビューにおけるGSN, D-Caseの現場活用法(1)〜レビューの前提となる基準を作る
続編は、こちらです。
「他の人も納得できる折り紙の「コツ」の引き出し方」 Qiita
小林さんは、組込みソフトウェア開発の現場で、ソフトウェアエンジニアリング、D-Case(Dependability Cases)の実践者です。名古屋市在住。
（平鍋）