とある就職サイトで「設計コンサルタント」という名称を知りました。
常々、ITの設計のことを「アーキテクト」＝「設計者」という割には、詳細設計は大手若手SEに任せていたり、職種自体も雑誌の名を冠しているぐらいで怪しい感じがするし、と思っていて「アーキテクト」ってのはどんなもんなんですかね～、と思っていたわけですが。
なるほど、建築関係や三次元の意匠デザイン（かな？）の場合、「設計コンサルタント」という職名があるようです。
龍菜の3次元CAD活用相談室（1）私の設計、変ですか？
http://monoist.atmarkit.co.jp/fmecha/articles/dragon/01/dragon01a.html
http://www.page.sannet.ne.jp/gah01300/
本来、ITシステムを構築するときには、要件定義、設計、開発/実装、試験、運用、なる流れが必要なのですが（ウォータフォール形式的に言えばね）、受託開発を多くやってきたので、
・大手の要件定義
・大手の設計
が良く分かりません。つーか、見ていて不安なんですけど。
要件定義のほうは、提案/営業活動/製品説明/予算/納期などなど、顧客からの要望を引き出す技術（あるいは製品を押しつける技術）が必要になるので、いわゆるIT関係とは離れたノウハウがが必要です。あるいは他の業界とは同じような活動の仕方があります。
また、受託開発をする会社の場合は、設計が落ちてくるのを待つことが多いので（この体制が問題だと思うのですが）開発/実装/単体試験/結合試験/納品までのプロセスをいかに効率よくやるのか/コストを掛けないか、という「オフショア開発」的なノウハウに長けてきています。
なので、真ん中にある「設計」が抜けていることが度々あります。というか、設計とは名ばかりで、中身がいきなり細かい詳細設計をやっていたり、逆に要件定義で設計をやっていたりします。
設計の大まかな分類/種類を並べると、
・システム設計
・ソフトウェア設計
・概要設計
・外部設計
・内部設計
・詳細設計
というものがあります。他にもデータベース特有の
・概念設計
・論理設計
・物理設計
なるものもあり、オブジェクト指向で言えば
・ユースケース
・クラス図
・シーケンス図
などのUML関係があります。他にもデータフローチャートなんてのもあります。
本来、これらの設計工程は、建築業界の設計業務と同じように、三面図/見取り図などの図面と変わらない意味を持つはずですが、なかなかそうは行きません。
実際、CASEツールの筆頭としてUMLが持て囃されたころから10年経ちますが、未だにUMLで統一された設計書を出す会社を見たことがありません（部分的には使うことは多いのですが）。
UMLの場合は、所詮ツールですので、本来の目的は要件を如何に実装へ繋げるかという「設計」のサポートが本来の役割です。なので、UMLからJavaやC#のコードがはきだされるのは、補助的な機能に過ぎないんですよね～（というのを数年前に気付いた）。
と、改めて先のITの設計工程を見直してみると、実はこれらはプログラム言語に依存しません。当たり前といえば当たり前なのですが、予算/期間/製品/技術スキル/可搬性などを考慮するので、設計自体にjavaだのc#だのという制限は入ってきません。勿論、制約として現在のシステムがjavaで組んであるので流用を含めてjayaにしたいとか、フリーの環境で揃えたいので ruby や php を使うとか、組み込みシステムなので c 言語以外は使えないとか、があるので、これらは「制約事項」として設計工程に盛り込みます。
そういう訳で、しばらく
「プログラム言語に依存しない設計工程」
を考えていこうかな、と思っています。
言語に依存しないといえば真っ先に思いつくのは、UML でしょうが、これだけが設計ではありません。
DBA（データベース管理者）やオブジェクト指向/サービス指向/データ指向を交えて、考えていきたいと思います。
余談
と、前振り完了。
実はこの話２年前に考えていたことなのですが、ごたごたがあって立ち消えになっちゃんたんだよね～。
なので、再開しよかなっと。
