Scrum Fest Osaka 2021 Day 2
2021/06/26に開催されたScrum Fest Osaka 2021 Day 2のイベントレポートです。
金沢トラックの岡島さんのキーノート成功と失敗に学ぶアジャイル受託開発の極意の内容を・感想を記事化しています。
チーム参加してきました
aslead Agile のチーム「オキザリス」にて参加してきました。
チーム4人で参加して、その場で実況しつつ、記事も作っています。
私は一人で金沢トラックに一日いました。
この記事では、お話をきいたうえで筆者が感じたことをまとめていきたいと思います。
アジャイル受託の定義
ソフトウェア会社による事業として組織的取り組みをしている
契約方式は請負・準委任どちらでも
Scrumなどの特定のフレームワークに縛られない
アジャイル受託開発を始める～請負業者からの脱却
一括で業者・外注として大量に客先に行って仕事を持ち帰ってくる、そんな形態から脱却したいと思った。
一括請負の場合
全要研が揃うわけないのにコミットメントが必要になったり
安い・早い・うまい的な期待があったり
アウトプット＞アウトカムな価値観にしばられがち
アジャイル受託委開発に選ばれがちなプロジェクト
明らかにアジャイル向きでもなく、ウォーターフォール向きでもない。
規模もまぁまぁで、ビジネスルールも複雑だったり、関係者が多かったり。
そんなプロジェクトが選ばれがち。
ふきつなにおいがする
当時は分からなかったけど、あとからふりかえると不吉なにおいが分かる。
リスク回避報～二段階契約
要件定義は準委任として、アウトプットの一つとして規模（金額）を見積もって、開発は一括契約。
フェーズ０（要件定義）のなかで、小さくモノづくりをさせてもらうのがポイント。動作する基盤と最小限のユーザーストーリーを作って、この段階から開発することを認めてもらう。
ここで要件を固めてお互いのリスク回避だけに終わらせず、アジャイルの価値を味わい、理解を深めてもらう。お互いのことを知ってもらう、という努力をするのが大事。
ただ、これは必勝ではない。
そもそも二段階契約に出来ない場合もあるし、
見積もりなんて（不確実性コーンのように）外す。
フェーズ０（要件定義）をやっていたとしても外す。
二度と同じプロジェクトもない。
アジャイルを知ってもらったり、精緻に見積もりする、そこに注力し続けても、「アジャイルになった」という状態ことにたどり着けるのか？
一個一個のプロジェクトが成功しても嬉しいんだっけ？
成功とは？失敗とは？
財務的な指標が期待を下回ると、失敗という扱いになっている。
受託をアジャイルでやったけど、ダメだったという事例がいくつか。
**ただ、これをウォーターフォールでやっていたら成功したのか？**それは分からない。
じゃあ、うまくいったと言われるプロジェクトはどうなのか。
Agile Japan 2019で話した事例では、顧客評価は高くても、チームは危機的状況に陥っていて辛くなっていた。これは成功と言えるのだろうか？
見え方によって成功・失敗というのは変わっていく。
正しいアジャイルへ向かっていくためには？
受発注関係で「これはうまい方向へ行っているね」と思えるのは、
『アジャイルソフトウェア開発宣言』の本質を理解している、向かっている、と私たちとお客様双方が同意できることだと思っている。
「色んな手法を使ってなんとか利益を出すようにした。」
それも大事かもしれない。
でも、それだけではないと思う。
お互い双方が本質を分かることが、請負業者から脱却する1つの考え方なのではないか。
アジャイルの理解度を知ろう
発注側の理解度×受注側の理解度
- 高い×低い＝あかんでしょ
- 高い×高い＝いいかんけい
- 低い×低い＝うそでしょ
- 低い×高い＝えごいすと
エゴイストになっていないか？押し付けになっていないか？
たいがい、お客様にとって初めてのプロジェクトでは「エゴイスト」パターンになっていることが多い。
「アジャイルしたいんだ！」というエゴをすてることも大事なんだ、と強調したい。
なんのためのアジャイルなんだっけ？
お互いアジャイルのことを分かっていれば、何か困ったことが起きても、両者の協力と知恵でなんとかなる。
アジャイル受託の目指すところと本質的な難しさ
発注者・受注者のパートナーシップの元でのアジャイルジャーニーであること。
アジャイル受託開発を続ける～事業として契約する
ここまでの話を、組織として、事業として続けて、拡大していく。
そこが大事だと思う。
平鍋さんのビジョン：ユーザーとベンダーが一体で開発できる場所を提供したい
組織としてどういう形でゴールしたいのか？
受託開発は製品を持っていない会社が多い。
自分たちの組織そのものが「プロダクト」として扱うといいと思う。
アジャイル受託開発とは、組織ビジョン、戦略込みで考える必要がある。
今の流行はプロジェクトマネジメントからプロダクトマネジメント。
プロジェクト（ミクロ）だけでなく組織（マクロ）の視点も入れていく必要がある。
アジャイルパートナーシップジャーニー
お互いのアジャイル度はジャーニー。
発注側のアジャイル度×受注側のアジャイル度のマトリクスで、どのようなジャーニーをしていくのかを描いていくもの。
使い方
真っ白なキャンバスを書いて、右上がゴール。
発注側・受注側のアジャイル度を Ready Agile / Do Agile / Be Agileにステップかして分ける。
このステップを超えるための条件やKPIを設定する。
よく、ここには契約の壁がある。一緒に契約の壁を越えていこう、というKPIを設定することもある。
そして、今どのあたりかというポイントを取っていく。
ジャーニーの例①
最初、お客様のほうがアジャイル度が高く、我々にはアジャイル経験をしたことがある人が少なかった。
今はBe Agileとしてお客様と動けるチームに変わっている。
途中途中では、自分たちがどうなっているのか、というのをコミュニケーションしながらやっていくことには
Ready / Do / Be でのふりかえり
Ready Agileステップでの信頼貯金の積み重ねが大事だった。
ウォーターフォールでも構わないのでやりきる。
発注側にとっても重要なプロジェクトであること。
しんどくても、積み重ねていく。それが大事。
最初のステップは完全なウォーターフォール。
教科書通り？
きちんとスクラムのフレームワークを回すけどうまくいかない。
「あんなものはアジャイルじゃない」とディスられながらもうまくいく。
どちらがいいか？
あらゆる道程のあるジャーニーのなかで、マクロな視点でどう評価できるか、を見ることで、「今回はこれでいこう」という議論ができるようになるはずだ。
ジャーニーの例②
一括請負で、要件も緩やかなプロジェクト。
今は契約の壁も突破していい感じになっているものの、最初はテコ入れをせざるをえないプロジェクトだった。
最初はスクラム熟練メンバーを入れて、なんとかやった。
ミクロで見ると、失敗もあった。
テコ入れをすることで収支は悪化した。
ただ、メンバー追加でチーム状況は改善し、顧客評価は高く終えられた。
視点を上げてマクロ視点になることで、「炎上プロジェクトを終わらす」以上の価値があったという風に気づけた。
プロジェクトを終わらせるだけじゃなくて、長い目で見て「こういう意味があったんだ」と思えるようになる。
プロジェクトを積み上げても事業にはならない
人数のつじつま合わせをするだけで、事業としてうまくいっているように見えても、それは本質ではない。
複数のお客様との関係として、あるべき状態になる。
マクロな視点を持ったうえで判断していくことが大事だと思う。
「顧客が増えてきたから立派な事業だよね」は違う。
お客様との関係性を大事にして、ジャーニーマップを描きながらいくのはとてもいいやり方だと思っている。
アジャイル受託開発に終わりはあるのか？
アジャイル受託開発はよくやられるようになった。
「受託はダメだ」とずっと言われ続けている。
たくさんの会社が「アジャイル受託」にチャレンジしていっている。
これはいつまで続くのか？
開発パートナー（準委任）モデルでのアジャイル受託開発
これまでの請負モデル
契約金額 - 単価 * 人数 = 事業価値
これからの開発パートナーモデル
Σ(k=1 to n)∫(1 to t)nさんの成長度合い = 事業価値
つまり、それぞれが評価（単価）向上のための付加価値付けを続けるしかない。
アジャイル受託開発を終わらせないために
そもそも、n(人数)が多くなければ事業として苦しい。
働く優秀な人が多くないとダメ。
そして、「成長度合い」も大事。
キーワードは透明性、ふりかえり、自己管理、適切な異常。
それを支えるチーム。
マクロ（組織）とミクロ（個人）レベルで両面のマネジメントがさらに重要になっていく。
役割がマネジメント・メンバで分けられるとしたら、やることが大事になってきている。
マネージャーがどんどんチームに委譲して、チームにやっていってもらわないと。
一方、需要とか供給を持ってくるのは、ちゃんとビジョンを持って、マーケティングして、というのが大事になってくる。
アジャイル受託開発のその先
開発パートナーの正常発展形として内製化支援パートナーがある。
内製化支援パートナーは首を絞める？
内製化が進んでいけば、（不合理な）ベンダーロックインも減る。とりあえずこの業者に出しとけ、みたいなのがなくなる。
結果、開発者が支援する伴走型の内製化支援のニーズは高まり、
組織導入の面から支援するアジャイルコーチのニーズも高まる。
内製化支援（ASY×ESM）
PoCやって、本開発やって。
長い道のりのうえ、内製化支援をいっしょにやっている。
アジャイルパートナーシップジャーニーをやってみたら、ぐるぐるする（行きつ戻りつ）図を書いてくれたが、確実に右上の方向に行っていることが分かって、とても有意義だった。
ふりかえってみると、「Ready Agile」での信頼関係を作ったことがとても大事だった。
契約の壁は最初から超えているが、途中で「本当に準委任でいいんだろうか」という議論もあった。
本当にいいものを作るために、一緒に共創していけるチーム。
これが、現時点でのアジャイルパートナーシップジャーニーの一つのゴールだと思っている。
内製化支援時代のアジャイルパートナーシップ
マネージャーとエンジニアが顧客・支援パートナ―側の計4つの領域が出てくる。
コミュニケーションをしっかりとっていかないといけない。
ビジョンは同じでも、お客様のミッション・支援パートナーのミッションは異なってくる。
この溝をコミュニケーションで補って、新しい形でのパートナーシップがうまれてくるんじゃないか。
感想
アジャイル受託開発であるある、というのが多すぎて頷きまくって聞いていました。
内製化支援に行きつく、というその先を示してくれたのがとても素敵でした。
ジャーニーマップを使って「一緒に考える」。Howは現場によって、状況によっても違うでしょうが、一緒に未来を考えていく、のは粘り強く続けていこう、そんな風に決意させられたセッションでした！（森）