2005年12月アーカイブ

この1年は、どちらかと言うとプロセスに重点をあてた問題点を取り上げてきました。

そして、来年は、アプリケーションを中心に展開したいと考えています。いろいろなアプリケーションを導入する際に、どのような考え方で導入すれば良いのかというようなこと、また、その時に話題となっているようなことを取り上げたいと考えています。

今年のIT関係で、大きな話題になったものに、日証のシステムの問題があります。これについて、以前メルマガでほんの少し、私の考えを披露しましたが、今回、1年の締めくくりとして、考えてみたいと思います。

この問題には、2つの事象が絡み合っています。

1つは、システム自体がダウンして、ビジネス上に大きな損害をもたらしたこと。もう1つは、みずほ証券の間違った売り注文をそのまま通し、後でキャンセルできなかったことです。こちらもビジネス上大きな損害を与えています。

昨年の11月にメルマガを発行し始めた、そしてこのブログも立ち上げました。この1年は、私の経験を元に、日ごろから考えていたことを皆さんに伝えてきました。

まず、ITの目的と経営の方向が合致していないと言う事実があり、プロジェクトの企画フェーズとして、経営戦略とどのように整合性を取るかということから書き始めました。最初の頃は、まったくITとは関係ない話ばかりで、むしろ、読者の皆さんは、とっつきにくかったのではと反省しています。

次いで、情報企画化の課題として、業務のあり方、将来のシステム像、業務分析の仕方などを取り上げました。

3番目に、導入ITシステムの調達について、お話しました。日本の調達は、非常に曖昧で、契約書も曖昧なままになされていることに疑問を感じ、調達プロセスがどのようにあるべきかを伝えてきました。

そして、開発フェーズに入り、プロジェクトマネジメントの問題点を取り上げてきました。

この1年は、どちらかと言うとプロセスに重点をあてた問題点を取り上げてきました。プロジェクトマネジメントについては、もう少し、伝えたいことがありますので、もう少し継続したいと思います。

キックオフも終わり、プロジェクトが軌道を進み始めました。プロジェクトが計画通りに進むかどうかは、プロジェクトチームにかかっています。

プロジェクトマネジメントの技法だけを活用してもプロジェクトは成功しないことは、皆さんもご存知の通りです。リーダーシップ不在では、プロジェクトはうまく行きません。

プロジェクトマネジャーの仕事の大半が、コミュニケーションだといわれています。仕事の60%～90%程度までがコミュニケーションだといわれています。

まだ発表できる段階ではないのですが、現在、海外のソフトハウス2社と提携の話が進行中です。日本にないようなソフトを持ってくることを目的としています。

海外のソフトハウスを調べていると、多言語化に熱心な所とそうでない所があります。海外製のソフトで、現在、インフォカートなどで登録されているものの中には、日本語が扱えないソフトが存在しています。金儲けのために、ユーザのことを考えず、販売して、何の徳があるのでしょうか。疑問です。

これから展開しようとしているソフトの販売は、基本的に、日本語が扱えないとダメ。できなければ、できるように修正をしてもらうことが前提です。メニューなども翻訳できれば尚良しと考えています。

こんな考えで、ソフト販売事業を展開したいと考えています。昨日も、海外とメッセンジャーを使って、チャットをしていました。

計画フェーズについて私の考えを書いてきましたが、ここらで、計画フェーズは終了し、これから実行フェーズに入って行きたいと思います。

実行フェーズに入ると計画したことを実行に移すわけですが、ここからが、プロジェクトマネジメントの本番です。

最初は、キックオフを行なわなければならないのですが、キックオフで明確にしなければならないことは、何でしょうか。

プロジェクトマネジメントテンプレートを改定中です。もともとPMBOKに準拠しているのですが、第3版に対応させてバージョンアップします。

しかし、すべて第3版に対応するわけではありません。ほとんどの計画書がマネジメント計画書に統一されていますが、計画書とマネジメント計画書を分けてテンプレート化しておいたほうが分かり易いと思い、そのままにしています。

今回、スコープ記述書とWBS辞書を追加する予定です。HPの方へWBSテンプレートというキーワードで検索してくる方が多いので、WBS自体のテンプレートを追加するかどうか迷っていますが、おそらく追加しないと思います。

また、名称も変更します。Workflow@ProjectManagementでは長すぎる....短くして、PM123とする予定です。プロジェクトマネジメントが123と簡単にできるという意味をこめて。

ITプロジェクトでは、なぜか、しっかりとしたリスク計画を作っていません。言葉では、リスク、リスクといっていますが、明確にリスクを定義しているプロジェクトにお目にかかったことがありません。

私自身も、やはり、明確に文書を作成して管理した経験はありません。プロマネをしながら、状況を判断して、次にこんなことが起こるのではないかと予測をつけて、それが起こらないように対策を講じるだけです。

KKD（勘、経験、度胸）という昔から言われているプロジェクトマネジメントの真髄（？）に頼っているだけです。