「引っ越しをする」と言われて、いきなり最初の一手を出せる人はいません。大きすぎて、どこから手をつけるか分からないからです。プログラミングでも同じことが起きます。「家計簿アプリを作る」と考えた瞬間に固まってしまうのは、能力の問題ではなく問題の大きさの問題です。
そこで最初の道具が分解です。大きな問題を、それ以上考えなくても手が動く大きさまで割っていきます。
カレーを作る、を分解する
「カレーを作る」を一段割ると、こうなります。
- 材料をそろえる
- 材料を切る
- 炒める
- 煮る
- ルーを入れて仕上げる
まだ「材料を切る」は大きいので、もう一段割ります。
- 玉ねぎを薄切りにする
- じゃがいもを一口大に切る
- にんじんを乱切りにする
ここまで来ると、もう迷いません。迷わずに手が動くところが、分解の止めどきです。
止めどきの目安
分解しすぎても困ります。「包丁を持つ」「刃を下ろす」まで割ると、かえって全体が見えなくなります。目安は次の2つです。
- その作業を人に頼めるくらい、内容がはっきりしている
- 「これってどうやるんだっけ」と手が止まらない
もう一つの例: 家計簿アプリを分解する
料理だけの話ではありません。「家計簿アプリを作る」も同じように割れます。
- 支出を記録する
- 記録を一覧で見せる
- 月ごとに合計する
- グラフにする
さらに「支出を記録する」を一段割ると、「日付と金額と分類を受け取る」「入力が正しいか確かめる」「ファイルに書き込む」になります。ここまで来ると、それぞれが数行から数十行で書けそうだと想像がつくはずです。作れる気がしない、から、作れそう、に変わる瞬間——それが分解の効果です。
分解はそのまま設計になる
分解した1つひとつは、のちのC言語では関数という部品になります。「材料を切る」が1つの関数、「炒める」が1つの関数、といった具合です。今それを知る必要はありませんが、いま紙の上でやっている作業が、そのままプログラムの設計図になるのだと知っておくと、この訓練の意味が見えてきます。
もう一つ、分解にはうれしい副作用があります。どこで失敗したかが分かりやすくなるのです。「カレーがまずい」では原因を追えませんが、「炒めが足りない」なら直せます。プログラムでも、細かく分けてあるほど不具合の場所を絞り込めます。この考え方は、第3トラックのデバッグでもう一度出てきます。
分解は、プログラミング的思考の第一歩であり、4つの道具のなかで最もよく使うものです。プロが大きな仕事を任されたときにやることも、結局は同じで、まず紙に書き出して割ることから始まります。難しい問題に出会ったら、まず「これは何と何でできているか」と問いかけてください。答えが3つか4つ出てきたら、それだけで前進です。手が止まったら、それは能力ではなく粒度の問題だと思い出してください。