Scrum Alliance Reional Gathering Tokyo 2013『野中郁次郎氏 : 特別講演 知識創造企業』ノート（後半）

2012/01/16に開催されたScrum Alliance Reional Gathering Tokyo 2013『野中郁次郎氏 : 特別講演 知識創造企業』のノートです。こちらは後半部分です。



（前半の続き）

■野中氏の講演

◆実践知・ジャッジメント・コンテキスト

◇全てを総合するリーダーシップ = フロネティックリーダーシップ
・フロネシスの語源
　→ギリシャ語
・実践知
　→賢慮(Prudence)と実践的な知恵(Practical Wisdom)を併せたもの
　→文脈で使い分けられる
・ハーバードビジネスレビューにこれに関する論文を書いたとき、日本の経営者を中心に調査した
　→こういうのもは日本が得意だと思う
　→→日本の組織には、一丸となって知を生み出していくというDNAがあるのではないかと思っている

◇知の生態系は不確実
・そんな中でのイノベーションには実践知のリーダーシップが必要
・ワイズリーダー
　→さまざまな円環の中で持続的に知を作り続けるリーダーシップ
　→文脈を読みながら絶えずSECIプロセスを回し、触発・支援・蓄積ができるリーダーシップ
・個別を離れた普遍の知はなかなか存在しない
　→観念論としてはあるかもしれないが、実践論としては？
　→「何が本当か？」はその都度のコンテキストの真っ只中で判断できないといけない
　→→身体性を伴うということはそういう意味で重要
・個別具体の文脈で"Just Right"な判断をしていかないといけない
　→単なる改善ではない
　→大きなビジョンやイデアが関わってくる
　→→そういう志を持ちつつ、現実の中でのジャッジをする必要がある
・最初から演繹的な絶対的な真理からブレイクダウンしていくのではない
　→これはウォーターフォール的かもしれない

◇実践知の考え
・どういうものか
　→『イデア（顧客の思い）がある』けど…
　→『それがあると信じる』けど…
　→現実の中で一緒になって、皆の英知を結集してベターに向かってやっていく
・行為の真っ只中で考える
　→動きながら考える
　→そして文脈に即したジャッジをする
・DecisionではなくJudgement
　→マネジメントの領域ではDecisionだと言われてきた
　→→これはコンピュータでもできるもの
　→Judgementは背後にあるコンテキスト（関係性）の読み
　→→全ては読みきれない
・なぜ読みきれないのか
　→その都度の動きの中での関係性が、背後にあるから
　→→お互いのインタラクションを通じて、Assumptionを豊かにしながら明らかにしていく必要がある
・Contextual JudgementとTimely Balancing
　→事象の背後にある関係性は見えない
　→→だから、現実の只中でコンテキストに応じたジャッジメントをすることが重要
　→→それを適時・絶妙なバランスでやらないといけない



◆フロネティック・リーダーシップの6つの能力

◇フロネティック・リーダーシップについて
・何が必要か
　1. 何が"Good"なのかを作る能力
　→→スパイラルをどこでやめるかとか
　→→志の大きさに依存する
　2. 場をタイムリーに作る能力
　3. 現実を直視、直感する能力
　4. 直感の本質を概念・言語化する能力
　5. スパイラルして"やりぬく政治力"
　→→イノベーションはおそらく政治プロセス
　→→現実の只中でしかるべきタイミングでジャッジする能力
　→アリストテレスのいう中庸
　→→グレーなものをコンテキストを読みながら判断する能力
　6. 実践知を組織化する能力
　→→実践知を組織に埋め込む力
　→→全員がリーダーになるまでリーダーシップを高める力

◇（アジャイルを含めた）プロジェクトで重要なこと
・何が重要か
　→人が育つこと
　→リーダーがたくさん育つこと
　→→自立分散型のリーダーシップ(Distributed Leadership)

◇1. 何が"Good"なのかを作る能力
・「何が善いか」についてはいろいろ議論がある
・アリストテレス
　→「本質的に人はいいことをしたい」
　→「世の中の価値には、絶対に手段にならない、それ自体を追求する価値があるものがある」
　→幸福とか自己実現
・確実に唯一最善のものに到達できるという方法はない
・マッキンタイア
　→「絶えずエクセレンスを追求する、そのプロセス自身が"Good"」
　→職人の道
　→→ベターに向かって無限にイデアを追求するという姿勢
・人は理想を追求する
　→達成できないかもしれないけど、達成しようとする
　→→だから人間は限界を超えて知を作る
・スティーブ・ジョブズ
　→「我々の心を高鳴らせるものはリベラルアーツと結びついたテクノロジーであり、人間愛と結びついたテクノロジー」
・本田宗一郎
　→「どの国境、どの人種の上を越えても、いつだれがどこで考えてもそうなくちゃならん、ということが世界的視野」
　→「国境を越えて、人類として、人間である限りは、必ず納得できるような、理論の持ち主になってもらいたい」
・ホンダの本田宗一郎、Panasonicの松下幸之助、シャープの早川徳次
　→創業者はみな技術者

◇2. 場をタイムリーに作る能力
・文脈に応じてバランスをとる・共有する
・いかにバランスを取るかがリーダーの仕事

◇3. 現実を直視、直感する能力
・日々変化する現実を全身で理解する能力
・全ての五感を総合して、相手の視点に合わせる
　→その上で共感する
　→そして、彼の視点から次の仮説を立てる
・全ての五感を総合する
　→そうやって瞬時の想像力や判断力を高める
　→そうすることで研ぎ澄まされた共通感覚を得ることができる

◇4. 直感の本質を概念・言語化する能力
・それを大きな物語にして共有することが重要
　→大局観が必要
　→→Historicalな歴史観が重要になる
・物語はチームを元気付ける
　→会話をしながらコンセプトやストーリーを作っていく

◇5. スパイラルして"やりぬく政治力"
・周囲を説得して価値創造にまい進する
　→説得できる演説力が大切になってくる
　→→「一般通念を打破する新しいビジョンはレトリックに頼らざるを得ない」
・スティーブ・ジョブズの現実歪曲空間

