越境する開発 -Final Bordar-

越境する
開発

- Final Border Ichitani Toshihiro

Toshihiro Ichitani All Rights Reserved.
2014年3月6日木曜日

市谷聡啓

@papanda
Ichitani Toshihiro

市谷聡啓
http://about.me/papanda0806

ここまでのあらすじ
受託→SIer→サービス→受託→
プロダクトオーナー支援
アジャイル開発プロジェクト
マネージャ
現場コミュニティDevLOVE
ファウンダー
「リーン開発の現場」

本日のStoryは、
現職2年半における
複数の受託開発PJを
元に構成しています。

今回のStoryを紡げたのは、
仮説検証型の受託開発の
ゼロからの立ち上げから、
ビジネス面では羽根田、
開発面では瀬戸さんという
相棒に恵まれたおかげです。
そして、お付き合い頂いたすべての
お客様と皆さんに感謝いたします。

アジャイル
ソフトウェア
開発

問い
なぜ、ダメになるのか？


コレジャナイ
コミットメント練度不足
顧客の理解
契約の壁

俺のアジャイル

想定外の失敗
不慣れなやり方

合ってない

組織の理解
多すぎる変更要望

初めてのチーム


Do the Right Things Right.

正しいものを正しく作る

User

Customer


Dev

相手の意図もこちらの意図も
圧倒的に伝わらない。


正しく作る

？
正しいものを？

誰かが正解を持っている
訳ではない。


正しいものを正しくつくるへ向う道
第1の門

期待マネジメント
第2の門

仮説検証型と最短距離型
第3の門

越境する開発

注意

何から学ぶべきか？
100人マネージャがいてもソフ
トウェアは永遠にできないが、
100人プログラマーがいたら、
いつか何かできる

生存戦略
What
正しいものを
ダメにつくる

正しいものを
正しくつくる

ダメなものを
ダメにつくる

ダメなものを
正しくつくる

How

生存戦略

正しさは状況が決める(不安定)。
一方、つくる力は嘘にならない。
つくる力= 正しさを見つける力

２つのレバー


２つのレバー
期待

リスク


関係者が互いに持っている
プロダクト/プロジェクト/チーム
への暗黙的な望み

期待
期待を明らかにして適切に調整
し続ける。立場と時間を越えて。


プロダクト
として
何を作るか
考えたい。

プロダクトオーナー

考え
終わったら
呼んで
下さい。

開発チーム

これで良いのだっけ？

目的

期待
目的

期待
目的

期待
目的

期待
目的


目的

期待
開発への
期待。

目的

期待
目的

期待
期待

プロダクト
目的
オーナーへの
期待。
目的

立場を超えた理解

Moving Management Target
プロジェクト
開始直前

Sprint0 Sprint1 SprintN

期待
リスク
期待があるから

状況の把握が進む。如何にQCDSを

プロジェクトを

PJのWhat/How

着地させるかが

始める。広がる夢

が明らかになる。

焦点になる。

時間を超えた理解



・確認できた最古の書籍

「達人プログラマー」

※最近では「アジャイルサムライ」邦訳版コラムに

・PMBOKと期待マネジメント

第3版まで明記はない
第4版からコミュニケーションマネジメントの中に
第5版からステークホルダーマネジメントとして格上げ
※10個目の知識エリア

期待もリスクも無くすべきもの？


期待もリスクも無くすべきもの？
リスクがある=不確実性への挑戦
期待があるから挑戦ができる

期待もリスクもあるべきもの。
暴走しないようにマネジメントし
続ける。

インセプションデッキ
技術的な
解決策

エレベーター
ピッチ

期間を
見極める

トレードオフ
スライダー

なにが
どれだけ
必要か

やること
やらないこと
リスト

われわれは
なぜここに
いるのか
パッケージ
デザイン

プロジェクト
コミュニティ

Whyを明らかにする

夜も眠れない
問題

Howを明らかにする



