Help us understand the problem. What is going on with this article?

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

More than 1 year has passed since last update.

■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がうまく請うことができるような契約条件にできないか?
su-te-mi
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away