ウォーターフォール脳に冒された日経SYSTEMS池上俊也記者はAgileとCloudの隆盛に自己存在意義の危機という悪夢を見たのか？（仮題

お断り: 題名はTweetしにくいように意図的に長くしてあります。

日経ITPro: 「規模見積もり」が消えてしまう？
→クラウドやAgileを活用した「作りながら煮詰めていく」開発の普及で「規模見積もり」という習慣がなくなり

• プロジェクトがコントロール不能に陥る
• 準委任契約が広がる可能性がある

ということを日経SYSTEMS池上俊也記者は懸念している。ちなみに過去にもこの人にケチつけたことあり。

そこで本記事では

• 果たしてそんなことはあるのか？ あったとして問題なのか？
• そもそも規模の見積もりにどれほどの価値があるのか？

を中心に突っ込んでみる。

突っ込み(1) 「規模見積もり」がなくなるとプロジェクトはコントロール不能に陥るか?

規模見積もりの結果である成果物スコープは、工数の算出につながり、それが期間やコストの見積もりのインプットとなる。つまり成果物スコープがないと、プロジェクトの計画値のほぼすべてが根拠の乏しいものになってしまう。計画値がブレれば、プロジェクトのコントロールは困難を極める。

これは「ブレない計画を策定することは可能である」という前提で話をしているよね。IT業界の先人・諸先輩あるいはA級戦犯の皆様方はこの「ブレない計画・ブレない見積り」というピンクのドラゴンのようなものを求めて散々苦労し、数々のデスマーチプロジェクトを生み出してきたわけだ。

見積もりは必ずブレる。なぜなら見積もりは確率分布だからだ。その事実を理解せず、「ブレない見積もり・ブレない計画」の存在を前提としてプロジェクトを進めるから制御不能=デスマーチに陥る確率が高くなるわけでしょ。

むしろ「見積もりはブレる」という前提でプロジェクトを組み立てるAgileのほうが、より現実的な対応が可能になるわけで。ただしこれは「Agileがプロジェクトの成功を約束する」というわけではない。計画が現実離れしていれば、プロジェクトの早い段階でAgileチームは降参するしかない。だがそれは引くに引けないプロジェクト最終段階で刹那的に戦力を追加投入せざるを得ないウォーターフォールのデスマーチよりは余程「よく制御されている」と言えるのではないか。

突っ込み(2) 「規模見積もり」がなくなると準委任契約が広がるのか? 

もう一つの問題は、規模見積もりが実質的に消えることで、準委任契約が広がる可能性があることだ。以前はプロジェクトの上流工程のみに準委任契約が適用され、後工程は請負契約となることが多かった。それが最近は“作っては見直す”というアジャイル開発において、全工程を準委任契約で進めるケースが少なくないようだ。
　準委任契約は、ユーザー企業にプロジェクトのリスクが付くことを意味する。極端に言えば、ベンダーがユーザーに対して「作ってみなければいくらかかるか分からない」と突き付けているようなものだ。ベンダーにとっては事前に規模見積もりをしないだけに、何を作るのかが不透明で、準委任契約をせざるを得ない事情がある。かかった分へのコストが保障される契約なので、ベンダー側が生産性向上施策を積極的に取りづらく、業界発展の妨げにもなりかねない。

準委任契約が増える可能性は否定できない。だが、後半の「かかった分へのコストが保障される契約なので、ベンダー側が生産性向上施策を積極的に取りづらく、業界発展の妨げにもなりかねない」というのは誤りだろう。

Agile的に開発していくからには、例えば一ヶ月とか三週間ごとに成果物を納品していくことになる。その出来具合と契約に基づく価格とを比較して「それはないんじゃない？」と発注側が感じたら、受託側に相談すればいいだけのこと。ウォーターフォールで「こんなはずじゃなかった」と文句を言えるのは早くて数ヶ月、ひどければ一年も二年も待った後なのである。「ベンダー側が生産性向上施策を積極的にとりづらい」のはどちらの手法だろうか？

またウォーターフォールの場合、規模見積もりにゲタを履かせて「かかった分のコストを保障させる」という契約がまかり通ってしまってきたわけだ。これこそSI屋やベンダへの信頼を失わせ業界発展の妨げとなってきた感があるのだが日経SYSTEMSはそのあたりをどう考えているのだろう？


