Trust Based Development
- 1. Toshihiro Ichitani All Rights Reserved. Trust Based Development Ichitani Toshihiro 市?聡啓 - リモートワークによるアジャイル开発 -
- 2. Toshihiro Ichitani All Rights Reserved. http://about.me/papanda0806 Ichitani Toshihiro 市?聡啓 ソフトウェア開発16年 SIer→サービス→受託→起業 仮説検証とアジャイル開発 ギルドワークス株式会社 代表 株式会社 エナジャイル 代表 ?般社団法? 越境アジャイルアライアンス代表理事 DevLOVE コミュニティ ファウンダ 0 → 1
- 3. Toshihiro Ichitani All Rights Reserved. スタートアップや事業会社での新規事業、 新規サービスの?ち上げ 事業会社での現場改善、仮説検証コーチ ゆるやかにデベロッパーのギルドを形成 ギルドワークス 「正しいものを正しくつくる」 Why What
- 4. Copyright (c) 2017 Guild Works Inc. 本?のテーマ リモートワークによるアジャイル开発
- 5. Copyright (c) 2017 Guild Works Inc. ちょっとおさらい “アジャイルな開発”とは？
- 6. Copyright (c) 2017 Guild Works Inc. ちょっとおさらい “アジャイルな開発”とは？ 少しずつ反復的に開発を進めることで 必要とする?から必要なフィードバックを得て 調整し続けられる開発
- 7. Copyright (c) 2017 Guild Works Inc. ちょっとおさらい “アジャイルな開発”とは？ 少しずつ反復的に開発を進めることで 必要とする?から必要なフィードバックを得て 調整し続けられる開発 「インクリメンタル」(少しずつ) 「イテレーティブ」(繰り返し) つまり「早く(少しだけ)形にできる」やり?
- 8. Copyright (c) 2017 Guild Works Inc. リリーステスト実装設計 フェーズゲート開発 アジャイルな開発 要件定義 開発された ボリューム 8
- 9. Copyright (c) 2017 Guild Works Inc. /papanda/ss-41638116/papanda/ss-79465986 “アジャイル開発”の理解を深める 具体的な進め?を知る From do agile To be agile.
- 10. Copyright (c) 2017 Guild Works Inc. 早く(少しだけ)形にできることの意義 フィードバックに基づく調整で、?的に適した ソフトウェアに仕?てられる 形にすることで早めに関係者の認識を揃えられる つくるものやチームについての問題に早く気付ける チームの学習効果が?い 早く始められる 結合のリスクを早めに倒せる Time to market が短い サンクコストが?さくできる 開発チームのリズムを整えられる ① ② ③ ④ ⑤ ⑥ ⑦ ⑧ ⑨ 10
- 11. Copyright (c) 2017 Guild Works Inc. もうちょっというと プロセスやツールよりも個?と対話を ビジネス側の?と開発者は、プロジェクトを通して? ?々?緒に働かなければなりません。 情報を伝えるもっとも効率的で効果的な?法は? フェイス?トゥ?フェイスで話をすることです。
- 12. Copyright (c) 2017 Guild Works Inc. もうちょっというと プロセスやツールよりも個?と対話を ビジネス側の?と開発者は、プロジェクトを通して? ?々?緒に働かなければなりません。 情報を伝えるもっとも効率的で効果的な?法は? フェイス?トゥ?フェイスで話をすることです。 これまで通りの解釈では リモートワークに合わない (?分たちの状況によった解釈が必要)
- 13. Copyright (c) 2017 Guild Works Inc. そもそもリモートワークで必然性あるのか？ 当然、リモートワークでの開発だからといって、つくる ものは容易ではない。というか、昔に?べるとますます よくわからないものをつくっている。 早く少しだけ形にすることで つくるべきものが何か理解で きる
- 14. Copyright (c) 2017 Guild Works Inc. ① ツールコミュニケーションが中? ② 何をつくるべきかの統制を記述に頼りがち ③ あいまいさが混乱を招く。責任分界点が求められる ④ …ということやっていくと、?ずと硬めの計画的になる 物理的に離れた分散開発の場合 プロダクトオーナー 開発チーム プロダクトオーナー代? 兼マネジメント A拠点デザイナー B拠点プログラマー C拠点プログラマー スクラムイベント 委託契約 委託契約 委託契約 UserStory Base
- 15. Copyright (c) 2017 Guild Works Inc. ① ツールコミュニケーションが中? ② 何をつくるべきかの統制を記述に頼りがち ③ あいまいさが混乱を招く。責任分界点が求められる ④ …ということやっていくと、?ずと硬めの計画的になる 物理的に離れた分散開発の場合
- 16. Copyright (c) 2017 Guild Works Inc. ① ツールコミュニケーションが中? ② 何をつくるべきかの統制を記述に頼りがち ③ あいまいさが混乱を招く。責任分界点が求められる ④ …ということやっていくと、?ずと硬めの計画的になる ⑤ “いつもの(同席の)感じ”でいると品質は落ちる ⑥ むちゃくちゃマネジメントも?数かかる 物理的に離れた分散開発の場合
- 17. Copyright (c) 2017 Guild Works Inc. リモートワーク開発、やばい？！ ① ツールコミュニケーションが中? ② 何をつくるべきかの統制を記述に頼りがち ③ あいまいさが混乱を招く。責任分界点が求められる ④ …ということやっていくと、?ずと硬めの計画的になる ⑤ “いつもの(同席の)感じ”でいると品質は落ちる ⑥ むちゃくちゃマネジメントも?数かかる 物理的に離れた分散開発の場合
- 18. Copyright (c) 2017 Guild Works Inc. Cost Delivery Scope Quality よくある”アジャイル開発”の教え QCDは固定なのでSで調整しよう リモートワーク開発に移?して 最初にやられるパターン C D Q S 機能の仕様を?較的細かく事前に 決めておかないとQもCもDもずれる！ Sも固定する。(あれ？） 次にもめるパターン C D Q S Sが決めきれないので、時間契約 しよう！(=コストで調整) 現実的にはDがコミットできない
- 19. Copyright (c) 2017 Guild Works Inc. 3年間の実地検証による学び 離れているからこそ、いつ仕事をするかなんて当?次第。 時間契約でないならば、結果の測り?は成果主義。 ① やり?がプロなら、成果もプロ。 ② 信頼がおける、お互いの価値観。 リモートワークによる(アジャイルな)開発にある ”フォース” 離れているからこそ、いちいち疑?暗?にならなくて済む ように、仕事に対するあり?が共通認識化されていること。
- 20. Copyright (c) 2017 Guild Works Inc. ① やり?がプロなら、成果もプロ。 (1) アウトプットではなく、アウトカムに対する対価。 機能(アウトプット)ではなく、?標達成の度合い(アウトカム)を ベースに対価を決めるイメージ。 ある達成に対して、どの程度の対価でやるかを握って進める。 ある仕事をするのに、どの程度時間をつぎ込むかは?分次第。 想定よりも物理的な時間がかかることもあるし、少なく済むこと もある。 もちろん、やってみないと分からないこともある。想定の度を 越える場合は、期間やお?、スコープなどで調整をかける。
- 21. Copyright (c) 2017 Guild Works Inc. ① やり?がプロなら、成果もプロ。 (2) バッファマネジメントで期間を守る。 「プロとして、仕事をやりきる」スタンスでも、?番ネックに なりがちなのは ”スケジュール”。 リモートワークは、同席に?べると、認識やコミュニケーション のオーバーヘッドは必ずある。それは、期間に響いてくる。 期間のコミットを守るためには、”バッファ”のマネジメントが 必須。プランニングでの腕の?せ所。
- 22. Copyright (c) 2017 Guild Works Inc. Cost Delivery Scope Quality “アウトカムベース”をQCDSで表現したイメージ QCDSすべて固定的。バッファと確率の問題で捉える。 Cost、Scopeは、許容量と現実的な発?確率でどの程度リスクの 重さがあるか判断する。 依頼側のリスク 受ける側のリスク期間バッファ バッファとリスクの組み?の例。 実際に、どこにバッファを張り、 どこでリスクを捉えるかは ケースに応じて変わる。 ポートフォリオで判断する。 どれか?つではなく、複合的に組み合わ せてヘッジする。どれが?つが突出して しまうと??Loseの確度が?まり バランスに?ける。
- 23. Copyright (c) 2017 Guild Works Inc. ② 信頼がおける、お互いの価値観 (3) プロジェクトを越えた共通のミッション。 仕事を?緒にする者同?として、守りたい、到達したい ミッションを共通化しておく。 ギルドワークスで?えば「正しいものを正しくつくる」。 ギルドワークスだけではなく、ギルド的開発チームの共通の ミッションに置く。 共通ミッションを醸成するのは、プロジェクト始まってから では準備不?。プロジェクト外で、?語化、認識を深める。
- 24. Copyright (c) 2017 Guild Works Inc. ② 信頼がおける、お互いの価値観 (4) ここぞという時はやっぱり結集する。 ?常コミュニケーションのメインが、オンライン通話、チャット だとしても、ここぞいうときは集まることを厭わない 主な”ここぞ”は、仕事をはじめるとき、問題が起きているとき、 ピンチのとき、仕事を終えてお祝いするとき。?同で集まる。 “同席”のために、合宿を?なう。たいていコスパは割に合う。 もしコストが?すぎる、つまり想定以上に頻繁に”同席”が 求められるのであれば、やり?に問題があるか、リモートワーク 向きのプロジェクトではないのかもしれない。
- 25. Copyright (c) 2017 Guild Works Inc. ① やり?がプロなら、成果もプロ。 (1) アウトプットではなく、アウトカムに対する対価。 (2) バッファマネジメントで期間を守る。 ② 信頼がおける、お互いの価値観 (3) プロジェクトを越えた共通のミッション。 (4) ここぞという時はやっぱり結集する。 根底にあるのは、互いへの ”信頼” 互いの信頼が無いと、アウトカムベースの握り?は 不確か過ぎて、お互いとして出来ない。
- 26. Copyright (c) 2017 Guild Works Inc. 共にしている時間 取引コスト リモートワーク 同席開発 相?に依頼し内容を 理解してもらったり 履?してもらうため に要するコスト リモートワーク、同席開発
- 27. Copyright (c) 2017 Guild Works Inc. 共にしている時間 取引コスト リモートワーク 同席開発 相?に依頼し内容を 理解してもらったり 履?してもらうため に要するコスト プロジェクトを越えた 共通のミッション ここぞいうときは結集 Trust Based Development 「安?社会から信頼社会へ」(?岸 俊男)によると、 みんなが同じ環境にいるという安?感から?まれた安定性に基づく=「安?社会」 独?した個々?が、相互に尊重し合う関係=「信頼社会」 という分類ができ、物理的に場所が離れるというリモートワークでは「信頼社会」 の考え?が合致すると?える TBD
- 28. Copyright (c) 2017 Guild Works Inc. どうやって信頼をはぐくむのか？ 少しずつ重ねるしかない。 少しずつ仕事をして、お互いの考え?や調?を把握し、 チューニングし、やれるかどうかを?極める。 互いを?極める前に、?いなる仕事を始めてはいけない。 プロダクトも、関係性も、 インクリメンタルに形作る。