最近、参画しているプロジェクトが忙しくなってきてます。
今、大変な状況に置かれている金融業界の中の某社のプロジェクトにて、
プロジェクトが開始した後、このままでは頓挫しかねないという状況のなか、
助っ人としてプロマネで入らせてもらいました。
キックオフ後に参画したので、予算や人的リソースも自分で見積もり、
アサインをかけたわけではなく、リソースは既に決まっていて、
動いている中にマネージャーとして入ったわけで、まぁ、
キャッチアップに時間がかかるだろうなぁと覚悟はしていました。
初日からスケジュール・タスク・工数を既にあるものから書き換えて
作りあげ、メンバー一人一人の名前・年齢・特性・バックボーンなどを
さりげなくヒアリングしたりなどして、もうかれこれ１ヶ月以上が経過しました。
顧客のカウンターパートと進捗、メンバーとの調整などをこなしていきながら、
帰属する組織のラインマネジメントとプロジェクトとしてその目的を切り出した形で
運営する組織体のマネジメントにおいて、共通する部分と固有の部分が、
自分のなかで改めて明確化できたのは、大きな収穫になりました。
そして、共通する部分というのが、マネジメントの根本であり、
それらはどの組織に行ってもやはり共通します。
カウンターパートもメンバーも自分より年上で、なお且つプロジェクトについて
一番よく理解していない状況でマネジメントをはじめても、メンバーを馴らし、
顧客のカウンターパートから高い評価をえて、信頼関係を築いていくプロセスは、
シチュエーションによって変化はあるにせよ、おさえるポイントは同じです。
どっかで聞いた言葉だけど、自信が確信に変わりました。
一番大きいポイントは、顧客にしてもメンバーにしても、
細かく言えば交渉力だとか判断力だとか実行力だとか、そういう表現で表せる
能力もかなり必要だけど、それらを持った上でのコミュニケーション力が大事です。
管理能力を持っているが、それらを表に出す表現力も必要で、自分がマネージャーとして
目的を果たすのに、何を管理してどう推進しているのか、今現在どこまで進んでいて、
それは予定通り進んでいるのか、遅れているのか、遅れている場合どれくらい遅れているのか、
それらをリカバリするのにどれくらいの期間とコストを要するものなのか、
わかりやすく表現するのに、数値化は必須ですね。
そして、それらを報告資料としてコミュニケーションをとることも重要で、
報告資料は一つのコミュニケーションツールであるという認識ができていない
マネージャーは、けっこう多いのではないでしょうか。
それらもふまえてコミュニケーションであるという認識があるかないかで、
マネジメント力という総合的なものに大きな差が出てくるものです。
もちろん、報告資料だけではなく、提案資料や計画書・企画書などもそうです。
なので、これら計画書や報告資料などは、一目見れば作成者のマネジメント力がある程度
はかれると言っても過言ではとないと思います。

プロジェクトマネージャー用の参考資料や、色々な概念のもとに作成された手法などは
一長一短であり、必ずどこかに落とし穴があります。
落とし穴があることをわかっていてその手法をとり、補っていくものが明確になっていれば
問題はないけど、手法にこだわりすぎて、策に溺れるパターンが多いようですね。
今のプロジェクトで、私が採用した進捗管理の手法は、スケジュールとコストの予算実績を
マトリックス的にいくつかの指標にて分析する手法をとっています。
よくあるのは、一つのタスクに対して、その進捗率は５０％です。
という報告に対して、その５０％の分母は一体何？？　という議論。
ＩＴに限らず、色々なプロジェクトで物議をかもし出す"進捗率"、
プロジェクトにおいては、たいがいは、プロジェクト計画書にて％の定義をし、
それらで運営しています。
あるドキュメントを作成するというタスクにて、目次作成完了で２０％・本文作成完了で５０％・
内部レビュー完了で７０％・顧客レビュー完了で９０％・清書完了で１００％　というように。
これって、どうも違和感あるんですよね。その定義であれば、％で表現しなくても良くて、
厳密ではないんですよね。　他では、ドキュメントの予定総ページが１００枚で、１００枚を分母として
何枚書いたかで進捗率を出したりっていうのもあるけど、枚数なんかいくらでも水増しできるし、
枚数が完了したからそのタスクが完了するのかというと全然違う。
それらの管理手法で実際に管理をすると、８０％という報告があってから、
１ヶ月過ぎても８０％のまま、でも実際はタスク担当はその作業をしていないわけではなく、
夜遅くまで行っていたりし、実態を管理しているとはとても言えるようなものではないですよね。
システム案件のテストのフェーズにおいて、テスト項目が洗い出され、一つ一つの項目にかかる工数が
わかっているような簡単なものであれば良いけど、ソリューションを模索しながらドキュメントを
したためていくようなタスクには意味がない。　今回はそのようなケースなので、
アンドバリュー分析と改善目標指標というのをスケジュールとコストの観点から使い分けて、
進捗を管理する手法で取り組んでいます。

