アカウント名:
パスワード:
海外や国内いずれにおいても、大規模システム開発には、「初期の開発時期は維持保守の時期に比べて人数が大量に必要」という特性があります。
この特性にフィットするための方法は雇用制度や契約形態のために、国や地域で異なります。
例えば、今回の記事で出てきた国でいうなら、アメリカ:開発時期に要員を雇用・実費償還契約し開発完了後は維持保守の要員を残して解雇・契約終了本邦:保険機構、人材派遣業、商社機能を兼ねたSIerを元請けとして一括請負契約し元請けが多段下請け構造に投げていくという違いが出ます。
アメリカなどで、アジャイルのいわゆる「チーム内顧客」や「計画ゲーム」が成立するのは、「顧客が雇用した専門家が顧客側の意志決定者として存在しうる」、「実費償還契約故にやっただけコストがかかるため、顧客側がどこまでやり込むかを決定する動機がある」といった、契約の特性に由来する事情があるからです。
本邦で、パッケージやインハウスの開発以外の、大規模システムでアジャイルが成立し得ないのは、「顧客側の意志決定者が基本的に素人」(大体は管理、よくても維持・保守程度の要員であるため開発経験が薄い)、「チーム内顧客が法的に不可能」(一括請負契約でそれをした場合、厳密には「顧客→元請け」も「元請け→下請け」も偽装請負)「一括請負で全てのリスクを受注者が既に負っているため、顧客側に自分でリスクを制御する動機が薄い」といった、同じく契約の特性に由来するもので、本邦で「アジャイルで自社以外の案件の開発」を売りにしているSIerはどこも一括請負契約以外の契約形態を併せて提案しているのもそのためです。
また、本邦で繰り返しのないウォーターフォールが主流であるのも、「工程ごとに契約を分割することで一括契約のリスクを軽減している」(工程が逆流するとリスク軽減効果が減少する)、「工程ごとに下請けへの発注を行うことで人員数を制御しコストを制御する」(工程が逆流するとコスト制御効果が減少する)等々の契約の特性に由来しています。
おそらく、グッケンハイマー氏はアメリカの雇用・契約形態を前提に語っており、筆者の方はそこを読み取れていなかったという話ですね。
アメリカの一部でのアジャイルにせよ、本邦の繰り返しのないウォーターフォールにせよ、流行り廃りや技術の高低ではなく、雇用・契約形態という容易に変えがたい制約条件があるなかで、「制約条件から自動的に導き出された最適解」であるので、制約が変わらないかぎりは、本邦の大規模システム開発でアジャイルが用いられたりはしないでしょうね。
※その他、本邦SIerにおける多重下請け構造や「顧客にいち早く価値を届けるよりも瑕疵がないことを重視」といった 方向性も同様に雇用・契約形態に由来するものですが、それはまた別の話。
>チーム内で意思決定して顧客側はステークホルダーとして扱うだけだよ。
チーム内に意思決定権者(=顧客)がいなくて何を持ってチームが「決定」できると言うのか…。
#つうかステークホルダーの味、分かってる?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人はmoriwaka -- Anonymous Coward
雇用・契約形態が全て (スコア:1)
海外や国内いずれにおいても、大規模システム開発には、
「初期の開発時期は維持保守の時期に比べて人数が大量に必要」という特性があります。
この特性にフィットするための方法は雇用制度や契約形態のために、国や地域で異なります。
例えば、今回の記事で出てきた国でいうなら、
アメリカ:開発時期に要員を雇用・実費償還契約し開発完了後は維持保守の要員を残して解雇・契約終了
本邦:保険機構、人材派遣業、商社機能を兼ねたSIerを元請けとして一括請負契約し元請けが多段下請け構造に投げていく
という違いが出ます。
アメリカなどで、アジャイルのいわゆる「チーム内顧客」や「計画ゲーム」が成立するのは、
「顧客が雇用した専門家が顧客側の意志決定者として存在しうる」、
「実費償還契約故にやっただけコストがかかるため、顧客側がどこまでやり込むかを決定する動機がある」
といった、契約の特性に由来する事情があるからです。
本邦で、パッケージやインハウスの開発以外の、大規模システムでアジャイルが成立し得ないのは、
「顧客側の意志決定者が基本的に素人」(大体は管理、よくても維持・保守程度の要員であるため開発経験が薄い)、
「チーム内顧客が法的に不可能」(一括請負契約でそれをした場合、厳密には「顧客→元請け」も「元請け→下請け」も偽装請負)
「一括請負で全てのリスクを受注者が既に負っているため、顧客側に自分でリスクを制御する動機が薄い」
といった、同じく契約の特性に由来するもので、
本邦で「アジャイルで自社以外の案件の開発」を売りにしているSIerはどこも一括請負契約以外の契約形態を
併せて提案しているのもそのためです。
また、本邦で繰り返しのないウォーターフォールが主流であるのも、
「工程ごとに契約を分割することで一括契約のリスクを軽減している」(工程が逆流するとリスク軽減効果が減少する)、
「工程ごとに下請けへの発注を行うことで人員数を制御しコストを制御する」(工程が逆流するとコスト制御効果が減少する)
等々の契約の特性に由来しています。
おそらく、グッケンハイマー氏はアメリカの雇用・契約形態を前提に語っており、
筆者の方はそこを読み取れていなかったという話ですね。
アメリカの一部でのアジャイルにせよ、本邦の繰り返しのないウォーターフォールにせよ、
流行り廃りや技術の高低ではなく、雇用・契約形態という容易に変えがたい制約条件があるなかで、
「制約条件から自動的に導き出された最適解」
であるので、制約が変わらないかぎりは、
本邦の大規模システム開発でアジャイルが用いられたりはしないでしょうね。
※その他、本邦SIerにおける多重下請け構造や「顧客にいち早く価値を届けるよりも瑕疵がないことを重視」といった
方向性も同様に雇用・契約形態に由来するものですが、それはまた別の話。
Re: (スコア:0)
> 自分たちの「習慣・現状」に新しい考えを合わせるのか、新しい考えに合わせて「習慣・現状」を変えるのか。私は「習慣・現状」を変える方が本質だと思う。
と、元の記事が言うようにその制約を変えるべきなんだろうけどね。
現状の契約でうまくいっている様に品質で帳尻を合わせている事の多さに気づくべき。
契約で言えば外注プロジェクトだとプロジェクト完成までといった単位で起用されることもあるけど、内需では長期的に複数のプロジェクトで起用されることもある。
海外でもx年間で完成させるという一括請負で失敗していたし、国内でも1年の約束でも内々では3ヶ月更新とかざらだし国や地域に限られるというのは疑問。
「チーム内顧客」の成立うんぬん言っているけど、チーム内で意思決定して顧客側はステークホルダーとして扱うだけだよ。
Re: (スコア:0)
>チーム内で意思決定して顧客側はステークホルダーとして扱うだけだよ。
チーム内に意思決定権者(=顧客)がいなくて何を持ってチームが「決定」できると言うのか…。
#つうかステークホルダーの味、分かってる?