SlideShare a Scribd company logo
1 of 28
Download to read offline
Toshihiro Ichitani All Rights Reserved.
Trust Based Development
Ichitani Toshihiro
市⾕聡啓
- リモートワークによるアジャイル開発 -
Toshihiro Ichitani All Rights Reserved.
http://about.me/papanda0806
Ichitani Toshihiro
市⾕聡啓
ソフトウェア開発16年
SIer→サービス→受託→起業
仮説検証とアジャイル開発
ギルドワークス株式会社 代表
株式会社 エナジャイル 代表
⼀般社団法⼈ 越境アジャイルアライアンス代表理事
DevLOVE コミュニティ ファウンダ
0 → 1
Toshihiro Ichitani All Rights Reserved.
スタートアップや事業会社での新規事業、
新規サービスの⽴ち上げ
事業会社での現場改善、仮説検証コーチ
ゆるやかにデベロッパーのギルドを形成
ギルドワークス
「正しいものを正しくつくる」
Why
What
Copyright (c) 2017 Guild Works Inc.
本⽇のテーマ
リモートワークによるアジャイル開発
Copyright (c) 2017 Guild Works Inc.
ちょっとおさらい
“アジャイルな開発”とは?
Copyright (c) 2017 Guild Works Inc.
ちょっとおさらい
“アジャイルな開発”とは?
少しずつ反復的に開発を進めることで
必要とする⼈から必要なフィードバックを得て
調整し続けられる開発
Copyright (c) 2017 Guild Works Inc.
ちょっとおさらい
“アジャイルな開発”とは?
少しずつ反復的に開発を進めることで
必要とする⼈から必要なフィードバックを得て
調整し続けられる開発
「インクリメンタル」(少しずつ)
「イテレーティブ」(繰り返し)
つまり「早く(少しだけ)形にできる」やり⽅
Copyright (c) 2017 Guild Works Inc.
リリーステスト実装設計
フェーズゲート開発
アジャイルな開発
要件定義
開発された
ボリューム
8
Copyright (c) 2017 Guild Works Inc.
https://www.slideshare.net/papanda/ss-41638116https://www.slideshare.net/papanda/ss-79465986
“アジャイル開発”の理解を深める 具体的な進め⽅を知る
From do agile To be agile.
Copyright (c) 2017 Guild Works Inc.
早く(少しだけ)形にできることの意義
フィードバックに基づく調整で、⽬的に適した
ソフトウェアに仕⽴てられる
形にすることで早めに関係者の認識を揃えられる
つくるものやチームについての問題に早く気付ける
チームの学習効果が⾼い
早く始められる
結合のリスクを早めに倒せる
Time to market が短い
サンクコストが⼩さくできる
開発チームのリズムを整えられる
①
②
③
④
⑤
⑥
⑦
⑧
⑨
10
Copyright (c) 2017 Guild Works Inc.
もうちょっというと
プロセスやツールよりも個⼈と対話を
ビジネス側の⼈と開発者は、プロジェクトを通して

⽇々⼀緒に働かなければなりません。
情報を伝えるもっとも効率的で効果的な⽅法は

フェイス・トゥ・フェイスで話をすることです。
Copyright (c) 2017 Guild Works Inc.
もうちょっというと
プロセスやツールよりも個⼈と対話を
ビジネス側の⼈と開発者は、プロジェクトを通して

⽇々⼀緒に働かなければなりません。
情報を伝えるもっとも効率的で効果的な⽅法は