突っ込み(3) そもそも規模の見積もりにどれほどの価値があるのか?
引用記事ではFP法などが紹介されていたけどさ。FP法って自分が社会人になった80年代にはすでに存在していたと記憶しているけど、未だに普及しているとは言い難いよね。自分もかじったことがあるけど、結局は測定者の主観と匙加減でどうにでもなる指標でしかないし、「ブレがない」とは言い難い代物である。しかもわかりにくい。SI屋による人月コスト保障の隠れ蓑にFP法見積もりが悪用されたとしても、お客さんが指摘することは無理でしょ。

仮にFP法が「客観的」で「誰がやっても同じ規模の見積もり」を導出できるとして、それが何になるというのだろう？「このプログラムはFP法で3000ポイントの規模となります」という数字が出た所で、それを「いくらで」「どれくらいの期間で」開発できるのかはまた別の話なわけで。まさか「プログラマAは月間300FPの開発ができる」とか測定するわけにもいくまいし。「秋季情報処理試験・FP能力測定試験」なんて嫌だよね？

そして「規模見積もり」にこだわる人達に決定的に欠けているのは「不具合対応にかかる期間と費用」の概念なんだよね。これから書くソースコードにどれくらいバグが含まれていて、テストでどれくらいの確率で捕捉されて、それらがどれくらいの期間で修正されるのか、なんてのを計画段階で決定できるはずがないのだよ。そこを決定論的に予め計画に組み込もうとするからプロジェクトが制御不能に陥りやすくなるのだけど、ウォーターフォール脳には理解出来ないものなのか。

なぜTPSは日本から生まれたのにAgile開発は米国発なのか？

今回のAgile2011には「文化」というお題目で参加している。それは国民性かもしれないし、企業文化かもしれないし、開発チームの雰囲気かもしれないし、個人の性格かもしれない。だけど、その「文化」がAgile(に限らないけど)開発の成否に影響を及ぼしているのではないか、というのが今回自分が持ち込んだ仮説であり、実際「文化」を取り上げた発表がいくつか散見される。

「文化」を数値的に測る尺度は何種類か発表されているようだけど、これらのいずれを使っても日本の文化ってのは「Agile」にはあまり合ってないのですね。むしろ、米国やカナダなんかは「最初からAgileに向いている」文化に見える。

だからといって「ああ、では日本人にはAgileは無理だ」などという結論に飛ぶのは早い。なぜなら、Agile開発はTPS(Toyota Production Systems)あたりが「ご先祖」とも言える思想なわけだし、Agile開発を産んで育てたアメリカ自身、製造業は古びた大量生産方式から脱却できないでいたわけで。

整理すると

• 日本
• 製造業はAgile的思想を生み出し、受け入れた
• ソフトウェアは旧態依然
• 米国
• 製造業は旧態依然で、空洞化も進行した
• ソフトウェアはAgile開発を生み出し、受け入れた

なんてところかな。では、やはり文化と開発手法は関係ないのか？？

ヒントは昨日聞いた黒岩さんの講演(Basic Principle of the TPS and its Practical Ideas for Agile Software Process)にあるのかもしれない。トヨタが生産方式を見直すきっかけになったのは1950年代に発生した経営危機。いわゆる「ケツに火がついた状態」になると、人々は「文化の壁」を破って真剣に物事を考えるのかもしれない。

「設計」ってなんなのだろ？

Agile 2011三日目、Mary Poppendickおばさんの「Design Thinking」を聴講。あらためて「設計」とはなんなのか、ということを考えさせられた。

発表では下にある動画が紹介されていた。これはPalo AltoのIDEOにおける「ショッピングカート」の再設計の過程を記録したものだが、全部で一週間ちょっとの限られた期間で徐々に完成に近づいていくのがわかる。

講演で強調されていたのは「設計とは要件を満たせばいいものではない。要件を発見発掘するのも設計なのだ」ということ。上の動画でも「従来の大きくて重くて曲がりにくくいショッピングカートを改善したい」という初期の要件から、デッサン・プロトタイプ構築を通じて様々な要件が追加されていく様子がわかる。

また、設計は複数の担当者の「思い」をそれぞれ取り込んでいることにも注意したい。その「思い」が新たな要件を生み、最終形に統合されていく。それらの「思い」は、「買い物をする」という利用者の立場から生まれている。

