- ビジネス・キャリア
- マナー・一般常識
- 一般常識
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
第1号（創刊号） 2009.07.29
現場から学ぶプロジェクト管理(PMを目指して)
ｂｙ ひとなみ君
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
┌───────────────────────────┐
このメルマガは、プロジェクトマネージャや、それを目指す方々に
プロジェクトでの管理業務を中心に、私が実際に携わった数々の
経験を通して管理業務の実態をお伝えしようというものです。
└───────────────────────────┘
よろしくお願いします。
<今回の目次>
1. 「ひとなみ君」のプロフィール
2. このメルマガでお伝えする提供する内容
3. 今後の提供予定スケジュール
4. 「電力関係の会社向け業務システム構築」プロジェクトに
おけるプロジェクトマネージャとしての業務
5. 業務遂行時のトピックス等
＊「プレイングマネージャの幻想」
6. 次回予告
編集後記
■□■□■□■□■□■□■□■□■□■□■□■□■□■□■□■□■□
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1. 「ひとなみ君」のプロフィール
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
○ 1979年～1981年 中堅小売業にて家電売り場担当
販促（新聞チラシの紙面作り等）業務、商品仕入業務、
売り場のレイアウト作り、在庫管理等の業務に従事
○ 1981年～2001年 企業内SE
小売業で社内システムの保守、改善、新規システム開発
に従事。（プロジェクト管理業務がメイン）
○ 2001年～ 個人事業主としてプロジェクト管理業務に従事
○ プロジェクト管理は２６年の経験。
経験した対象システムは小売、物流に始まり電力、自動車、地方自治
体等の大小システムと多岐にわたる。
ユーザ部門としての経験、社内ＳＥの経験もある。
個人事業主としては8年以上の経験。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2. このメルマガで提供する内容
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
○ 過去経験してきたプロジェクト毎に
(1) 全体プロジェクト概要
(2) 担当プロジェクト概要
(3) プロジェクトマネージャとしての業務内容
(4) 業務遂行時のトピックスを紹介
(5) その他
○ 先ずは個人事業主としての経験をお伝えしますが、企業内ＳＥとして携
わったプロジェクトについても紹介する予定です。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
3. 今後の提供予定スケジュール
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
○ 毎週月曜日発行（祝日等で変動することもあります）
○ 一つのプロジェクトを複数回（５～１０回程度）に分け、その時々のトピ
ックス等を紹介
６つ以上のプロジェクトについて紹介を行っていく予定です。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
では、さっそく・・・
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
4. 「電力関係の会社向け業務システム構築」プロジェクトに
おけるプロジェクトマネージャとしての業務
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
○ プロジェクトの概要。
ある電力関係の会社における用地の利用に関する管理するシステムについ
て、汎用機利用の従来システムをＷｅｂベースのシステムにバージョンアッ
プするというもの。
従来の各種マスターやトランザクションデータは従来のものを新システムに
引き継ぐというもの。
○ 担当プロジェクト概要
上記のプロジェクトの中で、従来システムから新システムへの移行に関する
部分を担当するサブチームの管理業務。
そのチームの具体的対応内容は以下の通り。
従来システムのデータやマスターについて、フォーマット及び各値を新シス
テム用に変換するための仕組み作り及びプログラム作り、と実際の移行処理
も行うというもの
ここで仕事の委託について若干説明しておきます。
最終エンドユーザは電力関係の会社の方々です。そのユーザ会社がシステム
開発を一括である一社のソフト会社に委託。そのソフト会社が更にサブシス
テム毎に複数のソフト開発会社に開発業務を再委託するという形態。これは
結構一般的な委託のカタチです。
このプロジェクト内で移行処理部分の開発と移行処理実施を請負ったソフト
会社がチーム（移行チーム）を編成し、そのリーダとして私が参画したわけ
です。但し、私は途中からの参画でした。
（注記）私はこのソフト会社と契約し、この会社の人間として参画。最初は
SE兼プログラマとして、だったのですが、ある偶然からリーダとし
てやることになったのです。このあたりの事情は次回以降お話しし
ましょう。その当時はプロジェクトマネージャを個人に依頼すると
いうことは一般的ではなかったのです。
参画時点では全体プロジェクトは１年以上が経過していて、特にこの移行
処理部分の開発が大幅に遅れており、プロジェクト全体を一括で請負ったソ
フト会社は、最終ユーザである電力関係の会社からそのリカバリーを強く迫
られていました。一括で請負った会社は当然、移行処理部分を委託した会社
に「何とかしろ」と迫っている状況だったわけです。当時の移行チームは選
任のリーダはおらず、開発の実業務を行うメンバーの一人がリーダとしてと
りまとめるといった状況でした。つまりプレイングマネージャですね。
こういった状況の中でのプロジェクト参画。
今回は参画当時についてお伝えします。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
5.業務遂行時のトピックス等
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
○ 「プレイングマネージャの幻想」
ご存知のように、プレイングマネージャというのは、一人で二役（リーダ役
と作業者役）こなすのだから人です。使う側からすれば低コストで便利な存在。
でもスケジュールが大幅に遅れている状況において、実務をもっていてはチー
ムの管理はとてもできるものではありません。
何故か・・・。
リーダ自身もスケジュールに追われている作業を持っているわけですから、
その作業に専念しなければ自分の担当分のスケジュールは守れません。ところ
がチーム全体の進捗遅れなので他のメンバーも遅れている場合が殆ど。個々の
スケジュール遅れを全体としてどのようにリカバーするかがリーダの責務です
が、とてもそんなことに気をまわせるものでｊはない。もし気を回す時間的余
裕があるのなら、自身の作業に当てるかを迷うはずです。全体スケジュールを
守るためには自身のスケジュールを先ずは守る必要がある。それにスケジュー
ル遅れは後でなんとかなるのでは、という一種あてにならない希望を抱きがち
です。結局全体管理は後回しとなる。ところが全体管理を怠ると結局は更にス
ケジュールは遅れてくるわけです。リカバリーの為の対処がなされないからで
す。
これは精神論で片付く問題ではない。ちゃんと全体を管理する人物を専任でた
てるべきなのです。
私が参画した当時、そのリーダは当然自分の担当分の作業すら遅れ勝ちの状況
でした。私はまずそのリーダに
「全体スケジュールとメンバーごとの現在の作業状況を教えて」と投げかけま
した。
すると、彼は全体スケジュールを示したものを示し、
「僕の作業状況はこのスケジュールではここまでで、遅れています・・・」
「で、他のメンバーの進捗は？」、と先を促すと
「このあたりをやっているはずなんだけど、よく分かりません。僕、今忙しい
からメンバーに直接聞いてくれません？」と彼。
彼は、リーダとしての役目を果たしたくても、できなかった。説明する時間も
惜しい、ということもあるでしょうが、本当に把握していなかったのです。
みなさんの現場でもよく見かける光景では？
客先からは「スケジュールが遅れているのだから早く作業しろよ。なんでもい
いからなんとかしろ！」
当然です。
リーダがどのように管理しているのか、ではなく。スケジュールを守れ・・・
です。
そんな中、新しいリーダとして紹介された私に客先は
「開発の現状と遅れに対する対策について明朝までに報告するように」
ということでした。
客先からすれば新しいリーダが来たのですから当然の要求。このプロジェクト
における私の初仕事はこのように始まりました。
このような状況の中で、何故私が投入されたかがもうお分かりですね。管理が
ないプロジェクトはありえないのです。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
6. 次回予告
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
○ 次回は
「電気関係会社向け業務システム構築」というプロジェクトについて
お届けいたします。
＊「スケジュールは守るためにある」
です。
＊スケジュールについてどう考えたらいいのか・・・
○ おまけ
＊「当初ＳＥ兼プログラマのはずが、プロジェクトマネージャをやるようにな
ったわけ」
乞う、ご期待！
編┃集┃後┃期┃
━┛━┛━┛━┛━━━━━━━━━━━━━━━━━━━━━━━━━━
○ 創刊号ということで、大まかな説明を初めにしました。
○ 今後個々の事例の紹介を行っていきます。
どうぞ、ご期待下さい。
○ プレイングマネージャは絶対無理・・・とは言いません。これをこなせる
凄腕の方もおられます。単にコストを下げたい、だけの無理な押し付けではう
まくいかない、ということ。そこそこの規模なら管理は専任、というのがポイ
ントです。プロジェクトを成功させなければ、低コストも無意味・・・。当然
のことですよね。
○ 今後ともよろしくお願いいたします。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
最後までお読み下さり、ありがとうございました。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
