パスワードを忘れた? アカウント作成
87095 story
ソフトウェア

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

ストーリー by reo
おしえて ! えろ^Hらいひと ! 部門より

pinbou 曰く、

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

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

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

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 一つ言えるのは (スコア:5, すばらしい洞察)

    by duenmynoth (34577) on 2009年04月23日 12時19分 (#1553939) 日記
    一つ言えるのは「自分は作業しない事」ですね

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

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

    問題はそんなに役割分担できるほど人材というか人数がいるかどうかですが・・・
    • by Anonymous Coward on 2009年04月23日 12時38分 (#1553953)

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

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

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

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

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

      親コメント
      • Re:一つ言えるのは (スコア:1, すばらしい洞察)

        by Anonymous Coward on 2009年04月23日 12時53分 (#1553969)
        それをやると、成果物に漏れが発生するので。
        成果物定義とWBSと、要素の完了確認は必要だと思います。
        (精度が悪くても、定期的に修正すれば、無いよりまし。)
        欲をいうと、絶対に考慮漏れ要素とボトルネックが発生するので、 工期に対して作業を均一に振らないことでしょうか。
        親コメント
      • by BlueRain (37857) on 2009年04月23日 23時48分 (#1554276)
        >>「船頭多くして船陸に上がる」
        船頭がおおけりゃ船でさえも陸に上がれる。
        もっと大勢いれば宇宙にだって行けるさ。
        ということですよね。

        そういう私は毎日Excelを眺めて進捗報告してました。ソフト系じゃないけど。
        たくさんいる船頭さんにお世辞を言ったりごまをすったり頭を下げたり。
        それでも仕事が進んでくれるからいいや。
        その船頭さんたちもみんな自宅待機という名の切り捨て状態です。
        親コメント
    • by CowardDuck (25674) on 2009年04月24日 0時28分 (#1554293)

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

      これはとっても正しい。

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

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

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

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

      • 後から値切る。
      • 設計段階を過ぎてから仕様変更する。
      親コメント
  • by tiga (4391) on 2009年04月23日 14時01分 (#1554025) 日記

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

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

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

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

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

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

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

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

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

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

  • 本家より (スコア:4, 参考になる)

    by hohehohe (11394) on 2009年04月23日 16時47分 (#1554104)
    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がいろいろあれば非常に小さなものを選びなさい。
        意見の不一致が多すぎればもう1つか2つあなたにできるものを選びなさい(ちょっと訳おかしいかも)。

        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
    • by hanap (14297) on 2009年04月23日 18時37分 (#1554178)

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

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

      親コメント
  • やめとけ (スコア:3, すばらしい洞察)

    by Anonymous Coward on 2009年04月23日 11時34分 (#1553905)

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

    その職場では無理。

    • Re:やめとけ (スコア:3, 興味深い)

      by macintrash (30773) on 2009年04月23日 12時40分 (#1553955)
      ねたにまじれすかっこわる、ですが。
      原文を読んできました。
      今まで唯一の"IT屋"という状況からして、全て一人でやってきたのでしょう。
      そのため、要求仕様を一番理解できる立場であるでしょうから、SEに徹して、実際の作業は外注化するのが唯一デスマ化を防ぐことができる方法でしょう。

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

      #自分?この舟には乗りません。
      親コメント
    • by Anonymous Coward on 2009年04月23日 11時54分 (#1553924)

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

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

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

      親コメント
    • by Anonymous Coward
      断言するのは早漏^h^h早計。

      「今まで…いなかった」という事は、
      IT屋が増員された可能性もあるわけで。
  • by Anonymous Coward on 2009年04月23日 11時31分 (#1553904)

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

  • by Anonymous Coward on 2009年04月23日 11時35分 (#1553907)

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

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

  • 無題 (スコア:0, おもしろおかしい)

    by Anonymous Coward on 2009年04月23日 12時25分 (#1553943)
    > おしえて ! えろ^Hらいひと ! 部門より。

    つまんねえ。reo は2ちゃんねるにでも行けよ。
    • というか,この「^H」って何なの?
      • by Anonymous Coward

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

        • by likeamagic (32922) on 2009年04月23日 16時13分 (#1554092)
          スラドをOperaで見てるんですが、いきなりOperaが消えました。
          アクティブになったPowerPointでやってみたら置換画面になりました。
          IEでは履歴が表示されるようです。

          #違うモンですねえ。
          親コメント
    • by Anonymous Coward

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

      • by alpha_246net (10584) <{alpha} {at} {246.ne.jp}> on 2009年04月23日 13時00分 (#1553979)

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

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

        ってところでしょうか?

        --
        ♪潔くカッコよく生きてゆこう
        親コメント
      • Re:ばっくすぺーす (スコア:2, おもしろおかしい)

        by Anonymous Coward on 2009年04月23日 13時12分 (#1553991)

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

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

        親コメント
typodupeerror

あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall

読み込み中...