フェイス・トゥ・フェイスで話をすることです。
これまで通りの解釈では
リモートワークに合わない
(⾃分たちの状況によった解釈が必要)
Copyright (c) 2017 Guild Works Inc.
そもそもリモートワークで必然性あるのか?
当然、リモートワークでの開発だからといって、つくる
ものは容易ではない。というか、昔に⽐べるとますます
よくわからないものをつくっている。
早く少しだけ形にすることで
つくるべきものが何か理解で
きる
Copyright (c) 2017 Guild Works Inc.
① ツールコミュニケーションが中⼼
② 何をつくるべきかの統制を記述に頼りがち
③ あいまいさが混乱を招く。責任分界点が求められる
④ …ということやっていくと、⾃ずと硬めの計画的になる
物理的に離れた分散開発の場合
プロダクトオーナー
開発チーム
プロダクトオーナー代⾏
兼マネジメント
A拠点デザイナー
B拠点プログラマー C拠点プログラマー
スクラムイベント
委託契約
委託契約
委託契約
UserStory Base
Copyright (c) 2017 Guild Works Inc.
① ツールコミュニケーションが中⼼
② 何をつくるべきかの統制を記述に頼りがち
③ あいまいさが混乱を招く。責任分界点が求められる
④ …ということやっていくと、⾃ずと硬めの計画的になる
物理的に離れた分散開発の場合
Copyright (c) 2017 Guild Works Inc.
① ツールコミュニケーションが中⼼
② 何をつくるべきかの統制を記述に頼りがち
③ あいまいさが混乱を招く。責任分界点が求められる
④ …ということやっていくと、⾃ずと硬めの計画的になる
⑤ “いつもの(同席の)感じ”でいると品質は落ちる
⑥ むちゃくちゃマネジメントも⼯数かかる
物理的に離れた分散開発の場合
Copyright (c) 2017 Guild Works Inc.
リモートワーク開発、やばい?!
① ツールコミュニケーションが中⼼
② 何をつくるべきかの統制を記述に頼りがち
③ あいまいさが混乱を招く。責任分界点が求められる
④ …ということやっていくと、⾃ずと硬めの計画的になる
⑤ “いつもの(同席の)感じ”でいると品質は落ちる
⑥ むちゃくちゃマネジメントも⼯数かかる
物理的に離れた分散開発の場合
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がコミットできない
Copyright (c) 2017 Guild Works Inc.
3年間の実地検証による学び
離れているからこそ、いつ仕事をするかなんて当⼈次第。
時間契約でないならば、結果の測り⽅は成果主義。
① やり⽅がプロなら、成果もプロ。
② 信頼がおける、お互いの価値観。
リモートワークによる(アジャイルな)開発にある ”フォース”
離れているからこそ、いちいち疑⼼暗⻤にならなくて済む
ように、仕事に対するあり⽅が共通認識化されていること。
Copyright (c) 2017 Guild Works Inc.
① やり⽅がプロなら、成果もプロ。
(1) アウトプットではなく、アウトカムに対する対価。
機能(アウトプット)ではなく、⽬標達成の度合い(アウトカム)を
ベースに対価を決めるイメージ。
ある達成に対して、どの程度の対価でやるかを握って進める。
ある仕事をするのに、どの程度時間をつぎ込むかは⾃分次第。
想定よりも物理的な時間がかかることもあるし、少なく済むこと
もある。
もちろん、やってみないと分からないこともある。想定の度を
越える場合は、期間やお⾦、スコープなどで調整をかける。
Copyright (c) 2017 Guild Works Inc.
① やり⽅がプロなら、成果もプロ。
(2) バッファマネジメントで期間を守る。
「プロとして、仕事をやりきる」スタンスでも、⼀番ネックに
なりがちなのは ”スケジュール”。
リモートワークは、同席に⽐べると、認識やコミュニケーション
のオーバーヘッドは必ずある。それは、期間に響いてくる。
期間のコミットを守るためには、”バッファ”のマネジメントが
必須。プランニングでの腕の⾒せ所。
Copyright (c) 2017 Guild Works Inc.
Cost
Delivery Scope
Quality
“アウトカムベース”をQCDSで表現したイメージ
QCDSすべて固定的。バッファと確率の問題で捉える。
Cost、Scopeは、許容量と現実的な発⽣確率でどの程度リスクの
重さがあるか判断する。
依頼側のリスク
受ける側のリスク期間バッファ
バッファとリスクの組み⽅の例。
実際に、どこにバッファを張り、
どこでリスクを捉えるかは
ケースに応じて変わる。
ポートフォリオで判断する。
どれか⼀つではなく、複合的に組み合わ
せてヘッジする。どれが⼀つが突出して
しまうと⼀⼈Loseの確度が⾼まり
バランスに⽋ける。
Copyright (c) 2017 Guild Works Inc.
② 信頼がおける、お互いの価値観
(3) プロジェクトを越えた共通のミッション。
仕事を⼀緒にする者同⼠として、守りたい、到達したい
ミッションを共通化しておく。
ギルドワークスで⾔えば「正しいものを正しくつくる」。
ギルドワークスだけではなく、ギルド的開発チームの共通の
ミッションに置く。
共通ミッションを醸成するのは、プロジェクト始まってから
では準備不⾜。プロジェクト外で、⾔語化、認識を深める。
Copyright (c) 2017 Guild Works Inc.
② 信頼がおける、お互いの価値観
(4) ここぞという時はやっぱり結集する。
⽇常コミュニケーションのメインが、オンライン通話、チャット
だとしても、ここぞいうときは集まることを厭わない
主な”ここぞ”は、仕事をはじめるとき、問題が起きているとき、
ピンチのとき、仕事を終えてお祝いするとき。⼀同で集まる。
“同席”のために、合宿を⾏なう。たいていコスパは割に合う。
もしコストが⾼すぎる、つまり想定以上に頻繁に”同席”が
求められるのであれば、やり⽅に問題があるか、リモートワーク
向きのプロジェクトではないのかもしれない。
Copyright (c) 2017 Guild Works Inc.
① やり⽅がプロなら、成果もプロ。
(1) アウトプットではなく、アウトカムに対する対価。
(2) バッファマネジメントで期間を守る。
② 信頼がおける、お互いの価値観
(3) プロジェクトを越えた共通のミッション。
(4) ここぞという時はやっぱり結集する。
根底にあるのは、互いへの ”信頼”
互いの信頼が無いと、アウトカムベースの握り⽅は
不確か過ぎて、お互いとして出来ない。
Copyright (c) 2017 Guild Works Inc.
共にしている時間
取引コスト
リモートワーク
同席開発
相⼿に依頼し内容を
理解してもらったり
履⾏してもらうため
に要するコスト
リモートワーク、同席開発
Copyright (c) 2017 Guild Works Inc.
共にしている時間
取引コスト
リモートワーク
同席開発
相⼿に依頼し内容を
理解してもらったり
履⾏してもらうため
に要するコスト プロジェクトを越えた
共通のミッション
ここぞいうときは結集
Trust Based Development
「安⼼社会から信頼社会へ」(⼭岸 俊男)によると、
みんなが同じ環境にいるという安⼼感から⽣まれた安定性に基づく=「安⼼社会」
独⽴した個々⼈が、相互に尊重し合う関係=「信頼社会」
という分類ができ、物理的に場所が離れるというリモートワークでは「信頼社会」
の考え⽅が合致すると⾔える
TBD
Copyright (c) 2017 Guild Works Inc.
どうやって信頼をはぐくむのか?
少しずつ重ねるしかない。
少しずつ仕事をして、お互いの考え⽅や調⼦を把握し、
チューニングし、やれるかどうかを⾒極める。
互いを⾒極める前に、⼤いなる仕事を始めてはいけない。
プロダクトも、関係性も、
インクリメンタルに形作る。

