[#TiDD] SECIモデルから朝会という「場」を考える - 平鍋さん＠SEA関西 -

以前ご紹介した平鍋さんと野中先生の書籍「アジャイル開発とスクラム」は私のお気に入りの１冊です。アジャイル開発とはどのようなものであるかだけでなく、モノ作りはどうあるべきか、人が知的な存在として関わるにはどうすれば良いかが書かれているからです。

アジャイルスクラムが完成する際に必要だった最後のパーツが野中先生の実践知とSECIモデルです。今回のSEA関西プロセス分科会での講演は「アジャイル開発とスクラム」の内容ということでざっくりとお願いしました。そして、お話の中心は実践知とSECIモデルで、この本でとても大切な内容の一つだと思いました。

アジャイル開発（というかXP）が日本に入って来た時、その背景にある「なにか」に気づいて、我々は興奮しました。その「なにか」は、人が知恵を出し合い、助け合い、より良いモノ作りを目指す事だったのかもしれません。

SECIモデル

書籍に載っているSECIモデル(情報システム用語事典)では、暗黙知と形式知の間で行われる以下の４つの変換の繰り返しからなる知識想像活動のモデルです。

• 共同化（暗黙知→暗黙知）：言葉になっていない知識や感情を体験によって共有します
• 表出化（暗黙知→形式知）：暗黙知を図や文書によって伝達が容易な形式知に変換します
• 連結化（形式知→形式知）：形式知の組み合わせや編集によって体系化し新しい知識を生み出します
• 内面化（ 形式知→暗黙知）：実践を通じて体で理解学習していく

理論だけでも、実践するだけでもだめで、SECIモデルの繰り返しによって、イノベーションが生まれます。

このモデルはスクラムに組み込まれている大切なポイントなのですが、内容を理解できても腑に落ちるというか、応用が利く所までは言っていませんでした。しかし、今回の講演を聴いて、ようやくわかったように思いました。

SECIモデルの私的解説

この「わかる」とは、以前「できる人を観察して勝負する」に書いた知識が整理された状態です。自分なりに説明できるほどに整理できましたので、私なりにまとめておきます。

共同化（暗黙知→暗黙知）の経験

私が新人の頃の最初の仕事で用いた環境は、OSのバージョンが１に満たない不安定なものでした。プログラムを書き終えたものの、どうしてもコンパイルできない部分がありました。何度見直してもうまくいかず、上司に「動きません」と言いました。すると、上司がペアプロのように横について原因追及を手伝ってくれました。

「馬鹿者！少しずつ確認して、どこが原因か突き止めろ！」と言えば良いだけの状況でしたが、新人であったからか作業の仕方をナビゲートしてくれたのです。まずは、全体をコメントアウトしてコンパイル。次に上半分をコメントアウトしてコンパイル、、とバイナリサーチの要領で部分を特定していきました。原因の場所を突き止めれば、書き方を工夫するだけでした。

この経験で私は多くの事を学びました。仕事はあきらめては行けない事、頑張れば原因は突き止められる事、知識を応用して作業は工夫できる事、原因が分かれば問題解決につながること、、。

実際のところ、上司がたまたま暇だったからか、面白そうだから一緒にやってみたかっただけなのかもしれません。しかし、同じ場所で体験を共有する事で暗黙知が得られたのです

表出化（ 暗黙知→形式知）

平鍋さんの講演で印象深かったお話の一つがPanasonicのホームベーカリーの話です。機械を作ったもののパンをこねてもうまくいかず、大阪の国際ホテルに弟子入りして暗黙知を取得し、そこで得たヒントを実践し、試作を繰り返して形式知を得て、製品化したそうです。

ここで、思い出されるのは、エンピリカルソフトウェア工学のコースで「エンピリカルソフトウェア工学において観察は基本だが、鳥をいくら観察しても空は飛べない」と教わったことです。そういえば飛行機の歴史は、鳥人間コンテストのような真似事からはじまり、様々な模型を作り、理論的基礎を整えて、さらに試作を繰り返して飛行機ができました。

このようにして「実践知（後述）からイノベーションが生まれる」のだと思いました。

連結化（形式知→形式知）

チケット駆動開発で用いるチケットは「形式知」です。それらは単独で存在するのではなく、構成管理と紐づいたり、作業間で関連や順序があり、個人や優先順位、全体のロードマップといった様々な視点で確認する事で、やるべき事を見出します。

ビジネスの世界では様々なデータマイニングによって進むべき道を探ります。ソフトウェア開発において、開発に関連するデータをリポジトリから抽出しマイニングすることが、チケット駆動開発の一つの方向だと思っています(プロセスモデリングにおけるチケット駆動開発の可能性、Jenkinsの特長 - メトリクス収集サーバの視点から -)。

内面化（ 形式知→暗黙知）

講演では自転車の乗り方について、 共同化（暗黙知→暗黙知）の文脈で出てきました。まずは自転車を支えてあげて、慣れてきたら黙って手を離すというやり方です。多くの方が、この方法で教えられていると思います。

私が長男に教えた時は、ペダルを漕げば(車輪が回り)自転車は倒れないという形式知を実践させる方法です。自転車に慣れる必要はありません。後ろを押さえておいて「漕げ！」といってすぐに離す、というのを繰り返しました。

子供にすれば「怖いから押さえて欲しい」と思ったかもしれませんが、伝えたいのは「慣れ」ではなく「漕げは倒れない」なので思いっきり漕ぐ事だけを指導しました。なれるまで直進しかできませんでしたが、すぐに乗れる様になりました。

実践知（フロネシス）

実践知は「目に見える事象と、その背後にある関係性までを読み、その場で適切な判断を下し実行する」もので、実践知を持ったリーダーが実践知リーダーです。

この実践知リーダーに求められる事の一つが「『場』をタイムリーに作る能力」です。

知識を創造し、それを共有、成長させるための「場」

このブログでも「技術者には「場」が必要」と書いていましたが、ここでいう「場」とは、知識を流通させる時空間です（場[Ba]というのは、米国ではFieldになるがそれでは意味が通じない。英国ではBarになると説明すると笑いが取れて意味が通じるそうです）。

この「場」で思い出すのは、「先駆者の集まりから、プロセス・チャンピオンの集まりに - XP祭り関西2012 -」で書いた田口さんの「壁」です。壁にタスクボードを並べることで、チーム間のコミュニケーションの「場」ができたというお話です。まさに実践知リーダーですね。

チケット駆動開発で朝会に求めるもの

「朝会」ですることについては、以前からアナログ派の方と意見が合いませんでした。わたしは進捗と課題だけでなく質問や簡単な課題の解決の場にしても良いと思っているのに対して、みなさん進捗と課題のみで15分を守れと言われます。これが、いくら聞いても納得できないのです。

SECIのお話を聞いてこの理由がわかった様に思います。結論を書くと

• アナログアジャイルでは暗黙知を中心にプロジェクトが進むので、朝会を個人の予定を形式知にする「場」にしてバランスを取っている
• チケット駆動開発では形式知であるチケットを中心にプロジェクトを回すので、朝会を暗黙知を共有するための「場」 として利用している

という違いがあると思いました。

アナログアジャイルにおいて、タスクボードに貼るタスクカードに担当者の名前やマークがつけられる事も多いでしょうけど、個人の作業単位でタスクボードを見る事は困難です。そこで、朝会で確認する事で、チーム全体の状況を見える化しているのでしょう。

一方のチケット駆動開発では、チケットに形式知化された情報があり、個人の予定は簡単に確認できます。朝会で進捗だけを確認していたのでは、新たな情報がほとんど得られません。そこで、朝会は自然と課題中心の報告になり、細かな課題の解決とノウハウの情報共有の場になります。

チケット駆動開発では形式化された情報が中心になりますので、形式化されにくい情報をいかに拾い上げるかがポイントになります。そのためには、サーバントリーダーシップ(アジャイル開発への壁は価値観の壁)を心がけ、開発者の能力を最大限に発揮できる様にします。そして、拾いにくいものが形式知として蓄積できたとき、チケット駆動開発が挑戦の道具として大きな成果を出すのだと思います。

挑戦の道具としてのチケット駆動開発(長編版) from Makoto SAKAI