Reframing the Agile Manifesto

by Koichi ITO

Embed

Start on current slide

Slide 1

Slide 1 text

Scrum Fest Osaka 2026 梅田クリスタルホール 2026.08.01 (土) マネージャーこそコードを書こう Reframing the Agile Manifesto 伊藤浩一 / ESM, Inc.

Slide 2

Slide 2 text

No content

Slide 3

Slide 3 text

Permanent Agility アジャイルはわたしたちの原点であり、方向でもあります。Permanent Agility （パーマネント・アジリティ）を自身の北極星として指差しながら、アジャイルを社内に、社外に、そして社会課題の解決に積極的に取り入れて活動していきます。わたしたちESMのビジョン https://esm.co.jp/vision

Slide 4

Slide 4 text

@koic • OSSプログラマー • RuboCopコアチームコミッター • MCP (Model Context Protocol) steering group • 株式会社永和システムマネジメント (ESM, Inc.) エンジニアリングマネージャー / ディスティングイッシュド・エンジニア

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

働き方の多様化と採用方針 🗾 •人生の状況にあわせたライフスタイルを尊重する •関東圏、福井、滋賀、京都和歌山、島根、福岡、宮崎からのリモートワーク絶賛、全国採用中！お気軽にお声掛けください！お仕事のお話もお待ちしております！

Slide 7

Slide 7 text

"楽しさ"にはビジネス価値がある達人プログラマー David Thomas, Andrew Hunt 1.自らの技術に関心を持つこと 2.あなたの仕事について考えること！アジャイルサムライ Jonathan Rasmusson 1.君は学ぶことが心から好きだ 2.君はソフトウェアのことを大切に思っている

Slide 8

Slide 8 text

RubyKaigi 2026 (Apr 22) Photo taken by @vipulnsward AI時代のツールの在り方への模索についてひたすら話したカンファレンス

Slide 9

Slide 9 text

No content

Slide 10

Slide 10 text

今日の話

Slide 11

Slide 11 text

中級セッション ☝ AI時代のアジャイルマニフェストの解釈と実践を踏まえて持ってきました

Slide 12

Slide 12 text

きっかけ

Slide 13

Slide 13 text

XP祭り2015 角征典さん基調講演「XP lives, XP dies, XP lives again!!」より https://kdmsnr.com/slides/20150912̲xp-lives-again/#9

Slide 14

Slide 14 text

10年後とあるイベントにて (2025年) • 「EMやっていて、ずっと打ち合わせでコード書いていないんですよ」 • 「私もEMですけどコード書いてますよ？」 • 「ええ、私もEMですけど書いてますよ」軽快にコード書けばいいのにな趣味でコード書いている人たちのバイアスがある点は、差し引いてください

Slide 15

Slide 15 text

2026年の弊社シニアマネージャ

Slide 16

Slide 16 text

AI時代にどこまで「コードを書かなくても良いか」を知るには手を動かすのが重要

Slide 17

Slide 17 text

https://agilemanifesto.org

Slide 18

Slide 18 text

https://agilemanifesto.org ソフトウェア開発を実践することを通じて、よりよい開発方法を見いだし続けている

Slide 19

Slide 19 text

https://agilemanifesto.org ソフトウェア開発を実践することを通じて、よりよい開発方法を見いだし続けているソフトウェア開発の実践を手助けする活動を通じて、よりよい開発方法を見いだし続けている

Slide 20

Slide 20 text

https://agilemanifesto.org ソフトウェア開発を実践することを通じて、よりよい開発方法を見いだし続けている両方を通じて、よりよい開発方法を見いだし続けているソフトウェア開発の実践を手助けする活動を通じて、よりよい開発方法を見いだし続けている

Slide 21

Slide 21 text

https://agilemanifesto.org ソフトウェア開発を実践することを通じて、よりよい開発方法を見いだし続けている両方を通じて、よりよい開発方法を見いだし続けているソフトウェア開発の実践を手助けする活動を通じて、よりよい開発方法を見いだし続けているマニフェスト署名者たちは、両方を実践してきたと考えられる

Slide 22

Slide 22 text

https://agilemanifesto.org

Slide 23

Slide 23 text

目次 1. 手を動かしてないことは想像力でしかない 2. マネージャーは何を書くことができるのか 3. マネジメントとアウトカム 4. マネージャーこそコードを書こう

Slide 24

Slide 24 text

1 手を動かしてないことは想像力でしかない

Slide 25

Slide 25 text

コードを書く意義とは？

Slide 26

Slide 26 text

想像力とその先

Slide 27

Slide 27 text

実作業をイメージできるか？ •「◯◯という画面が遅いので調べて直して」で何を行えば良いかわかるか？ •APMやプロファイラーでボトルネックを特定 •データベースが原因なら、EXPLAINの取り方と改善のBofore/Afterをプルリクエストに貼って説明するまでの手順と実施イメージを持つか

Slide 28

Slide 28 text