◇6. 実践知を組織化する能力
・個人の全人格に埋め込まれているフロネシスを組織に埋め込む
　→実践の中で自律分散的な体系化・伝承・育成を行う
・そうすれば何が起こっても弾力的に対応できるしなやかな組織ができる
　→そのためには評価システムが適応している必要がある
　→あるいは徒弟制度
・意図的に大きな挑戦を与えて飛躍的成長をしてもらう
　→絶えずフィードバックを得るようにする
　→複数のメンターを付ける
　→→そうやって仕事の型を共有させる
・ホンダの考え方
　→「全員が本田宗一郎になろう」

◇シュンペーターが指摘していた問題から考えてみる
→「組織は個を殺すから崩壊するしかない」
・そうではない組織のあり方があるのでは？
　→個をクリエイティビティする組織
　→組織の知をもっと大きくするような組織
　→→そのためのやり方があるのではないか？
・そのために必要なリーダーシップが1から5
・組織知にするためには6がなければならない



◆組織・フラクタル・ミドルアップダウン

◇最近の組織構造はマトリックス型が多い
・部分最適で終わるのではないか？という話がある
◇そうではない組織構造のケース
・ダイハツのケース
　→新製品開発に辺り全員転籍
　→→帰る場所はどこにもない
　→人事権はPLである部長が持つ
　→→結果として人が育った
　→→→これを受けて組織全体の再編へ
・JALのケース
　→アメーバ経営
　→→時間辺り付加価値を全面的に導入
　→→→組織の末端が社長と同じことを考える
　→予算の執行権を経営企画から経営管理部へ
　→フラクタルな組織経営になっている
・アメリカ海兵隊のケース
　→フラクタルな組織
　→→パイロットは地上部隊のリーダーを1年経験していないといけない
　→→全員でライフルマンをバックアップする
　→仲間（個）のために戦う
　→→お互いの信頼関係が非常に重要
　→→→数人で一個小隊を撃破することもある

◇自立分散型実践知経営
・フラクタルな組織は絶えず環境と共振する
　→組織が1つの個であるかのように振舞う
・クロネコヤマト
　→社長曰く「うちの社長はセールスドライバーだ」
　→→彼らが知の最前線にいて、即座に対応できる
・マージナルマン
　→境界にいて絶えずコネクトしている人が重要

◇フラクタルな組織ではミドルアップダウンが重要になる
・トップダウンやボトムアップではない
　→ミドルが非常に重要な役割を果たすようになる
・Cisco
　→"Lead from the middle."
　→社内SNSで知をアドバタイズしながら、知を絶えずリンクさせている
　→→Distributed Leadership
・明治維新もミドルアップダウンの方式になっている

◇アジャイルやスクラムもこのコンテキストで見るとどうなるか
・組織的なイノベーションやDistributed Leadershipを作ることができる、1つのプロセス

◇コミュニティと知の関係
・コミュニティが内に向かうと知は枯渇する



◆最後に

◇実践知は非常にリスキー
・でもベターを追求するためには必要
　→だからCourageが大事
・ロロ・メイ
　→「Courageはすべての徳の源泉である」
・本田宗一郎
　→「試す人になろう」

◇賢慮と実践知のリーダー : 知的体育会系
・ベターを無限に追求する人
　→現実の中で実践的推論を重ねて真理に近づいていく






野中郁次郎様、平鍋健児様、Scrum Alliance Regional Gathering Tokyo 2013 実行委員会様、翔泳社様、ありがとうございました。

Scrum Alliance Reional Gathering Tokyo 2013『野中郁次郎氏 : 特別講演 知識創造企業』ノート（前半）

2012/01/16に開催されたScrum Alliance Reional Gathering Tokyo 2013『野中郁次郎氏 : 特別講演 知識創造企業』のノートです。いつもとは違う刺激や気付きがあって良かったです。こちらは前半部分になります。



■平鍋健児氏によるイントロダクション

◆野中氏の紹介

◇野中氏はスクラムと言う言葉を最初に作った人
・でもソフトウェア業界でスクラムと言う言葉がここまで使われていることは知らなかった
　→一昨年開催されたイノベーションスプリントで知った
・世界で最も影響力のあるビジネス思想家の1人
　→日本からオリジナリティのあるアイデアを発信している
　→本を英語でも書いている

◇ソフトウェアの大切なところ
・技術
　→これはもちろん大事
・人と人とのコミュニケーションのデザイン
　→マネジメントも含めて、これが大事

◇アジャイルが気付いたこと
・「どう"コミュニケート"したら、良いソフトができるのか」
　→アジャイル = ソーシャルなコミュニケーションパターンデザインの方法
　→→そこで使われているコミュニケーションデザインの方法について、始めて言及したのが野中氏



■野中氏の講演

◆はじめに

◇知識創造理論はアジャイルと関係なくやってきた
・イノベーションスプリントの基調講演の依頼を受けて、初めてつながりを知った
　→自分はそもそもコンピュータを使えない
・「アジャイルはソフトウェアの開発の話に留まらない」という話
　→聞いて納得するところがある
・アジャイルは組織変革のプロセスそのものにまで展開されつつある
　→アジャイルとスクラムというのは物凄く大きな話になっていくのではないかと思っている

◇マネジメントにはいろいろな切り口がある
・我々は知識ベースのストラテジックなマネジメント
　→今は戦略によっている
・戦略と組織は分離できない
　→戦略は人間が解釈して作り出すもの
　→戦術を実行するのは組織
　→→人間の解釈や実践・組織作りがないと戦略は成立しない
・戦略と組織を分けるという考えが、欧米では伝統的に強い
　→でも、いくらビューティフルな戦略を考えても実行できなければ仕方がない
　→→戦略と組織をダイナミックに統合するのがストラテジックなマネジメント

◇知識ベースのストラテジックなマネジメント
・これの大まかな枠組み = 絶えずイノベーションを生み出すようなコミュニティ
　→そこには大きな枠組みや大きな志がある
　→→"共通善"があるということ
・大きな枠組みを代表するのが企業ビジョン
　→それを具体的に組織全体に落とし込んだのがビジネスモデル
・いかにユニークな価値を顧客に創造するか？（価値命題）
　→これは非常に難しい