これは「要件定義」→「設計工程」というウォーターフォールモデルでは実現できない流れであるし、設計者と利用者とが隔離されても生まれてこない設計なのである。

Agile2011

Salt Lake Cityにやってきた。Agile 2011参加。

てかね、日本出張の疲れが抜けてない。ヤバい。

オフショア開発ってなんだったの？（勝手に総括）

今日印象に残った話→「オフショア開発って一体なんだったんだ？」

インドだ中国だベトナムだフィリピンだロシアだ東欧だ等々と言われたけど、詰まるところは「円高差益」でしかなかったのでは、という指摘。つまり、日本円が独歩高になるにつれて相対的に安くなる海外の労働力を「日本は高付加価値の仕事」「通貨の安い国に低付加価値の仕事」という基準で活用していただけではないかと。

で、どこかの時点でそれがいつかはわからないが円安に転じる時に、「通貨の高い国に低付加価値の仕事を出さざるを得なくなって日本の情報産業は競争力マイナスになるよね」という予測。

アメリカでAgile内製やってた人達は、自国通貨がどこかで安くなるという予測をしていたのかどうかは知らないけど、「コア開発は米国でAgile的に内製」という事業構造に転換していた人達は、結果的に自国通貨安で大きな恩恵を受けているのは事実なわけで。

というわけで勝手にオフショア開発を総括すると

オフショアの労働力が安い間はそこに古い技術で外注を出すけど、それで時間を稼いでいる間に自国内で立ち上げるべき高付加価値な事業をできるだけ内製で作れるように体質を改善する

というのが正解だったのかな、と。そうじゃなくてオフショア開発依存症になってしまった人達はよっぽど頑張って体質改善しない限りある日突然通貨安という死刑宣告がやってくるんだね。

ということで総括終了。

雇用体系、労働者の権利、業界の成長...

(諸般の事情により書きなおし)

今回のシアトル訪問はクラウド関係者の集まりへの参加が目的。昨日は準備運動で、今日から本番。

そのクラウド提供事業者の人達と話していて改めて思い出したのは、

• 比較的新しい事業にも関わらず、事業面・技術面それぞれで「プロフェッショナル」を揃えている。
• 各自、自分の守備範囲が明確で、その範囲内ではかなりの裁量を任されている。つまり判断から執行までが早い。
• 人事採用権限は各部門の長がもっている。

等々。

「こういう人材が欲しい！」という要望を各部門は明確に描けるし、それに適合した人を自分たちで探せるというのは素晴らしい。人事部という間接部門(しかも技術や事業の専門家集団とは言えない)を挟まなくていいわけだ。結果として

• 新規事業を立ち上げる助走期間が減る＝機会損失回避
• その事業に不適合な採用を減らせる＝利益率向上

という効果が得られる。反面、成果をあげられなかった人はあっさりと解雇されるかもしれない。また、事業がうまくいかなかったらその部門まるごと畳まれる可能性もある。

そして雇用をささえる仕組みを企業側が持たないというところがミソなわけで。採用したけど仕事に不適合だから別部門に移動してもらってなんだかよく分からない仕事を与えて給与を払い続けるなんてことはない。要は実力に見合った仕事さがして頑張れ、と。

当然、終身雇用なんてのは有り得ないし、大卒即正式採用なんてのは珍しい話になる。若いうちは、トレーニーや下積み前提の雇用で働くことが前提となるかもしれない。結果として、学生からは「不人気業界」という烙印を押される事になる。

だがドットコムバブルの頃のような「売り手市場の雇用」というのは、実力に見合わない給与の人達を業界全体が大量に抱えることになりかねないわけで。実際そのとおりになってしまったので、業界全体がインドなどへのオフショア移転を推進したという面はあるだろう。

でも、そういう「自浄作用」が機能するというのは、米国のソフトウェア業界がまだ健全であることを示しているということでもある。

• 自立の遅れ、利権集団、そして国

私が働いているコンピュータ業界は、個人の能力が重視される。学歴は二の次だ。これこそ、コンピュータ業界が常に革新的で、進化を続ける原動力であろう。窮屈な官僚主義も利権主義のゴマすり連中も、コンピュータ業界の創造性や破壊的想像力を浸食するには至っていない。今のところは、ね。

まさにこの記述のとおりなんだな、と。