「プログラミングと設計は本来切り離せないものなのでは」に対して

プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指してについて。
結構前に書いた記事だったので、今頃になってここまで大きな反響が得られるとはまったく驚きです。やはり、はてブのトップページ(ホッテントリ呼ばれるらしい。)に出るとすごい目立ってしまうのですね。
多くのコメントは現役のプログラマーの方々からだと思うのですが、皆さんからいただいたコメントを見ると、開発の現場で日ごろから矛盾を感じながらも日々設計や開発の仕事をされている方が多いみたいですね。私としては共感していただける多くの仲間がいるということで、ちょっと勇気付けられたというか本当に嬉しく思いました。
また、中にはマネージャーや年配のSEの方からと思われる意見もいくつかありました。従来のやり方になんとなく問題を感じてはいるのだけれど、オブジェクト指向やアジャイルと言われてもなんとなくやり方の実感がわかないし、危険を冒してまでも実績のないやり方を積極的に採用するのもどうかなという方も多くいらっしゃるかもしれません。
これは、あくまでもプログラマーとしての私の考えなのですが、

運悪くそういう環境で働くことになったら、「変化の触媒たれ」という達人プログラマーの心得でもって徐々に時間をかけて考え方を変革していってもらうよう努めています。多くの場合その人がプログラミングという行為を設計と結びつけて考えられないのは、単にその人の経験不足、知識不足ということが多く、リファクタリングなどでいかに無駄なコーディングが減らせるか、生産性が向上するかということを実演して見せれば簡単に現代的な開発におけるコーディングと設計のつながりを正しく理解してもらえるようになることも多いと思います。

と書いたとおりで、結局食わず嫌いというか、新しいプログラミング言語や開発環境の特徴を理解していただくことができれば、プログラマーとSE、マネージャーは本来、お互い技術者としてもっと分かり合えるようになれるはずという楽観的な期待もあります。
ソフトウェアアーキテクトほど魅力的な職業はない！？（アメリカでは） - 達人プログラマーを目指して
で既に書いたことなのですが、

現在のIT業界の状況は幕末の日本の危機的な状況と非常に似ているところがあるなと思えるところがあります。ちょうど、NHK大河ドラマの竜馬伝も大政奉還に向けていよいよクライマックスを迎えようとしているところなのですが、ドラマの影響もあってか、最近ますますそのように感じてしまいますね。幕府とか諸大名などの旧勢力をSIerに、クラウドなどの新技術はちょうど黒船にたとえることができます。

やはり、多くの職場で20年〜30年も前のやり方を踏襲している日本のSIの状態は、幕末の日本とよく似ていると感じざるを得ないところがあると思います。（ちょっと大河の影響を受け過ぎなのですが。）オブジェクト指向やイテレーション開発など、得体の知れないものは今後も使わないと言っているのは、海外の新しい技術を学ばないばかりか、頑なに古いやり方に固執して、武士道といった精神論や刀、槍、火縄銃で、蒸気船や最新のライフル銃を装備した欧米列強と戦争をするようなものなのですから。*1上の記事ではクラウドを黒船にたとえたのですが、オブジェクト指向のような基本技術は、ちょうど蒸気機関とか熱力学とかもっと根源的な知識に相当しますね。今の日本のIT業界の状態はこういった基礎技術に対する理解があいまいなまま、とにかく、SOAやクラウドなどのバズワードだけはなぜかありがたがる傾向があるのですが、それだと、結局、フランスから不当に高い金額で蒸気船を購入して得意になっている幕末の幕府海軍と同じで、結局、いつまでもIT先進諸国と対等な立場になることはできないのだと思います。
残念ながら、竜馬のように将来に向けた明快な解決策を思いつかないのですが、（だれでも思いつくことですが）まずは

• 会社や大学におけるプログラミングやソフトウェア工学の教育をもっと尊重する
• プログラマーの専門性やスキルを正しく評価し、相応の職務権限や報酬を与える
• プログラマーに勉強会や自習などの機会を与える
• 高性能開発PCなど現場の開発環境の改善にもっと真剣に取り組む
• 時代遅れの慣習や規約を廃止する
  • ×開発フェーズになるまでいっさいコードを書かない
  • ×アルファベットの1〜2文字の業務区分をクラス名につけたがる
  • ×コードと一対一対応にするような無意味な詳細設計書の作成に時間とコストを浪費する
  • ×コード変更コメントをコード中に直接履歴として残す
• PG→SE→PMというような実態に合わないキャリアパス（身分制度？）を廃止する
• SE、PGなどというあいまいな区分を廃止し、作業内容に合わせてより合理的な分類を行う*2
  • ビジネスアナリシスト
  • UIデザイナー
  • テクニカルドキュメントライター
  • 開発者
  • アーキテクト
  • テストエンジニア
  • ビルドエンジニア
  • デプロイメントスペシャリスト
• PM=管理職という考え方をなくし、文字通り現場でプロジェクトを管理する専門家を雇う
• 個別システムレベルでのアーキテクトは現場でプログラミングやプログラマーの指導も行う*3

あたりから、徐々に改善していくのはよいと思います。
ところで、組織に新しいアイデアを導入する際のヒントとなるパターンとしては

Fearless Change: Patterns for Introducing New Ideas

などの本も参考になるかもしれません。また、
- 組織パターンとプロセスパターン
なども昔から知られています。（これについてはアジャイルではない開発組織に導入することは困難ですが。）
さらに、従来のゼネコン体質や人月のビジネスモデルなどは遅かれ早かれ見直しを迫られることになると思います。http://www.esm.co.jp/trial/new-agile-contracts-service.htmlのようなところも出てきてはいますし、今後これらのやり方がうまくいくという実績ができれば、一気に古いやり方が一層されるということも考えられないことはないかもしれません。
最後に、SIerなどのフェローやITアーキテクトなど上級の責任ある立場の技術者の方々には、SOAやクラウドなどマーケティング的に受けの良い新技術を追いかけるだけでなくて、設計やプログラミングのやり方など基本的な開発技術についても、もっと会社の技術者を指導、啓蒙していっていただけたらと思いますね。

*1:前にはまった、シヴィライゼーションというPCゲームだと技術の差が付けらた国は直ちに他国から侵略されますが。

*2:アジャイルならもっと別の分類になるでしょう。

*3:海外ではHands-on architectという言葉があるようです。