知識のフレームワーク

自分はなぜ、知らない業務の見える化ができるのだろうか?

コンサルティングをやりながら時折そう思う。

逆に言うと、優秀な方々が忙しく業務をこなしていながらも、どうして自分の業務をわかりやすく説明したり、「見える化」できないのだろうか。

昨日、コンサルをやりながら、このことを少し考えてみた。
続き

ファイル 5-1.jpg

僕は、仕事を入れる箱を常に考えている(B)。

その箱には仕事(作業)をグループ化して入れている。

また、その箱は、役割、目的、価値で評価される。

ポイントとしては、この箱は、AsIs(現在)の業務ではなく、ToBe(将来のあるべき姿)として役割、目的、価値を定義する。

この役割、目的、価値で評価デザインされたToBeの箱に現在の作業を入れてみると、作業の中で改善すべき点や、意識を変える部分が見つかる。

このような箱のデザインをターゲットとなる業務全体に行いつつ、その時系列の流れを定義したり、関係を定義する。これはUMLで表現可能。

箱と箱との関係 (概念モデル:UMLクラス図)

箱と箱との流れ (業務フロー:UMLアクティビティ図)

そして、その次に面白い事が脳の中で起こるのだ。

作業を囲む箱の中から、作業そのものを取り去り、箱の関係だけを残すのである。
中身なき箱の構造だけを取り出し普遍的な知識としてスタックしている。

この中身なき箱の枠組み構造に異なる問題領域の作業・活動を当てはめることをやっている。

たとえば要求開発の下記の図は、そうやって生まれたものである。

ファイル 5-2.jpg

この図は、要求開発とシステム開発の各段階での活動を先に考えて、それを目的・価値で極端にシンプルに分類。その後活動を取り去ったものとなる。

これも知識のフレームワーク。