◇SECIプロセス
・「顧客にいかにユニークな価値を提供するかという命題」にどう応えるか
　→そのための知識を作り続けるのがSECIプロセス
・SECIプロセスとそれを支援するプラットホーム（場）の関係
　→顧客や自社の能力があって、知を利益に変化できる
　→→ここにコスト構造など勘案してビジネスの流れを作る
・これら全てをまとめるのがリーダーシップ（フロネシス）



◆経済モデル・完全情報・知識創造理論

◇20世紀は資本主義の時代
・アダムスミスの『神の見えざる手』
　→企業も個人も自分の利益を追求すればよい
　→→そうすると神の見えざる手が市場を媒介してバランスがとってくれる
　→個人利益の追求が社会の幸福につながるという考え
・その後の経済学を科学的にしたいという流れ
　→このなかで科学的・論理的なモデルが出来ていった
　→『神の見えざる手』を理論的に分析した
・完全情報という仮説の登場
　→互いが完全情報を持っていると仮定する
　→→そうすると、個々のプレーヤーの利益追求によって、論理的・数学的に市場がバランスする

◇「でも…　資本主義が社会の幸福につながるのか？」というのが今の時代
・カール・マルクス
　→このことを最初にいった人
　→「資本主義は資本の蓄積、さらなるお金を求めて永久運動するプロセス」
　→「これは格差をもたらすし、資本家と労働者の搾取モデルになる」
　→「だから階級をなくす革命が必要となる」
・ドラッカー
　→「21世紀は知識創造・ナレッジソサエティの時代」
　→知識というわけの分からないものを経済に落とし込むことが必要
・シュンペーター
　→イノベーションについて初めて言及した
　→「新古典派の考えるような均衡はない」
　→→「均衡ではなく、絶えざる均衡破壊がある。それがイノベーション」
　→→→イノベーションで資本主義を延命させるという考え方
　→マルクスとは対極にいる
・ハイエク
　→「マーケットは単なる競争の場ではない」
　→「顧客のニーズというのは定式化されていない」
　→→「完全情報なんていうものはそもそもない」
　→→→「いかにそういうものを発掘して形式的な知識につなげていくか」
　→→→→「マーケットはそういうものを発見する場」

◇完全情報になっていない部分とは何か
・我々の言葉なら暗黙知
　→『氷山のモデル』
　→→形式知は海に浮かぶわずかな部分
　→→水面下には膨大な暗黙知があり、それが知の源泉になっている
　→マーケットは知の創造の場

◇再びシュンペーター
・彼はある種のペシミズムを持っていた
　→「様々な知を組み合わせ均衡破壊をするのはは企業家・個人と銀行」
・これは組織化の時代になるとサイロ化していく
　→→そうやってできる官僚機構は創造的な個を殺していく
・「企業家が持っている、天職としての倫理を持つ資本主義」
　→ウェーバーが言っていたこと
　→これが金儲けに走るうちに失われてしまう
・それから民主主義にあるポピュリズム
　→ここから来る、ある種の平等感が企業家精神を劣化させてしまう
・そして資本主義は自ら崩壊して社会主義にいくという悲観
　→これがシュンペーターのペシミズム

◇知識創造理論の源泉
・我々が知識創造理論を思いついたのは…
　→組織はクリエイティブでありうると考えたから
　→組織は個の力を増幅させることができると考えたから
　→イノベーションが持続する組織がありうると考えたから
　→→そういう組織をどうやって作るか？という話
　→その1つとしてアジャイル・スクラムも大きな話につながっていくと思う

◇知識という、よくわからない財をどう概念化するか
・知の源泉は自分の主観
　→知は最初からあるものではない
　→知は客観的に与えられるものでも、簡単に組み合わせられるものでもない
・知は情報
　→自分の主観を真理に向かって社会的に正当化していくダイナミックなプロセス
　→→イノベーションは知識創造プロセスであるということ
・知は主観
　→知は人間が介在し解釈するからでてくるもの
・そのための知識創造プロセス = SECIモデル

◇知識創造理論の背後にある考え方
・理想主義のプラトン
　→演繹の父
　→→「真・善・美は天上にある」
　→→「イデアこそ真理」
　→→体は五感の塊だからそれを抜いて考え神に近づく
・実践主義のアリストテレス
　→帰納の父
　→→「イデアは地上にある」
　→→「実践が大事」
　→→BODYが大切
・イデアには簡単に到達できない
　→実践の中で考える必要がある
　→→SCRUMに似ている？
・プラトン以来の知の伝統が、西欧にはある
　→身体を否定して純化するというアイデアが強い
・知識想像の考えが影響力が持つのは何故か
　→そうではない考えが前提にあるから
　→→「身体の知がその前にあって、それが源泉なのではないか」



◆暗黙知・型式知・SECIプロセス・場

◇今まで強かった考え方
・主観的にものをいかに客観的に修正するか
　→客観的・科学的で形式的なものが知識
　→マネジメントもサイエンス
　→→それもいいけど…

◇マイケル・ポラニー
・「われわれは語れる以上のことを知りうる」
・「すべての知識は暗黙的、あるいは暗黙知に根ざす」
　→暗黙知の根底にはBelief（信念）がある
・知るということには個人がコミットしないといけない
　→全身全霊でコミットして、そこから生み出されるのが知
　→→だから信念と暗黙知、信念と理性の関係が必要
・アートとサイエンスがたえずダイナミックにバランスを取っていく中から知が生まれる

◇SECIモデルではどうなのか
・暗黙知と型式知がある
　→どちらが先かという話がある
　→→我々は初めに経験ありきではないかと考える
　→言葉は後
・暗黙知と型式知はおたまじゃくしのように円環する
　→相互に円環しながら膨らんでいくと言うイメージ
・トヨタの偉い人
　→「経験・知覚というのは、五感を想像すれば言語よりはるかに豊かなもの」
　→「でも言語も五感を豊かにする」
　→「両方が弁証する相補的な関係にある」
　→→「One wayではない」