[ＢＡＣ](Budgeted At Completion：完了時総予算)
　　<　概要　>計画したプロジェクト完了時の総コストを示す。単位は工数(H)。

[ＣＶ](Cost Variance：コスト差異)
　　<　概要　>計画したコストと実際に要したコストの差分を示す。単位は工数(H)。
　　<値の意味>CV = 0：計画通り　CV > 0：計画内　CV < 0：計画超過
    < 計算式 >CV = EV - AC

[ＣＰＩ](Cost Performance Index：コスト効率指標)
　　<　概要　>コスト消化の効率性を評価する指標。
　　<値の意味>CPI = 1：計画通り　CPI > 1：計画内　CPI < 1：計画超過
    < 計算式 >CPI = EV / AC

[ＳＶ](Schedule Variance：スケジュール差異)
　　<　概要　>計画したスケジュールと実際にのスケジュールの差分を示す。単位は工数(H)。
　　<値の意味>SV = 0：計画通り　SV > 0：計画内　SV < 0：計画超過
    < 計算式 >SV = EV - PV

[ＳＰＩ](Schedule Performance Index：スケジュール効率指標)
　　<　概要　>スケジュール消化の効率性を評価する指標。
　　<値の意味>SPI = 1：計画通り　SPI > 1：計画内　SPI < 1：計画超過
    < 計算式 >SPI = EV / PV

[ＥＴＣ](Estimate To Completion：現時点から完了までのコスト予測)
　　<　概要　>現時点からプロジェクト完了までに要するコストの予測値。単位は工数(H)。
    < 計算式 >ETC = (BAC - EV) / CPI　ETC(最大) = (BAC - EV) / (CPI * SPI)

[ＥＡＣ](Estimate At Completion：完了時コスト予測)
　　<　概要　>プロジェクト完了時点で要するコストの予測値。単位は工数(H)。
    < 計算式 >EAC = AC + ETC　EAC(最大) = AC + ETC(最大)

[ＶＡＣ](Variance At Completion：完了時コスト差異)
　　<　概要　>予算とプロジェクト完了時点で要するコストの差分。単位は工数(H)。
　　<値の意味>VAC = 0：計画通り　VAC > 0：計画内　VAC < 0：計画超過
    < 計算式 >VAC = BAC - EAC　VAC(最大) = BAC - EAC(最大)

[ＥＡＣスケジュール](Estimate At Completion：完了時スケジュール予測(期間表示))
　　<　概要　>プロジェクト完了時点で要する日数の予測値。単位は日。
    < 計算式 >EACスケジュール = タスク予定日数 / SPI

[ＶＡＣスケジュール](Variance At Completion：完了時スケジュール差異(期間表示))
　　<　概要　>計画期間とプロジェクト完了時点で要する日数の差分。単位は日。
　　<値の意味>VACスケジュール = 0：計画通り　VACスケジュール > 0：計画内　VACスケジュール < 0：計画超過
    < 計算式 >VACスケジュール = タスク予定日数 - EACスケジュール

[ＴＣ＿ＣＰＩ](To Complete Cost Performance Index：計画通り完了するために必要なコスト効率指標)
　　<　概要　>計画したコスト以内に完了するために必要なコスト効率指標。
　　<値の意味>TC_CPI = 1：現行のままの生産性で計画通りのコストで終了予定
　　          TC_CPI > 1：計画通りのコストで終了させるためには、生産性の向上が必要
　　          TC_CPI < 1：生産性は高くコストに余裕がある
    < 計算式 >TC_CPI = (BAC - EV) / (BAC - AC)

