What We Talk About When We Talk About XP

by seki at druby.org

Embed

Start on current slide

Slide 1

Slide 1 text

XPについて語るときに私たちの語ること What We Talk About When We Talk About XP

Slide 2

Slide 2 text

これまでのあらすじ ✦ 医療機器をXPで開発（25年くらいやってた） ✦ ミッションクリティカル、製造業で非常に大きいシステム ✦ 2004年から2025年までさまざまな場で報告した ✦ 報告を聞いてくれた人たちが「あのチーム」と呼ぶようになった ✤ あのチーム = 前職のチームの他称 🥷今日の話で出てくる「あのチーム」とはこういうチームだよ！ 2

Slide 3

Slide 3 text

2025 あのチーム編のラスト 3

Slide 4

Slide 4 text

XPについて語るときに私たちの語ること What We Talk About When We Talk About XP 関将俊・深谷美和（三菱電機株式会社）

Slide 5

Slide 5 text

自己紹介関将俊プログラマー。2001年からXPを実践。RubyKaigi 2006-2024, 2026、RubyConf2013、 RubyWorld Conference 2023-2025スピーカー。主な著作は『The dRuby Book』、『プログラマが知るべき97のこと』（日本語版エッセイ）。深谷美和ソフトウェア開発に従事。eXtremeな開発者（テスター）。動かして試すのが好き。 🥷 2026/1より現職。なんとふたりで三菱電機に転職 5

Slide 6

Slide 6 text

XPのかけらである私たちが語ればXPの話という論理で押しきります ✦ 語り合うスタイル ✦ その様子からXPを感じて欲しい僕らエクストリームはプログラミングのかけら角谷信太郎(@kakutani) 09/21(土), XP祭り2019 🥷XP祭りに集まる人を信じている https://speakerdeck.com/kakutani/xpmatsuri2019-keynote 6

Slide 7

Slide 7 text

今日語ること新しい環境でなにをはじめて、どうなったか ✦ なにからはじめたか ✦ なんでいつも通りのことがおきたのか！？ ✦ 忍者式テスト ✦ ひとつのソーシャルチェンジ 🥷いつも通りやってます！という事例紹介です 7

Slide 8

Slide 8 text

なにからはじめたか 8

Slide 9

Slide 9 text

なにからはじめたか ✦ 「いいチームがあるから一緒にやってみてください」 ✤ ふたりがきても大丈夫そうなチームを選んでくれた ✤ ほどほどに動くモノがある、ちょっと部活みたいなチーム ✤ なにをするかはふたりにお任せ ✦ なにをしたか ✤ テストして、問題を見つけて、直してもらう、の繰り返しの状況を作った 🥷XPぽい！ 9

Slide 10

Slide 10 text

いつも通りのテストをする ✦ うごくソフトウェアを手で触って違和感を見つける ✤ 中間成果物（部品／書類）をレビューするイベントじゃないよー ✤ 手で触って違和感を見つける = 知らない問題を探すために触る 🥷つまりCIとかじゃないよ？（それはbuildの一部じゃね）次はテストとはなにか 10

Slide 11

Slide 11 text

テストとはなにかエラーを発見する目的でプログラムを実行する過程がテストである． (ソフトウェアの信頼性 p.194) 「発見」。知ってることは発見とは言わなそう 11

Slide 12

Slide 12 text

「仕様の通り」も疑わしいだろ？ 1.2 エラーとは何かよくある定義の一つは，仕様の通りにソフトウェアが実行されない時にソフトウェアのエラーが生じたとするものである．この定義には根本的な欠陥がある．仕様が常に正確であることを前提にしている．この前提が正しいことのほうが，むしろ稀である． (ソフトウェアの信頼性 p.5) 12

Slide 13

Slide 13 text

仕様のエラーも見つけたいのは当然だエラーを発見する目的でプログラムを実行する過程がテストである． (ソフトウェアの信頼性 p.194) 「仕様」などあらゆる設計を疑う！ 13

Slide 14

Slide 14 text

いつも通りの問題が見つかった！心配なこと、気になることすべて ✦ 動いてない ✦ 役に立たなそう ✦ 評判が落ちそう ✦ ほかにも気になることすべて 🥷ソフトウェアそのものだけでなく周辺のユーザー向けドキュメントなども含めたさまざまなこと 14

Slide 15

Slide 15 text

いつも通り直してくれた ✦ 情報をみんなに提供したら直してくれた！（直せとは言ってない（と思う）） ✤ どれを直すかはお任せしてた（ここはこれまでと違うところ） ✤ 原因や修正方法などからシステムを理解した ✤ そしてもっとバグを出す ✦ 現象を聞いて、問題のコードを調べて、直し方を提案 🥷あのチームでもm̲sekiはコードを直接書かなかった（プロの無職なので） 15