More Related Content

What's hot

What's hot (20)

4つの戦犯から考えるサービスづくりの失敗
4つの戦犯から考えるサービスづくりの失敗4つの戦犯から考えるサービスづくりの失敗
4つの戦犯から考えるサービスづくりの失敗
 
ソフトウェア開発の(俺の)掟
ソフトウェア開発の(俺の)掟ソフトウェア開発の(俺の)掟
ソフトウェア開発の(俺の)掟
 
拝啓、プロダクトオーナー様。
拝啓、プロダクトオーナー様。拝啓、プロダクトオーナー様。
拝啓、プロダクトオーナー様。
 
多様な働き⽅のチームでどうやって アジャイルにやるの?(雁行陣開発)
多様な働き⽅のチームでどうやって アジャイルにやるの?(雁行陣開発)多様な働き⽅のチームでどうやって アジャイルにやるの?(雁行陣開発)
多様な働き⽅のチームでどうやって アジャイルにやるの?(雁行陣開発)
 
逆境から新規事業をスタートアップする「仮説検証型アジャイル開発」の実践
逆境から新規事業をスタートアップする「仮説検証型アジャイル開発」の実践逆境から新規事業をスタートアップする「仮説検証型アジャイル開発」の実践
逆境から新規事業をスタートアップする「仮説検証型アジャイル開発」の実践
 
鉄壁の中のアジャイル
鉄壁の中のアジャイル鉄壁の中のアジャイル
鉄壁の中のアジャイル
 
時を超えた越境への道
時を超えた越境への道時を超えた越境への道
時を超えた越境への道
 
我々に越境できない境界は無い。
我々に越境できない境界は無い。我々に越境できない境界は無い。
我々に越境できない境界は無い。
 
越境アジャイル
越境アジャイル越境アジャイル
越境アジャイル
 
アジャイル開発はWhyから始まる
アジャイル開発はWhyから始まるアジャイル開発はWhyから始まる
アジャイル開発はWhyから始まる
 
ユーザーストーリー駆動開発で行こう。
ユーザーストーリー駆動開発で行こう。ユーザーストーリー駆動開発で行こう。
ユーザーストーリー駆動開発で行こう。
 
