私が普段の課題解決に使っているアプローチを言語化した記事です。分割統治法に似ているけれど違和感を感じたのがきっかけで執筆しました。少し昔話を混ぜた話におつきあいください。
先日、職場の後輩の課題解決を手伝っいる中で、「この課題はこのままだと難しいからこういうステップにわけて、」と話したあとでそういえばこれが世間でいう分割統治法というやつかと、いまさら思い当たりました。今まであまり意識したことがなく、課題解決の中で自然にやっていたようです。（ん？でもなにかが違うような）
ではいつからこの考え方を使っているのだろうと思い返してみると、高専ロボコンをやっているときにはすでに無意識にやっていたように思いました。それもただひたすらに。ロボットを作っていればなにかしらの問題が起きるのが当然ですものね。
その中でも特に、赤外線通信のプログラムをフルスクラッチで書き直そうとしたときのことをよく覚えています。そこでは小さな課題を積み重ねることでプログラムを完成させる成功体験をしました。当時は「急がば回れ」という表現をしていました。
もともとは既存のプログラムの性能を改善したかったのですが、赤外線通信は目に見えないので他人が書いたプログラムのどこを変更すればよいかわかりません。いきなり16bitのデータを送信するプログラムを書こうとすると、当然のようにうまく動かないか動いても性能が悪くなります。「ではどうするか？」と考えたときに、下の箇条書きのように正しく動いているかどうかが確実にわかる粒度になるまでレベルを落として実験しようとなんとなく思いついたのでした（当時の自分えらい）。
- まずは搬送波を作って単純なオンオフの状態を送受信できるか。
- 次は1/0を交互に送って受信できるか。
- できるけど時間が経つにつれてbitがずれる。ずれないようにするには？
- 特定のbit列を送信したときだけ問題が起きる、これはなぜか、どうすれば回避できるか。
- 8bitでは足りない、16bit、24bitにペイロードを増やすには？
- 近くに別のコントローラがいると間違ったデータを受信してしまう、間違わないためには、間違ったデータを捨てるにはどうするか。
- 受信側が通信可能な範囲外に出るとロボットが走り続ける、これは簡単に回避できる。
などなど（実際はもっと細かったはず）。時間が経つとbitがずれるなどはやる前から想像がつきましたが、それでも先回りはしないでひとつずつ確認しながら進めました。どの程度ずれるものか、ということも感覚で把握しておく。ずれの程度がひどい場合は長いbit列の通信が成立しないのでこの確認は重要でした。ときには想定しなかった問題（特定のbit列を送信するときのみに発生する問題など）にも遭遇しました。
全体をいきなり書いても動かない。小さな実験を繰り返して動作を確かめながら道を開拓していけば、遠回りをしているように見えても最終的には早く達成できる、という気づきを得たのがこのときでした。このことから「急がば回れ」という言葉がとてもしっくりきたのでした。
これはボトムアップ型のアプローチであって、分割統治法とは違いそうです。一方で、比較的サイズが小さい問題に対しては、見通しが立つのでトップダウンな分割統治法と違いが見えなくてほぼ同じ結果が得られそうです。ゴールまでの道のりが見えた結果、課題をステップにわけることができたようです。各ステップが独立している場合は分業が可能なのですがそれは別のお話。
ボトムアップ型の「急がば回れ」アプローチ、今見返すとTDD（テスト駆動開発）にも少し似ているように感じます。小さな足回りを固めながら開発を進めていく。テストコードや、テストの自動化のようなことはまったく頭にはなかったですが、固めた足回りをもとに開発を加速する。
TDDをはじめて知ったときは「なんてすごいやり方なんだ！おもしろい！」と思ったのですが、親和性の高い考え方を持っていたので受け入れやすかったのかもしれません。
ここまで思い出をふりかえったところで、後輩との課題解決の話に立ち返ります。その課題は私にとってはステップを定義できる小さな課題に見えました。しかしそのその人の経験によっては未知の大きさの課題かもしれません。実は課題を適切なステップに分割することはそれなりに難しいことなのかもしれないと気づいたのでした。
余談。当時のみちのりを「赤外線通信ことはじめ」という名前の課題集・教育資料として公開していました。同じ課題でも取り組む人によってできあがるプログラムの質が違うのですが、当時の凄腕の後輩が作ったプログラムのほうが性能がよくてとても悔しかったことを思い出しました。資料が見つかったらこのブログで公開したいと考えています（残念ながら少し探したかぎりでは見つかりませんでした）。