« ロバストネス図の使い道 | トップページ | 組織的な阻害要因は欧米人と日本人で問題の観点が異なる »

2014/04/13

日本でモデリングツールが使われない背景

日本でモデリングツールが使われない背景について記事があったのでメモ。

【参考1】
プロマネBlog: SysML 中級講座: 第7回 日本のモデリング事情

(引用開始)
北米が50%を占めていますが、そのうち大半がUS(合衆国)です。
欧州市場は40%を占めていますが、その40%のうちの7割ぐらい(全体比で30%程度)は英独仏の3カ国で占められています。
そして、残りの10%は、日本を含むその他すべての国を意味します。
この図で、日本のモデリング市場の特徴を見る事が出来ます。
一般のソフトウェア市場で見た場合、日本の市場規模はアメリカに次いで2番目に大きく、国別ではヨーロッパのどの国よりも大きいのが通例です。
しかしながら、モデリング・ツールの市場で見た場合、アジア市場は非常に小さく、また日本は、そのアジア市場でも必ずしも多数派ではなく、インドやオーストラリアなどと横並び状態です。
日本は決してソフトウェア投資、IT投資をしてない訳ではなく、GDP比で見ても、投資額で見ても、先進国の中では中の上くらいに位置しますが、 モデリング・ツールをあまり使わないと言う点で、相対的に異質です。
欧米の専門家は、ツールを用いないモデリングは実用性に欠けると考える人が圧倒的であり、筆者自身の経験から言っても、欧米で、ツールを使わないでモデル・ベース開発を行なっている現場を見た事がありません。
また、このポイントは、IPAのモデリング部会(筆者もOMG代表として出ております)の日本企業に対するアンケート結果に示される「モデリングの実用性に不満を持つ層が多い」と言う事実と符合します。
日本は、モデリングそのものに関する知見は高いものの、実用のための知見に乏しいと言っても良いのではないか、と言うのが率直な感想です。
(引用終了)

【参考2】
プロマネBlog: SysML 中級講座: 第8回 日本のモデリング事情  2

(引用開始)
以前のブログで、日本のモデリング事情の特徴の1つとしてツールの使用度が非常に低い事を挙げました。
そして、このことが多くの日本の組織がモデリングが実用な技術ではないと感じていると言う調査結果と方向的に一致していると述べました。
本日は、それでは、「なぜ日本ではモデリング・ツールが使われなかったのか?」と言う事について議論してみたいと思います。
非常に多くの要因が考えられると思います。例えば、財務上の問題でツールが買えない、とか、上司が旧来の実績ある方法に固執している、現状の方法論で十分間に合っている、以前使った事があるが上手くいかなかった、プログラマ達が新しいやり方に抵抗を示す、等々、日本の組織の数だけ理由が出てくる事でしょう。

現実問題として、日本のエンジニアが全員一律にモデリング開発を行う必要はなく、現状で満足できるのであれば、わざわざリスクを取る必要が無い事は事実ですが、既に旧来の方法の限界に直面しているにもかかわらず、モデリング手法を取り入れる事を躊躇する組織が多く見受けられます。
大別すると、①以前ツールを使ってみたが、その後使わなくなった(挫折型)と②使った事が無い(食わず嫌い型)に分かれると思います。
今、筆者が非常に興味を持っているのが①の挫折型です。
と言うのも、日本以外、特に欧米では①のパターンを殆ど見かけないからです。

欧米の開発現場の新入社員は、最近では、殆どがUMLを学校でならって入社して来ています。
そして、大学(院)では、UMLはツールを使いながら学習しています。
ちなみに、話の枕に取り上げたMITの数学の講義ですが、線形代数の講義中、要所要所でMATLABではどう計算するか、と言うポイントを講師が簡単に説明しており(実演は無し)、数学の教育にもツールを取り入れている事がうかがえます(日本で言うと、教養課程の数学教育の段階でMATLABを使用)。
従って、大学(院)でUMLを習った場合、
UMLを知っている ≒ UMLツールが使える
と言う公式が成り立ちます。(これは、学生本人や企業が期待するところでもあります。)
(引用終了)

【1】2000年代前半なら、モデリング・ツールと言えば、RationalRoseが主流だった。
使い道は、モデル駆動開発。
つまり、UMLでクラス図、シーケンス図を書いて、そこからソースを自動生成して実装していく。

でも、ソースを修正すれば、モデルと相違点が出てくる。
本番リリース後に次々に出てくる障害修正パッチを当てていくと、WF型開発で作ったモデルはもはや、現実のシステムを表現していない。
かと言って、モデルを直してからソースを自動生成するやり方は、モデルの修正箇所が多いほど、修正時間が長くなる弱点がある。

結局、モデル駆動開発の問題点は、モデルとソースの同期が最大のボトルネックという感想を持っていた。
モデリングツールがモデル駆動開発を標榜する限り、その問題から離れることはできない。

【2】モデリングツールが使われない原因として、「上流工程の分析よりも下流工程の実装に興味がある」という話もある。
おそらく、日本における設計のイメージは、詳細設計書レベルのイメージが強いのだろうと思う。

