初心者の方は特に感じられることかと思いますが、さぁ、プログラミング言語を覚えた！プログラムをどうやって作成するのでしょうか？
例えば、ゲームのプログラムを作りたい！と思ったときに、手が勝手に動いて、気が付いたら思う通りのゲームを作れる人は多分、これ以降は読まなくてもよいかもしれません。
これは皮肉ではなく、私自身が本当にそう思っているということもありますし、一方で私には無い才能ということで憧れでもあります。
実は、ソフトウェアの開発環境はこのようなある種の、プロデューサーといいますか映画監督といいますが、要するに『何を作るかが分かっている人』が潜在的には求められており、AIがコーディングを助けるようになると、ますます重要なポジションになるかと思います。
これは、特にソフトウェアをある種の表現行為に使う（ゲームとかAI動画等）場合に必要な人材と言えるかもしれません。
一方で、ソフトウェア開発というのはもっと多種多様な世界ともいえます。こういうと大げさに聞こえますが、『どう作るかは分からないが、完成図が見えている人』と『完成図を貰えれば、あとは作れる人』と組み合わせると上手くいくケースもあります。大半のエンジニアが関わる業務アプリやらECサイト、その他、WEBアプリや組み込みアプリがありますが、『現場で使う人』と『現場の人が使えるツールを作る人』という組み合わせもあるでしょう。
このように作る人と作ってもらいたい人が別になる、つまり組織的にプログラムを作るようになると、作るものの合意をしたり役割分担をすることになり、『誰がいつ、何をするか？』というソフトウェアの開発手順が必要になってくるでしょう。
ソフトウェアの開発手順の古典的かつメジャーな方法が、「ウォーターフォール開発」ということになります。
段取りを踏んでプログラムを作りましょうということですが、『こういう面倒なことは知らなくてもよいのでは？』と思われる方も、自分が仕事としてプロジェクトに参加して、プログラムを組む場合は、つまり組織的に開発するということは何らかの開発手順を踏むことになりますので、勉強されることをお勧めします。
ウォーターフォール開発は、色々細かいところはありますが、概ね
・要求仕様（Requirements）
・設計（Design）
・実装、開発（Implementation）
・テスト（Verification）
・運用（Maintenance）
という風に工程を分けて、開発を行うということです。『要求仕様』というのは一言でいうと『何を作るのか？』を決める作業で、『設計』は『どう作るのか？』を決める作業、『実装』で実際にモノを作り、『テスト』で動作確認を行いバグをとりのぞき、『運用』では実際に使っていくということになるかと思います。
実装、テスト、運用についてはプログラマの方には分かりやすいかと思いますが、要求仕様や設計についてはピンと来ないかもしれません。いわゆる上流工程と言われている工程が要求仕様になるかと思います。具体的になにをするかは様々ですが、ここではお客さんと頻繁に打ち合わせを行うことになります。よく、オプションとして「AとBどちらにしますか？」というとお客さんから「どっちもできるように対応して」とか言われるところです。ここですかさずに「そうしますと工数が増えますね。あとで概算見積もりに入れます」と言えるかどうかが、その後の開発が修羅場になるかどうかを決めることになります。
設計作業は、名前ほどキチンとしておらず曖昧かもしれません。例えば、昔は「オブジェクト指向は大規模開発に向く」と喧伝され「UMLが・・・」とか「オブジェクト指向設計」やら「モデリング」やら言われた時代がありました。これらの声が下火になった、今、はたしてどこまで浸透しているかは謎ですが、批判を覚悟であえて言いますと、大規模開発において信頼性のあるアプローチ（設計手法）はトップダウンや分割統治かと思います。つまり機能ごとに分割してアプリケーションを定義するということになります。ECサイトなら「購入サイト」や「商品・その他マスター管理」、「顧客管理」、「注文管理」とかになるかと思います。機能分割に着目することは「オブジェクトがどうのこうの」というより、より上位の、つまり抽象度が高い操作と言え、分割にも適しているでしょう。
さて、以上は、『私のウォーターフォール開発』の理解です。日本でのソフトウェア開発の現場を見てきましたが、こういうことをキチンと分かっている人や出来ている人は経験上少なかったかと思います。
『お前はどうやねん』と言われそうなので、予め答えますと、プログラミングと同様に一通りの勉強はしました。また、キャリアのごく初期は幸運にもウォーターフォール開発を行っていた経験があり、理論と実践で学ぶことができました。
一方で、繰り返しになりますが、現場現場で、関わる人達の理解に差があったり、ケーススタディーがキチンとしていない面もあり、状況は「カオス」かと思います。
私が情報処理技術者試験の受験をやめたことがあるのですが、これは『あまりにもソフトウェア開発手順を無視したプロジェクトマネージャ』がいる現実に落胆して勉強するのが馬鹿らしくなったことがあります。
以上、ざっとウォーターフォール開発を見ていきましたが、ウォーターフォール開発の批判の1つが、「各工程を厳密に区切る」ところにあり、Wikiにもあるとおり、「全工程に間違いがない」ことを前提にしている開発手順と指摘されています。
例えば、要求仕様の段階で、「そのままの要求仕様を満たすものは作れない」となると大問題ということになります。
これに近いものになりますが、私が気を付けているのは「プロジェクトメンバはどのタイミングで、作成するものを具体的にイメージ出来るか？」ということになります。言葉を変えると「この情報でプロジェクトメンバは開発が滞りなくできるか？」ということになります。
ソフトウェア開発の現場で、よくあるトラブルの１つは『プログラムを作れない』という状況になります。要求仕様の間違いもありますが、どうも一部のエンジニアは『出来ない』ということが言えなかったり、自分の能力不足を認めなかったりし、想定（報告）以上の時間を使って開発が遅延します。
次回では、ウォータフォール開発をもう少し突っ込みつつアジャイル開発についてみます。