発注側に必要なのは「技術」ではなく、「マネジメント」。
では、マネジメントとは実際に何をすれば良いのでしょうか？
その答えは、一般的な書籍には書いてありません。何故なら、皆様が手にしているその本は、ITベンダー用のプロジェクトマネジメントの本だからです。
弊社では、システム調達側に必要なマネジメントの達成・育成をサポートしています。
調達側（発注者側）に必要なマネジメントは、事業者側のそれとは全く異なります。
こちらについては、「発注者側のマネジメントとは何か？」で、弊社のコンセプトを紹介しています。
「クラウド」でもない、「SLA」でもない、
本当の最適化を実現するシステム調達手法「サービス調達」
弊社独自の情報化プロジェクトの事業スキームである「サービス調達」の適用をお勧めしています。
サービス調達に至るまでの、IT戦略・企画の策定や事業スキームの検討の流れは
「サービス調達による情報化プロジェクトを計画する」で紹介しています。
身の丈に合ったマネジメント
ITILやPMBOKなどに代表されるように、世の中には様々な情報システムプロジェクトのマネジメント方法論があります。
ですが、これらに関する知識を単に身に付けたとしても、実際の現場ではうまくマネジメントできないでしょう。これらのマネジメント手法が生まれたプロジェクトと、実際にあなたが担当しているプロジェクトでは、規模も目的も予算も違うからです。
プロジェクト全体に対して、マネジメントに割り当てることができる予算も人員も限られています。担当者のスキルも異なれば、事業者の実力もプロジェクトによってバラバラです。
そういった条件下で最大限の結果を出すためには、様々なマネジメントの手法を、実際のプロジェクトの実情に合わせ使いこなしていくだけでは不十分です。
ビジネスの設計、システムの設計、開発、運用、システムの利用終了まで、情報システムプロジェクト全てのフェーズについての経験と知識、洞察力を深め、大小さまざまな問題に対処できる具体的な”方法”を持っていなくてはなりません。
方法論ではなく、実際の方法を駆使すること、それが弊社のスタンスです。
こんな事に困っていませんか？
① プロジェクト（構築）の途中で、「実は・・・」と対象範囲を変更してくる。
② 予定通りの予算・期間で完成したが、機能は予定通りではなかった。
③ 性能が良くないので、予定外の予算を追加して機器を増設。
④ ちょっとした機能の追加・変更にもカネを取られる。
⑤ システムが停止しているのに、「申し訳ありません」の言葉だけ。
トラブルがあっても、カネは満額払う。
⑥ SEが使えない。こっちが教えているのだから授業料が欲しいくらい。
要するにこれらは、「最初と話が違う」ということですが、言い換えれば、「発注側がプロジェクト当初（契約前）に持っていた期待値」と「事業者が実際に提供した結果」が異なっていたということです。
これらの問題は、結果が提供されるまで（もしくは問題が表面化するまで）、発注者側が気付かなかったために起こった問題と捉えることもできます。発 注者には上記のような見解があるように、受託者である事業者にも別の言い分があり、そのギャップにお互いが気付かなかったために、最終的に問題として表面 化したのです。
発注者側から見れば「勝手なことを･･･」と感じるかも知れませんが、こういった問題が発生する場合には、同時に事業者側でも、「最初に『詳しいことは任 せた』と言っていたのに、後になってから言われても･･･」とか、「受注後に現場との調整もこちらで行っているのに･･･」と感じているものです。
情報システムプロジェクトにおいては、このような認識のずれが、常に発生しています。この認識のずれが次第に拡大し、最終的に問題として顕在化していくことになります。従って、この認識のずれをどのようにコントロールするかが、マネジメントのポイントとなります。
