੡଄ۀͰͷΞδϟΠϧɺ೰Έͱޫ ʙ্ϩδͱԼϩδʙ 永和システムマネジメント 平鍋健児

2 昨⽇まで、 九州⼤学にいました

Conwayʼs Law “organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations” ̶ M. Conway ”組織の構造がソフト ウェアの構造に反映す る“ であれば、よい組織構造をつくろう。 （Inverse Conway Maneuver) 3

No content

No content

6 https://arxiv.org/abs/2311.10475 これがその論⽂

平鍋健児 (株)永和システムマネジメント社⻑ (株)チェンジビジョンCTO (株)Scrum Inc. Japan 取締役 福井で受託開発を続けながら、アジ ャイル開発を推進し、国内外で、モ チベーション中⼼チームづくり、ア ジャイル開発の普及に努める。ソフ トウェアづくりの現場をより⽣産的 に、協調的に、創造的に、そしてな により、楽しく変えたいと考えてい る。アジャイルジャパン初代実⾏委 員⻑。 7 第⼆版

◎ 本社／福井市 WeWork 沖縄 Agile Studio Park 新幹線開通記念。福井駅前

9⽉20⽇オープン@FUKUMACHI BLOCK 9 ⾒学受付中︕ https://www.agile- studio.jp/post/agile-studio-park- to-be-opened （上部に申し込みボタンあり）

共創・共育で利⽤するプラクティス 10 モブプログラミング ● ⼀つのPCとディスプレイ ● 同じ課題にみんなで⽴ち向かう ● 知識伝搬が早い ● レビューも同時に⾏うことで効率的 スプリント （1〜4週間） ふりかえり ● 毎週（スプリント毎）実施 ● ⾃分たちの課題を出し合い改善策を探る ● チームワークを⽣み出す効果も 福井での共創・共育

11 顧客の看板の下にチーム

150社2,000名が⾒学

No content

アジャイルを⽇本で広げたい • ⾸都圏、地⽅を問わず、優秀なエンジニアは多い。 • エンジニアが直にビジネス、社会に影響を与えられる時代。 • ソフトウェアはもはや、調達、ではない。イノベーションの核。 • もともとチームワークは、⽇本は得意なはず。 • ⼈と関わること、の⼤切さ。 • わくわく、どきどき、やった︕ の感覚。 • エンジニアとしての、倫理観を持って、社会と関わる。

2020/1/10 Regional Scrum Gathering Tokyo

今⽇議論したいこと 製造業（⾃動⾞業界を例に）でアジャイル が普及しているのか？どのドメインで、ど のフェーズで、産業構造のどこで。 アジャイルが普及するには「上ロジ」と「下ロジ」 が必要。実践の⼤変なことは、ほとんど「上ロジ」 （本に書かれていない）。 時間があれば、SDV(Software Defined Vehicle)

アジャイルの上ロジと下ロジ • ロジ＝路地 • 道。道路。路地裏。 • ロジ＝ Logistics • 兵站、（物資の）輸送路 • アジャイルを実装するための、両⽅⾯の地ならしと展開作戦。

18 アジャイル（スクラムを例に） ふりかえり P.O

19 Scrum Team P.O The Other World 上ロジ 下ロジ スクラムで定義されて いるのは、ほぼ下ロジ。

下ロジ • 最⾼のプロダクトを作ること（もちろん） • スクラム（など）の実践 • メンバーの巻き込み • プラクティスの実践 • プラクティスの教育 • パートナーの巻き込み

上ロジ 本来の仕事 • 最⾼のプロダクトを作ること（もちろん） • ユーザとの対話 • ビジョンづくり 社内 • マネジャーの理解、説得、巻き込み • 経営層へのアプローチ • 他のステークホルダー（他部署、他社）との調整 • 予算づくりと承認、チームメンバー選定 • 成果の説明

誰がはじめる? (Champion) トップがChampionで あれば、すべて下ロジ ボトムがChampionで あれば、すべて上ロジ

Startups, Webサービス • アジャイルチームは経営(プ ロダクトマネジャ)に直結、 市場と対話している（社内の 上ロジはいらない）。 • やることは下ロジがほとんど。 • ただし、依然としてP.O.の仕 事は超重要（プロダクトの⽣ 命線） Scrum Team P.O 市場 顧客（ユーザ） 会社

