プロジェクトマネジメントってどうすればいいの ?

pinbou 曰く、

本家 /. の記事 (Project Management For Beginners?) より。悩める新米プロジェクトマネジャーからのご質問。

仕事でかなり複雑なウェブデータベースアプリケーションを作ることになりました。今までこの職場には私しか「IT 屋」がいなかったので、適切なプロジェクトマネージメントのやり方を学ぶ必要を感じたことはなく、コードのコメントとして情報を残しておけばそれでいいやくらいの感じだったのです。

ところが今回のプロジェクトは複数人が関わるなんだかややこしいものになってきていまして、そろそろ組織だったプロジェクト運営をする必要があるんじゃないかと思い始めました。そこでプロジェクトマネジメントについてきちんと学びたいのですが、何を見れば良いでしょう ? 本でしょうか ? (良い本なら買います) 、あるいはウェブサイトで良いところがありますか ? 仕様書はどういうふうに書くのがいいんでしょう ? UMLを使うべきなんでしょうか (でも私にはなんだか UML は複雑で直感的でないように思われます) 、それとも ER 図のほうがいいでしょうか。今回の仕事に限って言えば、機能完成日の見積もりを出すだけで良いのですが、これから本格的にチームで仕事をするときに必要になるものはどんな知識でしょう ?

一つ言えるのは

[duenmynoth (34577)]

一つ言えるのは「自分は作業しない事」ですね

プロジェクトマネージャーに徹してください

グダグダになるのは目に見えているので、担当部署ごとにサブマネージャを置いて
実作業は全部任せて自分はその管理のみに集中する事です
マネージャーなのにコーディングまでやるようだと
結局全責任を取らされる上に一人デスマーチになります

問題はそんなに役割分担できるほど人材というか人数がいるかどうかですが・・・

Re:一つ言えるのは

[Anonymous Coward]

…というやりかたには現実的に無理があることが多いので、

>プロジェクトマネージャーに徹してください

まったく逆に「マネージャなんて誰も(自分も)やらない」という手も。

「船頭多くして船陸に上がる」が成り立つのは、船頭どうしのコミュニケーションが足りないせいです。
じゃあコミュニケーションをすればいい。
べつに船頭を一人以外全員殺すのだけが「正解」ではないです。

もっと現実的にいえば不慣れかまたは「自分は慣れてる」という思い込みにより
不適切な「マネージメント」がおこなわれることが凄く多いんですわ。
そんなことするくらいならヤらないほうがマシという似非マネージメントが。
なので、マネージメントをするということ(ましてや「しろ」という上からの命令)には十分な用心と警戒が必要。

Re:一つ言えるのは

[Anonymous Coward]

それをやると、成果物に漏れが発生するので。
成果物定義とWBSと、要素の完了確認は必要だと思います。
（精度が悪くても、定期的に修正すれば、無いよりまし。）
欲をいうと、絶対に考慮漏れ要素とボトルネックが発生するので、 工期に対して作業を均一に振らないことでしょうか。

Re:一つ言えるのは

[BlueRain (37857)]

>>「船頭多くして船陸に上がる」
船頭がおおけりゃ船でさえも陸に上がれる。
もっと大勢いれば宇宙にだって行けるさ。
ということですよね。

そういう私は毎日Excelを眺めて進捗報告してました。ソフト系じゃないけど。
たくさんいる船頭さんにお世辞を言ったりごまをすったり頭を下げたり。
それでも仕事が進んでくれるからいいや。
その船頭さんたちもみんな自宅待機という名の切り捨て状態です。

Re:一つ言えるのは

[CowardDuck (25674)]

> 一つ言えるのは「自分は作業しない事」ですね

これはとっても正しい。

> プロジェクトマネージャーに徹してください

プロジェクトマネージャーになるよりクライアントになるべきだと思う。 それも良いクライアントに。

