イベント概要

  • 先日、アジャイルの本質について語るイベントが日本橋で開催された

    • イベントのテーマは「本質を理解しないままのアジャイル開発に挑む危うさ」
    • アジャイル3怪獣 と呼び声の高い (?!) お三方がアジャイル開発の本質を激辛トークで深掘り
    • 会の後半では、参加者を交えたディスカッション（フィッシュボール形式）も行われた
    • イベント詳細はこちら：https://connpass.com/event/96750/

  • 登壇者

    • やっとむさん「アジャイルってなにが美味しいの？」
    • きょんさん「目的論からのアジャイル～手段を目的化すること～」
    • ryuzeeさん「アジャイル開発でコールド負けしないための5つのポイント」

  • 感想を一言で言うと

    • タイトル通り、内容が本質すぎて辛かった
      • 終始「ぐぬぬ…」となる胸熱展開のオンパレードでした

「アジャイルってなにが美味しいの？」 by やっとむさん

登壇資料

そもそもアジャイルとは

  • そもそもの話をする　ex.) なぜ砂糖をたべて甘いと感じるのかというレベルの話
  • アジャイルとは何か：「しゃべって、リリースして、変更する」
  • なんのためにコード書いてるのか
    • 欲しいもののためにかいている
    • 欲しいもの＝価値

価値は時間累積

  • 欲しいものを「価値×コスト」軸で比較した時、価値が大きく早くできるものから着手する
    • 内製開発の場合、コストと時間はほぼ比例する　
  • 価値は時間累積
    • リリース後、価値は時間累積として積み上がる
    • 価値が大きく早くできるものからリリースすることで価値の積み上げ面積をできるだけ大きくしたい
  • 価値とは欲しいもの
    • ユーザーが利用することで享受する価値
    • お金に直結するもの ex.) 広告収入、月々のライセンス料
    • 情報、リスク対策（将来の価値毀損するリスクに関する情報を得られる）
    • 生産性

PBIは仮説でしかない

  • PBIは本当に価値があるものなのか
    • PBLは妄想、PBIは仮説でしかない
    • 検証可能な価値の単位でリリースしないと有効なFB得られないよ　by nagaseさん
  • より正しいものがつくれるように学習していかないといけない
  • まとめると
    • 早いほうがいい
    • 細かいほうがいい
    • 数手先まで考えたほうがいい
    • 常に学ばないといけない

learnとunlearn

  • learnの定義
    • 勉強と訓練　→　知識やスキル
    • 発見すること
    • 態度の変化　→　行動の変化
  • unlearnとは
    • 今やっていることは捨てて、さらに学ぶこと
  • 簡単なわけない、めちゃくちゃ難しいこと

高速に学習していくためのコミュニケーション

  • 情報帯域
    • 「ホワイトボードに向かった2人」がいちばんコミュニケーション効率いいという研究結果
    • コミュニケーションパスが多いと情報が劣化する　＝　学習効率の低下
    • できるだけ少人数で・・簡単なわけない

品質はだれかにとっての価値である

  • 品質と一口にいっても、さまざまな要素を考慮しなければいけない
    • いま品質が良い悪いという話
    • 将来の品質がどうだという話
    • 技術的負債がどうだという話
  • 「必要な考慮がされた状態を維持しないといけない」というのがいちばんしんどい
    • 変更容易性はどんどん失われていくが、そこを維持しなければならない
  • 「品質はだれかにとっての価値である」by ワインバーグ

ソフトウェアってのは簡単に作れないけれども

  • こんな難しいことを実現する仕組みを作るのは困難
    • こんな難しいことを実現する人は作れるかもしれない
  • モチベーション3.0の3原則
    • 自律
    • 熟達
    • 目的
  • モチベーションを上げるには
    • 好きなことに集中し
    • より上手になり
    • できることも広がり
    • その上で大きな目標を目指す
  • TOYOTA WAY
  • 赤福のビジョン
    • 続けることが進化する業（なりわい）であり、進化することが続ける業である」

