前回からの続き。
森を選んだその後、一番最初にやる事。「前提条件を知る」事。
前提条件の意味を辞書で引くと。。。
「物事を進める為の予めの決め事」「ものごとを推進するときの実施上のタイミングや満足させなければならない事」
(引用:大辞林)となっている。
要は、何の為にその物事に携わっているのか?いくのか?を早々に決めて、プロジェクトの最後まで決してそれを忘れてはならない事である。その携わり方を決めるの為の条件をここでは「前提条件」と定める。
森の話を例に上げると、そもそもその森はホントに森なのか?という所から確認する。そっからかい!と突っ込みが来そうではあるが、過去にもネタで書いたが、そもそも顧客がニーズ&要求(森)を把握している事は、ある条件化以外ではあまりない。ある条件というのは非常に低い予算か、すんごい高い予算の場合。要は先方の担当者が、自分の手におえる範囲の時は、大概の場合ニーズをキャッチできていない事が多い。ここでいう低予算は、失敗しても大した事ない位の金額もしくはニーズを解読するレベルにない予算。高予算は社運をかける程の金額、もしくは失敗すると自分の首が危ない金額を指す。(まあニーズをキャッチ出来ていれば、レイヤー高めのコンサルティングがそもそも入らないんですけどね。)
そもそも、森なのか林なのか区別がついていないパターンの場合は、まず森なのか林を見極める。続いて、その森がどの地域のものなのか?を調べる。極寒地域の森なのか?亜熱帯地域のものなのか?(ここでは業界的カテゴリーを指す)続いて、森を拡大したいのか?縮小したいのか?新たに作りたいのか?蘇生したいのか?(新規作成?追加?リストラチャー?バージョンアップ?)を確認したい。
要は顧客が求めている事を、全く違う事柄に置き換えてみて、矛盾が起きず、かつ顧客からその通り!と言わせて初めて「前提条件」がクリアになる。新しいシステム(WEB)を作りたい!というオーダーがあった場合、そもそもそのシステムは何の為につくるのか?目的は?コストは?リリース時期は?効果は?コストは?という内容を多次元的に分解してみる作業=「前提条件」作りになる。
逆から俯瞰してみると、具体的な作業に入った時に、判断がつかない、もしくはつきづらい時、この前提条件に戻る事によって大概の事は解決できる。出来ない場合は「前提条件」作りが甘いという事になる。
次回は、もうちょっと「前提条件」のお話と、存在意義のお話。




