アジャイル開発とスクラム 第2版 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント みんなのレビュー

投稿元：

レビューを見る

アジャイル開発やスクラムをソフトウェアの開発手法だけにとどまらず、組織構造や文化といった観点で記載している

一部はアジャイルとはスクラムとはと言った基本的な話から始まり、二部では実際の事例と、三部は組織論。

SECIモデルの理解とアジャイルとの親和性について深く理解できる。

投稿元：

レビューを見る

　文句なしの★5つの本です。　というのも野中先生の『知識創造企業』は本当に僕の中でのビジネス人生において一番大事にしている本だというところもあります。　

知識創造企業への想いについては、当時の読書レビュに詳細は委ねますが、その中の「ラグビーアプローチ」にものすごく感動しました。　そして、この本は、20年以上前にはじめて社会人としてビジネスパーソンになる際に、内定者への課題図書として会社から提供された本でした。　当時まだ学生だった私としては、会社っていうところはすごい本を読ませるところなんだな、と、青二才ながら大変感動していたことをよく覚えています。

　そういう、僕のビジネス人生の基礎を築いてくださった野中先生の本は、失敗の本質、しかり、戦略の本質、直観の経営ほか、そして、ワイズカンパニーも当然読んできたのですが、この第2版が出版されると知って、この本を読むために、個人的に　『アジャイル三部作』（This is Lean, みんなでアジャイル，そしてこちら）と課題設定して、ゴールデンウィークを活用して三本読んできたかいがあると思いました。　本当に三部作を順番で読んできて、ものすごく理解が深まりました。　僕はソフトウェア技術者ではなく、営業職責の人間なんだけれども、「ラグビーアプローチ」による知識創造は非常にインパクトを受けた理論であって、それが「スクラム」という名前に変わってソフトウェア開発における一大アプローチになったと聞いたことから、これは読まねば！と思っておりました。
　　
　ラグビーをやってきたものからすると、スクラムというとどっちかというとセットプレイであって、止まった状態、という印象があり、「スクラム」が動的に動き続ける、というところに若干の違和感はあったのですが、今回の書籍においては、1986年の論文から正しく引用してくださっていたり、知識創造企業から「ラグビーのようにチームで一丸となってボールを運んでいる」や、「ラグビーにおいて、チーム内でボールがパスされながらフィールド上を一群となって移動するかのように」の部分を正しく表現してくださっていて、ちょっとううれしい。（さらに書籍の中にはポッドシステムについても少し触れられているのが、また、うれしい）

　まぁ、あくまでメタファーなので、若干の変化はあるとは思いますが、最後のメッセージ文を読んで、僕も何らかの形でまたこちらの「スクラム」にも関わり続けていきたいなぁ、と思いました。

P289 「スクラムとは、会社を機能単位に分割した階層や組織ではなく、どこをとっても会社のビジョンに向かった判断・行動パターンを共有する自己相似形の知識創造活動であり、それを実践する人々である」



以下、改めまして抜粋引用となります。(ふせんはりはりしすぎで多めです)
＝＝＝＝＝＝＝
P66　
　スクラムが役割を3つに分けているのはそれぞれの仕事に線を引くためではない。「計画」と「実行」を分離してしまってはスクラムの意味がない。そんなやり方は本末転倒である。
　スクラムでは役割を超えて���力していくことが欠かせない。「あなたvs私」ではなく「問題vs私たち」の構図を引き出すことが重要である。「私たち」はもちろんスクラムチームだが、私たちが向き合う問題とは何なのかをチームが共通認識として揃えておく必要がある。

P72
　アジャイル開発では対話を重視している。ユーザーストーリーは、従来の仕様書による情報伝達の欠点を補う手法として生まれた。従来の問題とはすなわち、完璧な仕様書で伝達しようとするあまり、どこまでも詳しく書くことになり、大きなドキュメントを抱えて「分析麻痺」に陥る問題だ。しかも、書き終えた頃には、要求が変化してしまっている。

P94
　これらを見ると、アジャイル開発の現場がいかにアナログのコミュニケーションを重視しながら、チームの暗黙知を共有し、テストとコードという動くものによって品質を作っていくかがわかる。顧客から見て価値がないムダなドキュメントを排除し、密度の濃い「場」を使ったコミュニケーションこそが、アジャイル開発の圧倒的なスピードを支えている。それは、チームの力を最大限に活かすプラクティスによって成り立っている。

