2016/1/19 Regional SCRUM GATHERING® Tokyo 2016 に参加しました（二日目）

1/18,19の二日間にわたって開催された Regional SCRUM GATHERING® Tokyo 2016に参加してきました。
一日目に降った雪は残っているものの、2日目はとくに遅延もなく会場に着けました。

togetter はこちら

Economically Sensible Scrum

エッセンシャルスクラム氏によるKeyNote

経済合理的性 を何度も強調していました。
Scrumのベストプラクティスや、こうすべきという話はもちろん根拠があって参考にすべきだが、
結局儲かってなんぼなので、そういう観点であえてベストプラクティスに沿わない選択をするケースもある。

大事なのは 経済合理的性 ということでした。

例えば、一日目のキーノートではフィーチャーチームがいいよという話だったそうですが、
経済的合理性がコンポーネントチームにあれば、コンポーネントチームと言う選択肢も取るべきだろうといったことも言及されていました。

確かに、儲からないことにはどんなに理想的なプラクティス、プロセス出会っても事業が継続できないですよねぇ。

「Scrumに従う必要はあるがそれだけでは十分ではない、経済合理性のあるScrumをする必要がある」

レゴスクラムの覚醒 / The Lego Scrum Awakens

スライド

XP祭り2015の基調講演や、XPの第二版を始め様々な良書の翻訳もされている角さんによるセッション。
度々有償でセミナーが開催されているレゴスクラムは
「全体性」があり「経験学習モデル」で効果的に学習でき「開発者以外も参加」できる。
この点からスクラムの学習に最適という解説でした。

レゴスクラム

レゴスクラムのマニュアルは翻訳されているのでぜひやってみてくださいとのことでした。

印象に残ったのは「みうらじゅん＆タモリ理論」からのワークショップ疲れ→もはや「ゲームしかない！」の流れです。

セッションを聞いて思ったのは、初期投資は必要な物の、紙飛行機ワークショップの代わりにでもぜひやってみたいと感じ米sた。

フィリピンのスタートアップにスクラムを導入しようとしてみたお話

アジア圏に可能性を感じた！と言っていたと思っていたらほんとにそっちの会社に転職して、来月からダナンに行くという藤村さんのセッション。

内容はスライドを見ていただくとして。

非常にアツく面白いセッションでした。

金融系ＩＴ企業におけるスクラムへの挑戦

ニッセイ情報テクノロジー株式会社の社内でのScrum導入のお話。

publickeyで記事になってました前編後編

チームがScrumを導入するときに組織としてのサポートは重要
  • 今までのウォータフォールベースの社内標準プロセスから逸脱する許可を得た
  • 看板などの掲示物はセキュリティ的に問題ないと説得した
立ち上がりをスムーズにする試み
  • アジャイルコーチをおねがいした
周りからみて楽しく見えるような工夫をした
  • スプリントごとにスローガンを決めた
  • プロジェクト公式キャラクターを作った
  • お菓子神社をつくった
報告に工夫をした
  • WBSなどの旧来の報告方式から
  • プロダクトバーンアップチャート
  • スプリントバーンダウンチャート
やってみて
  • 価値のあるものに注力
  • フィードバック
  • テストツールが充実した
  • 自主的な行動
  • コミュニケーションの活性化
  • モチベーションUP
  • 自分たちでやってる感

People As the Conveyer of Knowledge (知識は人が運ぶ)

平鍋さんによるおはなし。

当日のスライドの日本語版のスライド

  • スクラムは海外発祥と思っているかもしれませんが、その源流は日本人が発表した論文
  • SECIモデルを利用してのプロダクト開発には暗黙知の共有が重要である。
  • それ故プロダクト開発は（角さんのセッションでもあった）「経験学習モデル」と学びが重要。
    • 松下電器がホームベーカリーを開発した時はエンジニアが一番好きなパンを作っている職人に弟子入りした
      • 知識は暗黙知が多く、ドキュメントだけでは伝えられない
      • ソフトウェアは共感で繋いでいく
  • 究極のプロダクトオーナーは何を作るのかを共感