価値、コミュニケーション、技術、人

「目的論からのアジャイル～手段を目的化すること～」 by きょんさん

「目的と手段」論

  • 目的と手段は対義語じゃないってこと、みなさんご存知？

    • 手段は目的の従属語である
    • つまり、手段は目的によって正当化される

  • Question：アジャイル、プラクティスが目的化している事例知っていますか？

    • 会場にて出た意見
      • 「スクラムはこうだから◯◯しないと」といった、原理原則に囚われている人
      • とにかく開発やばいんで、アジャイルやります（安い・早い・うまい的な）
      • 目的化していいじゃんｗ 何が悪いの？

仏教に置き換えて考えてみる

  • 仏教における目的と手段
    • 目的：悟り
    • 手段：修行、念仏
  • 「悟りを得ることが目的だから、修行に執着しなくていいよ」　→なにをいってるんだ？！
  • 修行を目的化し、自身と念仏が一体化する
    • そこまでやらないとたどり着けないのが “悟り”

目的化と形骸化を混同するな

  • きょんさんのチームの目的
    • ソフトウェア工学の歴史に名を残す
    • 世界最高の開発チームになりたい
  • スクラムを目的に仕事するくらいでちょうどいいという想いでやっている
  • 目的化と形骸化は異なる
    • 形骸化のことを目的化する〜と簡単に言わないでほしい・・

アジャイルには理想はかいていない、20年前をベースとした現実解

  • チームビルディングに関してよく言われること
    • 良いチームはなかなかできない、解散しないほうがいい
    • 同じ場所同じ時間で仕事をしたほうがいい
    • スクラムチームは専任のほうが良い
  • 目を覚ませ!! 、理想は世界最高のチームを数分でビルドできること
    • 分散オブジェクトシステムとして協調し、時間や場所を超えてはたらける
  • アジャイルには理想なんて書いていなくて、現実解しかない。しかもそれのベースが20年前 1
    • アジャイルは老害です

「アジャイル開発でコールド負けしないための5つのポイント」 by ryuzeeさん

登壇資料

こんばんは、老害です

  • アジャイルコーチをしていて、今まですべてのチームに必ず伝えてきたことを今日話す
  • 野村監督の言葉　
    • 勝ちに不思議の勝ちあり、負けに不思議の負け無し
  • アジャイル開発、ソフトウェア開発で失敗する理由はたくさんある
    • 失敗する箇所を潰したからといって勝てるとは限らない
    • 速攻で負けないようにする上で、最低限注意する項目を5つ紹介する
  • とりあえず勝てるかどうかはわからない、やってみなきゃわかんない
    • 10個だして、1個あたればボロ儲け
  • 主にスクラムの文脈で話す

コールド負けしないための5つのポイント

  • 十分条件で開始する
  • Readyなプロダクトバックログ項目だけ着手する
  • 同時の仕掛りを少なくする
  • フィードバックサイクルを回し続ける
  • 技術に投資し続ける

十分条件で開始する

  • アジャイル開発は無理難題をなんとかするためのものではない
    • 変化に対応して複雑な問題を解くため
  • プロダクトのゴールやビジョン、必要な体制やファシリティ、ツールセットや技術スキルなどが必要
  • アジャイルじゃなくても、プロジェクトの立ち上げは大変
    • 開始前にやるべきことは取捨選択して、ちゃんと準備しよう
    • 足元固めてからはじめようというだけ
  • 兼任は避ける
    • マルチプロジェクト、マルチロール等、兼任は不十分の典型
    • シングルプロジェクトできるようになってから試せ
    • 「4番ピッチャー」はやっぱり辛い
    • 現在集中すべきこと以外の影響によって
      • リードタイムが不安定化する
      • ボトルネックによって待ち時間が増える
      • つまり成果が変動し、予測性が低くなる（POがやきもきすることになる）