◇暗黙知には瞬時に想像する要素がある
・でもそれは言語化できないといけない
　→言語化を積み重ねていくと言葉が豊かになっていく
・ワインの話
　→ソムリエの田崎氏が、暗黙知と形式知のスパイラルと同じようなことを言っている
　→「暗黙知を豊かにするには、いいワインを飲まないと駄目」
　→「そのとき感じたことをきちんと言語化しないと駄目」
　→「顧客とは一期一会なので、あった瞬間に現在・過去・未来を瞬時に想像できないと駄目」
　→→暗黙知があると予見能力が高まる
・でも暗黙知がたくさんあるだけでは駄目
　→それは言葉で語らなくてはいけない
　→→言語化を積み重ねることで、本質的な言語化（メタファーやレトリックを使った感覚的で詩的な言語）に至る
　→言葉にすることでスパイラルアップできる

◇SECIモデルでは
・共感→概念化→モデル化→実践のフェーズを経る
　→チームの知が組織の知へ
　→それが個に返りつき、さらに大きな知へ
・スパイラルにすることでもっと大きな知を想像できる
　→知を組織的に作るモデル

◇イノベーションはSECIスパイラルである
・共同化→表出化→連結化→内面化
・『相手の視点に立ったときの気付き』がないと本質には辿りつかない
　→本質は見えないので対話を通じて徹底的に考えないといけない
・それをコンセプトに凝縮して、関係付けして、量モデル化して、徹底的に分析する
　→そして技術・経験・サービスなどに価値化
　→→知を血肉化（内面化）して暗黙知化するということ
　→これは（結果として）組織や市場の新たな知を提供することになる
　→→これが新たな知を触発する
　→→→この新たな知をまた共同化する
・この反応を絶えず生み出す

◇この反応が生み出される状態をどうやって目指すか
・個人を殺さず、個人を活かし、個人ではできない知を創造する状態
　→こういったものをきちんと量モデル化しないといけない
　→→そのためには場（プラットホーム）が必要
・どういう場である必要があるか
　→コンテキストがあるもの
　→スパイラルアップするようなもの
・場の文脈は常に動いている
　→動いている文脈を共有できるのがダイナミックな場
　→そういう場で、皆の主観(Belief)を出す
・場を『皆の主観の場』にする
　→思いは言葉、言葉は形にしないと共有できない
・全人的に向き合うことで自己を超える我々の主観を生み出す
　→そのためにコンテキストがとても重要だということ

◇言葉の意味は、インタラクションの中でしか分からない
・「けっこうです」
　→"いる"ということ？
　→"いらない"ということ？
・言語学の関連性理論でのコンテキストの定義
　→「お互いの発話の解釈の手助けになる、聞き手の頭の中にあるAssumptionsのこと」
・アジャイルやスクラムもそう
　→顧客とのインタラクションの中でどう解釈するか
　→→ここでAssumptionが出てくる
　→→それを対話の中で共有しながら新しいAssumptionを作り出していく
・場 = 動いているコンテキストを共有するところ
　→そして知を生み出せるところ



◆身体・体験・ビジネスモデル

◇もう1つの重要なこと
・合意形成について
　→皆の主観（相互主観性）を作り上げるプロセス
　→→この中でベースになるのは身体

◇身体のタッチ（メルロ・ポンティ）
・身体感覚は相互に浸透する ： 間身体性
　→右手で左手に触る
　→→しばらくすると左手からも右手を触っていることを感じる
・Embodied Mind（フランシスコ・ヴァレラ）
　→ボディとマインドは分けられない
・ミラーニューロンの発見
　→他人のしていることを自分がしていることのように感じる細胞
　→→模倣すると相手の意図が読める

◇共感の土台が重要だということ
・我々は生まれつき共感を覚えるように出来ている
　→マズローの自己実現理論の上には、コミュニティを作るというニーズがあるということ
・場の根底にあるもの
　→タッチも含めた身体的・精神的な触れ合い
　→→Socializationにおける重要な概念
・マーク・ザッカーバーグの提唱するエコシステム
　→「2人の人間のインタラクションの場（社会の基盤）を作る」
　→「それを繋げてもっと大きな場を作る」
　→「究極的には大きなイノベーションを作る」
　→「最終的に大きなHapinessにしていく」
　→「単なるマーケットを越えてコミュニケーションする関係を作る」
・でも組織が直接インタラクションすることはできない
　→実際にやるのは個人
　→→場を作ることとそれをスピーディにやることが重要

◇なんのために知を想像するのか
・最終的には"Common Good"
・もっと具体的には価値命題とビジネスモデル
　→いかにユニークな価値を創造するか
・ビジネスモデル = 知を価値・利益に変換すること
・　「コトづくりのためのモノづくり」
　→ユニークなコトを提供するためにはユニークなモノが必要
・コトから入っていった方が大きな経験価値を与えるモノを作れる
　→音楽配信という経験価値を与えるためにモノを作る
　→→モノは体験を提供するためのもの
・「iPodというモノはマルチメディアの視聴という体験（コト）を与えるためのものである」
　→ここまでコンセプトをクリアにする
　→→これがわかれば、誰が顧客でどんなユニークな価値を提供するべきかが分かる

◇顧客にユニークな価値を提供するためには
・流通の最先端、顧客の最前線まで行ってきちんと意味を伝えないといけない
　→絶えず価値命題は変化している
　→→最先端で顧客から学び、それをフィードバックサイクルの中に入れる

◇ビジネスモデルについて
・知識ベースでの基本的な考え方
　1. いかなるコトを与えるのか
　2. 顧客は誰か
　3. 能力（能力・知力）はあるか
　→→（どこをクローズドに、どこをオープンにするか）
　4. コスト構造
　5. それで利益を考える
・（ポーターの）伝統的な戦略論での考え方
　→極力競争しない
　→差別化して参入障壁を高める
　→価格決定権を渡さない
　→→サプライヤのパワーを高め、顧客のそれを低める
・伝統的な戦略論の目的
　→既存の市場をいかに守るか
　→競争の少ない市場を作るかというもの
　→→こういうのもが支配的だった
・ドラッカーがそうではないといった
　→「企業のミッションは顧客の創造である」
　→→そういう意味で顧客創造・価値命題がでてくる