野中先生はヨーダ

  • とあるセミナーでの質問「ステークホルダーが多くて調整が大変です、どうすればいいでしょう」

    • 合宿をしなさい

  • 合宿をすると一日目で形式知ができる

    • 食事して、メンバーのバックグラウンドがわかり
    • なぜここにいるのかというはなしになり
    • そこからプロダクト開発の話が始まる

以下メモ。

RSGT2016 Day 2 Scrum alliance talk

Forbs 100 -> 今は一社しか残っていない→変化に適用できていない→変化に適用することが必要

Economically Sensible Scrum

大きな組織ではチームレベルではScrumがうまく行っているが、収益ができてない
→経済的合理性がないから
→阻害要因
経済合理性のあるスクラムをやってほしい

Scrumの概要説明

→ Scrumは成功に必要だが、十分ではない

Scrumに違反しない＝Scrumで成功 とはいえない

4つの阻害要因

  • アジャイル原則に沿ってない
  • アジャイルの原則を社内に適用できていない

  • 経済合理性が考慮されていない？

  • 経済合理性の中でアジャイル原則を適当できていない

→ スクラムとその原則を理解する必要がある

経済合理性のあるScrum

ライフサイクルプロフィット
→違った変数で表現されるプロダクトの価値を比べる時の尺度？

遅延

変更コスト

JITの誤解

ScrumなのでJITでやるます→見通しは立てません は間違い→バランスが必要
→見通ししすぎ→推測しすぎ沼
→すべてをJITで→Sprint1に入ってストーリー作るの？
→事前作業は必要なやる、だがやり過ぎない

WIPの問題

ソフトウェアの在庫
→見えないから、ないと言われがち
→在庫を見える化すればいい

ソフトウェア開発の最もかかるコスト
→人件費
→テスターが60%しか稼働していなかったらそれは無駄ですね
→Projectを掛け持ちして稼働率を100%にする→ムダがなくなりました→これはだめだよね。

リレーのメタファ
→リレー選手の稼働率は25%
→残りの75%はどうする？
→すきま時間に別の競技に出る
→そうではない
→リレーの目的からすれば稼働率100%ではなくて、25%でバトンを誰よりも早く繋げば最も価値がある。
→稼働率100%はプロダクトの価値を高めない、収益性は上がらない。
→バトンがつながらない時のロス

[参考]バリューストリームマップ

Idle Workに注目しない！

キューイングすることの無駄
→Fast flexible flow

計画

バリューチェーン

Portfolio Planning

  • 遅い車（トラクター）
    →ボトルネックになる→遅延コストがかかる

  • アジャイルの原則をポートフォリオレベルでは使わない

パートナー

→アジャイル開発の契約書を作るべき

変化への抵抗

→ 変わることに対して抵抗勢力がある

全体が見えていない

→ システムレベルでの最適化をすべき

組織構造を経済合理性のある形にあってない

マルチタスク

  • 稼働率を上げるためにマルチプロジェクトとか
    → ダメです

  • マルチタスクは能率を下げる

    • 1prj = 70% の付加価値を提供できる
    • 5prj = 30% の付加価値しか提供できない
      →マルチタスクは経済合理性がない

    2pararellだとちょっと効率が上がる
    → 1プロジェクト目がブロックされたら2つ目に逃げられるから？

T字スキル

  • BROAD + DEEP

長生きチーム

  • プロダクトごとにチームを作るのは経済的に良くない
    →チームを解散すべきではない

  • 消防士
    →チームを解散させると効率が下がる

→ チームの経済効率性を考える

チームの分け方

  • コンポーネントチーム
    → GUI・Serversideなどで分割されている

  • フィーチャーチーム
    →クロスファンクショナル
    →クロスコンポーネント