エンジニアリング新技術を抽象と具体を話せるか？ •抽象的な一般論と、プロジェクトでの具体例の両面で話す知識と経験に根付いた話は対話からアイデアを創発していく種 •特に経験からなる対話は、手を動かさないと出てこないものがある •近年だとAI技術は使わないと説明の根拠が弱い

Slide 29

Slide 29 text

標本を集めても実体験にならぬ

Slide 30

Slide 30 text

時を超えた建設の道 “ 9章 “花と種” 生きている花をつくろうとすれば、ピンセットで細胞を一つ一つ物理的に組み立てるのではなく、種から育てるであろう Christopher Alexander (4 Oct 1936 ‒ 17 Mar 2022)

Slide 31

Slide 31 text

AIを例に

Slide 32

Slide 32 text

コーディングエージェントの使い方 •モデルの癖 (例: Fable 5, Opus 5, GPT-5.6) •プロンプトへの待ち時間の使い方 •打ち合わせの裏でAIを実行しておくのは、一見時間効率が良いようで、人間として作業メモリとして覚えておくことが増え、疲れは増える現代 AI 社会での働き方として、時間効率と疲労対策のいい落とし所を考えたい

Slide 33

Slide 33 text

うわすべりしない技術話

Slide 34

Slide 34 text

時流のAI話は1on1でまず出てくるアイデアや切磋琢磨できる会話は、お互いの知識と経験からの関係と技術力による

Slide 35

Slide 35 text

エンジニアリングマネージャーのしごと “ 委譲とは、タスクの実行責任を他の人に託しつつ、説明責任を持ち続けることです。 https://www.oreilly.co.jp/books/9784873119946 3.2.2 説明責任は委譲できない James Stanier著

Slide 36

Slide 36 text

昔偉い人は言いました「百聞は一見にしかず」 •実際のところ、どの程度AIの自律で任せられるかの肌感を獲得する •事例のまた聞きや想像力によるものと、実際の自分自身の体験による知見から語れる力は説得力が違う他人の事例語りパーソンよりも、自身の体験による知見の語りは説得力が上がる

Slide 37

Slide 37 text

2 マネージャーは何を書くことができるのか

Slide 38

Slide 38 text

コードには何がある？ •プロダクトのアプリケーションやインフラコード •プロジェクト自動化コード / 運用コード •OSSレイヤーのコード •日常の業務だったり、業務ではないスクリプトのコード •個人開発の趣味コード / 競プロ / IOCCCやTRICKでの趣きのあるコード / 学習、研究のためのコード

Slide 39

Slide 39 text

お仕事のコード関与例 (弊社CKPTA) •打ち合わせに出ていないプロダクトは業務知識が欠如で難しい •一般的なプロジ Claude Fable 5で作ったプルリクエスト群ェクトオートメーションは深い業務知識は不要

Slide 40

Slide 40 text

仕事のコードでなくても良い良いと思うものを作ったら自慢したくなる。その気持ちこそが大事結局のところ、自分の手を動かしたアクティビティこそが自身の経験値になる

Slide 41

Slide 41 text

TRICKでの手書き作品 (ぺんさん作) • ぺんさんやmameさんのアレ (github.com/tric) • コードによる最恐アート https://x.com/tompng/status/1582322388678549504

Slide 42

Slide 42 text

何の役にも立たないプログラムを楽しむ文化 https://www.youtube.com/watch?v=TB-nmGG6uu0

Slide 43

Slide 43 text

個人から組織まで多様なコード人間関与競プロ特定少数の利用者不特定多数の利用者自分のみの利用という個人が最小生成したコードを読まない狭義のバイブコーディングによる進め方がある現代度合い著名OSS 業務プロダクトコードプロジェクト自動化個人開発アプリ個人の日常自動化バイブ

Slide 44

Slide 44 text

個人から組織まで多様なコード人間関与 TRICK IOCCC 特定少数の利用者不特定多数の利用者自分のみの利用という個人が最小 TRICKやIOCCCといった特殊な環境下で楽しめる世界も依然として存在する度合い著名OSS 業務プロダクトコードプロジェクト自動化個人開発アプリ個人の日常自動化バイブ

Slide 45

Slide 45 text

隙があらばコード

Slide 46

Slide 46 text

3 マネジメントとアウトカム

Slide 47

Slide 47 text

ドラッカー師曰く、マネジメントとは • 地位と権力を持つものではない • 部下を持つのがマネジメントではない • 部下の働きを持つものに責任を持つことがマネジメントではない (わかるかな？) ☝ • 知識を行動に具体化することに責任を持つもの

Slide 48

Slide 48 text

永和システムマネジメント社是 1. 会社の繁栄と社員全員の幸福が常に一致する経営を行う。 2. 少数精鋭主義を貫くユニークな集団を目指し、ソフトウェア開発を通じ、社会に貢献する。 3. 和を重んじ、チームプレーを中心に高能率・高利益をあげ、信用の増大を図る。弊社システムマネジメントで名文と謳われる社是をサンプルに再確認してみましょう

Slide 49

Slide 49 text

