フレームワークを生み出す メタフレームワークという考え方 適応型から生成型へ kyon_mm

あらゆるネットが眼根を巡らせ光や電子となった意思を ある一方向に向かわせたとしても “孤人”が複合体としての“個”になる程には情報化されていない時代 -Shiro Masamune

3

４７機関 • https://47kikan.org • kyon_mm • bleis_tift • its_out_of_tune • dico_leque • aki.m 4 • 2011年末結成（現在14年目） • アジャイルチーム • 所属:デロイトトーマツコンサ ルティング合同会社 • 専門 • ソフトウェア開発 • ソフトウェア工学 • アジャイルコーチング • リーンスタートアップ、スクラム • 学生のトレーニング • 自社サービス開発

個人の知見バトルで満足するなんて そんな話あるかよ 「チームみんなの経験と知見を持ち寄って議論しましょう！」 「そう。それは大事。。。でもさ、個人の知見バトルに頼った意 思決定で組織が強くなると本気で思ってるの？妥当な結論を導く やり方の再現性低すぎない？」 5

劇とは、観客自体もその演出 の一部に過ぎない 荒巻大輔 攻殻機動隊 STAND ALONE COMPLEX 第6話 6

普段どのような議論をしていますか？ 議論の妥当性はどのように担保していま すか？ 5min オンサイトの方は近くの人と対話してみましょう オンラインの方はDiscordに書いてみましょう。emojiでリアクションも 7

よくある困っているシーン 8

規範の中にいるときはそれを窮屈と感じるけど、規範な き行為はまた行為として成立しない。 チームの始まり スクラム経験者を含むチー ムでは、製品開発を始める 際にスクラムを不完全に採 用しながら進めることが多 い。 それによって一定程度進ん でいる感じはするが、それ 以外になにを採用するかの 指針は、エンジニアは DevOpsの指針を、POはPdMの 指針を採用することが多い。 既存の使えそうなもの 戦略に使えそうな既存のソ リューション（ただしこれ らは部分的であることが多 い） • PMBOK : プロジェクトマネ ジメント • 財務諸表 : 会計 • DevOps：ソフトウェアテク ノロジー/Digital技術 9 引用 : 草薙素子 攻殻機動隊 STAND ALONE COMPLEX 第6話 意思決定の脆弱性 自分たちにとって効果的な 進み方をつくるための参考 となる戦略が一貫していな い

理解なんてものは概ね願望に基づくものだ 課題 • 始める時に必要なものを選択する 基準/方針が曖昧 • 始めてから必要なものを選択する 基準/方針が曖昧 • 既存の戦略を整理する 基準/方針が曖昧 起きていること • チームの選択の妥当性評価は部分的にな り、全体での評価のためには統合する必 要があるが、統合して評価することを想 定していないため、全体での統合が困難 になり、全体での評価は結果指標に依存 せざるを得ない。 • 現在のデファクトスタンダードである Four Keysは、一定規模以上のシステム開 発プロジェクトでないと有効に機能しな い。 10 引用 :荒巻大輔 イノセンス

エキスパートとユーザーによ る間の生成 11

理解なんてものは概ね願望に基づくものだ 解決の方向性と選択したもの 1. よりメタ性のたかい先行指標を持つ（全体の先行指標を作る） 2. 領域ごとに先行指標をつくる（部分ごとの先行指標を作る） 3. 全体の妥当性評価をしやすいメタフレームワークを利用する （部分ごとの戦略の妥当性を上げることで先行指標をつくりやすくした り、先行指標の必要性をさげる） <= これを選択 12 引用 :荒巻大輔 イノセンス

根拠ですって？ そう囁くのよ、私のゴーストが The Battle for the Life and Beauty of the Earth: A Struggle Between Two World-Systems という事例 • 1980年代には、エキスパートとユーザーの相互作用によって部分から全体を生成する方 法が提案され、実践された事例もいくつか存在する。 “Together we could choose to work toward a reconfiguration of professional standards and practices of the building industry that address both the operational and human aspects of the system of production.” "Again and again we are confronted daily by decisions, by the question, "What should I do, what path should I take, how should I approach this problem?” There is no human being who does not, in some form, encounter this kind of self-doubt. Every one of us needs help or guidance in doing the best possible thing, in so far as what is available and practical, on the day when you encounter this question, in yourself.” 13 引用 : The Battle for the Life and Beauty of the Earth: A Struggle Between Two World-Systems 引用 :草薙素子 攻殻機動隊 GHOST IN THE SHELL

Back to Generative 14

我々の間には、チームプレーなどという都合のよい言い訳は存 在せん。有るとすればスタンドプレーから生じる、チームワー クだけだ。 秩序、枠組みの中で前の行為の成果をより強化する • “それは、建物や町の秩序が、そこにある人間や動物や植物や事物などの 内なる本質から、直接的に生まれてくるようなプロセスである。” • “共通ランゲージの枠組のなかで、何百万もの建設行為が一つとなり、生 命に満ちあふれた、全一的な、誰も予測できない町が、ごく自然に生成さ れていく。” • “前の行為の成果を修復かつ強化するいくつかの建設行為によって、単独 の行為ではとてもかなわぬような、より大規模で複雑な全体が少しずつ生 成されていくであろう。” 15 引用 : 時を超えた建設の道 引用 : 荒巻大輔 攻殻機動隊 STAND ALONE COMPLEX 第5話

