顧客のタスクは顧客自身で対応

「顧客のタスクを含めてマネジメントする」において、コンサルタントが参画していないプロジェクトでは、
「顧客企業側の実施事項、それを支援のための実施事項について、構築ベンダー側のWBSに含め、構築ベンダー側のプロジェクトリーダーが上手くマネジメントする」ことがプロジェクトの成功要因の一つである、という考えを紹介しました。

それに関連しますが、
その顧客企業側の実施事項について、顧客自身に対応いただくこと、
これも、当然ながら必要な事項です。

顧客自身で実施いただくことの認識・理解のため、WBSをもとにして役割分担を明確化します。
その時に、いろいろと交渉事が発生する場合がありますが、いずれにしても、顧客自身で実施するタスクが明確化されます。

しかし、そこで、
構築ベンダーが「支援」という役割を担うように定義されることがあります。
その「支援」が、いつの間にか主体的な実施事項に位置づけられてしまう場合もあります。

そうしますと、
お互いの責任範囲が不明確になり、実施事項のモレ、遅延、品質悪化などを招く原因となり得ます。

構築ベンダーは、
「顧客企業側の実施事項を肩代わりしてやったのに」との感情になり、
顧客企業側は、
「頼んで了解してもらったことなのに、責任を持って対応していない」
という思いを抱くこともあります。
それが双方の信頼関係の悪化を招き、プロジェクト全体のQCDも悪化する可能性があります。

よって、構築ベンダーは、
顧客企業側で実施すべき事項について、
顧客企業側に責任があること、その実施主体は顧客企業であることを明確化し、
そして安易な肩代わりは実施せず、上手にマネジメントしてほしい、
それがプロジェクト失敗のリスクを軽減することになると、私は考えています。

顧客のタスクを含めてマネジメントする

情報システムの開発や導入のプロジェクトのおいては、
構築ベンダー側と顧客企業側の両方が、プロジェクト体制を整える必要があります。

規模によっては、プロジェクト体制と呼ぶほどの状態を作る必要がないケースもありますが、
顧客企業側においても、
定められた期限までに、非日常的な活動によって、明確な成果物を創造する必要がある旨を認識していただく必要があります。

抽象的な言い回しをしてしまいましたが、
顧客企業のプロジェクトであることを意識していただくためにも、
小さな規模・スコープであっても、プロジェクト体制を明確にすることは重要であると、私は考えます。

プロジェクト体制についてもそうですが、
顧客企業が主体となって、また独力で実施すべきタスクも発生します。
これは契約内容にもよりますが、
例えば、
必要な検討メンバーのアサイン、内部の合意形成、構築ベンダーからもとめられる情報の提供や判断、運用テストの準備と実施、データー移行の元データーの準備、社内への説明会などなど、多岐にわたります。

経験豊富な情報システム部門が存在する場合は問題ありませんが、
基幹システムの構築の他では大規模なシステム化の経験がない、人事異動が頻繁に発生する、など、経験が乏しい場合においては、
顧客企業側で実施すべきタスクに気が付かない、または内容が不十分となることが発生し易いと、私は考えています。
しかし、それでも顧客企業としてのプロジェクトの責任が免れるわけではありません。

あくまでも顧客企業側の責任範囲で実施すべきことではあるのですが、
外部コンサルタントが参画していないプロジェクトにおいては、
私は、
構築ベンダー側のプロジェクトリーダーに顧客企業側が実施すべきタスクを上手くマネジメントしていただきたい、
と考えています。

反対意見もあるかもしれませんが、
構築ベンダー側の方が経験豊富な案件は多々あり、その経験を理由にベンダー選定されている案件も多いと考えられ、
その顧客企業側の期待に応えてほしい、と私は思うのです。