P143　
　メンバーはスクラムの方法論だけでなく、その本質にある「課題を見つけ、5cmの階段を上るように小さく改善する（検査と適応）」「困り事などは書き出し、空中戦にせず課題を解決する（透明性）」「誰かがやってくれる、を待たない（オーナーシップ）」といったマインドを学び取っていた。

P153
―最後になりますが、薄井さんは、すべてのプロジェクトがアジャイルになる、もしくは、なるべきだ、と考えますか？
　個人的にはなるべきだ、と考えます。　人間が成長し続ける生き物である以上、その活動を支えるITシステム開発や、それ以外の営みも、同等以上のスピードで成長する必要があると思います。それを実現するためにも、アジャイルは不可欠と思います。

P209
　それは技術的な議論だけではなく、人と人との協調、共感といった感情面も含めた、チーム作りや組織作りにまで及んでいた。そして、彼らは正解を学んでいるのではなく、新しいコンセプトを使って、自分たちのやり方を形作ろうとしているように見えた。まさに、私たちが「スクラム」という言葉で呼んだ共感と共振がそこにはあったのだ。

P211
　新製品開発という速さと柔軟さが求められる場面では、成果物を紙に書き、それを壁越しの別のチームに渡すようなリレーをしていてはだめである。様々な専門性をもった人が1つのチームを組み、ラグビーのように開発の最初から最後まで一緒に働くことが求められる。人とチームを重視し、彼らに自律的に動ける環境を与えることでブレークスルーが起こりやすくなると同時に製品化までの時間が短くなるというのがこの論文の趣旨だ。

P236
　現在、65%の人が自分の仕事を幸せだと考えていないという調査結果がある。彼らは、自分たちの仕事がうまくマネジメントされていない、自分の仕事をコントロールできない、創造性を排除されている、と考えている。そしてそのことが生産性を落とし品質も悪くしてしまう根本の原因だと思うんだ。もしみんなが自分の人生に責任を持ち、自分の進む方向を自分で��められたとしたら、自分の人生にもっとエネルギーと創造性を感じて、チームですごいソフトウェアを作り出す仕事を、わくわくしながらやれるんじゃないかと思っている。その結果、製品のコストが10分の1になれば、この地球上にはもっと必要なものが手に入るようになるだろう。スクラムによって、こういった職場の変化、そして製品やサービスの変化が、もっと現実的な未来に近づくと思っているんだ。

P261　
野中　P、つまり「プラン:plan」というものは言葉で書かれた形式知であって、PDCAは最初に計画ありきなんですね。　これでは本当にほしいもの、顧客に届くもの、そして感動すなわちイノベーションは作れないんです。最初に論理思考、分析思考に陥ってしまってはだめ。作るものには「意味」があって、意味は計画や論理からは出てこない。意味の正体は、最初はもっと主観的かつ曖昧で、言葉にできないことが多いのです。
平鍋　いきなり「何を作る」のではなく、「なぜ作る」のかという情熱を、主観のままに伝えることが大事だと。
野中　我々が何かを作ろうとするときには、まずプランがあるのではなく、その前に直接経験や直観、主体的・身体的な経験というものから得た動機があるはずです。それこそが「意味」であり、コミットメントの源泉になる。知も感情も含めた全人的な身体知＝思いが、まず一番初めにあるのです。

P273
野中　論文「The New New Product Development Game」の図1、TypeCを見てください。ここはフェーズが重なった絵がありますが、よく見ると、最初のフェーズを示す円は最後に向かって伸びています。これを言い換えると、「最初に企画をした人は、最後までチームに残って、身体で意図を伝えよ」ということなんです。
平鍋　これがプロダクトオーナーの仕事なんですね。ユーザーと開発チームを身体でつなぐ。そして、それができるのは、実践知リーダーだと。
＝＝＝＝＝＝＝

投稿元：

レビューを見る

アジャイル開発とスクラム

企業内でもアジャイル開発が広まって来たと思う一方で、まだまだウォータフォール開発がなくならない現実。
アジャイル開発を知識創造型と呼びますが、人との繋がりによって臨機応変に動くことで、より良い、より市場に特化した製品やサービスを生み出す。
私達と顧客と見ることで、一体感を生み出す。

