アジャイルと請負契約

ござ先輩が興味深いエントリーを書いていました。
アジャイルって受託開発との相性が最悪な気がする - GoTheDistance
ちょうどそんな感じの問題にぶち当たっているので、私も書いてみよう。

アジャイルを採用する上でのメリット/デメリット

顧客側(システムを使って利益を生み出す側)にとって、
動きもしない自然言語で記述された設計書について
あーだこーだと会議をされるより、
実際に動くものを見ながら話をした方がゴールが見えやすく
認識違い、コミュニケーションロスも早めに討ち取れるので
メリットは大きいです。絶対。
開発側も仕事してるぜってアピールにもなるし。
長い時間かけて作ったシステムを納品前に初めて見せて、
「これは何の冗談?」と言われることもなくなるでしょう。


ただ、作ってないものに関してはリスクの先送りになるので、
作り始めてから問題点に気づくのは手遅れになります。
なので、アジャイルとは言え、全体的に何をすべきなのかを押さえた上で
イテレーションの計画をしなければならない。
(システムが満たすべきユースケースくらいは決めないといけないと思います)
また、システム全体の共通的な振る舞い
(DB更新前に入力確認画面を出す、ログを出力するタイミング等)も
ある程度実装してから合わせるのは余計な工数がかかってしまうので、
その辺を押える必要があります。
また、データソースとなりうる外部システムや
データ連携方法・タイミングもある程度押えておかないと
想定と違った場合、痛い目に合います。
早い段階で他システムと疎結合になるポイントを
見極めることが重要になるでしょう。
また、早めに見せることで、要望が膨らんで、
あれもやりたい、これもやりたいと機能が増えてしまうこともあります。
全体のスケジュールとシステムが満たすべきゴールと新たな要望を鑑みて
その中で収まるようにするように顧客側と調整できないと、
良い様に機能を追加されることになるので
交渉力のあるヒトも必要です。


早く動くものを見せる(またはリリース)ことができる点で、
早期にゴールの共有ができることがメリットなのですが、
実装を意識しつつシステム全体を把握し、
リスクを早めに洗い出せるヒトがいないと
うまく回りません。
ただ、この辺はウォーターフォールを採用しても必要なヒトであるので、
開発方法云々というレベルではないでしょう。

いざ実践

これは受託開発でもいわゆるSESでも問題ないと思います。
もう「やり用」の一言に尽きると思います。
顧客側、開発側が一緒になってゴールを共有できる関係であれば
後はテクニカル、マネージメントスキルを駆使すればで何とかなるでしょう。
開発側が下請けに投げてピンハネしようなんて思わなければできるはずです。


アジャイルで何が重要かって、プログラミング能力でなく、
コミュニケーション能力だと思うんです。
お互い不足している情報を補完しあうことが重要。
で、受身でなくゴールを目指してアグレッシブに提案、実装できるスキルを持つ人が
顧客側、開発側両方に多く揃えられれば成功する可能性が限りなく高まります。

利益を出す為に

受託側も企業ですので利益を出さなければなりません。

通常の請負契約の見積であれば、
機能実現/成果物作成にかかる想定の工数 + 粗利
になるはずです。
ここで、想定の工数には
要件がぶれそうだ、とか、難易度高そうだからとかの理由で
リスクが多かれ少なかれ乗せられます。


見積もり時のリスク > 実際発生したリスク
であれば、丸々受託側の利益になります。
請負契約は成果について契約する為、
実際にどのくらい工数がかかったかというのは
開発側の裁量に委ねられる訳です。
約束した成果が出せればそれでいい。
ただ、成果が出るまでは、赤字になっても
やり遂げなければならない。
うまく行けばウハウハですが、失敗すると
企業自体が傾くこともあるわけです。
ハイリスク・ハイリターン。


対して委任契約(人貸し)の場合は、単純に
(人月単価 + 粗利)×人数×契約期間
となり、人月単価に乗せた粗利しか利益になりません。
その契約で行った人がどんなに頑張って生産性を上げても、
利益にはなりません。
むしろ、残業しまくって超過分の費用を貰えた方が
企業によっては利益になります。
ただ、成果に対する責任を負う必要が無いので、
最悪プロジェクト全体のスケジュールに間に合わなくても
契約的にはお咎めなし。
ローリスク・ローリターン。


アジャイルでやる場合の契約

顧客側ではRFPが無い(作れない or 作る時間が無い)
でも、早く動くものが見たい
となった時に最近では「じゃあアジャイルだ」となると思うのですが。


ちょっと待って下さい。


契約はどうしましょう。
請負契約でしょうか、委任契約でしょうか。


委任契約の場合は簡単です。
人を貸し出すだけですから。
でも、粗利は少ない。頑張って成果を出しても
売上げには結びつかない。
現場はともかく、経営者の観点からだと粗利が稼げないのは
嬉しくない訳です。
評価されて契約期間の延長はメリットかもしれませんが、
それだけできる人なら他の案件でもやって欲しい。
委任契約では、有能な人を張り付かせなければならず、
他の仕事をやらせるわけにもいかないですからね。


じゃあ、請負契約でしょうか。
さて、RFPもないのに、成果を約束できるのでしょうか。
アジャイルでの請負契約となると、リスクが積み切れない。
RFPがあって、明らかな変更依頼に対しては
追加工数を請求することもできますが、
「なんとなくこんな感じ」を元に見積もったものは
見積の精度も怪しいものです。
「ある程度の変更を見越して」見積もれるはずもありません。
下手をすると、「受けたモン負け」で、あいまいな仕様の名の下に
ずるずると開発をすることになりかねません。
それも追加工数無しで。


顧客側と開発側がうまく行っている時は何の問題も無いはずです。
うまくいっている間はあらかたのことは飲んでくれるでしょう。
「こんなもんでいいですか」「いいですよ」
が通じる。
ただ、開発側の成果が思ったより出ていない、とか
要求に対して「それはちょっと無理です」的な話になった時に
関係が悪化し始めます。
この状態に持っていくことは簡単で、
そこから良好な関係に持っていくのはとても難しい。
そうなった時に、自分を守ってくれるのは、契約なわけなのですが・・・。

他に良い契約は無いか?

InfoQにこんな記事がありました。
アジャイル・ソフトウェア開発における契約

・固定利益方式
なんかはとても興味深いですが、請負契約で粗利を稼ごうとしている
日本のSIerには支持されないかもしれません。


受託開発は、案件の注残ビジネスです。
受注した案件を注残にして、システムを開発し、納品して、
お客様より検収を頂いて売上げになります。
だから、受注金額が不安定なものは売上金額の予定も立てづらい。

疲れたのでまとめ

RFPが出て、それを元に見積もる場合、
見積の拠り所が明確なわけです。
この場合は請負契約で、プロジェクトはアジャイルでも良いと思います。


予算は決まってて、その中でできる機能を詰め込みたい時の見積が難しい。
顧客側、開発側がお互いWin-Winの関係になることを考えながら
進めないとこじれること間違いなし。


顧客側のリスクをSIerが被って、それを利益にするビジネスモデルが
「普通」だと思えている間は、契約を変えるのは難しいかもしれませんね。
SIerに負わせているリスクを顧客側が「無駄」だと思わなければ
変わらないでしょう。
自分達で使うシステムですよ?自分達で何とかしたくありませんかね?
「やっぱ内製でしょ」って思うのです。