ウォーターフォール考察
■実はIT業界だけじゃない
ウォーターフォールと聞くと、工場や建設でも同じような事やってたぞ。と思う。建設だと、「要求定義」でどんな建物を建てるかを決める。「設計」を行って、大工さんが建てる。工場でも、新製品を作る時は、ライン作業の流れをウォーターフォールで組み立ててた。最初に「要件定義」をして、工作機の配置、人員の配置を設計する。試験運用を経て実運用を行う。
そもそも、ウォーターフォール・モデルとはソフトウェアの開発モデルだ。しかし基本はありきたりな方法のように思う。結構メジャーなやり方なので、「大規模な事をやろうとしたらこういう風にやるよね。」って雰囲気でこういう方法を取ってるのかもしれない。
■この方法でうまくいかないのはIT業界くらいなものだ
最近、このウォーターフォール・モデルはうまくいかないやり方の代名詞ようにIT業界で使われているように感じる。実際に不思議なのが、IT業界に限ってウォーターフォール・モデルでうまくいかない事が多いのだ。
建築や工場ラインの立ち上げにウォーターフォール・モデルという言葉を使うのが適切かはよく分らないが、やり方の流れは似たようなものだ。にもかかわらず、IT業界での失敗の規模や頻度は桁が違う。IT業界にいい加減な人間が多いのかと言うとそうでもない。どの業界にも、平等にいい加減な人間は存在する。
■他業界と決定的に違うもの
ITと建築、工場ラインの違いとは何か考えてみた。自分なりに行き着いたのは、「ITって、冒険色が強い」という答えだ。少なくとも私の経験した建築や工場ラインというのは、意外としっかりした検証がなされていた。
一方、ITではどうだろう。未知の技術をいきなり使うようなケースも多い。しかも、十分な検証をせずに「エイ！ヤ！」でどうにかしなければならないケースも多い。特性上、仕事のやり方にバクチ的な要素が高くなり易い。新しい手法や技術がどんどん出てくるので、どうしてもそうなると思う。
■バクチ的要素との付き合い方
ITの業務というのは理論で組み立てれば計画的に業務ができると思われている。なのでウォーターフォール・モデルがよく取り入れられるのだろう。しかし、実際は予測可能な要素が少ないと私は考える。十分な時間があれば予測可能だが、割り当てられた時間が少ないので予測ができない。変則的なやり方を押し通されて予測できなくなる。現実的にそういう実例を多く見てきた。そこをもっと認めていったらどうだろう。
気付くか気付かないか。これだけで作業時間が大幅に変動する。優秀な人が集まっても、たまたま気付かなかったというだけで、大きく工数が増えるというのはよくある。農業でいる不作、豊作みたいなものだ。動けば動いただけ成果が出るというものではない。それだけ不確定要素が多いので、ウォーター・フォールのモデルでうまくいかせるのは難しいと考えている。
■相対的価値への値段
現状、成果物と利益のバランスを取るのは難しい。ITの成果物は一発で完成品ができることが少ない。使い始めてからでないと出来がいいのか悪いのか判断がつかない。お金を払って手に入るものが完成品という感覚になれた現代人にとって、価値のつけ方が難しい。
ウォーターフォールの手法より、お金を払って手に入るのが完成品。という感覚を変えていく方がうまくいくんじゃないだろうか。投資と同じで、払ったものが直接結果に結びつくとは限らない。そういう感覚じゃないと、失敗した時に引き返すという発想はできない。
結論として、ウォーター・フォールだろうと良いものは作れる。しかし、それに見合った対価を得るのが難しい。そう考える。良いものを作るより、成果物への適切な対価を判断することの方が難しいのかもしれない。
コメント
たしかに、建築や工場のラインではウォーター・フォールでちゃんとやってますよね。失敗すると発注した部品が無駄になっちゃうからしっかり計画することが定着しているのでしょうか。
それに対してIT業界は計画が失敗しても人海戦術だけで取り返しが可能なので、ウォーター・フォールの上流工程が冒険色が強くなってしまうのかもしれませんね。
Anubis
>>abekkan さん
コメントありがとうございます。
私のイメージでは、きちんと計画できる人がいた。という状況でした。
IT系の人海戦術については・・・。私の経験では、取り返しがついた事例が無かったりします（笑）ただ、ご指摘の通り、人海戦術で何とかしようとする空気は確かにありました。
としろう
実際やってみないと判らない事も少なくないので仕方が無い面も有ると思う。
しかし、ウォーター・フォールを悪く言うのは言いすぎでも有ると思う。
実際の所、アジャイルではないのに
要件定義が客の怠慢で決まらないのにエンドと予算枠が決まっていて見切り発車
製作中に仕様が結構変わるだけではなく、
テスト・検証段階になって客がアレが無い、コレが出来ないを言う。
こういう案件も少なくないのはいただけない。
それを見れば、先に作りたい物がかなりハッキリして次に進む
ウォーター・フォールの部分は理に適っていると思う。
※だから仕様固めまではウォーター・フォールでいいと思う
仕様固めで矛盾や価値の有無も判断出来、システム作成の是非が判断出来る
100%綺麗に欲しい物が判ってからという事は逆に非効率だとしても
90%～95%位で骨組みは決めてから、機能の優先順位などもね。
対価の問題はまた別ですねえ。
khaosG
単に、ウォーター・フォールを実現できる人が少ないだけでは？
大抵のSIベンダーが作成した上流工程のドキュメントは使えない。
また、下流工程では、仕様の変更をはね付けることができていない。
そりゃあ、火も噴くよね。
mmmr
古きよき時代ではウォーター・フォールでよかったのではないでしょうか。
それは単に人間が紙に記入する実績データ等の内容を例えばホストコンピュ
ータの画面に入力するようになるだけの単純な場合が多かった。
そしてホストコンピュータで出来ることはたかが知れていた。
大抵の場合は、それはできませんね。ということで済ませれた。
そのころと今とではシステム機能の内容の次元が違っているのだと思います。
しかし、開発スタイルとしてはウォーター・フォールしか知らない管理者が
指揮をとる。
ちゃんと用件分析して、ちゃんと機能定義して、ちゃんと画面、ＤＢ設計して
やればちゃんといいシステムができるはずだ。
しかしながら今の時代にシステム構築する場合、そのちゃんとという中身、
深さを開発側も依頼側もちゃんと判っては（把握）いないのではないでしょうか。
従って実際の画面、機能を見れる段になってようやく、ちゃんとの中身が
見え出してくる。
開発側が経験豊富でユーザーの１の発言で１０を創造、想定できる開発者で
あればウォーター・フォールでもそれなりにちゃんと出来る可能性はあるで
しょうが、そういう神様的な開発者はそうはいません。
大抵、システム開発をする側の担当者はその業務システムを作るのが始めて
の場合が多いのです。
依頼側のその業界のこの程度は常識だということがさほど通じません。
依頼側の業界常識が通じないということは、ユーザーの１の発言では１分しか
機能が網羅されないわけです。
最近ではオープン化が進み、システム屋が業務を理解してシステムを作るよりも
ユーザー側がシステム作成、プログラム作成を理解する方がいいものが
できる可能性が高まっているのではないかと思います。
まさにオープン化とはパソコンがあれば誰でもシステム構築できることを
言うのではないでしょうか。
ホストの時代は、ユーザーＩＤとパスワードを取得しなければホストを
触れないという高い壁があったわけです。