システム開発はウォーターフォールとアジャイルのどちらが望ましいか？という議論が無駄だと分かった瞬間

開発手法でよく対比されるこの二つ。 どちらがいいという議論はすでに「犬と猫のどちらが好きか？」と同じレベルの議論であり、目的が成果物のクオリティになるべきである。

ウォーターフォール解説

https://ja.wikipedia.org/wiki/ウォーターフォール・モデル 工程の後戻りを無くすように開発する方法。 このモデルの難易点としては「前工程に間違いがない」という事が大前提になるため、間違いが合った場合は大事故に繋がる。

アジャイル解説

https://ja.wikipedia.org/wiki/アジャイルソフトウェア開発 短期間で区切って開発することで、リスクを少なくする。 このモデルの問題点は、プロジェクトチームが分散された場所にある場合、工程管理などが重要視されないため、短期間での開発ができない場合がある。 また、ウォーターフォールモデルと平行で行うこともよく行われるため、モデルとして単体での精度は高くないかもしれない。

その他の手法

カウボーイコーディング エクストリーム・プログラミング スクラム

発注サイドの趣向

注文している側の意見を汲み取り、最も効率的且つ最大限のクオリティに仕上げてほしい。 高い金を出して委託するので、仕上がった後のバグや、機能漏れは基本的にご法度である。 また、長期保証も対応してもらいたいので、メンテナンスも簡易に行えるように考慮してもらいたい。

開発サイドの趣向

発注者の意向はよくわかるが、一般的で無い開発物は、出来るかどうかの検証から入らなければならない上、それを踏まえた費用定時は非常にナンセンス。 正直、言われていない事は、作る対象では無いので、確実に伝えてもらわないと漏れる。 費用を叩かれて、潤沢では無い工数で、どう構築するかは、何処か簡易な要素は時間をかけられないので、本意では無いが手を抜かざるをえない。

両サイドの意向のズレは永遠に無くならないのか？

システム開発も、建築も、よく似ていると思いますが、基本的に間に入る建築家やSEと呼ばれる立場の人が重要になる。 何故なら彼らが勘違いして進めてしまうと、完成後に、発注者から「こんなの頼んでいない」という事故になってしまうからだ。 発注者は、安く無い金額かつ、思い通りの成果物が望めないのであれば、それが叶えられるパートナーを探す以外に手は無いのである。 開発者は、言われた仕事をこなすだけという、あぐらをかいた状態から脱しなければ、将来は安定で無いだろう。 詳細設計書は、開発スタートに完璧と思われるものを作るのは、それ以後の変更を行わないという手法のため、柔軟な開発はできない。 よくあるのは、UIUXデザインなどは、試行錯誤が必要な領域であり、これを固めてしまうが故に矛盾が生じてしまう現象は、開発あるあるである。 一方、アジャイルは、事後に設計書を構築しなければいけないのだが、スピード優先で行う手法のため、そんな物を書いている時間があれば、さらなるブラッシュアップを求められる傾向がある。 要するに、完璧な開発手法などは世の中に存在出来ず、そもそも、設計書を書くのにもスキルが必要であるし、コメント書いていれば設計書などいらないという開発員も存在する。 詳細設計所は、とても分厚い資料になるため、誰も紐解いて読み返すという事は行われない上、開発員以外は難読で仕方が無いシロモノらしい。

開発手法の向き不向き

お役所系のシステム開発を行うのは、確実にウォーターフォールでなければならないが、それが故に、役所系のwebページやシステムは使いにくくて仕方が無い。 大人数で行う大手の開発も、カッチリ型にはまった手法でなければ、統率も取れない。 ベンチャー企業のような、スピードもコストもクオリティも重要視される場合は、その会社ならではのアジャイル方式に自然となっていくはずである。 要するに、すべての人がどういう特性かによって開発手法は千差万別であるべき事がわかります。 一番重要視されるべきは、「どういう物を作って、どう使いたいか」であるはずです。 注文者の想いを開発にぶつける事は重要だが、伝えきれない時に、どうすれば伝わるかを考える人は少ないのが現状です。 個人的には、「自分で作ればええやん」と思うんですが、こういったことを解決できるソリューションがあるといいが、無理でしょうね。 一番最悪なのは、発注側、開発側それぞれで、相手側がこうあるべきと決めてしまっている場合。 とても悲惨な結果になる事は間違い無いでしょう。 改めて、技術先行のエンジニアリングファーストになる事が望ましいと思っています。 あれでも、これってプロダクトアウトってことになるのかな？