建築分野とIT分野のウォーターフォール

はじめに

IT分野で開発モデルというと、ウォーターフォールやアジャイルなどがあります。
このテックブログの中の人的にウォーターフォールがダメだと思っているわけではないのですが、ウォーターフォールを成功させるのは難しいと考えているのが本音です。
この話をしたとき、中の人が建築分野の人間だったことがあるので「建築分野とかではウォーターフォールなのに、なぜIT分野ではうまくいかないと考えているのか」と聞かれたことがあります。
建築分野がなぜウォーターフォールなのか、なぜウォーターフォールで進められるのか…
それを踏まえて、なぜIT分野でウォーターフォールを成功させるのは難しいと考えているのか、どのような開発モデルを採用するのがよいのか…
本稿では、そのような話をしようかと思います。

建築分野のウォーターフォール

建築分野ではほぼウォーターフォールで開発が進みます。
建築でも施主の要望を聞いて、意匠設計、設備設計、構造設計を行い、設計に従って施工をするという、IT分野のような要件定義・設計・実装の流れで、大まかな流れは同じです。
ウォーターフォール自体が土木・建築の開発をスムーズに進めるために生まれた開発モデルなので、当たり前といえば当たり前なのですが…
でも、なぜ建築分野ではウォーターフォールなのでしょうか？
一番大きな理由は簡単には戻せないことにあるかと思います。施工の段階で、建物の安全性に関わる部分の設計に問題があるとなった場合、すでに施工が完了した基礎などをなかったことにするのは大変です。やり直しをするために相応のコストが掛かりますので、設計をしっかり行って、建築確認申請の審査で設計が建築基準法などに適合しているかをチェックした上で、その設計のとおりに施工を進めましょうとなっているわけです。

建築分野の工程が戻らない工夫

では、なぜ建築分野では工程があまり戻らないのか？(絶対戻らないというわけではない…)
建築基準法や建築学会などの指針・基準に従って設計している、建築資材として実験を繰り返して十分な強度が担保されたものを使用しているなどなど、理由はたくさんあるかと思いますが、あまり自分が詳しくない部分について話すと、建築分野の諸先輩方に怒られそうなので…自分が知っている構造設計における「あらかじめの検討」について話そうかと思います。
構造設計とは、建物自体の荷重や地震・土・風・雪などで発生する荷重に対して、十分な強度を確保するための設計です。(あとは床のたわみが大きすぎないかとか、建物の壊れ方に問題がないかとか…)
そのため、構造設計したとおりに施工すれば、当然、十分な強度は確保できるはずです。しかし、実際はそう簡単ではありません。なぜなら、施工には誤差がつきものだからです…特に杭の打設は誤差なく行うことが難しく、かつ、この施工誤差は建物の力の流れ(応力)への影響も小さくありません。杭の打設で誤差が生じてから構造設計を再度行い、建築確認申請をするとなると、その間、施工もストップしてしまいます。
では、どうするか？
そこで登場するのが構造設計における「あらかじめの検討」です。
「あらかじめの検討」にはいくつか種類がありますが、ここでは杭の施工誤差についてお話しします。
この「あらかじめの検討」の考え方自体は単純で、施工誤差が生じても大丈夫なように、構造設計時にあらかじめ検討しておけば、施工誤差が生じても、構造設計し直して、再度、建築確認申請をしなくてもよいというものです。
いろんな方向への施工誤差がありえるので、結構大変ではあるのですが…(特に計算プログラムをつくる人が…)
大変ですが…施工がはじまってから構造設計し直して、再度、建築確認申請をし、施工もストップさせるというコストを考えれば、ずっとマシです。
このように、建築分野でも工程が戻らない工夫はしています。

IT分野のウォーターフォールとその他の開発モデル

さて、IT分野に話を戻しましょう。
IT分野でも開発モデルとして、ウォーターフォールはよく採用されます。
ウォーターフォールのメリットは要件がしっかりしていて、技術的な不明点がなければ、工数を正確に見積もることができ、段階的に作業を進めることができるので、管理もしやすいことにあります。
逆にウォーターフォールのデメリットとして、要件・仕様の変更に対する費用と時間が大きくなることが挙げられます。
つまり、要件がしっかりしていて、技術的な不明点がないようなプロジェクトでは、ウォーターフォールが適していると言えます。
ですが、これがウォーターフォール開発を成功させるのが難しいと私が考えている理由でもあります。要件がしっかりしていて、技術的な不明点がないようなIT分野のプロジェクト…ありますかね………
では、どうするか？
ウォーターフォールの改良型としてプロトタイプという開発モデルがあります。
これは建築分野の工程が戻らない工夫として紹介した「あらかじめの検討」に考え方が似ています。
要件があいまいで、技術的な不明点もあるのであれば、小さいアプリを試作してあらかじめ検討しておけばよいわけです。試作を元に要件をしっかりと固め、技術的な不明点がない状態にできれば、あとはウォーターフォールと同様に開発を進められます。
ただし、これにもデメリットはあります。単純に本番のアプリをつくるのとは別に試作品をつくらなければならないので、プログラマーの負担はかなり大きくなります。
ではでは、どうするか？
建築分野とIT分野の違いに着目してみましょう。
建築分野とIT分野で違う点はたくさんありますが、自分が特に違うと感じるのはバージョン管理アプリ(Gitなど)によって、実装したコードを簡単に戻せることです。
一度実装したコードをなかったことにするのは、プログラマーとしてはつらいですが、戻すだけならコストはほとんど掛かりません。
であれば、プロトタイプのようにあらかじめ試作品をつくって検討するのではなく、本番のアプリの開発の要件定義・設計・実装・テストを繰り返していく中で、要件を固めて、技術的な不明点を解消していく開発モデルであるアジャイルを採用するのがよいと考えることができます。
もちろん、アジャイルにもデメリットはあります。
それはリリースまでの工数がプロジェクトのスタート時点ではわからないことです。
しかしながら、工数がわからないというのは、要件があいまいで、技術的な不明点がある状態でのウォーターフォールでも同じことです。無理にリリースまでの工数を出したところで、確実にズレます。大体は工数が拡大する方向で大きく…
別にアジャイルでプロジェクトをスタートしたら、リリースまでずっとアジャイルでやらなければならないということでもないので、リリースまでの見通しがつかない状態であれば、アジャイルでプロジェクトをスタートして、リリースまでの見通しがついてきたら、ウォーターフォール的な進め方に切り替えるというのもありです。これなら、プロジェクトのスタート時点で工数がわからなかったとしても、プロジェクトの途中からはそれなりの精度の工数を出すことができます。

まとめ

以上が建築分野のウォーターフォールとIT分野のウォーターフォール、そして、その他の開発モデルについての紹介と所感となります。
結局は、「常にウォーターフォールが正解」、「常にアジャイルが正解」というのではなく、プロジェクトの目的・状況によって、それに適した開発モデルを採用すべきということになります。
まぁ…それが大変なのですが………

参考文献

この記事は以下の情報・書籍を参考にして執筆しました。

• ウォーターフォールとアジャイルとプロトタイプの違い図解
• 建築行政情報センター「2011年版建築構造審査・検査要領 -確認審査等に関する指針 運用解説編- 」7.2.2 施工の関係上やむを得ず発生する可能性の高い変更事項への対応方法があらかじめ検討されている場合の留意点に対する検討