• ビジネス
  • IT
  • テクノロジー
  • 医療
  • 建設・不動産
  • TRENDY
  • WOMAN
  • ショッピング
  • 転職
  • ナショジオ
  • 日経電子版
  • 日経BP
  • PR

  • PR

  • PR

  • PR

  • PR

萩本・匠スタイル研究所

第8回 論理的美の虚像(その2)

萩本 順三=匠Lab代表取締役、匠BusinessPlace代表取締役 2009/07/21 日経コンピュータ

 ビジネスとITの摩訶不思議な世界を“創発号”に乗って旅する匠Style研究所。第8回は、前回に引き続き、僕がソフトウエア開発の経験や要求開発を通して、少しずつ分かってきた人間の活動における普遍的な成功パターンをテーマにします。それは、一般常識を飛び越えていかなければ見つからない面白い領域の話しです。

 前回は、下手な論理思考がもたらす、論理的な“美の虚像”を追いかけてしまうことの弊害と、学習用の手法では実際の現場に適用できないという、結論じみたことを紹介して終わりました。

 しかし、この問題は、そんな簡単なことではありません!!

暗黙知を形式知に変えるチャレンジは否定できない

 暗黙知を形式知に変えることへのチャレンジを、簡単に否定することなどできないのです。こうした努力は、システムエンジニアという職業に就く限り、あきらめてはなりません。

 ただ、僕が主張したいのは、安易に論理性で手順的なやり方を見つけ、それを形式化してしまうことによる弊害が大きいということです。少しITの専門的な話しになりますが、「システム要求から、ソフトウエア論理構造につなげる」、すなわちユースケースからロバストネス分析を経由して分析モデルを作ることを例に考えてみましょう。

 もしITにあまり詳しくない方の場合、3ページ目中段にある小見出し「常識を疑い、打ち破ろう」まで読み捨てていただいても結構です。

 「ユースケースからロバストネス分析を経由して分析モデルを作る」という方法は、システムに対する機能的な要求からシステムの論理構造に変換するための手法として、ある程度の規模があり、オブジェクト指向技術を使う開発でよく使われています。

 具体的には、ユースケースを書き、そのユースケースに対するユースケース記述を書く。そのユースケース記述からロバストネス分析図を書き、複数枚からなるロバストネス図の中に表れるクラス(バウンダリ、コントロール、エンティティ)の責務を統合するなどの結果から、分析モデル(概念モデル)を作ります(図1)。

図1●ロバストネス分析による分析モデルの抽出
[画像のクリックで拡大表示]

ここから先はITpro会員(無料)の登録が必要です。

次ページ ロバストネス分析による弊害
  • 1
  • 2
  • 3
  • 4

あなたにお薦め

連載新着

連載目次を見る

今のおすすめ記事

ITpro SPECIALPR

What’s New!

経営

アプリケーション/DB/ミドルウエア

クラウド

運用管理

設計/開発

サーバー/ストレージ

クライアント/OA機器

ネットワーク/通信サービス

セキュリティ

もっと見る