ソフト開発に限らず、ビジネスやマーケティングなどでもスクラムは取り入れられてきた。アメリカの海兵隊の陸海空が連動して動くシステムもまた、然りとのこと。

よりコミュニケーションを必要とすると考えれば、必ずしも万人に、良いものとは思えない。コミュニケーション高荷になりかねないのでは。
それでも、情が先にくるかっての日本企業が当時、この方法を取り入れることができたら、日本の歴史も少しは変わっていたかもしれませんね。

投稿元：

レビューを見る

第1版は読んでなくて、実はそれが長い間のひっかかりだったのだけど、第2版が出たということで同僚と読書会を開催し、それをトリガーに読んだのでした。

読書会はまだ続いているけど、先に読了。

読んで良かった。特に第3部はグッと来た。決して長い文章じゃないんだけど、シンプルな言葉で本質を伝えてくれている感あった。

そして実践知リーダーシップについてもっと理解を深めるために『ワイズカンパニー』も読んでみたくなった。（そして読むだけでなくきっと自分の課題として実践も必要だと思われる）

投稿元：

レビューを見る

ウォーターフォール型の開発は敵対関係を生み出しやすく、面白くない→個人的に刺さった

【感想】
　スクラムを中心に、アジャイル開発の技法、企業への導入エピソードが紹介されている。アジャイル開発は大きく技術的手法、組織的手法に分けられる。本書は、組織的手法である「スクラム」の記述に焦点をあてていて、技術的手法の詳細には立ち入っていない。リファクタリングやTDD、CI等については紹介程度の記述がある。実際の開発で生かすには、別の本を読む必要があるだろう。
　とかく、情報が分散していて、章ごとのつながりを捉えるのが難しく、咀嚼が難しいと感じた。おそらく、この本の目的は「アジャイル開発手法とスクラムについて色々な観点で紹介する」ことなのだろう。フレームワーク・プラクティスがかなり多く登場するし、ケーススタディの登場企業も多い（覚えて使いこなすことが難しい）。
　企業４社ごとのアジャイル導入経験も記述されているのが、各企業群をまとめて抽象化していないので、頭に叩き込むのが難しい。研究書ではないので、当然ではあるのだが。そして、読んでも、弊社で実施している４，5カ月程度のシステム導入プロジェクトを、アジャイル方式にするイメージが余り湧かなかった。なんといっても、顧客にとって、アジャイル型を選択するメリットがイマイチ分からなった。基本設計までして、顧客から承認を得る必要があるとする。そのとき、請負型ではなく、準委任型で、なぜユーザー企業が発注してくれるのだろうか。準委任型で、開発発注するにしても、「何を開発するか」は決まっていないといけないわけだから、基本設計は顧客と行っておく必要があるように思えるのだが。基本設計まで終わっている機能を、準委任型で開発依頼してくれるためには、スケジュールと予算が潤沢にあるような企業じゃないと、無理なのかな、と思った。もしくは、要件がふわっとしていて、基本設計自体が無理で、開発して、その成果物をみないと要件が固まらないような内容なのだろうか。そうなると、それはもはやPOCのようでもあるのだろうか。
　「スクラムの源流は野中＆竹内のナレッジマネジメント論文である」という章の取り扱いも難しい。興味深くはあるが、スクラムの関連情報、アカデミックな組織分析である。スクラムの素養が日本企業にはあるよ、という意味では分かるのだが...。既に情報過多なので、ここで新しいアカデミックな話を入れてくるのであれば、事前のケーススタディに対する汎化、抽象化の章にしてほしかった。「野中さんと、点と点がつながる面白い話ができた！スクラムの関連情報だし、伝えたい」という意志を感じる。
　個人的に一番刺さったのは、ウォーターフォール型の仕事自体が楽しくない、と書いていること。今私が仕事で感じている辛みが簡潔な文章で表されていて、なるほどな、と思わされた。この文章と出会えただけで、★４つ。自分の生業、仕事内容を見直し、システム開発に携わるなら、アジャイル的な職場に移るように準備、努力をし始めようと思った。