新しいジャーニーをはじめよう。
新しいジャーニーをはじめよう。新しいジャーニーをはじめよう。
新しいジャーニーをはじめよう。
 
正しいものを正しくつくる
正しいものを正しくつくる正しいものを正しくつくる
正しいものを正しくつくる
 
正しくないものをつくらない。7つの失敗パターン
正しくないものをつくらない。7つの失敗パターン正しくないものをつくらない。7つの失敗パターン
正しくないものをつくらない。7つの失敗パターン
 
ジャーニーは、いつだって一人から。
ジャーニーは、いつだって一人から。ジャーニーは、いつだって一人から。
ジャーニーは、いつだって一人から。
 
価値探索 -仮説検証の実践-
価値探索 -仮説検証の実践-価値探索 -仮説検証の実践-
価値探索 -仮説検証の実践-
 
越境・ジャーニー
越境・ジャーニー越境・ジャーニー
越境・ジャーニー
 
塹壕にいるすべての同朋へ
塹壕にいるすべての同朋へ塹壕にいるすべての同朋へ
塹壕にいるすべての同朋へ
 
正しいものを正しくつくれているか?
正しいものを正しくつくれているか?正しいものを正しくつくれているか?
正しいものを正しくつくれているか?
 
Emotional development
Emotional developmentEmotional development
Emotional development
 

Viewers also liked

Viewers also liked (9)

BIツールActionista!のインメモリーデータベースIMDB
BIツールActionista!のインメモリーデータベースIMDBBIツールActionista!のインメモリーデータベースIMDB
BIツールActionista!のインメモリーデータベースIMDB
 
ジャストシステムJava100本ノックのご紹介
ジャストシステムJava100本ノックのご紹介ジャストシステムJava100本ノックのご紹介
ジャストシステムJava100本ノックのご紹介
 
Ameba流 scrumを浸透させていく方法
Ameba流 scrumを浸透させていく方法Ameba流 scrumを浸透させていく方法
Ameba流 scrumを浸透させていく方法
 
KPTの基本と、その活用法
KPTの基本と、その活用法KPTの基本と、その活用法
KPTの基本と、その活用法
 
ブロックチェーン技術の基本と応用の可能性
ブロックチェーン技術の基本と応用の可能性ブロックチェーン技術の基本と応用の可能性
ブロックチェーン技術の基本と応用の可能性
 
Googleのインフラ技術から考える理想のDevOps
Googleのインフラ技術から考える理想のDevOpsGoogleのインフラ技術から考える理想のDevOps
Googleのインフラ技術から考える理想のDevOps
 
訴求ファースト。キービジュアル。
訴求ファースト。キービジュアル。訴求ファースト。キービジュアル。
訴求ファースト。キービジュアル。
 
5分でわかるブロックチェーンの基本的な仕組み
5分でわかるブロックチェーンの基本的な仕組み5分でわかるブロックチェーンの基本的な仕組み
5分でわかるブロックチェーンの基本的な仕組み
 
とにかく楽してVue.jsでTypeScriptを使いたい
とにかく楽してVue.jsでTypeScriptを使いたいとにかく楽してVue.jsでTypeScriptを使いたい
とにかく楽してVue.jsでTypeScriptを使いたい
 

Similar to Trust Based Development

拝啓、プロダクトオーナー様。
拝啓、プロダクトオーナー様。拝啓、プロダクトオーナー様。
拝啓、プロダクトオーナー様。
GuildWorks
 
チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで
チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまでチーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで
チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで
toshihiro ichitani
 
第7回SIA研究会(例会)プレゼン資料 油野様
第7回SIA研究会(例会)プレゼン資料 油野様第7回SIA研究会(例会)プレゼン資料 油野様
第7回SIA研究会(例会)プレゼン資料 油野様
Tae Yoshida
 
越境する開発 -Seek Right Things-
越境する開発 -Seek Right Things- 越境する開発 -Seek Right Things-
越境する開発 -Seek Right Things-
toshihiro ichitani
 

Similar to Trust Based Development (20)

拝啓、プロダクトオーナー様。
拝啓、プロダクトオーナー様。拝啓、プロダクトオーナー様。
拝啓、プロダクトオーナー様。
 
NGY Goodfind Seminar 2011-12-10
NGY Goodfind Seminar 2011-12-10NGY Goodfind Seminar 2011-12-10
NGY Goodfind Seminar 2011-12-10
 
