2008年7月アーカイブ

ITプロジェクトですといくつかのチーム、サブチームが存在すると思いますが、

例えばプロジェクトマネジャーがチームリーダーの了解を得ないでチームメンバに直接指示を

するような事を思わずしてしまったりする事があります。

が、

これは絶対避けなければなりません。

 

指示する人間が複数になると指示される側は作業の優先順位や作業ボリュームをコントロール

してもらえないという思いからフラストレーションを高めてしまいます。

モチベーションマネジメントにも必要な要素です

 

 

類似パターンで良くあるパターンが、庶務的な事を担当してくれる方に対する指示。

あれやこれや、様々な人が仕事を振ってきますが優先順位を決めるルールや

作業ボリュームの把握をする人がいないと、相当なストレスをためてしまう状況になります。

 

顧客、同僚に何かを頼む場合も同様です

あたりまえの事ですが、指示系統は気を配りましょう。

 

 

システム、サブシステムの定義をどのような括りで定義するかは結構様々なように思います。

例えば受注管理業務機能に対してシステム導入を行う場合、受注管理システムなどど呼ぶと

して、これが受発注管理機能のシステム導入になると、受注管理サブシステムとなったり。

 

ホストからオープン系システムへ移行した際にオープン化された新システムを「○○システム」

と呼んで、それらを構成するサブシステムの単位が他のシステムと業務機能的に同レベルだったり

すると混乱する可能性があります。

 

神経質になるほどの事でないかもしれませんが、システム名称は大事ですので、

良く考えてつけたいものです。

 

 

IT経営においてマスタデータの整理は非常に重要なミッションですが、

これは場合によってはとっても大変な一大プロジェクトになります。

製造業では様々な目的別BOM(部品表)の整理をいっぺんにやろうとすると、

かなり大変な事になると思います。

 

流通業でひとつの商品に対して売価情報を登録しようとしても店舗毎、地域毎、エリア毎、

キャンペーン毎、特価設定など様々な要素があるのです。

「わざわざマスタ管理が大変なのは、言われなくてもわかっている」

と言われそうですが。。。。

 

実はマスタ管理に関しては甘く見る方が多いのです。

要件を決めるのを後回しにする、経験の浅いメンバで取り組むなどのプロジェクトは

実に多いです。

 

 

何をいまさら、、、という感もありますが、「議事録」書いてますか?

打ちあわせを行い、議論した内容、決定事項を第三者が読んでも判るように書くのは

非常に大事です。

 

そして議事録の運営についてプロジェクト開始時に決めておきましょう

配布者は誰か、作成期限はいつか?

議事録に承認はもらっていますか?

議事録の承認は必要ですが、なかなかもらえません。

議事録配布後、1週間以内に異議、意見が無い場合は自動承認となるなど、

プロジェクトルールを決めておくと良いでしょう。

 

議事録はプロジェクト記録として非常に重要です。

要件がどういった経緯で変更になったのか、あるいは決まったのか

誰の責任で何をいつまでに行うのか明確に記載される事でプロジェクト推進に非常に

役立つ重要なツールです

 

 

 

規模にもよるでしょうが、ITプロジェクトの進捗状況を経営陣に定期的に報告するのは

どの企業でも行っている事だと思います。

 

ITプロジェクトは、進捗に遅延が発生する事は良くある事ですが、正直に遅延を報告しても

最後にはつじつまが合うように(例え無理だと思っていても)報告をするケースを良く見かけます。

経営者からすると、「順調と聞いていたプロジェクトがいきなり破たんした」という事も世の中には

たくさんあるわけです。

 

ベンダーと発注者の関係でも同様の事が発生します。

遅延状況を正直に伝えないベンダー、あるいは「何とかします」と言い、それを信じる担当者。

 

どのような状況でも解決策はあるものですが、状況を公けに出来ないと機能不全となり

状況はさらに悪化します。

状況を報告する際には「私」を置いて客観的視点から正確な報告をする事が大切です。

 

 

優秀なコンサルタントを雇って高いお金を支払えば

儲かるシステムができあがると思えば大間違いです。

 

企業を変える、しくみを変えるというのはカルチャーも含めて変革しなければ難しく、

カルチャーを変えていくには経営トップのコミットが必要です。

 

システムの要件定義を行う際に実務を知る方々が時間が無いという理由で参画しない場合、

あるいはプロジェクトの方針としてユーザ要件を聞かないという方針であったりすると

多くの場合、実務に支障のきたすシステム、使われないシステムができるでしょう

 

大切なのは、新しい仕組みを構築する上で社内の各部署の人間が集まり、情報や意見の交換を

行い要件を決めていく、そして自らプロジェクトの参画者であるという意識を持って臨むことです。

プロジェクトに参画する事により、他部署や会社への理解が深まり、企業内での人脈が拡がるなど

