パスワードを忘れた? アカウント作成
245497 story
プログラミング

「ウォーターフォール開発」、本当に日本でうまく行っているのか? 97

ストーリー by hylom
日本的、ということだろうか 部門より

Unkown 曰く、

「Continuous Delivery」というソフトウェア開発に関する書籍の著者、Jez Humble氏によりますと、多くの日本IT企業は大規模ソフトウェア開発プロジェクトでウォーターフォール(Waterfall)な開発手法を取っているのですが、この開発手法は世界中で多くの失敗を引き起こしているにも関わらず、日本ではなぜかうまく行っているそうです(Humble氏のブログ記事)。

/.J諸兄方の職場では、ウォーターフォール開発手法で本当にうまく行っていますか? また、今使っている開発手法は何ですか?

これは、7月21日に行われたAgile Conference Tokyo 2010でのトークセッションで話題にされたそうで、参加者のレポートTwitter実況などによると、Humble氏は日本の開発工程に「バグフィックス工程」がないことに驚いたらしい。頻繁なテストやコーディング段階での修正が品質に寄与しているそうだが、Humble氏はそれでも「アジャイル開発のほうが安く、簡単に高品質を確保できる」と主張した模様。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • そりゃぁ、発注元と開発者が共同作業で作り上げようとなったらアジャイル最高でしょ。

    でも、この国だと子受け孫受けまでいって共同作業とか実質不可能。
    完全に仕様が決まって落ちてくるウォーターフォール以外にコンセンサス取れんだろ。
  • 水が流れるというより (スコア:4, おもしろおかしい)

    by Cellea (37481) on 2010年08月11日 21時25分 (#1808476) 日記

    水が流れるというより、「覆水、盆にかえらず」を体現しちゃってる開発が多い気がする

  • ウォーターフォールならウォーターフォールで通してくれるならいい。
    最初にきちんと仕様を決めて、最後までそれで通すなら。

    現実には、制作がほぼ終わった頃や最悪の場合はリリース近くになってから
    仕様変更→制作→検証を繰り返すという、
    泥沼アジャイルとでも言うべき状態になることが珍しくない。
    こういう状況は「ウォーターフォールがうまくいってる」とは言えないでしょう。

    発注側が、下請けがそう簡単に要望を断れないことが分かった上で
    最初にFIXした予算のままで仕様変更をゴリ押しで通すためのプランニング、
    それが日本のウォーターフォールだな、と思います。

    --
    --------------------
    /* SHADOWFIRE */
  • 私の実体験のみに基づいた感覚です。
    うまく行った、というより、試験に合格するため点数だけ積み上げた、というのに近いと思う。
    あの有名な絵(タイヤのブランコのやつ。「顧客の説明」とか「営業の約束」とかのアレです)のとおりで、
    元からして過不足がある、いびつなシステムしか作れていないのでは無いかと思う。

    その点、最終的な顧客満足を得るまで何度も調整を繰り返すアジャイルとは
    目指すゴール自体が違うのかな、とも思う。

    • by Anonymous Coward on 2010年08月12日 8時19分 (#1808603)
      最近、特に経営関係を中心に勉強すればするほど思うのは、ITで「コスト削減のみ」を重視するのは、実は駄目な方針だということ。
      ITの本質は「パターン化された」「大量のデータを」「地理的環境に関係なく」「高速に処理し」「2次・3次加工も容易」という部分をどれだけ「長所として」のばせるか、と言う点だと思う。
      アジャイルもコストが安い、と言う点よりは長所をどのようにのばせるか、が重要。
      コスト削減は2番目か3番目か、4番目か、重要度は落とした方が結果的に会社としては良くなると思う。

      そんな私は、経営とは関係ないシタッパーズ & 今はシステム屋でも無し。
      親コメント
  • RTFA (スコア:3, 参考になる)

    by 90 (35300) on 2010年08月11日 18時26分 (#1808334) 日記

    Agile Tokyo 2010 Continuous Delivery [continuousdelivery.com]

    Indeed, everybody I spoke to confirmed that waterfall worked perfectly well for them as a software development methodology. This was staggering to me, since outside Japan large software projects run with waterfall routinely go over budget and end up with either cuts in scope or poor quality – several recent reports, such as this one [zdnet.com]

    さうんずふぁみりあー?
    うまく行っているというより、プロンプトもどってきた!成功! 的な

  • by Oh-MissSpell (37716) on 2010年08月11日 19時37分 (#1808397) 日記

    開発者は死ぬ

  • by Anonymous Coward on 2010年08月11日 21時23分 (#1808475)

    これってQCサークル活動とかの活動成果報告みたいなもんですよね。
    ・うまく逝った活動のみが報告対象
    ・結果にあわせて問題を再構成

    ・成功報告は常に大成功

    うまくいかなかったプロジェクトってなかったことにして報告しないので、報道されてしまったもの以外基本的に成功したプロジェクトしか人の耳目に入らないハズ。

    うまく行く以外の結論なんて出てこないですよ。

  • 日本式ウォーターフォールがあるなら
    日本式アジャイルがあってもいいじゃないか -> 「アチャ」イルプログラミング

    どちらも本家とはかけ離れ、それぞれの方式の優位をうたう人への反例になるだろうけど。
  • by Anonymous Coward on 2010年08月12日 17時45分 (#1808928)

    ほぼ予定通りに比較的大きな規模のウォーターフォール型プロジェクトが終了した(とされた)例をいくつか見ていますが、下記のような流れでした。

    BI~BDはエンジニアの埒外で実施され、基本的に過去の例の焼き直しに最低限の追加だけで要件が詰められていない。
    FDはさすがに上級エンジニアが作成に参加しているが、不完全なBDを元にしているのでそれに従えばゴールだとは誰も思っていないが口には出さない。
    DDは下請けが納入ドキュメントを作成する(でっち上げる)作業であって製造のための詳細設計ではない。
    Mの段階でも下請けは出来上がるものは見えていないが単体・総合試験項目は決められるので、それを通すことだけを目的に製造する。
    UT、SIは淡々と進めるが、往々にしてこのあたりで客先との会議でBI・BDの不備がいくつか発見(!)されて仕様が追加されるが、残業でなんとかする。
    PT、RTの段階でBD・BI不備が致命的であることが客先との共通認識となり、(末端の人間にとっては)予定通りに緊急事態に陥る。

    ここで大規模プロジェクトが違うのは、まがりなりにもそれなりに能力が高い人間が揃っていること、有害なまでに縦に長い組織になっているが他業務兼任者が少ない、つまりマンパワーに質量ともに潜在的な余裕があるところと末端のメンバーの責任感(というか耐久力というか、とにかく逃げないこと)です。

    この後どうなるかというと客先担当者から末端の製造担当、試験担当、文書作成担当まで現場に横並びになり、ウォーターフォール開発がライン生産方式に変貌します。1日にウォーターフォールを何回転もさせる状況はむしろアジャイルなんじゃないかと思いますが。

    もちろんこれを休日返上、現場に缶詰めで実行したとしても全てが解決するはずもないのですが、交渉によってひとまず客先の受入れ判定をパスできる要件を最低限に引き下げ、優先度が低い開発未完了項目は本番障害として管理され、運用維持として再編された開発チームが引き続き開発を行うということで納められます。

    これで業務としてのプロジェクトが利益を生んだとしても、ウォーターフォール開発の実践例としては最低の部類だと思います。プロジェクト管理としては失敗だらけで、それを末端の個人の努力、しかも原動力は金銭的なインセンティブや忠誠心などといったものではなく、失敗を受け入れない文化と硬直した雇用市場からくる強迫観念といったネガティブな動機で解決した例でしかないからです。

    ただ、こういった展開が期待できるのはある程度の能力、社会的地位、収入がある20代後半の日本人を相手にした場合で、徐々に通用しない場面が増えてきています。これからは恵まれた環境の大企業でもプロジェクト管理を本当にすることが必要となり、管理技術の水準も高める必要性が増してくると思います。

    通常は中小企業よりも大企業の方が先進的な技術、手法の研究や導入に熱心なのですが、日本のIT企業においては逆に大企業こそ旧来の日本の商慣習に則ったビジネスを展開しているのがおもしろいと思います。

  • by Mahiru.Minamino (2542) on 2010年08月10日 22時58分 (#1807891) 日記

    WallfallではなくWaterfallでは?
    元の英文もそうなってますし。

    # タレコミ人の名前もUnknownではなかろうか…ウンコウンでは響きが下品すぎるような

    • Re:Wallfall? (スコア:3, おもしろおかしい)

      by Anonymous Coward on 2010年08月11日 17時47分 (#1808306)
      ドミノ倒しみたいな惨状を表現した名前なんじゃないすか

      「要件漏れがありました」
      ┣¨┣¨┣¨┣¨┣¨┣¨┣¨┣ ...
      親コメント
      • by firewheel (31280) on 2010年08月12日 10時13分 (#1808637)

        ちなみに"domino effect"って単語はあるみたいだね。

        どちらかというと"butterfly effect [wikipedia.org]"という気もするけど。
        #「ウオーターフォール開発では、上流工程のわずかなミスが時間とともに拡大して、
        # 結果に大きな違いをもたらす。そしてそれは予測不可能」

        親コメント
      • 機能要求や変更要求がいつまでたっても止まらないからWaterFallなんじゃないの。 止まるのは予算切れの時、、、しかし瑕疵の責任と称して変更や追加が、、、
    • ウォータースライダー開発(何
      --
      And now for something completely different...
      親コメント
    • by Anonymous Coward

      Waterfallはこっそり直してるみたいだけどうんこはそのままなのでそういう名前の人みたいだな。
      #こっそり直してなかったことにしようとするのはしょうがないか

  • 確かに無い (スコア:1, おもしろおかしい)

    by Anonymous Coward on 2010年08月11日 17時37分 (#1808295)
    手戻りで発生するサービス残業は無いことになっています。
  • 別枝にもありますけど、それ以外が機能しないってのはあると思います。

    あと、業種を別にすれば他の国にもあるとおもうのですが、力技で対応できてしまうパターン(時には良い方向に働くこともある)の一つとして「日本 - IT(?) - ウォーターフォール」という組み合わせがあるのかなと

    まあ、穏やかな時でも発展的とは言いがたく、デスマりやすいですが...

    # 「アメリカ - 小規模決済 - 小切手」とかもかな?
    # 「中国 - 宇宙開発 - 飛ばしたもの勝ち」もか?

    --
    M-FalconSky (暑いか寒い)
    • by Anonymous Coward on 2010年08月11日 20時38分 (#1808443)

      それに加えビジネス的な課題として
      ウォーターフォール以外は
      「スケジュールと予算が組み辛い」
      これが大きい。
      アジャイルは予算面で、スパイラルは進捗説明で難儀する。
      理解ある顧客ばかりではないからね。

      経験的にはプロトタイプ→ウォーターフォールの順での構築が
      いちばん効率がよかった

      親コメント
      • by yasiyasi (5450) on 2010年08月12日 10時49分 (#1808658)

        > 経験的にはプロトタイプ→ウォーターフォールの順での構築がいちばん効率がよかった

         Winston Royce氏が発表した,もともとのウォーターフォール開発に関する論文では,そういう「二度開発することを,あらかじめ予定しておけ。まず試作してから,その知見を踏まえもう一度作り直して,それを納品しよう」と論じていたようですね。
         論文の和訳 [hatena.ne.jp]にある「STEP 3: 2度行う」あたりが,該当するかと。

         いつ,なぜ,この繰り返し開発の考えがスッポリ抜け落ちて,一発勝負の賭けのような危ないものにウォーターフォール方式は化けてしまったんだろう?

         他にも,Always All Ways: [IT] ウォーターフォールの興亡 [pub.ne.jp] も参考になるかも。

        親コメント
      • by ttm (8278) on 2010年08月12日 8時41分 (#1808608)

        あと、日本の場合、顧客側の担当に裁量権がない場合が多いです。
        アメリカでは、顧客側の代表としてちゃんと裁量で判断できる人が出てきますが、
        日本では、エライ人は後ろに控えていて、担当として出てくるのはメッセンジャーボーイ。
        顧客企業の社員ですらないことが往々にしてあります。
        これじゃアジャイルは無理です。

        アジャイルは予算面で、スパイラルは進捗説明で難儀する。
        理解ある顧客ばかりではないからね。

        理解のない顧客と仕事しても、炎上のリスクを抱えるだけで、いいことなんて何もないです。
        景気がよければ他の案件で埋め合わせればいいかもしれませんが、そうはいかないご時世です。
        この景気の悪い時にこそ、顧客を選んで炎上の危険を回避したいものだと思っています。

        親コメント
      • 「ウォーターフォールでは予算が組みやすい」というのは言い過ぎではないかな。
        それは本来なら支払わなければならないはずの,「仕様変更や見積もりミスに伴う
        追加予算」を支払わずに踏み倒しているので、建前では見積もりがしやすいと
        いうことになっているだけ。

        トラブルが発生した時でさえ、残業手当も追加要員の費用も認めないから、
        サービス残業が殺人的なレベルに達したりするし、あまつさえメンバーが鬱病に
        なっても過労死しても金一封さえ出ないよね。
        #原価率600%のプロジェクトとかサービス残業月200時間超(?)とか。

        それらに対する正当な対価をきちんと支払ってたら、「ウォーターフォールは
        予算が組みやすい」なんて、冗談でも言わなくなると思うよ。

        #他に #1808531 の問題もある。当初の設計に問題があっても、予算の変更を避ける
        #ために、問題を修正するよりは問題を放置するほうを選択する。正に本末転倒。

        親コメント
  • スルガ銀行 (スコア:1, 参考になる)

    by Anonymous Coward on 2010年08月11日 18時28分 (#1808338)

    スルガ銀行がIBMを訴えた内容の一部が判明
    http://srad.jp/developers/article.pl?sid=08/04/28/0541220 [srad.jp]

  • みんなバグを見つけると嬉々として報告ないしフィックスするよ。
  • by Anonymous Coward on 2010年08月11日 19時11分 (#1808376)

    いじりまくった一万行のコードでも
    シンプルな100行のコードでも

    同じ品質である、それどころか、前者が生産性が高い

    と言われる、日本のウォーターフォール

  • そりゃなにがなんでもウォーターフォールでやっていれば、成功例も溜まるのでは?
    --
    -- 哀れな日本人専用(sorry Japanese only) --
typodupeerror

皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー

読み込み中...