プロジェクト管理

職業としてのエンジニア

  • 存在しているだけで役に立つもの 2014.10
    • 冗長化したバックアップ機というものは、本来は普段、何の仕事もしていない。だが、それは価値があるのだ。なぜなら、いざというときに、システム全体が倒れずにすむからだ。機能していなくても、存在するだけで価値があるもの。それは目の前にあったではないか。その価値は、すべてが正常に動いている普段は、まったく目に見えない。しかし、いざというときになると役に立つのだ。プロジェクト・マネジメントというものもよく似ている。順風満帆なときは、別に大した仕事はしていない。物事が難しくなったり環境が急変したときに、その真価が現れるのだ。つまり、リスク環境下でこそ、マネジメントの価値は測れるのである。
  • 新人プロジェクトリーダ向け。チームとプロジェクトを動かす10のポイント 2014.3.18
    • 1.チームメンバーが仕事ができないと思ってイライラしてはいけない
    • 2.依頼や説明は丁寧すぎるぐらいがちょうどいい
    • 3.自分でやったほうが早い、は危険
    • 4.とりあえず半歩先を見る
    • 5.数字にこだわりすぎない
    • 6.上手く上の人を使う
    • 7.熟考と弱気は違う
    • 8.リーダーになっても相談は忘れずに
    • 9.自分色を出すのはまた来年
    • 10.法律は覚えておこう
  • 曖昧なプロマネ権限と責任がプロジェクトを炎上に導く 2014.1.27
    • 営業と開発チームが分離した製販分離の開発体制の場合、時折「プロジェクトリーダ」に該当する役割を「プロジェクトマネージャー」って呼んでる
    • 戦略的受注のため、営業の無理な案件受託のため、意図せずデスマにならざるを得なかったプロジェクトリーダは、炎上プロジェクトの責任を負うべきか、という話になるのですが、これはNoだと思います
    • 例えば、プロマネが気を利かせてリーン開発とウォーターフォール開発を組み合わせて、顧客側の仕様検討のブレに対するリスク回避しようとしても、そもそもリーン開発を選択できる権限が「プロマネ」に与えられてないわけです。
    • これじゃあ、開発手法で工夫してプロジェクト炎上を防ぐなんて夢のまた夢です。
  • 『プロジェクト・マネジャーが知るべき97のこと』――ソフトウェア開発の難問はいつだって“人”だった 2011.12
    • 考えてみれば当たり前なのだが、ソフトウェア開発においてもっとも難しいのは、設計でもプログラミングでもデバッグでもなく「合意すること」なのである。
    • ソフトウェア開発プロジェクトでは、こういった「人間の厄介さ」が集約するハブとして「PM」というポジションがあるのだ。
    • それであれば、本書に「主張の衝突」が少ないことにも納得がいく。人間関係の問題とは、「すでに解決策が分かっており、そしてそれを実践するのが困難」なものだからだ。
  • リーダーシップについて思い出したこと
    • 私が米国のマイクロソフトで働き始めてまだ日が浅い頃、ソフトウェアの開発に関連して似たような言い訳をビルゲイツの前でした人間がいたのだが、その瞬間にビルゲイツは机を叩いて真っ赤になって怒り始めたのだ。この場面にビルゲイツがいたとすれば、こんな感じになる。
    • ビルゲイツ: (机を激しく叩いて)市側が十分なバスを手配してくれなかっただって?バカなことを言ってるんじゃない。市側が適切な対応をしなかったら、市長の首をねじ上げててもバスを手配させるのがお前の仕事だろう。それでも市が動かなかったら、隣の市からバスを借りて来るなり、軍にトラックを手配させるなりして、何としてでも市民を非難させるんだ。
    • Fema: しかし、市も軍も私の指揮権の及ぶところではありませんから…
    • ビルゲイツ: (ますます真っ赤になって怒って)指揮権がなんだっていうんだ。人の命がかかっているんだぞ。軍に要請を出して動いてくれなかったら、大統領に電話して命令を発動してもらうのがお前の仕事だろう。何のためにお前に高い給料を払っていると思ってるんだ。
  • ITマネージャの犯しやすい10の失敗
    • 1: 事業よりも技術を重視する
    • 2: 「目に入らないものは気にもならない」式の考え方
    • 3: チームに任せた仕事を確認しない
    • 4: 自分が期待していることを点検しない
    • 5: 事業部門の責任者と協力関係を作らない
    • 6: 自分を消耗させてしまう
    • 7: バックアップソリューションのテストをしない
    • 8: 助けを求めない
    • 9: 自己啓発に時間をかけない
    • 10: メンターやコーチを見つけていない
  • PMはひとりじゃない 2007.9.25
    • PM懐疑論:PMを強調しすぎると一番大事な価値の創造がおろそかになる、という考えについて
    • 結局は手法より組織の質が重要という…
  • 日本型PMの特徴 2007.4.19
    • 権限の所在があいまいで,業務が定型化されていない。誰も傷つけない玉虫色の決着が好まれ,個人の突出は許されない――。こうした日本のプロジェクトをうまくまとめて,破綻なくゴールさせるのは並大抵のことではない。欧米のプロジェクトマネジメント手法では無理が出てくる。
    • 日本型のスゴイPMの平均が,PM全体の平均より特に優れているシステム関連スキルは,
      • 「情報戦略策定」
      • 「ビジネスモデル定義」
      • 「ITプロセス管理」の3つである。
  • みなさん,プロマネになりたいですか?
    • プロマネになりたい若手は減っている
    • 実態は『現場の便利屋』に近い。何の権限もないのに,トラブルの責任だけは負わされる
    • 「プロジェクトの内容はどんどん高度になるのに,与えられた期間は短くなる一方。それなのに,会社は昔の感覚で『現場の裁量の範囲で工夫して乗り切れ」というばかり。PMO(プロジェクトマネジメントオフィス)はあるけれど,細かな報告を要求するばかりで,イザというときはもまったく役に立たない」
    • 問題の根底には,アウトソーシングなどに伴い,顧客側のプロジェクト推進力が落ちていることがあるという

トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2018-10-08 (月) 15:50:49 (926d)