コンセプチュアル・マネジメント

◆目的はプロジェクトのアンカーであり、灯台であるべき

前回は部門としての目的のバランスについて議論したが、個々のプロジェクトにおいてはその目的をどのように考えて設定すればよいのだろうか？よく目的を明確にしようと言われるので、非常に具体的な目的の設定をするケースが多い。たとえば成果物を作ったり、財務指標の達成を目的にする。本当にそれでよいのだろうか？

目的設定は何のためにするのですかと聞くと、チームの向かうところを明確にするという答えが返ってくることが多い。確かにそうなのだが、プロジェクトはうまくいっている時期もあれば、うまく行かない時期もある。具体的な目的は順調な時にはよいが、トラブルが起こると役に立たなくなる可能性がある。トラブルが起こったら、財務指標や、成果物は変わってしまう。その瞬間にプロジェクトは目的を失い、漂流を始める。

この議論はマネジメントの本質に関わる議論である。ゴールの耐久性、ロバストさを実現するためにもっとも簡単な方法は、ゴールを曖昧にすることである。逆にゴールを明確にすればするほど、耐久性がなくなる。要はこの議論もバランスの議論である。

目的は、灯台としてチームの一体感を生み出し、嵐のときにも、アンカー（錨）にならなくてはならない。どのように考えて設定すればそのような目的になるのだろうか？


◆成果物を目的にするとデスマーチが起こる

もっとも明確なゴールは成果物、あるいは計画ゴールである。しかし、成果物をゴールにしてしまうと、マネジメントが機能しなくなる。Ａの機能を持つシステムを作ることをゴールにすると、それが達成できないときには、デスマーチになる。デスマーチは向かうところが明確であるにも関わらず、ゴール達成のための手段が不十分なために起こる現象である。

ゴールに曖昧さがあれば、多くのデスマーチはなくなる。しかし、ゴールの曖昧さはプロジェクト品質の悪化を引き起こす。この二つの視点を持ちながら、バランスのよいところにゴールを決めるのがマネジメントの課題である。

一般的にいえば、ゴールを明確にしすぎる傾向がある。成果物をゴールにしてしまうからだ。その原因は、目的の設定の仕方にあるように思える。

プロジェクトの実行の中で、つまり成果物が決った状況で目的を考える場合が多い。と多くの人が思っている。そこで、たとえば、Ａというシステムを作るのだから、その中で使うＸという技術を保有する人材を育成しようという風な発想になる。このようには発想する背景に、経験偏重にあるように思う。Ａというシステムを作るといった瞬間に、過去の経験に基づき、Ｘという技術を中心にした開発プロセスが頭に浮かび、そこで絵ができてしまう。これがよいことだと考える人が多い。

このことは、功罪両面がある。功としては、多くの人が考えるように収益率が高まること。技術の展開が進めば進むほど、収益が大きくなってくる。罪はある種の思考停止に陥ること。仕事は独占していない限り、競争が出てきて徐々に条件が厳しくなる。あるいは、景気変動などの理由で突然条件が厳しくなることもある。その中で、「茹でガエル」になってしまい、気がついたときには遅い。


◆目的はプロジェクトにイノベーションを引き起こすことが必要

そのように考えると、ケースバイケースとはいえ、やはり、上のような発想の仕方は好ましくない。経験的に解決できそうな問題であっても、改めてどのように解決するかを考え、イノベーションを試みる必要がある。

その際に重要なことは耐久性のあるプロジェクトの目的を設定することである。つまり、そのプロジェクトをどのような目的で行うを決めることによって、そのプロジェクトで取り組むべきイノベーションの方向性が変わる。たとえば、顧客へのコミットメントを高めることがもっとも重要な目的であれば、納期を前倒しを実現する生産性向上をイノベーションの目標にするといった意志決定が可能になる。

大切なことは、成果物に依存せず、戦略や組織に貢献を引き出す目的を考え、まず、プロジェクトの目的の柱とすることだ。そして、成果物については抽象度を上げてみることも重要である。抽象度を上げることで、ベストプラクティスやナレッジの有効性が増し、移転が促進されることも少なくない。