アジャイルと請負契約、あるいは古のユーザー企業とSIerとデベロッパーの関わり方

---

■TL;DR

• アジャイルのSIでも、POの役割・責務を条件にすることで、発注者責任と完成責任がうまくバランスとれるんじゃないか?(※答えはまだ無い;)

---

■今までのSI:

• ウォーターフォール。ゼネコンスタイルによるヒエラルキーがゆえの高額見積もり
  • 実態は、発注者責任の放棄→発注者・受注者お互いの保険料がものすごく上乗せされている(コレ、本当にビックリするやつある。70画面くらいで4億とか)
• →結局
  • 丸投げ
  • 稚拙な表現力で書いたドキュメントによるバケツリレー
  • 超絶なムダ、コミュニケーションロス、デメリットばかり

---

■最近のヤバいSI:

• 発注者責任置いてけぼりの「早い・安い・旨い」的な請負い契約。なぜかアジャイル
  • バズワード駆動、発注者、元請営業のあさはかな都合の良い「いいとこどり」で始まりがち
  • そもそもウォータフォールでやればいいのにってケース
    • SoR領域、現行ありき多い
  • そもそもアジャイル初めてとか。。(しかも、発注者側も受注者側のチームメンバー両方とか、ありえんし;)
• →結果
  • プラハラ(プライム(または上位)コントラクター・ハラスメント)
  • カスハラ(カスタマー・ハラスメント)
  • チームは疲弊するばかり。チームの幸福 is何?

---

■そろそろ、、:

• 内製アジャイルと外注アジャイルについて向き合った方がいい
  • アジャイル・スクラムの原理・原則だけでは、外注アジャイル(日本のゼネコンスタイル)は無理ゲー
    • DEVが派遣や委託だと、ミッションに対するエンゲージメント低すぎるよ(あたりまえだけど)
      • これもそもそも問題なのだけど、すぐに打開できない；
      • チームもずっと維持できない
    • SIerはオワコン? 知ってるよ。ずっと前から言われてるの

---

■それに、、:

• ユーザ部門のPOは、技術的負債などについて理解しにくい
  • 教科書では"How"についてはチームに任せることになっているけど、バックログの優先順位付けに関わるので、責任を持つことからは逃れられない
    • たとえば、技術的負債の優先順位を下げまくると、生産性や保守性が下がって、デリバリの速度が落ちるってこと
• 最近、うまくいってる or いきそうなプロジェクトは、ダブルPO
  • ビジネス価値領域(ユーザ部門)のPO ... プロダクトのビジネス価値に責任をもつ
  • システム価値領域(情シス)のPO ... プロダクトの技術的価値(アーキテクチャ、保守性や運用性など)に責任を持つ

---

■請負契約によるアジャイル開発は、、:

• 結局のところ、"Do Agile"。現実的にみて、ちゃんと"Do Agile"できるようにすればいいんじゃないか?
  • ※内製は"Be Agile"で取り組めばいいと思うけど。。
• 受注者側の"完成責任"以前に"発注者責任"を発注者側のダブルPOがうまく請うことができるような契約条件にできないか?