ITプロジェクトを成功させる プロジェクトマネジメントのアイブルーム ブログ


プロジェクトマネジメントの強化でITプロジェクトの成功を確かなものに

株式会社アイブルーム
プロジェクトマネジメント支援
〒107-0062
東京都港区南青山3-11-10
TEL/FAX(03)-3403-5107

ITプロジェクトを成功させるマネジメント

ブログ


要件定義 【コンサルティング

最近仲良くしていただいている建築会社の社長がテレビに出ていたので録画して見させていただきました。

女性の目線でリフォームを提案するという事ですが、感銘を受けたのはリフォームのカウンセリングの方法です。

「どんな料理がお好きですか?」「洗濯はいつしますか?」「好きな雑誌は?」「冷蔵庫の中見ていいですか?」
リフォームと一見関係なさそうな質問が実はどのような家が必要かを提案するベースとなっている。
「どんな部屋にしたいですか?」という質問を投げかけてもお客さんの本当のニーズは引き出せない。
収納スペース、火力、洗濯機の置き場所、等々。。。 これらの質問によって顧客が気付かないニーズを引き出せる。

システムの要件定義も同じようなものですね。
どんなシステムが必要かをとりまとめられる顧客は普通いません。
本当のニーズを引き出さないと、システム上の制約によって、現在の業務が制約されている事に気付かず、
現在の運用をベースにシステムをデザインする可能性があります。

システムの要件定義もいかに顧客の本当のニーズを引き出す質問ができるか、それが重要ですね。

続きを読む"要件定義"

決断するのがリーダーの仕事 【プロジェクトマネジメント

前にも書いたと思いますが、「決断するのがリーダーの仕事」です。

AとBという選択肢がある。

どちらが良い選択か、決定的な決め手がない。

もっと詳細に分析するべきか、どこまで詳細に情報を集めるべきか。

プロジェクトは待ってくれません。

決断のタイミングが遅くなればなるほど、スケジュールへ影響を与えます。

 

選択肢のどちらが正しいかを誰でも判断できる状態であれば、誰がリーダーをやっても同じことです。

リーダーは不確かな状況において、決断を下す事が重要です。

その決断は論理的にはうまく説明がつけられなくても、自分の経験を元にしているのです。

自信を持って決断を下してください。

なにより一番最悪なのが決断をしないことです。

 

続きを読む"決断するのがリーダーの仕事"

認識あわせは思わぬオーバーヘッド 【プロジェクトマネジメント

プロジェクト内でのフェーズの考え方(何をアウトプットとするのか、どういう作業を行うのか)が違うと意識あわせだけで相当な時間がとられてしまいます。

こういうタスクは一々プロジェクトの計画に乗ってこないのが通常なので目に見えないタスクとして、けっこうオーバヘッドになります。

バックグラウンドの異なるメンバが集まる場合には特に、社内の標準化基準を元にするか、あるいはプロジェクトリーダーなどが決めてリードしないと、いつまでも軸がずれたまま進んでしまいます。

そういう意味でもプロジェクトの進め方について社内標準の定義があるのが望ましいのです。

 

続きを読む"認識あわせは思わぬオーバーヘッド"

ちょっと休憩 【モチベーションマネジメント

プロジェクトって、けっこう精神的にきつい時もありますよね。

そんなとき、お勧めなのがこのサイト

ほめられサイト

人に教わったんですが、思わず共有したくなりました。

 

PC画面で褒められてもうれしいんだから、人に褒められたらうれしいですね

プロジェクトの周りの人良い部分を見つけて称賛しましょう!

 

続きを読む"ちょっと休憩"

業務システムにもデザインは重要 【その他

あまりITプロジェクトで見た目のデザインについて触れることって少ないですが。

業務アプリケーションは人が毎日見るものですし、判り易くて使いやすい、スタイリッシュなインターフェースを提供出来るとユーザも喜びます。

入力項目がたくさんあって、見ただけでうんざりするような画面ってけっこうあります。

デザインがいいと、ユーザーのモチベーションにも影響するものです。

単に見た目がかっこいい画面を作るというのではなく、業務用途に応じた画面デザインが必要だと思います。見た目が良くても大量入力が必要な画面ではパフォーマンスが重要だったりしますしね。

業務判断を促したり、入力ミスを減らすという観点で画面デザイン・機能を見直すと出来ることがたくさんあります。

なかなかプロジェクト組織の中にデザインチームを持つのは難しいですが、開発会社としては差別化できる要素なんじゃないかと思っています。

 

続きを読む"業務システムにもデザインは重要"

プロジェクトの成功は委託者にも高く依存する 【ITコンサルタントを上手に使う方法】【プロジェクトマネジメント

プロジェクトが成功するかどうかは、実は委託者側の問題にけっこう依存する部分が大きいものです。

プロジェクトの成否は要件定義の質で40から50%程度決まります。

要件の定義はレベルの大小はあってもプロジェクトの開始から終わりまで発生してきます。

プロジェクトの開始には、そもそも何を実現したいのか?どのくらいの予算でやりたいのか?

といった要件から具体的な業務・システムのスコープの決定に始まり、どのように業務を変えるのか、システムをどういった機能にするのかといった詳細な部分にいたるまで。

さらには運用や移行の要件などもしっかり決めておかないと問題になります。

《システム開発の受託者によっては、これらの決めるべき(あるいは決めておいた方がトラブルを防げる)要件を事前に聞かない(多くの場合は気が回らない、ノウハウが無い)ケースがありますが。》

 