具体的には、
プロジェクト体制（案）を提示する、
スケジュールには、顧客企業側にて実施すべきタスクを含めておく、
顧客企業側のタスクを含めて、進捗会議の際に確認し、課題があれば、課題管理を行う、
顧客企業側がタスクを実施するために参考となる情報を提供する、
などなど、
顧客企業側に必要な支援内容も多くあります。

繰り返しになりますが、
顧客企業側の実施事項、それを支援のための実施事項について、
構築ベンダー側のWBSに含め、構築ベンダー側のプロジェクトリーダーが上手くマネジメントすることが、
プロジェクト成功要因の一つに挙げられると、私は考えています。

定期の打ち合わせを設定する

ICT導入プロジェクトにおいては、
ある程度の規模になった場合には、プロジェクト計画と運営ルールが策定されます。
そもそも前段のプロジェクト成果物（当該プロジェクトのインプット）に、当該プロジェクトのQCDは左右されますが、
勿論、当該プロジェクトのマネジメントによって、QCDは大きく左右されます。

プロジェクトの規模によって管理コストがかかり過ぎないようにすることを、私は意識しています。
つまり、小規模プロジェクトは厳格な管理をし過ぎないようにしている、ということです。

そのような対応をしているICT企業は多く存在すると思います。
プロジェクトの成功確率を100％にするプロジェクトマネジメントを実施すべきではありますが、
それほど管理コストをかけることができない、というケースが、小規模プロジェクトに多く発生していると認識しています。

ただし、省略してはいけない事項も存在する、とも私は考えています。
その中の一つに、定例会議が挙げられると、私は最近、あらためて感じているところです。

定例会議といっても、
・開催周期（週１、月１）、
・開催目的（進捗管理、課題の対応状況の確認など）
・開催方法（集合型、ビデオ会議、電話会議）
・参加者
など、いろいろなケースが考えられます。

私は、進捗と課題に関する打ち合わせは、定例会議として設定しておくべきと思います。
当然のこと、と言われる方も多いかと思いますが、
小規模プロジェクトは、その期間の短さもあり、進捗に関する定例会は省略し、随時確認する、というケースが多いのではないでしょうか？
小規模なのに利害関係者が多いプロジェクトは、随時の日程調整の難しさもあり、
期間が短くてても敢えて、定例会議の日程をプロジェクトキックオフ時に合意しておくことをお勧めします。


＜関連記事＞
　プロジェクト計画とプロジェクト運営ルール
　成功が見通せるプロジェクト計画を策定する
　文書化の精度とコミュニケーション

プロジェクトの教訓を得る

プロジェクトの終了後、教訓を得るためのミーティング開催は有効であると、
最近、あらためて感じさせる機会がありました。

PMBOKのようなプロジェクトマネジメントのフレームワークが、
そのまま適用できるようなプロジェクトではなかった場合であっても、
終結後のミーティングからは、いろいろ今後の参考となる知見が得られるようです。


途中で発生した問題、その原因、実施された対策、その効果への評価、
そして、そこから考えられる、事前・事後で実施すべきであった事項について、
そして、あらかじめ予防措置的な観点等から対処し、効果が得られた事項について、
今後の類似プロジェクトに活かす、

そのようなサイクルが廻れば、組織のマネジメント力がアップしていくものと期待されます。


とにかく、あまり力まずに、まず、そのミーティングの機会を設けること、
そして、その場を和やかに運営することが大切であるように、私には感じられます。
あまり視点を絞り込んだり、逆に網羅性を意識し過ぎずに、
自由度を高めて多くの発言を得ることがポイントであるように、私は感じています。


概ね成功したプロジェクトにおいては、

うまく行って誇らしい事項、いろいろ苦労した事項などが、
メンバーの口からどんどん出てくると思います。
その内容を、うまくファシリテーションしていくだけで、有効な情報がたくさん得られると思います。

繰り返しになりますが、
あまり視点を絞り込んだり、逆に網羅性を意識し過ぎず、
メンバーのさまざまな意見からフレームワークを頭の中で作っていき、
その上で、少しフレームワークに沿った関連質問を投げかける、
そのような運営が良いと、私は思っています。


