trust based development

Toshihiro Ichitani All Rights Reserved.

Trust Based Development

Ichitani Toshihiro

市⾕聡啓

- リモートワークによるアジャイル開発 -


http://about.me/papanda0806

Ichitani Toshihiro

市⾕聡啓ソフトウェア開発16年SIer→サービス→受託→起業仮説検証とアジャイル開発

ギルドワークス株式会社代表株式会社エナジャイル代表⼀般社団法⼈越境アジャイルアライアンス代表理事 DevLOVE コミュニティファウンダ

0 → 1

http://about.me/papanda0806


スタートアップや事業会社での新規事業、新規サービスの⽴ち上げ事業会社での現場改善、仮説検証コーチゆるやかにデベロッパーのギルドを形成

ギルドワークス

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

Why

What

Copyright (c) 2017 Guild Works Inc.

本⽇のテーマ

リモートワークによるアジャイル開発


ちょっとおさらい

“アジャイルな開発”とは？



“アジャイルな開発”とは？少しずつ反復的に開発を進めることで必要とする⼈から必要なフィードバックを得て調整し続けられる開発



“アジャイルな開発”とは？少しずつ反復的に開発を進めることで必要とする⼈から必要なフィードバックを得て調整し続けられる開発

「インクリメンタル」(少しずつ) 「イテレーティブ」(繰り返し) つまり「早く(少しだけ)形にできる」やり⽅


リリーステスト実装設計

フェーズゲート開発

アジャイルな開発

要件定義

開発されたボリューム

8


https://www.slideshare.net/papanda/ss-41638116https://www.slideshare.net/papanda/ss-79465986

“アジャイル開発”の理解を深める具体的な進め⽅を知る

From do agile To be agile.

https://www.slideshare.net/papanda/ss-41638116

https://www.slideshare.net/papanda/ss-79465986


早く(少しだけ)形にできることの意義フィードバックに基づく調整で、⽬的に適したソフトウェアに仕⽴てられる形にすることで早めに関係者の認識を揃えられるつくるものやチームについての問題に早く気付けるチームの学習効果が⾼い早く始められる結合のリスクを早めに倒せるTime to market が短いサンクコストが⼩さくできる開発チームのリズムを整えられる

①

②③④⑤⑥⑦⑧⑨

10


もうちょっというとプロセスやツールよりも個⼈と対話をビジネス側の⼈と開発者は、プロジェクトを通して⽇々⼀緒に働かなければなりません。情報を伝えるもっとも効率的で効果的な⽅法はフェイス・トゥ・フェイスで話をすることです。


もうちょっというとプロセスやツールよりも個⼈と対話をビジネス側の⼈と開発者は、プロジェクトを通して⽇々⼀緒に働かなければなりません。情報を伝えるもっとも効率的で効果的な⽅法はフェイス・トゥ・フェイスで話をすることです。

これまで通りの解釈ではリモートワークに合わない

(⾃分たちの状況によった解釈が必要)


そもそもリモートワークで必然性あるのか？当然、リモートワークでの開発だからといって、つくるものは容易ではない。というか、昔に⽐べるとますますよくわからないものをつくっている。

早く少しだけ形にすることでつくるべきものが何か理解できる


① ツールコミュニケーションが中⼼ ② 何をつくるべきかの統制を記述に頼りがち ③ あいまいさが混乱を招く。責任分界点が求められる ④ …ということやっていくと、⾃ずと硬めの計画的になる

物理的に離れた分散開発の場合

プロダクトオーナー

開発チーム

プロダクトオーナー代⾏兼マネジメント A拠点デザイナー

B拠点プログラマー C拠点プログラマー

スクラムイベント

委託契約委託契約

委託契約

UserStory Base


① ツールコミュニケーションが中⼼ ② 何をつくるべきかの統制を記述に頼りがち ③ あいまいさが混乱を招く。責任分界点が求められる ④ …ということやっていくと、⾃ずと硬めの計画的になる



① ツールコミュニケーションが中⼼ ② 何をつくるべきかの統制を記述に頼りがち ③ あいまいさが混乱を招く。責任分界点が求められる ④ …ということやっていくと、⾃ずと硬めの計画的になる ⑤ “いつもの(同席の)感じ”でいると品質は落ちる ⑥ むちゃくちゃマネジメントも⼯数かかる



リモートワーク開発、やばい？！

① ツールコミュニケーションが中⼼ ② 何をつくるべきかの統制を記述に頼りがち ③ あいまいさが混乱を招く。責任分界点が求められる ④ …ということやっていくと、⾃ずと硬めの計画的になる ⑤ “いつもの(同席の)感じ”でいると品質は落ちる ⑥ むちゃくちゃマネジメントも⼯数かかる



Cost

Delivery Scope

Quality

よくある”アジャイル開発”の教え

QCDは固定なのでSで調整しよう

リモートワーク開発に移⾏して

最初にやられるパターンC

DQ S

機能の仕様を⽐較的細かく事前に

決めておかないとQもCもDもずれる！

