プロジェクトマネジメントの最近のブログ記事

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

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

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

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

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

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

 

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

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

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

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

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

 

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

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

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

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

 

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

 

プロジェクトは何も問題が起こらないという事は無いものです。

何か問題が起こった際に問題の発生原因や誰が悪いといった事にフォーカスしすぎないで速やかに解決に向けて指向する事がリーダーの重要な役割です。

プロジェクトで何が起ころうと、部下のワーニングを見過ごしたり適任者をアサイメントできなかったり、マネジメントが原因であったりと行き着くところはプロジェクトのリーダーが悪いのです。

何かの問題の原因や責任を追及しても問題の解決にはなりません。

期間の限られたプロジェクトで問題解決を脇において問題にばかりフォーカスしているのはリーダーとしては無責任です。

また、どんな組織でもそうでしょうが、問題の責任ばかりを問うと部下は責任のある仕事をしなくなります。自分のタスクとして明確にされていない仕事を拾わない組織は、プロジェクトとしては致命的に弱い組織になってしまいます。

 

 

やっていて当たり前のようですが、以外とできていないのが「仕様変更管理」です。

設計の変更要因は仕様障害、要件もれ、仕様の詳細化不足など様々ですが、仕様変更で一番やっかいなのが、設計書の記載レベルが粗すぎて仕様変更なのかどうか揉めてしまうケースです。

「仕様変更」というと直接コストに跳ね返るような気がして、誰の責任なのか、といった話になりやすく仕様変更依頼をあげずに仕様変更をさせようとするケースもあったりします。

仕様変更管理はなぜ必要なのか、どういう目的で行うのかを明確にしてプロジェクトに適用できれば良いのですが、プロジェクト外部の方も含めて理解を完全に得て進めるのは難しい場合もありますね。

仕様変更はプロジェクト記録、情報共有という意味合いを強く出す方が、スムーズに運用に乗ると思います。

仕様変更の管理を行わないプロジェクトでは、担当者レベルの判断で項目の追加や動作の変更を行いシステムの全体整合性がいつの間にか損なわれるというが起こります。

こういう状況が発生しだすと、大規模プロジェクトでは底なし沼に陥るようなものです。

仕様変更の発生がむやみに現場レベルで行われないこと、そして発生した変更内容をプロジェクト内で共有できる事が重要な目的のひとつです。

それから、プロジェクト記録として重要な役割があります。

プロジェクト実施中に「いつの間にか」仕様が変わってしまう事をゆるすと、承認された設計書の位置づけがあいまいな物になってしまいます。

現場の担当者がユーザに求められて対応を行った仕様変更が、後に元の(承認された)仕様で無いことが問題になった場合、開発者側が元に戻すことを求められるリスクがあります。

設計書や仕様書を仕様変更のたびに書き換え、それを版変えして再承認を得るという運用は無理に近いので、仕様変更管理の運用を行います。

コストマネジメントの観点でも、重要です。予算内で対応できるのかどうか、対応の重要性はどうなのかといった事を常に把握できるプロセスを構築できるのです。予算超過するかどうかは予算根拠からの乖離について常に意識を向けているかが重要です。

 

 

 

 

 

 

 

プロジェクトに属するメンバ、あるいはチームに対してタスク分担が明確であることは重要ですが、これだけでは、うまくいかない場合があります。

プロジェクトのアクティビティはすべてWBSに落ち、それぞれに担当がふられるのが「あるべき」運営なのかもしれませんが、実際問題としてWBSに定義されていないタスクがあった場合に誰がそのタスクを拾うのでしょう?

プロジェクトは予期しないことが起きますし、たいていの場合は予定どおりにすべてが実行されるという事はありません。キーパーソンが退職する事もあれば、法律改正や企業統合がいきなり起こる場合もあります。このような変化に常にさらされるプロジェクトという組織体では個々の担当者のタスク定義の前にミッションを明確にする事が重要です。

ミッションで動く組織は柔軟で、そしてモチベーションが高く維持される傾向にあります。

 

開発者が大勢参加するプロジェクトでは開発規約を用意するのが普通ですが、意外とコーディング規約や開発に関する決めごとをしっかりと定めてプロジェクトを実行しないケースがあったりします。

命名規約、コーディング規約等を定めることは開発品質だけでなく保守の際にも理解されやすいという点で非常に重要です。

技術要素などに統一性があるような場合は社内の開発規約を統一する事が出来るのでベターかもしれません。ただし、プロジェクト独自の部分が大抵の場合はあるので、プロジェクト用として改めて定義するのは必要なタスクだと思います。

特にアーキテクチャの設計思想とアプリケーション開発の思想が一致して整合性を保たせるには明文化しておく事が必要だと思います。

開発会社へ開発委託するようなケースは予め決められた規約に従うようにRFPに記載しておけばスムーズです。

開発規約はプロジェクトに参加する設計・開発者すべてがスムーズに理解できるという事が何よりも重要です。

規約の類は理解しずらければ意味をなしません。

「使いやすく、わかりやすい」が開発規約のキーワードです。

 

 

このアーカイブについて

このページには、過去に書かれたブログ記事のうちプロジェクトマネジメントカテゴリに属しているものが含まれています。

前のカテゴリはスケジュール管理です。

次のカテゴリはモチベーションマネジメントです。

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

メルマガ登録・解除
 

ウェブページ

Powered by Movable Type 4.1