こまぶろ

技術のこととか仕事のこととか。

トップ > 開発手法 > 2018年8月23日「第133回白熱塾 きょん、やっとむ、ryuzeeらと語るアジャイル開発の本質」に参加した

2018年8月23日「第133回白熱塾 きょん、やっとむ、ryuzeeらと語るアジャイル開発の本質」に参加した

開発手法 イベント

8月23日の夕方から、「きょん、やっとむ、ryuzeeらと語るアジャイル開発の本質」（@デンソー東京支社）に参加してきた。

connpass.com

錚々たる登壇者の方々であることに加え、Connpassで参加者として登録している方の中にも単独でメイン登壇者が務まる方が複数いらっしゃる豪華イベント。テーマとしても、「本質を理解しないままのアジャイル開発に挑む危うさ」というもので、どんな話がされるのだろうと期待を膨らませながら当日を待っていた。

各登壇者の発表資料&参加者の方によるグラレコ

各登壇者ごとに簡単な紹介と発表資料（きょんさんは未公開）をまとめておく。内容については、共同主催のクリエーションライン社からレポートが出ているので、そちらをご参照ねがいたい。

また、参加されていたgaoryu*1（@DiscoveryCoach）さんと渡部そば（@sobarecord）さんがグラレコ（Graphic Record）をされていたので、ご紹介させていただく。

やっとむさん

やっとむ（@yattom）さん。お恥ずかしいことに、お名前に印象がなかったのだが、「安井力」という文字列は僕の自室の中にある何冊もの書籍に見出すことができる。翻訳書を多数出しておられて、ちょうど来週『テスト駆動Python』も出版されるところとのこと。

テスト駆動Python

テスト駆動Python

きょんさん

きょん（@kyon_mm）さん。Regional Scrum Gathering Tokyoなど、スクラムのイベントでの登壇が多数あり、エクストリームなスクラム実践者として有名だ。僕は、「しがないラジオ」のsp.22にゲスト出演されていたのを聴いてショックを受けたのが初めて彼の名前を知った時だった。

shiganai.org

（2018.08.27追記）

資料の公開はなされないそうです。

ryuzeeさん

ryuzee（@ryuzee）さん。吉羽龍太郎さんというと、『SCRUM BOOT CAMP THE BOOK』の共著者の一人であり、よく出回っているスクラムの図の作者であり、アトラクタに所属するアジャイルコーチだ。Ryuzee.comにはしばしばお世話になっている。

SCRUM BOOT CAMP THE BOOK

SCRUM BOOT CAMP THE BOOK

変則フィッシュボウル

お三方の発表後、登壇者の3人+3席にフィッシュボウル形式で入れ替わりながら座った方々によるセッションが行われた。こちらについては、発表資料もなく、イベントレポートでも記述が薄いので、手元のメモから一部を記載する。自分なりに理解しながら紙に落としたので間違っているところもあると思われることをご了承願いたい。

「守破離」というが、スクラムを「まず守らせる」については？

  • 「ちょっと忙しくなるとやめてしまおうとする誘惑にかられるから、何度でも同じことをいう」（ryuzee）
  • 「やりたいようにやらせてみて、うまくいかないのを笑う」（きょん）
  • 「外野がガーガー言ってくるときは黙らせる」（やっとむ）
  • （きょんさんの発言に対して）「プロジェクト、プロダクトの成功に対して金を貰っているかどうかによって言い方が変わる。貰っている場合は重大な失敗をしそうになっているのを見ているわけにはいかない。」（ryuzee）

アジャイル初心者はどうやって始めればいいか？

  • 「絶対に成功しないといけないプロジェクトで始めない。練習する。」（ryuzee）
  • 「XPの方が始めやすいのではないか。技術的な部分への言及がスクラムにはない。」（やっとむ）
  • 「信用してくれる経営陣を持つこと、それに報いる気概を持つチームになること。」（きょん）

形のある「アジャイル」の先に何があるのか？

  • 「アジャイルは終わらないジャーニー」（ryuzee）
  • 「Unlearnの仕方がまとまることが次のプラクティスではないか」（きょん）
    • ある仕事にしか対応できないチームになってしまった（早すぎた最適化）
    • 早すぎた最適化をUnlearnする必要がある
    • そのうえで今に最適なものをどう素早く構築するか
  • 「世の中の多くのチームは最適化にまで達していないのできょんさんの話は多くの人には関係ない」（ryuzee）
  • 大事なのはチームではなくビジネスではないのか？（司会の成迫さん）

