SECIモデルは知識の再利用モデル、または、実践知を生み出すモデルだ

SECIモデルを調べていたら、それは知識の再利用モデル、または、実践知を生み出すモデルに相当するのではないか、と気づいた。
ラフなメモ書き。

【元ネタ】
情報システム用語事典：SECIモデル（せきもでる） - ITmedia エンタープライズ

ナレッジマネジメント - Wikipedia

連載　オブジェクト指向と哲学 第14回　学習パターンとSECIモデル

連載　オブジェクト指向と哲学 第16回　パターン言語 - ソフトウェアへの浸透

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

- 組織パターンとプロセスパターン

SCRUM: 超生産的ソフトウェア開発のための拡張パターン言語

生成的開発プロセス・パターンランゲージ

【1】野中先生のSECIモデル(セキモデル)は、今まで何度聞いても分かりにくかった。
その理由は、SECIモデルを実際に使った具体例がイメージできていなかったからだと思う。

そこで、「SECIモデルは知識の再利用モデル、または、実践知の構築モデルである」という方針で、データマイニング・IT情報共有・見える化・Scrum・チケット駆動開発の各事例について、当てはめてみた。
すると、各プロセスにうまく当てはまりそうな感じがした。

SECIモデルの具体例(Scrum・チケット駆動開発など) from akipii Oga

【2】SECIモデルの具体例を実際に考えてみると、IT業界でよく言われるバズワード「情報共有」「見える化」とは、表出化プロセスに相当することが分かる。
つまり、チームや組織が何となく問題だな、何かおかしいな、という状況認識(暗黙知)を、ホワイトボードに書き出したり、メトリクスで出力して表示したり、無理やり形式知にしたプロセスである。

だから、表出化というプロセスはすぐに思いつきやすい。
しかし、見える化したからといって、それだけで問題が解決するわけではない。

見える化された問題に対して、どんな目標に向かって解決すべきかという課題へ洗練し(連結化)、その課題解決策ないし是正対策を各人が実施して解決しなければならない(内面化)。
実際は、この内面化のプロセスが難しいのだろうと思う。
是正対策を実施しなければならないことは分かっているが、本当にその対策が有効なのか、半信半疑だったり、躊躇したりして、その一歩を踏み出せない場合が多いと思う。

そこで、平鍋さんが提唱したプロジェクトファシリテーションが、行動を促進させる触媒として有効に活用できると思う。
連結化→内面化のプロセスで、プロジェクトファシリテーションを使って、メンバーのやる気を吸い出して元気づけて、メンバーが行動に踏み出すように促すのだ。

プロジェクトファシリテーションは、暗黙知を形式知へ変換させる表出化プロセスでも相性が良い。
「問題 vs わたしたち」という構造を作り出すことで、メンバーが暗黙的に感じていた問題点をどんどん吐き出す雰囲気を促進する。
朝会、KPTによるふりかえりが特に効果的だと思う。

Redmineでチケット駆動開発を実践していた時も、単にチケットを中心にタスクを回すだけでなく、プロジェクトファシリテーションを自然に使ってプロジェクト運営し始めた経験を持っているが、その理由はそんなところにあるのだろうと推測する。

もう一つ、注意するのは、形式知→暗黙知へ変換する内面化プロセスでは、形式知をそのまま現状に適用しても、思ったような効果が出ない場合が多い点だ。
その理由は、形式知が使える状況は限られているため、全ての現実に当てはまるとは言えないからだ。
つまり、パターン言語のように、パターンが使える状況(コンテキスト)を明確にしておく必要がある。
そうでなければ、形式知は生きた知識として、内面化プロセスを経た後に、自分たちのものとして所有できないだろう。

【3】Scrumを生み出したシュエイバーは、ScrumがSECIモデルに影響を受けていることを「アジャイルソフトウェア開発スクラム」で既に説明している。

Scrumでは、デイリースクラム(日次スクラム)が表出化プロセスを生み出す場になっている。
日次スクラムで、メンバーが持っている技術知識や経験をチームへ形式知として提供したり、問題となっている状況を障害(課題：Sprint Impediment)として表明したりする。
スクラムマスターは、日次スクラムで出てきた課題に対して、課題解決していく義務を背負っている。

Scrumでは自己組織化、自律化がキーワードになっているから、内面化プロセスが非常にスムーズに回る。
SECIモデルの観点では、Scrumは、表出化・内面化プロセスが自然に実践運用できる環境を作り出しているので、非常に上手く作られたフレームワークだなと改めて思う。

【4】では、チケット駆動開発をSECIモデルで見直すとどうなのか？

チケット駆動開発では、見える化のための手段が豊富だ。
例えば、チケットに起票したり、Wikiに書いて共有したり、ソースをコミットする時は必ずチケットに記録されるので、表出化するプロセスをツールが支援する。
また、朝会、KPTによるふりかえり、チケットの棚卸し、イテレーション計画の作成・変更のタイミングで、メンバーに技術検証の経験や課題を表明するような場、つまり表出化する場を生み出している。

そして、チケットが作業記録が更新される過程で、チケット消化に向けて、リーダーが課題解決を支援したり、他メンバーが環境構築や障害検証を行なって、一つのチケットにたくさんのノウハウがパッチとして更新されていく。
つまり、連結化プロセスに相当する。

そして、チケットが完了する過程で、どんどん知識と作業が一体化していく。
つまり、内面化プロセスに相当する。

最後に、イテレーションの全てのチケットが終了ステータスになれば、リリースが完了する。
そのイテレーションで得られた経験は、チームのナレッジ資産(PMBOKで言う組織のプロセス資産)となる。
つまり、内面化プロセスになる。

【5】同様に、パターンもSECIモデルで表現できる。
従来の狭義のソフトウェア工学は、再現可能なプロセスを創りだそうとして成功しなかったが、XPやScrumなどのアジャイル開発は、プラクティスとして実践知を再利用できることを発見し、成功したと思える。

つまり、プラクティスをプロセスパターンと見なせば、SECIモデルにうまく当てはまると思う。
チケット駆動開発も、使われているプラクティスをパターン言語として体系化できれば、XPやScrumのようなアジャイル開発のように、実践知の再利用モデル、あるいは、実践知を生み出すモデルとして、作り直せると思う。

それらについても考えてみる。