請負契約がソフトウェア開発者を苦しめている

IT業界で仕事していて、何故かデスマーチプロジェクトに数年に1回はぶち当たる。
デスマーチに陥る原因は技術力の不足やプロジェクト管理の能力不足などがあるけれども、IT業界で一般的な請負契約そのものに根本原因があるような気がしている。
請負契約が日本のソフトウェア開発者を苦しめているのではないかという仮説について考えたことをラフなメモ書き。

【元ネタ】
Twitter / @akipii: 日本のソフトウェア開発者を苦しめている根源に請負契約があるという仮設を考えてる。平鍋さんや倉貫さんが試しているアジャイルな契約は請負契約のアンチテーゼと考えると分かる気がする。

Twitter / @akipii: @mr_amichan 請負契約の制約条件は開発者の想像以上にソフトウェア開発者に厳しいのです。請負契約である限り本当のアジャイルな開発でないと体験してます。それをうまく説明したい。

Twitter / @sugimoto_kei: @akipii 僕は、成果物コミットなしの契約でずっとシステム開発をしていますが、その場合、お客様の側からみてコミットなしでも安心できるような仕事の枠組みをどう作るがポイントと考えています。これについて書いた文章があります。ご参考になれば→http://t.co/5et4iFiB

Twitter / @akipii: @sugimoto_kei @hiranabeビジネスだからソフトウェア開発者も責任あるけど請負契約にある成果物の完成責任がソフトウェア開発者だけの無限責任にすりかわるのが諸悪の根源と思います。アジャイルな契約では開発者の責任を減らして顧客も分担し責任のリスクを減らしてる気がする

Twitter / @itachidon: おー。そのとおり。RT @akipii: SEの仕事の大半は顧客や社内部署、他チームの調整という名前のコミュニケーション。ネゴシエーション、ハンドリングとも呼ばれる。IT業界でコミュニケーションが重要なのは役職ほど調整能力がいるから。面倒で仕方ない。

Twitter / @hiranabe: RE:請負契約 @akipii @raito3 @MasayukiToyoda IPAでも契約は１つの大きな問題だと捉えている。同じゴールを共有しにくくなる。海外事例の多くは１つの会社の製品（もしくはサービス）開発なので契約の問題を含まない。

Twitter / @hiranabe: @akipii @MasayukiToyoda @raito3 請負の中でもソフトウェア開発者がいきいきと活躍できる場は作れると思って、そのトライがプロジェクトファシリテーションでした。さらに、ブラジルで受託開発の100%アジャイル化を見て、まだぼくらに足りないことがあると知る。

Twitter / @akipii: 請負契約が主流のビジネスは動員力がモノを言う。外部設計までに仕様を固めて開発は請負契約で開発者を大量動員する。テストで最大人数になりリリース直前に一気に減らす。動員力を自社や外部で調達できる会社だけが有効なビジネスモデル。アジャイルと正反対だ。

新しい契約形態での受託開発サービス「価値創造契約」 ｜ 永和システムマネジメント

「価値創造契約」と「納品のない受託開発」そして二人の男の運命～アジャイルジャパンの見どころ - 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】請負契約は開発者にとってたくさんの不利な点がある。
アジャイル開発の契約では、開発者にとって不利な従来の請負契約ではなく、開発者の責任を減らして顧客にもシステム開発の責任の一端を取ってもらうような契約スタイルに変化していると言える。

平鍋さんの会社の「価値創造契約」や倉貫さんの「納品の無い受託開発」は、僕は詳細は知らない。
でも、その契約の背後には、開発者が本来の能力を発揮できるような環境を作るための契約である気がする。
その契約で本当にビジネスとして成り立つのか、そしてビジネスモデルとして請負契約を駆逐していくのか、正直分からない。
でも、従来の請負契約が日本のソフトウェア開発者を苦しめているのは事実だ。

色々考えてみる。