BPStudy-164 アジャイル開発とスクラムの今を語ろう
BPStudy#164〜アジャイル開発とスクラムの今を語ろう
https://scrapbox.io/files/608941f4cdac86002213863c.png
ログミー書き起こし
第1部 BPStudyラジオ〜アジャイル開発とスクラムの今を語ろう
(19:00〜20:15)
パーソナリティ
進行役
平鍋さんオススメの動画:
RSGT2021 - Closing Keynote - Ikujiro Nonaka 野中 郁次郎 - YouTube https://www.youtube.com/watch?v=s-zUWCQkUa4
アジャイル開発の馴れ初め
良い感じのプロジェクトの進め方だなと思っていたら、あとから「これはアジャイル開発って言うんだよ」と教えてもらった
それまで「できる人」がやっていた手法が明文化されていた 「システム開発で一番大切なことは、リリースしたらお客さんと一緒に美味しいものを食べることです」と書いてあってなんじゃこりゃ、とおもった。でも実際に良いプロジェクトってそういうものですよね。
システムのアーキテクチャパターンと相似形でチームパターン（コミュニケーションデザイン？）がある
でもね、契約でうまくいかなくてね・・
haru: 私は平鍋さんがJava Worldに書いた記事を読んだのが出会い
その後、オブジェクトデイというイベントで平鍋さんに実は会いに行ってました
アジャイル開発について（あまりメモ取れず）
及部: デンソーでもアジャイルが普通になっている。カンバン方式もアジャイル
平鍋: どれだけ一般化したと思っても、アジャイルに抵抗を感じる人もたくさんいる。そういう人達と戦っちゃいけない、そうですね！って言ってます
haru: 受託で大手さんからの契約のときには「契約書の雛形ありますか」ってよくいわれて、IPAのやつを出してるんですけど、あれはあれで偏ってて
平鍋: ある会社で、新しい契約フォーマット「準委任（アジャイル型）」を用意してもらえたことがあった
コミュニケーションデザイン
haru: 日々の開発や活動で楽しくするために意識してること、実践してることはありますか？
及部: よく「楽しそうだね」って言われるんですが、意識してるのは「この仕事は楽しい・楽しくない」と思ってるときは批評してしまっていると感じる。批評せず、プロレスみたいに、無理難題を言ってくる人がいても「おっきたな！」って思いながら対応したりしてます
平鍋: 僕も、本のサインに「仕事を楽しくやりましょう」って書くんですが、よく考えると仕事が楽しく無さそうな社長っていやじゃないですか。社長室に来た人には元気になって帰ってもらいたい。楽しくやることも仕事だと思ってます。細かいことだけどライフハックが好きで、今週は家の周りの水仙がキレイだったので刈り取って、良い感じの花瓶がなかったので徳利に差して社長室においたら「おーっ、いいじゃん」っていう感じになって、そういうちょっとした工夫をするのが良いと思うんですよね。
haru: 共通するのは「楽しい」じゃなく「楽しむ」なんですね
haru: アジャイル開発の中の事例はなにかありますか？
及部: 大体楽しいんですけど、バラバラで働いていると辛かったりつまらなかったりすることもあるけど、アジャイル開発は意見交換することが増えたなと思って、ここ4年くらいはモブプログラミングを取り入れてやってます。モブプログラミングのなかで「おっ、これできたらビール飲めますね」とか言ってたら、他のメンバーにも伝播していって同じようなことを他のメンバーも言うようになってきました haru: ところで金髪ってデンソー大丈夫なんですか？
及部: ダメって言われてもぼく変わらないんで。短パンで工場に入ったらさすがに怒られましたね。危ないんで。
平鍋: 今は開発やらなくなったけど、以前得意だった時期は10人くらいのチームで、Makefileのテンプレートの機能でincludeして良い感じにまとめてたんですが、 make coffee っていうコマンドを仕込んで自分で盛り上がってました。
haru: 最近だとSlackのbotとか、リアクションに仕込めるようになってきましたね
平鍋: そういう仕掛けを、偉めのひとがやるといいんですよね。そうすると他の人もやるようになって。僕が make coffee 作ったら別の人が make loveって作りやがって。もうこれ以上は言わないですけど。
及部: 教育的効果があるって言われてます。SECIモデルでいう形式知を伝えられますね。コードだけでは伝わらない「なんでこういう風に作ったのか」「どう考えてどう意思決定したのか」を共通体験にできる。これは仕事のうえですごいパワーになる。他に、モブプログラミングはコードが出来た瞬間にもうチームで合意が取れている状態になっている。モブでやっていると「ここは完成した」というのが分かりやすい。インクリメントしていることが実感できる。あとは効率。最初のころは分業した方が効率がいいっていう感覚に囚われてしまっていた。ペアやモブは一緒にやりましょう、だから効率は悪いと思われてしまう。でも、分業でやってあとから合意までに時間がかかることもあって、モブでやったほうが結果的に早かったということも多々ある。 平鍋: 形式知情報に残せるかどうかとは別に、「ここ悩んだよね」みたいな体験が共有出来る。ブーチのトライバルメモリー（部族記憶）・・・（メモ間に合わず） haru: 及部さんの教育効果についてなんですけど、駆け出しエンジニアって、シニアは悩まずにパパパッとコードを書いていくと思ってるようなんですけど、実際にはシニアも悩むのでそういうことが共有できるのが大事かなと。あとツールの使い方も共有できるのがいいと思う。ツールもどんどん変わっていくので知らない機能が増えていく。
及部: コードを書いているのを見られるのが嫌だ、っていう人もいるんですよ。書いてる途中は自信が無いので嫌だなって思ってしまう。気持ちは分かるけど、そういうところも見せられるチームの方がいいじゃないですか。そういうのを見せたくない自分に気づける、っていうのも大事。
haru: モブって1日どのくらいやるんですか？私はぼけーっとしてる時間も欲しいなって思うんです
及部: モブってけっこう集中すると疲れるんですよ。一気にやろうとおもって最初は朝から晩までやってたんですが、最近は4時間くらいでぎゅっとやって、後の時間は情報を整理したり他のことをしたりメールを読む時間にしてたりしてます。
平鍋: この本の「モブワーク」のセクションを及部さんに書いてもらったんですが、すごいいい話が書いてあるんです。営業の人がきたときに提案書をスクリーンに映し出してモブで作ったと言う話がって「ああ、こういうことこういうこと」って思いました。
haru: 以前及部さんがモブについてネットに書いてたのを見て自社に取り入れたりしてます。モブテストとかモブワークといってやってたりします。
haru: 「包括的なドキュメントよりも動くソフトウェア」を引用して「ドキュメントは悪」みたいに言う人も居て
平鍋: できるだけ書かない方が良いと思ってはいますけど、開発をしてると必ずステークホルダーがいて、そういったお隣さんに対してはコードだけでは伝わらないので、そういったステークホルダーに何を残したら伝わるだろう、っていうのをバックログに残したりしてます。誰が、が大事。部族記憶で足りるならドキュメントはわざわざ書かない。足りないなら書く。Q&Aは完全に文脈依存なのでドキュメントに残していかないといけない。
及部: ちょうど最近チームで「ドキュメント大事じゃん」という話題がでたところ。自分はできるだけドキュメント書かない方がいいと思ってるんですけど、「包括的なドキュメントよりも動くソフトウェア」っていうのをきいて「動くソフトウェア」ってあたりまえじゃんって思う。（中略）でも人は忘れるし、忘れてしまったものは取り戻せないので、「どういうドキュメントを必要最低限で残していくか」「どの精度で残すか」はいまちょうどホットなトピックです。
平鍋: テストコードを書くのが上手な人は、ドキュメント書くのも上手だよね。量もちょうど良いし読みやすい。
質問コーナー
Q. 質問:第3版が10年後に出ると仮定した場合、どんな事例が生まれていてほしいですか？
A. 平鍋: 10年って想像つかないな、って思ったけど1版から2版で10年経ってるんだよね・・
A. 及部: 「アジャイル開発やりました組織が良くなりました」、っていう事例は増えて欲しいけど、「そのチームが作ったのがこのプロダクト」という実際の成果が評価されるような事例をどんどん増やしたい。
haru: DXの流れの中でアジャイル開発、スクラムが注目されてますからね
平鍋: 元々アジャイルは「ビジネスの価値」を高めるための手法なので、手法だけじゃなく実際の成果が評価されるようになっていってほしいですね。今は成果を切り離して、手法だけで語られる状況。
平鍋: スクラムがソフトウェアを卒業していくのは何らかの本質を失うのではないか・・・いや良い事なのかもしれないんですけどね。
平鍋: コンペティター（同業他社）があつまって勉強会をやるようなのは他の業界から見ると異質なんですってね
shimizukawa.icon『風立ちぬ』のワンシーンを思い出した。エンジニア特有なのかな
（中略: 製造業での話、官庁での話・・・）
Q. 『アジャイル開発とスクラム』というタイトルですが、最近アジャイル開発(XP)とスクラムとの距離が離れていってると感じています。今後この2つの関係はどうなっていくと思いますか？
A. 平鍋: XPはソフトウェア開発のやり方で閉じてるんですよ。ソフトウェア開発は「ソフトウェア開発」と「チーム開発」の2つがあって。スクラムは「こういう3,5,3のやり方で開発するとコンパクトに済むんですよ」っていうところから最低限のところを抜き出してまとめた。XPがあればスクラムが無くてもソフトウェア開発ができる。スクラムはソフトウェア開発以外にも適用できる、そんな風に捉えてます。
A. 及部: いつぐらいにアジャイルに触れたかでも変わるかなと思うんですが、XP祭り2018くらいの角谷さんの基調講演が印象的でした。さらに新しい世代の人たちは「それがXPだ」と意識せずにやってるんじゃないかと思います。開発とビジネスが離れてしまっているとも言われるんですが、ホントにそうかなと思うことがある。広まったからこそ遠いところで使われているように思われているだけでは。遠くなったと思うなら、近づけるようにやればいい。
さいごに、書籍の読みどころ
平鍋: この本を英訳したいと思っていて、オファーをPragmatic Bookshelf のDave Thomasからもらって、その時は踏ん切りが付かなくて書けなかった。もう一度チャンスがあるなら、野中 郁次郎先生の（...）これだけソフトウェアがアメリカ、中国が強くなってしまって、参照される日本は過去のものになってしまっている状況はどうなの？アメリカや欧州のものが良い事だと言われて学ぶことはそれはそれで良いこと。でも日本は学んだことで成功していない。だから及部さんのいうように成功事例を積み上げたい。そういうのがナシで「スクラムは日本発祥です」って書けない。第3版があるならそういう話を書けるようにしたい。 及部: この本がすごく良いなって思うのは、アジャイル開発をいまから知ろうと思ったときに、この1冊で今のアジャイル開発の流れ全体が分かる。この本を読むと自分の現在位置が分かる。平鍋さんの話に繋げると、この本自体が過去のもの。この本に勝たないといけない。この本よりうまくいったら良いし、そうでなかったらまだまだだなと思う。この本の情報で高速道路にのって抜かしてしまえばいい。
haru: 私も経営者の端くれなので、第3部を読んでおー、って思って、そこで紹介されてるワイズカンパニーっていう本を読んでさらにおーってなりました。 平鍋:
https://scrapbox.io/files/608945e1f354a1001efd7891.png
「会社はそこここに起こる会話にある」
おわり
その後、延長線で残って飲みながら会話する人達がいたみたい。