Sも固定する。(あれ？）

次にもめるパターン

C

D Q S

Sが決めきれないので、時間契約

しよう！(=コストで調整)

現実的にはDがコミットできない


3年間の実地検証による学び

離れているからこそ、いつ仕事をするかなんて当⼈次第。

時間契約でないならば、結果の測り⽅は成果主義。

① やり⽅がプロなら、成果もプロ。

② 信頼がおける、お互いの価値観。

リモートワークによる(アジャイルな)開発にある ”フォース”

離れているからこそ、いちいち疑⼼暗⻤にならなくて済む

ように、仕事に対するあり⽅が共通認識化されていること。


① やり⽅がプロなら、成果もプロ。(1) アウトプットではなく、アウトカムに対する対価。

機能(アウトプット)ではなく、⽬標達成の度合い(アウトカム)を

ベースに対価を決めるイメージ。

ある達成に対して、どの程度の対価でやるかを握って進める。

ある仕事をするのに、どの程度時間をつぎ込むかは⾃分次第。

想定よりも物理的な時間がかかることもあるし、少なく済むこともある。

もちろん、やってみないと分からないこともある。想定の度を

越える場合は、期間やお⾦、スコープなどで調整をかける。


① やり⽅がプロなら、成果もプロ。(2) バッファマネジメントで期間を守る。

「プロとして、仕事をやりきる」スタンスでも、⼀番ネックに

なりがちなのは ”スケジュール”。

リモートワークは、同席に⽐べると、認識やコミュニケーション

のオーバーヘッドは必ずある。それは、期間に響いてくる。

期間のコミットを守るためには、”バッファ”のマネジメントが

必須。プランニングでの腕の⾒せ所。


Cost

Delivery Scope

Quality

“アウトカムベース”をQCDSで表現したイメージQCDSすべて固定的。バッファと確率の問題で捉える。

Cost、Scopeは、許容量と現実的な発⽣確率でどの程度リスクの

重さがあるか判断する。

依頼側のリスク

受ける側のリスク期間バッファ

バッファとリスクの組み⽅の例。実際に、どこにバッファを張り、

どこでリスクを捉えるかは

ケースに応じて変わる。

ポートフォリオで判断する。どれか⼀つではなく、複合的に組み合わ

せてヘッジする。どれが⼀つが突出して

しまうと⼀⼈Loseの確度が⾼まり

バランスに⽋ける。


② 信頼がおける、お互いの価値観(3) プロジェクトを越えた共通のミッション。

仕事を⼀緒にする者同⼠として、守りたい、到達したい

ミッションを共通化しておく。

ギルドワークスで⾔えば「正しいものを正しくつくる」。

ギルドワークスだけではなく、ギルド的開発チームの共通の

ミッションに置く。

共通ミッションを醸成するのは、プロジェクト始まってから

では準備不⾜。プロジェクト外で、⾔語化、認識を深める。


② 信頼がおける、お互いの価値観(4) ここぞという時はやっぱり結集する。

⽇常コミュニケーションのメインが、オンライン通話、チャット

だとしても、ここぞいうときは集まることを厭わない

主な”ここぞ”は、仕事をはじめるとき、問題が起きているとき、

ピンチのとき、仕事を終えてお祝いするとき。⼀同で集まる。

“同席”のために、合宿を⾏なう。たいていコスパは割に合う。

もしコストが⾼すぎる、つまり想定以上に頻繁に”同席”が

求められるのであれば、やり⽅に問題があるか、リモートワーク

向きのプロジェクトではないのかもしれない。


① やり⽅がプロなら、成果もプロ。(1) アウトプットではなく、アウトカムに対する対価。

(2) バッファマネジメントで期間を守る。

② 信頼がおける、お互いの価値観(3) プロジェクトを越えた共通のミッション。

(4) ここぞという時はやっぱり結集する。

根底にあるのは、互いへの ”信頼”互いの信頼が無いと、アウトカムベースの握り⽅は

不確か過ぎて、お互いとして出来ない。


共にしている時間

取引コストリモートワーク

同席開発

相⼿に依頼し内容を

理解してもらったり

履⾏してもらうため

に要するコスト

リモートワーク、同席開発


共にしている時間

取引コストリモートワーク

同席開発

相⼿に依頼し内容を

理解してもらったり

履⾏してもらうため

に要するコストプロジェクトを越えた共通のミッション

ここぞいうときは結集

Trust Based Development

「安⼼社会から信頼社会へ」(⼭岸俊男)によると、みんなが同じ環境にいるという安⼼感から⽣まれた安定性に基づく=「安⼼社会」独⽴した個々⼈が、相互に尊重し合う関係=「信頼社会」という分類ができ、物理的に場所が離れるというリモートワークでは「信頼社会」の考え⽅が合致すると⾔える

TBD


どうやって信頼をはぐくむのか？

少しずつ重ねるしかない。少しずつ仕事をして、お互いの考え⽅や調⼦を把握し、チューニングし、やれるかどうかを⾒極める。互いを⾒極める前に、⼤いなる仕事を始めてはいけない。

プロダクトも、関係性も、インクリメンタルに形作る。

trust based development

Software