開発手法とは＆ウォーターフォールの紹介とメリットデメリット
さて、前回は現在提供中のサービス「PackinsStarMD」の新機能と、開発に至るまでの経緯についてご紹介させていただきました。
今回はその「開発までの経緯」に着目して、初学者目線で「開発手法」についてまとめてみたいと思います。
ITについての勉強をしていると、アーキテクチャや○○指向、int型・string型など、「型」という考え方に触れる機会が多くあります。
この「型」という考え方は、シチュエーションによってニュアンスは若干異なるように感じますが、「こうしたら大体うまくいくよ」という、先人たちの失敗や苦労など、試行錯誤から得られた学びを、後世に伝えるための基本的な概念のようなものだと感じています。
開発手法もそれとよく似た考え方です。
サービスを作り上げるプロセスを、チーム全員が共有できる「型」として整理した、進め方のお約束のようなものだと言えます。
残念ながら開発手法には「この開発手法に則っていれば完璧！」という絶対的な正解があるわけではありません。
それぞれのメリットデメリットを理解したうえで、プロジェクトの状況や目標、工数などを整理しながら、適切に考え方を取り入れていくことが重要になります。
今回はそんな開発手法の一つ「ウォーターフォール型開発」について整理してみました。
ウォーターフォール型開発はその名の通り
「滝（Waterfall）が上から下に流れ落ちるように、工程を順番に進めていく」というイメージの開発手法です。
ウォーターフォール型開発の大きな特徴は「開発における各工程が細かく独立して区切られている」という点にあります。
そのため、工程ごとの進捗管理や品質管理がしやすくなるというメリットがあります。
その特徴から、大規模で複雑なプロジェクトに適した開発手法だとされています。
ウォーターフォール型開発では、開発までの道のりを大きく８つの工程に分けて考えます。
工程①から⑧まで上段から順を追って開発が進んでいきます。
| 要件定義 | システムの機能や、開発に必要な予算・人員を決める |
| 外部設計 | 見た目の部分（ユーザーインターフェース）を設計する |
| 内部設計 | システム内部の動作や機能、物理データ部分を設計する |
| 実装 | 外部設計・内部設計に基づいて実際にプログラムを作成・実装する |
| 単体テスト | 実装したプログラムが正しく機能するかテストをする |
| 統合テスト | 複数のプログラムを組み合わせて、正しく動作するかテストをする |
| 運用テスト | 完成したシステムが実際の業務に使用できるかテストをする |
| リリース | テストが完了したシステムをリリースする |
要件定義を最初にしっかり行うことで、方針が固まった状態で開発を進めていけるというのもウォーターフォール型開発の大きな特徴です。
複雑なプロジェクトに適していると言われる理由には、
この「工程が順番に進んでいく構造」も大きく関係しています。
例えば、プロジェクトが進んでいるうちに
「やっぱりここのボタンは違う場所の方がいいんじゃない？」
とか
「え、更新日は検索条件には含まないんじゃなかったっけ？」
といったように、仕様の急な変更や認識のずれが原因で作業が止まってしまったり、これまでの作業が無駄になってしまうような事も（本当は絶対に避けたいですが！）少なくないと思います。
特に関わるチームメンバーが多くなればなるほど、このようなケアレスミスや、ヒューマンエラーによる手戻りなどを防ぐことが重要になってきます。
最初に要件定義をしっかり行うことで、こうしたリスクを最小限に抑え、開発に集中しやすくなる点が、ウォーターフォール型開発の大きな強みだと言えます。
しかし一方で、最初に要件定義をしっかりすることがデメリットに繋がってしまうケースもあります。
企画や要件定義をじっくりと行ってから開発を開始する分、開発期間が長期化しやすいという欠点があります。
日々次々に新しいソフトウェアやアプリケーションサービスが登場する現代では、お客様の手元に届くまで時間がかかってしまうことが、致命的になってしまうシチュエーションも少なくありません。
システム開発に限らず、すべての業務が計画どおりに進行することは稀です。
開発の途中で
「ダイアログは使いにくいかも…」
「やっぱりこの機能はいらなそうかな」
と感じても、最初に全体像が固まっている分、仕様や計画を簡単に変更できません。
万が一、開発途中で仕様の変更をする場合は、甚大なコストと労力が発生してしまいます。コストや労力を捻出できず、「後戻りできないままシステムが完成してしまう」というケースもあるほどです。
また、ウォーターフォール開発では、システム修正やアクシデントが発生すると、工数が大幅に増加します。
例えば、実装段階に入ってから「機能の追加」や「データ連携先の変更」などが決まった場合、上流工程に戻って作業をやり直す必要があります。
既に完了したはずの工程を再度実行するため、追加の工数が発生してしまい、全体のスケジュールが後ろ倒しになることにもつながります。
開発コストは、利益に直結するとても大切な要素です。
なので、最初の要件定義の段階で修正やアクシデントのリスクを可能な限り洗い出し、想定しておくことが重要になります。
このように、デメリットとメリットを見てみるとウォーターフォール型開発は諸刃の剣のようにも感じられます。
一方で、開発者個人の視点で見てみると、このウォーターフォール型開発の考え方は非常に役に立つ場面も多いと感じています。
最初に与えられた課題をしっかり噛み砕いて理解し、 必要な実装の工程を整理したうえで、 サーバーサイド・クライアントサイドの実装を進め、 単体テストを繰り返しながら開発を行い、 最後にシステム全体に影響が出ていないかを確認する。
レビューを受けて、問題がなければマージする。
こうした進め方は、規模の大小に関わらず、 日々の開発作業やチーム内での作業整理においても有効な考え方だと言えるのではないでしょうか。
このように場面に応じて柔軟に応用しながら取り入れる点が「型」という概念の優れている点だと感じます。
プロジェクト全体の進め方だけでなく、自分のチームや個人の作業など様々な場面でこのウォーターフォール型開発の考え方を取り入れていきたいと思いました。
＜＜PREV
