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

プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指してについて。
結構前に書いた記事だったので、今頃になってここまで大きな反響が得られるとはまったく驚きです。やはり、はてブのトップページ(ホッテントリ呼ばれるらしい。)に出るとすごい目立ってしまうのですね。
多くのコメントは現役のプログラマーの方々からだと思うのですが、皆さんからいただいたコメントを見ると、開発の現場で日ごろから矛盾を感じながらも日々設計や開発の仕事をされている方が多いみたいですね。私としては共感していただける多くの仲間がいるということで、ちょっと勇気付けられたというか本当に嬉しく思いました。
また、中にはマネージャーや年配の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という言葉があるようです。

アーキテクトもプログラミングするべきか？

プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指して
で以下のようなコメントをいただきました。

アプリケーションのアーキテクトという役割についてちょっと理解が曖昧だったのがこのエントリ読んでだいぶスッキリした。今度の開発系の勉強会のネタにとりあげようかな

アーキテクトの働き方の参考に。

そもそもオブジェクト指向を本当に理解していてプログラミングも得意なアーキテクトがどれくらい居るのやら。 全体の設計がちゃんと推敲されていて、きちんと疎結合が達成されているなら、後の修正にも耐えられる。

アーキテクトが何をどこまで責任持つのか、という認識が整合されてないんじゃないの

現代的アーキテクトの仕事

このようなコメントから、「アーキテクト」という仕事の内容については、実はよくわからないと考えている方が多いように感じられます。実は、私自身も「アーキテクトという役割で仕事をする*1」などと書いたのですが、アーキテクトの役割や仕事の範囲について決定的なイメージを持っているわけではありません。少なくとも、ITSSのITアーキテクトの定義ITSSの次期版「V2」公表へ，専門分野の分類や記述を改良 | 日経 xTECH（クロステック）を参考にすると、実装技術よりも、上流のソリューションよりの傾向が強い気がしますから、普段の自分の仕事とはかけ離れていると思います。一方で、ソフトウェアアーキテクチャ―ソフトウェア開発のためのパターン体系やエンタープライズ アプリケーションアーキテクチャパターン (Object Oriented SELECTION)のような本で出てくるアーキテクチャーパターンという用語を考えると、設計レベルよりは視点が広めとは言え、かなり実装よりな視点からプログラムの全体構造を設計する人という解釈が自然なようにも思われます。
実はソフトウェアアーキテクトという言葉の意味するものが何なのかということは、日本のIT業界だけでなくて、海外でもさまざまな解釈があるようです。特に、アーキテクトがコードを書くべきかどうかという点については議論が分かれるところのようですね。アーキテクトは建築家ということなので、建物のメタファーで考えると、アーキテクトがコードを書くということは、建築家が金槌や釘を使って作業しているようでいかにも不自然に思われます。ですから、ソフトウェアの世界でアーキテクトがプログラムを書くなどということは、アーキテクトの単価に見合わない、お金の無駄使いのように考えている人も多いようです。
しかし、現実問題としては、プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指してで書いたとおり、言語やフレームワーク、ツールなど実装レベルの詳細を理解していないと、有効な設計を考えることは難しいという事実があります。*2建築のメタファーからすると不自然ですが、アジャイル開発のブームなどもあって、最近はアーキテクトがプログラミングできなくてはならないという事実が顕在化してきたみたいです。そこで、海外ではプログラムを書かないアーキテクトをhands-offアーキテクト、プログラムを書くアーキテクトをhands-onアーキテクトと読んで区別するようになっているみたいです。*3英語でネット検索するとアーキテクトの仕事の募集がたくさんで出てくるのですが、「hands-on Javaアーキテクトを募集」などという使われ方をするみたいです。
Spring Frameworkの作者であるRod Johnsonの著したExpert One-on-One J2EE Development without EJBの74ページで以下のような説明があります。

