請負契約がソフトウェア開発者を苦しめている
IT業界で仕事していて、何故かデスマーチプロジェクトに数年に1回はぶち当たる。
デスマーチに陥る原因は技術力の不足やプロジェクト管理の能力不足などがあるけれども、IT業界で一般的な請負契約そのものに根本原因があるような気がしている。
請負契約が日本のソフトウェア開発者を苦しめているのではないかという仮説について考えたことをラフなメモ書き。
新しい契約形態での受託開発サービス「価値創造契約」 | 永和システムマネジメント
「価値創造契約」と「納品のない受託開発」そして二人の男の運命~アジャイルジャパンの見どころ - Social Change!
再見積もり、Velocity、そしてアジャイルな契約: プログラマの思索
【1】日本の受託ソフトウェア開発の契約スタイルは、委託契約と請負契約の2種類がある。
WF型開発では、工程単位で委託契約と請負契約を分けて開発する。
見積りのタイミングは、システム提案完了時と外部設計完了時の2回がある。
システム提案時は顧客の要望を聞き出して概算見積りを行い、顧客とSIの双方で大きな隔たりが無いことを確認するのを目的とする。
普通は、システム提案から外部設計が完了するまでは委託契約を結び、少数精鋭のSEチームで要件から仕様を詰めていく。
理由は、開発対象の範囲が確定していないので、見積りが大きく変る可能性があるから。だから労働時間単位の契約を結んで、早めに再見積を行うための外部設計を行う。
そして、外部設計で仕様を詰めて開発範囲を決定後に再見積もりを行い、その再見積もりの結果を元に請負契約を結ぶ。
請負契約の期間は、内部設計、開発、単体テスト、結合テストまでが普通だろう。
特に顧客は請負契約をSIと結びたがる。
何故なら、開発したシステムの瑕疵担保の責任の所在を明確にして、もし瑕疵があればSIに責任をとってもらいたいからだ。
そのためにも外部設計後の再見積もりはとても重要な指標になる。
そして、システムテストや受入テストでは委任契約になり、リリース後は保守契約に進んでいく。
SIの受託開発の基本的なビジネスモデルは、1次開発は赤字になっても、その後の運用保守や2次開発で黒字化して定期的にお金が入ってくる仕掛けを作ること。
日本のSIもクラウドに対応しようとしているが、所詮はプライベートクラウドであり、自分たちが作ったデータセンターにあるシステムが稼働している間、顧客から定期的にサービス利用料としてお金をもらう仕組みにすり替わってる。
【2】だが、請負契約が主体の受託開発はとてもリスキーな気がしている。
請負契約では、開発者は成果物の完成責任を負う。
だから、自分たちが作ったプログラムでバグが見つかれば、そのバグが直るまで、最後まで見届ける責任がある。
そのために、開発者がどれだけ苦労していることか。
単体テスト、結合テスト、システムテストとテスト工程が進むと共に、開発者の責任は大きくなっていく。
請負契約に成果物の完成責任はビジネス上、責任を明確にする意味では当たり前だが、ソフトウェア開発では、開発者に対する成果物の無限責任にすり替わっている点に問題があると思う。
ソフトウェアはバグをゼロにするのは至難の業なのに、バグが出る度に残業して休日出勤して徹夜で作業しなければならない。
バグ修正しても、逆にデグレードしたり、別のバグを埋め込んだりするから、いくらやってもキリがない。
開発者が成果物の完成責任を果たそうと頑張るほど、逆に無限責任となり、無限地獄に陥る。
【3】請負契約のビジネスモデルでは、動員力がモノを言う。
開発からテストに至る工程で、大量の開発者を短期間にかき集めて、システムを作り上げる。
WF型開発では、プログラミングを「製造」という工程で呼ぶが、それはまさに工場の生産ラインでプログラムを大量生産していることを連想させる。
そして、テストが終わり、リリース直前にかき集めた大量の開発者を切り、システム開発を収束させていく。
何故、そのようなビジネスモデルになるのかという理由は、WF型開発では、要員の変動があまりにも大きい点にあるからだと思う。
外部設計で確定した機能を元に、リリースまでの短期間にどれだけ開発者の頭数が必要か見積もりする。
この時の要員表を作るのがマネージャの一番の仕事だ。
要員表はコスト管理に直結するため、自社で不足したリソースを外部から調達する手段をとるのが普通。
だから、大手SIは動員力に物を言わして、下請けのSIからたくさんの開発者を集めてもらう。
大手SIは外部調達能力に優れているからこそ、短期間に大量の人員を動員することができる。
大手SIは資金力があるからこそ、リソースの大きな変動に耐えれるわけだし、逆に中小SIは、下請けの仕事を常にかき集めなければ生きていけない。
でも、開発者から見れば、苦痛なことこの上ない。
何故なら、現場には入ればいきなり内部設計や開発を任されて、その後のテストでバグ出ししていかないといけない。そして、テストが追われば、自分の首が切られることを知っている。
開発者は、開発現場を渡り歩くジプシーや流れ板みたいな存在。
最近の日本のソフトウェア開発では、オフショア開発をうまく利用して、動員力を更に柔軟にしようとする姿勢が見られる。
日本国内で開発するよりもオフショアの方が1/5のコストで済むならば、プロジェクト管理能力さえあれば受託開発をコントロールするのはそう難しくない。
そのビジネスモデルは日本のソフトウェア開発の技術力を貶めている。
【4】請負契約の受託開発には、「成果物の完成責任が無限責任にすり替わっている」点や「リソースの変動が大きいために動員力が必要」な点という特徴が見られる。
その特徴は、アジャイル開発とは無縁な開発スタイルだ。
アジャイル開発では、顧客同席やプロダクトオーナーという概念によって、成果物の責任が開発者から減るような仕組みがあると思われる。
実際、顧客はどの機能をリリースするか決定する権限を持つが故に、どの機能を先に作るべきか、という決断の責任も持つ。
もしリリース後に、リリースした機能が本来の価値を生み出していなければ、それは開発者の責任だけでなく、リリースすると決定した顧客にも責任の一端はある。
だから、成果物の責任の一端を顧客は担っていると言える。
つまり、開発者の責任は減っている。
また、アジャイルなチームは結束力が高く、イテレーション単位に開発していくから、リソースの変動は殆どないと言っていい。
2~4週間のサイクルでリリースしていくには、いきなり新規の開発者を大量動員してもたかが知れているし、逆に新規の開発者に色々説明するために時間を取られて、逆にチームの生産能力が落ちてしまうからだ。
【5】請負契約は開発者にとってたくさんの不利な点がある。
アジャイル開発の契約では、開発者にとって不利な従来の請負契約ではなく、開発者の責任を減らして顧客にもシステム開発の責任の一端を取ってもらうような契約スタイルに変化していると言える。
平鍋さんの会社の「価値創造契約」や倉貫さんの「納品の無い受託開発」は、僕は詳細は知らない。
でも、その契約の背後には、開発者が本来の能力を発揮できるような環境を作るための契約である気がする。
その契約で本当にビジネスとして成り立つのか、そしてビジネスモデルとして請負契約を駆逐していくのか、正直分からない。
でも、従来の請負契約が日本のソフトウェア開発者を苦しめているのは事実だ。
色々考えてみる。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
- プロセス設計はどの範囲を指すのか?~プロマネの仕事はテーラリングにある(2022.06.19)
「ビジネス・歴史・経営・法律」カテゴリの記事
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- 農林水産業はITと相性がいい(2023.01.09)
- 過学習に陥った人間や社会の事例は何があるのか(2023.01.09)
- 経営戦略とIT戦略をつなぐ鍵は何なのか(2023.01.04)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
「ソフトウェア工学」カテゴリの記事
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- プロジェクト管理やソフトウェアアーキテクチャの問題の背後にはトレードオフが隠れているのではないか(2023.02.18)
- デブサミ2023の感想(2023.02.11)
- ChatGPTにEclipseでEclEmmaとJaCoCoからカバレッジを出力する方法を聞いた(2023.02.01)
- DDPは品質管理に役立つのか(2022.12.13)
「Agile」カテゴリの記事
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
- DDPは品質管理に役立つのか(2022.12.13)
- UMTPモデリングフォーラムのパネル討論の感想(2022.11.29)
- XPエクストリームプログラミングは偉大だ~時代がその設計思想に追いついた(2022.11.16)
コメント