設計フェーズでプログラミングを行うライフハック

現在、某SIerでお仕事させていただいてます。スーツを着てネクタイを締めて毎朝9:00に出勤しています。おかげでずいぶん健康的になりました。
で、今はお決まりのExcelなお仕事などをしています。詳細設計書とかクラス設計書とかプログラム構造設計書とか言われるもの。要は仕様は決定しておりプログラムの詳細を書く例のアレです。こういった設計書の目指すところはおそらく「誰が見てもプログラムを書けること」だと思います。まぁ、ぶっちゃけた話、ムリだよね(というかすごいコストかかるよね)。
なぜ、ムリか。それは机上で設計するからです。頭の中で考えたり、紙にチャートっぽいものを書いてみたりして、プログラムの中身を考えてそれを日本語で記述する。つまり、自分のなかでコードに変換されたものを日本語に変換して書き写す。それを実現できるコードが頭の中に浮かんでいるのに、もう1回翻訳する。無駄だなぁ。
で、タイトルに戻ります。「YOU、そこまでするならプログラム書いちゃいなYO!」というわけです。プログラムを書いてから、そのとおりにエクセルに書く。これ、最強(というほどたいそうなものじゃないけど)。それにプログラム書いてると案外思ったようにいかなかったり、もっとよい方法を思いついたりするので机上で考えてExcelに向かうよりよっぽど精度の高い設計書になること請け合いです。あと、これは副産物のようなものですが、新人を育てやすくなります。設計書を書いた時点でプログラムはできてるので、リスクを取ることなく新人に振ることができます。新人が書いたプログラムで問題なければそれでよし、ダメなら自分の作ったのと差し替えちゃえばいいです。
そしてプログラミングフェーズではテストコードを書いてテストします。品質が上がっていうことなしですね。
何が言いたいかというと、「現実はそう簡単には変わらない」ので「やれる範囲でベストを尽くそう」というのと「楽ができるのなら楽しよう」と。
現状の開発プロセスが歪なのは現場の開発者なら多かれ少なかれ感じていると思います。「俺が世の中を変えてやるぜ！」というのも結構ですが、理想と現実が乖離しすぎていると疲れちゃいます、絶望しちゃいます。なので、時には見えないところで舌を出しながら上手く立ち回ってください。そして少しずつ変えていきましょうよ。