HEROZ Kishin AIにおけるディープラーニング活用事例のご紹介
HEROZ Kishin AIにおけるディープラーニング活用事例のご紹介HEROZ Kishin AIにおけるディープラーニング活用事例のご紹介
HEROZ Kishin AIにおけるディープラーニング活用事例のご紹介
 
オタクエンジニアを熱くさせる!モチベーションと効率をあげるチームビルディング_20210611_TechDay#1_3
オタクエンジニアを熱くさせる!モチベーションと効率をあげるチームビルディング_20210611_TechDay#1_3オタクエンジニアを熱くさせる!モチベーションと効率をあげるチームビルディング_20210611_TechDay#1_3
オタクエンジニアを熱くさせる!モチベーションと効率をあげるチームビルディング_20210611_TechDay#1_3
 
株式会社ビシィッについて
株式会社ビシィッについて株式会社ビシィッについて
株式会社ビシィッについて
 
自分のハンドルは自分で握れ
自分のハンドルは自分で握れ自分のハンドルは自分で握れ
自分のハンドルは自分で握れ
 
成長請負人(Growth Contractor)プレ講義資料(第2期)
成長請負人(Growth Contractor)プレ講義資料(第2期)成長請負人(Growth Contractor)プレ講義資料(第2期)
成長請負人(Growth Contractor)プレ講義資料(第2期)
 
価値のデザイン
価値のデザイン価値のデザイン
価値のデザイン
 
「価値のデザイン」―2013年7月18日 サーブコープビジネス交流会@虎ノ門 城山トラストタワー
「価値のデザイン」―2013年7月18日 サーブコープビジネス交流会@虎ノ門 城山トラストタワー「価値のデザイン」―2013年7月18日 サーブコープビジネス交流会@虎ノ門 城山トラストタワー
「価値のデザイン」―2013年7月18日 サーブコープビジネス交流会@虎ノ門 城山トラストタワー
 
[Track3-1] ビジネスで役立つAIリテラシーから機械学習エンジニアリングまで実践形式で学ぶ課題解決型AI人材育成とは?〜国内最大AIコンペサイトの...
[Track3-1] ビジネスで役立つAIリテラシーから機械学習エンジニアリングまで実践形式で学ぶ課題解決型AI人材育成とは?〜国内最大AIコンペサイトの...[Track3-1] ビジネスで役立つAIリテラシーから機械学習エンジニアリングまで実践形式で学ぶ課題解決型AI人材育成とは?〜国内最大AIコンペサイトの...
[Track3-1] ビジネスで役立つAIリテラシーから機械学習エンジニアリングまで実践形式で学ぶ課題解決型AI人材育成とは?〜国内最大AIコンペサイトの...
 
Zarc_会社紹介資料_220309時点版
Zarc_会社紹介資料_220309時点版Zarc_会社紹介資料_220309時点版
Zarc_会社紹介資料_220309時点版
 
アジャイルジャーニー
アジャイルジャーニーアジャイルジャーニー
アジャイルジャーニー
 
チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで
チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまでチーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで
チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで
 
Zarc キャリア 採用ピッチ資料_220308時点
Zarc キャリア 採用ピッチ資料_220308時点Zarc キャリア 採用ピッチ資料_220308時点
Zarc キャリア 採用ピッチ資料_220308時点
 
発達障害と起業と継続可能な社会 〜Startup Weekend Kitakyushu vol6.によせて〜 
発達障害と起業と継続可能な社会 〜Startup Weekend Kitakyushu vol6.によせて〜 発達障害と起業と継続可能な社会 〜Startup Weekend Kitakyushu vol6.によせて〜 
発達障害と起業と継続可能な社会 〜Startup Weekend Kitakyushu vol6.によせて〜 
 
Dev sami 120727_slideshare
Dev sami 120727_slideshareDev sami 120727_slideshare
Dev sami 120727_slideshare
 
AI-OCR 導入最前線 (AI inside)
AI-OCR 導入最前線 (AI inside)AI-OCR 導入最前線 (AI inside)
AI-OCR 導入最前線 (AI inside)
 
第7回SIA研究会(例会)プレゼン資料 油野様
第7回SIA研究会(例会)プレゼン資料 油野様第7回SIA研究会(例会)プレゼン資料 油野様
第7回SIA研究会(例会)プレゼン資料 油野様
 
