最近は太りすぎで血圧が高めなので、一念発起して、一日最低５００メートルの水泳を自分自身に義務付けています。
また、食事も暴飲暴食はやめ意識的に軽く済ますように心がけた結果、始めてから一週間で3キロ痩せました。
この分で行くと3ヶ月もしないうちにベストの状態に行けるんじゃないかと思いますが、毎日泳ぎに行くのは結構辛い・・・
MBSE モデル・ベースト・システムズ・エンジニアリングの利点 その１
システム工学の歴史は古く、コンピュータ発明以前から存在していた事は先に述べたとおりです。
またシステム工学とモデリングの親和性はむしろ本質的です。
しかしながら、システム工学用のモデリング言語はソフトウェア系に比べるとかなり後発でした。
これは、いくら好条件がそろった商品でも需要がなければ全く売れないのと同じで、いくらモデリングと親和性の高い分野だと行っても、モデリングのニーズやメリットがなければ誰もモデリングなんてしないのは理の当然でしょう。
ところが2007年のSysML1.0の登場以来（わずか3年前）、システムズ・エンジニアリング分野はモデル・ベースのものに急速にシフトしていっています。
この普及の急速さは、UMLの時とは比べものにならないくらいです。
もちろんUMLの時と比べ環境的な条件が遥かに整っている事は事実ですが、何かメリットがあるはずです。
今回はMBSE(Model Based Systems Engineering)の利点を見て行きましょう。
1. 要件や設計の共通理解が容易
モデルではなく従来の文書によるシステムズエンジニアリングの欠点の1つは、表現の曖昧さでした。曖昧な表現のままコミュニケーションを行うわけですから、時には大きな誤解を生み出します。 その結果様々な問題が発生します。
1-1 文書ベースでは、要件そのものを間違えやすい、あるいは正しい事を検証できない（バリデーションの問題）のに対し、モデル・ベースでは検証が容易になる。
1−2 昨今のシステムの開発では、要件の分析と設計は一体となって行われる事が多いが、
モデルはその分析設計の共通基盤を提供してくれる。
1-3 モデル分析により、リスクの発見が容易になる。
まずは文書ベースのアプローチに比べMBSEは以上のような基本的なメリットがあります。
（次回に続く）
2010年7月11日日曜日
2010年7月7日水曜日
SysML 中級講座： 第２回 システム工学とSysML
SysML言語の詳細に入る前に、システム工学とモデリング、そしてSysMLの関係を概観しましょう。
まず、システム工学ですが、これ はコンピュータが発明される以前から存在する学問分野で、最初は人間系が主な対象でしたが、機械系、電気系システムの発展とともに対象が広がり、かなり広 範囲な学際的特徴をもつ分野です。
近年、コンピュータの登場とともにますます対象エリアは広がり、かつ非常に複雑なシステムを扱うようになってき ました。
システムズ・エンジニアと言うと日本ではITシステムを設計する技術者、特にソフトウェア技術者を指す言葉として定着しています が、これは日本固有の現象で、欧米ではシステムズ・エンジニアと言うと、第一義的に船舶とか航空機、ロケットなんかを思い浮かべる人が多いようです。
こ れは、システムズ・エンジニアと言う言葉が、それぞれの国で、どのような対象とともに登場して来たかを暗示しているのではないかと思います。
おそ らく日本では、IT系のシステムズ・エンジニアの登場以前には、システムズ・エンジニアと言う言葉が一般には馴染みのないものだったのではないかと想像し ています。
そもそ も、システム工学にはモデリングというコンセプトを始めから包含していたとも言えます（例えば、数学モデル）。
また、モデリングと言う概念も拡張 しようと思えばいくらでも拡張できる訳で、例えばニュートン力学なんかは、自然対象を非常に高い精度で近似できる数学モデルという見方も可能です（もちろ んニュートン卿は、けっして近似モデルを発明発見したとは思ってなかったと思いますが）。
さて、現代的な意味でのモデリングはここ十数年 の間に急速に発達してきました。
しかしながら、組込み系ではいわゆるIT系のUMLでは事足らず、ソフトウェアを取り巻くシステム環境がモデリング出来ないと分析設計そ のものが不十分であるという壁にぶつかり、９０年代後半あたりから独自の拡張をUMLに付け加えるようになってきました（当時、OMG内には、そう言った 問題に対処するSIGも誕生しました）。
このような「システム」を記述するためのUMLの拡張は、その後、UML2.0に取り入れられた形で発展 して行きます。
恐らく、IT系のみを担当するソフトウェア技術者の中には、UML2.0とともに登場した図の中に、何のためにあるのか分からない 表記法の存在に当惑した経験をお持ちの方が少なからずいらっしゃると思いますが、その多くは「システム」を記述するための（UML2.0の）拡張部分で す。
次の表はINCOSEとOMGの協同体制の発足からSysMLの誕生までの年譜を示しています。
しか しながら、その後のSysMLの詳細を詰める過程では議論は大もめにもめ、対立するグループが二派に別れて、それぞれが別々の言語仕様を作ると言った事態 にまで陥り、一元化するまでの間、半年以上の日月を空費するような事もありました。
SysML 1.0の誕生までに発足から約６年かかりましたが、関係者の努力の賜物と言えるでしょう。
誕生の経緯からお分かりの通り、 SysMLはモデルベースのシステム工学のための言語、道具です。目的か手段かと問われると、あくまでもMBSEを行うための手段です。
本講座で は、SysMLの言語的特性に焦点を当てて議論を進めますが、あくまでも道具である事を忘れないようにしていきたいと思います。
次回は、 システム工学をモデルベースで行う事に、どんなメリットが有るのかについて議論します。
まず、システム工学ですが、これ はコンピュータが発明される以前から存在する学問分野で、最初は人間系が主な対象でしたが、機械系、電気系システムの発展とともに対象が広がり、かなり広 範囲な学際的特徴をもつ分野です。
近年、コンピュータの登場とともにますます対象エリアは広がり、かつ非常に複雑なシステムを扱うようになってき ました。
システムズ・エンジニアと言うと日本ではITシステムを設計する技術者、特にソフトウェア技術者を指す言葉として定着しています が、これは日本固有の現象で、欧米ではシステムズ・エンジニアと言うと、第一義的に船舶とか航空機、ロケットなんかを思い浮かべる人が多いようです。
こ れは、システムズ・エンジニアと言う言葉が、それぞれの国で、どのような対象とともに登場して来たかを暗示しているのではないかと思います。
おそ らく日本では、IT系のシステムズ・エンジニアの登場以前には、システムズ・エンジニアと言う言葉が一般には馴染みのないものだったのではないかと想像し ています。
MBSE モデルベースト・システムズ・エンジニアリング
そして、モデリングとシステム工学も古くて新しい話題です。そもそ も、システム工学にはモデリングというコンセプトを始めから包含していたとも言えます（例えば、数学モデル）。
また、モデリングと言う概念も拡張 しようと思えばいくらでも拡張できる訳で、例えばニュートン力学なんかは、自然対象を非常に高い精度で近似できる数学モデルという見方も可能です（もちろ んニュートン卿は、けっして近似モデルを発明発見したとは思ってなかったと思いますが）。
さて、現代的な意味でのモデリングはここ十数年 の間に急速に発達してきました。
始めは組込みソフトウェアの現場から
UMLは最初はソフトウェア開発、なかんずく上流行程で発生する様々な問題に対処するために誕生し ました。しかしながら、組込み系ではいわゆるIT系のUMLでは事足らず、ソフトウェアを取り巻くシステム環境がモデリング出来ないと分析設計そ のものが不十分であるという壁にぶつかり、９０年代後半あたりから独自の拡張をUMLに付け加えるようになってきました（当時、OMG内には、そう言った 問題に対処するSIGも誕生しました）。
このような「システム」を記述するためのUMLの拡張は、その後、UML2.0に取り入れられた形で発展 して行きます。
恐らく、IT系のみを担当するソフトウェア技術者の中には、UML2.0とともに登場した図の中に、何のためにあるのか分からない 表記法の存在に当惑した経験をお持ちの方が少なからずいらっしゃると思いますが、その多くは「システム」を記述するための（UML2.0の）拡張部分で す。
INCOSEとOMGの協同体制の発足
この様に、最初は組込み系システムの現場から誕生したシステムのモデリングと言う概念は、 ２０００年代に入ると、より大きな問題、より広範なシステムに対処するべくOMGという組織の枠を超えて広がって行きます。そして、システム工学の本家、 INCOSEとOMGの共同作業が始まります。次の表はINCOSEとOMGの協同体制の発足からSysMLの誕生までの年譜を示しています。
- 2001年 INCOSEとOMG間で協議開始
- 2002年 RFI 発行 ー 市場から広く情報を集める
- 2003年 RFP発行 ー 市場に提案を求める
- 2007年 SysML 1.0
- 2008年 SysML 1.1
- 2010年 SysML 1.2
しか しながら、その後のSysMLの詳細を詰める過程では議論は大もめにもめ、対立するグループが二派に別れて、それぞれが別々の言語仕様を作ると言った事態 にまで陥り、一元化するまでの間、半年以上の日月を空費するような事もありました。
SysML 1.0の誕生までに発足から約６年かかりましたが、関係者の努力の賜物と言えるでしょう。
誕生の経緯からお分かりの通り、 SysMLはモデルベースのシステム工学のための言語、道具です。目的か手段かと問われると、あくまでもMBSEを行うための手段です。
本講座で は、SysMLの言語的特性に焦点を当てて議論を進めますが、あくまでも道具である事を忘れないようにしていきたいと思います。
次回は、 システム工学をモデルベースで行う事に、どんなメリットが有るのかについて議論します。
2010年7月5日月曜日
SysML 中級講座： 第１回 開始！
本日から、SysML中級講座を始めます。
最初に、何をもって中級と名付けたかについて触れておきたいと思います。
このOCSMPですが、OMG Certified Systems Modeling Professional と言う名称が示すようにシステムをモデリングする専門家のための認定試験です。
従っ てSysML言語そのもののテストではなく、システムのモデリングに関する知識を問う設問が中心となっています。
しかしながら、モデリングとモデ リング言語は極めて密接な関係があり、喩えて言うと日本文学と日本語の関係、あるいは数学と数式の関係のようなものであり、言語を理解せずに文学を学ぶ事 が実際不可能なように、モデリング言語を知らずにモデリングを実践することは殆ど不可能です（少なくとも、他人が書いたモデル図を読む事は不可能）。
OCSMP は全部で４つのレベルから構成されていますが、試験体系の設計に関しては、このモデリングとモデリング言語の関係、及び、個人の学習に関する成熟度が強く 意識された形になっています。
下の図は、OCSMPの４つのレベルを示しています。
OCSMPには２つのグループがあり、１つはモデルユーザー、もう一方はモデルビルダーと名付けられていて、モデルビルダーはその名前の通りモデルを構築 する人、つまりシステムを設計する人間を対象とした区分であるのに対し、モデルユーザーは、システム設計者に対し情報を提供したり、あるいは逆に情報をも らったりする人たちです。
実際の現場でもこの区分は良く当てはまり、システム設計を行う人間・グループを中心として、その周辺にはハード ウェア設計者（例：筐体や電子回路）やソフトウェア設計者、そして各々の分野の専門家、例えば社会学者や原子力科学者、物理工学者等々、が取り巻 いています。
そして、モデリングの学習は、他人が書いたモデル図を正確に、過不足なく読み取る事から始まります。
実際、 OCSMPのエントリーレベルであるモデルユーザーの試験は、モデル図を読む能力に主眼が置かれ、モデル図を読み取る上で必要なスキル、知識が試されま す。
言い換えると、エントリー・レベルでは言語の解釈能力を問う問題が中心的です。
一方モデルビルダーは、モデル図を描く人を想 定した出題群からなります。
モデルビルダー初級は、モデル図を描く上で必要な基礎知識が試され、中級、上級になるとモデリングを行う上で必要とな る知識・スキルが試される傾向にあります。
また、中級、上級となるにつれ言語に関する問題も高度化していく傾向がありますが、モデル図を描く上で 必要な知識に限定され、決して単純な文法問題になってしまわないよう配慮されています。
本講座では、モデルビルダー中級程度で必要となる ようなSysMLの知識を想定して進めて行きたいと考えています。
これは、モデルビルダー中級は、一般のシステム製品の設計者を想定した試験区分 である事、そして上級はSystem of Systemsと言うような巨大もしくは複雑なシステム設計者を想定した出題でありMBSE(モデル・ベースト・システムズ・エンジニアリング）中心の出 題になる事が予想され、言語色が薄れる事、等を勘案して設定しました。
また、前提としてUML初級（ファンダメンタル）程度の知識を読者 に想定しています（SysML言語は、UMLを拡張した言語であり、一種のUMLとも言える。）
UMLの入門的な知識に関して知りたい人 は、各種書籍や iStudyシリーズの「iStudy for OCUPファンダメンタル」などのE-ラーニング教材などをお奨めします。
最初に、何をもって中級と名付けたかについて触れておきたいと思います。
SysMLとOCSMP
現在、INCOSE(International Council Of Systems Engineering)とOMGの協業でOCSMPと言う資格試験の開発が進んでいます。このOCSMPですが、OMG Certified Systems Modeling Professional と言う名称が示すようにシステムをモデリングする専門家のための認定試験です。
従っ てSysML言語そのもののテストではなく、システムのモデリングに関する知識を問う設問が中心となっています。
しかしながら、モデリングとモデ リング言語は極めて密接な関係があり、喩えて言うと日本文学と日本語の関係、あるいは数学と数式の関係のようなものであり、言語を理解せずに文学を学ぶ事 が実際不可能なように、モデリング言語を知らずにモデリングを実践することは殆ど不可能です（少なくとも、他人が書いたモデル図を読む事は不可能）。
OCSMP は全部で４つのレベルから構成されていますが、試験体系の設計に関しては、このモデリングとモデリング言語の関係、及び、個人の学習に関する成熟度が強く 意識された形になっています。
下の図は、OCSMPの４つのレベルを示しています。
実際の現場でもこの区分は良く当てはまり、システム設計を行う人間・グループを中心として、その周辺にはハード ウェア設計者（例：筐体や電子回路）やソフトウェア設計者、そして各々の分野の専門家、例えば社会学者や原子力科学者、物理工学者等々、が取り巻 いています。
そして、モデリングの学習は、他人が書いたモデル図を正確に、過不足なく読み取る事から始まります。
実際、 OCSMPのエントリーレベルであるモデルユーザーの試験は、モデル図を読む能力に主眼が置かれ、モデル図を読み取る上で必要なスキル、知識が試されま す。
言い換えると、エントリー・レベルでは言語の解釈能力を問う問題が中心的です。
一方モデルビルダーは、モデル図を描く人を想 定した出題群からなります。
モデルビルダー初級は、モデル図を描く上で必要な基礎知識が試され、中級、上級になるとモデリングを行う上で必要とな る知識・スキルが試される傾向にあります。
また、中級、上級となるにつれ言語に関する問題も高度化していく傾向がありますが、モデル図を描く上で 必要な知識に限定され、決して単純な文法問題になってしまわないよう配慮されています。
本講座では、モデルビルダー中級程度で必要となる ようなSysMLの知識を想定して進めて行きたいと考えています。
これは、モデルビルダー中級は、一般のシステム製品の設計者を想定した試験区分 である事、そして上級はSystem of Systemsと言うような巨大もしくは複雑なシステム設計者を想定した出題でありMBSE(モデル・ベースト・システムズ・エンジニアリング）中心の出 題になる事が予想され、言語色が薄れる事、等を勘案して設定しました。
また、前提としてUML初級（ファンダメンタル）程度の知識を読者 に想定しています（SysML言語は、UMLを拡張した言語であり、一種のUMLとも言える。）
UMLの入門的な知識に関して知りたい人 は、各種書籍や iStudyシリーズの「iStudy for OCUPファンダメンタル」などのE-ラーニング教材などをお奨めします。
2010年7月4日日曜日
アーキテクチャー：メタモデルのすすめ ⑥
９０年代以降、アーキテクトは、その方向性を大きくモデリングの方へ舵を切って行き、またそのモデリングも具体的なものから抽象的なものへとシフトして来 ています。
また、アーキテクトの基礎知識として、モデリング技術は当然として求められますが、最近ではメタモデリングの知識も必須項目となって来 ています。
恐らく、このブログを読んでいる人にメタモデルの重要性を訴える事は、釈迦に説法だと思いますので、ほどほどにしたいと思いま すが、そもそも、何で日本ではアーキテクチャーとかメタモデリングが発達しないのかは、筆者にとっても最大の関心事ですので（あるいは、日本にとっても非 常に重要な問題だとも思いますので）、少し触れてみたいと思います。
先日、友人と寿司屋に行った際にもこの事が議論になりました。
ど うも今の日本のカルチャーの中では、無形なものに価値を見いだす事が難しい、と言うよりも、さらに悪い事に、無形なものに対して、ニュートラルではなく負 の評価を行う傾向があるんじゃないか、と言う命題が議論の中心でした。
概念的、あるいは抽象化した議論は、ややもすると言葉遊び的に捉え られ、具体性がないとか、（具体的な）結論を先に言え、と言うような否定的な評価につながり易い傾向があるのは、ITに限った事ではなく、殆ど日本のすべ ての分野で見られる傾向です。
筆者も海外で仕事をする前までは、具体性を好む人間の一人でしたので他の日本人を批判する資格は全くありません。
し かしながら、海外での仕事を通じて、考え方の違いや仕事のアプローチの違いを見るにつけ、日本のやり方が必ずしもベストではない事、結果を生み出さない事 を痛感するようになって来ました。
よく言われる事ですが、哲学（西洋哲学）は欧米では、結構身近な話題です。存在論メタモデルなんて言う話題は、ビジネスマンでも好んで口にします。（余談 ですが、哲学用語は、使うと話が高級そうに聞こえるため営業トークでも頻出しますが、これはやり過ぎでしょうね。）
もっとも欧米人と言っ ても、人によりますので、具体的な話しか好まない人も多くいます。ただ全体的に言って、抽象的な議論に対してネガティブな見方をしない、概念的な作業に価 値を見いだしている傾向があります。
それに対して、日本では「もの」が価値の中心であり、サービスは「もの」に付随する「おまけ」的な見方が相変 わらず続いています。
しかしながら、昨今、日本企業の経営陣の世代交代が進みつつあり、それにつれて考え方も少しずつですが、変わって 行ってる事を実感しています。
貴重な時間を割いて、このアーキテクチャーやメタモデルに関するブログを読んで頂いている方達ー世代が、今 後の新しい時代を作る、と期待しています。
次回からは、OCSMPの資格試験も近々始まる事から、SysMLに関してシリーズで 書いて行きたいと思います。
また、アーキテクトの基礎知識として、モデリング技術は当然として求められますが、最近ではメタモデリングの知識も必須項目となって来 ています。
恐らく、このブログを読んでいる人にメタモデルの重要性を訴える事は、釈迦に説法だと思いますので、ほどほどにしたいと思いま すが、そもそも、何で日本ではアーキテクチャーとかメタモデリングが発達しないのかは、筆者にとっても最大の関心事ですので（あるいは、日本にとっても非 常に重要な問題だとも思いますので）、少し触れてみたいと思います。
先日、友人と寿司屋に行った際にもこの事が議論になりました。
ど うも今の日本のカルチャーの中では、無形なものに価値を見いだす事が難しい、と言うよりも、さらに悪い事に、無形なものに対して、ニュートラルではなく負 の評価を行う傾向があるんじゃないか、と言う命題が議論の中心でした。
概念的、あるいは抽象化した議論は、ややもすると言葉遊び的に捉え られ、具体性がないとか、（具体的な）結論を先に言え、と言うような否定的な評価につながり易い傾向があるのは、ITに限った事ではなく、殆ど日本のすべ ての分野で見られる傾向です。
筆者も海外で仕事をする前までは、具体性を好む人間の一人でしたので他の日本人を批判する資格は全くありません。
し かしながら、海外での仕事を通じて、考え方の違いや仕事のアプローチの違いを見るにつけ、日本のやり方が必ずしもベストではない事、結果を生み出さない事 を痛感するようになって来ました。
よく言われる事ですが、哲学（西洋哲学）は欧米では、結構身近な話題です。存在論メタモデルなんて言う話題は、ビジネスマンでも好んで口にします。（余談 ですが、哲学用語は、使うと話が高級そうに聞こえるため営業トークでも頻出しますが、これはやり過ぎでしょうね。）
もっとも欧米人と言っ ても、人によりますので、具体的な話しか好まない人も多くいます。ただ全体的に言って、抽象的な議論に対してネガティブな見方をしない、概念的な作業に価 値を見いだしている傾向があります。
それに対して、日本では「もの」が価値の中心であり、サービスは「もの」に付随する「おまけ」的な見方が相変 わらず続いています。
しかしながら、昨今、日本企業の経営陣の世代交代が進みつつあり、それにつれて考え方も少しずつですが、変わって 行ってる事を実感しています。
貴重な時間を割いて、このアーキテクチャーやメタモデルに関するブログを読んで頂いている方達ー世代が、今 後の新しい時代を作る、と期待しています。
次回からは、OCSMPの資格試験も近々始まる事から、SysMLに関してシリーズで 書いて行きたいと思います。
2010年6月9日水曜日
アーキテクチャー：メタモデルのすすめ ⑤
以前OMGはアーキテクトの集まりだと書きましたが、もう少し正確に言うと、昔からそうだったわけではなく、また全員が必ずしもアーキテクトと言うわけで はありません。
OMGはもともとはCORBAに代表される分散処理技術者の集まりでした。人的、歴史的には、80年代に流行った人工知能 (AI)をやってた人が流れて来たパターンが多いようです。
では、いつ頃からアーキテクトが集まりだしたかというと、90年代の半ばにUMLの標 準化が始まりだした頃からです。
その頃から上流工程に従事するエンジニアがモデリングに興味を示し始め、アーキテクトの割合が増加してきました。
2000 年前後になるとITソフトウェアだけではなく、ハードウェア設計にもUMLを使う動きが顕著になってきて（ハードウェア設計と言っても上流設計、概念設計 です。念のため）、UMLバージョン１のソフトウェア中心の表記法では用が足らず、より論理的な構造を持つモデリング言語（メタ言語構造を持つ言語）とし てUML2.0が誕生しました。
2001年には、INCOSE(International Council of Systems Engineering：直訳すると国際システム工学学会ぐらいか？）と共同で現在のSysMLのひな形を作る作業が開始されました。
ちなみに SysMLは、UMLの自己拡張機能、プロファイリング機能を用いて作られていますので、厳密に言うとUMLの一種です。
また、話がそれますが （ブログなので流れのまま書いてます）、現在、プロファイリング以外の言語拡張の手法が検討され始めており、今後違った動きも見られると思いますが、恐ら くここ１０年はプロファイリング中心のやり方になるでしょう。（SysMLのひな形誕生から普及まで（つまりツール・ベンダーによってツール化されるま で）に7〜８年かかっていますので。）
2000年ぐらいには上流側の分科会（プラットフォームに対してドメイン側で、ファイナンス・タスクフォー ス等のように産業別に作られ始めました）が徐々に活発になり、BPMI(ビジネス・プロセス・マネジメント・イニシアティブ）との合併はドメイン側へのシ フトを決定づけました。
また世の中のお金の流れもプラットフォームからドメイン側に代わり、IT産業の主役もプラットフォームを作っているメー カーから、先進的な利用を行っているユーザー側にシフトし始めます。
そして、従来のアーキテクト中心のメンバー構成にビジネス・アナリストの集団 が融合し始めます。
ビジネス・アナリストの参入はOMGにとって業務構造へのより深い興味をかき立てました。
また、ビジネス・アナリスト は当初UMLに抵抗示す人もいたのですが、急速にモデリングの有用性に興味を示し始めました。
また余談ですが、ビジネス・アナリストの中 には、当初、BPMはBPMNを用いて書かれた業務フローをBPELを通してWebアプリケーション化すれば、それでOKだと言う（楽観的な）人もいたの ですが、融合の結果、それでは済まない問題が膨大にある事が、アーキテクト側もビジネス・アナリスト側にも共通の認識として拡がってきました。
恐 らく、基幹業務系はBPM/SOAが、そしてエンド・ユーザー系にはWeb技術に代表される廉価で高速なクイック・ソリューションがクラウド市場の中心を 占めていくと思います。
OMGはもともとはCORBAに代表される分散処理技術者の集まりでした。人的、歴史的には、80年代に流行った人工知能 (AI)をやってた人が流れて来たパターンが多いようです。
では、いつ頃からアーキテクトが集まりだしたかというと、90年代の半ばにUMLの標 準化が始まりだした頃からです。
その頃から上流工程に従事するエンジニアがモデリングに興味を示し始め、アーキテクトの割合が増加してきました。
2000 年前後になるとITソフトウェアだけではなく、ハードウェア設計にもUMLを使う動きが顕著になってきて（ハードウェア設計と言っても上流設計、概念設計 です。念のため）、UMLバージョン１のソフトウェア中心の表記法では用が足らず、より論理的な構造を持つモデリング言語（メタ言語構造を持つ言語）とし てUML2.0が誕生しました。
2001年には、INCOSE(International Council of Systems Engineering：直訳すると国際システム工学学会ぐらいか？）と共同で現在のSysMLのひな形を作る作業が開始されました。
ちなみに SysMLは、UMLの自己拡張機能、プロファイリング機能を用いて作られていますので、厳密に言うとUMLの一種です。
また、話がそれますが （ブログなので流れのまま書いてます）、現在、プロファイリング以外の言語拡張の手法が検討され始めており、今後違った動きも見られると思いますが、恐ら くここ１０年はプロファイリング中心のやり方になるでしょう。（SysMLのひな形誕生から普及まで（つまりツール・ベンダーによってツール化されるま で）に7〜８年かかっていますので。）
2000年ぐらいには上流側の分科会（プラットフォームに対してドメイン側で、ファイナンス・タスクフォー ス等のように産業別に作られ始めました）が徐々に活発になり、BPMI(ビジネス・プロセス・マネジメント・イニシアティブ）との合併はドメイン側へのシ フトを決定づけました。
また世の中のお金の流れもプラットフォームからドメイン側に代わり、IT産業の主役もプラットフォームを作っているメー カーから、先進的な利用を行っているユーザー側にシフトし始めます。
そして、従来のアーキテクト中心のメンバー構成にビジネス・アナリストの集団 が融合し始めます。
ビジネス・アナリストの参入はOMGにとって業務構造へのより深い興味をかき立てました。
また、ビジネス・アナリスト は当初UMLに抵抗示す人もいたのですが、急速にモデリングの有用性に興味を示し始めました。
また余談ですが、ビジネス・アナリストの中 には、当初、BPMはBPMNを用いて書かれた業務フローをBPELを通してWebアプリケーション化すれば、それでOKだと言う（楽観的な）人もいたの ですが、融合の結果、それでは済まない問題が膨大にある事が、アーキテクト側もビジネス・アナリスト側にも共通の認識として拡がってきました。
恐 らく、基幹業務系はBPM/SOAが、そしてエンド・ユーザー系にはWeb技術に代表される廉価で高速なクイック・ソリューションがクラウド市場の中心を 占めていくと思います。
2010年5月20日木曜日
アーキテクチャー：メタモデルのすすめ ④
要件分析・概念設計の日本固有の現象
創造性の軽視
前回は上流設計の重要性を書きましたが、仕事柄、筆者は開発プロジェクトに関与する事が度々ありますが、最近はつくづく、 その違いを考えさせられます。最近は日本でもUMLの使用率がかなり上がって来ていますが、大半が実装設計以降での下流工程での使用が中心的で す。
最近はオフショア開発の条件として要件仕様をUMLで書く事が条件になるケースも多いのですが、現地のエンジニアからは、日本の UMLは要件を本当に分析したのか？とか、分析した形跡がまったく見あたらない、と言う意見を聞きます。
「要件仕様をUMLで書いてくれ」と言う リクエストは、国際的には「要件をオブジェクト指向分析設計してくれ」とほぼ同義語ですが、日本人は文字通り、単に表記法としてUMLで書く、と言う意味 で捉えられてる形跡があります。
巷間、日本の携帯電話がなぜ海外で売れないかが一時話題になりましたが、多くの人は、実装技術ではなく要 件分析等の上流工程の品質の問題を指摘していました。
本来、要件設計や概念設計は製品やサービスの価値を決める最もクリエイティブなフェーズであ り、モデリング技術も本来そのために発展して来たものですが、全体に日本のエンジニアは実装設計には熱心ですが、上流工程にモデリングを持ち込む事が苦手 なようです。
アーキテクチャーも同様な傾向が見られ、上流工程のアーキテクチャーよりも実装のアーキテクチャーにのみ関心が集中する傾向 があります。
2010年5月3日月曜日
アーキテクチャー：メタモデルのすすめ ③
前回、筆者が80年代にアメリカにいた頃の話を書きましたが、その当時は、たまに日本に帰ってくると、時間を見つけては日本の港町に旅行に行きました。
羽田空港からそのときの気分のまま適当に切符を買い、着いた地方空港でレンタカーを借りて、気の向くままドライブしましたが、どういう訳かよく海の方、港 の方へ足が向きました。
そんなある日の事、筆者は、半日のドライブの後たどり着いた小さな漁港に面した居酒屋兼旅館と言った風情の店が気に入り、 ふらりと暖簾をくぐりました。
海の上に大きく赤く腫れぼったい天空の目のような満月が上り、そこは井伏鱒二氏の描くような浪漫的な夕暮れの港町でした。
こんな町で暮らす事が出来たら、どんなに素晴らしい人生だらうか、と若かった筆者はこの静かな美しい港町の生活を想像しながら宿を請うと、奥からごく若い 愛想の良い女将さんが宿帳を持って現れました。
女将さんは、筆者のペン先を見ながら、筆者が「神奈川県」とか「横浜市」と言った当時の住所を書いていくたびに、「はぁ〜」と深いため息をつき、「○○ 区」とか「××町」と進み、所番地あたりを書くあたりになると彼女の感嘆は最高潮に達しました。
彼女の不思議な反応が気になり、筆者は書く手を止めて顔を上げて彼女の顔を見ました。
女将さんは、「昔住んでいた町のすぐそばの所番地だったので、懐かしさのあまり声を上げて仕舞いました」、と訳を話し非礼を詫びました。
彼女は数 年前にこの港町にお嫁に来て、以来一度も横浜には帰っていなかったそうです。
そして、時たま何の目的も持たずふらりと風のようにやって来て、また 風のように去って行く旅の人が現れるが、心底羨ましいと語りました。
人間は、お互いに、自分のないものを羨むもののようです。
オブジェクト指向分析設計も歴史をひも解くと、元々は要件の分析と概念設計の為にモデリング言語が 開発されました。
従って、UMLは本来要件フェーズで最も活用されるべきツールです。
しかしながら、日本での使い方は圧倒的に実装フェー ズで実装設計のツールとしてのみ使われる事が多いようです。
本来、要件を記述するための言語であったUMLがむしろ実装設計にのみ用いられる状況 は、恐らく日本固有の現象のようです。
これは、実装のアーキテクチャーにのみ興味があり、上流部分（ドメイン側）のアーキテクチャーに無 関心な現況とも一致する現象です。
全体に東アジア圏の国々（日本、韓国、中国等）は、実装技術に強い関心を示す反面、ドメイン側に対する 興味は非情に薄いと言われていますが（興味が薄いのではなく、アーキテクチャーやモデリング技術を上流行程に持ち込む発想が薄いだけだと思いますが）、日 本はその傾向が顕著なようです。
理由はともあれ、日本は結果的に上流行程のアウトプット品質が非常に悪いと言う定評を得つつあるのは残念です。
特 徴的なのは、UMLを使わないから悪いのではなく、UMLを用い て書いた要件仕様でも、分析を行なった形跡がなく、単なる表記法としてのみ用いられていて品質の向上が見られないと言うのが平均的な現況の ようです。
昨今のこの状況に対し、日本でも要求フェーズの品質を高める事が脚光を浴び始めて来ました。
しかしながら、水をさすよ うですが、要求フェーズの品質向上だけでは、大した改善は期待出来ない、と言うのが歴史的事実です。
羽田空港からそのときの気分のまま適当に切符を買い、着いた地方空港でレンタカーを借りて、気の向くままドライブしましたが、どういう訳かよく海の方、港 の方へ足が向きました。
そんなある日の事、筆者は、半日のドライブの後たどり着いた小さな漁港に面した居酒屋兼旅館と言った風情の店が気に入り、 ふらりと暖簾をくぐりました。
海の上に大きく赤く腫れぼったい天空の目のような満月が上り、そこは井伏鱒二氏の描くような浪漫的な夕暮れの港町でした。
こんな町で暮らす事が出来たら、どんなに素晴らしい人生だらうか、と若かった筆者はこの静かな美しい港町の生活を想像しながら宿を請うと、奥からごく若い 愛想の良い女将さんが宿帳を持って現れました。
女将さんは、筆者のペン先を見ながら、筆者が「神奈川県」とか「横浜市」と言った当時の住所を書いていくたびに、「はぁ〜」と深いため息をつき、「○○ 区」とか「××町」と進み、所番地あたりを書くあたりになると彼女の感嘆は最高潮に達しました。
彼女の不思議な反応が気になり、筆者は書く手を止めて顔を上げて彼女の顔を見ました。
女将さんは、「昔住んでいた町のすぐそばの所番地だったので、懐かしさのあまり声を上げて仕舞いました」、と訳を話し非礼を詫びました。
彼女は数 年前にこの港町にお嫁に来て、以来一度も横浜には帰っていなかったそうです。
そして、時たま何の目的も持たずふらりと風のようにやって来て、また 風のように去って行く旅の人が現れるが、心底羨ましいと語りました。
人間は、お互いに、自分のないものを羨むもののようです。
上流行程の重要性とその限界
ソフトウェア工学によると、ソフトウェアの品質に最も影響を与えるのは設計フェーズの品質であり、その設計 に決定的な影響力を持つのが要件フェーズです。オブジェクト指向分析設計も歴史をひも解くと、元々は要件の分析と概念設計の為にモデリング言語が 開発されました。
従って、UMLは本来要件フェーズで最も活用されるべきツールです。
しかしながら、日本での使い方は圧倒的に実装フェー ズで実装設計のツールとしてのみ使われる事が多いようです。
本来、要件を記述するための言語であったUMLがむしろ実装設計にのみ用いられる状況 は、恐らく日本固有の現象のようです。
これは、実装のアーキテクチャーにのみ興味があり、上流部分（ドメイン側）のアーキテクチャーに無 関心な現況とも一致する現象です。
全体に東アジア圏の国々（日本、韓国、中国等）は、実装技術に強い関心を示す反面、ドメイン側に対する 興味は非情に薄いと言われていますが（興味が薄いのではなく、アーキテクチャーやモデリング技術を上流行程に持ち込む発想が薄いだけだと思いますが）、日 本はその傾向が顕著なようです。
理由はともあれ、日本は結果的に上流行程のアウトプット品質が非常に悪いと言う定評を得つつあるのは残念です。
特 徴的なのは、UMLを使わないから悪いのではなく、UMLを用い て書いた要件仕様でも、分析を行なった形跡がなく、単なる表記法としてのみ用いられていて品質の向上が見られないと言うのが平均的な現況の ようです。
昨今のこの状況に対し、日本でも要求フェーズの品質を高める事が脚光を浴び始めて来ました。
しかしながら、水をさすよ うですが、要求フェーズの品質向上だけでは、大した改善は期待出来ない、と言うのが歴史的事実です。
登録:
投稿 (Atom)