Slide 1
Slide 1 text
アジャイル開発の時代
川口 恭伸
アギレルゴコンサルティング株式会社 シニアアジャイルコーチ
株式会社ホロラボ シニアアジャイルコーチ
一般社団法人スクラムギャザリング東京実行委員会 代表理事
一般社団法人 DevOpsDays Tokyo 代表理事
Slide 2
Slide 2 text
川口 恭伸
かわぐち やすのぶ
Twitter: @kawaguti
アギレルゴコンサルティング株式会社 シニアアジャイルコーチ
株式会社ホロラボシニアアジャイルコーチ
一般社団法人スクラムギャザリング東京実行委員会 代表理事
一般社団法人 DevOpsDays Tokyo 代表理事
Slide 3
Slide 3 text
研修やってます
アギレルゴアジャイル研修
検索
Slide 4
Slide 4 text
No content
Slide 5
Slide 5 text
ソフトウェアの品質ってなんでしょう？
30年前なら、動いていれば
よかったかもしれないけど、
今は、きれいに整理されていて、
メンテナンスしやすいことが必要。
どうやったら変更しにくくなる？
…を考える(たぶん数値では測れない)
Slide 6
Slide 6 text
No content
Slide 7
Slide 7 text
この本が扱うのは人間だ。
それもソフトウェアを書く人間である。
ここ10年ほどの間、我々は、
共同作業によってソフトウェアを
生み出す方法について研究してきた。
優れたソフトウェアを効率的に
次々と生み出す能力に関心が
あるのだ。
Slide 8
Slide 8 text
No content
Slide 9
Slide 9 text
それでは、スクラムマスターの
⽬標とはなんでしょうか？
スクラムマスターは⾃⼰組織化した
チームを構築し、企業のあらゆる階層で
基本原則として⾃⼰組織化が⾏われるよう
努⼒します。⾃⼰組織化は当事者意識と責
任感をもたらします。
その結果、⼈々はより活動的になり、
説明責任を果たすようになります。
さらに、チームメンバーは⾃分たちなりの
解決法を考え出す機会を持つようになり、
グループ全体をもっと効率的にします。
Slide 10
Slide 10 text
おじゃる様問題
Slide 11
Slide 11 text
おじゃる様とは？
技術や現場担当者の
ことがよくわからない
マネジメントの方
Slide 12
Slide 12 text
おじゃる様とは？
以前は、はげちゃびんと
呼んでいたのですが、
特定の容姿批判に感じ
るということで改題
マリーアントワネットに
しようとしたのですが、
どうもピンとこないので
改題
Slide 13
Slide 13 text
おじゃる様とは？
技術や現場担当者の
ことがよくわからない
マネジメントの方
Slide 14
Slide 14 text
一般的な傾向
すこぶる優秀。
議論に負けることはまずない。
情報収集を怠ることもなく、
メンタルもフィジカルもタフ。
複雑な概念を一言で表したり
わかりやすい例を挙げて
説明することが得意。
Slide 15
Slide 15 text
←ちなみに、
この絵のモデルは
菅原道真公…超優秀
Slide 16
Slide 16 text
日本企業では、
組織階層の上にいくと
どこかでおじゃる様に
当たることが多い。
Slide 17
Slide 17 text
超優秀な人は
時間がないので、
資料がちゃんと
できているかを見る
ことで相手の思考を
チェックします
Slide 18
Slide 18 text
そのため、
「わからない人にも
説明できる」
ちゃんとした資料作りが
求められがち
Slide 19
Slide 19 text
作る人 報告する人 説明する人 聞く人
伝言ゲーム問題
Slide 20
Slide 20 text
「その資料、
私ならわかるけど、
はじめて読む人に
伝わらんだろう。」
…とか言われる。
※実際はそんな人は読まないので過剰品質を呼びますね。
Slide 21
Slide 21 text
作る人 説明する人 聞く人
伝言ゲーム問題
だってさ
Slide 22
Slide 22 text
教育心理学概論 新訂 (放送大学教材) [全集叢書]
三宅 芳雄(著)、三宅 なほみ(著)
経験から固めた「経験則」
(素朴理論)
学校で教える原理原則
科学的概念
自分で考えて言葉にすると
はじめてつながる
より適用範囲の広い、
抽象度の高い知識
Slide 23
Slide 23 text
教育心理学概論 新訂 (放送大学教材) [全集叢書]
三宅 芳雄(著)、三宅 なほみ(著)
経験から固めた「経験則」
(素朴理論)
学校で教える原理原則
科学的概念
自分で考えて言葉にすると
はじめてつながる
より適用範囲の広い、
抽象度の高い知識
わかりやすい説明が生む
バブル型理解
Slide 24
Slide 24 text
理解にはレベルがある
https://onlinelibrary.wiley.com/doi/abs/10.1207/s15516709cog1002_2
Constructive Interaction and the Iterative Process of Understanding
(建設的相互作用と
理解の反復プロセス)
三宅なほみ 1986
0. ミシンは縫うものだ
1. 上糸と下糸が結びつく
2. 下糸は上糸の輪をまたぐ
3. 輪がボビンの周りを回る
4. ボビンの構造は空間を与える
5. ホルダはカラーに固定される
Slide 25
Slide 25 text
下向きの批判は、評価的な批判とい
うよりは、「不満」と考えたほうが
いいかもしれません。批判する側が
提案されたメカニズムを理解できな
いということなのでしょう。しかし、
重要なのは、これらの批判によって、
より理解力のある相手が、メカニズ
ムを探し続けなければならなくなっ
たということです。
「わからない」というフィードバックが重要
https://onlinelibrary.wiley.com/doi/abs/10.1207/s15516709cog1002_2
Constructive Interaction and the Iterative Process of Understanding
(建設的相互作用と
理解の反復プロセス)
三宅なほみ 1986
Slide 26
Slide 26 text
教育心理学概論 新訂 (放送大学教材) [全集叢書]
三宅 芳雄(著)、三宅 なほみ(著)
経験から固めた「経験則」
(素朴理論)
学校で教える原理原則
科学的概念
自分で考えて言葉にすると
はじめてつながる
より適用範囲の広い、
抽象度の高い知識
わかりやすい説明が生む
バブル型理解
ポプテピピック
(C) 大川ぶくぶ, 竹書房
Slide 27
Slide 27 text
作る人 報告する人 説明する人 聞く人
おじゃる様問題の怖いところ
わかりやすい資料を作ることによって
わからない人が経営できるようになる。
Slide 28
Slide 28 text
小作人 庄屋 武士 殿
中世の貴族制度に似てる
Slide 29
Slide 29 text
世の中そんなものだ
と思っていた。
Slide 30
Slide 30 text
作る人 報告する人 説明する人 聞く人
しかし、そうではない世界があった
Slide 31
Slide 31 text
G A A M
F
おじゃる様のいない新世界の五皇
Slide 32
Slide 32 text
上司の上司を
さかのぼっても
エンジニア出身者
ばかりの組織がある
Slide 33
Slide 33 text
https://logmi.jp/tech/articles/320413
米Microsoftで働く日本人エンジニアが語る、
“楽しく開発”するために必要なこと - Part1
Slide 34
Slide 34 text
我々ソフトウェアエンジニアが、設計、実装、
あとはクラウドだったらデプロイから運用ま
で全部、最初から考えてコードを書きます。
運用も責任の一部なので、テレメトリを見て
例外が起きていたら、当然自分が直す。どう
いうテレメトリを埋め込めばいいか決めるの
も自分の責任です。
https://logmi.jp/tech/articles/320413
米Microsoftで働く日本人エンジニアが語る、
“楽しく開発”するために必要なこと - Part1
Slide 35
Slide 35 text
クラウドって、いろんなサービスの大きな集合体なの
で、自分のところを（ダウンさせずに）動かし続ける
しかないんです。ほかのサービスが一時的にダウンし
ても、当たり前に動かします。ネットワークが切れた
り、毎日どこかが壊れるんです。そういう中でも毎日
動かしつづけるためには、テレメトリの運用、あとは、
そういうのをあらかじめ全部考えた上での運用方法の
確立というのは、絶対に必要です。
https://logmi.jp/tech/articles/320413
米Microsoftで働く日本人エンジニアが語る、
“楽しく開発”するために必要なこと - Part1
Slide 36
Slide 36 text
ソースコードって、要はいろんな人たちの知識の蓄積
なんです。これに対して読んだり、自分がアクセスで
きて、なおかつそれに対してコントリビューション、
チェックインすることができる。これはものすごく素
晴らしいことだと思うんです。アウトソースするなん
てもったいない。これこそが我々の知識の集約。それ
を読めるということがもう、僕にとってはたまらない
です。そういう権限を会社が与えてくれていることは、
すごく大きな信頼感につながっています。
https://logmi.jp/tech/articles/320413
米Microsoftで働く日本人エンジニアが語る、
“楽しく開発”するために必要なこと - Part1
Slide 37
Slide 37 text
https://www.slideshare.net/WinOpsConf/sam-
guckenheimer-moving-to-one-engineering-system
https://www.youtube.com/watch?
v=8EN1kGFmiIo
Slide 38
Slide 38 text
Microsoftの組織図
(〜2011)
意図しない結果 :
再利用さえしなければ
怒られることはない
https://www.slideshare.net/WinOpsConf/sam-
guckenheimer-moving-to-one-engineering-system
Slide 39
Slide 39 text
開発システム統合の目的
エンジニアやプロダクトチームにとって
生産性を向上する以上に大事な
ことはありません。
ですから、週のどの日においても
機能を犠牲にしてでも
生産性を上げたい。
自社の最高のエンジニアたちに
この開発システムで働いてほしいと
私は考えています。
その結果、長い目で見れば、
私たちが望む新しいコンセプトは
すべて実現できるでしょう。
https://www.slideshare.net/WinOpsConf/sam-
guckenheimer-moving-to-one-engineering-system
Slide 40
Slide 40 text
エンジニアリングの目指すべき星
• 全社のソースコードはだれにでも利用可能
• 開発者はだれでも会社のどこでも改善できる
• 会社の知的財産は長年に渡って再利用可能な
コンポーネントである
• だれもが他の人の作った再利用可能なコン
ポーネントを探すことができる
• 開発者は人気のあるコンポーネントを作るこ
とで称賛される
• 開発者が変更を加えたら、すぐさま全社の社
員から見ることができる
• ビルドとテストの時間は、変更を加えたらす
ぐ確保される
• 開発者は他のチームに移れるし、そのチーム
での働き方を知っている
https://www.slideshare.net/WinOpsConf/sam-
guckenheimer-moving-to-one-engineering-system
Slide 41
Slide 41 text
No content
Slide 42
Slide 42 text
私がこの二年間で学んだのは
あなたのチームを見くびるな
Don’t underestimate your team
ということだ。
Slide 43
Slide 43 text
No content
Slide 44
Slide 44 text
私がこの二年間で学んだのは
あなたのチームを見くびるな
Don’t underestimate your team
ということだ。
Slide 45
Slide 45 text
モブプログラミング
同じ場所、
同じコンピュータで
作業する。
米Hunter Industries
で行われている実験
Slide 46
Slide 46 text
No content
Slide 47
Slide 47 text
タイピスト
(ドライバー)
ナビゲーター ナビゲーター
全員で見て、
考え、話し合い、
タイピストの
手を通じて
コンピュータに
伝える。
Slide 48
Slide 48 text
生み出される
すべてのコードは
少なくとも二人
以上が目を通し
問題がないと
考えているもの。
四つの眼の法則
Four Eyes
Slide 49
Slide 49 text
全員で一つの
ことに集中し、
一つ一つ解決して
前に進む。
コミットも休憩も
すべて合意する。
スウォーミング
Swarming
Slide 50
Slide 50 text
どのようなテスト
を書くべきか、
十分か、過剰か、
コミットごとに
全員で議論する。
リファクタリングも。
テスト観点の議論
Testing
Slide 51
Slide 51 text
プログラマーや
テスター、要件定義者
の垣根を超えて、
成果物に参加できる。
「実はどうやって作っ
ているのか知らない」
担当者の発生を避ける。
チーム全員参加
Cross-Functional
Slide 52
Slide 52 text
常に参加することで、
不具合の発生や、
納期遅延に関する、
「他責」によって
チームの信頼関係が
揺らぐことを防ぐ。
心理的安全性
No Brame
Slide 53
Slide 53 text
自分たちのペースを
常に確認し、
動作するコードを
継続的に統合する。
納期は開発者自身が
決める。
過剰な約束の禁止
No Overcommit
Slide 54
Slide 54 text
いや、分担したほうが速いでしょ？
？
＜
Slide 55
Slide 55 text
効率的な分担のために必要な作業がある
前工程 後工程
設計、タスク分割、
タスクアサイン、
受入テスト設計、
スキル教育
進捗管理、マージ、
コードレビュー、
受入テスト実施、
バグ対応、引継ぎ
Slide 56
Slide 56 text
モブプログラミング
米Hunter Industriesでは、
最初のチームの
モブプログラミングを
一年半に渡って実験してみた結果、
バグが一件も出なかった。
このやり方に「モブプログラミング」
という名前を付けた。
https://www.agilealliance.org/resources/
experience-reports/mob-programming-agile2014/
Slide 57
Slide 57 text
普及のきっかけとなった
経験論文を訳しました。
https://kawaguti.hateblo.jp/entry/
2021/03/30/082537
Slide 58
Slide 58 text
しばらくモブプログラミングをやっていると、
以前に直面していた問題の多くが、もはや自
分たちに影響を与えていないことに気がつき
ました。これらの問題を直接解決しようとし
たわけではありませんでしたが、私たちはそ
れらの問題が消えていくことに気がつきまし
た。
https://kawaguti.hateblo.jp/entry/
2021/03/30/082537
Slide 59
Slide 59 text
• 逆効果なコミュニケーション
• 意思決定の機能不全
• 「かろうじて足りる」こと以上を行うムダ
• 技術的負債による衰弱
• 重厚なマネジメントテクニックの負担
• 不必要なタスクの切り替えや中断によるプログラマの
バタつきによって引き起こされる集中力と有効性の喪失
• 社内政治の有害な側面
• 意思決定と知識創造を本質的に分離する
「ミーティングによるマネジメント」の弊害
https://kawaguti.hateblo.jp/entry/
2021/03/30/082537
見積もり
優先順位付け
スケジューリング
キューイング
パフォーマンスレ
ビューなど
自然と消滅したもの
Slide 60
Slide 60 text
モブの拡張
30人程度の組織を
すべてモブで開発。
作業対象ごとに
モブ設備を立てる。
https://www.youtube.com/watch?v=dVqUcNKVbYg
Slide 61
Slide 61 text
その場所では
一つの仕事をする。
人は、その場所に
仕事をしに行く。
開発環境を構築する
ムダを省く。
場所 = モブ
Location = Mob
https://www.youtube.com/watch?v=dVqUcNKVbYg
Slide 62
Slide 62 text
わからないところ
があったら、モブ
の外からでも助け
を呼ぶ。呼ばれた
ら助けに行く。
助けを請う
Ask for Help
https://www.youtube.com/watch?v=dVqUcNKVbYg
Slide 63
Slide 63 text
http://mobster.cc/
Ａさん1
Bさん1
Ａさん2
Bさん2
Cさん1
Cさん2
マイクロコミット
レトロスペクティブ
休憩
Slide 64
Slide 64 text
モブプログラミングの事例から
学べること
• ソフトウェア開発の問題の多くはコミュニ
ケーションの不都合から生まれることを
我々はよく知っている。特に「現地現物」を
見ていないと起こる。
• 「分担のやり方」を見直すことで、問題を
自然消滅させることができるかもしれない。
Slide 65
Slide 65 text
イノベーションのジレンマ
既存の企業からみると
「とるに足らない」
規模や品質の技術が
いつのまにか
顧客にとって
必要十分な技術になる。
Slide 66
Slide 66 text
モブやチームで仕事する
っつったって、そんなの
どうやって見積書を出せ
ばいいの？
Slide 67
Slide 67 text
チームの人月
この単位なら
計算は簡単
Slide 68
Slide 68 text
いや、４人でちょうど
いい案件なんて
転がってないんですけど。
Slide 69
Slide 69 text
チームの人月
やることリスト
稼働日数で請求
できないか？
Slide 70
Slide 70 text
顧客にとってのメリット
• 実績のあるチームでの仕事に
よって見積もり精度が高く、品
質も安定している。
• 継続的なOJT教育が行われてい
るため、スキルが安定している。
• 複数案件を並行作業しているの
で、得意分野に強み。
• 継続契約によって保守も安定。
Slide 71
Slide 71 text
提供企業にとってのメリット
• 継続的な雇用を維持することで、
OJT教育しやすい。
• 複数案件を並行作業しているので、
案件の変化に強い。
• コミュニケーションロスが少ない。
• おそらくバグは少なく品質高い。
• いつもより高く売れるはず。
(ただしすでに高めに売ってしまっ
ている可能性はある)
Slide 72
Slide 72 text
別解: ペアアサイン
• 2001年から受託開発を行っている
メンローイノベーションズ社
• ペアを日単位でアサインする料金体系に
している。ペアを選ぶことはできない。
ペアはほぼ毎日組み替えて属人性を抑止。
• ペアは毎朝バイキングのヘルメットの角
を一つずつ持ち、今日の作業を宣誓する
• 別にプロジェクトマネージャがおり、
スケジュール管理をする。
Slide 73
Slide 73 text
エクストリームプログラミングの原動力のひとつ
は、ビジネスとテクノロジーの間の溝を癒すこと
でした。私は、一般的に言われている2つのグ
ループが激しく対立し、協力する方法を見つけて
も必要なものが得られないという状況を目の当た
りにしてきました。つまり、自分には納期を決定
する力があると思っている人が、その力の幻想を
手放そうとしなかったのです。そこにエクスト
リーム・プログラミングが登場し、一連の人間関
係とそれを支える儀式、そしてそれらの儀式や人
間関係を支える技術的な慣習を提示しました。そ
して、その代償として、締め切りを指示すること
ができなくなりました。
(Kent Beck 2021年７月のAgile 2021でのトークより)
https://ja.wikipedia.org/wiki/
ケント・ベック
Slide 74
Slide 74 text
それを良しとする人もいました。そして、そのよ
うなチームはとてもうまくいきました。しかし、
一般的には、力関係は変わっていません。つまり、
インセンティブが変わっていないのです。だから、
行動は変わらない。だから結果も変わっていない。
私は、これはペアプログラムをするかしないかと
いう問題ではなく、意思決定をスキル・情報・結
果に向けて動かす意思があるかどうかという問題
だと思っています。
(Kent Beck 2021年７月のAgile 2021でのトークより)
https://ja.wikipedia.org/wiki/
ケント・ベック
Slide 75
Slide 75 text
要因に分解する？
動くものを
組み合わせる？
Slide 76
Slide 76 text
すでに動く実績
のあるものを
再構成し、少しだけ
内容を変えながら
新しいものを作る。
Slide 77
Slide 77 text
https://www.amazon.co.jp/dp/4532318416
構想力とは、
問題を限定する能力である。
Slide 78
Slide 78 text
何を固定し、
どう全体を作るか？
Slide 79
Slide 79 text
しかし、もし私が一つの教訓を選ぶとしたら、
他の何よりも多くの組織が失敗していると思うことは、
グループサイズです。リチャード・ハックマンの言葉を
借りれば、チームが5,6,7,8人よりも大きくなり、
10人近くになると、物事が本当に悪くなるという
証拠がたくさんあります。
基本的には、10人、あるいは11人になると、
調整のための雑務に費やす時間が増え、
実際に仕事をする時間が減っていきます。
もう1つは、人間関係の問題が発生することです。
ディナーに行って10人、11人と会話をするのは
不可能に近いですよね。
ロバート・サットン
スタンフォード大学経営学部教授
Slide 80
Slide 80 text
https://www.scaledagileframework.com/
SAFeも基本的には
チームを基調に
組まれています。
Dean Leffingwell は
マルチチームのスクラム
をやったときに
チームは成功したけど、
全体的に失敗したので
SAFeを作り始めた、
と言ってました。
Slide 81
Slide 81 text
上位下達型の組織
教育リソースが限られている場合に、
必要なトップ層を中心に教育を行い、
部下の指導を通じてユニバーサル
サービスを実現した。ルールを守って
適切に。目標達成と信賞必罰によって
コントロール。
チーム中心の組織
実務者によって顧客やユーザーへの
サービスが行われている、組織界面に
必要なリソースを集める組織。教育リ
ソースが十分に行き渡っている専門家
を現場に。マネジメントは現場を支援
するためにある。
Slide 82
Slide 82 text
https://agilemanifesto.org/
アジャイルマニフェスト
Slide 83
Slide 83 text
https://agilemanifesto.org/
アジャイルソフトウェア開発宣言
私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
https://agilemanifesto.org/iso/ja/manifesto.html
Slide 84
Slide 84 text
https://agilemanifesto.org/principles.html
アジャイル宣言の背後にある原則
私たちは以下の原則に従う:
顧客満足を最優先し、
価値のあるソフトウェアを早く継続的に提供します。
要求の変更はたとえ開発の後期であっても歓迎します。
変化を味方につけることによって、お客様の競争力を引き上げま
す。
動くソフトウェアを、2-3週間から2-3ヶ月という
できるだけ短い時間間隔でリリースします。
ビジネス側の人と開発者は、プロジェクトを通して
日々一緒に働かなければなりません。
意欲に満ちた人々を集めてプロジェクトを構成します。
環境と支援を与え仕事が無事終わるまで彼らを信頼します。
https://agilemanifesto.org/iso/ja/principles.html
Slide 85
Slide 85 text
https://agilemanifesto.org/principles.html
情報を伝えるもっとも効率的で効果的な方法は
フェイス・トゥ・フェイスで話をすることです。
動くソフトウェアこそが進捗の最も重要な尺度です。
アジャイル･プロセスは持続可能な開発を促進します。
一定のペースを継続的に維持できるようにしなければなりません。
技術的卓越性と優れた設計に対する
不断の注意が機敏さを高めます。
シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
最良のアーキテクチャ・要求・設計は、
自己組織的なチームから生み出されます。
チームがもっと効率を高めることができるかを定期的に振り返り、
それに基づいて自分たちのやり方を最適に調整します。
https://agilemanifesto.org/iso/ja/principles.html
Slide 86
Slide 86 text
https://kawaguti.hateblo.jp/entry/20110213/1297531229
私たちはすぐに、
それぞれ推奨しているもの同士が
とても似通っているのは偶然ではない、
という結論に至った。
そこには何か根底に流れる共通性があり、
それが何であるかを
見つける必要があると思われた。
なぜなら、日々や分単位のプロジェクトの進め方には、
食い違っている点があり、まだ解消していなかったからだ。
このような食い違いがあるにもかかわらず、
私たちには「私たち以外の人々とは違う」と言える、
とても強い共通性が存在した。
Slide 87
Slide 87 text
スクラム、
リーンは
日本の製造業から
影響を受けている
Slide 88
Slide 88 text
https://www.infoq.com/presentations/The-Roots-of-Scrum/
スクラムの源流
• チームプロセス – シリコンバレーの起業家たち
• 竹内・野中 – 日本の製造業
• 世界をもっとよい場所に – 内なるビジョン
• オブジェクト技術とEasel社のSmallTalkプロダクト
• オブジェクト指向アーキテクチャ
設計ツールの専門家、ベンダー、顧客
• 進化生物学と複雑適応系
• プロセスと生産性の研究
• ソフトウェア生産性の研究
• 外科手術チーム(人月の神話, IBM)
• 邪悪な問題、正しい解決
• ボーランド Quattro Pro プロジェクト
• iRobot -サブサンプション・アーキテクチャ
Slide 89
Slide 89 text
https://www.infoq.com/presentations/The-Roots-of-Scrum/
トヨタウェイ : Learn by Doing
張富士夫 : 代表取締役社長 2002
• 私たちが一番重視するのは、実際に実践し、
行動すること アジャイル原則#1
• わかっていないことはたくさんある。だから
「とにかくまずやってみよう」アジャイル原則#3, #11
• 自分の知識の少なさに気づき、自分の失敗に
直面して、もう一度やり直し、2回目の試行で
また別の失敗に気づく。そしてもう一度やり
直す。アジャイル原則#11, #12
• 絶え間ない改善によって、より高いレベルの
実践と知識に至る。アジャイル原則#3
Slide 90
Slide 90 text
竹内野中論文(1986)が示した
マネジメントスタイル
• Type A NASAのウォーターフォール型
• 要求、分析、設計、実装、試験と、
順に次の工程の部署に引き渡される
• Type B 富士ゼロックスのサシミ型
• 前工程と後工程が同席する
• Type C ホンダのスクラム型
• 一時は全工程が同席する
Jeff SutherlandはこのType Cから、
自らのフレームワークの名前を
とった。
https://www.infoq.com/presentations/The-Roots-of-Scrum/
Slide 91
Slide 91 text
コマンド＆コントロールを打ち破る
• 旧来の企業では、戦略は中央で作られる
• それぞれの現場で、創発的な戦略が自己
組織される
• 分散化された認知とアクション
• スクラムチームは、
自己組織化を許されなければならない
• 自働的 Autonomous
• 卓越的 Transcendent
• 他家受粉 Cross-fertilization
• チームは自らの仕事を選択する
• それぞれの個人は自らの仕事を管理する
• マネジメントを排除する
竹内野中
https://www.infoq.com/presentations/The-Roots-of-Scrum/
Slide 92
Slide 92 text
https://www.infoq.com/presentations/The-Roots-of-Scrum/
多様な観点
• 職能横断チーム (クロスファンクショナル)
• スクラムチームは(すべての職能を)持つ。
プロダクトの知識、業務分析、UIデザイ
ン、ソフトウェアエンジニア、品質保証
• さらに進んだスクラムではもっとステー
クホルダーを巻き込む ー 経営陣、顧客、
インストール担当、サポート担当
Slide 93
Slide 93 text
上位下達型の組織
教育リソースが限られている場合に、
必要なトップ層を中心に教育を行い、
部下の指導を通じてユニバーサル
サービスを実現した。ルールを守って
適切に。目標達成と信賞必罰によって
コントロール。
チーム中心の組織
実務者によって顧客やユーザーへの
サービスが行われている、組織界面に
必要なリソースを集める組織。教育リ
ソースが十分に行き渡っている専門家
を現場に。マネジメントは現場を支援
するためにある。
Slide 94
Slide 94 text
イノベーションのジレンマ
既存の企業からみると
「とるに足らない」
規模や品質の技術が
いつのまにか
顧客にとって
必要十分な技術になる。
Slide 95
Slide 95 text
https://web.cr-sis.com/seminar/20210727/
スクラム同士が、毎日会いながら、
白板を前にして、徹底的に、
いまここで過去をふりかえると同時に、
一人一人が、昨日何が起こったかを
しゃべる。
しかし、ムダな時間はない。一分。
そうすると本質を考え抜く。
これが一巡すると、先が見えちゃう。
全員白板を前に起立している。
すぐ動けるように。
Slide 96
Slide 96 text
https://web.cr-sis.com/seminar/20210727/
全員がこの一ラウンド終わった瞬間に
いまここで先行きが見えちゃって、
すぐ動く。
そこで、その時に
ペアプログラミングをやるんですよ。
まず二人でやってみろと。
開発者と品質管理、ペアで。
そこで、実際のコアモデルが
出来ちゃうわけ。
それをみんなで共有して完成させる。
Slide 97
Slide 97 text
https://web.cr-sis.com/seminar/20210727/
その背後には理論があって、単なる
ソフトウェア開発の手法ではない。
SECIモデルも単なるイノベーション
の作法ではない。
人間の生き方なんだと。これは。
絶えず現実のただなかで、新しい意味、
価値を続けていって、
全員がプロフェッショナルになるんだ。
っていう、生き方なんだと言っている。
まさに戦略の基本は生き方だ。
Slide 98
Slide 98 text
https://web.cr-sis.com/seminar/20210727/
利益とハピネス(共通善)
両者をうまくバランス
させていくのが
まさに実践知だと。
真剣に戦う。
Slide 99
Slide 99 text
変化の先を読みながら、
できていることを確認し、
いま、必要な準備を
一つ一つやってみるのが
大事かなと思います！