理論とパタンと適応型 16

教訓から学び―そして,それを捨て去る。 時代背景 1970 – 1980に生成型 • アレグザンダーの「時を超えた建設の道」 （1979年）や「パタン・ランゲージ」（1977 年）は、普遍的な価値や持続可能な秩序を重 視するアプローチとして登場した。当時、工 業化や標準化が進み、機械的なシステムが人 間らしさや自然な秩序を損なうことへの危機 感が背景にあった。 1990 – 2000に適応型 • 適応型はITの発展や市場の変化が激しい状況 に対応するために、1990年代後半から2000年 代にかけて台頭した。アジャイルマニフェス ト（2001年）の登場はその象徴であり、短期 間で結果を出し、変化に迅速に対応する必要 性が背景にあった。 生成型の強みが適応型で損なわれる 普遍的価値の軽視 • 適応型では、短期的なフィードバック ループに焦点を当てるため、生成型が持 つ「長期的で持続可能な価値」の重要性 が軽視される傾向がある。特に、外部環 境の変化に翻弄される結果、調和のある 全体像を見失いやすい。 全体性の欠如 • 生成型では、各要素が全体に貢献する調 和を重視するが、適応型では、短期的な 目的に最適化された要素が積み上げられ やすく、全体的な統一性や美しさが損な われやすい。 17 引用 :時を超えた建設の道

適応型を生成型に回帰させる 生成型の視点を復活させる • 適応型が短期的な成果に囚われるのを防ぐために、生成型理論 の「直観による（内発的な）秩序」や「持続可能な価値」を取 り入れる。 • スクラムのプロダクトゴールやリーンキャンバスのようなもの だけではなく、全体の調和や生命力に関する秩序で補助するこ とで、生成型の価値を取り戻す。 18 参考 : A Scrum Book

製品開発における生成型 19

組織はプロセスを通してマーケットと対 話しながらプロダクトを生成している 製品開発におけるリソース 20 組織 1人 – 1万人 製品開発プロセス 数秒 – 数十年 マーケット 数円 – 数百億円 プロダクト

ヒト/モノ/カネ/エネルギーの全てが枯 渇する、枯渇先進国日本を豊かな場所に • どうやって過剰なヒト/モノ /カネ/エネルギーを使う？ • 第二、第三の経済大国とし てどうリードする？ 21 • ヒト/モノ/カネ/エネルギー に頼ったソリューションは 使えない • リソースが少ない状態でも 生き生きとした生活が求め られる • リソースが少ない状態でも 社会貢献できる方法 今までの日本 これからの日本

新しいものにたいして、同じで良い考え方と、 新しくしなければいけない考え方があるはず 意思決定/学習の戦略性の低さ ウォーターフォールを学び実践し、アジャイルを学び実践し、リーン スタートアップを学び実践し、じゃあこの後はなにがくるんだろう？ 学ぶこと自体はいいんだけど、自分たちが何を学んだり実践すべきか の指標ってだれからもおしえてもらっていないじゃん！！！！ みんな自分が好きなことをやっているだけじゃん！！！！ 学習が続くことが問題なのではなくて、学習していることにある種の 原則を見出せていない、ひいては自分が実践していることに原則を見 出せていない、それがあらゆる場面でのスケールを阻害していました。 22

「数年ごとに新しい何かを学ぶ」だけではな く「常に自分たちにあったものを生み出す」 プロセス/組織/プロダクトの生成を助けるメタフレームワークを生成型とする • スクラムは適応型でありフレームワークである。 • ウォーターフォールは計画型でありフレームワークである。 • 生成型は他のフレームワークやプラクティスを生成するという 点でメタフレームワークであると考えている。 学習、議論、意思決定の再現性を高め、自分たちで最適な形を見 つけ出せるようにする 23 参考 : OOPSLA 1996 コンピューター革命はまだ起きていない

Why/What/Howのマルチレイヤーと それらの問いからプロセス/組織/ プロダクトを生成する 24

メタフレームワークの方針 • コアとなる概念は「Why/What/Howのベン図」が多層に重なり 合っている（セミラティス） • あるレイヤー（抽象度）でベン図の部分ごとに問いがあり、そ の問いに答えることで、フレームワークやプラクティスを生成 する（前の行為の成果から次を生み出すプロセス） • これらの原則がありながら15の幾何学的特性や構造保存変換で 提唱されている秩序を取り入れる 25 引用 : Nature Of Order Book1/Book2

Why/What/Howのベン図が基本構成 26 Why What How ユーザーストーリー TDD CI/CD Pull Request ADR プラクティス例（マッピング場所は参考例）

