開発手法について「ウォーターフォール」メリット

前回(ウォータフォール概要)に引き続き、

顧客(発注側)視点、開発者(受注側)視点それぞれから見たウォーターフォール開発のメリット

[顧客視点]

・予算を決めやすい

⇒あらかじめ要件定義で何をやりたいかが明確化していれば、受注側は概算の見積までは作成できるはずなのでシステム全体で凡そどれくらいの費用になるのかが把握できる。

このシステム開発にいくらの予算を用意すれば良いかが明確化するので運用しやすい。

 

・リリースまでの計画全貌が見えやすい

⇒予算同様に開発着手前にシステム全体像がある程度決まっているので、開発をいつ開始したらいつ頃納品されるかが明確です。

納期が決まっているので先々、営業をどうするのか、広告はどうするのか、運用体制はいつ頃までに整えればよいのか、なんていう計画も事前に立てやすい

 

[開発者視点]

・やることが決まっているので計画を立てやすい

⇒設計の前段階でシステムの全体像が明確になるので、いつまでに何をしなければいけないかが明確。

しっかりとマイルストーンを意識していれば納期の遅れは発生しないはず。

(ですが、そんなパーフェクトな運用は見たことが無いです。

そもそも人間のやる仕事なので遅れが出て当たり前、バッファは多すぎるくらいに積んでいても納期直前になると炎上まではいかなくても大体多かれ少なかれピリついたりするものだと思います。)

 

開発手法について「ウォーターフォール」概要

ここで言う開発手法はプロジェクトの進め方についてです。

個人の開発でわざわざ触れるような話ではないと思うのですが、折角なので少しだけ。

細かく見ていくと沢山の手法がありますが代表的な2つの手法について

それぞれ概要、顧客目線でのメリット・デメリット、開発者目線でのメリット・デメリットなんかをまとめます。

かなり主観入るのでご指摘あればコメントお願いします。

 

ウォーターフォールモデル】

[概要]:

以下のフェーズを上から順に実施していき、水が上から下に落ちるように逆流はあり得ないという理想的な思想。

・要件定義:

 要件のヒアリング(顧客が何をしたいのか)と仕様の策定(ヒアリングした要件をどのように実装するのか)を議論するフェーズ

後戻りが出来ないウォーターフォールモデルではこのフェーズで「やりたい事」を全て聞き出せていないと後で大変なことになる。

 

・基本設計:

 システムの大枠の構造を決める設計フェーズ、UI設計やデータフローとかもこのフェーズで決めてしまう。

ワイヤーフレーム等の絵が出てくるのでヒアリングの漏れとかもここでキャッチしたい。

ここでの定義がふわっとしていて漏れや誤り等があると詳細設計で大変なことになる。

最悪開発フェーズまで気づかずに炎上する。

後がないので少しでも怪しい言動があればしっかり突っ込んで「本当は何をしたいのか」をしっかり絵に起こす

「デザイン」を基本設計とするか詳細設計とするかは人によって意見分かれそう。

 

・詳細設計:

 システムの詳細を決める、データベースのテーブル設計やプログラムで使用する外部ライブラリ等の調査や策定なんかもここでやる。

調査するよりコーディングした方が早くねとか思うときがあるけど挫けない。

ここでの調査が甘いと開発フェーズが大変なことになる。

 

・開発:

 環境構築を開発に含むのか詳細設計に含むのかは意見分かれそうだけどウォーターフォールモデルではどのフェーズで遅れが出ても最終的に行きつくテストフェーズに全てのしわ寄せがいくのでやれることがあるならとっととくやるべきだと思う。

詳細設計が完全に終わってなくても開発はフライング気味に始めていいんじゃねと思う派です。

 

・テスト:

  単体テスト:開発者が行うテスト(プログラムのメソッドや関数もしくはクラスやモジュール単位でのテスト)(場合によっては開発フェーズに含まれるのかもしれません。)

 結合テスト:Web系であればフロントエンド、バックエンドアプリを開発用のサーバにデプロイして行う。

 ユーザーテスト:顧客が行う(受け入れテスト)

要件と設計のズレに気づかずにここまで来てしまうと大変なことになる。

顧客からすると受入テストで初めて実際のアプリに触れるので「あれ?」と思われたら地獄の始まり。

ウォーターフォールでは逆流は出来ないので歪みは誰かが被るしかない、現場によっては醜い罪の擦り付け合いが始まる

 

思ったより長くなったので記事分けます。

次回はウォータフォールのメリットデメリット。

Blogのシステムをスクラッチから自作してみる

【自己紹介】

ちょっと歳はイってるけど、駆け出しのエンジニアです。

フリーランスとして活動しており、日本/海外兼用のポートフォリオやら技術ブログなんかを作らなければならず、どうしようかと迷っていたところ

諸々一緒くたにして開発の経緯やらドキュメントも全公開した自作ブログを作ればいいんじゃないかと思い立った次第です。

 

ちなみに他にもちょっと思うところがあって、

最近(特に流行りのWeb開発においては)フレームワークやら流行りのライブラリが無限にあって更にMac,Linuxユーザも増えているので

・いざ自分が開発上でトラブルに遭遇してもネット上の情報は散らかっていて中々自分の状況にあったものが見つからない。

・更にエラーの原因究明は一切せずにこうやれば直るよ(ただし環境によるけどね)みたいな記事が大量にあって私のような初学者からすると中々読み解くハードルが高い。

・更に更に実際には動かない(誤った)ソースコードのコピペが大量に検索に引っかかるので中々正解にたどり着けない

・案件によってライブラリもフレームワークも違うので情報量多すぎ、整理したい。

 

みたいなことがありました。

上記も踏まえて初学者フレンドリーな内容の記事を目指して且つ自身の情報整理にもなれば良いなと思っています。

 

どうせ勉強するならいつか誰かの役に立つかもしれない情報は残しておきたいですし。

という事で今回実装予定の内容は以下になります。

 

【やりたい事】

・ドキュメント化をきっちりやる(出来れば英語翻訳も自力で頑張りたい)

アジャイルが流行りだけど基本のウォータフォールで1つずつ確実に進める

・フロントエンド、バックエンドを一通りスクラッチから自作してポートフォリオ的な位置に持っていきたい。

・インフラはどこまでやるか分からない

・自分で書いた記事の投稿、公開、編集、削除(CRUD

・あれこれ興味はあるけどとりあえず一番ベーシックな構造で最低限のサービス内容を構築する

 

【その他】

・あまりストイックにやりすぎると心折れるのでのんびりDIY感覚で続ける

・いずれ海外でのフルスタックエンジニアとして就活が控えているので出来る範囲で英語力も一緒に上げていきたい