2015年4月中四国Ｐ２Ｍセミナー
アジャイルテスティング
アジャイル -> 小さいチームではうまくいく <- 世の中で認知されつつある。
分散 利点と欠点
コミュニケーションコスト
ダイバーシティー：習慣の違い、言語の違い、相互作用／対話
チャレンジ -> 理由を確認する。人によっては問い詰められてると思うこともある。
テスティングに特定した課題
- 依存関係が大きすぎる
- アウトソース
- 独立したテストチーム
- インテグレーションのテスト
解決方法
- 全員にオープン <- みんながアクセスできるようにする。
- 意思決定
- 計画づくり会議
- 議事録
- 均等な機会
- 全員ヘッドセットで参加（例）：オブザーバー
ツール：使い分け
- Email
- ブロードキャスト
- 会話後のフォロー
- 電話
- メッセンジャー
- 顔を見ながらの対話 <- お互いを理解するきっかけになる。訪問しなくてもできる方法
- バーシャル テレプレゼンス
マインドマップを利用して強調
Google Docs を利用したリアルタイムでのやり取り
ストーリーマッピングツール
ファーストチーム作り <- ゲームを用いること
学ぶことに楽しさを持ってくる。
テストでチームのコミュニケーションを手助けする。問いからテストが始めることもある。
Done の定義 <- 何を持ってOKとするかの共通理解を設ける。
早いフィードバック フィードバックサイクルを短くする。
Feature teams 機能をベースとしたチームを作る。コンポーネントでチームをわけるより依存関係が減る
学ぶ組織を作る
デジタル革命には アジャイルがよく似合う
重要な言葉「インサイト」
ビジネスデジタル革命
フィルム -> デジカメ -> 別分野で活躍
３Dプリンタ -> 何が起きるのか
最後まで残る仕事 -> 料理人かもっとのこと
7つ
SO Social, LO Location, MO Mobile,
CP Contactless Payment
CL Cloud, SE Sensor, BI Big Data
サッカーを科学する
ドイツ -> 靴にセンサーをつけて情報収集。科学する。
Sales デジタル化
訪問先をすべてデジタル化する。セールスマンの行動をすべて見える化する。
販売活動に対して、足りない点を科学で指摘できるようにする。
警察のビジネスモデル。戦争のビジネスモデル。すべて変化が起きている。
デジタルビジネスの特徴。常にイノベーションを実施する。
新しい価値づくり。お客様がその製品に対して Wow と言ってくれるものを作る。
４つの視点 <- アジャイル ビジネスを作ることも同じ
- Customer Centric お客様から見る。言葉だけでは実現できない。実現するためのメソッドが「Design Thinking」
４日間のワークショップでマインドを変える。シンガポールでは小学校４年生から Design Thinking を実施している。CEFL - Collboration
- Dialog 議論するのではなく対話する。
- プロトタイプ
- 考える人／作る人をわけない。一体化で実施する。
- Visible 見えるようになれば工夫できる。ソフトウェアは見えないから改善が難しい。
- 要件定義書なんて書いても意味がない。模型とか本当に目で見えるもの
- Iterative 改善。実際にお客様に見せてフィードバックを受ける。
ウォーターフォールで議論してビジネスを作って、この世の中に勝てるのか？
アジャイルかウォーターフォールかで議論している場合ではない。
アジャイルでないと勝てない。
Constant beta フィードバックと毎日の改善
会社としてのカルチャー 文化を変える。
アジャイルチームを作りゆっくりシフトする。
アジャイルチームが失敗を繰り返して勉強をしていく。
CEFL -> 経営者に対しての啓蒙を実施する。
エンジニア ビジネスを提案して、ビジネスの議論ができるようにならないといけない。
テクノロジーを理解したエンジニアしかできない。
ビジネスイノベーション、アジャイル、ビジネスアナリシスは１セット
「納品のない受託開発」の先にある「エンジニアの働きかたの未来」
アジャイル型での受託開発。エンジニアが生きる道。
受託開発50% 自社開発50% 100%アジャイル開発
繰り返しは効率はよくない。一気に作ったほうが効率は良い。
100個決まったものを作る。繰り返しだろうと一気につくるだろうとかわならい。
どのくらい作れば、お客様は満足するのか。
なぜ繰り返すのか、いらない機能といる機能をはっきりさせるため <- 最初に約束した機能をすべて作るのであればアジャイル開発する必要はない。
要件として提示された機能を作らないとお金がもらえない。
乗せたリスクが利益になる。 <- ディフェンシブな開発
お客様のビジネスをITで支えるための顧問としてサービスを提供する。
要件定義は不要。仕様変更はいつでも出来る。
作らない提案。
来てもらうか、オンラインか。
納期を死守するとスケジュールにバッファが入る。バッファを積むことになる。
ビジョンを決める。仲間を集め、そこらビジョンを決める。最初にビジョンを決め人を集めるわけではない。
サービスを作るために必要なもの -> 時間
ビールゲームで楽しく学ぼう
システムダイナミックス（System Dyanmics: SD）を学習するロールプレーイングゲーム
面白かった。
相手を疑ってたし、自分がコントールできると思ってた。
情報が足りてないのに足りてると勘違いしてた。
何を記録すべきか気付いたときに対応すべきだったけど、行動に移せなかった。
後半は、本当に一度リセットしたかった。。。