>>p47「工程を追って順に仕事を進めるやり方は、仕事を渡す���と受ける側の間に敵対関係を生み出す傾向にある。「仕事に書かれていないことをやってほしいと言うのです」「簡単に気を変えないでほしい」「自分にコントロールできないことに対して、私は責任が持てません」などなど。ウォーターフォールの開発を観察すると別の発見がある。そう、仕事が楽しくないのだ。ウォータフォールの開発モデルは、製品作りに携わる人々のモチベーションをそぐ原因になる。そして、その結果できた製品は、作った現場開発者の創造性、スキル、そして情熱を表現するものにはならなにのだ。人はロボットではない。だから、人にロボットのように働くことを求めるプロセスは、介在する人々を不幸にする結果になる。」

【本書を読みながら気になったコト】
■アジャイル開発では、期間を短く区切って優先度の高い機能から実装することを繰り返すことで、最後にならないと動くものが見えないリスクを軽減する。ユーザーからフィードバックを取り入れながら開発する

■ウォーターフォール手法の問題点
・創造性を奪う。変更を拒み、部分最適な機能が出来上がる
・文書による完璧なコミュニケーションなど不可能
・完璧な計画を立てることはできず、必ず不確実なことが起きる
・工程を追って順に仕事を進めるので、ステークホルダー間で敵対関係ができて、仕事が面白くない

■インクリメント…スプリントにおける成果物、製品の機能。

■リファイアメント…プロダクトバックログの内容を更新する。優先順位の変更、機能詳細の追加、工数見積もりの変更を行う

■アジャイル開発という開発手法が存在するわけではい。アジャイル開発宣言の価値観を反映した開発の手法の1つがスクラムである


■こまめに完成物を見せて、フィードバックをもらう、という考え方自体はウォータフォール型の開発でも活かせる。その前提で工数、費用を見積もりする

■各種企業での実践例が記述されているが、何故多くのユーザー企業は、請負型ではなく、準委任型（アジャイル開発）でのプロジェクト推進を許したのか？
　→完成物責任が無い状態で、発注する（最終的な予算がいくらになるか見えてこない）以上、ユーザー企業としては、アジャイル開発を好みそうにないと思えたのだが
　・BtoBでリリースはどうやっている？細かくフィードバックをもらえないと、リリースはできない
　→なぜそんなにも、ユーザー企業は開発やスプリントレビューに付き合ってくれる？どうしてそんなにユーザー企業がアジャイル開発に理解があり、つきあってくれるのか？
　
■2020年3月にIPAからアジャイル開発版「システム・モデル取引・契約書」が公開された
　→準委任契約を前提とする
　→プロダクトオーナーはユーザー企業から選出する

■人生もウォーターフォールより、アジャイルに。変化を前提に。一定の期間、目標を決めて、実践しながら、時折振り返りを実践する
　

投稿元：

レビューを見る

Scrum;
適応型ソリューション(adaptive solutions)をチームで開発するために従うべき少数の規則・軽量フレームワークがスクラムである。
1986年に野中郁次郎と竹内弘高が「新製品開発のプロセス」について日本の組織とNASAといったアメリカの組織との比較、分析を行った研究論文「The New New Product Development Game」が『ハーバード・ビジネス・レビュー』に掲載された。その中で柔軟で自由度の高い日本発の開発手法をラグビーのスクラムに喩えて「Scrum」として紹介した。
スクラムの定義と解説はスクラムの創設者Ken SchwaberとJeff Sutherlandによる「The Scrum Guide」にまとめられており、スクラムの改良に伴ってこのガイドも更新されている。(Wikipedia)

Agile;
アジャイルソフトウェア開発宣言(Manifesto for Agile Software Development)は「アジャイルソフトウェア開発」という概念を提唱した文書である。
2001年に、軽量ソフトウェア開発手法（と当時呼ばれてた）分野で名声のある17人がアメリカ合衆国のユタ州のスノーバードというスキーリゾートに会し、彼らがそれぞれ別個に提唱していた開発手法が共有する価値観を議論した。彼らはその結果を 「アジャイルソフトウェア開発宣言」という文書にまとめた。アジャイルソフトウェア開発宣言はアジャイルソフトウェア開発とその諸原則を公式に定義した文書であると、広く認められている。
この宣言は以下の4つの価値観を示し、これらの価値観を有するソフトウェア開発を「アジャイルソフトウェア開発」と名付けた。
・プロセスやツールよりも個人と対話を
　　Individuals and interactions over processes and tools
・包括的なドキュメントよりも動くソフトウェアを
　　Working software over comprehensive documentation
・契約交渉よりも顧客との協調を
　　Customer collaboration over contract negotiation
・計画に従うことよりも変化への対応を
　Responding to change over following a plan
(Wikipedia)