5分でできるチームの賞味期限は30秒では？変化し続けることが大事？

  • 「構造を決定するのではなく過程であり続けることが大事」（きょん）
  • 「お金を稼げなければ意味がなく、そのためにはたくさん球を投げなければならないが、中の人は今のプロダクトで勝てるはずだと信じられないといけないのが難しい」（ryuzee）
    • チームビルディングを叫んでいる人は、当事者意識があるか？圧倒的当事者意識は？
    • SIerの場合は、アジャイルでやって何にコミットすればいいのかがよくわからないので難しいのではないか。
    • 当たり前のことができていない、規律の部分をかなり指導した。
  • 「なぜビジネスは大事か？」（やっとむ）
    • 赤福は変化ができている。ビジネスを意識するだけではできなかったことなのでは？
    • エコシステムを存続させることを意識した結果が変化できる会社のあり方なのでは

ちゃんとやれていない組織には鞭を入れる必要があるのか？

  • 「変えられない会社で頑張るより移ったり独立した方が幸せになれる」（やっとむ）
  • 「大きい会社でも味方がいれば可能性がある、ミドルレンジ以上の人のサポートが得られるか」（ryuzee）
  • 「案件単位で、偉い人が興味を持たないようなものでやればいい」（ryuzee）
  • 「間違ったスイングの方法で試み続けるよりは見学に行く、コーチを呼ぶ」（ryuzee）
  • 「現場がやらされ感をもっていてはダメ、チームを連れてカンファレンスに行ったりすればいい」（きょん）
  • 「教育を徹底的にやる、トップダウンの場合はそれができる」（やっとむ）

自動車産業でのアジャイル。高品質、大規模なプロダクションにどうやって結びつければいいのか？

  • 「機能以外のソースコードが多くなるはず、それをプロダクトバックログに入れるのかどうか。」（ryuzee）
  • 「デモやPoCのコードは捨てた方がいい」（ryuzee）
    • どの段階で使うためのものなのかによって品質のレベルが違うはず
    • 品質を後から上げるのは難しい、だから捨てた方がいい
  • 「コードを2回捨てて3回目を使う」（きょん）
    • Royceのモデル、ソフトウェアは三回作る
    • 捨てるレベルはどこか？実装、アーキテクチャ設計、基本設計？
    • 捨てるレベルをどこまでに留めるかがチームの力ではないか
  • 「プロトタイプをTDDで作っていって、プロダクトコードだけを捨てる」（やっとむ）
  • 「車も1週間スプリントで作ればいい」（やっとむ）
  • 「どっかの原野に人工の街を作って、『人を殺せる』環境を作って試験をしまくるのがいいのではないか」（ryuzee）

自動車の開発におけるテストはどうするか？

  • 「ソフトウェアの場合も、自動テスト（xUnit、Selenium）の技術が育つのには時間がかかった。車の場合でも、似たようなことが起きない限りは難しいのではないか？」（やっとむ）
  • 「網羅性を求める前に、プロダクションラインを絞った方がいいはず。部品化、標準化が必要？派生開発が多すぎるのではないか」（ryuzee）
    • CI／CDの場合は、リリースするのは一本で、顧客ごとの違いはフラグで管理
  • 「10年かかることが今できていないのは10年前に始めなかった自分が悪い」（やっとむさんに急に振られた川口さん）

なんでアジャイルコーチと偉い人しか前にいないんですか？

下記のようなツイートをしていた及部（@TAKAKING22）さんが最後の質問者として問いかけた。

  • 「僕は現場代表です」（きょん）
  • （聴衆の方を見て）「みなさん、アジャイルを現場に取り戻しましょう！」（及部）

感想

先に公開しているこちらの記事を読んでいただきたい。

ky-yk-d.hatenablog.com

*1:ファシリテーションのセミナーなどを主催されている方で、先日僕もワークショップに参加させていただいた。【2018年8月】ガオ流ファシリテーション基礎講座 - connpass