◇今はイノベーション系のビジネス思想家の影響力が高まっている
・ナレッジベースはいかにユニークな価値を提供するかのために有効
　→バリューは主観的
・戦略 = いかに1人1人の主観・価値を合意形成して自分の真理に向かって実現していくか
　→だから戦略以上に重要なのは組織であり人・最近、ポーターのコンサルティング会社が倒産した
　→価値命題が非常に重要になってきているということ

◇コトで世界を作る
・名詞ではなく動詞でとらえる
　→絶えずダイナミックな関係性を洞察する
　→動きながら考える
　→→SCRUMのプロセスがやろうとしていること
・ここで全てを総合するリーダーシップが重要になってくる

（後半へ続く）






野中郁次郎様、平鍋健児様、Scrum Alliance Regional Gathering Tokyo 2013 実行委員会様、翔泳社様、ありがとうございました。

『スクラム道 EXPO 2012 - 午後のセッション』ノート - 1 / 2

2012/10/28に開催された『スクラム道 EXPO 2012』午後のセッションのノートのパート1です。

パート2はこちら

◆高橋 一貴氏「スクラムマスター思い出語り」

◇アジャイルコーチをやっている

・自分は推進係

　→知らないところで好きにやっていたりする

・昔は壁に張り物がなかった

　→今は場所取りが必要なくらいになっている

◇スクラムマスターって？

"スクラムマスターは、スクラムチームとのやり取りで役に立つこと／立たないことをスクラムチームの外部の人たちに理解してもらうようにする。

スクラムマスターは、みんなのやり取りを変えてもらうことで、スクラムチームの作る価値を最大化するのである。"

 - (Ken Schwaber and Jeff Sutherland､ Scrum Guide)

　→みんなのやり取りを変えてもらうことでスクラムチームの作る価値を最大化する

◇最初はわからないことだらけ

・スクラムマスターについて

　→どこまで理解しておけば？

　→チームとの関わり方のコツは？

・どこから始めれば？

　→『塹壕より Scrum と XP』を読んだ

　→→今だと若干古いところがあるので注意

◇失敗

・Excelでスプリントバックログとプロダクトバックログを一元管理

　→プロダクトバックログのアイテムの下にインデントでタスクを並べる

・個人別にバーンダウンチャート

　→個人の遅れもばっちり把握

・フロントエンドとバックエンドでチームをわける

　→効率的な分業

・スクラムマスターがタスクをアサインした

　→抜け盛れを防ぐ

・レビュー完了はスクラムマスターが判断

　→確実な品質確保を

・詳細仕様をプロダクトオーナーに承認してもらう

　→外部仕様より先の話

・ミーティングはスクラムマスターがどんどん発言

　→進行も決定も効率的に

　→自分の意見もどんどん言う

◇こういうことをしているといろいろ変になる

・タスクの残量が把握できない

　→並べてあるから見える化

　→→全体量が分からない

　→→メンテナンスが大変

・遅れている人を問いたださないといけない

　→いつも遅れている人に余計なプレッシャー

・堂々巡り

　→「バックエンドが終わってないから画面作れない」

　→「いやいやフロントエンドが終わってないから見せられない」

・追加タスクが申告されない

　→バーンダウンチャートが増えるだけだから隠してしまう

・自分のところでレビューが溜まりすぎる

・POと話がかみ合わない

・チームから活気が消えた

◇どうなったか

・葬式のような振り返り

　→ミーティング全てお葬式に

　→→こんなはずではなかった

◇もう一度定義をよく見直した

・スクラムの理解と成立のために

　→皆のやり取りを変えてもらう

　→→スクラムチームの外側ステークホルダーに理解と行動を促す

　→→→個々の作業に関与しすぎるからうまくいかない？

◇やり方を変えた

・手法や環境へ働きかける形へ

　→作ったものや個人ではなく、全体的な視点で

・スプリントバックログは付箋とペンで

　→『塹壕より Scrum と XP』どおりにやってみた

　→→一覧性がぜんぜん違う。何が起こったかすぐわかる

・チーム全体のバーンダウンチャートのみに

　→チームを解散させたいなら個人別バーンダウンチャートがオススメ

・チームはクロスファンクションで組成し直し

・放置・滞留しているタスクに気付いてもらうように

　→「しばらく貼りっぱなしだけどどうしたの？」

　→→意外と話してくれる

　→→→フィードバックすれば自主的にやってくれる

・レビューはチームで完結

　→実施有無とレビュー観点のみ見る

　→後はチームに任せる

・詳細仕様は求められた場合のみ説明

　→プロダクトオーナーはデータベースとかに興味ない

・ミーティングへの貢献の仕方を変える

　→ゴールとアジェンダを必ず用意

　→→参加者に手伝ってもらうつもりで

　→進行のコントロールに徹する

　→→内容には干渉しない

　→→→"誰が喋るか"を決めては駄目。"誰から喋るか"を決めるのはよい

◇大事だと思うこと

・いっぱい勉強してやってみる

　→今はいろいろなところで話を聞ける

・『自分が信頼している人に見せる態度』でみんなに接する

　→ノーガードで飛び込んでしまう

　→→ガチで殴ってくる人はいない

　→チームの少々の混乱は覚悟しておく

・Be Nice

　→いい人のいいところを容赦なく真似る

◇変えられないものを受け入れる

・変えられるものは変える

　→そこはあきらめない

・判断できる力をつける

高橋 一貴様、スクラム道様、ありがとうございました。

『スクラム道 EXPO 2012 - 午前のセッション』ノート

2012/10/28に開催された『スクラム道 EXPO 2012』午前のセッションのノートです。


◆和田　卓人氏「ペアプログラミング ホントのところ」

