SECIモデルはパターンランゲージの作成プロセスに似ている～第52回SEA関西プロセス分科会の感想 #seaagile

第52回SEA関西プロセス分科会で、平鍋さんの講演「アジャイル開発とスクラム」を聞いてきた。
感想をラフなメモ書き。

6月7日 第52回 SEA関西プロセス分科会

第52回 SEA関西プロセス分科会-SEA関西

【1】参加者は70人余りでおそらく過去最高の人数ではないだろうか？
講演内容も素晴らしかったし、1時間半の質疑応答は引っ切り無しで、参加者もアジャイルにとても興味を持っていることがよく分かった。
平鍋さんは、関西はアジャイルで独自の活動をされている人が多い、と言った後で、「わかりやすいアジャイル開発の教科書」と一緒に「チケット駆動開発」の本も紹介して頂き、嬉しかった。

平鍋さんの講演では、「アジャイル開発とスクラム」の内容紹介よりも、野中先生の経営理論からアジャイル開発のスクラムが生まれた経緯を中心に話された。

【2】スクラムという概念は、野中・竹内先生の論文「The new new product development game」から生まれた。

Newが2つある理由は、2つ目のNewは「新製品開発」の「新」、一つ目は「新しい」という意味らしい。
従って、論文は「新しい新製品開発」という日本語タイトルになる。
つまり、野中先生は、80年代の日本企業の開発プロセスを研究して、生産ラインに乗らないような新製品開発について分析していたわけだ。

論文では、3種類の開発プロセスが説明されている。
一つ目は、NASAの開発プロセスで、品質ゲートが設けられていて、ある工程で品質をクリアしたら、次の工程へドキュメントと一緒に送られる手法。
ウォーターフォール型開発と呼ばれていないが、まさにそれと同じ。

2つ目は富士ゼロックスの開発プロセスで、品質ゲートがなく、工程の間の切れ目が曖昧になっている。
3つ目はホンダの開発プロセスで、前工程が後工程に重なっている。
つまり、前工程に関わった人はその後の工程でも関わっていることになる。

その手法はアジャイル開発と呼ばれていないが、まさにそれと同じ。
つまり、要件定義や設計で携わった人は開発やテストでも一緒にやり、製品に関わる。
仕様書を下請けに回して、それでおしまいという手法ではないのだ。

野中先生は、そのプロセスの絵を最初は「刺身モデル」と呼ぼうとしたらしい。
前工程のプロセスが後工程に重なる姿が刺身に似ているからだ。
でも、もっと良いネーミングがないか考えて、ラグビーの「スクラム」のように、パスを出す人もパスを受ける人も一体化して前へ走るイメージで「スクラム」という言葉を持ち出したらしい。
だから「スクラムマスター」ではなく「刺身マスター」と呼んだかもしれない、と。

【3】講演で興味を引いたのは、「SECIモデル」と「フロネシス」。
僕は野中先生の本を何度かトライしたが、難しすぎて、理解できなかったが、今日の話を聞いて、何となく引っかかりはつかめた。
SECIモデルは、暗黙知から形式知、形式知から暗黙知へ変わる知識創造のフレームワーク。

知識創造理論：SECIモデル : NED-WLT

暗黙知は例えば、直観や共感。マニュアルにできないもの。
例えとして、自転車の乗り方。
自転車は本で教えても、実際に乗ってみて、転んだり、トライしなければ身につかない。

形式知は言葉にできる知識。
ポータブルな知。
コンテキスト非依存、他人に伝播可能という2つの特徴がある。

SECIモデルは、まず経験(共同化)して、それを言葉にして(表出化)、別の知識と連携して(連結化)、自分の中に取り込む(内面化)というサイクルを繰り返す知識の発展の理論。

この話を聞くと、KPTによるふりかえりと同じモデルであるように思える。
KPTでは、Problemで現状の問題点や課題が出てきて、その問題を解決しようと色々な解決案がTryに出てくる。
そのTryを試してみて、次回のふりかえりで、うまくいったTryはKeepに貯められ、うまくいかなかったTryはProblemで一つの経験として貯められたり、もう一度やり方を変えてTryを試す。
その後、問題解決するたびにKeepにたくさんのノウハウが貯められていき、そのノウハウがチーム全員で当たり前となれば、暗黙知となってKeepから消えていく、という流れ。

つまり、まずは問題解決を試して経験し、経験した結果は実践知としてKeepに貯められ、他の知識と結びついて、当たり前になれば暗黙知として水面下に沈むという流れになる。

【4】知には「暗黙知」「形式知」「実践知(フロネシス)」という3つの種類があると、アリストテレスは言ったらしい。
実践知は、フロネシス - Wikipediaによれば「個別具体的な場面のなかで、全体の善のために、意思決定し行動すべき最善の振る舞い方を見出す能力という意味らしい。
僕の理解では、実践知とは、状況(コンテキスト)に応じて知恵を使うことができる能力と思っている。

野中先生は、フロネシスを伴ったリーダーシップが重要で、そのような人が、SECIモデルを組織内で実践していくと考えているらしい。

