職業柄、よく「プログラミングを覚えたいけどどうすりゃいいの」と相談されますが、手順を機械に教えて動かすという非常に単純な説明しかできず、全容を理解できるようにうまく説明できずに困ってました。
そんな中、GWに色々レシピをみながら料理をしていて、プログラムというかソフト開発の全容はなんぞやを教えるのに「プログラムを作ることは誰でも確実に同じ味の料理を作るレシピを作ることに等しい」ということを教えればイメージしやすそう、ということに気が付きました。
ソフト開発屋の私から見ると、料理という作業は各手順・要素をソフト用語に変換してプログラムを頭の中でイメージしてプログラムを実行、結果を見て手順やパラメーターを修正して改善しているような感覚になります。
基本的な用語は以下のように変換できますね。
- レシピ＝プログラム
- 料理を作る＝プログラムを実行して結果を得る
- キッチン＝プログラムを実行する環境
- キッチンの広さ＝メモリ容量
- 調理器具・加工方法＝一定の共通手順をまとめた関数(鍋に火をかけるとか千切りにするとか)
- 調理器具に入れる材料の種類と分量＝関数の引数定義とパラメーター設定
- 加工手順で使う材料と加工方法の詳細＝関数の引数定義
- 調理時間＝プログラムの処理速度
より専門的な部分も変換すると以下のようになります。
- 並行して行う作業＝並列処理
- 同時にできない作業＝クリティカルセクション
- 材料分量・火加減・時間の正確さ＝数値処理精度
- 調理場の使い方＝メモリ確保と用途の定義、および開放
- 手順間違えたときのリカバー処理＝フェールセーフ処理
- これをやっては絶対だめ手順＝Assertion
- 「状況に応じて」＝条件分岐(＆曖昧な条件は失敗の原因)
- 後片付け＝一時ファイル削除・メモリ解放・デバイスリセットなどの終了処理
さらにソフト開発にまで踏みこむと以下のようになるかと。
- 味の調整＝プログラム汎用化のためのパラメータ設定
- 失敗の割合＝バグの量（想定している条件下で必ず同じものを作れるかどうかのレシピの品質）
- 初期トライアルコスト＝開発費・教育コスト
- 準備できる材料の質・量および確保できる調理時間＝開発・生産リソース
- レシピの公開＝リリース＆テスト＆フィードバック
- 失敗しないための事前知識＝開発経験
説明の仕方としてはこんな感じ。
- レシピは記載されたとおりにしか実行されない(記載がなければその作業は行われない)
- レシピの記載を間違えれば思った通りの味は得られない
- レシピの記載が曖昧だと作る側が勝手に判断して結果が一定しない
- 手順やあまり細かくしすぎると料理に必要な時間が増え時間もかかる
- 要望が多いと手順が複雑化する
- 特殊な調理器具や特殊な材料はあまり汎用性がないことから入手が困難、もしくは自作する必要がありでコストがかかる
- 手順を汎化・単純化させ、すでにあるものを使うようにすれば、手順も削減されてかつ失敗も減る
- 同時に使う調理器具は少なくして使ったら、すぐ片付けをきちんとして必要な器具の無駄を省く
- 調理場は広いほうが作業が早い
- リソースがギリギリだと、ちょっと失敗(材料が腐ってたとか、調理器具がちょっと違うなど)しただけで完成までの時間が長くなる
- 片付けの頻度が多いとなかなか料理が進まない
- 前提となる環境がそろわない(海外では日本特有の食材が入手できないなど)とレシピは使えないか変更を余儀なくされる
- レシピ作成はその料理に向き合っている経験者が継続してやったほうが品質が良くなる
ソフト開発をよくわかってない人への説明にも使えそうです。