ビジネススクールに行き始めたり、小さいながらも組織を任されていることもあって、以前に比べて、プランフェーズと実行フェーズのバランスをいろんな観点でケアするようになった。で、それらのプロセスって、自分の中ではソフトウェアを作ってた頃の感じに似ているような気がしている。
どういうことかというと、机上の spec では全部のバグはでなくて、コードを書いてリアルに実行しないとバグは消えない。つまり現実とリンクしていない机上の spec はあくまで机上の spec でしかないということ。そういう意味では、社会人大学院というスタイルのビジネススクールである早稲田大学ビジネススクールは、僕の中では理論と実践が並立する非常にバランスのいい環境だと思っている（と、少し持ち上げておきましょう）。
ちなみに spec もなくコードだけ書いた場合、一見良さそうに見えたとしてもすぐにスケーラブルさを失う（または生産性を失う）。特に複数でコードを書いている場合には、共通の理解素地としての spec は必要で、decent で scalable で誰が読んでもわかるコードなんてちょっとなかなかない。
で、ちょっと強引にこじつけてみるけれど、企業戦略とか経営企画に近しい仕事をしているんだったら、そういう戦略論について理解することはとりあえず必要条件だという気がする（もし理解せずにそういう部門のマネージャーになったなら、すぐに学習しはじめたほうがいい。さもなくは、さっさとリタイアしたほうが周りのためになる）。
そういう、いわゆる spec についての理解を深めていくのは必要だけれど、でもそれはやっぱりあくまで spec に過ぎないのであって、リアルに実行できる（scalable で decent な）コードを書けることも、現場にいるマネージャーには必要なんじゃないかと思う。
そういう感覚から、アーキテクチャへの理解とコードレベルの理解、両方を深めていくことが当面の自分の課題なんだろうな、という気がしている。で、その両方、つまり理論と実践を並立させることが自分の性に合っているということも。
