Reframing the Agile Manifesto

Scrum Fest Osaka 2026
https://confengine.com/conferences/scrum-fest-osaka-2026/proposal/50431

Transcript

1. Scrum Fest Osaka 2026 梅田クリスタルホール 2026.08.01 (土) マネージャーこそコードを書こう Reframing the Agile Manifesto 伊藤 浩一 / ESM, Inc.
3. Permanent Agility アジャイルはわたしたちの原点であり、方向でもあります。Permanent Agility （パーマネント・アジリティ）を自身の北極星として指差しながら、アジャイルを 社内に、社外に、そして社会課題の解決に積極的に取り入れて活動していきます。 わたしたちESMのビジョン https://esm.co.jp/vision
4. @koic • OSSプログラマー • RuboCopコアチームコミッター • MCP (Model Context Protocol) steering group • 株式会社永和システムマネジメント (ESM, Inc.) エンジニアリングマネージャー / ディスティングイッシュド・エンジニア
6. 働き方の多様化と採用方針 🗾 •人生の状況にあわせた ライフスタイルを尊重する •関東圏、福井、滋賀、京都 和歌山、島根、福岡、宮崎 からのリモートワーク 絶賛、全国採用中！お気軽にお声掛けください！お仕事のお話もお待ちしております！
7. "楽しさ"にはビジネス価値がある 達人プログラマー David Thomas, Andrew Hunt 1.自らの技術に関心を持つこと 2.あなたの仕事について考えること！ アジャイルサムライ Jonathan Rasmusson 1.君は学ぶことが心から好きだ 2.君はソフトウェアのことを大切に思っている
8. RubyKaigi 2026 (Apr 22) Photo taken by @vipulnsward AI時代のツールの在り方への模索についてひたすら話したカンファレンス
10. 今日の話
11. 中級セッション ☝ AI時代のアジャイルマニフェストの解釈と実践を踏まえて持ってきました
12. きっかけ
13. XP祭り2015 角征典さん基調講演 「XP lives, XP dies, XP lives again!!」より https://kdmsnr.com/slides/20150912̲xp-lives-again/#9
14. 10年後とあるイベントにて (2025年) • 「EMやっていて、ずっと打ち合わせでコード 書いていないんですよ」 • 「私もEMですけどコード書いてますよ？」 • 「ええ、私もEMですけど書いてますよ」 軽快にコード書けばいいのにな 趣味でコード書いている人たちのバイアスがある点は、差し引いてください
15. 2026年の 弊社シニアマネージャ
16. AI時代にどこまで「コードを書かなくても良いか」を知るには手を動かすのが重要
17. https://agilemanifesto.org
18. https://agilemanifesto.org ソフトウェア開発を実 践することを通じて、 よりよい開発方法を 見いだし続けている
19. https://agilemanifesto.org ソフトウェア開発を実 践することを通じて、 よりよい開発方法を 見いだし続けている ソフトウェア開発の実践 を手助けする活動を通じ て、よりよい開発方法を 見いだし続けている
20. https://agilemanifesto.org ソフトウェア開発を実 践することを通じて、 よりよい開発方法を 見いだし続けている 両方を通じて、 よりよい開発方法を 見いだし続けている ソフトウェア開発の実践 を手助けする活動を通じ て、よりよい開発方法を 見いだし続けている
21. https://agilemanifesto.org ソフトウェア開発を実 践することを通じて、 よりよい開発方法を 見いだし続けている 両方を通じて、 よりよい開発方法を 見いだし続けている ソフトウェア開発の実践 を手助けする活動を通じ て、よりよい開発方法を 見いだし続けている マニフェスト署名者たちは、両方を実践してきたと考えられる
22. https://agilemanifesto.org
23. 目次 1. 手を動かしてないことは想像力でしかない 2. マネージャーは何を書くことができるのか 3. マネジメントとアウトカム 4. マネージャーこそコードを書こう
24. 1 手を動かしてないことは 想像力でしかない
25. コードを書く意義とは？
26. 想像力と その先
27. 実作業をイメージできるか？ •「◯◯という画面が遅いので調べて直して」で 何を行えば良いかわかるか？ •APMやプロファイラーでボトルネックを特定 •データベースが原因なら、EXPLAINの取り方と 改善のBofore/Afterをプルリクエストに貼って 説明するまでの手順と実施イメージを持つか
28. エンジニアリング 新技術を抽象と具体を話せるか？ •抽象的な一般論と、プロジェクトでの具体例の 両面で話す知識と経験に根付いた話は対話から アイデアを創発していく種 •特に経験からなる対話は、手を動かさないと出 てこないものがある •近年だとAI技術は使わないと説明の根拠が弱い
29. 標本を集めても 実体験にならぬ
30. 時を超えた建設の道 “ 9章 “花と種” 生きている花をつくろうとすれ ば、ピンセットで細胞を一つ一 つ物理的に組み立てるのではな く、種から育てるであろう Christopher Alexander (4 Oct 1936 ‒ 17 Mar 2022)
31. AIを例に
32. コーディングエージェントの使い方 •モデルの癖 (例: Fable 5, Opus 5, GPT-5.6) •プロンプトへの待ち時間の使い方 •打ち合わせの裏でAIを実行しておくのは、一見 時間効率が良いようで、人間として作業メモリ として覚えておくことが増え、疲れは増える 現代 AI 社会での働き方として、時間効率と疲労対策のいい落とし所を考えたい
33. うわすべり しない技術話
34. 時流のAI話は1on1でまず出てくる アイデアや切磋琢磨できる会話は、お互いの知識と経験からの関係と技術力による
35. エンジニアリング マネージャーのしごと “ 委譲とは、タスクの 実行責任を他の人に 託しつつ、説明責任を 持ち続けることです。 https://www.oreilly.co.jp/books/9784873119946 3.2.2 説明責任は委譲できない James Stanier著
36. 昔偉い人は言いました「百聞は一見にしかず」 •実際のところ、どの程度AIの自律で任せられる かの肌感を獲得する •事例のまた聞きや想像力によるものと、実際の 自分自身の体験による知見から語れる力は説得 力が違う 他人の事例語りパーソンよりも、自身の体験による知見の語りは説得力が上がる
37. 2 マネージャーは 何を書くことができるのか
38. コードには何がある？ •プロダクトのアプリケーションやインフラコード •プロジェクト自動化コード / 運用コード •OSSレイヤーのコード •日常の業務だったり、業務ではないスクリプトのコード •個人開発の趣味コード / 競プロ / IOCCCやTRICKでの 趣きのあるコード / 学習、研究のためのコード
39. お仕事のコード関与例 (弊社CKPTA) •打ち合わせに出 ていないプロダ クトは業務知識 が欠如で難しい •一般的なプロジ Claude Fable 5で 作ったプルリクエスト群 ェクトオートメ ーションは深い 業務知識は不要
40. 仕事のコードでなくても良い 良いと思うものを作っ たら自慢したくなる。 その気持ちこそが大事 結局のところ、自分の手を動かしたアクティビティこそが自身の経験値になる
41. TRICKでの手書き作品 (ぺんさん作) • ぺんさんやmameさんの アレ (github.com/tric) • コードによる最恐アート https://x.com/tompng/status/1582322388678549504
42. 何の役にも立たない プログラムを楽しむ文化 https://www.youtube.com/watch?v=TB-nmGG6uu0
43. 個人から組織まで多様なコード 人間関与 競プロ 特定少数の利用者 不特定多数の利用者 自分のみの利用という個人が最小 生成したコードを読まない狭義のバイブコーディングによる進め方がある現代 度合い 著名OSS 業務プロダクトコード プロジェクト自動化 個人開発アプリ 個人の日常自動化 バイブ
44. 個人から組織まで多様なコード 人間関与 TRICK IOCCC 特定少数の利用者 不特定多数の利用者 自分のみの利用という個人が最小 TRICKやIOCCCといった特殊な環境下で楽しめる世界も依然として存在する 度合い 著名OSS 業務プロダクトコード プロジェクト自動化 個人開発アプリ 個人の日常自動化 バイブ
45. 隙があらばコード
46. 3 マネジメントとアウトカム
47. ドラッカー師曰く、マネジメントとは • 地位と権力を持つものではない • 部下を持つのがマネジメントでは ない • 部下の働きを持つものに責任を持 つことがマネジメントではない (わかるかな？) ☝ • 知識を行動に具体化することに 責任を持つもの
48. 永和システムマネジメント社是 1. 会社の繁栄と社員全員の幸福が常に一致する 経営を行う。 2. 少数精鋭主義を貫くユニークな集団を目指し、 ソフトウェア開発を通じ、社会に貢献する。 3. 和を重んじ、チームプレーを中心に高能率・ 高利益をあげ、信用の増大を図る。 弊社システムマネジメントで名文と謳われる社是をサンプルに再確認してみましょう
49. エンジニアリング "技芸"を持って "技芸"集団の組織が持つ 知識を行動に具体化する これは私のEM論ですが、 それぞれが考え出して持てると良いですね https://twitter.com/morimorihoge/status/1453900986833989634
50. ? 知識を行動に具体化した アウトカムとは？
51. ジュニア育成のアウトカムづくり •Kent Beck「グッドハートの法則はもっと悲観 的に捉えるべきだった」でも育成重要とされる •ジュニアの弱点克服のためトップダウンで師範 付き稽古となる「永和道場」を爆誕させる ボトムアップへの期待放置ではなく、ジュニア層の苦手そうな部分をよく観察する
52. 日報 永和道場 はじめました 入社すると 全文読めます 打ち合わせの 本質はお互い の見識の交換
53. 学ぶために教えること “ お菓子を分け合うと、食べる量は 減ってしまう。しかし、スキルを分 かち合えば、生徒とあなたの両方 が、より多くのものを得ることに なる。それはプラスサムゲームだ。 https://www.oreilly.co.jp/books/9784814401710 シンプリシティ Dave Thomas著
54. 成長するのは自分自身たちしかできない •門下生だけでなく師範もレベルアップする •「師範できそうかな？」「やってみようかな」 くらいが自信づけにもちょうど良い •組織全体のつくる力をレベルアップしていける 環境づくりはマネージャーの仕事のひとつ •メンバーの成長はひとつの大きなアウトカム
55. ? AI時代のジュニア育成方法は？
56. 世界中が困っていて答えはない •ジュニアエンジニアの採用を止めるべきではな いことはわかっている •AI革命により、依然として必要で、何が不要に なったかの線引きは、手を動かさないと実体験 で話せない (それでもケースバイケースだろう) やれることの判断 やらなくて良い判断 •まず足し算ができないと、引き算はできない
57. マネージャーにとって 社会生態学重要
58. 4 マネージャーこそコードを書こう
59. https://agilemanifesto.org/
60. AI時代を踏まえて いま考えていること
61. Individuals and interactions over processes and tools プロセスやツールよりも個人と対話を •様々なことが生成AIというツールによって実現 できるようになったが、依然として他人の世界 観を自分の頭に構築するのは対話によるもの •「この人と仕事をしたい」という相手はAIでは なく人間になるので、人間味を帯びた「対話 力」というのがより重要になるかもしれない
62. Working software over comprehensive documentation 包括的なドキュメントよりも動くソフトウェアを •人間がたくさんのドキュメントが読むのは難し かったが、AIでピンポイントで調べたり、サマ リーすることが可能なので、ドキュメントの 価値が以前より上がった •動くソフトウェアを作るコンテキストとなる ドキュメントとしての意味も含めて改めて ドキュメントの価値が再発見されていそう
63. Customer collaboration over contract negotiation 契約交渉よりも顧客との協調を •契約 (荒ぶる四天王) の元となる見積りに対し 「どう作るから、どれだけ時間が掛かるか」の 実装工程がAIによって転覆した部分がある •依然として優秀なプログラマーであるほど、 より良い問題定義と質の良いアウトカムを生む のでアウトカムへの価値の探索がより重要そう
64. Responding to change over following a plan 計画に従うことよりも変化への対応を •AIを使って何をどうやって実現していけるかは 目まぐるしく変化していっている •モデルやエージェントの変化で、事前に立てた 計画に対してより良い、あるいは悪い結果が 得られる機会をより速めることができる •人間の速度を超える部分があるので健康大事に
65. エンジニアのこゝろと全体性 • 新しい技術が来たときの評価 (生成AI!) • 要求整理からリリースまで繰り返し行われ るなかで、複雑な要件をシンプルな定義に 落とし込めるか？ (作るだけの終焉) • 生成込みでのコードを書かず、新しい時代 のエンジニアとの仕事が見えるだろうか？
66. マネージャの覚悟、EMのこゝろ • 経営、施策、評価、各種フォローなど、覚悟を持っ て臨んでいる経営職、マネージャを多くみている • エンジニアとマネージャーのこころの狭間 • エンジニアメンバーの伸び代を伸ばせる環境づくり • エンジニアとしてどういったところが嬉しくて不満 になるか？想像が想像に過ぎないように努める
67. “ Software is Made for People by People ソフトウェアは人が 人のために作っている 株式会社永和システムマネジメント 会長 平鍋 健児 個 (自分) と個 (他人) がどう時間を過ごすかは、これからの時代より大切になりそう
68. Scrum Fest Osaka 2026 基調講演 @ryuzee