ITの開発手法を旅行に例えるとこうなる

ITの開発手法であるウォーターフォールモデル、スパイラルモデル、アジャイル開発手法を旅行に例えるとこうなります。

ウォーターフォールモデル:

「何時何分の電車に乗る」「何時からの講演を見る」
と前もって決めて、チケットも時間指定で取っておくやり方。
修学旅行みたいに統率が重要で、絶対に予定の変更がない状況では有効だが、
万一予定に変更が生じるとチケットを買い直すなど大きなコストが発生する。
計画に過剰な時間が取られるのもデメリット。
情報産業ではかなり古いやり方。

 

スパイラルモデル:

旅行先とそこでしたいことを前もって決めるが、
チケットはその場で買う。
「昨日はこうで、今日はこうしたいから、このチケットを買おう」
みたいに計画と振り返りのプロセスを繰り返す。
これなら想定外の予定変更にも対応できるし、
大まかな予定は決まっているので人が多めでも成り立つ。

 

アジャイル開発手法:

したいことを達成することを最優先とし、
予定に固執せず、気のしれた少人数で素早く出かける。
予定など変わって当然だから、
旅の途中で密な連携と旅行ノウハウを発揮し、
素早く意思決定をすれば良いという考え方。
ただし、人数が増えると難しくなる。

 

上から下の順で新しい開発手法になる。
そもそも新しい手法が出た理由は、
古い手法に重大な欠点があったからだ。
「予定変更つらい!対応できない!」
「計画や技術資料のために作る書類が多すぎ!進まない!」
という現場の悩みを解消すべく、新たな手法が考案されている。
だから全てのIT企業は、これらを取り入れようとしてみたり、
そうでなくとも注目くらいはすべきだ。
手放しに新しいもの全てを容認することはできないだろうが、
自社の悩みを解決するための実用的なヒントがそこにあるのは間違いないのだから。

もし「新しい事なんか覚えたくない」という理由で
ウォーターフォールに固執する企業があるなら、
そこでは軍隊的な統率ばかりが重んじられていて、
予定変更なんかに対応できなくて、
細かい計画のためにいくつもの形式的な書類を作り続けるような
効率の悪い働き方が行われているのだから、
きっとその企業はすぐ潰れるに違いないよ。

 

あと、開発手法ではないけど これも説明しておきたい。

UML

システムの動きや仕組みを顧客・技術者に分かりやすく伝える書き方の国際規格のこと。
これは旅行より建築に例えたほうが良いと思う。
つまり、家の図面の書き方の規格だ。
誰もがバラバラな方法で書いたら混乱してしまう。
顧客や他社と連携をとるために、規格が重要なのだ。
もしUMLを使っていない企業がいたら、
そいつは他社との連携がとれず、
鎖国のごとく孤立しているだろう。

 

補足:

ウォーターフォールをディスったように見えるかもしれないが、
必ずしもウォーターフォールは悪ではない。
修学旅行の例もそうだし、
航空や医療など命に関わるシステムのように、
計画にバカ長い時間をかけるのが大事なケースだってある。
良くないのは、1つの手法に固執することだ。
場合によって使い分けれるのが一番良い。

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト /  変更 )

Google フォト

Google アカウントを使ってコメントしています。 ログアウト /  変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト /  変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト /  変更 )

%s と連携中