はじめに
この記事はウェブクルー Advent Calendar 2022 1日目の記事になります。
参加していただいた方々本当にありがとうございます！！
経緯
よっぽどプログラマーに特化した人でもない限り、システム開発にかかわる人は開発工程を意識せずに仕事はできません。
しかし開発プロセスに関する話は基本情報でも応用情報でもさっくり終わってしまう範囲であり、意識せずなんとなく仕事をしているというのを最近強く感じました。
そんなシステム開発の工程をみんな大好きカレーの作り方へと具体化することで、理解しようという記事になります。
開発プロセス
アジャイル開発にスクラム開発、プロトタイピングモデル…と手法は多々ありますが、今回は由緒正しき(?)ウォーターフォール開発で理解していきたいと思います。
1つずつ確実に進めるという考え方が料理の工程と似ているのと、(情報の漏れが無ければ)スケジュールの管理や進捗把握がしやすいということが大きなメリットになります。まぁそんな都合よく進むことはないんですが。
1.システム要件定義(要件定義)
概要：
そのシステムを作ることでどんなことをしたいのか。何のどんな業務を対象にするのか明確にしていく段階。
実現するために実装しなければいけない機能や性能などを話し合って決定していく。
ユーザーがシステムに求めていることをまとめた発注者向けの「要求定義」とそのために必要な機能をまとめた開発者向けの「要件定義」の二つをまとめて要件定義とみなすこともある。
ここのヒアリングを重点的に行わないと、壮大な手戻り(=やり直し)が発生したり、出来たものが誰のためにもならないという事が起こりかねません。(参考リンク:顧客が本当に必要だったもの)
カレー：
どんなカレーが食べたいのか。甘口か辛口なのかを話し合っていく段階。
そもそも作るべきなのはカレーなのかをヒアリングする必要もある。
聞いてみたらただ辛い物を食べたいだけという事が分かるかもしれない。
激辛が食べたいというのは「要求定義」、じゃあ唐辛子を入れましょうというのが「要件定義」となる。
ここのヒアリングを漏れなく行わないとあとで悲鳴を上げることになる。(日本カレーを作ったら求めていたのはインドカレーだった、なんてときは鍋を投げたくなります。)
ライスではなくナン派の人は早めに言っておきましょう。考えのすれ違いが許されるのはラブコメだけです。
2.システム方式設計(外部設計)
概要：
要点定義でまとめたことを実現するために、ハードウェア、ソフトウェア、ネットワークの構成などを決定する。
例えばサーバーであればオンプレミス(自前)にするかクラウドにするか等を決定する。
また、システムが自動ですることと利用者が手作業で行うことの範囲を決定する。
カレー：
要件定義でまとめた味・形式を達成するために何を使うのか決定していく。
カレーの味を作るのにルーを買うのか、スパイスの調合から行うのか、というのを選び決めていく。
また、レシピとしてカレールーとごはんは出すけど、福神漬けは各自に乗せてもらうという事を決定する。
3.ソフトウェア要件定義(外部設計)
概要：
利用者の視点からソフトウェアに必要な機能や能力を決定する。
システムを使う一連の流れを定義するためにユースケース図を作成したり、データの流れに着目したDFDを使用することもある。
カレー：
野菜炒めて、肉焼いて、水入れて…というレシピを作る状態。
4.ソフトウェア方式設計(内部設計)
概要：
開発者の視点からソフトウェアに必要な機能や能力を決定する。
ソフトウェアの構造とコンポーネントについて考える。
カレー：
米を用意するのに、ご飯を炊くという工程が必要になるのでレシピの手順書に追加する。
同じように野菜を用意するために皮むき工程を挟む必要があるので、手順書に追加する。
5.ソフトウェア詳細設計(内部設計)
概要：
各プログラムの構造設計を行う。
テストするソフトウェアごとに詳細化して、クラスの名前を一つずつ付けるなどして文章化する。
カレー：
野菜は○○で買う、肉は△△で買うというように詳細に決めていく。
ぶっちゃけ無くても良いという意見はあり、内部設計は行わず外部設計から一足飛びにプログラミングに移る場合も実際にある。
6.ソフトウェア構築(プログラミング)
概要：
詳細設計に基づいて作成していく。
カレー：
買い出し、準備、作成、召し上がれ！
7.テスト
概要：
作成したプログラムは要求水準を満たしているか、ミスやバグが無いかを確認する。
全体の3~4割の時間を費やす場合が多い。
モジュールレベルの単体テスト、結合させた状態を検査する結合テスト、システム全体を稼働させたシステムテスト、実際の運用と同じ環境で行う運用テストがある。
カレー：
要求レベルの味が出来ているか確認する。
野菜・米レベルでチェック、料理全体でチェック、実際に出してみてチェックを行う。
不味かったら作り直す。
まとめ
これで完成！ としたいですが、実際に出した場合には「思っていたのと違う」と言われることもあるのがウォーターフォール型です。
カレーの場合「嫌なら食べるな」とでも言えますが、システム開発ではそうもいきません。
このような不幸な事故を防止するためにアジャイル開発やプロトタイピングモデルが用いられたりします。
興味ある方はぜひITパスポートなどの取得を目指しつつ、調べていただければと思います。
ここまで読んでいただきありがとうございました！
明日は、@piwiさんになります。
よろしくお願いします！
ウェブクルーでは一緒に働いてくれる方を絶賛募集中です！
興味のある方はぜひお問い合わせください。
https://www.webcrew.co.jp/recruit/
参考
https://qiita.com/chocode/items/fd51dd8f561e2a0fbd70
https://www.it-shikaku.jp/top30.php?hidari=00-00.php&migi=km00-00.php
キタミ式イラストIT塾 応用情報技術者
栢木先生の基本情報技術者教室