タグ

PMと重要に関するshozzyのブックマーク (9)

  • 「最悪の事故」から学ぶ教訓 : 小野和俊のブログ

    「最悪の事故が起こるまで人は何をしていたのか」では、チェルノブイリ原発事故、スペースシャトル・チャレンジャー爆発墜落事故をはじめ、潜水艦の沈没や航空機墜落事故、石油プラットフォームの爆発や橋の崩落といった巨大事故が実際に起こってしまった事例と、事故が起こる直前にい止めることができた事例を通じて、事故を生み出してしまったシステムや体制、組織の規律やそこで働く人のメンタルな状態など、さまざまな切り口から事故の原因が考察されていく。 普段の生活において、自分のちょっとしたミスがこのような大事故につながるような場所に身を置いている人はそれほど多くないかもしれない。しかし、書で述べられている内容のうち、事故の原因とそこから学ぶ教訓の部分について目を向けてみると、私たちが日常的に接しているような場面においても同じように当てはまる内容があまりにも多いことに驚く。 書には実に数多くの教訓が含まれてい

    「最悪の事故」から学ぶ教訓 : 小野和俊のブログ
  • ミスとかトラブルとか - 最速配信研究会(@yamaz)

    UIEUEIのid:shi3zさんがミスについての話を書いておられる(会社名間違えてました.大変失礼しました. > shi3zさん). 部下が致命的なミスをするのは全面的に上司の責任 1行でまとめると「ミスは必ずおきるので,ミスを事前に検知する仕組みが必要だよ」ということなんだけど,私も前職ではありとあらゆるミスやトラブルに遭い,それに対して思うところがあるので,どう対処してきたかを書いてみようと思う. このエントリは長くなりそうなので,先に「今来た3行」でまとめるとこんな感じになる. ミスやトラブルはありとあらゆる隙間を縫っておきるので,確率的なものととらえる方がいいよ. ミスやトラブルがおきた時の影響を最少にするためにはミスやトラブルを検知することの他に,「そもそもそんなミスが起きえないようにする」,「万一そのミスがおきても大丈夫なようにする」為の仕組み作りが重要だよ. 根性論に頼るの

    ミスとかトラブルとか - 最速配信研究会(@yamaz)
  • 最適な工期は「投入人月の立方根の2.4倍」、JUASが調査 ― @IT

    2007/07/05 日情報システム・ユーザー協会(JUAS)は7月5日、ユーザー企業102社の357プロジェクトを調査した「ソフトウェアメトリックス調査2007」を発表した。システム開発の企画、開発計画に始まり、保守や運用管理まで実態を調査した内容で、企業情報システムの実態を伝える。調査結果からは“デスマーチ”となるプロジェクトの実態も浮かび上がった。 デスマーチ化するプロジェクトの条件の1つは工期の設定が不適切であることだろう。調査から導き出された標準開発工期は「投入人月の立方根の2.4倍」。調査対象のプロジェクトの全体工数と全体工期をグラフ化し、回帰直線によって求めた。この計算によれば1000人月のプロジェクトの場合は24カ月の工期を設定するのが標準的といえる。事情によってこの標準工期よりも短い工期しか取れない場合は、その短縮率を計算して対策を採るべきとJUASは提言。だが、「(短

    shozzy
    shozzy 2007/07/07
    今のプロジェクトは…無茶ではないらしいw ということは、きつく感じるのは掛け持ちの弊害か。/↓立方根だから、9人月なら4.99ヶ月くらいになりますよ。30%短縮で3.49人月。
  • なぜCCPMなのか | ビーイングコンサルティング

    プロジェクトの納期を守るための効果的な管理手法「CCPM(クリティカルチェーン・プロジェクトマネジメント)」。 現在プロジェクトの複雑化やサービスの多様化によって、プロジェクト管理の現場ではプロジェクト遅延やコスト増大・品質低下など深刻な問題が発生しています。 それにより、既存のリソースでより高いパフォーマンスを発揮できるCCPMに注目が集まっています。 しかし、CCPMがどのようなものか理解できていない方もいるでしょう。 記事ではCCPM導入のメリットや導入手順をわかりやすく解説します。 プロジェクト管理に悩んでいる方はぜひ参考にしてください。 導入編:このようなことありませんか? プロジェクト管理に頭を悩ませる田ヌ田部長ですが、プロジェクトの進捗など現場の状況をきちんと把握できていないため、的確な指示が出せません。 それにより、プロジェクトが納期に間に合わないなど現場では大きな混乱が

    なぜCCPMなのか | ビーイングコンサルティング
  • プロマネ必読!「アポロ13」

    「アート・オブ・プロジェクトマネジメント」で強くオススメされてたので読む ―― これはスゴい。ドキュメンタリーとして夢中になって読めるだけでなく、プロジェクトが危機に陥ったときの「べき/ベからず集」しても、ものすごく有効な一冊なり。 どうしようもない状況、限られた時間、非常に高いリスク、疑わしい解決策…プロジェクトがパニックに瀕したとき、優れたプロジェクトマネージャは何を考え、どう行動するかを知ることができる。書を通じて学んだ危機管理マネジメントは、次のとおり。 プロジェクトが危機的状況のとき、あらゆる手段を使って、自分の感情をコントロールせよ。感情は事実をゆがめ、判断を誤らせ、解決への手段の一つ一つに邪魔をする 「危機」は、すぐに数字にならない。必ずタイムラグが発生している。だから、危険な数値が今出ているということは、既に危機的状況に突入している、ということだ 問題に対処するとき、絶対

    プロマネ必読!「アポロ13」
    shozzy
    shozzy 2007/01/10
    「問題に対処するとき、絶対に忘れてはいけないのは、「いつメンバーを休ませるか」だ」
  • 「SIerよ! リスクを取れ」と言っても、リスク管理ができてなければ・・・

    少し前の話だが9月20日に、日立情報システムズが9月中間期の業績予測を下方修正した。なんでも連結経常利益が従来予想より15億円下回る32億円となり、増益見通しから一転減益となるという。まあ業績予測の下方修正なんか日常茶飯事だから、投資家でもなければ大した話ではないのだが、「将来を見据えたチャレンジングな案件で躓いた」といった趣旨の説明を見つけ、あれっと思った。 ITサービス会社も今、リスクを取るべき時だ。プロジェクトの失敗を過度に恐れるあまり、ガチガチの管理ばかりをやっていては未来がない。そんな話を以前書いたことがある。だから、チャレンジングな案件に挑戦して失敗するのは、ある程度は仕方がない。だが、経営トップが投資家に頭を下げなければいけない業績予想の下方修正となると、ちょっと穏やかではない。「ほら見たことか」という声も聞こえてきそうである。 で、少し詳しく話を聞いてみた。中堅・中小企業向

    「SIerよ! リスクを取れ」と言っても、リスク管理ができてなければ・・・
  • 真髄を語る 経営者がITを理解できない本当の理由

    佐藤正史 氏 JTB情報システム 代表取締役社長 当サイトにおいて、企業情報システムにかかわってきたベテランが引退する、いわゆる「2007年問題」について色々な議論がされております。私は1971年にJTBに入社して以来、ほぼ一貫して情報システムの仕事に従事してきました。私が情報システムに関係してきた期間は、日における約40年の企業情報システムの歴史と概ね重なっております。 2001年から取締役(情報システム担当)として、CIO(最高情報責任者)の仕事をし、現在はJTBの情報システム関連会社の社長を務めています。おそらく、あと数年で2007年問題の一方の主役として、この舞台を去ることになるでしょう。まもなく企業人生を終えようとする一介のシステム屋ではありますが、ぜひとも多くの方に申し上げたいことがあり、この場を借りて思うところを綴ってみます。 私は今、日ITを巡る状況に大変な危機感

  • プロジェクトチームのリーダーに向く人、向かない人 ― @IT情報マネジメント

    チームで遂行されるプロジェクトにおいて、優秀なリーダーの存在は極めて重要です。そこで今回から、リーダーについて考えてみることにします。リーダーシップの具体的な技術に関してはコーチングなどの記事を参考にしていただくことにして、ここではもっとベーシックなところをターゲットにします。なお対象としては、ユーザーサイドに限らずプロジェクト一般についての話となります。 誰でも持っているリーダーの素質 よく話題になることに、リーダーにはリーダーとしての素質がなければならないのか、ということがあります。ある程度の素質は必要でしょうが、それは大多数の人が持っているはずです。そのように考えられる根拠はあります。 例えば、ふさわしい人が地位に就くのではなく、「地位が人を育てる」ケースはよく知られています(年功序列主義の会社ではよく見られることです)。これは、リーダーとして特別な素質がないと思われたり、思い込んだ

    プロジェクトチームのリーダーに向く人、向かない人 ― @IT情報マネジメント
  • アジャイルだとリファクタリングが必要な理由&アジャイルする意味をなくす営業・PMの態度 - ウィリアムのいたずらの、まちあるき、たべあるき

    ウィリアムのいたずらが、街歩き、べ物、音楽等の個人的見解を主に書くブログです(たま~にコンピューター関係も) アジャイルが使われる多くの理由は、「仕様が固められない」という部分が多いと思う。 あ、あとは、できるのを見ないと怖いとか。。 っていうことで、アジャイルではじめる場合、初めから「共通部分を抜き出して」ということをやれないケースもあるし、やると危険なケースがおおい。 話が進んでいったら、「ぜんぜん共通じゃないじゃーん!!」っていうことになり、その部分を作り直しとなったりするから。 オブジェクト指向な人は、「そーいう部分のために、派生があるんです」というとおもうけど、派生する意味ないくらい、共通じゃない(見た目は共通だけど、中身は共通じゃない)というケースがあるので、やっぱ、オブジェクト指向を採用しても、共通化すると、作り直しになってしまったりする。 てなわけで、いったん全体を作って

    アジャイルだとリファクタリングが必要な理由&アジャイルする意味をなくす営業・PMの態度 - ウィリアムのいたずらの、まちあるき、たべあるき
  • 1