問題を分解する（Decomposition）

「引っ越しをする」と言われて、いきなり最初の一手を出せる人はいません。大きすぎて、どこから手をつけるか分からないからです。プログラミングでも同じことが起きます。「家計簿アプリを作る」と考えた瞬間に固まってしまうのは、能力の問題ではなく問題の大きさの問題です。

そこで最初の道具が分解です。大きな問題を、それ以上考えなくても手が動く大きさまで割っていきます。

カレーを作る、を分解する

「カレーを作る」を一段割ると、こうなります。

• 材料をそろえる
• 材料を切る
• 炒める
• 煮る
• ルーを入れて仕上げる

まだ「材料を切る」は大きいので、もう一段割ります。

• 玉ねぎを薄切りにする
• じゃがいもを一口大に切る
• にんじんを乱切りにする

ここまで来ると、もう迷いません。迷わずに手が動くところが、分解の止めどきです。

止めどきの目安

分解しすぎても困ります。「包丁を持つ」「刃を下ろす」まで割ると、かえって全体が見えなくなります。目安は次の2つです。

1. その作業を人に頼めるくらい、内容がはっきりしている
2. 「これってどうやるんだっけ」と手が止まらない

もう一つの例: 家計簿アプリを分解する

料理だけの話ではありません。「家計簿アプリを作る」も同じように割れます。

• 支出を記録する
• 記録を一覧で見せる
• 月ごとに合計する
• グラフにする

さらに「支出を記録する」を一段割ると、「日付と金額と分類を受け取る」「入力が正しいか確かめる」「ファイルに書き込む」になります。ここまで来ると、それぞれが数行から数十行で書けそうだと想像がつくはずです。作れる気がしない、から、作れそう、に変わる瞬間——それが分解の効果です。

分解はそのまま設計になる

分解した1つひとつは、のちのC言語では関数という部品になります。「材料を切る」が1つの関数、「炒める」が1つの関数、といった具合です。今それを知る必要はありませんが、いま紙の上でやっている作業が、そのままプログラムの設計図になるのだと知っておくと、この訓練の意味が見えてきます。

もう一つ、分解にはうれしい副作用があります。どこで失敗したかが分かりやすくなるのです。「カレーがまずい」では原因を追えませんが、「炒めが足りない」なら直せます。プログラムでも、細かく分けてあるほど不具合の場所を絞り込めます。この考え方は、第3トラックのデバッグでもう一度出てきます。

分解は、プログラミング的思考の第一歩であり、4つの道具のなかで最もよく使うものです。プロが大きな仕事を任されたときにやることも、結局は同じで、まず紙に書き出して割ることから始まります。難しい問題に出会ったら、まず「これは何と何でできているか」と問いかけてください。答えが3つか4つ出てきたら、それだけで前進です。手が止まったら、それは能力ではなく粒度の問題だと思い出してください。