投稿元：

レビューを見る

2022/4/3
アジャイルは原則でありそれに沿った具体的な手法としてスクラムやエクストリームプログラミング、カンバンなどがある。ドキュメントより対話、仕様書より動くソフトウェア、交渉より協調、予定より変更を重視するのがアジャイルの原則。リリースをスプリントという単位で分割し高速でデリバリーするための各種プラクティスを定義した方法論がスクラム
野中氏のオリジナルの新製品開発についてのスクラム論とアジャイルスクラムの共通点は不確かな状況の中で大胆な目標を達成するために①柔らかなマネジメントによる自律的チーム、②学習、③フェーズを横断してプロダクトオーナーが責任を持つ人による伝達。
ウォーターフォールには学習を経ていない洞察のない計画、変更への柔軟性がなく、下流工程が情報処理要員となりモチベーションが下がるという問題がある。
身体的な暗黙知と言語化された形式知を行き来してスパイラル上に知的生産をするseciモデル。形式化された知識は内面化されないといけないし、内面化された知識はまずF2Fで共有され、それが言語化されて、議論や交流を経て洗練される。スクラムでの朝会、ペアプログラミング、レトロプロスペクティブ
暗黙知と形式知だけでなく、それらを統合して実際の文脈に合わせて何をすべきかを共通善に沿って判断する実践知が必要。
継続的なイノベーションのためには、ビジョンと学習、各ファンクション、各スキルを一通り持った小さな相似形のチームが集まって全体を構成するフラクタルな組織が必要。

投稿元：

レビューを見る

スクラムをフレームワークとしてだけではなくて、人々の活動と捉えているところに著者たちの熱い気持ちを感じました。

投稿元：

レビューを見る

たしかにスクラムの概要や導入のための具体的な手法を求めて読むには物足りない内容かも知れないが、スクラムのスケーリングのための手法 LeSS, SAFe, Nexus, Scrum@Scale の各手法の解説は、スクラムの全社的な展開の選択肢を広げる際の参考になる。関連して、終盤の自己相似的な組織の拡大の話も新鮮で刺激になった。

投稿元：

レビューを見る

スクラムというタイトルが付いているけど、この本を読んだからスクラムが出来るという訳ではない。
スクラムが対象としている根っこの課題は何なのかを語ろうとしている本。
なので、1部にスクラムの表面的な話が載っているが、知らない人向けだろうし、知っている人からすると退屈。
後半の対談とかは面白いが、これも示唆くらいな話なので、そこから自分で考える事が必要だろう。

投稿元：

レビューを見る

アジャイル・サムライを読んだ後だったので、「ふーん」という感じだった。

開発現場に深く入ってない人が「アジャイルってどんなもんじゃい？」というときに読むと非常にいいかも。

投稿元：

レビューを見る

■従来手法の何が問題なのか？
・人の創造性を奪ってしまう
・文書によるコミュニケーションには限界がある
・悪いタイミング
・未来を読む水晶玉はない
・仕事が楽しくない
・部分最適化

■アジャイルを大規模化するフレームワーク
【共通する点】
１．既にうまくいったチームが２つ以上あること
２．大規模化する必要があること