トップ主導の変⾰ • アジャイル,チームは経営(プロダク トマネジャ, CxO)に直結、市場と対話 している（社内上ロジはいらない）。 • もし、CEOが「全員アジャイルでや るぞ」と⾔ったら? (2007 Salesforce) • やることは下ロジがほとんど。 • ただし、依然としてP.O.の仕事は超 重要（プロダクトの⽣命線） P.O 市場 顧客（ユーザ） 会社

CxO 市場 顧客（ユーザ） 会社 S CxO 市場 顧客（ユーザ） 会社 S S S S S S S S S S 上が決めた固いワクに はめるようなやり⽅は ホントよくない。 経験した⼈が、試しな がら徐々に形を作って ⾏くのがよい。

⾃動⾞産業 • 最終製品市場とチームの距離 が⾮常に遠い（上ロジがたい へん）。 • POは会社の多くの部⾨と調整 しなくてはならない。 • 上層部の理解がない場合ア ジャイルを「翻訳して」伝え ないといけない（無理筋） 。 • 産業構造(OEM/Tier1…)をまた ぐことも出てくる Scrum Team P.O 会社の 他の機能 上層部 顧客 （取引先） 会社 市場 顧客（ユーザ） あなた

⾃動⾞業界 Webのスタートアップと違っ て、最終成果物（⾞両）は デカい。 ソフトやハード、 さらに全体の⽣ 産、検査、型式 認証、Co2、機能 安全 関わるプレイヤーも多数 OEM、Tier1サプ ライヤー、認証 機関、、、、 チーム開発の延⻑で捉えられるか？

序列 •⼠農⼯商 メカ・エレキ・ソフト •これはもう古い？ 意思決定とリズムの主導権

分割軸 • 先⾏開発→標準化→量産 という 「フェーズ」で分ける • OEM→Tier1→Tier2 という 「産業構造」で分ける • In-Car/Out-Car という 「内外」で分ける • パワトレ、シャーシ、インフォテイメ ント、ADASなどという 「ドメイン」で分ける まずは、ドメインとフェーズで考え てみた。なぜかというと、、、

アジャイルとアーキテクチャのスイートスポット 開発時間 事前設計とリスク解決の時間 修正時間（⽋陥の修正、書き直し、間違い） 全体のプロジェクト時間 備考: 事前設計に使った時間は開発を加速し 修正作業の時間を減らす Barry Boehm: The ROI of Systems Engineering: Some Quantitative Results 2007 Michael Keeling: “Design It!” (Design It! プログラマのためのアーキテクティング⼊⾨ 2017)

アジャイルとアーキテクチャの バランス sweet spot アーキテクチャ設計とリスク解決のための時間 全体に追加された時間 アーキテクチャ設計 修正作業

Barry Boehm et. al : Architected Agile Solutions for Software-Reliant Systems

アジャイル 適正 経験メンバの割合 要求変化 企業⽂化 メンバ数 クリティカルさ 35 30 25 20 15 0 10 20 30 40 (1B%) (L2,3 %) (変更/⽉(%)) 1 5 10 30 50 90 70 50 30 10 3 10 30 100 300 (⽋陥による損害) 快適さ 限定額 巨額 ⼀⽣命 多数の⽣命 計画型 アジャイル “Get Ready for Agile Methods – With Care” (Barry Boehm, IEEE Computer, January 2001) 5つの主要パラメータを定義。これは会社 ごとに仮説を⽴てて決めればよいと思う。

ドメイン 伝統的には • 制御系（パワトレ、シャシ） • ボディ系 • 情報系（インフォテイメント、 マルチメディア） 現代的にはさらに • コネクテッド、アウトカー • EV • AUTOSAR BSW • ADAS • セイフティ/セキュリティ • そして最近は、SDV の流れ http://www.jasa.or.jp/TOP/offer/automotive/

