問題を難しくするな。
- ほんの少しの厄介さも、数が増えれば手に負えなくなる。
- そのような厄介さを確実に減らしていこう。
- フールプルーフを考えていないシステムは、複雑度が上がりすぎると手に負えなくなる。
- UIが利用者にとって不可思議な前提を要求したり、押し間違いなどへの対策がないなど、そういう項目が増えすぎると手に負えなくなる。32桁の英数字をタイプすることを考えてみよう。これは128桁などのなったときには、タイプミスを生じないことは考えにくい。そのようなときには、本来の操作をすることには無関係のところで手に負えなくなってしまう。
- 性能がこういう状態では出にくくなるとわかっているギリギリのところで動作させようとするな。
- 雪道で、道の端っこを歩こうとするようなものです。いずれ側溝に足を突っ込むことになります。
- ものごとが100%精度でうまくいくようにはできない種類の問題に対して、100%の精度がでたらという前提で 話を進めるのはやめよう。
- 考えている手法がうまくいかない場合の、「逃げ」の手法を考えておこう。
- 物事が自分の予想しているとおりに簡単に解決できるとは限りません。常に「逃げ」の手法を考えておきましょう。
- CPUの性能を上げれば済む問題なら、CPUの性能を上げよう。
- 問題を明確化しよう。
- 問題が解決できていない状況では、問題を明確に記述できていないことが多い。
- 問題を明確に記述できていないから、必要以上に騒ぎ立てる人も出てしまう。
- 問題を単純化しよう。
- 前提条件の少ない形で問題を記述しよう。依存しているものが多い記述ではなく、依存性の少ない記述にしよう。単純化することで、「さまざまな問題が込み入った問題」から「単純化された小さな問題が、いくつか同時にある問題」となります。単純化された小さな問題は、「さまざまな問題が込み入った問題」よりもはるかに解きやすくなります。
- 解決できた部分については、解決できたことを共有しよう。そうすることで進展した部分での成果を使って次の解決がしやすくなっている。
- 問題の全てが同時に解決することはない。そこで１つの問題を解決したときに、「まだ、○○が解決できてないじゃないか」などと言ってはいけない。えてして、そのような発言によって、課題解決にあたっていた人のやる気をそぐことになる。
- 「ベストを目指すな」、「許容できる設計をしよう」
- それがベストであることを示すのは、ほとんどの場合とても面倒です。ベストを見つけてベストを実装するのはとても厄介です。でも、必要なことは、使う状況の範囲でその手法が十分に問題なく使えるかということです。例をあげれば、最適なソート（ならびかえ）のアルゴリズムを実装するのと、バブルソートを実行するのでは、目的によって使い分けるべきだということです。利用する状況によってはバブルソートでも十分なことがあります。高速なソートアルゴリズムを実装するのは楽ではありません。（ここでは、作業の例としてあげているのであって、あなたが解決する問題の中では、別の作業です。ですから、STLのsortを使えば一発じゃないという突っ込みは不要です。）
繰り返し言う。
問題を過度に難しくすれば、どんな問題だって解決不能になる。
開発に投入できる人員と、許された期間の中で、妥協できる性能を出すことです。
「ベストを目指すな」、「許容できる設計をしよう」
付記：
問題を簡単にするための例を書き始めてみたが、逆に発想を制約してしまうことに気づいた。