問題を早く解くために検討すること

paizaというWebサービスがある。

ITエンジニアの転職情報サービスなのだが、出題された課題を制限時間内に解くコーディングスキルチェック機能もある。

paiza.jp

純粋に問題を解くのが面白くて、少しやってみたのだが、

制限時間を与えられると、如何に効率的に早く解けるかを考えるようになる。

そこで気づいたことを以下に書いてみる。

問題を分解する

複雑で一筋縄ではいかない問題を考え続けていると、時間は経っているのに思うように進めていない時がある。

そんな時は、一度冷静になって問題を分解できないか考えてみる。

ひとかたまりに見える厄介な問題を、普通に対処できる問題の集合に分解できないだろうか。

プログラマなら関数を定義する。

対処できる問題の一つを全体から外に切り出す。

これで全体からは関数の中の詳細が見えなくなる。

適切に抽象化さていけば、問題全体は遥かにスッキリして、分かりやすい秩序が見えてくる。

さらに、解く者にとっても、小さいながらも確実に前進している実感がある。大きい問題の前に足踏みしていたような停滞感は軽減されるはずだ。

思えばプログラマに限った話ではない。

『バガボンド』で、宮本武蔵は一乗寺下り松で吉岡一門70名と斬り合うが、

ここで武蔵が考えたのは、 1対1の決闘を流れるように70回繰り返す、というやり方だった。（逆に吉岡側は1対70の決闘を一遍にやりたい）

バガボンド(26)(モーニングKC)

話が逸れたば、何かに時間がかかってしまっている時は、問題を切り分けるというやり方を検討したい。

急いで局所的な最適化をしない

私がコーディングする時の流れは大雑把に言うと以下だ。

1. 期待通り動くように書く

2. よりシンプルに読みやすくなるように推敲する

推敲すること自体は大切な習慣だ。「動く」だけのコードをコミットされても困る。当然リファクタリングの余地がないか検討してみる。

しかし、私は時々、まだ問題全体が解けていないにもかかわらず、ある一行を推敲するために時間を使っている自分に気づくことがある。

なかなか定量的な評価は難しいが、この早い段階で局所的な最適化にかける時間があまり効果的ではないように感じられるのだ。

つまり、局所的には完璧でなくとも十分役立つコードを組み合わせて問題全体を解く => リファクタリング

という流れの方が完了まで早く辿り着けるのではないだろうか。

そういえば、37signalsの書籍『小さなチーム、大きな仕事』に似た記述があったので引用する。

建築家は、階の設計が終わるまではシャワーにどのタイルを使うか、また台所にどのメーカーの食器洗浄機を置くかなんて気にしない。 そうした細かなことは後で決めた方がいいとわかっているのだ。...（中略）

問題ではないところで気が取られてしまい、結局は変化していくようなことに対する決断に無駄な時間を費やすことになるのだ。 しばらくの間は細かいことは気にしないことだ。まず根本的なところを固めて、特殊なところは後で考えればいい。

小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則

以上は、特に目新しい発見ではないが、ついつい頭から抜け落ちている時がある。

これらが強く意識されたのは制限時間が与えられたり、問題を解くのにかかった時間が計測されて明確に表示されるからだろう。

つまり、普段からポモドーロテクニックなりで工夫して、どの課題にどれだけ時間をかけたか明確に分かるようにしておけば、 早く解くための工夫、効率化は自然に生まれてくるのだと思う。 自分の時間管理に活かしたい。

アジャイルな時間管理術 ポモドーロテクニック入門