コンポーネントチームに取ってフィーチャーなものが、フィーチャーチームにはタスクである

アジャイル界隈ではコンポーネントチームは良くない、フィーチャーチームがおすすめと言われている

コンポーネントチームで複数のフィーチャーを実装しようとすると、バトンが下に落ちた状態になる。
→チーム間のコンセンサスが取れない？？

  • この辺よくわからん？？？

経済性にしたがってスケールしましょう

まとめ

  • Scrumに従う必要はあるがそれだけでは十分ではない、経済合理性のあるScrumをする必要がある

質問

  • コンポーネントチームのPO ＝ テックリード
    → テックリードはビジネスをあまり考えない
    → コンポーネントチームをなくす時も経済的な合理性があるならよい

    • 消防署は東京で一個とかはありえないですよね
      → そういった場合は各区に消防署はあるべき

フィーチャーチーム、コンポーネントチームにするにせよ、マルチタスクと考えるとT型スキルにはならないのでは？

→チームにはT型にはなってほしい
→クロスファンクショナル

→マルチタスキングは完全には解決できない
→フィーチャーチームとコンポーネントチーム同時に所属するのは正しいが、マルチタスキングしちゃいけないという意味では正しくない

レゴスクラムの覚醒 / The Lego Scrum Awakens

http://www.slideshare.net/kdmsnr/legoscrumawakens20160119

レゴスクラム

→翻訳してるのでやってみてね。

OpenStack

→OpenSourceのモデルをレゴで表現してみよう
→フリーのコントリビューターがいるのがほかと違う

アジャイル開発の体験に最適

レゴスクラムの3つの特徴

経験による学習ができる

スクラムガイドと実践の間を埋めるためのレゴスクラム

経験と教育
→教育とは日常に溶け込んで行くべきだ

経験学習モデル
→まず経験する

みうらじゅん＆タモリ理論

ワークショップ疲れ→もはや「ゲームしかない！」の流れ

全体性が備わっている

ホールネス
→ぶぶんぶぶんで違っていても全体として合っていればOK
→見積もりとか、部分のトレーニングは意味がないのではないか？

デイリースクラムが時間の関係でない、後で研修する。
時間が短い1スプリント7分
→それ以外はスクラムそのもの

開発者以外でも参加できる

スクラムチーム以外、関係者、ユーザーすらも！

フィリピンのスタートアップにスクラムを導入しようとしてみたお話

経験

→食いっぱぐれない！！！！！
→金を払ってでも得たい経験！！！

0週目

  • 明確ではないけどなんか良くないよねという状態

  • 勉強はしてくれなかった！！

1週目

  • KPT2

  • 日本とフィリピント特に変わらないKPT

2週目

だんだん暇になる→隙間タスクをやっていた！

金融系ＩＴ企業におけるスクラムへの挑戦

WFとスクラムを足した感じ
→要件定義＋基本設計 WF
→予算承認
→開発以降はスクラム

アジャイル→生産性が高いという噂
→途中からメンバーを追加した 開発T6人 PO2人中野さんが忙しいのでサポートとして一人入れた

導入は1Day研修を受けた

社内の標準開発工程を適応しない申請をした！

看板も掲示したままでOKとした。

アジャイルコーチをお願いした→豆蔵山田さん

デイリースクラム

→今日やることは最後にみんなで決める
→報告チックになっていたので、ファシリテートは持ち回りにした

KPT

Tryの確認をスプリント中間で行う

コミュニケーションの活性化

→周りから見て楽しそうに見えるように

  • スローガンをスプリントごとに決める
    → POが20分以内に今スプリントでやることを踏まえて決める

  • キャラクターの作成

  • お菓子神社

  • HELPカード

課題

進捗と品質の報告

  • WF
    • 計画通りか
  • Agile
    • 実績を計測して
    • 収束予測する

進捗の報告方法

  • プロジェクト
    →プロダクトバーンアップ

  • スプリント
    →バーンダウンチャート

