|
|
８０年代の頃から，物事を簡単にするということに関しては様々な試みがなされてきました。構造化分析手法とか，オブジェクト指向という考え方ももつきつめていえば，複雑な問題をどう簡単にするかということを目指したものであるといえます。
問題を簡単に解決できると言うことは，上で述べたような費用対効果以外にも，品質が劣化しない。短期間で実現出来る，うまくいかなくても負うべきリスクが少なくてすむなど計り知れないメリットがあります。
|
では，どのようにすれば物事を簡単化できるでしょうか。通常簡単な解を求めるには次の４ステップが必要です。
(1)現実を整理する
(2)問題点を見つける（あるいは本質を見きわめる）
(3)解決すべきゴールを設定する
(4)そのゴールにたどりつくための最短距離を何度も繰り返し考える。
といったステップを踏みます。 |
|
| ■(1)現実をいかに整理できるか |
一般的にシステム開発などのプロジェクトは現状がどのようになっているのかということを整理する事から始めます。実際に現場に行って，インタビューをしたり，使われている帳票や業務の流れを分析します。これは，複雑に絡み合ったひもの束を丁寧にほぐしていくようなものです。
現実の実体を分析し簡単にするには一般的に図式化することをします。図式化は物事を簡単化するうえでの第一歩です。
電話帳のような分厚い文書資料よりも，A3１枚くらいの図の方がずっと物事を理解しやすくなります。では，電話帳のような内容をA3一枚にどのように集約したら良いのでしょうか。これが絵なのです。 |
昔からSEの訓練としては絵を描かせます。文字を読むのでなく視覚から入ってくる情報は何万倍ともいわれています。特に概念などのようなものを絵にするということは，システム分析の第一歩です。
巻紙解析とかワークフロー分析，システムフローチャート等伝統的なものから，最近ではUML（統一モデル化言語）のなかのユースケース図などが該当します。絵を描く場合，芸術作品を作るわけではないので，無手勝流とか自分だけがわかるようなものはあまり適しません。
第３者が見てわかるものという観点からは，世の中で採用されているルールに従って書くことが望ましいです。
|
ユースケース図 |
■データの変化に注目した分析
現実のモデルを絵に表現する場合，業務上意味のある単位に分けて考えると言うことをします。これは構造化分析という考え方で，最近では，カプセル化とか，コンポーネント化などとも言われますが，複雑な現実の業務を山分けし，グルーピングして，一言で言ったらこの業務はなにをやっているという観点から整理することです。ここは，残念ながら分析者の個人的な経験や腕（うまい下手）がでる部分です。
山分けをやりやすくするツールとしては，KJラベル，PNカード，CRCカードなどがよく使われます。同じような業務を山分けし（つまり似たようなもの）にグルーピングして最終的にはターゲットとするシステムを最大でも７つぐらいの山に分けます。７つ前後というのが重要で，これを越えると一目で見て理解できなくなり，これより少ないとあまり簡潔すぎてターゲットの特徴が現れにくくなります。
ここで重要なのは，時間や組織，業務の流れなどで山分けするのではなく，何のためにやっているかとか，その結果どうなるかという観点で山分けすることです。たとえば，作業担当者が伝票や指示書に基づいて行っているものと，センサーなどで自動認識しているものは，一見見た目では違うフローのように思えますが，結果は検査済みになるというのであれば同じ山にすることが正しいです。
|
こういった観点，つまり未検査状態が検査済み状態になるなどというデータの属性の変化に注目して分析することをデータ中心分析といいます。なぜデータの遷移に注目するかと言えば，業務改善などでプロセスや順序・やり方等が変わっても，データの遷移は変わらないという事実があるからです。データベースアプローチも同じ様な考え方に基づいています。この点に注目すると，変化につよい物事の本質をついたモデルを作ることができなす。
手順とかプロセスといたといった目に見える動きが違っていても，ビジネスとしての本来の意味は変わらない。という本質を見抜くことが重要です。これは，オブジェクト指向でいうところのクラスの発見に他なりません。 これらの手順を総合してモデリングといっています。
山分けしてグループ化するもう一つのポイントは，物理条件をとってしまうということです。上で言っている本質というものの裏腹かもしれませんが，人もの金時間組織といった物理条件をとって，流れを考えてみると物事の本質が見えてくるものです。これを一般的には抽象化といいます。いちばんだめなのは，物理条件をフォローしたシステムを構築してしまうことです。現状のプロセスをトレースしたようなシステムは，ほぼ１００％効果がでないか，早い時期に破綻します。
|
|
| (2)問題点や本質を見極める |
問題点とは，言うまでもなくあるべき姿と現状とのギャップです。この問題点，ちょっと現場を分析すれば１０も２０も，PNカードなどでアンケートを採れば１００くらいは平気で出てくるものです。このなかから，問題の本質を見極めるのが問題分析です。
このやり方としては，昔からあるフィッシュボーンチャートなどがありますが，問題点ネットワーク図というものもよく使われます。 |
つまり，ある問題点Aというものは，別の問題点Ｂがあるために派生して起こる問題点で，もし問題Ｂがなかったら，問題Aも無いというように，因果関係で問題点をつなげたものです。そして，キーとなる問題点を見つけだすことです。これは，患者が訴える様々な症状や検査データから，病気の原因を見つけるプロセスに似ています。 |
キーとなる問題点を探す |
|
| (3)問題の抽出と解決すべき目標を決める。 |
上記問題点を解決する目標を設定します。通常キーとなる問題の逆表現をしあます。たとえば，販売会社最前線の在庫が多すぎるというのが，問題だとしたら，販売会社最前線の在庫を最小限にするということを逆表現とします。
これでは，言葉のトリックで解決策にはなりません。 |
これを数字にします。たとえば，前線在庫をゼロにするとか，半日分にするとかいうように決めます。あるいは主力商品のみ２日分在庫するなどということを決めます。
|
|
| (4)そのゴールにたどりつくための最短距離を何度も繰り返し考える（イテレーション） |
最後は，この目標を実現するための方策を，いくつも繰り返し検討します。最初に考えついたものだけでなく何度も繰り返し，「もっと簡単にならないか」とか，発送の転換をするとか，逆に考えてみるとかいうことをします。
たとえば，最前線すべてに，POS端末を入れるという案もあれば，在庫なし販売を行う方法を考えるというのも良いかもしれません。
とにかく，山の頂上につくルートは一つだけではなく，すべての山が頂上についたとしても，最短でいちばん楽なルートを見つけだすことが成功要因です。時間がある限り，何度も何度も簡単になる方法を繰り返し見つけだすことです。これを一般的にはイテレーションと呼んでいます。 |
このイテレーションがうまくいけば，効果が大きく非常に簡単な業務システムが設計できます。つまり簡単に考えれば，コンピュータ化は必要ないかもしれません。ここをおろそかにして，ERPパッケージをいれてPOS情報をリアルタイムでとって・・・・などといっても効果が同じ程度なら，業務改善のほうが得策であるといえます。
すべての問題点の９０％は簡単な方法で解決できると言うことをゴールデンルールで業務改善を進めてください。 |
ゴールに到達するもっとも簡単な方法を見つける |
|