[ＴＣ＿ＳＰＩ](To Complete Schedule Performance Index：計画通り完了するために必要なスケジュール効率指標)
　　<　概要　>計画したスケジュール以内に完了するために必要なスケジュール効率指標。
　　<値の意味>TC_CPI = 1：現行のままの生産性で計画通りのスケジュールで終了予定
　　          TC_CPI > 1：計画通りのスケジュールで終了させるためには、生産性の向上が必要
　　          TC_CPI < 1：生産性は高くスケジュールに余裕がある
    < 計算式 >TC_SPI = (BAC - EV) / (BAC - PV)

[ＣＰＩ要改善倍率]
　　<　概要　>計画したコスト以内に完了するために必要なコスト効率指標の向上倍率を示す。単位は倍。
　　<値の意味>CPI要改善倍率 = 1：現行のままの生産性で計画通りのコストで終了予定
　　          CPI要改善倍率 > 1：計画通りのコストで終了させるためには、生産性の向上が必要
　　          CPI要改善倍率 < 1：生産性は高くコストに余裕がある
    < 計算式 >CPI要改善倍率 = TC_CPI / CPI

[ＳＰＩ要改善倍率]
　　<　概要　>計画したスケジュール以内に完了するために必要なスケジュール効率指標の向上倍率を示す。単位は倍。
　　<値の意味>SPI要改善倍率 = 1：現行のままの生産性で計画通りのスケジュールで終了予定
　　          SPI要改善倍率 > 1：計画通りのスケジュールで終了させるためには、生産性の向上が必要
　　          SPI要改善倍率 < 1：生産性は高くスケジュールに余裕がある
    < 計算式 >SPI要改善倍率 = TC_SPI / SPI

元ネタ(進捗のインプット)は、ガントチャートやＷＢＳに用意し、スタッフから密な報告を受け、
上記を計算し、プロジェクトの進捗を分析・管理しています。
顧客もメンバーも、こんな細かい管理手法は今まで見たこともないと口ぐちに言っており、
理解するのに少々時間がかかったけど、逆に顧客からはここまで高度な管理を行ってもらえて
嬉しいと、満足度があがり、自身の管理も楽になったので良かったです。
やはり、こうやって、一般的にどこにでもあるようなサービスを提供するのではなく、
独自性や特異性を持ち、且つ品質の高いサービスを提供することで、
顧客の満足度をえていくものだと、改めて感じます。
そしてその顧客の目が肥えていて、レベルが高くしきいの高い顧客であればあるほど、
自分の市場価値もあがるということで、お互いにWinWinな関係という事が、ビジネスの根本で
あり、これらが小さいところでも行われることで、微力ながら社会に貢献できていると実感します。

今後の個人的な話としては、しゅくしゅくとプロジェクトを進めながら、更新時の単金交渉にのぞもうかと、
そういった流れと、このプロジェクト以外に話がある、某ソフトウェア会社との怪しい動きや、
とある企業の新規事業立ち上げなどで、また違う領域での仕事があり、正式に受託できるよう、
中身のつまった提案資料を作成し、営業活動の時間を作っていくという、
時間的にも中身的にも、比較的ドＭな感じの今日この頃です。　

さて、Googleが一から開発をしたという、Webブラウザ「Google Chrome」が
正式リリースされました。
Googleの発表内容としては、まず性能面について、Googleの検索機能と同様で、クリアで超高速だそうです。
高速パフォーマンスを発揮するため、JavaScriptをＣＰＵダイレクトに実行する仕様になっているそうです。

安定性については、ＩＥと比較してだと思いますが、１ウィンドウに複数タブが開かれ、
そのタブ毎にプロセスを割り当てるため、どれか１つのタブの障害で、
他のタブまで巻き添えになって、ウィンドウが閉じられることがないという仕様が特徴のようです。

ユーザーインターフェースは、ＩＥなどではタブがウィンドウの中にありますが、
Google Chromeでは、外側に配置されており、アドレスバーには、ＵＲＬだけじゃなく、
キーワードを入力してそのまま検索できる機能も装備され、ユーザビリティの高い仕上がりとなっています。と。

