TOP
＞
プロジェクト管理
＞ 「見える化」の目的
見える化とは何か〜改めて問うその真価
第１回：「見える化」はなぜ必要か？
著者：
チェンジビジョン 平鍋 健児
2006/10/26
1
2
3
次のページ
「見える化」の目的
最近、「見える化」という言葉が広く使われるようになった。ソフトウェア開発やプロジェクトマネジメントの文脈において、「トヨタ生産方式」が再度見直されていることが理由の１つであるが、この「見える化」という漢字かな混じり語のベタっとしたインパクトも大きく貢献していると思う。
この言葉からは「現場」や「アナログ」のにおいがする。スマートさからは離れているが、逆に「粘り強さ」や「実践感」といった点で「可視化」という無機質な言葉とは一線を画している。
実は、ここが「見える化」の肝であり、物理的な「モノ感」であったり、体を使った実践的な「行動」に繋がってはじめて見える化なのである。
つまり「見える」だけでは「見える化」とはいわない。
そこから喚起される実際の物理的な感触が、問題の解決にむけた身体的な行動を生み出してはじめて
「見える化」
なのだ。
そういう意味で、「何のための見える化か？」ということは、常に問わなければならない設問なのである。本連載では、当社のコンセプトでもある「見える化」について、その意義と具体的な手法について紹介したい。
現在多くのシステム開発現場で発生している混乱は、以下の3つにその多くの原因がある。
ソフトウェアの構造が目に見えないこと
ソフトウェアへの要求がうまく捉えられないこと
ソフトウェアの開発状況（進捗）が目に見えないこと
表1：システム開発現場の混乱の原因
これら3つの見える化について、順に解説していく。
ソフトウェア構造の見える化
最初に、「ソフトウェア構造の見える化」から話をはじめよう。
システム開発の現場を建築の現場と比べてみる。例えば、欠陥の認識はどのように行われるだろうか。建物では水漏れがあれば、その部分を指差して「ここから水が漏れています」とか、図面を指差して「このあたりに亀裂があるようです」と視覚的に示すことができる。
建物は物理的な構造物であり、実際に空間を占有しているために視覚化が比較的容易なのだ。一方、ソフトウェアの場合「ここ」とか「このあたり」というのは何に対応するのだろう。幸いソフトウェアにも建築と同様の「構造」という概念があり、それを「アーキテクチャ」と呼んだりする。
まずは、この「アーキテクチャ」を見えるようにする（可視化する）ことが、システム開発の中で最も重要なことである。それは「文書」では駄目だ。文書では「このあたり」という人間の右脳感覚が働かない。「色」と「形」を持った構造物である必要がある。
1996年にオブジェクト指向設計図解法の集大成として、米国の標準化団体OMG（Object Management Group）によって、UML（Unified Modeling Language）が定義された（図1）。
図1：ソフトウェア構造の見える化（JUDEによるUMLの例）
（画像をクリックすると別ウィンドウに拡大図を表示します）
それまではいくつもの流派があった図解法が1つの標準として統合されたのだ。この図解法はベンダーニュートラルであり、国際標準であり、ツールも教育も書籍も揃っている。今この図解法を使って、ソフトウェアのアーキテクチャの静的構造と動的構造を「見える化」することが、システム開発を進めていく中でキーになってきている。
この流れは何十何百というエンジニアが参加する大規模開発や、設計工程と製造工程を分離して後者を人件費の有利な海外で行うオフショア開発で、特に顕著である。（この是非についてはここでは議論しない）
このようにソフトウェアの構造を「色と形をもった図」で右脳感覚に訴求することで、「あそこ」や「ここ」と指を差せる状態を作ることができ、その結果チームメンバーの意思の疎通が素早くなり、誤解を少なくすることができる。
1
2
3
次のページ
著者プロフィール
株式会社チェンジビジョン 平鍋 健児
代表取締役社長
1989年東京大学工学部卒業後、3次元CAD、リアルタイムシステム、UMLエディタJUDEなどの開発を経て、現在コンサルタントとしてオブジェクト指向とアジャイル開発を研究、実践中。アジャイルプロセス協議会副会長、要求開発アライアンス理事。翻訳書多数。
INDEX
第1回：「見える化」はなぜ必要か？
「見える化」の目的
ソフトウェアの要求の見える化
「かんばん」によるタスクの見える化
