2009年2月アーカイブ

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

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

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

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

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

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

 

 

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

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

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

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

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

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

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

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

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

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

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

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

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

 

 

 

 

 

 

 

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

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

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

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

 

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

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

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

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

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

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

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

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

 

 

このアーカイブについて

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

前のアーカイブは2009年1月です。

次のアーカイブは2009年3月です。

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

メルマガ登録・解除
 

ウェブページ

Powered by Movable Type 4.1