良いクライアントとはベンダに騙されず、自分もベンダに嘘をつかないクライアントのことだ。

ベンダに騙されないのはそれなりの経験がいるがベンダに嘘をつかないことはすぐ出来る。
特に次の二つをしないことだ。

• 後から値切る。
• 設計段階を過ぎてから仕様変更する。

プロジェクト管理と開発手法

[tiga (4391)]

何だか、プロジェクト管理と開発手法が、同列になっているのが、気になりますが。

開発手法
ずばり、アーサーアンダーセンあたりの開発手法を買うのが、早いでしょう。
勿論、これをそのまま使えというのでは、ありません。
自社ニーズに合わせて、カスタマイズすればよいのですから。

プロジェクト管理
上記の開発手法には、必ずレビューポイントが、いくつかあります。
進捗記録もチェックポイントとなるでしょう。
これらにより、
1.進捗管理
2.品質管理
を行っていくのが、よいでしょう。

その上で
要員の配置
かなり贅沢ですけど、マネージャーとリーダーを分けるというのも一案です。

PL（プロジェクトマネージャー）
・対外折衝
・全体工程管理
・システムを機能的な側面から捉える。
・PL、客先を交え、各種協議の調整を行う。
など

PL（プロジェクトリーダー）
・開発者内での調整
・サブシステムレベルでの工程管理
・主に技術面からシステムを捉える
・成果物の適合判断・・・レビューアーとしてレビュー実施

SL（サブリーダー）
・世に言うSE業務を行う。

といった感じでしょうか。

プロジェクト管理手法の本は、多く出版されています。
でも、最終的には、自分たちでその適用可否を判断すべきです。

そのためには、プロジェクト管理と開発手法をひとくくりにしないほうがよい
との思いで、コメしました。

本家より

[hohehohe (11394)]

Making Things Happen: Mastering Project Management (Theory in Practice (O'Reilly))
という本を書いた人のブログ [scottberkun.com]に「本を読む前にすること」として面白いコメントがありました。（括弧内は補足）

　　　　But without talking to your team, and without establishing credibility and leadership, no book, degree,
　　　　or IQ, will be of any use to you as a project manager. Start with your team first and earn their trust.

　　　　チーム（のメンバー）に話しかけず、信用とリーダーシップを得なければ、どんな本や
　　　　degree（学位？地位？）やIQもプロジェクトマネージャーとしてのあなたには役にたたない。
　　　　あなたのチームから始め、彼らの信用を得なさい。

そのための方法として次のような方法 [slashdot.org]を挙げています。

　　　　1) I'd recommend talking to your team, individually, about what things on the project are most frustrating or could be improved.
　　　　プロジェクトのどんなことが一番苦痛か、あるいは何が改善できるかについて、あなたのチームの一人一人に話しかけることを勧めます。

　　　　2) In each conversation ask for their advice on what you can do, and also what they are willing to do or try
　　　　それぞれの会話で、あなたに何ができるかを聞きなさい。また彼らが何を喜んでする/トライするかをききなさい。

　　　　3) Based on your conversations, propose one simple change that has the best odds of both being accepted, and improving things.
　　　　If the team has lots of conflicts, pick　something very small. If there is too much dissension, pick something you can do with just one or two others.
　　　　その会話に基づき、みんなに受け入れられ、物事を改善することもできる簡単なことを一つ提案しなさい。チームにconflictがいろいろあれば非常に小さなものを選びなさい。
　　　　意見の不一致が多すぎればもう１つか２つあなたにできるものを選びなさい（ちょっと訳おかしいかも）。

　　　　4) Then make the change.
　　　　そして変化をおこしなさい。

　　　　5) If things go poorly go back to #1.
　　　　うまく行かなければ1に戻りなさい。

　　　　6) If things go well, propose the next thing from #3.
　　　　うまく行けば3に戻り次の提案をしなさい。

--
AVG anti-virus data base out of date

Re:本家より

[hanap (14297)]

