アジャイルとかウォーターフォールがどうとかはそろそろ止めませんか

2020/03/08

技術者の採用面談で、結構な頻度で聞かれることのひとつに「御社はアジャイルはやってますか」や「Rubyの案件はありますか」というのがあります。
この声を聞く度、エンジニアにとってアジャイルというやり方で仕事ができるのは魅力的なんだろうな、と感じます。
その一方で開発モデルや技術言語にこだわるのも諸刃の件と思います。

ちなみにアジャイルはウォータフォールの課題を克服する形で現れたため、ウォーターフォールは古く、アジャイルは新しいという文脈で語られることが多いようです。それゆえアジャイルは注目される機会が多いのでしょう。

「ウォーターフォールとは」

ソフトウェア工学では非常に古くからあるポピュラーな開発モデル。
開発プロジェクトを時系列に、「要求定義」「外部設計」「内部設計」「開発」「テスト」「運用」などの作業工程にトップダウンで分割する。原則として前工程が完了しないと次工程に進まない事で、前工程の成果物の品質を確保し、前工程への後戻りを最小限にする。

参考：Wikipedia

「アジャイルとは」

ソフトウェア工学において迅速かつ適応的にソフトウェア開発を行う軽量な開発手法群の総称。反復 (イテレーション) と呼ばれる短い期間単位を採用することで、リスクを最小化しようとするもの。アジャイルソフトウェア開発手法とは、一群のソフトウェア開発手法の総体を意味する言葉であり、単一の開発手法を指す言葉ではない。アジャイルソフトウェア開発宣言は、その諸原則を公式に定義したものと認められている。

「アジャイルソフトウェア開発宣言」

プロセスやツールよりも個人と対話を、包括的なドキュメントよりも動くソフトウェアを、契約交渉よりも顧客との協調を、計画に従うことよりも変化への対応を、価値とする。

参考：Wikipedia

ウォータフォールとアジャイルは対立する概念ではないという話

アジャイルのトリガーをひくのはエンジニアだけではなく、経営層の場合もあります。
経営者にとってもこの変化が激しい時代に「開発時間の短縮」、「変化に柔軟に対応」と聞くと魅力的に映ります。現場に「アジャイルを調べるように」「次はアジャイルでやれ」とひとこと言ってみたくなるのは良くわかります。しかし手法ファーストはあらゆる点において博打です。そのことについて考察してみましょう。

まずアジャイルという概念を捉えるうえでは、ウォータフォールの理解が必要です。
ウォータフォールの考え方は「何が問題なのか」「その問題をどう解決するか」が出発点になります。
つまり「システムを作る」こと以前の検討事項に対して存在していると言えます。
一方アジャイルは「システムを作る」ことに対して存在します。

さらに両者をソフトウェア工学以前の視点から捉えると、問題発見と解決のアプローチとしてウォーターフォールという概念があり、その後工程であるシステム開発を、シーケンシャルと反復のどちちのアプローチで行うか、といえるでしょう。

つまりウォーターフォールとアジャイルは新旧あるいは対立の概念で捉えるものではありません。
ただ最適な解決方法を検討するにおいて、私たちの手には複数の選択枝と組み合わせがある、ということです。

そのうえで理解しておくべきことがあります。アジャイルは「作る」という行為に対するリスクを最小化しているように見えて、実のところ「作り始めた」以上は後には引きにくいものです。一方ウォータフォールであれば「作らない」という判断をして打ち切ることができます。つまり一長一短の特徴を分かったうえでアプローチを組み立てるべきなのです。

またアジャイルを扱ううえで注意しておくべき点として、「文書より対話だ」とか「ソースコードこそすべて」という偏重からくる無文書開発という極端なスタイルが存在します。また設計自体をなくしユーザーと打ち合わせしたら記録も書かずに、さっとプログラミングに取り掛かり、全ての情報がソースプログラムになるという極端なスタイルもあります。

これらはウォータフォールスタイルへの反動からくる極端な例ですが、アジャイルはとかく「システムを作る」ことが出発点ですから、殆どのエンジニアが持ちうる「プログラムを書きたいモード」を発動させがちな点も多分に影響しているのでしょう。アジャイルには明確な定義がありませんので、無文書、無設計といういわばアジャイル開発といいながらアジャイル開発ではない、ものも存在します。

特にAIや農業ITの分野では「まず作ってみて検証しよう」となりがちです。このような場にアジャイルに偏った人がいると、事前の検討はそこそこに作り始めることになります。しかしアジャイルが必ずしも最適解とは限らず、「ありき」で始まった開発は結構な確率でおかしなことになります。しかしウォータフォールの先頭からしっかりとやっていけば、ユーザーニーズの側面から検証したり、「それは必ずしもシステムで検証する必要はない」という判断を導いたりすることができます。

医療に例えれば胃腸の専門医は患者が「胃が痛い」と言えば、「ではこの薬が効きますよ」と胃腸薬を処方します。しかしその胃の痛みが脳挫傷が来ている場合は何の意味もありません。しかし胃腸薬のことしか知らない医者は、どんな症状の患者が来ても胃腸薬で解決しようとするのです。

ですから医者はしっかり診療して「ここが問題だ」というところを突き止めて、それに対する薬を処方するわけです。私たちの仕事に話を戻せば「ここが問題だ」と分かるためには、ITでの様々な解決手法をしっかり知っておいたうえで、クライアントをしっかり理解しないといけません。ただ一つか二つの手法を知っているだけではダメなのです。

しかしそれがなくて「今はアジャイルはすごい」、「やはりウォータフォールが基本だよね」という考えでやろうとしたら、それは博打でしかありません。
だからエンジニアのみなさんへ、アジャイルとかウォーターフォールがどうとかはそろそろ止めませんか。

この記事を書いた人について

谷尾薫

オーシャン・アンド・パートナーズ株式会社　代表取締役
協同組合シー・ソフトウェア（全省庁統一資格Aランク）代表理事

富士通、日本オラクル、フューチャーアーキテクト、独立系ベンチャーを経てオーシャン・アンド・パートナーズ株式会社を設立。2010年中小企業基盤整備機構「創業・ベンチャーフォーラム」にてチャレンジ事例100に選出。