リスクからは逃れられない、ブーメランのように戻ってくる。だからアジャイルを使え!

2009年11月12日

Risk boomerang | Andy's Mind

先日、アジャイル開発に関係する人たちが「Risk boomerang」という記事をツイッターで話題にしていました。

Andy Brandt氏のブログ「Andy's Mind」にポストされたこの記事は、顧客が契約によってSIerにリスクを押しつけても、結局そのリスクは顧客に返ってくる、ということを説明しています。

SIerにリスクを投げたつもりでも、顧客に返ってくる

Risk boomerang」からポイントをいくつか引用します。

The single biggest risk anyone faces when they build something is that this something won't fit the purpose it was intended for. Causes for this can be numerous: the needs might have been not understood properly or the idea doesn't fit the market, the needs have changed or the thing built can't be used because of defects.

誰にでもあり得る最も大きなリスクとは、何かを開発してもそれが意図したような目的に合致しないことがある、ということです。その理由はいくつもあります。ニーズが的確に理解されていなかったり、考えがマーケットにそぐわなかったり、ニーズが変化したり、障害により使えなかったり。

No matter how hard you try the biggest share of this risk is always on the client's side, because it is the client who won't get expected benefits in the end. You may add as many penalties and harshly sounding clauses to a very fixed and rigid contract as you want, you still won't get away from this risk.

どれだけ頑張ったとしても、結局もっとも大きなリスクはいつもクライアントにあります。なぜなら、最終的には期待したものが得られないからです。いくら開発側にペナルティを課し、厳しい条項を加えたとしても、(顧客側は)リスクから逃れることはできないのです。

顧客は契約によってリスクをSIerに付け替えたつもりで、結局のところリスクから逃れることはできない。これがつまり、著者のいう「Risk Boomerang」ということです。

You don't need rigid relationship based on distrust to tame this risk, you need an adaptive relationship with people you trust but can check all the time.

リスクを管理するために不信感による厳しい契約を結ぶのではなく、信頼関係とつねに状況を確認できるような関係を築くことが必要でしょう。

リスクを管理するには、契約ではなく開発者との信頼関係が必要だと著者は書いています。

That's exactly what agile offers: tight control of the product being developed in short inspect&adapt cycles. Instead of trying to write clever penalty clauses and waste time on lawyers clients can closely monitor the progress of the team(s) that build their software.

これこそまさにアジャイルが提供するものだ。製品が順調に開発されているかを短いサイクルできちんと管理する。SIerにペナルティを課そうと弁護士と無駄な時間を費やす代わりに、ソフトウェア開発チームが進捗しているかを間近で確認するべきだ。

アジャイル開発の関係者がこの記事を話題にする気持ちがよく分かると思います。

以前Publickeyの記事「「納期を半分にしてくれ、金なら出す」」では、

発注側のかけるコスト(工数)の限界が、ソフトウェア開発における速度の限界点なのだ。

という発言を紹介しました。顧客側が積極的に開発に協力することこそ、ソフトウェア開発のプロジェクトを成功させる重要な要素だ、ということですね。

とはいえ顧客とSIerの契約は大事だ

10 Contracts for your next Agile Software Project | Agile Software Development

契約より信頼関係が大事だとしても、開発にあたり顧客とSIerが契約をしないわけにはいきません。では、人月契約に代わる、アジャイル開発にふさわしい顧客とSIerの契約とはどういうものなのでしょうか? これはなかなか解決しにくい問題です。Agile Software Development.comの記事「10 Contracts for your next Agile Software Project」では、表題通りにアジャイル開発のための契約例を10パターン紹介しています。

  • Sprint Contract
  • Fixed Price / Fixed Scope
  • Time and Materials
  • Time and Materials with Fixed Scope and a Cost Ceiling
  • Time and Materials with Variable Scope and Cost Ceiling
  • Phased Development
  • Bonus / PenaltyClauses
  • Fixed Profit
  • Money for Nothing, Changes for Free
  • Joint Ventures

この記事はクリエイティブコモンズライセンスが設定されているので、翻訳して紹介しようと思ったら、すでに「翻訳 - 次のアジャイルソフトウェアプロジェクトに使える10の契約」という素晴らしい日本語訳がありました。今後のSIerビジネスを考える上でも、一読に値する記事だと思います。

あわせて読みたい

DevOps アジャイル開発




タグクラウド

クラウド
AWS / Azure / Google Cloud
クラウドネイティブ / サーバレス
クラウドのシェア / クラウドの障害

コンテナ型仮想化

プログラミング言語
JavaScript / Java / .NET
WebAssembly / Web標準
開発ツール / テスト・品質

アジャイル開発 / スクラム / DevOps

データベース / 機械学習・AI
RDB / NoSQL

ネットワーク / セキュリティ
HTTP / QUIC

OS / Windows / Linux / 仮想化
サーバ / ストレージ / ハードウェア

ITエンジニアの給与・年収 / 働き方

殿堂入り / おもしろ / 編集後記

全てのタグを見る

Blogger in Chief

photo of jniino

Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。
詳しいプロフィール

Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed

最新記事10本