If there is too much dissension, pick something you can do with just one or two others.
意見の不一致が多すぎればもう１つか２つあなたにできるものを選びなさい（ちょっと訳おかしいかも）。

意見の不一致が多すぎれば、あなたが他のせいぜい1人か2人とできることを選びなさい。といったところでしょうか。

Re:本家より

[hohehohe (11394)]

あ、なるほど。ありがとうございます。

--
AVG anti-virus data base out of date

やめとけ

[Anonymous Coward]

>仕事でかなり複雑なウェブデータベースアプリケーションを作ることに
>なりました。今までこの職場には私しか「IT 屋」がいなかったので

その職場では無理。

Re:やめとけ

[macintrash (30773)]

ねたにまじれすかっこわる、ですが。
原文を読んできました。
今まで唯一の"IT屋"という状況からして、全て一人でやってきたのでしょう。
そのため、要求仕様を一番理解できる立場であるでしょうから、SEに徹して、実際の作業は外注化するのが唯一デスマ化を防ぐことができる方法でしょう。

ただこれを機に、大規模開発の経験を積みたいということなのであれば、原文のコメントにもある通り、必要最低限の知識だけを学んでいくのが良いでしょうね。
デスマは避けられないと思いますが、そうやって経験をつまない限りは、知識や手法は身につきませんから。

＃自分？この舟には乗りません。

IT ITしないプロマネ

[Anonymous Coward]

IT屋向けではないプロジェクトマネジメントをするべきでしょうね。
ほんとITの世界で確立したマネジメント術は、そうじゃない人に理解してもらうのは結構難しい...

なので本から学ぶにしても、著者が自分のいるところの業界に近い人のものがいいかも？

# とタレコミ人の立場に近いAC、こっちが教えてほしいくらいだ。

Re:

[Anonymous Coward]

断言するのは早漏^h^h早計。

「今まで…いなかった」という事は、
ＩＴ屋が増員された可能性もあるわけで。

Re:やめとけ

[firewheel (31280)]

新人の優秀なIT屋がバリバリこなしているのなら、
彼がこんな悩みを抱えることは無かったであろう。

Re:やめとけ

[narunaru (30931)]

仕組みがない所に、いきなりプログラマだけ増員したら、崩壊するのは確実なわけで・・・・
最近はPMだけを外注で受ける会社もあるらしいので、本当はそういう所に依頼して、その仕事っぷりを見て学習するとかがいいと思う。

プロジェクトマネジメントというものを、

[Anonymous Coward]

妹に例えるといい。そうすれば自然と解決法が見つかると思う。

Re:プロジェクトマネジメントというものを、

[ddc (14170)]

俺のプロジェクトがこんなに順調なわけがない！

Re:プロジェクトマネジメントというものを、

[snurf-kim (10835)]

＞妹に例えるといい。そうすれば自然と解決法が見つかると思う。

仮想化すれば幸せになれるんですね！

Re:プロジェクトマネジメントというものを、

[Gedachtnis (37928)]

＞妹に例えるといい。

実は妹が三児の母になっていたりするにだが,,,,

＞そうすれば自然と解決法が見つかると思う。

つまり惨事の母と？

Re:

[Anonymous Coward]

「煩雑で喧しく鬱陶しいので関わり合う事を避ける」ですね。わかります。

Re:プロジェクトマネジメントというものを、

[yukichi (12361)]

「理想と現実の違いを知れ」という意味では?

Re:

[Anonymous Coward]

12 とおりもあるの?

Re:プロジェクトマネジメントというものを、

[Anonymous Coward]

最近は15人に増えましたけど何か？

# 姉3+同い年1+妹15

Re:

[Anonymous Coward]

多人数の妹の同時攻略をいかにして行うかを考えれば、
自ずと分かるということか。

マーフィーの法則

[Anonymous Coward]

「技術的な判断と経営者的な判断が対立した場合、技術的な判断は常に無視される。」

