Agile and AI Redmine Japan 2026

Redmine Japan 2026 アジャイルと開発の場づくり〜暗黙知の逆襲〜

Transcript

1. 1 株式会社永和システムマネジメント 平鍋健児 アジャイルと開発の場づくり 〜暗黙知の逆襲〜
2. 平鍋健児 (株)永和システムマネジメント社⻑ (株)チェンジビジョンCTO (株)Scrum Inc. Japan 取締役 アジャイル開発を推進し、国内外で、 モチベーション中⼼チームづくり、ア ジャイル開発の普及に努める。ソフト ウェアづくりの現場をより⽣産的に、 協調的に、創造的に、そしてなにより 、楽しく変えたいと考えている。 アジャイルジャパン初代実⾏委員⻑。 3
3. 4 線形代数の緒概念が、直感的に⼿に取るように把握できます。
4. 永和システムマネジメント 5 本社/福井 ◎ ◎ • 業界は⾦融、医療、⾃動⾞ • Web/Cloud、アジャイル開発 • 社員220名エンジニア集団
5. 共創・共育で利⽤するプラクティス 6 モブプログラミング • ⼀つのPCとディスプレイ • 同じ課題にみんなで⽴ち向かう • 知識伝搬が早い • レビューも同時に⾏うことで効率的 スプリント （1〜4週間） ふりかえり • 毎週（スプリント毎）実施 • ⾃分たちの課題を出し合い改善策を探る • チームワークを⽣み出す効果も 開発はすべてスクラム
6. 顧客の看板の下にチーム 7
7. アジャイル開発 とは何か? スクラム とは何か?
8. 12 プロセスとしてのAgile • 短いサイクルで、分析、設計、実装、テストを並列に⾏う • タイムボックス型、進化型開発 分析 設計 実装 テスト 時間 時間 要求(スコープ) 要求(スコープ) Waterfall Agile Beck 2000 Royce 1970 最後に動くものができる 動くものが徐々に できあがり、成⻑する
9. スクラムの流れ（イベントと作成物） スプリント 計画づくり スプリント 機能リスト 製品増分 製品機能 リスト ⼀週間
10. アジャイル開発 の現場
11. プロジェクトの可視化から はじめましょう。
12. 27 ⾒える化/透明性 l 「最新の正の情報」が、「⼀箇所に」、「⼤きく」書かれ ていて、それを、「両チームのメンバー」、「審判」、「観 客」が⾒ている。 「次の⾏動」を誘発する。 全ステークホルダーが、行動を起こせるような、確かな、分かりやすい情報源 POINT
13. タスクかんばん • 作業の見える化 – ToDo(未実施) Doing(実施中) Done(完了) で管理。 – 各自の作業を指示しなく ても、毎朝自発的に 作業開始。 – フォーマットは徐々に カイゼン。 タスクかんばんの例 ※バーンダウンチャーなどと共に、とにかく、壁に貼る。「情報発信器」とも呼ばれる。 作業の見える化は、「タスクかんばん」で行なう。 POINT (協力：チェンジビジョンastah* チーム） 28
14. 助け合う
15. ⽇本からも海外へ発信 30
16. “Kanban, Successful Evolutionary Change for Your Technology Business” http://www.agilemanagement.net 31
17. http://leansoftwareengineering.com/2007/10/27/kanban-bootstrap/ Corey Ladas 32
18. チームが現場で⼯夫する
19. （協力：ヤマハモーターソリューション） 34
20. ポータブルかんばん 「かんばん-nano」スーツにもベストフィット！ POINT (協力：CCS 佐藤竜一さん） 35
21. バーンダウンチャート • 進捗の見える化 – バーンダウン（下向き） – タスクかんばんと連動 – 中間成果物で は計測しない。 – メールでエクセルシート を配布したり、 サーバに置いたから 見てね、はナシ。 バーンダウンチャートの例 全体進捗は、「バーンダウンチャート」で見える化、繰り返しのリズムづくり POINT (協力：永和システムマネジメント：チーム角谷） 36
22. スルーしない
23. p.38 朝会(デイリースクラム) • 作業の明確化 –⾃発的なサインアップ –ゴールへ向かっているか の確認。 –昨⽇やったこと、 今⽇やること、 問題点などが典型。 –かんばんの前 で、⾏なう。 –朝の仕事はじめが 重要︕ –スタンドアップで１５分． –定時刻、定位置、短時間 朝会の例(協力：チェンジビジョンastah* チーム） 毎朝、「かんばん」の前で全員で短い会議を行ない、リズムをとる。 POINT PF実践編：朝会ガイド http://www.ObjectClub.jp/community/pf/
24. p.39 ふりかえり(1) • カイゼンの気づき – Keep(良い点) Problem(悪い点) Try(次回挑戦) を出す。 – 全員で意⾒を出し、 暗黙知の共同化と 形式知化を⾏なう。「名前付け」 – 「課題－解決リスト」、とは違う。 – とにかく、カジュアルな雰囲気で 全員発⾔することで、チームの 安全性を確保する。 – 「問題vs私たち」の構図になるように。 ふりかえりシートの例 カイゼンの「気づき」を「ふりかえり」で得る。 POINT 実践編：ふりかえりガイド http://www.ObjectClub.jp/community/pf/
25. p.40 ふりかえり(2) • Keep/Problem/Try（KPT） –Keepは定着する。 –ProblemはTryを ⽣み出す。 –Tryは、Keepか Problemに移動する。 –定着したものには、 「名前づけ」を。 ふりかえりがカイゼンを導く Keep Problem Try 新しい問題！ 新しいアイディア！ 解決法 やってみて うまく行った うまく行かない 定着 イテレーション毎に「ふりかえり」を繰り返すことでプロセスが改善される。 POINT
26. あんどん • 異常の⾒える化 – 全受け⼊れテストを⾃動化。 – 毎時バッチで流す。 失敗があれば、即時表⽰。 原因追及。 – ⽋陥のムダを排除。 – ⾃働化とあんどんに対応 – ⽋陥の⻑期滞在を排除。 あんどんの例 異常の見える化は、「ソフトウェアあんどん」で行なう。（受け入れテストを回帰） ※ ⽋陥のムダ＝⽋陥の⼤きさ×プロセス中の滞在時間 POINT (協力：永和システムマネジメント：チーム角谷）
27. 5つの原則 • ⾒える化(Management by Sight) –⽬に⾒えるようにして、⾏動につなげる。 • リズム(Rhythm) –⼈間活動として定期的なリズムを設計する。 • 名前づけ(Name and Conquer) –気づいた概念に名前をつけておく。 • 問題 vs. 私たち (Problem vs. us) –「問題」と「⼈間」を分離する。 • カイゼン（Kaizen) –継続的に、今の⾃分たちにできる、⼩さいことから。
28. 43 ⾒える化/透明性 l 「最新の正の情報」が、「⼀箇所に」、「⼤きく」書かれ ていて、それを、「両チームのメンバー」、「審判」、「観 客」が⾒ている。 「次の⾏動」を誘発する。 全ステークホルダーが、行動を起こせるような、確かな、分かりやすい情報源 POINT
29. p.44 リズム • リズムを「デザイン」する – 四半期、⽉、週、⽇ – 会議や成果物のタイミング – ⽇次のテスト – ⽇次の朝会（毎朝１０︓００） – 週次の会議（毎週⾦曜は。。。） • 朝会、ふりかえりのタイミング • リズムが⾏動の「搬送波」 リズム（チームの鼓動）をデザインして、チームを前進させよう POINT リズムがチームのハートビ ート
30. p.45 名前付け • 「気づき」をキャッチ • ナレッジを， –定着 –他のチームに伝播 • 例︓ –「今⽇のお仕事」 （by 坂⽥さん） –「ぬかどこ」(by 倉貫さん) –「にこにこカレンダー」 名前をつけないと，「気づき」が逃げて行っちゃう！ POINT 名前は⼤切（写真協⼒︓平塚市博物館）
31. p.46 問題対私たち (Problem vs. Us) • ともすると，議論は You vs. Me You vs. Us になりがち． • 「問題」と「⼈」とを分離 • Problem vs. Usにもちこむ。 – ホワイトボードを使う – 座り⽅を替える – ペアプログラミング 不毛なゼロサムゲームから，生産的な議論へ向かうカギ． POINT You vs. Meの構図 You vs. Usの構図 問題 vs. Usの構図 問題 vs. Usの構図
32. p.47 カイゼン • ⼤きな改⾰でははじまらな い • ⼩さなカイゼンから • 今の⾃分たちでできること • 来週からできること • よくなっていくことを体感 しよう • ふりかえり、が強⼒な武器 • For the better tomorrow • 明⽇はきっと今⽇よりも、 いい⽇に決まっている 継続的に、今の自分たちでできることからカイゼンを。うまくいったら自分たちをホメよう。 POINT
33. p.48 ユーザ ストーリ タスク タスク タスク タスク 計画 イテレーション開発 ふりかえり 朝会、かんばん バーンダウン あんどん ペアボード ふりかえり 全体構成 半日 半日 一日の繰り返し １週間 • ⾒える化 • リズム • 名前づけ • 問題対私たち • カイゼン にこにこカレンダー プロダクト バックログ スプリント バックログ デモ
34. 49 •概念＝名前のついたもの。私たちが頭の中で、あるいは、他者とのコミュニケーション に乗せてハンドリングできる単位。 •モノ＝概念のうち、⽬に⾒えるもの。物理法則に従うもの。 世界の理解 概念 コト 未概念 モノ 名前付け ⾒える化 ⼈間の理解の⽅向 ⼈間の理解と、名前、概念、モノ・コト、⾒える化、 •名前づけ＝⼈間は、名前をつけることによってその対象物をはじめてはっきり 認識できる。未概念の名称による概念化。輪郭の切り取り。⾔語操作対象化。 •⾒える化＝⾒えないものを⾒えるようにする（モノ化する）ことによって、よ りはっきりと実体の存在感を得ることができる。 視覚、⾝体感覚、空間感覚（右脳的） 論理、⾔語操作（左脳的）
35. Scrumと野中郁次郎 （組織とアジャイル） 54
37. 最初のスクラムの本 • “Agile Software Development with Scrum” (by Ken Schwaber, Mike Beedle) の最初の⼀ ⾏は次の引⽤で始まっている。 今⽇では新製品開発の動きが速く、競争率の⾼い世界では、速度 と柔軟性がとても重要である。企業は、新製品開発に直線的な 開発⼿法は古く、この⽅法では簡単に仕事を成し遂げることが できないことを徐々に認識し始めている。⽇本やアメリカの企 業では、ラグビーにおいて、チーム内でボールがパスされなが らフィールド上を⼀群となって移動するかのように、全体論的 な⽅法を⽤いている。 -- “The New New Product Development Game”
38. https://hbr.org/1986/01/the-new-new-product-development-game
40. Toyota Production System Lean Lean Software Development Kanban Lean Startup Agile Scrum XP The New New Product Development Game Four steps to the epiphany Agile and Lean Startup Patterns Manufacturing Industry in Japan 2013 Yasunobu Kawaguchi 1 2
41. http://www.publickey1.jp/blog/11/10_innovation_sprint_2011.html Innovation Sprint 2011 Jeff Sutherland Ikujiro Nonaka me
42. SECIモデル 65
43. http://www.flickr.com/photos/visitabudhabi/6708954439/ 暗黙知 l 言語・文章で表現 するのが難しい l 主観的・身体的な 経験知 l 特定の文脈ごとの 経験の反覆によっ て体化される思考 スキル（思い･メン タル･モデル）や行 動スキル（熟練･ノ ウハウ）
44. • 形式知 l ⾔語・⽂章で表 現できる l 客観的・理性的 な⾔語知 l 特定の⽂脈に依 存しない⼀般的 な概念や論理 （理論・問題解 決⼿法・マニュ アル・データ ベース） http://www.flickr.com/photos/stuartpilbrow/4264302708/
45. 知識創造は暗黙知と形式知の相互変換運動である 相互作用の スパイラルアップ アナログ知－デジタル知の動的綜合 言語・文章で表現できる 客観的・理性的な言語知 特定の文脈に依存しない一般的な 概念や論理（理論・問題解決手法・ マニュアル・データベース） 言語・文章で表現するのが難しい 主観的・身体的な経験知 特定の文脈ごとの経験の反覆に よって体化される 思考スキル（思い･メンタル･モデ ル）や行動スキル（熟練･ノウハウ） 暗黙知 （Tacit Knowledge） 形式知 （Explicit Knowledge） © Nonaka I.
46. 組織的知識創造の行為 - SECIモデル 「どう知るか」 - 暗黙知 暗黙知 形式知 形式知 暗黙知 暗黙知 形式知 形式知 共同化(S) 表出化(E) 内面化(I) 連結化(C) O G E G G G G Org. I Environment Individual I I I I I Group I E E I O © Nonaka I. & H. Takeuchi
47. 暗黙知と形式知 － 氷山のメタファー － © Nonaka I. 水面下の領域には、膨大な感覚・イメージ的な経験知がある。 それを共感し、共有し、変換して、新しい知をつくりだす。 形式知 暗黙知 ～～～～～～ １． メタファーの本質とは、ある種類のことがらを別の種類のことがらの 見地から理解し経験することである。 （レイコフ Ｇ. ＆ Ｍ. ジョンソン 『レトリックと人生』 ） ２． 本来まったく異なる領域にあるものどうしを重ね合わせることで、そ の領域にはなかったイメージを導入し、新たな関係（連想・仮説）を 作り出す。 （井崎正敏 『＜考える＞とはどういうことか？』 洋泉社 2008） 例: 暗黙知のイメージ → 氷山のメタファー
48. https://hbr.org/1986/01/the-new-new-product-development-game
50. この絵の左から右へ、 暗黙知のまま移動する⼈
51. Phronetic Team with AI。
52. AIについての⾒解 88
53. 89 AI as a Team Member 考えたこと（平鍋）︓ 2025 年「⾮常によくできる、⽇雇いプログラマー」 Agent 元年 → 2026年「⾃分よりでき、⾃⾛できるエージェント」 → 現在「⼈間が介在しない、ループとハーネスの設計」 競技プログラムやアルゴリズム、よくある設計パターンやAPIは強い。 膨⼤な学習済知識 特定のチームのリポジトリ、チームの⽂化、チームのやり⽅にまだ弱い。ローカル知識 スクラムのオープンエンドなプロセス（試⾏錯誤してやり⽅を変える考え⽅） にAIをうまく乗せることができれば、⼈間とAIが分かり合える可能性がある。 https://note.com/trans_n_ai/n/n11cf35257ff8 https://www.youtube.com/watch?v=lXUZvyajciY Andrej Karpathy 2025
54. 90 https://x.com/mernit/status/2021324284875153544 • 新しい案件 → /cases/ に書き込み • 弁護⼠割り当て → /lawyers/.../cases/ • 時間記録 → /billing/time-sheet • 権限 = Unixファイルパーミッション （juniorは⾃分の案件のみ、partnerは全アクセス） 法律事務所の例 Filesystem as state + OpenClaw as orchestrator (powered by Claude / any LLM) skills 定義例 会社だって、AIだけで作れちゃうよ。
55. 91 2026/3 アリババ（中国）と中⼭⼤学 • 18のAIエージェント（8社）を評価 したところ、75%のモデルがメン テナンス中に既存の動作するコー ドを破壊。 • ⼀時的な修正は⽐較的得意でも、8 ヶ⽉規模の⻑期進化ではほとんど が崩壊。Claude Opus系の⼀部だけ が⽐較的良いゼロ回帰率を⽰した が、全体的に苦戦。 • AIは短期最適化を優先しやすく、 コンテキスト忘却や現実環境の複 雑さで⻑期的に負債を⽣みやすい 。 • この論⽂は「AIはコードを書けるが、 ⻑期メンテナンスは⼈間の仕事」とい う議論をデータで裏付けたもの 実際のプロジェクトでは うまくいかないよ。
56. ３つの未来 • もう⼈間は開発ループには⼊らない。 – (option1)最上位の要求レベルと承認レベルのみは欲しい。 – (option2)⼤きな決定（アーキテクチャとか）には欲しい。 • いや、理解していないソフトウェアは負債となる。 – (option1) ⼈間はPRをレビューすべきだ→もうできない。 – (option2) ⼈+ AI の開発のよいやり⽅がある（ここ︕） • ソフトウェア開発は、将棋のように⼈間が楽しむ技芸。 – 観戦する。 92
57. 周囲のムード（GrokでのX調査 2026/5） • 完全/ほぼ置き換え派（20-30%）: – AIが計画・実装・テスト・レビューまでこなす未来に積極的。 – 特にスタートアップ層で⽬⽴つ。code reviewは「死ぬ」との声も。 • ⼈間介⼊必要派（70-80%）: – architecture判断・⻑期保守性・hallucination防⽌・セキュリティ・ビジネス⽂ 脈は⼈間必須。検証レイヤー（特にアーキテクチャ進化） • ⽇本語圏の最近の投稿（あなたのタイムライン近く） – 「AIがレビュー・修正するが、⼈はplan/architecture/reviewの判断役」という ハイブリッド派が優勢。純粋「⼈間不要」は少ない。 93 AI完全置き換え派 ⼈間介⼊必要派
58. 94 https://zenn.dev/haru_iida/articles/redmine_tokyo_ vol29
59. 弊社社内事例から 95
60. ①AIによるAIのための設計 「設計（Plan）」すらAIが担う時代 自律設計： 面倒だったAI向けの設計をAI自身が爆速で生 成。プログラム仕様に近い。人間が読むのは辛い。 UML同期： 人間にも分かりやすいようにUML等で可視化 してもらうことで、より直感的に把握可能。 Skill制御： 双方向けのフォーマットを同時生成。 このようなチーム固有の設計スタイルもSkillとして容易 に定義することができる。
61. 設計フォーマットをSkillで定義 【AI向け】 【人間向け】 AIがやろうとしていることを把握しやすくなった 効果
62. AIの仕組みから考えた 103
69. 今の⽇本のPDCA はいかん。 PDCA になっている。 オーバーコンプライアンス オーバーアナリシス あらかじめ描かれた、綺麗な Pでなく、みんなで経験して そこから出てくるPが今必要 。
73. 対象に棲み込む －Indwelling－ 提供：本田技研工業 あらゆる状況の 手がかりを統合し て対象に住み込 み、ライダーの視 点(内側)から切開 していく暗黙的な 知り方 「マシンを見てい ると、いろんなこ とがわかります。 あのカーブを切る には、ああやれ ば、こうすれば と･･･。そして次の 製作過程へ自然 に入っているんで す。」
74. その場で概念（コンセプト）を紡ぎ合う 床の上の 設計図 言葉と動作 提供：本田技研工業 言語化によって 初めて自己の考えが 明確になる
76. 12 3 ⼀緒に学ぶの⼤事
77. 12 4 ともに働くのだいじ
78. 12 5 喜びの⾷事だいじ
80. 出典︓東洋経済オンライン https://toyokeizai.net/sp/thinkers/ed/nonaka01.html
81. ちなみに、ぼくが使っている LINE スタンプです。。。