最近一気に忙しくなってきた。
昨年春-秋に参画した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も描いておかないとあっという間に物事は絡まる。
精神的余裕が無いとき程、強く上記を意識しなくてはならない。
SECRET: 0
PASS:
難しすぎて、自分の経験に置き換えられませんが、よく仕事でこんがらがってくることを、上記のような意識ができれば、スムーズさをキープできるのかなと、勉強意欲がかき立てられます。
ありがとうございます。
SECRET: 0
PASS:
僕の表現がわかりづらいですよね(^^;)済みません。
文章を書くことに例えてみるとわかりよいかもしれないです(^^)例えば頭から順番に書いていって、図表の参照等も意識せずに書き進めていくと、途中で図を追加したときに、図の番号がずれて、文中から参照する番号も修正する必要が発生します。削除した場合も同様です。
また書いていてロジックの矛盾に気付いて文章を修正するときに、ソノ文章で支える主張が2つあったとして、そのうち1つだけを修正したいと考えると、面倒ですよね(^^)
なので、書き始める前に、タイトル（目的）、目次（Issue）、各Issueに応える骨組み（以上Architecture）を決めた上で内容を埋めていくといいかな、と。で、そのときに1つの文章で複数のIssueを支えないように考慮しておくとかするといいかな、なんていうことです(^^)
SECRET: 0
PASS:
すいません。sagadさんの説明、わかりやすいですよ。
難しいけど、とても大事なことだなとはわかりましたから。
自分で具体な事例が思いつかなかったもので。
でも、納得です。（まだまだ勉強不足ですが）
そういえば、仕事で文書作るとき、付箋に項目書いて、ならべなおして、う〜んとうなって書いています。でも、修正が続くと、つらくなってきますね。
また、仕事でも、はじめに、いろんなリスクを想定して、検討を始めるのですけど、だんだんことが詳細になってくると、不自然な形で存在するリスクは、忘れ去られ、あとで、あっということがあります。
そういうとき、いつも思うのが、どういうフォーマットで整理すれば、いつもわかりやすくチェックできるのか。ですが。
我流でいろいろ挑戦してみます。ありがとうございます。
SECRET: 0
PASS:
何かしら有益なことを感じていただけていると嬉しいです(^^)
文書作成時のフォーマット。クリシンにおける”フレームワーク”がそれにあたりますね。そして大切ですよね。
Projectにおいては様々なフォーマットを作成しますが、大切なのは”何のためにこの文書を書くのか？”という問いに対する答えで、その答えを満たすだけの項目はフォームとして定義しますよね。
例えば、議事録を取るときに、単にその会議の日時・場所・参加人数だけ書いてあるのと、フォームとしてToDoを埋めるよう欄を用意しておくのでは大きく違いますし、その欄に完了予定日と担当者を埋める欄を用意しておくのでまた違う、というように（勿論あくまで目的ありきですが）。
あまりやりすぎると何となく”楽しくない”感じがしてきますので（書かされている感がしてくる）、Creativeに考える/書くときは厳密にはいらないかな、と個人的に考えています(^^)
SECRET: 0
PASS:
貴重なご意見ありがとうございます。
クリシンで学んだ、トップダウン、ボトムアップの繰り返して、イシューを支えるサブを整理するということを、予め枠組みとして用意し、会議や客先との打合せの濃度を高めないと、という意識は常に持つようにしていますが、こと業務全体になると・・・。
ある病院の看護システムに、POS（problem oriented system＝問題思考システム）というものがあり、症状の観察や治療行為の内容だけでなく、患者に対して、どういう意味の言葉を話したかまで書くそうです。
そうすると、看護士が変わっても、病院としてのケアサービスの一貫性は、患者さんの心の面までケアできるようになると。
仕事でも、常に、顧客にとっての意味を、カルテでないですが、なんらかのフォームで整理することが大事なのかと思います。
クリエイティブなコミュニケーションの記述方法というものを、もう少し訓練したいと思いますが、前提としていい人間関係なんでしょうね。
ありがとうございます。