Readyなプロダクトバックログ項目だけ着手する

  • 生煮えのプロダクトバックログ項目をたべるとお腹壊す
    • 着手してから確認と検討を繰り返し、見積もりが外れ、成果が出ない
    • 次から準備するようになる見込みがあるならば、一回お腹壊してもいいかもしれない
  • スクラムやアジャイルは準備不足を許容しているわけではない
    • 今やるべきこと、後でやるかもしれないことを識別する
    • 今やるからには着手時点では自信を持って進められるように準備すること
  • Readyにするためにプロダクトバックログリファインメントを活用する
    • POと開発チームの継続的な対話が必要

同時の仕掛りを少なくする　

  • 稼働率はくそです
  • リトルの法則
    • あるステップの所要時間　＝ 仕掛り作業の数 / 処理能力
  • 仕掛かる数を減らせば早くおわるという話
    • スプリントは短いので、待ち時間多いとすぐ死にます
    • 現場では、1週間スプリントでやれってよくいう
      • 予測精度がたかくなり、安定してパフォーマンスだせる＝成果がでる
  • 仕掛りの障害はあまりにも多すぎる
    • コンテキストスイッチの増大
    • 遅れると仕事が増える（報告してよ！
    • リスク増える
    • オーバーヘッドがふえる
    • 品質下がる
    • モチベーション下がる
  • リソース効率よりプロダクトの効果
    • バックログの完成にフォーカスすること！
  • デンソーさんの実例
    • PBIは1個流しか2個ながし
    • スプリント初日からPOチェック依頼
    • かんばんはホワイトボードで可視化のために複数のマグネットを活用している
      • PO宿題（POチェック依頼しているPBIに貼る）
      • 今日のゴールポインタ（PBI並べてる列に貼る）
      • NOTREADY,READY（PBIに貼る）
      • PO OK（POチェックが完了したものに貼る）
      • POに確認依頼だした日付、POOKの日付を書いておいて、POの忙しさを可視化している

フィードバックサイクルを回し続ける

  • スプリントレビュー
    • ステークホルダーからプロダクトへのFBもらう
  • スプリントレトロスペクティブ
    • プロセスに対するFBをだしあう
  • 大きな痛みを取り除く（＝本当の痛みを取り除く仕掛けをつくる）
    • 今一番つらいのはなにか
    • たくさん改善するのではなく、本当に効果のあるものにフォーカスする
      • ちっさい改善してもあまり意味ない
  • 「〇〇に気をつける」「〇〇に注意する」「〇〇を疑う」を疑え

技術に投資する

  • いくらプロセスがうまくいっても、技術力がないと要求を実現できない
  • プロセスの話ばかりに逃げ込まない
  • 必要な技術スキルを身につける
  • 勝率をあげるように勝ちパターンナレッジをためること
  • 必要なスキルを明らかにして、早期から継続学習する
  • 学習の仕掛けをつくる
    • 新メンバー受け入れプロジェクト
    • コードレビュー
    • ペア作業、モブプロ
  • 学習しようと思ったら、リソース効率を追求しすぎてはいけない
    • デンソーさんでも3割位はバッファ積んで計画している
    • それでも相当無駄な作業は削っている

コールド負けしないための5つのポイント（再掲）

  • 十分条件で開始する
  • Readyなプロダクトバックログ項目だけ着手する
  • 同時の仕掛りを少なくする
  • フィードバックサイクルを回し続ける

  • 技術に投資し続ける

  • この5つをやっておけば、開発チームのせいでぽしゃったとは言われないのでは？

参加者も交えたディスカッション

Q. アジャイルをはじめるときのポイントは？

  • ryuzeeさん
    • 十分条件から始める、環境整えること。
    • 最初から大きいリスク抱えた状態ではやらない（不退転のプロジェクトではやらない）
  • きょんさん
    • 自分のチームはなんちゃってでアジャイル始めたが、成果でた。
    • 信じてくれる経営陣をもつこと
  • やっとむさん
    • XPのほうがとっつきやすい（スクラムはやるべきこと多い）
    • スクラムは技術的なこと定義されてないので自分で考えなきゃいけない
    • アジャイルサムライはXPの本

