2006年05月27日

芋づる式分解

 ここまで紐解いてみて、自分がプログラムの仕組みを明確化するとき、たった2つのMECE的分解のフレームワークをつかって作業しているという事実に気がついて、われながら驚いています。
 その2つのフレームワークとは、
(1)「2006年05月22日 分解レベルの判断基準」の記事で説明した「外部入力、外部出力、外部データ、外部処理」で、名づけて「処理に関わる4つの外部要素」
bunkai1.jpg
 
(2)「2006年05月17日 「動作」系の関係の違い」で説明した「登録、更新、参照、削除」で、名づけて「データを操作する4つの処理」
bunkai2.jpg

です。
 実際に作業するときは、(1)で分解した結果、新たなデータが出てきたら(2)で4つの処理を洗い出す。そこで新たな処理が出てきたらそれを(1)で分解する、という具合に、2つのフレームワークを当てはめながら、芋づる式に処理を分解しています。芋づる式に分解できるからこそ、次々と効率よくできるのでしょう。

 このことから想像すると、ヒアリングや原因分析などが得意な人も、実はそんなにいろいろなMECE的分解のフレームワークを駆使しているのではなく、1〜2種類のMECE的分解のフレームワークを使って、芋づる式に分解しているのではないでしょうか?
posted by koppe at 22:00| Comment(2) | TrackBack(0) | 7.具体例からMECEを紐解く | このブログの読者になる | 更新情報をチェックする

2006年05月22日

分解レベルの判断基準

 連続投稿ついでに、もうひとつ投稿させてもらいます。
 2006年05月14日の記事を書いてからずっと考えていたことがあります。それは、処理を分解するときに「今回はここまで分解すれば十分」という判断を一体どうやってやっているのかということです。ずっと考えていて、一つの仮説にたどり着きました。それは、「外部との関係がすべて明確になるまで」という判断基準です。

 どこまでが内部で、どこからが外部かというのは、場合によって異なります。開発するシステム全体が内部の場合もあれば、ある機能を実現するプログラムの塊が内部の場合もあるし、1つの関数が内部の場合もあります。内部の範囲は、見積もりや設計などのフェーズごとに異なります。フェーズが後になるほど、設計が進むほど、処理は詳細化されていき、内部の範囲は小さくなっていきます。

 また、あるプログラムと外部との関係には、主に以下の4つがあると思います。
1.入力(渡される)
2.出力(渡す)
3.外部データのアクセス(取りに行く、ためておく)
4.外部処理の呼び出し(外部に処理させる)

 私は、ある処理を分解するとき、その処理にとって上記の4つがいるのかいらないのか、いるのならそれはどのようなものかが明確になるまで、処理を分解しているようです。それは外部との関係のモレやぶれは内部処理のモレやぶれに比べてその影響が大きいことから来ているのではないかと思われます。

 「外部との関係がすべて明確になるまで」分解する。この分解の判断基準は、プログラムの処理を分解するとき以外でも使えるかもしれません。

posted by koppe at 00:32| Comment(0) | TrackBack(0) | 7.具体例からMECEを紐解く | このブログの読者になる | 更新情報をチェックする

2006年05月20日

関係と属性

 2006年05月14日の記事でもう一つ気がついたことがあるので、もう少し続けます。
 その記事で分解した処理の中に、
「FAX出力形式のデータを送信待ちボックスに入れる」
「送信が成功したら(FAX出力形式のデータを)送信済みボックスに入れる」
「送信が失敗したら(FAX出力形式のデータを)エラーボックスに入れる」
という記述があります。この記述の中にある、「FAX出力形式のデータ」と「送信待ちボックス」「送信済みボックス」「エラーボックス」との関係はどうなっているのでしょうか?

 プログラム的にいうと、それぞれのボックスに入っている「FAX出力形式のデータ」は、まったく同じデータです。しかし、「送信待ちボックス」に入っている「FAX出力形式のデータ」は、ただの「FAX出力形式のデータ」ではなく「送信待ちFAX出力形式のデータ」であり、「送信済みボックス」に入っている「FAX出力形式のデータ」は、「送信済みFAX出力形式のデータ」です。「FAX出力形式のデータ」だけをみても「送信待ちFAX出力形式のデータ」かどうかはわかりませんが、「送信待ちボックス」と「FAX出力形式のデータ」とがあって、その間に関係があることがわかって初めて「送信待ちFAX出力形式のデータ」であることが分かるのです。
 このように、「FAX出力形式のデータ」に付加された「送信待ち」という表現は、「何かとの関係において対象に付加される属性」といえるのではないでしょうか。
 
 さらに別の例で考えて見ましょう。ここに2つのたまねぎと2本のにんじんがあるとします。この状態でこれらを分類しようとすると、たまねぎ同士、にんじん同士の分類しか思いつきません。ここで、たまねぎの1つとにんじんの1つでカレーを作ろう、残ったたまねぎとにんじんでサラダを作ろうと思ったとします。すると、先ほどまでただのたまねぎとにんじんだったものが、「カレー用のたまねぎ」「サラダ用のたまねぎ」「カレー用のにんじん」「サラダ用のにんじん」にかわります。
 つまり、それを使って作る料理と結びつけたとたんに、それぞれに「カレー用」「サラダ用」という属性が付加され、新たに「カレー用の食材」「サラダ用の食材」という分類ができるようになったのです。

 私が普段やっているMECE的分解では、この「何かとの関係において対象に付加される属性」を手がかりにして分解することが多いような気がしますが、mokurenさんはどう思いますか?