実践知（Practical Wisdom）とは？：アリストテレスがポジティブ心理学に出会う | 仕事の心理学

フロネシス・リーダーシップ（野中　郁次郎教授） eqpartners/ウェブリブログ

つまり、フロネシス(実践知、パターンランゲージ)を伴ったリーダーシップを持つ人(スクラムマスター)は、実践知を組織化する能力(開発プロセスを進化させる)を持っている。
平鍋さんは、その構造は再帰化みたいですよね、コンポジットパターンですよ、と言っていた。

そのようなフロネシスを生み出すには場(ba)が大事と言う。
つまり、二人の人が互いに自分の意見をぶつけたり、議論したり、共感しようとしたりして、お互いの力の相互作用が生まれる場が発生し、実践知が生まれていく。

この場というアイデアは、量子力学のfieldという概念に似ている。
電子や粒子が存在すると、その周囲に電場や磁場が勝手に作られ、波として力の相互作用を及ぼす。
場であるからには、引力もあれば斥力もある。
つまり、相互に惹かれ合う場合もあれば、相互に反発し合う場合もあるだろう。

そして、海兵隊のように陸軍・海軍・空軍のスキルを持つ専門的な人達が集まってチームをなして、プロジェクトに取り組む。
それは、スクラムが、ユーザ・マネージャ・開発者を巻き込んだチームとして、プロダクトオーナー・スクラムマスター・チームの役割を持つスクラムチームと呼び直して、ソフトウェア開発に取り組むやり方に似ている、と。

【5】その実践知はコンテキスト依存であるという平鍋さんの話を聞いて、まさにパターン言語そのものではないかと思った。

パターン、Wiki、XPは良書: プログラマの思索

Coplienの開発工程の生成的パターン言語を読むpart1: プログラマの思索

パターンランゲージの形式と正当性: プログラマの思索

パターン言語は実践知や経験知を一つの形式でまとめたカタログ。
その経験知は、パターンとして他人にその意味を共有することができる。

コプリエンのパターンの形式は下記のスタイル。
まさに、野中先生の言う実践知(フロネシス)とぴったり合うのではないだろうか？

パターン名称(Pattern Name)：
問題の解決の仕方などが直感的にイメージできるような名前。

別名(Alias)：
上記のパターン名称の別名。すべてのパターンが別名を持っているわけではない。

問題(Problem)：
解決したい問題。あるべき課題。

コンテキスト(Context)：
問題が発生しているまわりの状況や、問題を解決しようとしている人が置かれている状況。
現実と理想のギャップ。

影響する事柄(Forces)：
問題解決に際して影響を与える事柄や考慮しなければならない事柄。

解決策(Solution)：
問題解決策。

結果として生じるコンテキスト(Resulting Context)：
問題を解決したことによって生じる状況。

論理的根拠(Rationale)：
パターンが効果があることの論理的な根拠。

フロネシスの体系化がパターン言語であるとすれば、複数のパターンを組み合わせることで、パターンでは語られなかった新しい性質が生み出されるという、パターン言語の最大の特徴が出てくるが、それはどのように解釈されるのか？
つまり、生成的(generative)というパターン言語の特徴だ。
例えば、XPのテスト駆動や継続的インテグレーションなどのプラクティスは、それ自身では品質や効率について何一つ語っていないのに、それらプラクティスを組み合わせると、従来のWF型開発よりも品質が良く、効率も良くなるという特徴を持つ。
この特徴こそが、XPの面白い部分であり、アジャイル開発を経験して成功したことがなければ分からない部分だと思う。

パターン言語の生成的(generative)という特徴は、SECIモデルやフロネシスではどんな文脈で説明できるか？
平鍋さんに質問してみたものの、僕の理解ではよく分からなかったけれど、パターンの生成的な特徴は、SECIモデルの「連結化」に相当するような気もしている。
複数の実践知、経験知を組み合わせると、今までになかった新しい特徴が出てくるという部分に相当するのではないだろうか？

すると、SECIモデルとパターン言語は、それぞれの概念やプロセスがどのように対応していて、どの部分に差があるのだろうか？

チケット駆動開発をパターン言語として考え直すアイデアは、ちょっと止まっていたけれど、新しい考え方を取り入れることができて刺激になった。

【6】平鍋さんの話を聞いてみて、「スクラム」といい「かんばん」「リーン」などの概念を日本人が生み出し、それを欧米人が理解して、ある意味では自分たちの都合の良いように取り入れて、「アジャイル」という新しい言葉で提唱して、日本に逆輸入されたことに、正直悔しいなあと思っている。

何故、日本人はそのアイデアを生み出したにもかかわらず、日本のソフトウェア産業に適用して、発展させようとしなかったのか？
アジャイルといい、DOA(データモデリング)や品質管理の技法と同じく、日本独自の歴史を持ちながらも、そのアイデアは僕ら開発者に全く生かされていない。
この辺りの知識体系を日本人自身の手でまとめて、世界に提唱できたらいいなと思っている。