◇質問「ペアプロすべきか？」
・答え「状況による」
　→それはずるい
　→→経験者としてそういう結論になるのはわかるが…
・ペアプロは議論を巻き起こす
・見た目も派手

◇ペアプログラミングって何？
・書籍「プログラマが知るべき97のこと」
　→「いかに周りの人とお客と仕事をするか」という中身が詰まっている
　→→プログラマは技術が優れいてるだけでは充分ではない
　→→他人との連携でより大きな成果が上げられるようでなければならない
・2人で1つのマシン、1つのキーボード
　→ドライバとナビゲータ
　→2人でコラボレーション
・いろいろなイベントではモヒカンが切りあう形になっている
　→それも面白いが…
　→チーム（ペア）でプログラミングするもの

◇ペアプロをやっている人の結論
・外国でやっている人も国内でやっている人（自分）同じような結論に至る
・やっている人とそうでない人ではイメージがだいぶ違う

◇ペアプロの利点
・規律の強化
　→1人だとサボったり、コーディング規約が億劫になったりする
　→→1人だと悪魔のささやきに負けやすい
　→→2人でコードを書いているときは天使の方が勝る
　→ペアプロ中ってtwitterやネットサーフィンをしない
　→→仕事モードになっている
　→→→仕事と休みのメリハリが付きやすい
・より良いコード
　→品質は上がっていく
　→→すぐ隣にそのコード使う人がいる
　→→フィードバックが非常に早い
　→→→それが良い効果をもたらす
　→ペアは最小のチーム
　→→シンプルさはチームが決めるもの
　→→→複雑なコードは書かなくなる
　→力技でこなす「動けばよい」みたいなコードも書かなくなる
・快活なフロー状態
　→1人と2人とでは深く集中した状態（フロー）が異なる
　→→ペアならではでのフローがある
　→→→1人のときとは異なるフローの状態に入れる
・チームの士気向上
　→ペアプロをすると部屋が無言ではなくなる
　→会話をしていくことがチームの仲の良さ
　→→情報が伝わりやすくなる
　→→→チームがよりよい方向に行く
・コードの共同所有
　→プロダクトコードに持ち主がいない状態
　→→少なくとも2人は知っている状態
　→「ある個人しか知らない」というのはない
　→→保守性が高まる
・学習効果
　→ペアプロはばらつきを一番早く吸収できる
　→→エディタ・開発環境・ネーミングなどなど
　→教える側は知識の整理などが必要
　→→教える側にも学びがある
・チームの一体化
　→チームが同じ方向に進むという方向付けがやりやすい
・割り込み削減
　→ペアプロ中の人には割り込みにくいという調査結果
・つまり…
　→教わる側は当然学べる
　→教える側は滅多なことは言えなくなる
　→→実は教える側の方が学べる

◇1人でプログラミングするのと、2人でするのとの違い
・最大の違いは"喋るか喋らないか"
　→この差は非常に大きい
　→→1人の場合、考えてコードに落として　…というのをグルグル回す
　→→2人の場合、声に出すので頭の中をもう一段整理しないといけない
　→Rubber Duckingという手法もある

◇機能しないとき
・管理者はハードウェアに投資したくない
・現場がペアプロに最適化されていない
　→机の並び方など
・現場では従来型の雇用方法を採用している
　→覚悟や適正など、ペアプロに向いたプログラマーを雇っていない
・現場では反社会的な行動を大目に見る
　→コーディング規約に従わない
　→ペアプロやらなくても「プログラマはそういうものだから」で看過されてしまう
・ペア作業の生産性が理解されていない
　→「生産性が半分になるじゃないか」という管理者の意見
　→→生産性は2割増しくらいになる
　→→仕様・スキルの伝達・Better Codeなどの生産性がある
　→ペアプロにはペアプロの生産性がある
　→→なかなか理解されない
・現場では的確でない開発者を雇っている
・現場は過労と人員不足に陥っている
　→「この期に及んで二人でコードを書くなんて」
・開発者は一緒に仕事をしている人達全員を好いているわけではない
・開発者はそのような面倒なことをしたいとは思わない
・たいていのソフトウェアの現場では、優秀さのことを本当は気にかけていない

◇ペアプログラミングをエゴの問題
・角谷さんとKent Beckさんとのやりとり
　→ペアプロするとき自分のキー配列とかの好みはどうする？
　→→「おまえの好みとチームの成功とで大事なのはどっち?」
・ワインバーグによるエゴレスプログラミングの十戒

◇ペアプロを入れるかどうか
・結局はIt depends.
　→気に入らない人という人も一度やってみると即座に気に入る（塹壕とScrum本）
　→→（結局）8割は気に入る
　→→それでも2割には通じない

◇ペアプロは楽しい
・楽しいのが一番
　→「楽しい」はものごとを前に進めるためのプリミティブな原動力



◆吉羽 龍太郎氏「Doneの定義 虎の巻（再演）」

◇出荷可能な製品とは？
・Doneの定義
　→実施しなければいけないことの一覧
　→→プロジェクトとして定めた『出荷可能な製品』を作るため

◇（個人的には）次の単位でDoneを定義したりする
・バックログ単位
・スプリント単位
・リリース単位

◇何が出来たら完了なのかを決めるもの
・どこまでやったら終わりかが分からずにやると…
　→悲惨なことになる
　→→だからゴールを決めてからやる

◇手戻り
・本人だけできていないつもりで延々と作りこむ
　→時間の無駄が発生
　→→（ex. 誰が見るのか分からないのに、一生懸命レイアウトを整える）
・本来やっていないといけないことをやり忘れる
　→セキュリティとか考えずにとりあえず作る
　→→後でセキュリティホールが見つかったりする

◇アジャイルな進捗の判断は0 or 1
・ウォーターフォールは80%などあるが、アジャイルにはない
　→アジャイルでは、できたか、できていないか
　→アジャイルは判断が必要ということ
　→→その基準がDoneの定義
・バーンダウンチャートの数字が信用できる理由は？
　→Doneの定義に従って進めているから
　→Doneの定義がないと見せかけの進捗でごまかせてしまう

