越境する開発 -final bordar-

Toshihiro Ichitani All Rights Reserved.

越境する開発

Ichitani Toshihiro

市谷聡啓

- Final Border -

2014年3月6日木曜日

Toshihiro Ichitani All Rights Reserved.http://about.me/papanda0806

Ichitani Toshihiro

市谷聡啓@papanda


http://about.me/papanda0806

http://about.me/papanda0806


受託→SIer→サービス→受託→

プロダクトオーナー支援アジャイル開発プロジェクトマネージャ現場コミュニティDevLOVEファウンダー

ここまでのあらすじ

「リーン開発の現場」2014年3月6日木曜日


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



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



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



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



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

顧客の理解

多すぎる変更要望組織の理解初めてのチーム

契約の壁コミットメント練度不足

コレジャナイ

合ってない

俺のアジャイル



正しいものを正しく作るDo the Right Things Right.



User Customer Dev2014年3月6日木曜日


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



正しく作る2014年3月6日木曜日


正しいものを？

？2014年3月6日木曜日


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



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

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

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

越境する開発



注意

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

何から学ぶべきか？



How

What

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

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

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

正しいものをダメにつくる

生存戦略



生存戦略

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






越境する開発



２つのレバー



２つのレバー

期待リスク



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

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



プロダクトとして

何を作るか考えたい。

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

これで良いのだっけ？

プロダクトオーナー

開発チーム



目的

目的

目的

目的

目的

期待

期待

期待

期待



目的

目的

目的

目的

目的

期待

期待

期待

期待

開発への期待。

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

立場を超えた理解2014年3月6日木曜日


プロジェクト開始直前 Sprint0 Sprint1 SprintN

期待リスク

期待があるからプロジェクトを始める。広がる夢

状況の把握が進む。PJのWhat/Howが明らかになる。

如何にQCDSを着地させるかが焦点になる。

Moving Management Target

時間を超えた理解2014年3月6日木曜日


期待マネジメント・確認できた最古の書籍　「達人プログラマー」　※最近では「アジャイルサムライ」邦訳版コラムに・PMBOKと期待マネジメント　第3版まで明記はない　　第4版からコミュニケーションマネジメントの中に　第5版からステークホルダーマネジメントとして格上げ

　　※10個目の知識エリア　



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



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

期待があるから挑戦ができる

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



インセプションデッキ

われわれはなぜここにいるのか

エレベーターピッチ

パッケージデザイン

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

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

技術的な解決策

夜も眠れない問題

期間を見極める

トレードオフスライダー

なにがどれだけ必要か

Whyを明らかにする Howを明らかにする2014年3月6日木曜日


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

アジャイルサムライP442014年3月6日木曜日


What

How

Why

アクションまたは結果

Whyを実現する手段

何のためにやる

ゴールデンサークルStart With Why



関係者同席のデッキ作りワークショップ

10個のタフクエスチョン

PJを始める前に関係者の認識をあ

わせる

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

デッキのゴールデンサークルなぜインセプションデッキを作るのか？






越境する開発



数々のデッキ作りと期待マネジメントを通じて

分かったこと。



仮説検証型と最短距離型



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





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




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

決められる。







決められる。


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






決められる。


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


仮説検証型最短距離型




サービスの企画を

一緒に考えて欲しい。

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




3月末までにサービスをローンチしたい作りながら

もろもろ決めて

いきましょう






いきましょう危険仮説検証型と最短距離型



考えながら3月末までにはサービスをローンチしたい

作りながらもろもろ決めて

いきましょう






いきましょう超危険仮説検証型と最短距離型



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

必要なスコープを定めましょう




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

必要なスコープを定めましょう

期間契約請負契約目的に適した方針と建付けを適用する

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

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




戦い方が変わる



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

ユーザーストーリーマッピングスコープ最小(MVP)バッファマネジメント

リスク回避のためのイテレーション開発

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

ワークフロー可視化のためのカンバン

セットベースゴールデンパス

Plan

Do

Check 仮説評価レトロスペクティブAction 転回改善



誰の何のために何を提供するのか企画書を検証する。

リーンキャンバス

課題

解決策

測定指標

提供価値

圧倒的優位性

チャネル

顧客

収益コスト

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

仮説検証型



エクスペリエンスマップ

ユーザーのインサイトに踏み込む。ペルソナも参加キャンバスの課題が現れるか？

提供価値が顧客の感情を変えられるか？2014年3月6日木曜日


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

ソフトウェアとして必要なストーリーを洗う。検証したいMVPを特定する。

エクスペリエンスマップから変換する2014年3月6日木曜日



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



仮説検証

仮説

検証

リーンキャンバス

エクスペリエンスマップ

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


インタビュー

フィードバック初期コンセプト2014年3月6日木曜日








Plan

Do




カンバン仮説検証型最短距離型

仮説検証型フェーズの場合ワークフローが定まりにくいため関係者の状況把握に使うタスク、課題解決の可視化 => タスクボード

最短距離型フェーズの場合ワークフローを見えるようにし改善できるようにする全体フローの見える化 => カンバンボード









Plan

Do











Plan

Do



期待マネジメント

リスクマネジメント2014年3月6日木曜日





越境する開発



ある春。



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

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

How

Why

？



ユーザーストーリーマッピングでMVPを特定し開発へ進む。

ゴールデンサークルは埋まった、WhyもHowもある。次の一手は？



ユーザーストーリーマッピングでMVPを特定し開発へ進む。作る前の仮説検証(インタビュー)。想定ユーザーの反応を見る。「本当に、ユーザーの用事を　解決できるのか？」

ゴールデンサークルは埋まった、WhyもHowもある。次の一手は？



「ユーザーの声を聴く必要はない」2014年3月6日木曜日


ソフトウェア開発3つのムダ間違ったものを作るというムダ

学び損ねるというムダ

過度な作業切り替えによるムダ

ソフトウェアを作るという高価な検証手段を取る前にユーザーの反応を見る。



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

相手の無謀を止める



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

相手の無謀を止める＝

開発を止める?!


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

<このプロジェクトの根幹に関わる理由を1つ、ここに書く

絶対に実現しなければいけないこととは？




どのレイヤで顧客と向き合っているのか？

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

顧客のプロダクトが売れなければ意味がない



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



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

取引関係一時限り彼ら疑念

自分を良く見せる現在に注目勝利すること消耗、防御

長期的われわれ信頼

相手を理解する将来に注目関係を保つこと心地良さ、開放的



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



チーム顧客

ユーザープロジェクト

ソフトウェアを創り上げるもの



誰が誰と

誰のためにどういうルールで

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

何を




正しいものを正しく作るDo the Right Things Right.



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



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

　共に、探すしかない。2014年3月6日木曜日


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


チーム顧客




境を、越える



われわれはなぜここにいるのか？

①何を作るべきか学ぶために。②早期に、直近の収益を上げるために。

ビジネスオーナーを含めて、Why(目的)を再確認する。

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



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

越境する開発とは？



できるのか？



顧客とどのレイヤで



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



期待を可視化し



状況に応じた道具を選び



日々の準備があれば



2回目の正直

約300人

境界は、越えられる。



1回目ローンチできず



約300人

2回目の正直


P109

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



前例に囚われず思考を停止しない

＝ありたい姿のために



チーム顧客


自らの境界を2014年3月6日木曜日


越えて、行け。






越境する開発

次の門へ。



願わくば、みなさんと境のどこかで

出会えますように。


越境する開発 -final bordar-

Technology