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

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