・Nexus：最も純粋なスクラムの複数チーム拡張。あくまでソフトウェアのプロダクト開発に焦点がある。チーム間の依存関係を調整しながら、同期的に全体スプリントを回し、動くソフトウェアをデリバリーする。
・Scrum@Scale：単にソフトウェア開発手法としてのスクラムを拡張したものではなく、スクラムによる組織運営を主眼としたフレームワーク。会社全体がすばやい意思決定と顧客指向の組織に変わること、そして、優れたプロダクトやサービスを市場に出していくことの両方を指向している。また、マーケティングチームや人事チームなど、これまでアジャイルが対象としてこなかったチームにも、スクラムを適用する。よって、導入には会社の方針が必要となる。EATを採用するには、エグゼクティブレベルの意思決定が必要になる。
・SAFe：プロダクト開発の方法論に留まらず組織運営や文化形成までを対象にしたフレームワーク。プロダクトを作る部分はもちろん、そこに至るまでの判断やワークフロー、チームを支える組織を対象とすることで、部分最適ではなく全体最適を目指している。
　また、SAFeは大規模アジャイルフレームワークの中でもトップのシェアを誇っていて、世界中の多くの企業による導入事例がある。ScaledAgile,Inc.によって事業として運営されていることもあり、トレーニングや認定制度導入支援をしている企業や団体も多い。
　SAFeの全体像を見ると複雑で難しく感じるかもしれないが、導入レベルに合わせた4つの構成、ロードマップ導入事例導入支援を受けられるという点が高いシェアにつながっている。
・LeSS：シンプルにスクラムを大規模開発に適応させたフレームワーク。チームを中心に、大規模に適応させるために必要なものだけを追加している。そのため、ある程度スクラムに慣れたチームや組織にとっては、すんなりと受け入れることができるであろう。
　一方で、用意されたプロセスやルールを使って一気に導入したい場合には向かないかもしれない。プロダクトやプロダクトグループの成長に合わせて学習を繰り返し、フレームワークも成長させていく姿勢が求められる。
　Nexusと共通点は多いが、詳細では違うところもある。スクラムの共同開発者の1人であるケン・シュエーバーが開発したNexusとは違うルートで、開発現場の大規模開発へのニーズに適応していったスクラムの形だといえる。
・Disciplined Agile：エンタープライズ対応に重きを置き、これまでアジャイルに含まれていなかった、「ガバナンス」「文書標準」「レビュー」「エスカレーション」「教育」「運用」「予算」「人事評価」などという言葉が出てくる。リアルな大企業でよく聞く言葉群だ。例えば、契約方���やリソースの戦略が「方向付け」フェーズの「予算確保」というゴールに登場する。
　また、これまでチームベースのアジャイルがわざと避けてきた大域構造を示す言葉群、「アーキテクチャ」「フェーズ」を積極的に入れている。スコット・アンブラーの過去の仕事から、ラショナル・ユニファイド・プロセス(RUP)、アジャイル・モデリング(AM)、アジャイル・データ(AD)などの視点もしっかり入っており、集大成的なアジャイル百科事典ともいえるだろう。
　PMIがこの手法を取得したことで、今後PMBOKと相乗した普及活動が活発になるだろう。

■事例：NTTコムウェア
【社内プロセスの変革】
　そこで、これらの既存プロセスが抱える課題感例えばNTTコムウェアとしてウォーターフォール開発で積み上げてきた、統計データに基づく品質評価が、
・案件ごとに完成の定義が異なり、試験工程をまとめて取らないスクラムに適さない
・意思決定の会議体に必要となる、資料作成や事務処理、事前説明等が煩雑である
といった課題に対し、冒頭で出てきたアジャイル推進組織とともに、カイゼンに取り組んだ。
　このプロセス改革においては、アジャイル開発の実践と同様、守破離のマインドで取り組んだ。実際にスクラムを行う中で、社内プロセスに対し理想論を押し付けず、既存のプロセスで取り組み、結果として見えた既存制度の課題点を、他組織を巻き込むことで社内プロセスの変革につなげたのである。
　例えば品質評価のプロセスにおいては先述の通り、統計データに基づいたテスト消化曲線やパ発生曲線の収束を目指す従来型の評価方法が主流であった。しかし、開発の中で試験を同時に実施する私たちのチームでは時系列曲線を描くことができない上、「バグ」の定義も困難であった。
　こういった課題に対し、定性的な評価として「プロダクトオーナーによる評価レポート」や、「品質コントロールのために行った施策の透明化」を用い、定量的な評価として「循環的複雑度」や「長期的に見たモジュールごとのコミット数」(コミット数が多い=リファクタリング頻度が高いモジュールは要注意)を用いる等、新たな品質評価の可能性を品質管理部門と連携して模索した。これら新たな指標値の出力に自動化を組み合わせることで意思決定プロセスの短縮化に挑戦した。


■「合宿をしなさい」
「形式的な会議で決めることはできない。いろんな背景を持った人の集合において、形式知で語れること、理解し合えることはごく一部だ。合宿をし、一緒に飯を食い、泊まって徹底的に話をする。そうすると、形式知は脱ぎ捨てられ、自分の主観で話をするようになる。そこで、なぜこのプロジェクトに自分が参加しているのか、という根源的な問いにまでたどり着けるだろう。そこから初めて、1つの共通理解が生み出される。この過程をみんなで踏みなさい」