エンジニアリング "技芸"を持って "技芸"集団の組織が持つ知識を行動に具体化するこれは私のEM論ですが、それぞれが考え出して持てると良いですね https://twitter.com/morimorihoge/status/1453900986833989634

Slide 50

Slide 50 text

? 知識を行動に具体化したアウトカムとは？

Slide 51

Slide 51 text

ジュニア育成のアウトカムづくり •Kent Beck「グッドハートの法則はもっと悲観的に捉えるべきだった」でも育成重要とされる •ジュニアの弱点克服のためトップダウンで師範付き稽古となる「永和道場」を爆誕させるボトムアップへの期待放置ではなく、ジュニア層の苦手そうな部分をよく観察する

Slide 52

Slide 52 text

日報永和道場はじめました入社すると全文読めます打ち合わせの本質はお互いの見識の交換

Slide 53

Slide 53 text

学ぶために教えること “ お菓子を分け合うと、食べる量は減ってしまう。しかし、スキルを分かち合えば、生徒とあなたの両方が、より多くのものを得ることになる。それはプラスサムゲームだ。 https://www.oreilly.co.jp/books/9784814401710 シンプリシティ Dave Thomas著

Slide 54

Slide 54 text

成長するのは自分自身たちしかできない •門下生だけでなく師範もレベルアップする •「師範できそうかな？」「やってみようかな」くらいが自信づけにもちょうど良い •組織全体のつくる力をレベルアップしていける環境づくりはマネージャーの仕事のひとつ •メンバーの成長はひとつの大きなアウトカム

Slide 55

Slide 55 text

? AI時代のジュニア育成方法は？

Slide 56

Slide 56 text

世界中が困っていて答えはない •ジュニアエンジニアの採用を止めるべきではないことはわかっている •AI革命により、依然として必要で、何が不要になったかの線引きは、手を動かさないと実体験で話せない (それでもケースバイケースだろう) やれることの判断やらなくて良い判断 •まず足し算ができないと、引き算はできない

Slide 57

Slide 57 text

マネージャーにとって社会生態学重要

Slide 58

Slide 58 text

4 マネージャーこそコードを書こう

Slide 59

Slide 59 text

https://agilemanifesto.org/

Slide 60

Slide 60 text

AI時代を踏まえていま考えていること

Slide 61

Slide 61 text

Individuals and interactions over processes and tools プロセスやツールよりも個人と対話を •様々なことが生成AIというツールによって実現できるようになったが、依然として他人の世界観を自分の頭に構築するのは対話によるもの •「この人と仕事をしたい」という相手はAIではなく人間になるので、人間味を帯びた「対話力」というのがより重要になるかもしれない

Slide 62

Slide 62 text

Working software over comprehensive documentation 包括的なドキュメントよりも動くソフトウェアを •人間がたくさんのドキュメントが読むのは難しかったが、AIでピンポイントで調べたり、サマリーすることが可能なので、ドキュメントの価値が以前より上がった •動くソフトウェアを作るコンテキストとなるドキュメントとしての意味も含めて改めてドキュメントの価値が再発見されていそう

Slide 63

Slide 63 text

Customer collaboration over contract negotiation 契約交渉よりも顧客との協調を •契約 (荒ぶる四天王) の元となる見積りに対し「どう作るから、どれだけ時間が掛かるか」の実装工程がAIによって転覆した部分がある •依然として優秀なプログラマーであるほど、より良い問題定義と質の良いアウトカムを生むのでアウトカムへの価値の探索がより重要そう

Slide 64

Slide 64 text

Responding to change over following a plan 計画に従うことよりも変化への対応を •AIを使って何をどうやって実現していけるかは目まぐるしく変化していっている •モデルやエージェントの変化で、事前に立てた計画に対してより良い、あるいは悪い結果が得られる機会をより速めることができる •人間の速度を超える部分があるので健康大事に

Slide 65

Slide 65 text

エンジニアのこゝろと全体性 • 新しい技術が来たときの評価 (生成AI!) • 要求整理からリリースまで繰り返し行われるなかで、複雑な要件をシンプルな定義に落とし込めるか？ (作るだけの終焉) • 生成込みでのコードを書かず、新しい時代のエンジニアとの仕事が見えるだろうか？

Slide 66

Slide 66 text

マネージャの覚悟、EMのこゝろ • 経営、施策、評価、各種フォローなど、覚悟を持って臨んでいる経営職、マネージャを多くみている • エンジニアとマネージャーのこころの狭間 • エンジニアメンバーの伸び代を伸ばせる環境づくり • エンジニアとしてどういったところが嬉しくて不満になるか？想像が想像に過ぎないように努める

Slide 67

Slide 67 text

“ Software is Made for People by People ソフトウェアは人が人のために作っている株式会社永和システムマネジメント会長平鍋健児個 (自分) と個 (他人) がどう時間を過ごすかは、これからの時代より大切になりそう

Slide 68

Slide 68 text

Scrum Fest Osaka 2026 基調講演 @ryuzee