人気ブログランキング | 話題のタグを見る

a IESE class of 2014, strategy consultant has focused on emerging economy and innovation management writes about learning from MBA, feeling from daily life, with photography. Twitter : @dsaga


by dsaga
カレンダー
S M T W T F S
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31

Architecture

最近一気に忙しくなってきた。
昨年春-秋に参画したProjectに関するTask、提案活動、新規参画Project準備、社内勉強会準備、面白いように時間が埋まっていく。
何度と無く感じるが誰にでも当てはまることだろうか。時間の使い方について2つのことを感じる。

1. 暇なときより忙しいときのほうが勉強に集中できる
2. 忙しさが増してくると、その忙しい対象とは違った分野の勉強をしたくなる


幸いにも自分は忙しい対象以外にも手を伸ばしたい分野が幾つかあるので、勉強するべきことには事欠かない。

そんな中で、先日Blogに少し書いた調査設計について少しまとめておきたいと思ったので以下に書いてみる。

そもそも調査の目的って何?その目的達成するために調査するべき要素って何?というのを明確にするというのは当然のことでこれは調査に関わらずProject work然りその他然り、おおかたの事に関して当てはまる原則だ。
ただ、実際にProjectを進めながら調査をしていると、往々にして変更が発生する。目的が変わることもあれば、それに応じて調査すべき要素が変わる、新たな解釈を検証するために要素の追加/削除が起こることもいくらでもある。(勿論最初にどれだけ筋の良い仮説を立てられるかでこのInpactの大小は変わるのだが。)

こんなことを考えたときに大切になってくるのが調査設計。調査の構造。

Architectureだ。

システムの設計思想と同じ。コーディングの思想と同じ。目的の変化、要素の追加/削除に柔軟に対応できるような構造を持たせた上で調査を実施し、Factを埋めていく必要がある。
ここでPointとなるのは以下の3つではないかと考えている。(まだ実践はしていないが次Projectにて必要があれば実践したい。)

1. 調査のComponentの定義
2. Component内の密結合、Component間の疎結合
3. Data Sourceの明確化


この手の話をすると、”Componentの単位って何だ?”という議論になるが、それは置いといて(^^;)目的にぶら下がる複数のIssueの1つに応える調査が1Component、といった感じだ。(じゃあそのIssueの大きさって…?は置いといて(^^;))
まあPoint 1については、調査の目的を明確にして、その目的を達成するにはどんなIssueに応える必要があるのかを考えると自然と定義できるだろう(ざっくり)。
次に大切になるのはPoint 2。同じIssueを支える調査Dataは密結合に、複数のIssueをまたぐ調査Dataはできるだけ疎結合にしよう、要するに調査結果のDataの1箇所をいじったら、1つのIssueを支える一部分にはそれが反映されたけど、同じDataを使って組み立てているLogicの他の部分には変更が反映されない、ということや、逆にIssueを2つも3つも…もまたいで要素がころころと変わってしまう、というような設計は避けよう、ということ。
それをやりやすくするためには、Data Sourceは明確に、そして一箇所に持っておいたほうがいい。各Issueに対して、そして勿論複数のIssueをまたいでもその必要があるものについては、まとめておいたほうがいい。で、さらに言うとそれはどういった調査で獲得したDataなのか、生のまま、Evidenceとして残しておいたほうがいい(おくべきだ)。その上で、目的、Issueに応じてData Sourceを加工するLogicに組みあわせて解釈していくのが良いと考える。

Architectureというものを常に意識しながら調査を設計し、実施していかないと、その場その場の対応でAdjustしながら分析を進めていくと、後々変更があったときにどこをどういじっていいのか分からない、その結論ってそもそもどの調査・どのDataから抽出したんだっけ?と問われても明確に答えられない等のTroubleに繋がる。

そして、そうなってから調査の設計を見直しても、それ自体容易ではないし、その上で調査をやり直すこともまた容易ではない。

システム構築のProjectも同じである。
”とりあえず”でも目の前にある選択が容易な手段から順にとっていくことが必要な場合は多々あるが、目的と応えるべきIssueを明確に頭の中に描いた上で、それらを今選択した手段のOutputがどう支えるのか、そのArchitectureも描いておかないとあっという間に物事は絡まる。

精神的余裕が無いとき程、強く上記を意識しなくてはならない。
by sagad | 2006-01-18 03:59 | Business