読者です 読者をやめる 読者になる 読者になる

sankakuichi's blog

働き盛り!日々感じたことを書きます♪

コンサルタントとエンジニア - トップダウンとボトムアップの考え方の違い -

最近、友人との付き合いで競馬をすることがある。

友人と私との考え方は全然合わなくて…

 

友人の考え方

いくら儲けたいから、倍率を基準に考え、勝ち馬の組み合わせを選定する。馬の人気は基本的に参考程度。

 

私の考え方

馬の人気、倍率を基準に考え、いくら儲けたいかは結果として考える。

 

みなさんはどちらの考え方をするだろうか?

競馬だからどっちでもいいと思うが、この考え方の違いはトップダウンで考えるか、ボトムアップで考えるかということだと思う。

仕事や実生活では、この考え方の違いは、行動や実施方法、結果に影響を及ぼす。

 

 

例えば会議をするにしても

①1時間しか時間を確保できない→伝えたいことは1時間でまとめよう

となるか

②伝えたいことを全部話すと1.5時間はかかるな…→1.5時間会議を設定しよう

というように考え方によって行動が変わってくる。

 

①の考え方は、一見スマートなように見えるが、伝えたいことをすべて会議中で伝えきれず会議後に資料を使ってフォローをするなどの対応が必要になる。②は伝えたいことはすべて会議中で話すことができるが、会議に時間がかかり関係者の時間を多く割いてしまう。

 

会議なら大した問題ではないが、大規模なプロジェクトの場合はどうだろうか?

予算も時間も会議なんかとは比較にならず数億円、数年間規模になる。

 

大規模プロジェクトの場合、役員会などで予算や期間の承認が下りてからスタートすることになると思うが、その際の見積もりはどうやって実施しているのか。

トップダウン型の考え方か?ボトムアップ型の考え方か?

トップダウン型ならば、社会情勢やライバル会社の動向を考えながら、戦略を練り、予算や期間を考えていくことになり、

ボトムアップ型ならば必要な組織・人員・システムなど必要なリソースの概算見積もりを実施し、プロジェクトの予算・期間を考えていくことになる。

 

私の経験上、トップダウン型、ボトムアップ型の考え方は多くの場合、不整合を起こしているように思う。

私が経験してきたのは、多くがシステム開発プロジェクトであったが、多くの場合、計画した納期に対して遅延が発生していた。

システム開発プロジェクトはコンサルタント(という名のSE?)とシステムエンジニアが参画し、推進していくことになりますが、コンサルタントトップダウンの考え方、システムエンジニアは、ボトムアップの考え方で動いているように思う。

※優秀な人は両方ともできるが…。

 

コンサルタントは、システム知識は基本的にないためシステム開発にどのくらい時間がかかるのか、何が必要なのか分からない。基本的に計画上いつまでに必要だから「作れ」という人だ。

(本来はこうあってはならないが、私が見てきたコンサルタントは雇い主同様、システムに関しては当たり前のことしか言わない素人同然の人が多かった。)

 

対して、エンジニアは、要求に対して、作るのに何が必要でどのくらい時間がかかるのか積み上げて納期を考える。

 

この場合、信憑性があるのはどちらだろうか?

顧客が欲しい情報を提供できるのはどちらだろうか?

 

 

長くなりそうなので、一旦ここで終わります。

 

<スポンサーリンク>

なぜ、システム開発は必ずモメるのか?  49のトラブルから学ぶプロジェクト管理術

なぜ、システム開発は必ずモメるのか? 49のトラブルから学ぶプロジェクト管理術