本当にそのオフィスいりますか?全社員がリモートで働く幸せな働き方革命
本当にそのオフィスいりますか?全社員がリモートで働く幸せな働き方革命本当にそのオフィスいりますか?全社員がリモートで働く幸せな働き方革命
本当にそのオフィスいりますか?全社員がリモートで働く幸せな働き方革命
 
越境する開発 -Seek Right Things-
越境する開発 -Seek Right Things- 越境する開発 -Seek Right Things-
越境する開発 -Seek Right Things-
 

More from toshihiro ichitani

More from toshihiro ichitani (20)

アジャイル開発は世界を変える夢を見るか
アジャイル開発は世界を変える夢を見るかアジャイル開発は世界を変える夢を見るか
アジャイル開発は世界を変える夢を見るか
 
ナラティブ・プロトタイピング
ナラティブ・プロトタイピングナラティブ・プロトタイピング
ナラティブ・プロトタイピング
 
組織にアジャイルの構造を作る
組織にアジャイルの構造を作る組織にアジャイルの構造を作る
組織にアジャイルの構造を作る
 
組織でアジャイルの ”回転” を繋ぐ
 組織でアジャイルの ”回転” を繋ぐ 組織でアジャイルの ”回転” を繋ぐ
組織でアジャイルの ”回転” を繋ぐ
 
組織アジャイルをはじめる
組織アジャイルをはじめる組織アジャイルをはじめる
組織アジャイルをはじめる
 
デジタルトランスフォーメーション・ジャーニー・デッキ
デジタルトランスフォーメーション・ジャーニー・デッキデジタルトランスフォーメーション・ジャーニー・デッキ
デジタルトランスフォーメーション・ジャーニー・デッキ
 
Digitaltransformation Journey
Digitaltransformation JourneyDigitaltransformation Journey
Digitaltransformation Journey
 
Agile again
Agile againAgile again
Agile again
 
伝統的な組織で始めるアジャイル
伝統的な組織で始めるアジャイル伝統的な組織で始めるアジャイル
伝統的な組織で始めるアジャイル
 
アジャイルブリゲード 〜対立する二項を組織の構造と仕組みによって繋ぐ〜
アジャイルブリゲード 〜対立する二項を組織の構造と仕組みによって繋ぐ〜アジャイルブリゲード 〜対立する二項を組織の構造と仕組みによって繋ぐ〜
アジャイルブリゲード 〜対立する二項を組織の構造と仕組みによって繋ぐ〜
 
私がのこすだろうたった1つの言葉
私がのこすだろうたった1つの言葉私がのこすだろうたった1つの言葉
私がのこすだろうたった1つの言葉
 
13年かけたら、言えること
13年かけたら、言えること13年かけたら、言えること
13年かけたら、言えること
 
正しいものをともに考え、正しくともにつくる
正しいものをともに考え、正しくともにつくる正しいものをともに考え、正しくともにつくる
正しいものをともに考え、正しくともにつくる
 
チーム・ジャーニー・デッキ
チーム・ジャーニー・デッキチーム・ジャーニー・デッキ
チーム・ジャーニー・デッキ
 
ISHII SPRINT
ISHII SPRINTISHII SPRINT
ISHII SPRINT
 
ともに考え、ともにつくる 〜リーン・ジャーニー・スタイル〜
ともに考え、ともにつくる 〜リーン・ジャーニー・スタイル〜 ともに考え、ともにつくる 〜リーン・ジャーニー・スタイル〜
ともに考え、ともにつくる 〜リーン・ジャーニー・スタイル〜
 
正しいものを正しくつくるへ至る道
正しいものを正しくつくるへ至る道正しいものを正しくつくるへ至る道
正しいものを正しくつくるへ至る道
 
プロダクト開発を繋げる
プロダクト開発を繋げるプロダクト開発を繋げる
プロダクト開発を繋げる
 
見えないものを見ようとして僕らは何をのぞきこむか
見えないものを見ようとして僕らは何をのぞきこむか見えないものを見ようとして僕らは何をのぞきこむか
見えないものを見ようとして僕らは何をのぞきこむか
 
分からないものを分かるようにする
分からないものを分かるようにする分からないものを分かるようにする
分からないものを分かるようにする
 

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. https://www.slideshare.net/papanda/ss-41638116https://www.slideshare.net/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. どうやって信頼をはぐくむのか? 少しずつ重ねるしかない。 少しずつ仕事をして、お互いの考え⽅や調⼦を把握し、 チューニングし、やれるかどうかを⾒極める。 互いを⾒極める前に、⼤いなる仕事を始めてはいけない。 プロダクトも、関係性も、 インクリメンタルに形作る。