Trust Based Development

Trust Based Development - リモートワークによるアジャイル開発 - Ichitani Toshihiro Toshihiro Ichitani All Rights Reserved. 市⾕聡啓

Ichitani Toshihiro 市⾕聡啓 ギルドワークス株式会社 代表 株式会社 エナジャイル 代表 ⼀般社団法⼈ 越境アジャイルアライアンス代表理事 DevLOVE コミュニティ ファウンダ ソフトウェア開発16年 SIer→サービス→受託→起業 仮説検証とアジャイル開発 0→1 http://about.me/papanda0806 Toshihiro Ichitani All Rights Reserved.

• http://about.me/papanda0806

ギルドワークス Why 「正しいものを正しくつくる」 What スタートアップや事業会社での新規事業、 新規サービスの⽴ち上げ 事業会社での現場改善、仮説検証コーチ ゆるやかにデベロッパーのギルドを形成 Toshihiro Ichitani All Rights Reserved.

本⽇のテーマ リモートワークによるアジャイル開発 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

From do agile To be agile. “アジャイル開発”の理解を深める https://www.slideshare.net/papanda/ss-79465986 具体的な進め⽅を知る https://www.slideshare.net/papanda/ss-41638116 Copyright (c) 2017 Guild Works Inc.

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

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

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

もうちょっというと プロセスやツールよりも個⼈と対話を ビジネス側の⼈と開発者は、プロジェクトを通して ⽇々⼀緒に働かなければなりません。 情報を伝えるもっとも効率的で効果的な⽅法は フェイス・トゥ・フェイスで話をすることです。 これまで通りの解釈では リモートワークに合わない (⾃分たちの状況によった解釈が必要) Copyright (c) 2017 Guild Works Inc.

そもそもリモートワークで必然性あるのか？ 当然、リモートワークでの開発だからといって、つくる ものは容易ではない。というか、昔に⽐べるとますます よくわからないものをつくっている。 早く少しだけ形にすることで つくるべきものが何か理解で きる Copyright (c) 2017 Guild Works Inc.

物理的に離れた分散開発の場合 ① ツールコミュニケーションが中⼼ ② 何をつくるべきかの統制を記述に頼りがち ③ あいまいさが混乱を招く。責任分界点が求められる ④ …ということやっていくと、⾃ずと硬めの計画的になる プロダクトオーナー代⾏ 兼マネジメント A拠点デザイナー 委託契約 スクラムイベント UserStory Base プロダクトオーナー B拠点プログラマー 委託契約 Copyright (c) 2017 Guild Works Inc. C拠点プログラマー 委託契約 開発チーム

物理的に離れた分散開発の場合 ① ツールコミュニケーションが中⼼ ② 何をつくるべきかの統制を記述に頼りがち ③ あいまいさが混乱を招く。責任分界点が求められる ④ …ということやっていくと、⾃ずと硬めの計画的になる Copyright (c) 2017 Guild Works Inc.

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

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

よくある”アジャイル開発”の教え Cost リモートワーク開発に移⾏して 最初にやられるパターン C Quality Delivery Scope QCDは固定なのでSで調整しよう D 次にもめるパターン C Q 機能の仕様を⽐較的細かく事前に 決めておかないとQもCもDもずれる！ Sも固定する。(あれ？） Sが決めきれないので、時間契約 しよう！(=コストで調整) D Q S 現実的にはDがコミットできない S 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.

“アウトカムベース”をQCDSで表現したイメージ QCDSすべて固定的。バッファと確率の問題で捉える。 Cost、Scopeは、許容量と現実的な発⽣確率でどの程度リスクの 重さがあるか判断する。 Cost 依頼側のリスク バッファとリスクの組み⽅の例。 ポートフォリオで判断する。 実際に、どこにバッファを張り、 どれか⼀つではなく、複合的に組み合わ どこでリスクを捉えるかは ケースに応じて変わる。 Delivery 期間バッファ せてヘッジする。どれが⼀つが突出して しまうと⼀⼈Loseの確度が⾼まり Quality バランスに⽋ける。 Scope 受ける側のリスク 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.

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