posted by koppe at 23:19| Comment(0) | TrackBack(0) | 7.具体例からMECEを紐解く | このブログの読者になる | 更新情報をチェックする

2006年05月17日

「動作」系の関係の違い

 と、あっさりmokurenさんに頼るのもあまりに根性なしなので、もう少しがんばって自分なりに紐解いてみたいと思います。
 前の記事であげた分解作業は何MECEになっているのか、まず「登録、削除、参照、更新」機能で考えて見ましょう。

 以前、5月4日の「2枚の写真」の記事で、「関係は2つ以上の対象の間にあるなんらかのつながり」で、関係の種類には、(1)1枚の写真に2つの対象が写っていて初めて存在が分かる「状態」系の関係と、(2)時間をおいて写した2枚の写真を比べて初めて存在がわかる「動作」系の関係があるというような話をしました。
 さて、「登録、削除、参照、更新」機能はそのどちらに当たるでしょう?

 登録、削除、参照、更新の違いは、前の記事で書いたように、対象データを操作する前と操作したあとの状態の違いにあるので、(2)の「動作」系の関係に当たると思われます。mokurenさんが分析していた「人、物、金、情報」の違いである「流れの速さ」も2枚の写真の違いと考えると移動した距離の違いということができますね。ということは、「動作」系の関係の違いは2枚の写真の間の「変化の種類」と言えると思います。
 では、変化の種類にはどのようなものがあるかといえば、「出現」「消滅」「変形」「増加」「減少」など、実はそれほど数が多くないのではないでしょうか。とすると、変化の種類をMECE的分解であげることができれば、「動作」系の関係のMECE的分解が簡単にできるようになりそうな気がします。
posted by koppe at 20:57| Comment(0) | TrackBack(0) | 7.具体例からMECEを紐解く | このブログの読者になる | 更新情報をチェックする

2006年05月14日

これは一体何MECE?

 なるほど、「流れる」という関係の属性が「速さ」ですか。面白い考え方ですね。
また、mokurenさんが試してみた、実際に使われているMECEを「なぜこれはMECEになっているといえるのか」という視点で分析してみると、新しくMECEを作るときのヒントが見つかりそうです。
 そこで、私が仕事の中で使っていると思われるMECE的分解の中で、どういうMECEなのか良く分からないものがあるので、それを紐解くのを手伝ってもらえませんか?
問題のMECE的分解は、プログラムの仕組みを明確化するときの作業に使っています。
たとえば「伝票を顧客にFAX送信する」というような機能を実現するための仕組みを明確化するには、その機能を分解して、どんな処理をどのくらい作るかの見当をつけていきます。
機能分解する作業は、たとえば「伝票を顧客にFAX送信する」機能の場合、およそ以下のような手順でやっています。

(1)まず処理の入力と出力を確認します。
ここでは、入力は「伝票データ」、出力は「顧客にFAXを送る」です。

(2)次に入力から出力するまでに必要な処理を考えます。
「伝票データをFAX出力形式に変換する」
FAX送信は時間がかかるので、直接FAX送信はせずに
「FAX出力形式のデータを送信待ちボックスに入れる」
「送信待ちボックスの古いデータから順番に引き取って処理する」
「FAX出力形式のデータをFAX送信ソフトに渡す」
「FAX送信ソフトがFAXを送信し、結果を返す」
「送信が成功したら送信済みボックスに入れる」
「送信が失敗したらエラーボックスに入れる」

(3)上記の(2)で新たにデータを蓄積するための「送信待ちボックス」「送信済みボックス」「エラーボックス」が出てきたので、それぞれのデータを操作する機能が必要ないかを考えます。その機能とは「登録する機能」「参照する機能」「更新する機能」「削除する機能」で、これらをmokurenさんの記事と同じように2×2に分類するなら以下のようになるでしょうか。
・データの存在自体を変更する
 - 登録  「存在しない」を「存在する」に変更する。
 - 削除  「存在する」を「存在しない」に変更する。
・データの存在自体は変更しない
 - 参照  データの内容を変更しない。
 - 更新  データの内容を変更する。

(4)分解した結果、新たに登場して来た処理やデータについて、(1)や(2)や(3)を繰り返します。

(3)は類似しているものが並んでいるので、今までのMECEの考え方にはまりそうです。
(1)や(2)は一見すると類似しているものが並んでいるわけではありません。分解している本人が言うのも変ですが、一体どんなMECEで分解しているのでしょう?
ということで、mokurenさんアドバイスをよろしくお願いします。
posted by koppe at 22:45| Comment(0) | TrackBack(0) | 7.具体例からMECEを紐解く | このブログの読者になる | 更新情報をチェックする
×

この広告は1年以上新しい記事の投稿がないブログに表示されております。