システム開発のゴール

システム業界で働くと、モヤモヤすることがたくさんある
ITリテラシーの低い人との認識の相違が、モヤモヤの原因だが、その認識の相違の最たるものが、ウォーターフォールモデルだと思う

一般的なシステム開発は、要件決めて、設計開発し、テスト、リリース、保守運用という、ウォーターフォールモデルに沿って行われる
ITに馴染みのない人にとって、この説明はとても腹落ちするらしく、多数問題点が指摘されながら、しぶとく生き残ってきた

WEBの世界でもウォーターフォールモデルは根付いている
特にプログラミングの経験がない人には、何の疑問もなく受け入れてもらえる

しかし、少しでもシステム開発の経験があれば違和感を抱く
ウォーターフォールの手法がまともにワークしていることはほぼ無い

原因はいくつかある
まず、ウォーターフォールの前提として、技術の基本を理解している人が設計を行わなければならないが、この世界では同じ開発が
再度行われることはない（もし同じものを作るとしたらコピペで完了する）
作ってみないとわからないことが多すぎる
つまりガチガチの汎用機でもない限り、ウォーターフォールなど無理なのである

さらに、仕様の複雑さがあげられる
今まで完璧な仕様書を見たことがあるだろうか
完璧な仕様書とはイコール、ソースコードだ
ソースコードに近いくらい細かく書かれた仕様書を見たことはある
しかし、ソースコードには及ばないし、何より無駄が多すぎる

現実世界を仮想の空間に再現する、システム開発において、とんでもなく複雑な、それらを文章で全て書き表すのは無理である
エッセンスを正確に伝えることさえ、難易度は高い

コンピュータの世界は日進月歩だ
ソフトウェアの開発技術は飛躍的に進歩した
何かを実現するために書かなくてはいけないソースコードの量は、減っている
今後、減ることはあっても増えることはない

さて、ソースコードの技術的な部分が極小になり、ほとんどが宣言的に表現されるようになると、プログラミングとはすなわち仕様を決めることである

仕様を決めることが最も重要であり、難易度も高い
スループットはどれくらいなのか、応答時間は何ミリ秒か、レコードは1対NかN対Nか、パラメータは状態を持つのか持たないのか
何もないところから、机上でそれらを見定めるのは、とてつもなく困難である

結局、作ってみないとわからない
作られたシステムこそが仕様書であり、要件定義書である
システムにデータを入力し、動かせば、何が起きているかは誰の目にも明らかになる

となると、システム開発のゴールは、はじめに決めた仕様を満たすものを作ることでは決してない
仕様を決めることでもない
前述したように、仕様を定めることなど不可能だからだ

それらしいシステムを早期に実現し、実際に関係者に使ってもらい、高速にフィードバックを行うサイクルを高速に回す
いわゆるDevOpsだ
継続的インテグレーション（CI）であり、継続的デリバリー（CD）である
そういったアジャイルな仕組みを作り上げることこそが最も重要であり、システム開発のゴールとなる

自動テストを組み込み、実装されたすべての機能が壊れることなく、新しい仕様を組み込んでいける仕組みを作り、その仕組みを維持することこそが最重要である

ウォーターフォールでいうと、全ての水が滝を落ち、穏やかな流れになったところが、実は開発のスタートといえる
この認識の相違は彼岸と此岸のごとくである