◇プロダクトバックログの受け入れ基準との違い
・受け入れ基準とは
　→どこまでできたら終わりか？を書くもの
　→→機能要件適合性の判定のためのもの

◇体験談
・悪い受け入れ基準
　→『ソースコードが綺麗なこと』
　→→あやふや
・良い受け入れ基準
　→ソースコードをCheckStyleで検証し、重要度N以上の違反がないこと
　→→全員が合意できる
・変な基準を強制される
　→品質はコンテキストに寄る
　→→金融・医療・ウェブでは異なる
　→→→社内品質基準は顧客の期待と関係ない
　→そもそもゴージャスすぎる
・守っているかどうか判断できない
・そもそも定義の中身を知らない

◇Doneの定義を守れない理由
・なぜの分析が足りない
・別の圧力に負けれる（スコープの圧力など）
・チームがオーバーコミット
・そもそもDoneの定義が曖昧

◇どうやって改善するか？
・振り返りで改善
　→プロセスが改善されることでDoneの定義が変わっていく
　→1スプリント目と10スプリント目で同じなのは逆にやばい
　→→それは、従来のウォーターフォールの書き方を変えただけ
　→プロセスは自分達で変えることができないといけない

◇Doneの定義の更新
・自明のDoneは外す
　→チームが成熟するとでてくる
　→→もっと進むと『リリースのDoneの定義』をスプリント内でやれたりする
　→→→でもやりすぎには注意

◇Doneの定義の縮小
・気をつけなければいけないこと
　→明確に守れていないものを外すのはまずい
　→→本当に顧客の期待に応えられているかを考える

◇Doneの定義充足の検証
・Doneの定義を見ればチームの技術力がわかる
　→自動化できるものは自動で
　→→より本質的なものに時間が使えるようになる

◇Doneの定義をいつ決めるか？
・見積もりや契約の前に大枠が決まっているべき
　→そうでないと工数がぜんぜん異なる
・誰が決める
　→プロダクトオーナー + スクラムマスター + チーム
　→→プロダクトオーナーは外部のステークホルダーの声も聞く
・決め方
　→必要な作業を付箋に書き出す
　→実施タイミング(Release, Sprint, etc.)でグループ分け
　→リスト化して印刷して、皆が持つ

◇荒ぶる四天王
・品質は固定パラメータ
　→スコープ達成の圧力に負けない

◇大事だと思うこと
・プロジェクト開始時点で決める
・スプリントで全部やろうとしない（最初は無理）
・チームが成熟したら拡張
・品質は固定パラメータ
・途中で縮小しない
・自動で検証
・定義をみんな知っている


◆市谷 聡啓氏「Your Mind is the Scene of Development」

◇なぜインセプションデッキ？
・プロジェクトに然るべき人が集まっているかを確認
　→いないと後で話が変わる
・プロジェクトがしかるべき方向を向いているかを確認
・「チームメンバーが誰もいないところで合意したことを前提にしているからプロジェクトがダメになる(The Agile Samurai)」

◇インセプションデッキとは
・10個の問いから構成されている

◇いつデッキを作るか？
・プロジェクトキックオフ？　最初のイテレーション？
　→それでは遅すぎる
・契約前、予算取り前
　→検討する段階で作る
　→正しい制約を作るために

◇予算が確定した後にデッキを作るにしても、プロジェクトの前提は後からは動かしにくい
・だからステルスデッキ（受注前のインセプションデッキ）
　→前提を作る
　→目的に適した制約を作り、プロジェクトを開始する

◇プロジェクト開始前・開始後で進め方が違う
・開始前（ステルスデッキ）
　→ステークホルダーにはインセプションデッキとあえて言わない
　→→相手の期待値が上がる
　→あくまで制約をあぶりだすための仕掛け
・開始後（インセプションデッキ）
　→目的を明らかにして作る
　→→プロジェクトの方向を明らかにするために

◇インセプションデッキのCRUD
・Create
　→プロジェクト開始前と後
・Read
　→最初はデッキの内容のチームへの定着を図る
　→→週一回全員で点検するなど
・Update
　→デッキの更新はプロジェクトの方向が変わるということ
　→→その認識を併せる
・Delete
　→デッキが用を成さなくなったとき

◇ゴールデンサークル
・why, how, whatの順で考える
　→インセプションデッキの前半5枚がwhy
　→後半5枚がhow
　→ユーザストーリがwhat
・howが変わる
　→インセプションデッキに影響が及んでくる
・whyが変わる
　→プロジェクトの方向が変わる
　→→ステークホルダーが認識しているかを確認
　→→→プロジェクト全体で判断し合意する

◇インセプションデッキの弱点
・whoが弱い
　→エレベータピッチの「対象顧客向け」しかない
・whyを考えるためにはwhoは必要

◇エレベータピッチ
・whoの分だけエレベータピッチを考え、作る
　→ターゲットが複数
　→→ニーズが複数ということ
・複数ニーズに対してプロダクトは1個でよいのか？
　→そういう疑問をステークホルダーと話し合う

◇やることやらないことリスト
・いきなりやらないことを出すのは難しい
・目的
　→スコープを明らかにする
　→加えて、開発への期待を明らかにするためにも使える
　→→開発の苦い経験を明らかにしてもらう
　→→ここを見誤ると、この後の開発での相手の期待がわからなくなる

◇プロジェクトコミュニティ
・誰がどういう理由でソフトウェア開発に関与するのか、気付くのは案外難しい
　→顧客には顧客組織が分かる
　→開発は開発の人しかわからない
　→→コミュニティを明らかにする必要がある
・開発のよくある役割を確認する
　→顧客に過去の開発であった役割を思い出してもらう

◇重要なこと
・練習重要
　→本番は本番の結果を出さないといけない
・質問力重要
　→良質な問いかけがプロジェクトの行く末を左右する
　→→アクションラーニングオススメ





和田 卓人様, 吉羽 龍太郎様, 市谷 聡啓様, スクラム道様、ありがとうございました。

『第32回すくすくスクラム 〜スクラムを学ぶ方法〜』ノート