の副次的な効果もあります

 

マスタスケジュールを作成する際にクリティカルパスを意識するのは非常に重要です。

スケジュールを共有する際にも、これを意識してもらえるように明示的にする事で

プロジェクト運営に大きなインパクトがあります。

クリティカルパスの遅延はすなわち、プロジェクトの遅延に直結します。

このパスの遅延を避けるために各チームはマネジメントを行い、結果各チームの個別最適

スケジュールを避ける運営が可能になるとも言えます。

 

 

基幹系システム導入にあたって現状業務の理解、問題点の抽出などのためにヒアリングを

行うのが一般的かと思います。

事前に業務分掌などを入手し業務理解をした上でインタビューを行うのも良い方法かと思いますが、

単純にインタビューを実施するよりも効果的な方法があります。

 

それは該当業務に関係する方々を集めて2時間程度のセッションを行い、

現状業務の分析を行う事です。

セッションのアウトプットでDMMやDFDを作成してもらいます。

作成の過程で業務の無駄、負荷などの意見が出てくるので、それらを記録し、改善テーマとして

管理します。

 

 

プロジェクトにおける課題管理は意外と奥が深いです

 

課題管理に自由に記述できるようにすると実に様々な事柄がのってくる

分類すると、現在起こっている問題、将来のリスク(備忘録的な)、未決定事項、ToDoList、

悩み、など

これらを一緒に管理するとマネジメントはうまくいかない。

いや、いかない事もないかもしれないが、やりずらい。

これを避けるためにも、どういった事を何で管理するのか、プロジェクトメンバに対して

ルールを定義し、示すことが重要です。

 

 

大規模なITプロジェクトにおいて予算の見積もりはけっこう難しいものです

 

その理由のひとつに、ITプロジェクトは人の技量によりアウトプットの質量が

大きく影響される点があるかと思います。

 

とはいえ、見積りの手法は数多くありますが、何を使うにしろ、機能に対する工数の積み上げから

算出する見積りと要員計画から積み上げる見積りの両方を実施するべきです。

 

そしてこれらの見積もりをベースに経験則をプラスしましょう

 

見積りはプロジェクトのフェーズが若い段階ではプロジェクト予算の確保、実行判断、

スコープの意思決定などに使われる事を意識して算出します。

なお、一度出た数字は、いくら条件を並べたところで、あたかも決定した金額として

扱われ予算を追加していくというのは困難となるのでご注意を

 

情報システム部が各部署のご用聞きになっている企業はけっこう多いように思います。

 

このような企業では、各部署の要求を満たすシステムの導入が進み

無駄が多くメンテナンス性も低い上に運用コストが高いシステムが意図せず

できあがってしまいます。

 

IT部門が経営と密接に連携できていない企業は

本来企業として何を実現すべきか、全体のIT投資の中で優先順位は

どうであるかといった全体最適が失われがちです。

 

こういった企業においては、個々の案件の対応に対して費用対効果を稟議にあげてといった

処理をされているのを目にする事があります。

個別の小さな改善で費用対効果を測るのは非常に苦しいものです。

IT投資で本来威力を発揮する投資ではないのですから。

 

ITプロジェクトを実行する上で企業の情報システム部とは切っても切れない中です。

 

私がかかわってきたITプロジェクトは企業改革とセットとなったITプロジェクトで経営者直轄の

プロジェクトである場合がほとんどですが、そういうITの重要性を理解している経営者の企業

でありながら、情報システムを担当する部署の立場が意外にも弱かったりします。

 

「システムは動くのが当たり前」な社員の方は、当たり前に動いている事に高い評価は

なかなか得づらいでしょうし、IT部門が出世の花道という企業もあまり無いのが現実です。

最近ではCIOを置く企業も増えましたが、企業経営と情報システムの連携の重要性が

高まっていることの表れだと思います。

 

現実としては、1部上場企業でさえ、情報システム部門は古いシステムの運用業務

に追われる毎日で、システムの改修はできるが、新しいシステムを導入する事に経験豊富な

方はなかなかいなかったりします。

 

(続く)

 

ITプロジェクトで共有する用語集は、大きなプロジェクトであれば必須です。

プロジェクト内で使用する特殊な言葉をはじめ、一般的な言葉であっても人によって

とらえ方が変わるものは定義しておくと混乱を避けることができます。

用語集とあわせてドキュメントの整理も行っておくとプロジェクトへ新しく加わるメンバへ

スムーズにキャッチアップしてもらえます。

 

用語集は場合によっては要件定義などを行う際に業務担当者が使用する言葉の

意図を明確にするという利用の仕方にも利用できます。

業務を行っている人は自社内の言葉がどこまで一般的であるか意識をしないで

利用するため、後に「○○も当然含まれていると思った」といったことが起こりかねません。

 

