小飼弾氏の記事『転職活動する暇があったらブログを書け』で 「1から100までの数をプリントするプログラムを書け。ただし3の倍数のときは数の代わりに 'Fizz' と、5の倍数のときは 'Buzz' とプリントし、3と5両方の倍数の場合には 'FizzBuzz' とプリントすること」 という問題を見て、「これが書ければプログラマとして認めてもらえるのか。ハードル低っ」と思いました（ハードル下げたくて下げているわけじゃないでしょうが）。 まあ、その時はそう思っただけだったんですけど、昨日の夜になって、試験官に「確かに正解だけどさあ」と言わせるようなものを書いてみたらどうだろう、とか思いついてしまいました。 思いついたら、なんかもうサンプル品を書かずにはいられません（苦笑）。 そんなわけで、日曜の午後をつぶして、「FizzBuzzをムダに難しく書いてみよう」というお題でコードをいくつか書いてみま

よく受託開発案件などでは、ユーザーの現状をヒアリングし、問題点の洗い出しを行うことがあるかと思います。洗い出した問題点に基づいて業務を再考し、適切な形へと組みかえる、BPR（ビジネスプロセス・リエンジニアリング）と呼ばれるものです。 実際、どのように分析して対応策を考えていくかについては、世の中にたくさん記事やら解説やらが揃っていますのでそちらを参考にしてもらうとして。 わたしは、気のせいや考えすぎのきらいがあるのですけど、どうにも見ていると、ある1つの「正解」をあてはめよう、としている雰囲気が感じられるのです。特にその風潮は、実装＜設計＜分析……というように、上層へ向かえば向かうほど強まっていると思えます。 恐らくは分析時などに限定した話題でもなく、プログラムの組み方や設計の行い方など、エンジニアとして関わる分野ほぼ全てに見受けられる傾向なのでしょうが。 要件定義はこうするべき。 ビジネ