プロジェクトを管理するにあたって

質問

ただいまＰＪをはじめるにあたって色々整理しております。

ベンダーや、客先と共有、ルール化しておいたほうが良い、
こうしてうまくいった、というようなことがあればご助言頂きたいと
思っております。

今考えているのが
　問題事項のフォーマット・管理方法、議事録の運用…です

よろしくお願いします

回答No.5

sinjou

海外製のプロジェクト管理webツール（ダウンロードは無料）ですが、
・現時点で必要な事項
・二週間後に必要な事項
・毎週の議事録
・プロジェクトの概要
・バグ
・進捗率etc
全てを箇条書きに表形式で表示→クリックしたらCADの画面みたく無限に広がります。

webサイトなので、県外に住む下請会社の方も見れますし、現地テストの方も見れますし、箇条書き入力が確定された時点で、関係するメンバーのメインPCにメールも飛びます。もちろん、メールチェックは不要です。
webサイトの自分の画面を見れば、自分の現作業や今後の作業候補が箇条書きの一覧で把握できます。

忘れっぽい方がいるなら、その方の画面に対して、箇条書きで突っ込みを入れておき、その画面のリンク先に、用件を丁寧に書いておく。

一番多いのが、ファイルの同期化の失敗です。
プロジェクトが始まる前に、フリーツール（なぜか海外製を採用するリーダーが多いです）をいくつか試して、同期の失敗発生率が少ない製品を選ぶべし。庶務さんに試してもらうと、効果的だと思います。

エクセルでルールの記述を増やす女性リーダーがいましたが、
「あいつは自分だけにしか読めないルール表を作る。」
と、社員＆派遣から言われてました。
エクセルに更新履歴シートを作成し、元のセルを修正するよりも、
webツールを採用し、更新履歴をクリック→更新された画面名をクリック→追加されたルールを読めるほうが、文句が出ません。確認を怠った側の自己責任でカタがつくみたいです。

回答No.4

iriyak

こんにちは。

プロジェクト計画を今まさに立案されているのですね！

(回答者のサジェッション)

ルールの洗い出しのやり方の一例をご紹介します。

(1) ルール化の狙い、目的を書く
(2) ルール素案を書く
(3) ルールを決めなかったら目的が達成されるか調べる
(4) ルールを決める

このやり方は、立案者 (ここでは質問者) の身の丈にあったルールを洗い出すことを狙ったものです。網羅的にルールを洗い出しません。身の丈にあったとは、立案者が思考実験で未来に起こりうることを見通せる範囲のもので、という意です。

(3)は、他の有識者に過去経験をたずねることで、立案者は仮想経験を得ることができます。それによって見通せる範囲を広げることも可能です。すでに寄せられている有識者の皆さんの回答は、まさにそうなっていませんか??

それから、(3)を調べるには、適切な問いかけを立案者自身に行うと進めやすくなるかもしれません。参考までに問いかけの文例をメモしておきます。

> 問題事項のフォーマットを決める

⇒フォーマットを決めずに進めたプロジェクト運営の事例は立案者の身近にあるか?? そこではどんなことが起きたか?? その結果、当初期待した目的は達成されたか??

> 問題事項の管理方法を決める

⇒管理方法を決めずに進めたプロジェクト運営の事例は立案者の身近にあるか?? そこではどんなことが起きたか?? その結果、当初期待した目的は達成されたか??

> 議事録の運用方法を決める

⇒議事録の運用方法を決めずに進めたプロジェクト運営の事例は立案者の身近にあるか?? そこではどんなことが起きたか?? その結果、当初期待した目的は達成されたか??

回答No.3

don_go

プロジェクトは結局の所、様々な人間の集まりです。
どれほど立派なルールや書式、ドキュメント等を準備
していても、何気ない言葉や態度が相手に対しやる気
をなくさせたり、対立感情が発生するといった著しい
悪影響を与えてしまい、結果としてチームの崩壊を招
く事も少なくありません。
プロジェクトリーダーには、そういった事の発生を未然
に防ぐ事も要求されます。
また互いの連携を良くする為に、各人の役割と相互依存
関係・責任関係等は最初のうちに明確にして把握させて
おく必要があります。
いかにしてチームを目標に向けて団結させるかが重要に
なります。

回答No.2

Mogugen

こんばんわ。

フォーマット的なモノはさほど重要でないと思います。随時プロジェクト実行時に見直しをかければ良い程度です。プロジェクト管理は「計画」が命です。計画の際は、スコープ／コスト／スケジュール／品質／コミュニケーション／調達／リスクなどの観点で計画が必要です。

今のあなたにとって何が不足しているかは解りかねますが、ご質問されている事項について、私の経験を交えて書いてみます。

＞ベンダーや、客先と共有、ルール化しておいたほうが良い、

・ベンダやお客様との間では、仕様凍結後の仕様変更に関するトラブルが発生しがちです。仕様変更する場合の取り決めや文書フォーマットを事前にけってし、双方で合意しておくと良いと思います。
・また、ベンダやお客様と良好な関係を気付くためには適切なコミュニケーションが重要です。困ったときにでも信頼関係があれば助け合えるものです。密な報告を心がけてください。具体的には計画時に会議体を規定しておくと良いでしょう。

＞問題事項のフォーマット・管理方法、議事録の運用…です
・問題事項には、懸案事項とリスク事項に分ける事ができます。
・懸案は備忘録になってしまいがちなので、何を記載するか事前に決めておくと良いと思います。また重要度などの項目を設けそれに応じて報告方法を変更すると、適切な管理ができると思います。
・リスク管理は、常にリスクを洗い出し、常にチェックをすることが重要です。
・議事録の運用はさほど重要でないと思います。ステークホルダとのコミュニケーションツールとして利用してください。経緯などを書いておくと、後で「何故この仕様になっているか？」を忘れてしまった場合などは助かります。

プロジェクト管理は、成功する計画さえたててしまえばあとは実行するだけです。
ただ、そのプロジェクトによっては（規模等）、管理しすぎても上手く回らない事がありますので、状況に応じて柔軟に押し引きしてください。ご健闘をお祈りしています。

参考URLにつけているPMBOKを読んでみると勉強になりますよ。（PMIという組織が認定しているPMPという資格もあります）

参考URL：

http://www.12manage.com/methods_pmi_pmbok_ja.html

回答No.1

nfushi

残念ながらルール化しても守られないと思います。
例えば、変数名のつけ方なんてルール化しても、途中から好き勝手につけられます。結果、作った人間が同じでも統一性のないゴミソースができます。ガチガチにルール化するよりある程度自由に作らせて、禁止事項だけを設けるようにしてはどうでしょうか？
ルール化とは違いますが、メールだけのやり取りはなるべくよした方がいいです。メールを送るのは構わないのですが、必ず電話でその内容の確認を行うといいでしょう。毎日数十件のメールがやり取りされる中で全ての内容を洩れなく頭の中に格納できる人は少ないです。別に長く話す必要はありません。メール見てもらえましたか？の一言でいいです。

個人的にはルール化より要求定義や概要設計に120％の力を注ぎ込んだほうがPJの成功に繋がると思います。