失敗したプロジェクトにおいては、

そのプロジェックトのメンバーは、
反省の気持ち、悔しい思い、少し被害者意識も混じった、複雑な感情である可能性があります。
先ずは冷静に、客観的な視点で意見を述べてもらうよう促していくことが大切かと思います。

しかし、感情の面は無視せず、受け止めることも重要であると、私は思っています。
理由は、問題が発生して深刻化、複雑化した場合には、
メンバーはさまざまな役割の中で、
いろいろな思いを持ちながら対応していき、結果、それらも問題解決に影響しているからです。

プロジェクトの状況が深刻化し長期化した場合、
そのプロジェクトのメンバーがどのような感情を抱くようになるのか、
その感情を認識した上で、どのような対応を実施すべきか、という事項についても、
無視できない、大切な教訓になると、私は思っています。
積極的にその感情に触れるのではなく、メンバーからそれらの感情についてコメントが出された場合には、
その意見をうまく受け流したり、抑えたりすのではなく、傾聴の姿勢で対応すべきであると、
私は考えています。


＜関連記事＞
　過去のプロジェクトから得た暗黙知を、次のプロジェクトに活かす

クラウド上でRDBMSを利用する際のライセンス上の注意点

カテゴリー名とは異なる内容になりますが、
既に多数の方がご存知のとおり、
クラウドサービス上で、DBサーバーを立てようとする際、ライセンス（使用許諾契約）上の制約に注意する必要があります。

PostgreSQL等のオープンソース系のRDBMSでは、あまり注意することは見受けられませんが、
（パフォーマンス面やサポート面で考慮すべきことは多くありますが、）

OracleやSQLServerでは、いろいろ確認しておくべき事項があります。


まず、クラウド事業者側のサービス自体が、それらを利用可能と認められているかについてです。
それらは各事業者に確認する必要がありますが、その根拠が各RDBMS提供元の情報と一致しているか等の確認が必要です。


次に、ライセンス違反とはならない利用方法・購入方法についてです。
それらは、
① クラウド事業者のサービスとして提供を受けて利用する方法
② 自社でライセンスを購入する方法
の大きく二つに分かれます。

①はクラウド事業者側に詳細を確認する必要があります。

②もクラウド事業者側に詳細を確認しつつ、その根拠が各RDBMS提供元の情報を一致しているか等の確認が必要です。
クラウド事業者自体として、それらRDBMSを実装可能なよう申請が必要な場合が多いようです。
また利用者側もRDBMS提供元への申請が必要な場合があったり、
また、当然ですがライセンス違反にならない購入方法等が必要となります。

その「ライセンス違反にならない購入方法」についてですが、
最近は以前に比べて、RDBMS提供元やクラウド事業者側から提供される情報が充実しつつあります。


例えばSQLServer2012の場合、
ソフトウェアアシュアランス（SA）によるライセンスモビリティの特典が必須となるようです。

※以下をダウンロードしてご確認下さい。
　SQL Server 2012ライセンス リファレンス ガイドVer.1.3
　マイクロソフト ボリューム ライセンス 製品使用権説明書 日本語 (Japanese) 2013年1月

SQLserver2012のSA更新は２年間であり、その更新費は購入費の50％程度のようです（１年間25％程度）。
よって、例えば5年間の利用を考える場合、SA付購入＋２回のSA更新になり、合計で通常購入費の2.5倍程度がかかります。
かなり高コストになりますが、
その費用と、サーバー管理負担の軽減メリット＋高可用性のメリット＋最新バージョン適用可能性のメリットなどとを比較検討することになります。

その他、oracleについても、以前より分かりやすい情報が出されています。
以下は、クラウド上ではなく、あくまでもサーバー化仮想に関する情報ですが参考になります。
ORACLE 仮想化環境におけるライセンスカウントについての補足資料 2013年1月16日