例：
経営者「このシステムを3ヶ月でサービスインしろ。」
技術者「無理です。これを作るのには、どうみても1年はかかります。」
経営者「新人を追加して人数を倍にしてやる。だが3ヶ月は絶対に死守しろ。
　　反論は許さない。お前に許されたセリフはＹＥＳだけだ。」

Re:マーフィーの法則

[ryu-2 (9699)]

反論を封じるのは前時代的です。

ここは紳士的に、
「返事は、“はい”か“ＹＥＳ”で答えて下さい。」
と言うべきでしょう。

Re:マーフィーの法則

[Anonymous Coward]

いいえッス

Re:マーフィーの法則

[Anonymous Coward]

淑女的、の間違いでは？

Re:マーフィーの法則

[firewheel (31280)]

どう答えますか？ YES/NO

ＹＥＳ：おめでとう！あなたはこのデスマーチプロジェクトの責任者になりました。
    今後もプロジェクトマネージャとして酷使されることになります。

ＮＯ：おめでとう！あなたはこのプロマネの任を解かれ、デスマーチプロジェクトの
　一開発者になりました。今後も開発者として酷使されることになります。

Re:マーフィーの法則

[127.0.0.1 (33105)]

(Yes / yes)

Re:マーフィーの法則

[tarosuke (2403)]

TOC的には「このシステム」の仕様と3ヵ月の理由を探り出して理由の方を満足させるような方法を考える。というところかなぁ...。
# 具体性は視野狭窄を引き起こす。というのが前提。

Re:マーフィーの法則

[nim (10479)]

サービスインの日付が、実は来年のものだった、ということにします。
もし、年まで出てしまっていたのなら、実は皇紀で表示していた、ということにします。

Re:マーフィーの法則

[vn (10720)]

それじゃあ時蕎麦だよ。

無題

[Anonymous Coward]

> おしえて ! えろ^Hらいひと ! 部門より。

つまんねえ。reo は2ちゃんねるにでも行けよ。

Re:

[schwarz (28506)]

というか，この「^H」って何なの？

Re:

[Anonymous Coward]

CTRLキーを押しながらHキーを押す
表記用法等はご自分でお調べください

Re:無題

[likeamagic (32922)]

スラドをOperaで見てるんですが、いきなりOperaが消えました。
アクティブになったPowerPointでやってみたら置換画面になりました。
IEでは履歴が表示されるようです。

#違うモンですねえ。

ばっくすぺーす

[Anonymous Coward]

「えろいひと」と言い切っちゃうのがねらーだ。
取り消し線で消すのがブロガーだ。
そして「^H」で消すのがよく訓練された/.erだ。

Re:ばっくすぺーす

[alpha_246net (10584)]

パソコン通信出身者にはアタリマエの表現だったと思うんだが・・・
他にもプレーンテキストの中にエスケープシーケンス混ぜ込んで
行頭まで戻すとか、ベルコード入れといて読む人を驚かすとか・・・

1. ていう昔話を知らない
   → 時代も変わったモンだねぇ・・・
2. アスキーコード0x08を^Hと表記することを知らない
   → そう言えば、最近あまりこういう表記はしない気がする。CTRL+Hとか書くのが多いんじゃね？
3. アスキーコード0x08がバックスペースコードであることを知らない
   → /.erとしては勉強不足

ってところでしょうか？

--
♪潔くカッコよく生きてゆこう

まぁそう言うな。

[Tatenon (20311)]

今だと２ＣＨやスラドに貼られてるＡＡがいきなりアニメーションするくらい
遊べる機能だったんだから。

# エスケープシーケンスだけで画面作ったこともあったなぁ。（遠い目）
## そうやって考えると、今時の掲示板って面白みに欠けるなぁ。
# 確認不足で投入した奴のせいで、画面が元に戻らなくなることも多かったけどな。