Slide 16

Slide 16 text

どうもモノがよくなっているらしい ✦ ソフトウェアの評判はよくなった ✦ 付き合った人たちはハッピーそう 🥷インタビューしたら「ピリッとした」と言われた。たぶんmiwaのせい 16

Slide 17

Slide 17 text

あのチームでおきていたことが再現さらに！ ✦ 付き合ってくれた人の行動 ✤ 「深谷さんがやりそうなところを直しておきました」 ✤ 「指摘されると思ってました」 ✤ 詳細に考えましょう！じゃなくて、「ああここまで試してくるのかー」「考えてくるのかー」を目の当たりにしたからだと思う ✤ みんなでひとつの巨大な脳になっていく感じがした 🥷再現性ありそう 17

Slide 18

Slide 18 text

あのチームでおきていたことが再現巨大な脳って... 🥷ソフトウェアシンポジウム2023 https://www.sea.jp/ss2023/download/15-ss2023.pdf 18

Slide 19

Slide 19 text

あのチームでおきていたことが再現チームの価値観の醸成ロールプレイングゲーム 2010年 https://druby.hatenablog.com/entry/20101202/p1 19

Slide 20

Slide 20 text

なんでいつも通りのことがおきたのか！？ 🥷いつも通り(A)やってたらいつも通り(B)のことがおきた！！ 20

Slide 21

Slide 21 text

なんでいつも通りのことがおきたのか！？ ✦ miwaの問い ✤ ちがうメンバーなのになぜおなじことがおきたんだろう（よいことがおきた） ✦ m̲sekiの仮説 ✤ ふたりで「いつも通り」の態度・行動で接していたら、みんなもつられてやっちゃった！？ 🥷SECIモデルで説明してみよう 21

Slide 22

Slide 22 text

SECIモデル知識の伝播のモデル - スパイラルしてるのは組織でなく知識の方だよ SECIモデルを誤解するぞ [Nonaka 98] Nonaka, I. and N. Konno (1998). "The Concept of 'ba': Building a Foundation for Knowledge Creation," California Management Review , 40-3, pp.40-54, 1998. http://www.jaist.ac.jp/ks/labs/umemoto/ai_km.html デブサミの廊下ゲリラライブ「表出化は誤解を期待してるよ仮説」 22

Slide 23

Slide 23 text

SECIモデル知識の伝播のモデル - 暗黙知チームで動いてるとき SECIモデルを誤解するぞ知はみんなの血肉になっている暗黙知内面化共同化情報は濃密に交換されててエラー訂正頻繁 [Nonaka 98] Nonaka, I. and N. Konno (1998). "The Concept of 'ba': Building a Foundation for Knowledge Creation," California Management Review , 40-3, pp.40-54, 1998. http://www.jaist.ac.jp/ks/labs/umemoto/ai_km.html 形式知のままでは行動できない。暗黙知にする必要がある（内面化）。同じ場で活動しながら伝え合う（共同化） 23

Slide 24

Slide 24 text

SECIモデル知識の伝播のモデル - 形式知へチームの外へ言いふらす SECIモデルを誤解するぞ短期間で全てを伝えられないコンセプトにして外に出すある視点/モデルで切り取って誇張する表出化 [Nonaka 98] Nonaka, I. and N. Konno (1998). "The Concept of 'ba': Building a Foundation for Knowledge Creation," California Management Review , 40-3, pp.40-54, 1998. http://www.jaist.ac.jp/ks/labs/umemoto/ai_km.html 全部伝えるのは無理（当たり前） 24

Slide 25

Slide 25 text

SECIモデル知識の伝播のモデル - 形式知を解釈誰かが受信 SECIモデルを誤解するぞ受信側のもってるコンセプトと混ぜて受ける結合化エラー訂正はないし100%伝わることは期待してない [Nonaka 98] Nonaka, I. and N. Konno (1998). "The Concept of 'ba': Building a Foundation for Knowledge Creation," California Management Review , 40-3, pp.40-54, 1998. http://www.jaist.ac.jp/ks/labs/umemoto/ai_km.html エラー訂正がないのはよいことかも！ 25

Slide 26

Slide 26 text

SECIモデル知識の伝播のモデル - 暗黙知と形式知のループ表出化と結合化 SECIモデルを誤解するぞ花粉をまく受粉する積極的に伝播エラーを誘うことで似ているようで違うものを生み出すよりよくなるとも限らない挿し芽みたいなクローンじゃない [Nonaka 98] Nonaka, I. and N. Konno (1998). "The Concept of 'ba': Building a Foundation for Knowledge Creation," California Management Review , 40-3, pp.40-54, 1998. http://www.jaist.ac.jp/ks/labs/umemoto/ai_km.html スパイラルしてるのは組織ではなく知識の方である 26

