トップダインで概念から思考すると仕事の手戻りが少ない

ときどきいらっしゃるんですよね、MBA持っているクライアント。MBAといってもMac Book Airじゃないですよ。そんなこと言っていると寒いって言われますよ。
＃こっち向かって言わなくていいですから…

論理的思考とか交渉術とかででてくるそういった方のです。

MBAを持っている人の仕事の流れ
ワタシの知っている方は、トップダウンで物事を考えます。仕事の流れを書くとだいたいこんな感じ。

目的を設定する

boundary（範囲）を決める

（概念的な）仮説を立てる

調査（裏付け）をする

（具体的な）計画に落とす

実行する

計画を見直す

こんな流れになっている理由
目的を設定するのはやっているうちにぶれてしまわないためですね。具体論になるとシステムエンジニアは目的を見失って手段と入れ替わることがよくあります。これをしないですね。

範囲を決めるのは、仮説を立てるときの前提になります。仮説の結果が想定と違っていたら、前提の範囲が間違っていた、とわかります。システムエンジニアはこれもはっきりないままに検討を始めてしまうケースが多いです。それをやってしまうと、どこの話をしているのか議論の最中にわからなくなって空中戦にはまってしまいます。

仮説はソリューションとするアイデアなわけですが、ここでは概念レベルでしかデザインしません。これもシステムエンジニアがやると自分の関心がある分野や得意なエリアだけ詳細化してしまうんですよね。まず、概念でソリューションが成立するかを検証する方が先です。

そうした仮説も必ずその段階で取れる範囲での裏付けを取ります。制約となるもの、前提となるもの、要求されて仕様があればそれが対応できているかを確かめるのは必ずやります。そうしないとソリューションは成立しませんから。その際に、組織によっては関連する部署に相談したりしていますね。少なくとも反対されないようにでしょうが。

概念がまとめるまで詳細化はしてはいけない
やっとここまで来て初めて詳細化をします。ただ、ここまでの流れが速いです。決断しますね。パッと。でもですね、決断できるんですよ。決断できるプロセスになっているんです。

目的は狙いどおりか。
検討の範囲は（その時点で）正しいか。
仮説は実行できそうか（実行できる確信がある程度持てるかどうか判断するのが大事）。
（手戻りにならないように）事前に情報を取っているか。
実行できるプランになっているか。

決して大風呂敷を広げない
あとですね、実行プランも実現できるプランを作ります。大風呂敷を広げない。例えばシステム化の要件がある場合、リリース時期は明示しても何をリリースるするかまでは言わない。だってやってみないとわからないですから。でも何かしら手をつけて、一部だけの機能でもリリースするんですよ。そうすると経営に対しては説明できるので。

それと柔軟に計画を見直しますね。組織の中には様々なしがらみがありますが、そうしたことも裏付けとして押さえておくとここで生きるんですね。無駄に裏付けの情報を取っているんじゃないんです。

トップダウン思考は早い方向転換のピボットができるのでやり直しが少ない
こうやってアプローチしていることを理解して一緒に仕事をすると、お互いスイスイと仕事が進みます。「あのタスクだけど」「範囲を定義したのでスコープをみてもらえますか」みたいなテンポの良い会話になります。もちろん、議論する時間は短く、議論の結論んが出るのも早いです。

これをシステムエンジニアよくやるボトムアップで仔細なところから入ると、概念がわからないから仔細を見ざるを得ないんですよ。これ、お互い不幸ですから。必ずリトライですし。