I believe that there is an important role for architects but that architects must retain hands-on contact with code. There is a real danger in architects who never work at the coal-face ― and hence lack awareness of the myriad of practical issues that dictate the success or failure of projects ― defining and dictating architecture in glorious isolation. This is a recipe for failure, and nearly always results in enormous complexity. Unfortunately, the notion that successful career progression involves a complete move away from coding dies hard, and does immense harm.
アーキテクトには大切な務めがありますが、アーキテクトはコードに直接手で触れる立場にいなくてはならないと信じます。開発現場での実労働を経験したことのないアーキテクト（したがって、プロジェクトの成否を左右するたくさんの実務上の問題を知らない）が、天下り的にアーキテクチャーを定義して押し付けるということは本当に危険なことです。これは失敗に至らしめる処方箋なのであって、ほぼ間違いなく、途方もなく複雑な設計に帰結します。*4残念ながら、キャリアパス上で昇進すると完全にコーディングから手を引くという考え方が染み付いていることもあり、これが甚大な被害をもたらしています。
Software architecture can be defined only with detailed knowledge of the issues that implementing them will pose. Architects who spend all their time writing documents and working with models seldom produce realistic architectures.
ソフトウェアアーキテクチャーは、それを実装するのに必要な事項に関する深い知識を通してのみ定義することが可能です。すべての作業時間を文書作成やモデルの作成に費やしているようなアーキテクトが、現実的なアーキテクチャーを創り出すことはほとんどありません。

hands-onとhands-offのアーキテクトは、別々の場面で、それぞれ役割があるのだと思いますが、少なくとも1プロジェクトのレベルでJava EEのようなプラットフォーム上でシステムの開発を行う場合は、スキルの高いhands-onアーキテクトの参画がプロジェクト成功の鍵を握っているというのは紛れもない事実であると思います。このことが日本ではいまだに広く知られていないのが問題ですね。私が比較的最近、途中からの立て直しのためヘルプで参加したことのあるプロジェクトでは、hands-offアーキテクトの判断でJSFとJPAというJava EEの標準仕様を導入し、少なくとも設計上はDDDを取り入れた斬新な設計を構想していたようなのですが、性能がまったく出ず、予算を大幅に超過して1年もリリースを延期した上に、大部分の設計見直しを行ったというところがありました。この失敗の主要な原因は、JPAの詳細な仕様を開発を引き継いだプロジェクトメンバーが誰も理解しておらず、lazyローディングや、SQLとO/Rマッピングの使い分けなど細かいところで適切な設計判断ができていなかったことが大きかったです。
最後に、上級プログラマーとhands-onアーキテクトとの役割の違いについて私の考え方を述べます。アーキテクトである以上、要件はもちろん、スケジュールやメンバーの経験などさまざまな観点から、全体として最適な方法を考えるというのがポイントになると思っています。設計ではどうしてもあっちを立てるとこっちが立たずというトレードオフの関係に陥ることが多いのですが、全体のバランスを考えて一部は妥協するようなバランス感覚が重要なのではと思います。また、実装上ちょっと仕様を変えるだけで、使い勝手が向上するだけでなく、大幅に工数を削減できるような有効な手段があるような場合は、可能な範囲で上流にフィードバックするといったような役割もhands-onアーキテクトにはあると思います。要するに、ユーザーやプロジェクト全体に対する視点も少しは必要かなと思います。そういうところが特定のモジュールの実装を担当する一般のプログラマーとの違いかと思います。

*1:あくまでも会社の営業的にアーキテクト単価で仕事をするという意味です。とはいっても実際は通常のSE単価と大差がないです。PMよりは金額的にははるかに下。一般のPG単価よりは数割程度は高いと思いますが。

*2:このアーキテクチャーの設計とコーディングの関係については、ファウラーの有名な論文でも論じられていますね。- 設計の終焉?

*3:日本語にあえて訳すと上流アーキテクト、下流アーキテクトといったような意味になるかもしれません。

*4:こうなるひとつの原因として、hands-offアーキテクトがプログラマーの苦労を考えず、やたらと複雑な商品を採用したがるという傾向が考えられると思います。分散オブジェクトやWebサービス、ESB、そして、最近はクラウドなど。そうして大規模で複雑な設計にした方が会社が儲かってhands-offアーキテクト自身の評価も高くなるというところもあるのでしょう。こういうアーキテクチャーをマーキテクチャーと呼ぶそうです。Marchitecture - Wikipedia