Q. XPやスクラムなどアジャイルの先にあるものは？

  • ryuzeeさん
    • 毎回客先でこうすればよかったと反省する、世界最高の仕事したなと思ったことない
    • アジャイルは終わらないジャーニー
    • 今後も新しいテクノロジーが出てきたら調べたり、プラクティスでたら適用できるかどうか検討する
      • それをアジャイルじゃないとは思わない
  • きょんさん
    • CEDECでも話したが、次はUnlearnのプラクティスではないかと思う
    • 自分のチームは最適化しすぎた結果、成長が指数関数的から数直線的になってしまった
      • 早すぎる最適化をunleanする必要ある
    • いかに今までやったことすべて忘れ去って、今！必要なものを爆速で構築できるか？
    • learnのプラクティスとunlearnのプラクティスがセットになったものが次かな
    • （ryuzeeさんからの補足) そんな領域にたどり着いてる人は99%いない。
      • これ真似しちゃいけない。火傷しちゃう。念のためにいうけどもｗ
  • やっとむさん
    • アジャイルとは進化すること、行き先は無数にある
    • アジャイル的な動き方がよりできるようになったらできることはたくさんあるのでは
    • ティール組織など

Q. ビジネスとチーム運営のバランスについて

  • きょんさん
    • 地図のように完成はない、常に変化しつづけるもの
    • 前進するためには、常に取り入れ続ける自分たちがいればいい
      • 常に情報をいれつづける、出し続けるという “過程” で有り続けることが大事
  • ryuzeeさん
    • チームの話いくらしても、お金稼げなかったらいみない
    • 中の人が勝てると信じられないチームが勝てるわけがない
    • チームビルディングという言葉はきらい
      • 本来は開発チームからあれやりたいこれはどうかという話がでないといけない
    • 成果がでてないのに、チーム仲いいとかくそだね
    • Sierがアジャイルやって一番ぶつかるのはここ
      • どこにコミットメントもつのかは、SIだと悩ましいところ
    • Q. デンソーさんにムチ入れたことはある？
      • いっぱいありすぎて覚えてない
      • バックログだめだよねで怒ったりしたことはない
      • プリミティブ、規律の部分で指摘したことは多い
        • 机の上汚い、部屋汚い、5Sを掲げているならまっとうしようよ等
        • 先週も先々週もいったのになんできたないの？関心ないの？なんで？
        • 時間になったらはじめるよね？整理整頓できてないよね？
      • 事前準備ができてない時点でだめ
        • スプリントレビュー開始時にWindowsUpdateがはじまったときは激おこぷんぷんまるだった
  • やっとむさん
    • ビジネスの観点が大事
    • 赤福　あんころもちで３００年
      • 営業停止後、品質管理の変化
      • ビジネスをうまく行かせるという観点でそれができたのか？
      • お金をもうけるのも大事だけど、自分たち、自分たちをとりまくコミュニティを維持させることを考えたのでは
    • ビジネスがまわることを考えた上で、その上で、自分たちが何を実現したいのかを大切にすることが重要

Q. アジャイルな組織にしたい時、一からスクラップアンドビルドしないといけないのか？それとも、現状に少しずつ上乗せするやりかたでもいいのか？

  • ryuzeeさん
    • デンソーさんは、従来型プロセスでやっていたが、偉い人説き伏せて好き勝手やれる環境つくった
      • 協力者がいっぱいいれば可能性はある
    • 現場の末端からボトムアップで新しいことにやろう・変えようというのはなかなか厳しい
    • 「うまくいっているとはどういうことか」という感覚がないと、うまくいかない
      • デンソーさん、ヴァルさんの見学いってみる等、そういった雰囲気を知るのは大事
      • リアルはどうなの？を先に知ったほうがいい
  • きょんさん
    • トップダウンからの支援があったとしても、現場のチームにやらされ感があったらうまくいかない
    • そういうときどううまくやるかという話は重要
      • きょんさんは、チーム全員つれて、スクラムのカンファレンスや見学にいった
      • そういう場にいって色んな話をきくと、やる意味が見いだせるようになる
  • やっとむさん
    • 今を改善するよりも、うまくいってるところに転職したほうがてっとりばやく幸せになれるかも？
    • トップダウンの支援がある前提では、教育を徹底的に行うというのも有効

