カレーを作ろう
というのは、ソフトウェア開発系の会社で行われる教育などで、よく見かけることがあるテーマの１つです。なぜなら料理は、しっかりと"考えて"取り組むことさえできれば、
スコープマネジメント
スケジュールマネジメント
コストマネジメント
リソースマネジメント
リスクマネジメント
要件定義
外部設計
内部設計
など、様々なことを学ぶのに適しているからです。以前も言ったかもしれませんが、「家計のやりくりが上手な主婦（主夫）は、マネジメントの才能がずば抜けている」と私は常々考えています。おそらく、その辺の男性でマネージャーをしている人よりはるかに優れているのではないかと思います。
「男子厨房に入るべからず」なんて言い訳して料理をしようとしない男性は、おそらく適切なマネジメントが苦手なんじゃないでしょうか。
年功序列で出世したところでマネジメントのいろはがわかっていなければ、部下に対して偉そうに接するだけで、正しい指示も指導も当然できませんし、そういう人が上司となっている組織では、部下も何を指標にして仕事していいかわからず、日々、無能な上司の怒号や皮肉ばかり飛び交っているかもしれませんね。
さて。
少し脱線しましたが、ソフトウェア開発もカレー作りも、「モノをゼロから作る」と⾔う⽬的を果たすためにすることはまったく同じです。使うもの、作り方に差はあれど、考える手順はまったく同じなのです。
ならば、それを教育や指導に使わない手はありませんよね。
私が講師なら…たとえば、こんな感じにするでしょうか。
（ざっとやっつけで作ったので、誤字等あったらｺﾞﾒﾝﾅｻｲ）
1. 要求事項から「仕様」を⾒つけ出す
提案依頼書（ＲＦＰ）は本気で書いたら、何十ページにもなる超大作ですが、シンプルな場合は数ページで作られていたりします。とりわけ「これが書かれていなければダメ！」という規定はありませんが、最低でも
・事情／背景および課題
・目的
・範囲や目標
・条件（日程や選定方針など）
が記載されている必要があります。こうした情報を元に発注先となるＩＴ業者に「提案書」の作成を依頼するわけです。いわゆる"調達条件"を明確にすることが、このＲＦＰの主旨となります。
まぁたとえば、こんな感じのＲＦＰがあったとします。
んー…ちょっとハードルを上げすぎたので、チーム内に１人、テクニカルスタッフを設け、その人に限りググって調べるのはＯＫと言うルールにしましょうか。あと、チーム構成は料理がそこそこできる人を散らしておきたいですね。
もちろん、ここに書かれているすべての情報がマネジメント、あるいは設計の原資となるとは限りません。あちこちに無駄な情報、勘違いしてしまいそうな情報が含まれていたりもします。
そう、気分は「現国」です。
作者の意図（要求事項）が記載されている文を読み解かなければなりません。
たとえば、カレーをつくるという要求のなかに「朝食は８時以前には済ませてしまいたい」なんて要望があっても、「作る」ための初回要求事項には全く関係ありませんよね。前日の夜に作ってしまうのであれば、翌日の朝は温めなおすだけなので好きにすればいいだけです。
あえて気にするなら「温めなおすだけで済む」「温まりやすい」などの非機能要件を検討するくらいですが、教育向けにはそこまでハードルを上げる必要性は無いでしょう。
また「付け合わせは２品目以上あることが望ましい」なんて要求なんてあったりすると悩ませてくれます。
『「望ましい」は必須ではない』
と言うことにどれだけの人が気づけるかもポイントですね。最悪、無理してまで作る必要はありません。
「望ましい」は他社との相みつで差別化を図るポイントではありますが、メインの要求に対して行われる提案を疎かにしていい条件とはなりません。それにＵＩ／ＵＸをしっかりと理解していれば、とりわけメインの要求に対してだけでも差別化は十分図れます。
ですが、そのことに気づかないと、無理にでも作ることを前提にしようとします。これを新人や若手に課すと、時間内に話がまとまらなくなってしまうチームが出てきます。
そして制限時間が過ぎたら、答え合わせをします。
ここでは「列挙」と言っているので、ＲＦＰから「要求事項」だと思われる文章を箇条書きに列挙するだけでかまいません。読解力を元に、お客さまのニーズをどこまで把握できたかを確認するテストのようなものです。
ポイントは
「それが実現されていなければ、お客さまはどうなるか？」
という結果に対するお客さまへの"効果"を想像することです。
⽇本⾵カレー以外の趣向でカレーを作成したい
と書かれているのであれば、「日本風カレーを作った場合、食べる人はどう思うだろう？」と考えるのです。
⾷事は夜20時から開始したい
と書かれているのであれば、「20時になってもまだご飯ができていなければ、どう思われるだろう」と考えるのです。
2. 計画する
マネジメントの基本です。
というか、計画がなければマネジメントできません。計画なしにマネジメントしている気になっている人は気を付けてください。「臨機応変に対応する」と言うのは耳触りのいい言葉かもしれませんが、それってただ単に"後手に回らされている"だけですから。
すべてが順調と呼べるのは、
計画を立て、計画通りにコントロールできている
ときだけで、そのような様のことを言うのです。
ここでの計画には、主に
目標（どんなカレーを作るか）
ＷＢＳ（どんな作業／成果物があるか）
資材（どんな道具、食器、材料が必要か）
スケジュール（どの順番で作業するか、どれくらいの時間がかかるか）
を考えます。
さすがに教育で、これ以上細かく考えるのは酷です。本当だったら、リスクくらいは考える余裕を作りたいところですが、この教育テーマを１時間未満で終わらせようと思ったら、もう少しデフォルメしてもいいくらいです。
ですが、現実的なノウハウとして身につけさせたいなら、これ以上簡略化するのもどうかと言うことで、悩ましいですね。まぁ…新人や学生相手ならデフォルメするとして、３年生くらいのエンジニアなら、これくらいは考えさせてもいいかもしれません。
そして制限時間が過ぎたら、また答え合わせをします。
作業…ここではアクティビティ（具体的な活動、およびその状況）と呼んでいますが、アクティビティであれば、
・調理だけでいいのか︖
・下ごしらえや炒めたり、煮込んだり、盛り付けたり…
・⽶（ナン︖）は忘れていないか︖
・買い物は︖
・買い物をさらに因数分解すると、移動して、買って、さらに移動して…
きちんと「所要時間がかかる」作業を洗い出せているかが大事になってきます。先の例を挙げるなら、スケジュール的には
・⾷事は夜20時から開始したい
のであれば、そのニーズにあわせて各作業が逆算されているかどうか…と言う点がポイントです。このリミットは厳守ですから。
3. 概要を設計する
普通に料理する際は、あまり「設計書」って書きませんよね。メモを取ることすらないかもしれません。ですが「設計」はしてるんですよ。頭の中で。
あるいはすでに設計書が容易されているんですよね。料理本やCOOKPADなどのレシピがまさにそれです。もちろん主婦も活用しています。
料理を頭の中で思い描く行為は、外部設計…ＵＩ設計に似ています。食べる人の顔を思い描いてみると言うのも、ソフトウェア開発に従事している人なら、なんとなくわかるんじゃないでしょうか。ソフトウェア開発でも、利用者の利用シーンを思い浮かべてＵＩやＵＸを設計しますよね。
実際に「〇〇する」シーンを思い描くと言うのは、それだけで十分設計と呼べる行為です。ソフトウェア品質における
「利用時の品質」
と言うのも、突き詰めればその設計品質をこそ求めているわけなのですから。
そして制限時間が過ぎたら、また答え合わせをします。
ここでのポイントは
「最後に何が出来上がるか
第三者がイメージできない設計は"設計"とは呼べない」
という点です。書き方や表現の仕方等について、細かいことを指摘しても意味がない（そういう教育ではない）ので、説明をされたときに聞き手が頭の中でイメージできれば良しとします。
何をどう説明するかはチームごとに一任しましょう。
講師側の好みやスタンスを押し付けても教育にはなりません。
ただ、こういうポイントは見てあげた方がいいかもしれません。
・⾷べられるモノであること（必要最低限の条件）
・カレーと呼ばれる条件を満たすこと（機能性）
・⾒た⽬、味、⾹り、⾷べやすさなど（使⽤性/効率性）
・保管⽅法や再利⽤⽅法など（保守性/移植性）
その他、ＲＦＰの要求をすべて満たしている確認しなければなりません。1つでも漏れていたら、その分の対価は支払わなくてもいいということ、あるいは損害賠償を求められても文句は言えないということになりかねません。
重要なのは、
『最後に出来上がったものがどのようなものか︖』
『どんな機能を有しているのか︖』
ができるだけ明確になっており、読み⼿／聞き手がイメージできるものであるなのですから。その脳内イメージを補完できる情報は、色々あった方がいいに決まっています。できていなければ、おそらく「質問」を受けることになるでしょう。
4. 詳細を設計する
レシピ…「材料（分量）」と「作り方」を明確にします。
もしもググるとしたら「どんなカレーがいいか」を探すという点を除けば、ここが一番多いかもしれません。誰もが料理を得意としているわけではありませんしね。
もちろん、カンニングはＯＫです。
社会人になってまで『カンニング』を禁止するような試験を行うのはナンセンスです。すべてが記憶になければならない道理はありません。わからなければ、知らなければ、ド忘れすれば、答えを見直せばいいだけです。
そうやってスムーズに仕事が捗るのであれば、褒められこそすれ、責められる謂れはありません。カンニングＮＧというのは、現実に則していないという理由だけでも唾棄されるべき慣習といえるのではないでしょうか。
ビジネスパーソンになっても稀に見かけることがありますが、カンニングＮＧの教育とかって何なんでしょうね。
知識（暗記）に頼らなければならない仕事なんてものはありませんし、ただ暗記できましたってだけで優秀かどうかなんて判断できるものではありません。
「理解」の度合いを問うのであればまだしも、ただの「知識」にカンニングＮＧを求める意味が分かりません。ただの無駄です。
業務は「正確性」と「効率性」が両立されていなければなりません。その意味で、カンニングすることによる業務効率向上は理に適っているはずです。
ここでのポイントは『誰が作っても同じ結果となる』ことです。そうでなければカレーをつくるという店を運営することはできません。ご家庭でカレーを作るのであれば、ギャンブルのように毎回毎回異なってもいいかもしれませんが、お客さまがいて要求（注文）されているのであれば、品質は常に高い状態で安定していなければ、提供する側として
信用
を得られません。
たとえば、インド⾵チキンカレーの作成⼿順なら
みたいな感じでしょうか。勝手に「おいしいと思って」なんて言いながらレシピを無視するような人でもない限り、それなりのインド風カレーができていることでしょう。
5. 最終評価
本当なら、各自それぞれ実際に作ってみてもらうのが一番手っ取り早いんですけどね。会社ではなかなか難しいと思いますので、各チームごとに発表をしてもらうと言うのもいいかもしれません。
評価する際は
・要件をすべて満たしているか
→３⽇⽬まで飽きがこなさそうか
→普段の日本風カレーと異なる部分がハッキリしているか
・計画通りのスケジュールで完成できるか
・自分自身が⾷べるイメージはできるか
・美味しそうか
等を意識して評価することです。評価が⾼いほど、お客さまが喜んでくれるカレーとなっている（かもしれない）…と⾔うことです。そして最後に、
・「作るモノ」「作り⽅」の説明が最もわかりやすかったチーム
・一番美味しそうなカレーのイメージができたチーム
をそれぞれ選ばせると、
「どこに着目するとよかったか」
「どんな表現がよかったか」
「どこに重きを置いた説明がよかった」
など、他人から学び取れるところが見えてくるのではないでしょうか。特に設計時点でお客さま（役）に「美味しそう」というイメージを強く与えることができたチームは優秀かもしれませんね。
カレーもソフトウェアも、基本は同じ
要求や要望、すなわちニーズを聞いて
「そのニーズを実現する」「その結果、満足させる」
それだけです。受注生産系の職種ではこの基本的コンセプトは変わりませんよね。そもそもカレーとソフトウェアの作り⽅の流れに類似点が多いのはＩＴ業界が、正確には『ＩＴサービス産業』と⾔って、製造業の側⾯を持ちつつも、飲⾷産業と同じサービス業の１種だからだと私は考えています。
ちなみに。
⾃炊し、⼀⼈で⽣活をやりくりできるようになると、そのノウハウを仕事に活かしやすい点が多いのもＩＴ業界の特徴の１つではないでしょうか。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。