Re:まぁそう言うな。

[alpha_246net (10584)]

＞# エスケープシーケンスだけで画面作ったこともあったなぁ。（遠い目）
チャットの画面が逆スクロールしたときには何事かと思いましたよ(おなぢく、遠い目)

＞## そうやって考えると、今時の掲示板って面白みに欠けるなぁ。
HTMLタグ使い放題な掲示板だと、<!-- ここに罵倒文句 --> なんてやって遊んでますが(ひどい奴だ)

--
♪潔くカッコよく生きてゆこう

Re:まぁそう言うな。

[Tatenon (20311)]

・・・いちいちソースまで見る奴居んの？

# 見つけて欲しければそれとなくヒントくらい書いておくものだ
## それでも気づかない奴は気づかないけどな。

Re:ばっくすぺーす

[alpha_246net (10584)]

はっはっは。おぢいちゃんの言うことはまだ難しかったかな？
おまえも大きくなったら分かるよ。

ってな気分になったのはナゼ？orz

--
♪潔くカッコよく生きてゆこう

Re:ばっくすぺーす

[alpha_246net (10584)]

＞おじいちゃんだからさ。

ロートルなのは自認してるんだから、もうちょっとヒネろうよ(^^;;

せめて、『おぢいちゃん、ご飯はさっき食べたでしょ』くらい
言ってもらわないと、それこそ『つまんない、おもしろくない』ですよぉ

--
♪潔くカッコよく生きてゆこう

Re:ばっくすぺーす

[reo (4042)]

どうでもいい。つまんない。

いやー、ねぇ ? こういうコメントつけられるとさ、ぎゅんぎゅん萌えますよね。

--
Hiroki (REO) Kashiwazaki

Re:ばっくすぺーす

[Anonymous Coward]

そして「C-h C-h」で (help-for-help) してしまうのがあまり訓練されていない Emacs-er だ。

# そして「いやぁ、 vi メインなもんで…」と取り繕おうとするのが，訓練されていない vim-er だ。

Re:30人以上コメントつけてて

[narunaru (30931)]

参考書を渡されただけで万人が滞りなくプロジェクトを管理できるなら、そもそもPMBOKなんかも生まれなかっただろう。PMBOKが存在することが「PMBOKを読んだだけでマネジメントが出来るようになる」なんてことがないということを表しているんだよ。

そもそもPMってITエンジニア向けのスキルじゃないからね。PMの主な仕事はは折衝とか、予算管理とかなんだからさ。ITエンジニアが一人しかいないなら、プロジェクトに関連しそうな部署から部長補佐でもやってるやつを引っ張ってくる方が現実的。

フレームの元（信じた人だけ救われる。)

[firewheel (31280)]

そう。まさに「フレームの元」。

プロマネがPMBOK信者だったりすると本人だけは救われますが、
プロジェクトは綺麗に炎上します。

Re:30人以上コメントつけてて

[galag (37512)]

PMの経験が無い人がPMBOK読んでも何の役にも立たないだろうね。
PMBOKとは指南書とか参考書とかじゃなく、PMの知識を体系的にまとめた本だから。

PMBOKガイドの第1の目的は、プロジェクトマネジメント知識体系のうち、
良い実務慣行と一般的に認められている部分を特定することである。
この場合、「特定する」とは、あますところなく記述するということではなく、
一般的な概要を示すことを意味する。（PMBOK 第3版より抜粋）

個人的には、PMBOKは「PM知識について頭を整理する本」として使ってる。

実際のプロジェクトではチラリと参照する程度にすると、忘れちゃいけないこととか、
間違っちゃいけないこととかいろいろ思い出せるからすごく役に立つよ。

Re:偉い人には相談するな。

[kicchy (4711)]

＞「読破したら感想を聞きたい」とのお言葉でした。

まずは読む時間を作りたいので
プロジェクトの終わらせ方を教えてください。

# それは、足利義満流？