なぜインセプションデッキ？
「然るべき人が集まっているか」
「プロジェクトが然るべき方向を
向いているか」
を明らかにする
チームメンバーが誰もいないところ
で合意したことを前提にしているか
ら、プロジェクトがダメになる
アジャイルサムライP44

Start With Why

ゴールデンサークル
何のためにやる

Why
Whyを実現
する手段

How
What

アクション
または結果


なぜインセプションデッキを作るのか？

デッキのゴールデンサークル
PJを始める前
に関係者の認識をあ
わせる

PJの状況や背景につ
いてチームで話しあっ
ておくことで、チーム
は状況に応じた適切な
判断が下せる。

10個のタフクエス
チョン
関係者同席のデッキ作り
ワークショップ

数々のデッキ作りと
期待マネジメントを通じて
分かったこと。


目的実現の
ための選択肢が
いろいろある


目的実現の
いろいろある

何を選ぶか
決めるために
試行し
検証する


目的実現の
いろいろある

検証(学び)から
何をどう作るか
徐々に
決められる。

何を選ぶか
決めるために
試行し
検証する


目的実現の
いろいろある

徐々に
決められる。

何を選ぶか
決めるために
試行し
検証する


手段と対象が
決まれば
ゴールまで
一直線でいく
迷わない

目的実現の
いろいろある

徐々に
決められる。

手段と対象が
決まれば
ゴールまで
一直線でいく
迷わない

何を選ぶか
決めるために
試行し
検証する

仮説検証型

最短距離型


サービスの
企画を
一緒に考えて
欲しい。

サービス実現に
必要な技術検証
をしましょう。


3月末までに
サービスを
ローンチしたい

作りながら
もろもろ
決めて
いきましょう


3月末までに
サービスを

危険
作りながら
もろもろ
決めて
いきましょう


考えながら
3月末までには
サービスを

作りながら
もろもろ
決めて
いきましょう


3月末までに
サービスを

超危険
作りながら
もろもろ
決めて
いきましょう


3月末までに
サービスを

3月末までに
必要な
スコープを
定めましょう


3月末までに
サービスを

3月末までに
必要な
スコープを
定めましょう

この機能が
このくらいで
出せたら
良いよね

期間契約

最短距離で
いかないと
間に合わない

請負契約

目的に適した方針と建付けを適用する

戦い方が変わる


仮説検証型
仮説立案(リーンキャンバス)

Plan

セットベース
ユーザーストーリーマッピング

Do

学習効果を得るための
イテレーション開発
共通認識を作る
ためのカンバン

Check

仮説評価

Action

転回

最短距離型
バッファマネジメント
スコープ最小(MVP)
ゴールデンパス
リスク回避のための
ワークフロー可視化の
レトロスペクティブ
改善


リーンキャンバス

仮説検証型

誰の何のために何を提供するのか
企画書を検証する。
解決策
提供
価値

課題
測定
指標
コスト

圧倒的
優位性
顧客
チャネル

収益

コンセプトの硬さ(練り具合)を見る。

エクスペリエンスマップ

ユーザーのインサイトに踏み込む。ペルソナも参加
キャンバスの課題が現れるか？
提供価値が顧客の感情を変えられるか？


ソフトウェアとして必要なストーリーを洗う。
検証したいMVPを特定する。
エクスペリエンスマップから変換する


プロジェクト準備OKか妥当性を確認する
関係者全員で確認する。

リーンキャンバス

仮説
エクスペリエンスマップ

検証
ユーザーストーリー
マッピング

仮説
インセプション
デッキ

検証
インタビュー

フィードバック

初期コンセプト

カンバン

仮説検証型
最短距離型

仮説検証型フェーズの場合ワークフローが
定まりにくいため関係者の状況把握に使う
タスク、課題解決の可視化 => タスクボード
最短距離型フェーズの場合ワークフローを
見えるようにし改善できるようにする
全体フローの見える化 => カンバンボード