パワトレ/ シャーシ ボディ Multimedia /connected ADAS 先⾏開発 量産開発 Safety/Security 機 能 安 全 認 証 統 合 テ ス ト 型 式 認 証 ？ 先⾏と量産を詰 める可能性 • OTA(Software Update) • シミュレーションとテスト、MILS/HILS • 段階的認証 • SDV(Software Defined Vehicle) イノベーション オペレーション 経験メンバの割合 要求変化 企業⽂化 メンバ数 クリティカルさ 計画型 アジャイル ？ 統合的視点の可 能性 • MBSE • SDV 考察：先⾏ではメンバ数、クリティカ ルさが⼤きく違う AUTOSAR BSW(Adaptive の参照実装) 先⾏はどのドメイ ンでもアジャイル が有効に機能する。 認証に関するドキュメントや エビデンスも、価値をもって おり「成果物」(バックログ) に⼊れることができるが、⼀ 気通貫は難しい。 量産でもCi/CDなど実装とテス トにまつわるプラクティスは 有効に機能する。 ア ー テ ク チ & ー に 関 し て は 。 量 産 開 発 に ⼊ る 前 に 確 定 す る 必 要 が あ る か も 。

Agile in Automotive – State of Practice 2021 まあ、そうだよね https://www.kuglermaag.com/report-on-the-agile-automotive-state-of-practice-2021-industry-barometer/

アジャイル の強み Unknown な市 場と課題を味 ⽅につける 市場=課題：どんなユーザが いて何を望んでいるか） 技術=解決法：実際にそれが 制約内で実装できるか チームの⼒ を最⼤に モチベーション=「やり がい」をもって活動でき るか 改善=やり⽅を⾃分たち で⼯夫できるか この⼆つの意図をもちたい

過去と現在と未来 • ⼤切にしてきたこと、と、これから⼤切にしたいこと。 • 現在を作ってきたのは、過去のおかげ。 • 未来を作るのは、現在の仕事。 • unlearn（学習棄却） することと、 • 伝承すること。学びほぐし。 • 暗黙知と形式知、さらに、 オートポイエーシス（破壊を含む⾃⼰創出） https://careers.denso.com/graduate/growth/CIP_SOMRIE/ Unlean Learn

39 アジャイルソフトウェア開発宣言 私たちは、ソフトウェア開発の実践 あるいは実践を手助けをする活動を通じて、 よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。 プロセスやツール よりも 個人と対話を、 包括的なドキュメント よりも 動くソフトウェアを、 契約交渉 よりも 顧客との協調を、 計画に従うこと よりも 変化への対応を、 価値とする。すなわち、左記のことがらに価値があることを 認めながらも、私たちは右記のことがらにより価値をおく。 Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas © 2001, 上記の著者たち この宣言は、この注意書きも含めた形で全文を含めることを条件に自由にコピーしてよい。 重要 いま重要!

組織の中での広め⽅

No content

北⽶トヨタにおけるアジャイルトランスフォーメーション https://speakerdeck.com/wadak8sk/bei-mi-toyotaniokeruaziyairutoransuhuomesiyon

発⾒できることはあまり違わない • ルールとは別に⾃分たちの「プレイブック」を作る。 • 作る活動は、「実践者たち」のコミュニティ。 • コミュニティは組織を横断している。 • コミュニティはやらされていない。 • コミュニティリーダーは会社からの権限をもち、チームを育て る視点で活動。 • デュアルOSの活動であり、しかし組織内で認識されている。

こんなアジャイルは嫌だ アジャイルは「⼈間賛歌」が起点だ。現場で働く⼈たちがモチ ベーションとやりがいを持って良い仕事をすることが、会社や社 会の利益にならないといけない。そういう時代なのだ。 上から降ってきたやらされアジャイル（ゾンビアジャイル） や、アジャイルやりたいだけのアジャイルごっこ、になって はいけない。

No content

アジャイルは「⼈間賛歌」が起点だ。現場で働く ⼈たちがモチベーションとやりがいを持って良い 仕事をすることが、会社や社会の利益にならない といけない。そういう時代なのだ。 ぼくらが考えて、仲間をあつめて、実装して、変 えていくのが正当なのではないだろうか。 上ロジと下ロジをつなぐ、 Champion(始める⼈)にならないかい？

No content