Captcha security check coolcoding.com is for sale Please prove you're not a robot View Price Processing
HugeDomains.com
Captcha security check coolcoding.com is for sale Please prove you're not a robot View Price Processing
第64回 リスク管理がうまくいかない7つの理由（後編）
リスク管理の重要性については，頭では重要だと分かっていながらも現場のプロジェクトではなかなか真剣に取り組めていないのが実情だ。前回は，リスク管理がまじめに取り組まれない理由のうち，前半の4つの理由を見てきた。今回は，リスク管理がなぜ現場でまじめに取り組まれないのか，その残りの理由について考えていきたい。 後藤 年成 マネジメントソリューションズ マネージャー PMP 前回のおさらいとして，リスク管理がまじめに取り組まれない7つの理由を再掲します。下記の7つの理由は，最初の2つの技術的な理由と後の5つの心理的な理由に大きく分けることができます。今回は，心理的な理由にあたる［理由5］～［理由7］を皆さんと一緒に考えていきましょう。前回と同様，解決策までは言及しませんが，「ほかに理由はないのか」「あなたならどうするか」を考えながら読んでみてください。 ［理由1］リスクは一意に特定，定義できない
第63回 リスク管理がうまくいかない7つの理由（前編）
プロジェクトマネジメントの中で「重要だと知りながら，うまく実践できていないこと」の筆頭にあるは「リスク管理」だろう。取り組んだとしても，プロジェクトの初期にリスク管理表を作っておしまい，というケースが多すぎる。これでいいはずはないが，一体なぜ，そうなってしまうのか。 後藤 年成 マネジメントソリューションズ マネージャー PMP PMBOOKやプロジェクトマネジメント研修，書籍などで学習したことがある方は，必ずと言っていいほど「リスク管理」の重要性について語ります。それは皆さん周知のことでしょう。プロジェクトマネジャやPMOにとって，リスク管理は疑いなく重要な責務の1つです。 しかし，リスク管理の重要性について，頭では重要だと分かっていても，プロジェクトの現場ではなかなか真剣に取り組めていないのが実情でしょう。筆者の経験から言って，名だたるシステム・インテグレータや大手企業であっても，PM
情報漏えいが事業経営に与えるインパクト － ＠IT
前場 宏之 トレンドマイクロ株式会社 営業統括本部 コンサルティングSE部 テクニカルSE課 課長 兼 ソリューションSE課 課長 2009/9/1 情報漏えい発生――そのとき、企業にはこれだけの作業、これだけの費用、これだけの損失が発生するのです。前編「雇用形態の変化と情報漏えいの実態」に続き、情報漏えい発生のインパクトを解説します（編集部） 情報漏えい事件はいまに始まったものではない。近年はインターネットをはじめとする技術の進歩によって、映像、文字、音声などのデータがデジタル化され、瞬時に地球を駆け巡るようになっている。しかしこれは情報の拡散範囲やスピードが変化しただけであり、人が情報を盗んだり、うっかり漏らしてしまったりといった、情報漏えい事件の根本は何も変わってはいない。 今回は、情報漏えい対策を行ううえで基本となる情報の価値設定と、情報漏えい事件が企業に与える財務上のインパクト、
第54回 情報に優先順位を付ける“確かなやり方”
プロジェクト内で「鮮度」と「質」の高い情報が活発に流通するようになったら，意思決定を迅速化するために，それぞれの情報をトリアージ（優先順位付け）する必要がある。日常的に行っていることだが，情報の種類によって適切な評価基準を設定しているだろうか。みなさんの現場で実施しているやり方を点検してみてほしい。 阿部 真也 マネジメントソリューションズ マネージャー 中小企業診断士 見えないところで“病魔”がプロジェクトを蝕んでいたら大変です。前々回の『プロジェクトの“健全度”を測るモノサシ』から引き続き，プロジェクトを健全な状態に保つための取り組みについて述べていこうと思います。そのポイントの1つは，前回の『メンバーの報告・提案意欲を萎えさせるもの』で紹介したように，プロジェクト内で「鮮度」と「質」の高い情報を活発に流通させることです。 ◆情報の鮮度と質が確保されているか 問題が直ちに顕在化し，コミ
この1ヶ月のプロジェクトで学んだこと - ここではないどこか
だいぶ落ち着いてきたので、冷静になって整理してみる。 先日までとある小さなプロジェクトに参加していた。結論から話すと、そのプロジェクトは軽く炎上し、そして遅延していた。 そのプロジェクトへの参加から問題発生までの経緯はこのような感じだった。 ・とある場所から仕事の依頼（以前に先輩がそのPJに応援に行っていた経緯有） ↓ ・自分の参加が確定する（自分はそのPJの経験無） ↓ ・話を伺いに行くと「想定：1機能4日/人を想定で、計2機能」との話 ↓ ・ふたを開けてみると「導入期間なし、2機能で6日というスケジュール」 ↓ ・矛盾を感じつつも穴を埋めようと軽い過剰残業が定常化 ↓ ・遅延発生 機能実現のための想定期間はいろいろなPJや案件によって違いがあるので言及はしない。ド短期なことも気にしてはいけない。 問題だったのは「（自身の作業で）穴を埋めようと過剰残業が定常化」してしまったことだ。 それ
トラブルを報告したくなる風土を作る
最終回は、プロジェクトのリスクマネジメントを中心に解説する。それにより、トラブルを未然に防ぐ方法と発生後の対処法の基本を学んでいく。 プロジェクトを「見える化」するには、トラブル予測、予防、発見、対応の4つを行うことが大切であると、前回の「プロジェクトの肝、見える化に挑戦！」で話しました。今回はその4つについて、もう少し詳しく解説を行いたいと思います。 トラブルの予測 トラブルを予測するうえで最も重要なのが、リスクの体系化です。リスクの体系化は予想以上に多くの知見をプロジェクトマネージャに与えてくれます。 なぜならば、通常プロジェクトマネージャはリスクを、自分自身の経験の範囲内で見ることが多いのではないでしょうか。しかし、個人で見切ることのできるリスクの数は限りがあり、しかも想定外のリスクも多いのです。そこでリスクの体系化を行い、漏れなくリスクを洗い出すことで、どこに着目すればトラブルを予
機能要件は3階層で整理
上はarrowheadの全体機能と利用者や接続システムを示す「全体業務フロー図」。中は業務単位で機能間の連携をまとめた図。下は機能をさらに細分化して要件を記述したもの 最上位層に当たるのが左上の「全体業務フロー図」。arrowheadを中心に配置し、接続先システムやシステムの利用者を周辺に並べて、それらの関係性を図式化した。 全体業務フロー図の狙いは、1枚の資料でシステム全体を俯瞰できるようにすることだ。「注文処理」や「情報配信」「取引規制」などの機能群を、どの粒度でどのように分類するのが最善かを検討しやすくなると期待した。 記述が細かすぎると全体を直感的に把握できない。かといって大ざっぱすぎても意味がないので、粒度には気を配った。今回は外部に位置する接続先システムや利用者などの「アクター」と呼ぶ存在に着目して機能群を分けた。arrowheadが処理するデータはアクターから入ってくる。出力
タダ働きは「使えない」 | おごちゃんの雑文
どうやら「タダ働き」がバズってる。 バズらせてる楠君も小飼氏も、「アルファタダ働き」なんで、軽々には言ってないだろう。タダ働きの価値については、私も昔書いてるんで、同じことを繰り返してもしょうがない。 どの文章にも書いてあって、よく読まないと見えて来ないのは、タダ働きというのは 主体的な働き についてのみ肯定されているということ。つまり、「使われる」側については肯定されてないのだ。 彼等、また私が否定している「タダ働き」は、「使われること」についてのタダ働きだ。戦略的に「タダでも儲かる」あるいは「タダでやってもいい」と判断するのは、あくまでも自分が主体となっている時に限る。なぜなら、表題に書いているようにタダ働きは使えないからだ。 「金」にはいろいろな側面があるのだけど、その一つが「責任の抽象化」だ。つまり、「もらった金の分くらいは責任取れ」ということ。何らかの損害が起きた時には、「損した
問題には「現象」と「原因」がある。 - 谷本 心 in せろ部屋
突然ですが、 どんな分野においても、問題には「現象」と「原因」が存在します。 「現象」は、特定のTPOにおけるスナップショットであり、 「原因」は、そのスナップショットを構築する要素です。 そして、時に「原因」は「現象」として観察することができます。 現象）進捗が悪い ↓ 原因）予定した工数を確保できていない 現象）工数を確保できない ↓ 原因）飛び抜けて朝寝坊なプログラマがいる 現象）プログラマが朝寝坊だ ↓ 原因）自己管理ができず、夜遅くまでモンハンに興じているらしい 現象）モンハンにハマってしまう ↓ 原因）モンハンはとても面白い 現象）モンハンは面白い ↓ 原因）パーティーで狩りができる おっと、どうやら原因分析の方向を間違えたようです。 パーティーで狩りできる機能を削除することが プロジェクトの進捗を回復するための手段ではないでしょう。 現象）プログラマが朝寝坊だ ↓ 原因）自己
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ふ・・・不可能なことは不可能と言う