某日、某所、とあるエンジニアにある依頼が入った。
シーフードカレーが食べたい！
作るよ！
カレーの作り方は知ってるし、余裕だぜ。
何も考えずに作ってみる
買い物に行く
シーフードカレーということはシーフードの入ったカレーのことだな・・・
カレールウ、じゃがいも、にんじん、玉ねぎ、肉…それと忘れちゃいけねえ、シーフードだ！！
エビとホタテとイカを買っとけばいいや
殻付きのエビ、イカ1杯、殻付きのホタテを購入した。
調理する
カレー作って、そこにシーフードを入れればシーフードカレーだろ
じゃがいも、にんじん、肉を切っていく。
肉を炒めて、野菜を炒めて、水を入れ、沸騰したらカレールウを入れる。これでカレーは完成。
シーフードの下処理わからんのだよなぁ…
エビは殻を剥いて、イカは内臓を抜いてぶつ切りでいいかな？あとはホタテは…こいつどうするんだ？とりあえず無理やりこじ開けて身をほじくろう…
処理を終えたシーフードをカレーの中に入れてしばらく火を通す
よし完成だ！シーフードカレーにはなったろ！
あっ、ご飯炊くの忘れた・・・
まだ完成しないのかなぁ。。。
実食
だいぶ時間掛かってたけど、なんだかんだ美味しそう。
いただきまーす！！
なにこれ、、エビは背わた入って生臭いし、イカは軟骨が入ってる、、ホタテも砂が、、、というかシーフードカレーに肉入れないし、、、
食事を終えた嫁は某料理漫画の美食家のような顔をしていたそうな。。。
システム設計
今回うまくシーフードカレーを作れなかったのはなぜでしょうか？
実は似たようなことが、エンジニアではよくあります。
このような自体が起こらないよう「システム設計」が行われます。
システム設計とは
システムを設計することですが、色々な手法があります。
今回はウォーターフォールモデルという手法を紹介します。
ウォーターフォール型とは、システムの開発を「基本計画」「外部設計」「内部設計」「プログラム設計」「プログラミング」「テスト」という工程に分けて順に段階を経て行う方法です。前の工程には戻らない前提であることから、下流から上流へは戻らない水の流れにたとえてウォータフォールと呼ばれています。
http://www.okapiproject.com/computer/leran_comp/sysdev/sd_01_003_0.htm
要件定義
要件定義では、その名の通り、要件をクライアントから聞き出した上で要件定義書にまとめることです。
相手の要望や予算を確認した上で、ざっくりとした工数スケジュールなども決めていきます。
外部設計/基本設計
要件定義で決まったものを確定するフェーズです。
外部要因（インフラやセキュリティ等）の確認を行ったり、実際に要件に対してどう対応するかを検討します。
また、実際の画面設計など実際に動くものがどんな感じになるのかをクライアントと共有します。
内部設計/詳細設計
内部設計では外部設計で決めた設計を処理やコードに落とし込みます。
クライアントには見えない（共有する必要のない）専門的な設計を行っていきます。
実装
ここまで行って始めて実装が始まります。
実装が始まるまで、時間が掛かるのがウォーターフローモデルの欠点ですが、着実に仕様を固めて進んでいくため後々の実装が楽になることがメリットです。
まとめ
ここまで書いて理解できていれば問題がないのですが、正直最初良くわかりませんでした。
そこで実際にウォーターフローモデルを取り入れたらどうなるのか、もう一度シーフードカレーの作成フローを見ていきましょう。
もう一度シーフードカレーを作る
要件定義
またシーフードカレーが食べたくなった
OK任せろ。ちなみにどんな具材を入れてほしい？
生の具材だと高いし、冷凍のシーフードミックスでいいよ〜
マジかよ。先日の具材無駄だったんか。
肉は何が良い？豚肉？鶏肉？
いやシーフードカレーに肉要らないから！
あとジャガイモも使わなくて良いよ
あ、福神漬けも買ってきて！
米は雪若◯がいいなぁ
要望が多い…
具体的に仕様を突き詰めていくと、お互いの認識が一致して完成形がより鮮明になります。
今回の例では、
- シーフードカレーが食べたい
- シーフードは冷凍のシーフードミックスで大丈夫
- 肉、ジャガイモは要らない
- 米は雪若◯がいい
- 福神漬けも欲しい
という要件が定義されました。
仕事において、クライアントから仕様が全て綺麗にまとまってくることは少ないです。
なぜならクライアントは専門知識が不足していることが多いため、エンジニア視点の仕様になっていないことがあるためです。
※ 本来であれば作る側の方が専門的な知識があるので、「安く済ませるために冷凍シーフードミックスはどう？」「今回肉は入れる？」など確認していくのが理想です
エンジニアから必要なものを確認することで互いの考慮漏れを防ぐことが出来ます。
外部設計/基本設計
作るものの具体的なイメージは掴んだからチラシで買うものを決めよ
お、欲しいものは全部売ってそう。
しかもシーフードミックス安売りしてる。
要望通りのシーフードカレーを作れそう！
しかもちょっと安く作れそう！
本当！？やったーー！！
相手の要望（要件定義）に対して、実際にどうしていくかを決めて、クライアントに共有することが出来ました。
外部システムとの仕様（今回はスーパーのチラシで売っているか）によっては要件通りに行かないことや想定外のコストの増減も発生します。
今回は口頭での確認で済む話でしたが、きちんとした仕事の場合、画面の遷移など画像やスライドにまとめて、よりわかりやすくクライアントに共有できると良いです。
そういった仕様の調整やコストの見積もりを密に行うことでクライアントに安心感を与えたり、今後の見積もりを把握できるようになるので、トラブルを抑えることが出来ます。
詳細設計/内部設計
C◯◯KPADでレシピ確認しとこ
シーフードってカレーに入れる前に炒めておくんか、しかも料理酒も使うし。。
あ、ご飯先に炊いておかんとなぁ。。
というか海鮮の下処理めっちゃ大変じゃん、冷凍で良かった。。
①米を炊く
②カレーを作る
③シーフードを炒める
④合わせる
で行こう！
具体的な内部実装を決めていくのが詳細設計です。
どのように実装を進めていくかフローをまとめたり、注意点を洗い出していきます。
調査を進める中で「ここは時間が掛かりそう、ここは並行で出来るから時間が掛からない」など工数に影響する部分も出てきます。
工数が変わる場合、ある程度見積もりが経ったら都度クライアントに共有していきましょう。
実装
買い物行ってこよう。今回はジャガイモと肉は買わないで、シーフードミックス買えば良いんだな・・・
〜買い物が終わり〜
素材買ってきたし調理に入ろう。最初に米を炊いて、待っている間にカレーを作りつつ、シーフードを解凍して火を通して、、、
外部設計・内部設計がしっかり決まっているので、迷うことはありません。
前回とは比べ物にならないくらいテキパキと動けています！
（おまけ）単体テスト・統合テスト
一応味見しておこ、、ﾍﾟﾛｯ…これは…硝酸カリ…じゃなくて完璧やんけ…！！
完璧なものをクライアントに提供するためにはテストは必須です。
最後の仕上げ直前に味見をするより、都度味見をしていった方が修正が効きやすいです。
要所要所でチェックを行うことを単体テストといい、最終的なチェックは統合テストといいます。
実装でも同じで、要所要所でチェックを行ったほうが不具合の原因を特定しやすくなったり、最後の最後で取り返しのつかない不具合が起きにくくなります。
まとめ
ということで、今回はシーフードカレーの作り方を紹介しました。今回はシステム設計を料理に例えて解説しました。
最も根本的な失敗の原因は下調べをせずに行動を起こしたことです。
これはエンジニアの開発でも同じで、何かを作ることになった際、確認を怠ると要件を満たさないものが生まれたり、無駄な工数が掛かってしまう事が起きます。
仕事としてエンジニアとして働く場合、そういったことを意識して働けるとクライアントに喜ばれる仕事ができます。
ここまで読んで頂きありがとうございます！
コメント