システムの作り方(WaterFall(ウォーターフォール)編)
システムの作り方は、色々あるのですが復習がてら書いてみたいと思います。
WaterFall(ウォーターフォール)は名の通り「滝」です。上から下にざーっと流れていきます。それが理由で上流、下流という言い方をします。どっちが格が上というものではなく、川上か川下というだけで、川下を過ぎ切らないとシステムが完成しないのでどちらも大切です。
「滝」のため、後戻りは基本なしです。
Backlogさんがまとまってたので貼っておきます。
色々会社によっても、呼び名やもっと細かかったりするようですが、Backlogさんのものを拝借すると、以下工程に沿って1→8に向かって進んでいきます。
1.要件定義→2.基本設計→3.詳細設計→4.実装→5.単体テスト→6.結合テスト→7.総合テスト→8.受入テスト
各項目の詳細はBacklogさんのページを見ていただければと思いますが、
1.要件定義が何を作るか、を決めます。ステークホルダーと呼ばれる関係者が出てきます。なのでヒアリング能力が高かったり、実務に精通している人などが必要です。せっかくお金かけて作るのに、無駄なつかいづらいものつくってもねえ、ということです。
つながっている別のシステムがある場合は、そことも調整が必要ですし
WaterFallは予算が決まっている場合がほぼほぼだと思いますので、この金額だとここまでしか作れませんなので、どの機能入れますかなど現実的な算段も必要です。
また、予定もここで組まれます。2.～以降は、3が2か月、4が3か月など、仮決めですが、新しいシステムに変える日も大体これくらいと関係者みんなで握ります。
なので、素人さんが大システムで、この工程をやるなんて通常ありえないわけですよ(理由は後述)。
※ここは上流と呼ばれ、コンサル、大手メーカー、SIer、SE、PM、PMOなどが主に活躍。
大事なことを忘れていましたが、「滝」であり戻らない理由として、1→2、2→3の次の工程に進むにあたり、必ずチェック(レビューとよく呼ばれる)が入ります。PM、全チームが全チェック項目で確認者のOKが出ているか、確認しているはず。
まれに、保留且つ同時並行の進む場合もありますが、それはよほど遅れているか何かあります。
また遅れると、先ほど予算の話を出したと思いますが、問題になってくるのが、お金です。
例えば2021年4月から要件定義開始し、2022年3月に完成し4月から本稼働というシステムがいて、2021年12月に単体テストまで完了予定とします。
お手伝いで他社から応援人員を借りている場合、遅延すると追加のお金誰出すの？もそうだし、2022年1月からエンジニアさんが別の案件に異動しますーなんてことも起きて(わかっている人がいなくなる)、面倒くさいことになり、だからといってバッファ取りすぎるとお金と時間が無駄になるというきわきわ攻める話になるわけです。
2.基本設計
3.詳細設計
正直自分がここやらないので、あっさりしますが、
「この機能をつくるのに作り方は選べる」わけですから、最終的に具体的にどこのソースをどうつくるのかも含めて、決めていきます。
このあたりからもめてくるのが、1.要件定義の練度です。作ろうとすると「〇〇が決まっていない！」だったり、「△△が考慮されていない」などせっかくプログラマーが手を動かそうとしても、固まっていないので問い合わせしてそれで時間をつかってしまう、ということが十分にあったり、
実力差が1.要件定義の人＜2.基本設計、3.詳細設計の人の場合、ちゃぶ台返さざるを得ない状況も発生します。
※SE、プログラマーなどが主に活躍。
4.実装
5.単体テスト
さすがにいきなり本体を変えるのは怖いので、開発環境と呼ばれるコピー環境にシステムを作成していきます。理論上では動くことになっていますが、動かない場合もあるので、実際に作ったものを動かして意図した通りに動くか確認します。勿論、動かなかった場合、修正を行います。
※SE、プログラマーなどが主に活躍。
6.結合テスト
7.総合テスト
機能単体だけではなく、既存の機能との組み合わせや、他のシステムとの組み合わせでも動くか確認しています。勿論、動かなかった場合、修正を行います。
※SE、プログラマー、品証などが主に活躍。
8.受入テスト
開発陣側が一連のテストを終えると、ユーザー側がテストを行い、1で依頼したものができているかや、ユーザー視点で問題ないか確認します。いわゆる検収と言ってよいと思います。通常、実機テストも7か8あたりで出てくるはずです(状況で5.6.もある)。
※ユーザのターン！
1～8までがすべて完了し、初めてリリース(新しいシステムに変える)のOKを取りに行くことになります。PMO的には、確か8までOKか？進む前に確認せいという内容はIPAの資料にもあったと思います。
リリースも、その会社や開発環境によって、本当に色々だと思いますが、大きいシステムであれば、一回で決めてこい且つ複数社にまたがりかかわる人数が多いため、リハーサルをして、当日の動きを確認します(考慮漏れが見つかる場合もあるので、その場合は修正)。
無事ユーザ＆上の人がOKを出してくれれば、Xデーにリリースと相成ります。当日は短ければさくっとおわりますが、巨大なシステムは夜を徹して数日もあるので、家に帰ってこないIT会社の人が家族でいる方は、生暖かく見守ってあげてください。
ウォーターフォールの良さとして、経験値の低い人でもチェックがあることでOJTができるし、成長させられるが、品質が担保できる。
ユーザ側を巻き込む仕組みがあることで、各チェック(レビュー)や受入テストでこんなはずじゃなかった、とか言わせない(お互いハッピーでいるために)
突然作るものが増えたり変更されないので、エンジニアが心の平安が得やすい(はず)
最終的に言いたいこととしては、以前「ウォーターフォール(笑)」とか思ってましたけど(ウォーターフォールの人ごめんなさい)、本当によく考えられた枠組みですよ。なのでプロジェクトマネジメントの方はベストな選択ができるように、がんばりませう！
この記事が気に入ったらサポートをしてみませんか？