プロマネBlog:アーキテクチャー:メタモデルのすすめ ③
(引用開始)
上流工程の重要性とその限界
ソフトウェア工学によると、ソフトウェアの品質に最も影響を与えるのは設計フェーズの品質であり、その設計に決定的な影響力を持つのが要件フェーズです。
オブジェクト指向分析設計も歴史をひも解くと、元々は要件の分析と概念設計の為にモデリング言語が開発されました。
従って、UMLは本来要件フェーズで最も活用されるべきツールです。
しかしながら、日本での使い方は圧倒的に実装フェーズで実装設計のツールとしてのみ使われる事が多いようです。
本来、要件を記述するための言語であったUMLがむしろ実装設計にのみ用いられる状況は、恐らく日本固有の現象のようです。
これは、実装のアーキテクチャーにのみ興味があり、上流部分(ドメイン側)のアーキテクチャーに無関心な現況とも一致する現象です。
全体に東アジア圏の国々(日本、韓国、中国等)は、実装技術に強い関心を示す反面、ドメイン側に対する興味は非情に薄いと言われていますが(興味が薄いのではなく、アーキテクチャーやモデリング技術を上流行程に持ち込む発想が薄いだけだと思いますが)、日本はその傾向が顕著なようです。
理由はともあれ、日本は結果的に上流行程のアウトプット品質が非常に悪いと言う定評を得つつあるのは残念です。
特徴的なのは、UMLを使わないから悪いのではなく、UMLを用いて書いた要件仕様でも、分析を行なった形跡がなく、単なる表記法としてのみ用いられていて品質の向上が見られないと言うのが平均的な現況のようです。
昨今のこの状況に対し、日本でも要求フェーズの品質を高める事が脚光を浴び始めて来ました。
しかしながら、水をさすようですが、要求フェーズの品質向上だけでは、大した改善は期待出来ない、と言うのが歴史的事実です。
(引用終了)

プロマネBlog:アーキテクチャー:メタモデルのすすめ ④

(引用開始)
要件分析・概念設計の日本固有の現象
創造性の軽視
前回は上流設計の重要性を書きましたが、仕事柄、筆者は開発プロジェクトに関与する事が度々ありますが、最近はつくづく、その違いを考えさせられます。
最近は日本でもUMLの使用率がかなり上がって来ていますが、大半が実装設計以降での下流工程での使用が中心的です。
最近はオフショア開発の条件として要件仕様をUMLで書く事が条件になるケースも多いのですが、現地のエンジニアからは、日本のUMLは要件を本当に分析したのか?とか、分析した形跡がまったく見あたらない、と言う意見を聞きます。
「要件仕様をUMLで書いてくれ」と言うリクエストは、国際的には「要件をオブジェクト指向分析設計してくれ」とほぼ同義語ですが、日本人は文字通り、単に表記法としてUMLで書く、と言う意味で捉えられてる形跡があります。
巷間、日本の携帯電話がなぜ海外で売れないかが一時話題になりましたが、多くの人は、実装技術ではなく要件分析等の上流工程の品質の問題を指摘していました。
本来、要件設計や概念設計は製品やサービスの価値を決める最もクリエイティブなフェーズであり、モデリング技術も本来そのために発展して来たものですが、全体に日本のエンジニアは実装設計には熱心ですが、上流工程にモデリングを持ち込む事が苦手なようです。
アーキテクチャーも同様な傾向が見られ、上流工程のアーキテクチャーよりも実装のアーキテクチャーにのみ関心が集中する傾向があります。
(引用終了)

最近、IPAの分科会でも、要求分析の工程で機能要件だけでなく非機能要件も考慮したり、超上流工程というバズワードで要求の品質をあげようという流れがある。
しかし、それらの活動にモデリングツールを使って、要求の品質を改善しようとする動きはあまりない。

モデリングツールを使わない要件分析や設計作業の成果物は、Excelで書かれた膨大な日本語のドキュメントだ。
それらは印刷されないと、特に50代以上のマネージャは読んでくれないので、大量のバインダーで保管されることになる。

日本語ので書かれたドキュメントはたしかに必要だが、運用保守されていくうち、現行システムと乖離が生じやすい。
1件の障害修正で、影響する要件や仕様を修正する必要があるが、その考慮が漏れてしまったり、書いていくうちに粒度が変わってしまったりする。

結局、設計書の間のトレーサビリティが意識されないまま、修正されてしまうのが最大の問題。
仕様の修正とモデルの変更の間のトレーサビリティの確保は、モデリングツールで自動補完されなければ、人手による作業は無理だろう。

【3】日本では、何故、モデリングツールが使われないのか?
上記のような問題点だけでないと思う。

個人的には、日本のSIの現場では、ソフトウェア開発を効率化するためのツールや環境に投資しない、という発想がすごく根強いと思う。
売上を上げる前に、お金を投資して、開発環境を整備しよう、という発想が、特にマネージャ層にない。
彼らは売上のコスト責任があるので、コストはできるだけ減らして、利益を確保したい動機がある。
つまり、マネージャ層の考え方や行動は、全体最適化の結果ではなく、局所最適化の結果であると言える。

そんな環境にあっても、オープンソースの開発ツールやモデリングツールを使う場合は、マネージャも大目に見てくれる。
運用ノウハウが事前にあれば、どうやって現場に浸透させると効果が出るのか、という利点も説明しやすくなる。

最近は、モデリングだけでなく、開発プロセスもツールで効率化していく手法が盛んに研究されている。
その辺りの流れも踏まえて、色々考えてみる。

|

« ロバストネス図の使い道 | トップページ | 組織的な阻害要因は欧米人と日本人で問題の観点が異なる »

モデリング」カテゴリの記事

コメント

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



« ロバストネス図の使い道 | トップページ | 組織的な阻害要因は欧米人と日本人で問題の観点が異なる »