![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
#author("2024-05-04T21:08:46+09:00","default:irrp","irrp") #author("2024-11-03T20:04:57+09:00","default:irrp","irrp") →プロジェクト管理 →職業としてのエンジニア #contents *PM一般 [#b93bdb73] -[[「子会社系SIer」で深刻化する“忙し過ぎ問題” 最も不足している意外なIT人材とは？ - ITmedia エンタープライズ>https://www.itmedia.co.jp/enterprise/articles/2405/02/news053.html]] 2024.5 -[[PMOに「向いている人」と「向いていない人」の特徴 | Think IT（シンクイット）>https://thinkit.co.jp/article/22865]] 2024.3 -[[あなたはプロジェクトリーダー（PL）に向いている？5つの特徴でチェック - paiza開発日誌>https://paiza.hatenablog.com/entry/2022/07/22/130000]] 2022.7 --計画に従って着実に実行していくことが好き --問題発生時に適切にエスカレーションできる --メンバーとの関係構築がスムーズにできる --共感力が高く、メンバーを思いやれる --ある程度の技術的スキルがある -[[プロジェクトマネージャーの本来の役割とその業務 | Think IT（シンクイット）>https://thinkit.co.jp/article/19479]] 2022.4 --「プロジェクトマネジメントは、基本的にプロジェクトの初期段階で、可能な限り明瞭かつ丹念な準備を行い、プロジェクト進行中は準備したものを忠実に遂行し、準備した際の想定と異なる自体が発生したら、速やかに原因究明と対策を施す」という基本思想は絶対に破らないということです。この基本思想を破ると、プロジェクトはほぼ失敗します。どれほど優秀な人間でも、沢山の人が関わるプロジェクトにおいて、問題が顕在化する度に対処し、解決していくことは不可能です。そのため、プロジェクトマネジメントでは徹底的に準備とその遂行に力点を置くのです。優秀なプロジェクトマネージャーと仕事をしたことがある方なら分かるかも知れませんが、優秀なプロジェクトマネージャーがプロジェクトの初期の段階において、メンバーがそれほど忙しくないのに1人だけ深夜まで残って仕事をしていたりしませんでしたか。また、プロジェクトが佳境を迎え、大量にプログラムを生産するようになると、神経質なほど遅れや品質懸念に気を遣っていませんでしたか。それらは、正にプロジェクトマネジメントの基本思想を順守しているためなのです。 -[[プロジェクトマネジャーが知るべき97のこと>https://プロジェクトマネジャーが知るべき97のこと.com/]] -[[存在しているだけで役に立つもの>http://brevis.exblog.jp/22448195/]] 2014.10 --冗長化したバックアップ機というものは、本来は普段、何の仕事もしていない。だが、それは価値があるのだ。なぜなら、いざというときに、システム全体が倒れずにすむからだ。機能していなくても、存在するだけで価値があるもの。それは目の前にあったではないか。その価値は、すべてが正常に動いている普段は、まったく目に見えない。しかし、いざというときになると役に立つのだ。プロジェクト・マネジメントというものもよく似ている。順風満帆なときは、別に大した仕事はしていない。物事が難しくなったり環境が急変したときに、その真価が現れるのだ。つまり、リスク環境下でこそ、マネジメントの価値は測れるのである。 -[[新人プロジェクトリーダ向け。チームとプロジェクトを動かす１０のポイント>http://getlife.hateblo.jp/entry/2014/03/18/031542]] 2014.3.18 --１．チームメンバーが仕事ができないと思ってイライラしてはいけない --２．依頼や説明は丁寧すぎるぐらいがちょうどいい --３．自分でやったほうが早い、は危険 --４．とりあえず半歩先を見る --５．数字にこだわりすぎない --６．上手く上の人を使う --７．熟考と弱気は違う --８．リーダーになっても相談は忘れずに --９．自分色を出すのはまた来年 --１０．法律は覚えておこう -[[曖昧なプロマネ権限と責任がプロジェクトを炎上に導く>http://getlife.hateblo.jp/entry/2014/01/27/024443]] 2014.1.27 --営業と開発チームが分離した製販分離の開発体制の場合、時折「プロジェクトリーダ」に該当する役割を「プロジェクトマネージャー」って呼んでる --戦略的受注のため、営業の無理な案件受託のため、意図せずデスマにならざるを得なかったプロジェクトリーダは、炎上プロジェクトの責任を負うべきか、という話になるのですが、これはNoだと思います --例えば、プロマネが気を利かせてリーン開発とウォーターフォール開発を組み合わせて、顧客側の仕様検討のブレに対するリスク回避しようとしても、そもそもリーン開発を選択できる権限が「プロマネ」に与えられてないわけです。 --これじゃあ、開発手法で工夫してプロジェクト炎上を防ぐなんて夢のまた夢です。 -[[ITエンジニアのチームリーダーシップ実践講座>http://jibun.atmarkit.co.jp/lskill01/index/index_tl.html]] 2013.6 -[[父親に聞いた管理職として「ダメなチームをデキるチームにする必勝パターン」>http://docs.komagata.org/5011]] 2012.12.22 -[[Structured Approachができる人、できない人>http://brevis.exblog.jp/18336958/]] 2012.8.12 -[[『プロジェクト・マネジャーが知るべき97のこと』――ソフトウェア開発の難問はいつだって“人”だった>http://el.jibun.atmarkit.co.jp/bookshelf/2012/01/post-88db.html]] 2011.12 --考えてみれば当たり前なのだが、ソフトウェア開発においてもっとも難しいのは、設計でもプログラミングでもデバッグでもなく「合意すること」なのである。 --ソフトウェア開発プロジェクトでは、こういった「人間の厄介さ」が集約するハブとして「PM」というポジションがあるのだ。 --それであれば、本書に「主張の衝突」が少ないことにも納得がいく。人間関係の問題とは、「すでに解決策が分かっており、そしてそれを実践するのが困難」なものだからだ。 -[[マネージャ層の技術が遅れている>http://forza.cocolog-nifty.com/blog/2009/04/post-042e.html]] 2009.4.17 -[[リーダーシップについて思い出したこと>http://satoshi.blogs.com/life/2005/09/post_1.html]] --私が米国のマイクロソフトで働き始めてまだ日が浅い頃、ソフトウェアの開発に関連して似たような言い訳をビルゲイツの前でした人間がいたのだが、その瞬間にビルゲイツは机を叩いて真っ赤になって怒り始めたのだ。この場面にビルゲイツがいたとすれば、こんな感じになる。 --ビルゲイツ： （机を激しく叩いて）市側が十分なバスを手配してくれなかっただって？バカなことを言ってるんじゃない。市側が適切な対応をしなかったら、市長の首をねじ上げててもバスを手配させるのがお前の仕事だろう。それでも市が動かなかったら、隣の市からバスを借りて来るなり、軍にトラックを手配させるなりして、何としてでも市民を非難させるんだ。 --Fema： しかし、市も軍も私の指揮権の及ぶところではありませんから… --ビルゲイツ： （ますます真っ赤になって怒って）指揮権がなんだっていうんだ。人の命がかかっているんだぞ。軍に要請を出して動いてくれなかったら、大統領に電話して命令を発動してもらうのがお前の仕事だろう。何のためにお前に高い給料を払っていると思ってるんだ。 -[[ITマネージャの犯しやすい10の失敗>http://builder.japan.zdnet.com/news/story/0,3800079086,20390263,00.htm]] --1: 事業よりも技術を重視する --2: 「目に入らないものは気にもならない」式の考え方 --3: チームに任せた仕事を確認しない --4: 自分が期待していることを点検しない --5: 事業部門の責任者と協力関係を作らない --6: 自分を消耗させてしまう --7: バックアップソリューションのテストをしない --8: 助けを求めない --9: 自己啓発に時間をかけない --10: メンターやコーチを見つけていない -[[PMは座っていてはいけない>http://itpro.nikkeibp.co.jp/article/COLUMN/20080507/300868/]] 2008.5.23 -[[プロマネよ奮起せよ!そしてベンダーは彼らを救え>http://itpro.nikkeibp.co.jp/article/Watcher/20071005/283908/]] 2007.10.22 -[[プロマネに送る泰蔵の一日一句>http://itpro.nikkeibp.co.jp/article/COLUMN/20070925/282819/?ST=management]] 2007.10.9 -[[PMはひとりじゃない>http://itpro.nikkeibp.co.jp/article/OPINION/20070920/282639/?P=2&ST=ep_infrastructure]] 2007.9.25 --PM懐疑論：PMを強調しすぎると一番大事な価値の創造がおろそかになる、という考えについて --結局は手法より組織の質が重要という… -[[日本型PMの特徴>http://itpro.nikkeibp.co.jp/article/COLUMN/20070406/267598/]] 2007.4.19 --権限の所在があいまいで，業務が定型化されていない。誰も傷つけない玉虫色の決着が好まれ，個人の突出は許されない――。こうした日本のプロジェクトをうまくまとめて，破綻なくゴールさせるのは並大抵のことではない。欧米のプロジェクトマネジメント手法では無理が出てくる。 --日本型のスゴイPMの平均が，PM全体の平均より特に優れているシステム関連スキルは， ---「情報戦略策定」 ---「ビジネスモデル定義」 ---「ITプロセス管理」の3つである。 -[[実録プロジェクトマネージャー>http://itpro.nikkeibp.co.jp/article/lecture/20070313/264658/?ST=lecture&P=1]] 2007.3.19 -[[みなさん，プロマネになりたいですか？:http://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20050513/160793/]] --プロマネになりたい若手は減っている --実態は『現場の便利屋』に近い。何の権限もないのに，トラブルの責任だけは負わされる --「プロジェクトの内容はどんどん高度になるのに，与えられた期間は短くなる一方。それなのに，会社は昔の感覚で『現場の裁量の範囲で工夫して乗り切れ」というばかり。PMO（プロジェクトマネジメントオフィス）はあるけれど，細かな報告を要求するばかりで，イザというときはもまったく役に立たない」 --問題の根底には，アウトソーシングなどに伴い，顧客側のプロジェクト推進力が落ちていることがあるという -[[「プロジェクト・マネジャはギリギリのところで働いている」:http://itpro.nikkeibp.co.jp/free/NC/NEWS/20050308/157166/]] --顧客のプロジェクトマネジメント能力が落ちている --所属する組織（企業）の支援を得るのが困難 --PMを支えるスタッフが足りない --求められる能力や責任に対して、報酬が安すぎる *プロダクトマネージャー(PdM) [#x9f624b5] -[[「私考える人、あなた作業する人」の関係をつくっているのはあなたかもしれない - AGILE-MONSTER.COM>https://agile-monster.com/blog/i-am-the-thinker-you-are-the-worker/]] 2023.3 -[[プロダクトマネージャーの業務マップを作りました - inSmartBank>https://blog.smartbank.co.jp/entry/2023/03/28/110000]] 2023.3 -[[エムスリーが誇る最強のプロダクトマネージャー育成環境：プロダクトマネージャー定例 - エムスリーテックブログ>https://www.m3tech.blog/entry/2022/12/25/203858#%E3%81%AA%E3%81%9C%E3%81%93%E3%81%AE%E6%96%B9%E6%B3%95%E3%81%8C%E6%9C%80%E5%BC%B7%E3%81%AA%E3%81%AE%E3%81%8B%E5%85%AC%E9%96%8B%E5%BE%8C%E8%BF%BD%E8%A8%98]] 2022.12 -[[エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド>https://qiita.com/hirokidaichi/items/95678bb1cef32629c317]] 2021.8