企業システムを構築するにあたり、WBSに記入し忘れないようにしたいのが、ユーザ教育です

当たり前の事ですが、システムを構築する事に集中すると優先度が低くなったりしがち

なので、あらかじめ計画をし、要件定義を行う際にラフな実施内容、スケジュール、体制などを

想定しておくと良いでしょう。

特にコスト面に影響するので注意したいのが、

誰がユーザ教育用の資料をつくるのか、誰が教育を行うのか

教育環境を用意するのか等明確にしておくことです。

 

ユーザ教育はなるべく現場の業務がわかっているリーダークラスの方に担当いただくと

スムーズです。

 

 

ITプロジェクトの話とは、ちょっと離れますが。。。

会社の近くにあるホットヨガスタジオに先週から通い始めた弊社のAさん。

やる気まんまんで、一昨日に早速予約をしようと電話をしたが、つながらない

オフィスに行っても閉まっている。。。

「今日は休みだったかな?HPに案内も出てない」と文句を言ってましたが

昨日はついにHPが閉鎖してしまい、これはオカシイとネットで情報収集。

 

回数券を買って1度しか通ってないのに・・・

 

会社に連絡もとれず、店に誰もいない、他の店舗に電話しても同様に電話は不通

 

こんな時にインターネットが無かったら、情報収集もできず途方にくれてしまうことでしょう

 

早速、インターネットでニュースや被害者の投稿するサイトを見つけたAさん

幸いクレジットカードの決済がまだだったため、被害はなく済みそうですが、

インターネットではニュースだけでなく、被害者同士や解雇されたスタッフからの

書き込みでリアルな情報を収集できるのがすごいところです。

インターネットの力を改めて感じる出来事でした。

 

全国に24店舗 エステサロンなど突然閉店

http://www.mbs.jp/news/kansai_GE080703112700129521.shtml

ITプロジェクトだけに限りませんが、実際にOne To Oneで話をする時間を意図的に作るのは

非常に大切です。

日頃から話せる距離にいるのであれば良いですが、あまり顔を合せることのないような

状況ですと、なおさらです。

部下は言いたい事があっても、本当に困った状況にならないと、なかなか上司に問題を

話さない事が多いものです。

日頃から部下の近くに行って声をかける、特に用事がなくても1対1で話をする時間をとる、

という事を意識的にする事が日ごろのコミュニケーションを円滑にし、社内・プロジェクト内の

空気を変えます。

実際、1対1で話すことにより、多くの情報を得られます。

プロジェクトの問題点、家庭の事情、希望している仕事内容・・・

 

メールだけでのコミュニケーションで済ませがちですが、あえてリアルなコミュニケーションを

意識的に行いたいものです。

 

 

ITプロジェクトを実行する上で非常に重要なのがコミュニケーションです。

コミュニケーションは事前にデザインするべき事項のひとつです。

例えば、定例ミーティング、報告会などの会議体の定義もコミュニケーションデザインのひとつです。

問題が発生した際に、どのように共有を行い、どのように解決するか、そういった事を事前に定義

しておくのはプロジェクト計画として必要です。

実際、プロジェクトのチームリーダーが集まる会議体を事前に設定せず、プロジェクトリーダーが

多忙になってしまうと、まったく会議が開催されなくなり、プロジェクト内の意思疎通が悪化し、

結果として各チームが個別最適に向けて動き出すというケースもありました。

 

 

 

 

あまりタイムリーな話題ではありませんが、、、

ビル・ゲイツ氏がついにマイクロソフトの経営から退くことになりました

20年くらい前には、まだMachintoshのユーザインタフェースが優位で、

少しあとにWindowsが出た際にも起動にえらく時間がかかっていたものです

あれから本当にあっという間で、なんとも感慨深いものです。

 

ビル・ゲイツ氏は日本のフィレオフィッシュが一番うまいと言って

マクドナルドに並んでいたという話を聞きますが、会社には成長を求める一方、

自分自身はお金には健全な感覚を維持しているようで、好感が持てますね

 

マイクロソフトの登場でパソコン市場が大きく変わり、オープン系での基幹システム構築も

今では普通の事のようになりました。

しかし、一方であれだけの膨大な研究開発費を投じても、Yahoo!やGoogleといったサービスは

自社の中から生み出すことはできませんでしたね。

(MS?DOS自体、マイクロソフトが開発したのではなく、買ったプログラムという話もありますが)

マイクロソフトはどういう企業になっていくのか、IT業界を変える大きな変革は次はいつ起こるのか、

興味を持って見守りたいと思います

 

 

 

このアーカイブについて

このページには、2008年7月に書かれたブログ記事が新しい順に公開されています。

前のアーカイブは2008年6月です。

次のアーカイブは2008年8月です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

メルマガ登録・解除
 

ウェブページ

Powered by Movable Type 4.1