はじめまして。ファイナンシャル・ソリューション開発部の赤坂です。
私は主に案件遂行の仕事をしているのですが、案件遂行はプロジェクトの全体像が見えないとなかなか難しいものがあります。そこで今回は、プロジェクト(=案件)の基本となるウォーターフォール開発を解説しながら案件遂行で気を付けることを書いていこうと思います。
- 1.ウォーターフォール型開発とは?
- 2.ウォーターフォール型開発の主な工程
- 3.要件定義
- 4.基本設計
- 5.開発・単体テスト
- 6.結合テスト・総合テスト
- 7.リリース
- 8.さいごに 【こまめな連絡と丁寧な橋渡しが大事】
- この記事を書いた人
1.ウォーターフォール型開発とは?
ウォーターフォール(英語:Waterfall)とは、日本語で訳すと「滝」を表します。開発現場で利用するシステム開発手法であり、その名の通り滝のように上流工程から下流工程にそって順番に開発を進める手法です。ウォーターフォール開発は、工程ごとに成果物を完了させていき、基本的には前の工程に戻らないのが前提です(そう上手くはいきませんが…)。そのため、各工程ごとに開発担当者や関係者が成果物を確認し、双方で合意を取りながら工程を完了させていきます▼。開発スピードが重視されるWeb開発ではアジャイル型開発が主流ですが、基幹システムなど、要件が明確で変更が少ないプロジェクトではウォーターフォール型開発が適しています。
▼アジャイル開発について知りたい方へ
blog.css-net.co.jp
2.ウォーターフォール型開発の主な工程
ウォーターフォール開発は1章の通り、上から下に流れるようにプロジェクトを進めていく必要があります。基本的な工程は、現場によって多少の差はありますが、「要件定義」「基本設計」「開発・単体テスト」「結合テスト」「リリース」 の工程を順番に進めていくのが特徴です。3.要件定義
こちらは、このプロジェクトは何を実現したいのか、どのような機能を開発するかを決める工程です。現場によって作業内容は異なり、お客様が全て要件定義を書くケースもあれば、打ち合わせをしながら要件定義を決めていくケースもあります。私の現場では前者で、お客様より要件をいただいたら、プロジェクトが本格始動する流れです。WBSを作成し、概要とスケジュールをメンバへ説明
お客様より要件定義をいただいて案件化されたら、スケジュールを決めてメンバに知らせる必要があります。WBS(作業分解図)を作成してプロジェクトの成果物と期間を可視化し、プロジェクトメンバへ概要とスケジュールを説明します。私の現場はテレワークなので、メールやチャットで「見ておいて」と振ることもできますが、個人的にはキックオフミーティングの開催をおすすめします。話したほうが伝わりやすいと思いますし、メンバにも「困ったときは通話して聞いていいんだ」と思ってもらえる効果もあり。何事も始めは大事ですからね。4.基本設計
次の工程は基本設計です。概要設計書・基本設計書・変更概要書など、色々な呼び方はありますが、要件定義を基にシステムの仕様(できること)や制約(できないこと)を決める工程になります。この段階でテスト概要や実施リスクなども考える
また基本設計と言いながら、この段階でテスト概要や実施リスクなども考える必要がある為、チャットなどで開発者・テストメンバ・運用メンバにも意見を聞きながらプロジェクト全体の青写真を考える必要があります。5.開発・単体テスト
ちょっと待て!基本設計の次は詳細設計じゃないんかい?と思ったそこのあなたは正しいです。しかし、私の出向先には詳細設計の工程はありません!その為、基本設計の内容をもう少しシステム寄りにして開発メンバに説明する必要はあります。開発メンバがわかるように、文字だけで伝わらなければ図を載せて説明するなど丁寧な説明が必要になります。まあ、私は出向先のプログラムや環境は分かりませんし、権限も無いので開発メンバに全てお任せなのですが、開発中に上がってきた質問や製造方針については顧客との橋渡しも必要になるので、ある程度の知識は必要になるのと、分からないことは分からないまま橋渡しせず、自身でも内容を把握してから橋渡ししないと後々大変なことになります。。。
6.結合テスト・総合テスト
開発が終わったらテストです。問題なくテストが進めばよいのですが、何か想定外の結果が出たときは、テスターから詳しい事象を聞く→テスト方法がおかしいのか、プログラムがおかしいのか判断する→開発メンバにフィードバックすると、各メンバ間の橋渡しが必要になってきます。丁寧な橋渡しと進捗管理がカギ
この時も、「今起きている結果」と「本来想定していた結果」をきちんと伝えないと各メンバも動くに動けないので、丸投げせずに丁寧な文章や図で事象を説明して橋渡しすることが大事です。そして、上記のほかに進捗管理も必要になってきます。定期的に進捗具合を聞いて、メンバ増員やスケジュール調整など、早めに動くことが重要です。
7.リリース
テストが終わってゴールも見えてきましたが、この工程は油断できません。リリース日が一番忙しいといっても過言ではありません(※案件によっては過言です)。どんなに開発環境でテストをしても本番では予期せぬ事態が発生することもありますし、その場合のコンチプランも入念に計画しておく必要があります。8.さいごに 【こまめな連絡と丁寧な橋渡しが大事】
長々と書いてきましたが、案件遂行で大事なのはこまめな連携と、伝わりやすい文章や図を用いての橋渡しを意識することと思います。案件がどのように動いているのかを少しでもイメージしていただけたり、案件遂行業務に興味を持っていただけたら幸いです。\システム開発なら、株式会社シー・エス・エスへ/
この記事を書いた人
【ニックネーム】:赤坂
【経歴】:入社以降、ひたすら投信・証券系システムのお仕事をしておます。
【一言】:老後に向けて貯金しなきゃと思いつつ、体力低下や体調不良、老眼の進行によりもはや今が既に老後なのでは?と自問する日々。