仮説検証型

Plan

セットベース

Do


Check

仮説評価

Action

転回

最短距離型
改善


最短距離型

仮説検証型

Plan

セットベース

Do


Check

仮説評価

Action

転回

改善

リスクマネジメント


ある春。


これから作るサービスの
ゴールデンサークルが描けるか？

Why

？

How
Coolなメガネを売るための
新感覚のECサイト


ゴールデンサークルは埋まった、
WhyもHowもある。次の一手は？
ユーザーストーリーマッピングで
MVPを特定し開発へ進む。


ゴールデンサークルは埋まった、
WhyもHowもある。次の一手は？
ユーザーストーリーマッピングで
MVPを特定し開発へ進む。
作る前の仮説検証(インタビュー)。
想定ユーザーの反応を見る。

「本当に、ユーザーの用事を
解決できるのか？」

「ユーザーの声を聴く必要はない」

ソフトウェア開発3つのムダ
間違ったものを作るというムダ
ソフトウェアを作るという
高価な検証手段を取る前に
ユーザーの反応を見る。

学び損ねるというムダ
過度な作業切り替えによるムダ

相手の無謀を止める


相手の無謀を止める
＝
開発を止める?!


我われはなぜここにいるのか
• 大事な理由その1

<このプロジェクトの根幹に
関わる理由を1つ、ここに書く
絶対に実現しなければいけないこととは？

どのレイヤで顧客と向き
合っているのか？
顧客の
プロダクトが
売れなければ
意味がない

PJの期間が
1ヶ月
伸びれば
1人月分


目的立ち返るために上位へ遡る。


相手とどんな関係を築きたいのか？
関係のマネジメントと取引のマネジメント
取引

関係

一時限り

長期的

彼ら

われわれ

疑念

信頼

自分を良く見せる

相手を理解する

現在に注目

将来に注目

勝利すること

関係を保つこと

消耗、防御

心地良さ、開放的


売り方(価値)が分からない
プロダクト開発で大丈夫か。

ソフトウェアを創り上げるもの
プロジェクト

チーム

ユーザー

顧客


どういう
ルールで

誰のために

何を
誰が

誰と

「誰が」「誰と」「誰のために」
「どういうルール」で「何を」作るか

正しさは誰にも決められない。


正しさは誰にも決められない。

共に、探すしかない。

プロジェクト

チーム

ユーザー

顧客

「自分が」「顧客ならば」「ユーザーのために」
「こんなやり方」で「これを」作るのか？

境を、越える

われわれはなぜここにいるのか？
ビジネスオーナーを含めて、
Why(目的)を再確認する。
①何を作るべきか学ぶために。
②早期に、直近の収益を上げるために。

検証継続。一般ローンチせず。
=自分たちの役割を終える


越境する開発とは？

自分と相手の中に
ぶれない軸をつくる

できる
のか？

顧客とどのレイヤで


どんな関係を結ぶつもりで


期待を可視化し


状況に応じた道具を選び


日々の準備があれば


2回目の正直

境界は、
越えられる。
約300人

1回目
ローンチ
できず


2回目の正直

約300人

P109



理想とはたどりつくべき
場所のことではなく、
ありたい姿に向かい続ける
ことなんだ！

P109

前例に囚われず
思考を停止しない
＝
ありたい姿のために

プロジェクト

チーム

ユーザー

顧客

自らの境界を

越えて、行け。

正しいものを正しくつくるへ向う道
第1の門


次の門へ。
第2の門

第3の門

越境する開発

願わくば、みなさんと
境のどこかで
出会えますように。

越境する開発 -Final Bordar-

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (14)

Destacado

Destacado (15)

Similar a 越境する開発 -Final Bordar-

Similar a 越境する開発 -Final Bordar- (11)

Más de toshihiro ichitani

Más de toshihiro ichitani (20)

Último

Último (7)

越境する開発 -Final Bordar-