Age of Agile Development 3

Transcript

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