品質の報告

  • ツールを導入して計測した

成功の要因

カイゼンの繰り返し

  • ルールをシンプルにする
  • 効果的でないならやめる

チームを取り巻く環境

  • 外部からの阻害が少なかった
    →初アジャイルなので、暖かく見守ってもらえた
  • メンバー
    →自己組織化できてた
    →リードするキャラがいた
  • アジャイルコーチを活用した
    →立ち上げがスムーズに
    →ちょっとしたことが相談できる

プロダクトへの効果

  • 価値のあるものに注力
  • フィードバック
  • テストツールが充実した

意識

  • 自主的な行動
  • コミュニケーションの活性化
  • モチベーションUP
  • たのしいかいはつ
    →自分たちでやってる感

今後の展望

社内への展開

社内開発支援組織を設置

複数チーム体制での開発

顧客も含めた開発への適用

People As the Conveyer of Knowledge (知識は人が運ぶ)

Slide日本語版あるよ→SlideShare
http://www.slideshare.net/hiranabe/nonakas-scrum-phronetic-leadership-and-requirements-development

アジャイル開発のコンセプトは日本が寄与している

海外プレゼン時にはその地で流行っているアニメを入れるとつかめる

The new new product development game が Scrumにあたえた影響

  • Scrumの黒い本
    → 扉の次のページに引用

  • リレーレースのモデルからラグビーのモデルへ

  • New New

    • 新しい
    • New Product
    • 新しい新製品開発

  • Scrumを編み出すときに100くらいの論文からこれだと選ばれた

  • TypeC Scrum の語源もこれ

  • プロダクト開発と同じく、関係者を巻き込んで行く進め方

  • 野中先生
    → Yoda

  • アメリカ海兵隊
    → クロスファンクショナル

  • Wise Leadership
    →Phtonetic Leadership

  • TypeC Scrum
    → 最初は刺し身にしようとした→ボツ

SECI-Model

暗黙知

  • more then you can tell
  • やってみるほうが早いこと、一緒にやって覚えること
    →自転車の乗り方とか
  • 同じ体験をすることによって伝わる
    →言葉がなくてもつたわる
  • ミラーニューロン
    →暗黙知暗黙知伝達

形式知

  • パターン、マニュアルなど

  • 知がポータブルになった

  • Sticky information
    →暗黙知にちかい

SECI Model

  • T-T

  • T-E

  • E-E

    • 組み合わせ特許

  • E-T

Story

  • 知識創造企業

松下電器がホームベーカリーを作った時のはなし

野中先生

  • 新製品開発の最初は暗黙知にある
    →想いからはじまる

  • PDCA → イクナイ → Planする前にみんなで何かをしよう→暗黙知の交換

  • パン焼き職人に弟子入り
    → 最終的には開発チーム
    → 実験＋実装＋暗黙知暗黙知変換
    → パン焼き器できた
    パン焼き職人の暗黙知からリブを作るという形式知になった
    → SECIモデル
    → 新製品開発においてT-E変換がいかに大事か

Design Thinking

→最初に「共感」がある！

  • Role Playing
    →実際のユーザーの共感をトリガーに

  • Bodystorming
    → 体で感じろ

T-T

  • pair programming

知識はどこからきてどこへ行くのか

  • 知識は暗黙知が多い

  • ソフトウェア開発は共感で繋いでいく
    →形式知、ドキュメントだけでは伝えられない

  • Honda
    → 作ろうと思っているもののユーザー視点になる
    → 共感して、もちかえる

究極のPOは何を作るかを共感

Scrum
→ 知識の運びては人であると宣言したもの

ステークホルダーが多くて調整が大変だ
→ 合宿をしなさい

→一日目で形式知ができる
→食事して、メンバーのバックグラウンドがわかり
→なぜここにいるのかというはなしになり
→そこからプロダクト開発の話が始まる