これからの開発環境の話をしよう － 開発現場力を高める環境づくり

Tomoharu Nagasawa Technical Evangelist, Microsoft Certified Scrum Master (CSM) これからのソフトウェア開発環境の話をしよう 開発現場力を高める環境づくり

これからの 開発の”現場” Development “Gemba”

Your View YOU

あなたのエンドユーザーのビジネス あなたのチーム YOU あなたの関係者 あなたのエンドユーザー

あなたのエンドユーザーのビジネス YOU code feature Business

Code Complete フィードバック サイクル YOU 手戻り コスト code feature Business x1 x10 x100

Feature Complete YOU code Your Team feature Business x1 x10

Business Technology

Business Customer Development Customer Discovery Customer Validation Iteration Customer Creation Company Building Execution Technology

Business Lean Startup | Build – Measure - Learn アイデア LEARN データ BUILD Dev Ops Biz プロダクト MEASURE Technology

2010s 2000s 1990s Cost Center Key Infrastructure Morphing IT

ビジネス モデル Cost Center IT に非依存 Key Infrastructure IT が関与 Morphing IT がドライバーIT

意思決定 Cost Center IT 部門 Key Infrastructure 経営者層 Morphing IT 顧客/市場が中心

テクノロジー CostC/S Center Key Infrastructure Web / Web サービス Morphing IT クラウドとデバイス

ビジネスモデル 顧客と市場への をけん引 アジリティ クラウド＆ Dev と Ops の デバイスの活用 協調

協調 協調ワークは非公開とさせていただきます。

Environment 環境 統制 Control Environment

Environment モチベーション 目的 / 規律 / 自律 / 見える化 よいものを取り入れる “勇気”

人 自立 Autonomy 相互作用 熟達 Mastery 動くソフトウェア 目的 Purpose 顧客との協調 変更/変化への反応 協調

これからの開発”現場” code feature Business ビジネス駆動 | 意味のあるフィードバック | 検査と適応

これからの 開発スタイル Development Practices

Changes 効率化 Decade Biz App ビジネス ＝確立 リリース ＝一括 意思決定 ＝開発 技術･手法＝経験済み ビジネス化 Next Decade Biz App ビジネス ＝変動 リリース ＝逐次 意思決定 ＝市場 技術･手法＝未経験

Delivery Value 仕掛り (WIP) 高 ROI 低 ROI Time

Delivery Value 適切な 仕掛り (WIP) 定期的 (Time Box) Time

View Points 変化 未経験 ？ リズム 協調

Stacey Matrix 難 無秩序 やや 複雑 複雑 ビジネスモデル (要求) 単純 やや 複雑 易 実績あり 未経験 テクノロジー

定義されたプロセス モデル Defined Process Model 例:  建物の建築 (過去に経験があり、技術も安定している)  ソフトウェア？ (過去に存在するものは調達すればよい) 実測駆動なプロセス モデル Empirical Process Model 例:  新製品開発 (過去に経験がない、ビジネス価値を創出)  ソフトウェア！ (新たなチャレンジが多い)

テンプレート化しやすい 定義されたプロセス モデル  見積もり可能で、計画を立てやすい M1 Task 1 Defined Process Model  WBS による計測がしやすい  工程を区切り、成果物管理がしやすい Task 3 例:  自分の割り当てられた仕事に注力しやすい Task 4  建物の建築 (過去に経験があり、技術も安定している)  I’m done の蓄積が全体成果になりやすい Task 5  ソフトウェア？ (過去に存在するものは調達すればよい)  サイロに陥りやすい Task 2 検査と適応 モデル 実測駆動なプロセス  価値と経験を基準にするしかない Empirical Process Model  見積もり、進捗、品質 Value  定期的に見直すことで見極めるしかない 例:  自分の割り当てられた仕事に価値は見いだせない  We’re done でなければ、計測できない  新製品開発 (過去に経験がない、ビジネス価値を創出)  サイロがない  ソフトウェア！ (新たなチャレンジが多い)

