プロジェクトマネージメントってなんだろうねという会話。まだまだラフですが。
本質的にマネージメントしなきゃいけないのは、1.ビジョンの実現品質、2.スループット（個々人のモチベーション）、3.リスクだと定義しました。
「ビジョン」とは望ましい将来の姿のことで、「なぜプロジェクトをやるべきか」というWHYの定義にあたります。（TODOミッションは入るのか？）。そこからシステムの仕様が段階的に導かれてきます。ビジョンの実現品質とは、きちんと段階的に導かれた仕様に従っているか、ということになります。
スループットとはプロジェクトの生産力になります。人をアサインしたからといって生産性が高いとは限りません。そのメンバーがやる気になって、十分な生産性を達成しているかが重要です。
リスクは言うまでもありませんね。変化が大きく、複雑なプロジェクトではリスクマネージメント、つまり不確定要素の管理が非常に重要です。
一方でスケジュール、コスト、アサイン（要員割り当て）、ファシリティ（設備）といったものはマネージメント対象とは考えません。これらは上記のマネージメントを実現するために利用するパラメタに過ぎません。つまり、マネージャーがコントロールすることができるものと考えます。
従来のマネージメントの基本は誤差の吸収と調整でした。決められたスケジュール、コスト、アサイン、ファシリティの中で目標を達成することが求められたため、これらのズレを管理することがマネージメントだと考えられたのです。ですが、より複雑なビジネス環境においてはスケジュール、コスト、アサイン、ファシリティは積極的に変化されるパラメタであり、ツールのようなものです。
むしろ1.ビジョンの実現品質、2.スループット（個々人のモチベーション）、3.リスクをマネージメントし、これらで発生した問題を解決するためにスケジュール、コスト、アサイン、ファシリティをコントロールするのです。
ただし、マネージメントで重要なことが「問題の把握と調整」であることに変わりはありません。ですから、なるべく客観性がある監査の仕組みを通じて1.ビジョンの実現品質、2.スループット（個々人のモチベーション）、3.リスクを見ていく必要があります。
そのためには予定と実績のズレを客観的な方法で計測する仕組みが必要になります。もちろん、こうした曖昧なマネージメント対象においてズレの認識は主観的にならざるを得ません。だからこそ、主観的に判断すべきポイントとスコープの定義は客観的で形式的な仕掛けになる必要があります。例えばフローなり、プロセスなりというのは、そのために使える見える化ツールなのです。
こうした監査においてズレや問題は悪ではありません。問題が発生することも、当初の予定からずれることも当然なのです。大事なことは問題を早期に把握し対応することです。
ただし、主観的でしかない、という言い方も語弊を招きます。どれを、どう管理するのかは考えていく必要があるでしょう。
こうした視点に立つと、従来のマネージメント手法が大きく変化してしまいます。スケジュール管理がガントチャートだろうと、タイムボックス＋チケットだろうと関係ない。プロジェクトのタイプに応じて選べばいいだけです。これはフローやプロセスといっているところと同じです。
もう1つマネージメントに影響を与えているのがアーキテクチャの成熟です。もちろん、いまだにシステム開発は原始的な産業です。ですが、少し前よりは安定的なアーキテクチャが存在し、マネージメントが容易になったと感じています。正確に言えば、ビジネスの可変性に対応するようにアーキテクチャの可変性を管理することが容易になり、やばい部分とやばくない部分が分離できるようになってきたと言うことです。
これからのSI企業は内部統制や工事進行基準の採用など、マネージメントに影響を与えるトピックスは出てきます。ですが、一方ではビジネス環境を考えると昔ながらの方法だけでは対応できない。「法律がそうだから」というくだらない言い訳をせずに、本質をきちんとつかんだマネージメントを定義できるかがポイントになります。