2012/06/29に開催された『第32回すくすくスクラム 〜スクラムを学ぶ方法〜』のノートです。
"スクラムを学ぶにあたって直面するであろういくつかのケースの中から、自分が話したいケースについてグループを作り、グループ毎に話し合いを行う"というのを2セット行いました。

自分が参加したテーブルの話だけでも、持ち帰れるものがいろいろありました。なのでつい油断してしまったのですが、各テーブルの話し合いの内容については、全く気に留めていなかったという　…自分のノートを整理しているときも、それぞれグループ毎にどんな話をしていたのだろうか、ということがたびたび気になりました。勉強会が終った後に皆でしばらく雑談する時間があったので、そのときに聞いて周ればよかったと思いました。せめて成果物（模造紙）の写真くらい撮っていれば　…誰かのノートに期待します。



◆勉強会の大まかな流れ

1. 勉強会の趣旨の説明
2. ウォームアップ
3. 話し合いのテーマ
4. 話し合いその1
5. 話し合いその2
6. まとめ
7. 勉強会（紹介）LT




◆今日のテーマ"スクラムを学ぶ方法"について

・"Scrumをやる"話ではない
・スクラムやアジャイルで「お客様が何かを作りたい」というときに何をしたらいいのか？というのを学ぶ。
・Scrumの開発手法を現場に導入するためには何が必要なのだろうか？


◇背後にある考え方

・"導入する"ことは現場に非常に依存する
・声の大きい人、力の強い人、同僚にだいぶ依存する
・それを乗り越えることが導入するために必要な要素のうちのひとつである



◆忘れないでほしいこと

・一人で仕事をしているわけではない
・誰のためにものを作るのか？という視点
・Scrumを導入することを目的としてはいけない



◆次のケースから、話し合いたいテーマを決めます

・1. 社内で一人で始めようとするケース
　・1-a. なにから初めて良いかわからない
　・1-b. 上の人をうまく説得できない
　・1-c. スクラムが全ての問題を解決してくれる

・2. 上から言われて、はじめるケース
　・2-a. 権限委譲してくれない
　・2-b. 上司の解釈と微妙に異なる

・3. 誰かと一緒に始めようとするケース
　・3-a. なにから始めてよいかわからない
　・3-b. 友達と解釈が異なる

・4. すでにAgileって言っている人がいる
　・4-a. スクラムマスターがPM
　・4-b. ツールやプラクティスの話しかしない

・5. お客様にはWFといっている場合

・6. 完璧なAgileの開発をしたい

・7. お客様にScrumでやってほしいといわれた

・8. なぜScrumが良いのか分からない

・9. 巻き込み力が足りない



◆話し合い1回目 / なにから始めてよいかわからない

◇考え方
・アジャイルは『ある』『ない』ではなくて度合い
・マインド重要


◇始める
・チームに問題意識があったときに手法を入れるときはうまくいく
・いいタイミングで仕掛けるとアジャイルよくね？と思う人が増える
・先輩に働きかけてそこから推進してもらう


◇問題について
・（問題があるのにそれを）問題だって思ってないことが問題
・（漠然と認識を共有している事柄について）声に出して話をすることは重要
・問題がないところでやっても意味ない。相手がやらされ感を持ってしまう
・問題じゃないときにアジャイルを入れていくのは怖い


◇未解決の疑問
・アジャイルじゃない人が沢山入ってくるときどうするか？
・問題を表面化させることが必要？


◇プラクティスについて
・（スプリントで）実現するフィーチャを決めても、緊急の対応でぐだぐだになる
・インセプションデッキは作るのに時間がかかるけど重要
・コミュニケーションの問題でプロジェクトが炎上した。振り返った結果、朝会をすることになり、それで上手くいった
・バックログが一杯になったら減らすことを決める
→「いらないからやめよう」だと喜ぶ
・フィ－チャ作るチームと既存の問題に対応するチームに分けると、割り込みを回避できる
→でも人数が少ないとそれはできない
・少数人数のチームで一週間毎の振り返りは期間が短い
・振り返りはすごい重要。振り返るとすごいアジャイルになる



◆話し合い2回目 / 巻き込み力が足りない

◇巻き込む自分
・ある程度身銭を切って見せる。そこまでやらないとのってこない
・興味を持った人を引き込む
・根気良く伝えていくと伝わる
・自分がわからないことを押し付けてはいけない。
・誘いのうまい先輩のスキルを盗み、巻き込み力のある人になる


◇巻き込まれる相手
・かっこいい先輩がいると、学ぼうという気になる
・どういう人に働きかけるかによってアプローチが違う
・巻き込み力がある人を巻き込む
・（周囲が受動的な場合）自分がアジャイルできることが前提。やって見せたり、フォローできることが大事
・（周囲が能動的な場合）一緒に学んでいくやり方でもよい


◇巻き込むこと
・ワークショップの写真を見せると興味を持ってもらえる
・信頼をどれだけ稼ぐかが大事。巻き込むというより引っ張っていく
・本を配っても興味ない人はそもそも読まない
・楽しそうな感じを見せることが大事


◇価値観
・うまくいかなかったらやり方を変えたり対象から外す
・休みの日まで仕事のことと嫌がる人はいる
・楽しくないことは続けられないが、成功体験を与えることで続けてもらえる


◇組織
・なんちゃってアジャイルでメタメタになったところは、アジャイルに拒否反応を示す
・社内のあちこちに仲間がいても、各自ばらばらのプロジェクトだと苦戦する
・上司を説得することが重要
・大事なのは強敵と戦わないこと


◇アジャイルについて
・"アジャイルが良い"とは言わない
・"うまくいったこのやり方、実はアジャイル"と持っていく
・アジャイルがバズワード化している
→興味がある人ならアジャイルといってもいい
・そもそもアジャイルはスタンスなので、名前を出す必要はない
・これをやったらアジャイルというのものはない



◆勉強会紹介

◇スクラム道

◇スクラムプロダクトオーナー勉強会

◇すくすくスクラム






すくすくスクラム様、VOYAGE GROUP アジャイル戦略室様、ありがとうございました。