よくありがちなのが、予算とスケジュールと、おおざっぱなシステム機能だけは決まっていて、いざプロジェクトが始まると社内で要件調整に手間どり、いたずらにスケジュール・予算を無駄にしてしまい開発予算が足らなくなるといったケースです。

これは委託者がシステム開発に対する認識が甘く、きっちりとした体制を組まないケースに多くあるように思います。業務システムの開発は要件を決めることやテストにおいて自社のメンバが必須となる作業があり、ここが非常に大きなポイントとなる事を認識する事がプロジェクトの成功への早道です。(受託者は委託者の巻き込み、啓蒙活動が重要です)

委託者の体制にITプロジェクトの経験豊富な人材を入れる事も大きな違いを生みます。

自社体制で不足している場合には外部のプロジェクトマネジメント支援を行うコンサルタントを活用するのもお勧めです。

続きを読む"プロジェクトの成功は委託者にも高く依存する"

プロジェクト参加者の教育 【プロジェクトマネジメント

プロジェクトの体制はプロジェクトのライフステージで変わっていきます。

設計・開発を行うメンバーが自分の担当分だけでなく全体の業務やシステムについて理解を深める事で設計・テストの品質が向上します。(効率アップも期待できます)

プロジェクトライフステージの中で状況に応じてプロジェクトメンバに対して、プロジェクトの全体像を説明する機会を意図的に設け、初めから計画に入れておくと良いと思います。

また、プロジェクトの共有フォルダには、読んで理解できる資料一式(用語集を含む)を格納し、新しいプロジェクトメンバが速やかに入れるように最初から考慮しておくと良いでしょう。

 

続きを読む"プロジェクト参加者の教育"

技術検証はお早めに 【プロジェクトマネジメント

オープン系システムで構築するプロジェクトの場合、よくある事ですが技術要素の組み合わせで社内で実績が無いような場合(ソフトウェアのバージョンの違いも含む)はプロジェクトの初期段階で検証チームを編成し、アーキテクチャを固める事をお勧めします。

プロジェクトの開発が進んでいざテストを実施したら技術的な課題が出たというケースですとプロジェクトの進捗や予算への影響が出てしまいます。

また、技術検証を行う上で基本となるコーディングなどが終わっていれば開発が本格化する際に効率よく着手できます。特に大規模なプロジェクトで1週間程度のロスはコスト的にも非常に痛いので、いかに効率よく開発を軌道に乗せるかという観点が重要です。

続きを読む"技術検証はお早めに"

プロジェクト実行のついで仕事にされがちな「標準化」 【その他

PMBOKの普及もあってか、企業統制が求められているのもあり、プロジェクト管理の標準化意識を持つ会社が増えています。

これについては良い事ではあるのですが、標準化作業を実行中のプロジェクトで実施しようという判断をされるケースがあったりします。

プロジェクト管理の標準化のたたき台があって、現場での適用を試験的に行うのではなく、プロジェクトの現場で標準化作業を進めようとするものです。

これが当初計画からのものでプロジェクトの体制・予算・スケジュールに織り込み済みであればいいのですが、そうでないとプロジェクトの現場は相当な負荷がかかるリスクがあります。

(気持はわからないでもないですが。。。。)

 

ところで、この「プロジェクト管理の標準化」って、出来ている大企業はけっこう少ないです。

さらに言うと、標準化があっても適用されない、あるいはガチガチで柔軟性が無いといった問題がある企業も多いです。

「標準」といっても決められた方法に必ず従って実行するというのではなく、標準の管理法があって、それをプロジェクトにあった形でアレンジする必要があると思います。(それがプロジェクトマネジメントの腕という気もしますし)

そのアレンジの幅をどこまでプロジェクトによって認めるのかが企業風土の反映という気もします。

 

 

続きを読む"プロジェクト実行のついで仕事にされがちな「標準化」"

システム構築を委託する側の体制について 【プロジェクトマネジメント】【組織・体制

企業システムの構築プロジェクトにおいて、システム開発を委託する会社は、開発会社の選定をしてお金を払えは終わりというものではありません。

特に大規模なプロジェクトであれば専属のプロジェクトメンバをアサインするべきだと思います。

このような場合に、どのような人間を社内からプロジェクトメンバとして入れるべきかという質問があります。

システムの品質を決定づける要件定義をスムーズに、そして精度高く実施するにはシステム要件をとりまとめる人間と業務要件を出す現場とのスムーズな連携環境を構築する必要があります。

業務改革の伴うシステム構築では時に現場の思いと衝突があったりしますし、日常の業務の中でプロジェクト作業をこなすという負担増もあり、現場の理解を得るための人間力や社内ネットワークがある方がプロジェクトマネジメントチームにいると非常にプロジェクトの進捗にメリットがあります。

若手は将来を有望視される、いわゆるホープを選ぶべきでしょう。

全社プロジェクトであれば社内を横断的に知る良い機会ですし、様々な事を俯瞰できる能力が身につきます。また、プロジェクトとしても現場の業務を深く理解している視点から様々な業務要件・システム要件を検討できるので創り上げるシステムが大きな成果を出しやすくなります。

ただ現場作業に影響が出てしまうので、社長からのトップダウンで業務部署からの理解を得ることが望ましいでしょう。

 

続きを読む"システム構築を委託する側の体制について"