Slide 27

Slide 27 text

今回のケース劣化しやすい形式知を経由しないダイレクトな知識の伝播 SECIモデルを誤解するぞ [Nonaka 98] Nonaka, I. and N. Konno (1998). "The Concept of 'ba': Building a Foundation for Knowledge Creation," California Management Review , 40-3, pp.40-54, 1998. http://www.jaist.ac.jp/ks/labs/umemoto/ai_km.html 🥷あのチームのかけらである私たちが、同じ場で一緒に活動することによって、あのチームの暗黙知を伝えたのであった！！お買い得！！ 27

Slide 28

Slide 28 text

ふたつのチームに影響を与えたと思う！ ✦ チームA ✤ 用意してもらったチーム。できそうで、やっぱりできた ✦ チームB ✤ 出会い頭の事故的なはじまり ✤ 意図してなかったが、できてしまった ✤ えも言われぬ感じでよくなった（目がキラキラしてた） 🥷そういえばラムダノート📕でも似たようなことが起きた！ 28

Slide 29

Slide 29 text

ふたりのやってること ✦ 表面的には「テストして、問題を見つけて、直してもらう」ことだけに見える ✤ 同じ場で一緒に仕事をした→共同化 ✤ 言葉にならない価値観や知が伝わった ✤ 「品質重要」「テスト大事」とかキャッチフレーズは言ってない - （やってないことはたくさんあるがそれを知るには一緒に仕事しないとわからない） ✦ 表面的な結果としてモノがよくなる ✤ 同時にチームもちょっと変わる 🥷XPの本にあるプラクティスはひとつもやっていないがXPになってる気がする 29

Slide 30

Slide 30 text

発見されにくいロール ⌛時計を見る 30

Slide 31

Slide 31 text

言いにくいことを言う係 ✦ あの仕様がなんで必要なのかわかんないんだよね（例） ✤ 作った方も、作ってもらった方も言えない ✤ issueとして指摘しちゃう ✦ 具体的な問題を使って話す ✤ ぼやっとしてるイヤなことを具体的に ✤ 解法も一緒に話してるかも！？ 🥷言いにくいことを言う係として利用してもらえてる感じがする 31

Slide 32

Slide 32 text

言いにくいことを言う係垣根見えてない ✦ 「垣根を越える」とか言うのは垣根が好きな人！ 🥷いろんな事情を知らない良さ 32

Slide 33

Slide 33 text

プロの無職プロの無職がふたりになった！ ✦ タスクを一切割り当てない ✦ 無責任範囲がない ✦ 説得・共感でしか伝えられない ✤ 権力がない ✤ エモさではなく技術的な共感 🥷開発チームに属してないが、どのチームとも一緒にやる 33

Slide 34

Slide 34 text

無任所開発者 developer without portfolio ✦ チームに所属してるところがちがうけど、だいたい同じ 🥷DWPはminister without portfolioから取られてる 34

Slide 35

Slide 35 text

忍者式テスト ⌛残り5分のはず 35

Slide 36

Slide 36 text

忍者式テスト ✦ あのチームの活動を説明するのに便利なプラクティスの名前 ✦ テストを起点とした開発全体のありようを述べている ✦ 全てのストーリーが手動のテストケースをベースに作られる ✦ 未知の問題を見つけるために毎日全部テストし直す 🥷やってるの？ 36

Slide 37

Slide 37 text

あのチームの最初期の状態になっている ✦ 関が全部触るから直せ！（当時） ✦ 二人が触るよー！（いま） 🥷原初のあのチームの姿とほぼ同じ（機能の管理はしたい） 37

Slide 38

Slide 38 text

忍者式テストみたいな工夫が必要になる状況にはならないかも ✦ 「全部テストしなきゃならないのかー」とうんざりする規模じゃない ✦ 仕様が覚えきれなくなったらなにか必要になる 🥷暗記してるよね？（暗記できているかもテストでわかる） 38

Slide 39

Slide 39 text

ひとつのソーシャルチェンジ 39

Slide 40

Slide 40 text

ひとつのソーシャルチェンジ ✦ いいものにしたい！という強い気持ちは環境によってかわらなかった ✤ あのチームだから、医療機器だから、というのは強い要因ではなかったのかも ✦ いつも通りすることが許されてる（？）のでその気持ちを保てている ✤ ロールはまだ名前がない（無任所開発者を自称するか！？） ✦ 自分たちがいつも通りにすることで、周囲に変化が起きている！ 🥷私たちにつられて変わってしまったタイプのソーシャルチェンジかも！？ 40

Slide 41

Slide 41 text

いつも通りやってます XPを感じた？ 41