実際にインストールして、使ってみました。
インストール時に、ＩＥのお気に入りから自動的にエクスポート/インポートしてくれたので、
お気に入りのデータ移行作業はないです。
また、他のブラウザと違うのは、Googleらしく非常にシンプルな画面になっており、
画面のそこらじゅうに色々な機能のボタンなどが表示されておらず、使い慣れるまでに
時間がかからない印象を受けました。
機能面では、多機能ワンボックスというワークボックスが設置されており、そこから自分が使いやすい
ようにカスタマイズできるようになっています。

一般向けという観点からは、非常に良いブラウザなのではないでしょうか。
企業向けとしては、アプリケーションとの相性という問題が焦点になりますが、
Webブラウザ経由の社内システムも増えていることから、パフォーマンスを考えると、
ＩＥにはかなり向かい風な状況になってきてますね。
LunascapeやOperaなどのシェアも伸びてきているらしいですし。

今後はしばらく、Google Chromeを使ってみることにしてみます。

Googleブログでの発表はこちら
http://googlejapan.blogspot.com/2008/09/google-chrome.html

いきなりダウンロードする人はこちら
http://www.google.com/chrome/index.html?hl=ja

世間をお騒がせしながら、今日の情報社会の大いなる立役者であるMicrosoft、
企業にとっても一般消費者にとっても、Microsoftの動向は非常に気になるところです。

WindowsVistaの後継バージョン、Windows7が３年後にリリースされる事により、
現在WindowsXPのユーザーは、ある種、ギャンブル的な決断をしないといけないですね。
一般消費者はまだしも、企業のＩＴ管理者は、頭を悩ませているものと思います。
実際、リリースされてすぐに導入する企業はなく、機能やセキュリティ、
現行の自社のシステム環境、ネットワーク環境などとの適合性を見極めるための
検証を行い、ＯＫであればＧｏ！！というステップを取るため、
１年或いは２年くらいをかけて導入することになるでしょう。
そう考えると、スケジュールどおりに開発が進み、２００９年に発売されたとしても、
実際の導入は２０１１年が妥当であり、その間、XPを使い続けるか、Vistaに切り替えるかの
判断をしないといけません。
XPの場合、サポート期限を過ぎるため、パッチの提供などがなくなり、
すぐさま新しいウィルスなどの餌食になることは明白で、大きなリスクを
抱える事になるし、Vistaを導入するにも、まだ検証が終わっておらず、その状況で
３年後にはニューバージョンがリリースされるということで、適合性がないというリスクと、
検証作業も含めたコストが大きく膨らむという考えたくない事が容易に想定できます。
いっそのこと、クライアントＰＣをWindowsではなく、Linuxにするなんてのも、
アリといえばアリなのかもしれないですね。
ＳＩ企業などでは、社員のリテラシーが高いので、Linuxでも十分なユーザビリティを
発揮できそうだし、社内システムは企業ポータルの上で全てブラウザベースになっていれば良いわけで。
Officeにしては、Microsoftの製品を使わず、無償のOpenOfficeを利用し、Officeのライセンス費用
までをうかせてしまえば、中長期でのスパンで考えた場合、メリットが大きいように思えます。
Windows7の後継も出るでしょうから、依存してしまうと、向こう十年はこのイタチごっこを
繰り返し、Microsoftに振り回されることになってしまいます。
Microsoftとしては、もちろんビジネスなので、そういった完全なる囲い込みが狙いであることは
言うまでもないですが。

結局、企業のＩＴ管理者としては、ＩＴ部門単体だけで考えるのではなく、全社レベルでコストメリット、
ユーザビリティ、セキュリティなどを勘案し、どれくらいのスパンでのＴＣＯとして捉えて
他の戦略と合わせてプランニングをするか、ＩＴ管理者ではなく、ＣＩＯなどその企業の
管掌者の力量に全てがかかってくる事になり、どれだけ優秀な人材をそのポジションに
設置しているかどうかが、こういった動きによる余計なコストを省いて、本業に力を
入れることができるかがポイントになります。
現在、SIerからの提案を中心に動いている企業は、ますますＩＴコストが膨らんでいくことに
なり、その分売上も伸ばさないといけない状況が厳しくなり、戦略と計画が重んじられる事に
なっていくものと思います。