WIP (仕掛り) とフィードバックの比較 6 か月のプロジェクト / 36 機能 Value 6か月 36 個 WIP  リリース: 1 回  WIP: 36 個  フィードバック機会: 1 回 Time ウォーターフォール Lead Time Value 6か月 36 個 WIP 3 WIP 2 WIP Time Lead Lead Lead Time Time Time スクラム Time Box (固定) Value Lead Time 6か月 36 個 1 WIP WIP 1 1 WIP WIP Time カンバン  リリース: 6m ÷ タイムボックス (2w) = 12 回  WIP: 36 個 ÷ 12 回 = 3 (2 ～ 4) 個  フィードバック機会: 12 回 Lead Lead Lead Time Time Time Lead Lead Time Time     リリース: MMF (Minimal Marketing Feature) = 36 回 WIP: 1 個 フィードバック機会: 36 回 (WIP Limit: 4 個)

主なムダな作り込みをしない戦術 MVP: Minimum Viable Product  顧客ニーズの学習を主目的とした最小限の製品/サービス を用いる戦術  実用可能な最小セットを実際に使ってもらいフィード バックを得る MVP Canary Release カナリア リリース  一部の協力的なユーザー (アーリーアダプター) に先行リ リースし、フィードバックを得るリリース  事前リリースのフィードバックにより、手戻りコストを 最小化する A/B テスト A A/B テスト B  2 通りのランディング画面やバナー、サービスを用意し、 実際のユーザーの行動パターンを計測し最適な解を得る  顧客開発 (開拓) の手法としても有効 (想定ユーザーと違う層にウケることがわかったなど) TIPS: 実運用を伴わないデプロイ を行うことが可能な場合も ある。 例:  別ブランドで実験  インサイト顧客にのみ 提供  期間限定のサービス 実際の行動/実績を伴うこ とがポイントである。  机上ではなく、事実に 基づく学習と検証が行 われる

Scrum スクラムマスター デイリー スクラム プロダクトバックログ ３ １ ５ １ ３ ３ ５ ？ ？ ？ PRIORITIZE プロダクトオーナー スプリント PLAN EXECUTE チーム RESPOND

Scrum スクラムマスター プロダクトバックログ ３ １ １ ３ ５ ？ ？ ？ PRIORITIZE プロダクトオーナー デイリー スクラム バーンダウン ３ ５ ３ ５ PLAN EXECUTE チーム RESPOND

Scrum スクラムマスター プロダクトバックログ ３ １ １ ３ ５ ？ ？ ？ ベロシティ ８ ７ ８ １ ３ ２ ２ ２ ５ ５ ３ PRIORITIZE プロダクトオーナー チーム

ツール活用の真価 Going Continuous Value Delivery with Tools

透明性は、 チームメンバーの信頼のために、 自らが選択するものである Tools for Agility By Kent Beck, June. 2008 http://aka.ms/T4A Transparency

Responsibility Code feature Business ツール: 個々の作業の効率化

Responsibility Code feature Business ツール: 作業間の効率化

ツールへの期待 チームの開発者には差がある！     設計能力 実装能力 テスト能力 情報把握能力

ツールへの期待 チームに求められる能力を把握

ツールへの期待 作業効率化ツール でカバーする領域

ツールへの期待 デッドゾーンを何で補うか！？ 作業効率化ツール でカバーする領域 Team Foundation Server 一元管理 | 作業間の効率化 | プラクティス支援 | 透明性 | 情報共有

ツールへの期待 作業効率化ツール でカバーする領域 作業間の移行の効率化と透明性 ＝ プラクティスとツールチェーン

Future Change❓ 今後の開発環境の変化:  作業間のスムーズな移行  自動テストの対象の拡大  リアルタイムな共同作業  透明性 Tools for Agility By Kent Beck, June. 2008 http://aka.ms/T4A

開発者が得るべき透明性 正しいことを、正しく行う これを正しくわかること うそのない 開発 変化に機敏な 開発 ビジネス駆動 な開発 自分を磨く 開発

情報リソース Kent Beck 氏 ホワイトペーパー 書籍 スピーカーのブログ Tools for Agility 『アジャイルソフトウェア エンジニアリング』 日経BP社 SoftwareEngineeringPlatform.com 俊敏性のためのツール http://aka.ms/T4A http://twitter.com/AgileSEBook http://aka.ms/tomohn

We are Pig ! for Customer Business http://www.scrum.org/You-Are-a-Scrum-Pig [email protected] | @tomohn http://SoftwareEngineeringPlatform.com