Monthly Archives: October 2009

ソフトウェア設計コンサルタント、っていう職種があるかどうかは怪しいのですが、そういう名刺を作ろうかなと画策中です。それで、コンサルタントって名乗るからには、何かをサポートできないといけないですよね。当然ですが。 設計というのが何処の部分を示すのかというと、ウォーターフォール的に言えば、要件定義と開発/実装の間です。そして、重要なのは先のエントリで説明しましたが、プログラム言語に依存しません。勿論、プログラム言語特有のメリットを使う場合もあるでしょうが、システムをトップダウンで見たときは、特定のプログラム言語、ライブラリに依存しないほうが、実装上の選択肢が多くなり、開発費等のコスト削減に寄与できます。当然、スケールも柔軟に考えることが可能です。 そんな訳で、最初は「システム設計」から入りましょう。 システム設計なんて大層な名前がついていますが、所謂、どんなシステム構成にするの？ってのを図示します。 システム構成のパターンは、ほぼ決まっています。 ・スタンドアローンのアプリケーション（インストールアプリ、ゲーム） ・クライアント／サーバー型 ・不特定多数のＷＥＢサイト ・特定人数のＷＥＢサイト（ＳＮＳ） ・ＵＩを持つＷＥＢサービス（ブログツール） ・ＵＩを持たないＷＥＢサービス（金融、株式データサービス） などです。この他にもいくつかあるでしょうが、大抵のものはこの範囲におさまってしまいます。 これにデータベースの有無が関係します。データベースの有無は、既存のデータ／テーブルを使うのか、新規にデータベースを使って良いのか、に関係してます。 これらを図に書くと、 ■スタンドアローン型 ■クライアント／サーバー型 ■不特定多数のWEBサイト ■特定人数のWEBサイト ■UIを持つWEBサービス ■UIを持たないWEBサービス となります。 新規システムの場合は、ネットワーク回線速度も含めてすべて設計する訳ですが、ほとんどの場合は既存のリプレースになります。なので、それぞれの箱や線について、既存の制約を書きだしていきます。 例えば、不特定多数のWEBサイトを再構築する際のチェックポイントを抜き出します。 チェックポイントの抽出は簡単です。 ・接続点 ・動作点（コンピュータそのもの） にマークを付けます。動作点については、 ・CPU ・DISK ・MEMORY を調べます。この根拠は microsoft のパフォーマンスチューニングのwebページにあります。 # ちょっとリンク先を失念。 と言う訳で、システム構成を決めるときには、 ・CPU ・DISK（永続化の容量） ・MEMORY（必要メモリ、推奨メモリなど） ・NETWORK（回線速度） … Continue reading →

とある就職サイトで「設計コンサルタント」という名称を知りました。 常々、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 言語以外は使えないとか、があるので、これらは「制約事項」として設計工程に盛り込みます。 そういう訳で、しばらく … Continue reading →