Q. 「組み込みでアジャイル」、「品質」について

  • ryuzeeさん
    • 組み込み系は安全を二重三重につっこむ
      • 見た目でわかる価値以外の安全価値にコストつっこまないといけない
    • プロトタイプや要素技術検証のコードをそのままプロドにもっていくと失敗することが多い
      • 検証したあとに、もっかいイチからつくるほうがよい
      • システムやプロダクトは、固有の品質要件がある
        • demo用プロダクトの品質
        • 人が死ぬプロダクトの品質　で要求される品質はちがう
      • 品質の差分をうめる取り組みが必要
      • あとから品質上げるのは結構大変なので、一回捨てたほうがはやい
  • きょんさん
    • 受託案件の際、1回つくって、全部すてて、もっかい作り直して・・ってやったことある
    • ロイズは「3回作り直す」を提唱している
    • どっから作り直すのかという話もある
      • 実装から捨てるのか、詳細設計から捨てるのか、アーキテクチャから捨てるのか？
      • 手戻りすべきポイントをどこまで下流におとせるか？がポイント
    • いろんなものに対応できる詳細度合いをどこにみつけることができるのか？
      • これを下流に落とせるチームは設計がうまいチーム
  • やっとむさん
    • プロトタイプのコードははりぼてでいい。品質あげてもいみない
    • テスト駆動開発というアプローチが好き
    • TDDしながらプロダクトコードすすめる
    • テストコードがあると、「動くけどそれほど良くない」という場合にコード捨てやすくなる

Q. ミッションクリティカルな組み込み製品では、「もしも〇〇が起きたら」という問題に備えるためにかなり時間を使うが、そういう特性をもった開発にアジャイルのコンセプトをどう適用していくとよいか？

  • やっとむさん
    • ソフトウェアでは、長い長い時間をかけて、テスト自動化するという話が発展してきた
    • ソフトウェアですら、こういった発展に結構時間がかかってる
    • ハードはもっと時間かかると思うけど自動化することにチャレンジしたほうがいい
    • テストつくるのは大変なので、時間はかかるが、自動化することで変更のコストを下げることができる

  • きょんさん

    • 最終的にこれがアウトプットですって決まってる仕事に対して、最初に投資しないのは馬鹿
    • 今不確定なものがあっても、これはこういうことだよねっていうのは少しずつ決めないといけない
      • そこから目を背け続けたらいつまでたってもできない
    • 今必要だったら今やるべき、あとになればなるほど複雑化する

  • 成迫さん

    • 機能要件よりも非機能要件のがpotionが大きいから機能要件のTDDだけじゃおいつかないという話では？

  • ryuzeeさん

    • 変革の奇跡という本を出した　HPプリンタ複合機についての話。
    • 網羅性を上げる前にプロダクトライン絞ったほうがいいのでは
    • 「ちょっとずつ違うからもとのやつもってきてコピー」というやり方は最悪
    • 標準化や共通化したほうが保守も楽
      • 部品化して、単体でブラックボックス化するとテストも楽
    • 10年たってできていないことは、10年前にはじめなかった自分のせい　by川口さん

LastQ. なんでアジャイルの話をしているのに、前に偉い人しかいないのか？

  • TAKAKING22さん

    • 前に出ている人の中で、現場メンバーとしてアジャイルやってる人がきょんさんしかいない
    • 「みなさん、アジャイルを現場にとりもどそーぜ！以上です！」

  • 成迫さん

    • かなり楽しかったと思うのだけど、みなさんはどうですか？楽しかったよね。（拍手）
    • ぜひ、またやりましょう。次は現場のメンバーも集めて。
  1. 御本人からTwitterでご指摘をいただき、一部訂正。きょんさん、ありがとうございます！ [return]