「Why/What/Howのベン図」が多層に重な り合っている 27 抽象度が高い 決定するために必要な変数の複雑さ 変数自体の多さ, 取りうる値の多さ

あるレイヤーでベン図の部分ごとに問いに答 えることで、組織/プロセス/プロダクトを生 成する • Why/What/Howの変数を簡単に明 らかにはどうする？その方法の 種類と比較方法は？（知る） • Why/What/Howの変数A、変数B、 変数C...から値を簡単に選ぶに はどうする？その方法の種類と 比較方法は？（選ぶ） • Why/What/Howの変数の実情を簡 単に知るにはどうする？その方 法の種類と比較方法は？（収 集） 28 ユーザーストーリー

あるレイヤーでベン図の部分ごとに問いに答 えることで、組織/プロセス/プロダクトを生 成する • Why/What/Howの変数の変化α、 変化β、変化γ...に簡単に 適応するにはどうする？その 方法の種類と比較方法は？ （変化） 29 ユーザーストーリー ユーザーストーリー 時間的変化に対してどうする？

あるレイヤーでベン図の部分ごとに問いに答 えることで、組織/プロセス/プロダクトを生 成する • Why/What/Howの変数がもっと 多いものはなに？（全体を知 る） • Why/What/Howの変数がもっと 少ないものはなに？（部分を 知る） • Why/What/Howの変数が同じく らいのものはなに？（隣接領 域を知る） 30

挑戦して見えてきたもの 31

いつ、いかなる時でも、私を信じ て疑わない部下への信頼。それこ そ私が今まで築き上げてきた財産 の全てです。 荒巻大輔 攻殻機動隊 SAC 第25話 32

チームAの概要 システム開発チーム（47機関with他メンバー） • 自治体向けサービスの開発をしている • 10名前後のチーム • PO 兼 Agile Coach • Scrum Master • Scrum Master • Developer x 3 – 8 • アジャイル開発に対する慣れはメンバーごとに異なる & 入れ 替わりもそこそこある 33

個人の知見バトルで満足するなんて そんな話あるかよ 「チームみんなの経験と知見を持ち寄って議論しましょう！」 「そう。それは大事。。。でもさ、個人の知見バトルに頼った意 思決定で組織が強くなると本気で思ってるの？妥当な結論を導く やり方の再現性低すぎない？」 34

チームAの挑戦 課題は山積しているので徐々に解消してきた 1. フラクタルスプリント 2. Living Process（ダブルダイアモンド風のふりかえり） 3. そしてこの生成型的な意思決定 35

チームAの全体 • 大きく3つのレイヤ • 段階的変容 • 粗っぽさ • 空 36

37

チームAのレイヤ2-全体 38 MTG テクノロジー マネジメント

チームAのレイヤ2-部分 39 テクノロジー マネジメント

チームAのレイヤ2-部分 40 MTG

チームAのレイヤ3-全体 41 Working Agreement 働き方 開発プロセス

チームAのレイヤ3-部分 42 開発プロセス

過去の47機関はより小さな範囲だった 受け身の中でうまくやっていた • 自動車業界向けサービスの開発をしている • 5名前後のチーム • PO 兼 Scrum Master 兼 Developer x 5 • （ロールをデイリーで変えていた） • アジャイル開発に対する慣れは熟成するが、途中で抜けてまた 戻ってくるみたいなのが多い 43

過去の47機関のほうが成熟度が高いが、 インパクトが小さく、挑戦領域も小さい チームの比較 • 過去の47機関はWhy/What/Howの部分でほぼWhat/Howに全振りし ており、Whyはクライアント任せである • 現在のチーム（47機関with他メンバー）はアンバランスながら も、さまざまな抽象度で製品開発をすすめていて、全体性が高 い • 過去の47機関の成熟度を超える日も遠くないと信じられる 44

まとめ 45

知見バトルではなくエキスパートとユー ザーの間で直観を信じるための秩序 • 方法論はこれからも多数生まれるし、多数採用するだろう。だ が、自分たちの全体性を高めることを基本としなければ生き生 きとした組織/プロセス/プロダクトは生まれにくいだろう。 • 製品開発における全体性を高めるための秩序としてアレグザン ダーの考え方をもとに生成型を活かしたメタフレームワークを 提案した。 • 基本はWhy/What/Howのセミラティス構造とそれらを導くための 問いという秩序である。各ベン図の大きさや関係性や質には15 の幾何学的特性と構造保存変換を活かすことで自然と生き生き できるようにした。 46

Reference 47

参考情報 • 攻殻機動隊 STAND ALONE COMPLEX • 攻殻機動隊 GHOST IN THE SHELL • スクラムガイド2020 • パターン、Wiki、XP • A Scrum Pattern • 時を超えた建設の道 • パタンランゲージ • Nature Of Order Book1/Book2 • The Battle for the Life and Beauty of the Earth: A Struggle Between Two World- Systems • コンピューター革命はまだ起きていない • 17th State Of Agile Report • The State Of DevOps Report 2024 48