テーマ:プロジェクト

初田賢司「ユーザーのためのシステム開発の見積もり評価」

FPのエキスパートが参加したシステム開発の見積もりとその評価を進める基本的考え方が綺麗にまとめられている。 機能要件はFPを活用して規模を見積もる。 非機能要件、技術要件、プロジェクト特性によって、生産性は変わるから、FPの生産性を調整する方法もあるが、筆者もIFPUGもFP調整はしない。 開発後、機能要件だけで予実対比ができるよ…
トラックバック:0
コメント:0

続きを読むread more

Scott W.Ambler「ディシプリンド・アジヤイル・デリバリー」は、素晴らしい本!

ディシプリンド・アジャイル・デリバリー(DAD)プロセスフレームワークは、「IT Solution Deliveryのための、人を最も重視した学習指向のハイブリッド型アジャイルアプローチである。 このフレームワークは、”リスクと価値によるライフサイクル”に基づき、ゴール駆動型で、スケーラブルであり、企業の基幹を支えるソフトウェアにも対応…
トラックバック:0
コメント:0

続きを読むread more

Dora_Papaのプロジェクトマネジメント(15)「閑話休題 「見通し」について 」

ジェームズ・C・コリンズ「ビジョナリーカンパニー③衰退の五段階」を読んでいたら、ふたつの面白い一節にであった。 「実際のところ、とくに危険な状況になるのは、明確で議論の余地のない事実を無視した時ではなく、データがどちらにも解釈できるが、悪い方向に振れた時に深刻な結果か悲惨な結果になりうる状況で、曖昧なデータを間違って解釈したときで…
トラックバック:0
コメント:0

続きを読むread more

日経コンピュータ「システム障害はなぜ二度起きたか」は「動かないコンピュータ」の続きだ

第一部と第二部では、みずほ銀行のトラブルの経緯と原因について述べられている。 筆者、日経コンピュータは、おそらく日頃の「公憤」をもろにぶつけ、真の原因は、経営陣のITに対する理解不足、IT軽視にあると断定している。 それは恐らく正しいだろう。 内容的には、この業界にいる人間にとっては、とくに新しい話はない。 ただ、みずほ銀行のト…
トラックバック:0
コメント:0

続きを読むread more

福島原発 失敗プロジェクト、あるいは、戦前の日本の、デジャブ

シニカルなのではない。 福島原発の対応は、いったんトラブルになってしまったプロジェクトの対応がいかに大変か、身につまされる。 日本的プロジェクトの典型例ともいえるのではないか。 あるいは、満州事変以降の日本全体の空気のようだ。  ①現場が死に物狂いでやっているのに、「上」は、遠くの「本社」で責任問題に明け暮れしている。 ②ゴ…
トラックバック:0
コメント:0

続きを読むread more

Dora_Papaのビジネスアナリシス(28)「BAケーススタディ(17) 要求マネジメ」

P社経営企画のH氏とS君は、社長の指示を受けて、ビジネスアナリシスを開始し、プログラムの承認を得るところまで来た。 プログラムの立ち上げは、プログラムマネジャーにすっかり依存していた。 事務局としては多忙ではあったが、ビジネスアナリストとしては、特に立ち上げに際して、何もすることはなかった。  プログラムの進行にともない、企画段階…
トラックバック:0
コメント:0

続きを読むread more

Dora_Papaのプロジェクトマネジメント(14)「D51章 プロジェクト計画作成にあたって」

「プロジェクト計画」は、プロジェクトを成功裏に運営するために、最も重要なアクティビティのひとつという認識がある。 しかし、その認識は、どの組織でも正しいとは限らない。 ベンダーの場合、プロジェクト計画が、プロジェクトにおけるコントロールの開始にあたるので、大変重要だが、ユーザーの場合、それも、あまり、マネジメントやコントロールになじまな…
トラックバック:0
コメント:0

続きを読むread more

Dora_Papaのプロジェクトマネジメント(13)「R章 RFPの作成と評価」

 RFPの作成についてガイドする本は、増えてきた。 もっとも完成度が高いと思われるのは、「ベンダーマネジメントの極意」だが、プライムコントラクター向けというべきで、普通の中堅企業には、そのままでは使えない。 他の本も残念ながら印象が薄い。  もっともRFPの作成や評価には、それほどの難しさはないから、印象に残る本がなくても不思議で…
トラックバック:0
コメント:0

続きを読むread more

小原重信 他「プロジェクト・バランス・スコアカード」は、残念ながらよくわからない

PMBOKに慣れ親しんでいるせいか、私の頭のせいか、この「プロジェクト・バランス・スコアカード」は、残念ながら、よく理解できなかった。 確かに、BSCはいろいろ応用のきく便利な考え方だと思う。 しかし、P2Mの価値評価にBSCを考えるのは、若干、私には違和感がある。 BSCがあるから使うというだけで、価値評価に最適だからBSCを使うとい…
トラックバック:0
コメント:0

続きを読むread more

「プロジェクトマネジメント 成功するための仕事術」は、本物だ

東洋エンジニアリング(TEC)は、プラントエンジニアリング会社として、プラント構築というプロジェクトマネジメントに秀でている。 40歳台前半で数百億円もするプロジェクトのマネジャーに任ぜられ、組織的にプロジェクト・マネジメント力を育成してきた。 EVMなども、ITプロジェクトよりずっと前から実施している。 EVMは「プロジェクトを…
トラックバック:0
コメント:0

続きを読むread more

Dora_PaPaのプロジェクトマネジメント(z章) 閑話休題 プロジェクトX

 数年前、NHKで放映されていた「プロジェクトX」という番組は、中島みゆきの主題歌と共に大変人気が高かった。 私も番組開始早々は結構好きで、あまり見ないテレビのなかでは、結構楽しんでいたのですが、自分も多少知っているあるプロジェクトが紹介されたとき、あまりに劇的な要素ばかりが強調されているのに辟易し、それから徐々に批判的に見るようになり…
トラックバック:0
コメント:0

続きを読むread more

Dora_Papaのプロジェクトマネジメント(12)「要件定義とインフラ基盤」

要件定義(Requirement Definition)は、当然のことに、ビジネス、業務の要求から始る。 いわゆる機能要件の聞き出し、つめ、文書化、検証・・・を、おこなうため、インフラ基盤の検討が、(シリアルにやれば)どんどん遅れてゆく。業務側の機能要件が全部でてこないのに、インフラの要件がでてくるはずもない、というのも真実だし、…
トラックバック:0
コメント:0

続きを読むread more

Dora_Papaのプロジェクトマネジメント(11)「C章. 会議体と会議について」

 伝統的な日本企業は、「プロセスの代わりに会議をしている」とは、私の持論である。 プロジェクトについても、それは同様だ。 プロセスを好まない企業のプロジェクトは、長い会議ばかりすることとなる。 文化は修正しようがないとして、どう、会議を効率的にするかを考えよう。 会議について、勇ましい両極端の意見がある。   ・ 「何時に…
トラックバック:0
コメント:0

続きを読むread more

Dora_Papaのビジネスアナリシス(9)「要求マネジメント④ Elicitation 」

「Elicitation」と言う言葉は、BABOKで初めて使われた言葉ではない。 Karl  E. Wiegers の "Software Requirements" でも、要求の引出しに使われていると記憶している。 そういう意味では、BABOKの知識体系のひとつに"Elicitation"があることは、不思議ではない。 しかし、BAB…
トラックバック:0
コメント:0

続きを読むread more

Dora_Papaのプロジェクトマネジメント(10)「附1.外部委託のセキュリティ」

 個人情報保護法の施行の時期あたりから、この数年、プロジェクト・マネジャーにとって、セキュリティは、避けてはとおれない、面倒なイッシューになっている。 プロジェクトの立ち上げ、計画時に、やっておくことがある。 まず、委託先企業との機密保持に関する契約。 一般に使われている契約書の雛型を使えばよいのだが、機密保持に関する契約での問題…
トラックバック:0
コメント:0

続きを読むread more

Dora_Papaのプロジェクトマネジメント(9)「D5章 プロジェクト計画レビュー」

 「終わりよければすべてよし」ではなく、最初が肝心。 しかし、日本の多くの中堅ユーザー企業は、ここがむずかしい。 計画的に進めて、あわよくば期限前に稼動しようなどという発想はない。 なにしろ現業とかけもちの人ばかりだから、メンタリティとしては、期限ギリギリに、なんとか帳尻を合わせる発想が多い。 計画して計画に従って進めることが、とても苦…
トラックバック:0
コメント:0

続きを読むread more

Dora_Papaのプロジェクトマネジメント(8) 「E章プロジェクトキックオフ」

よほど無理して開始したプロジェクトでないかぎり、プロジェクトのスタート時は、多くの人が、成功を期待し、成功させられると自然に考えている。 しかし、どんな場合でも、範囲、体制、期間などに、多少の懸念を抱えている人はいるものだ。 とくに、ユーザーからみて、急遽、集められた、初めて付き合うベンダーの場合は、どんな人がやってくれるのだろうか…
トラックバック:0
コメント:0

続きを読むread more

トム・デマルコ「アドレナリン・ジャンキー」

ソフトウエア開発の数ある本のなかで、トム・デマルコの著作ほど、「そうだ、そうだ」と思う本はすくない。 トム・デマルコ「アドレナリン・ジャンキー」(日経BP社 2009.10.26)も、やはり、たいへん楽しい本だ。 しかし、トム・デマルコの言葉は、どうして、こうも、日本のプロジェクトや組織にもぴったりな話が多いのだろう。 国柄や文化を問わ…
トラックバック:0
コメント:1

続きを読むread more

Dora_Papaのプロジェクト・マネジメント(7) 「D4章 マスタースケジュールとWBS」

 プロジェクト計画の時点でも、マスタースケジュールは必要で、誰もが作成するが、WBS(Work Breakdown Structure)までは、なかなか作らない。 WBSは、この業界では当たり前のものと考えていたが、意外にそうでもない。 WBS嫌いの人も少なくないので、作らないことが多い。 立上はじっくり戦略的に、計画的にやりたい。 し…
トラックバック:0
コメント:0

続きを読むread more

Dora_Papaのプロジェクトマネジメント(5)「D2章 プログラム立上げ-スコープと体制」

 プログラム/プロジェクト立上げ・計画に際して、リスクマネジメントは欠かせない。 「欠かせない」と言うのは、大抵、欠けるからだ。 なぜ、大抵欠けるかといえば、「リスクマネジメント」というと、リスクの識別から始めなければいけないと思って、ひどく形式的な結果になると予想するからなのだ。 そのとおりで、教科書どおりのリスクマネジメントも必要だ…
トラックバック:0
コメント:0

続きを読むread more

Dora_Papaのプロジェクトマネジメント(4) 「D章 プログラム立上げ」

 筆者のベンダー時代、プロジェクトを数多く見てきた。 数多くやってきたなら、もっと自慢しているのだが、やってきた数より見てきた数の方が圧倒的に多い。 管理者として、レビューアーとして、はたまた同僚として・・いろいろある。 プロジェクトが立ち上がり、最初のプロジェクトマネジメント計画書(PMP)が、出来終わる頃には、このプロジェクトは、ヤ…
トラックバック:0
コメント:0

続きを読むread more

オレゴン大学の絵

 要求定義などのコミュニケーションのむずかしさを漫画で示した、オレゴン大学の授業で使われているらしい、ブランコの絵です。 よく使われる漫画のようです。 システムアナリストやCIOがむずかしいひとつの理由として、比喩的に表現されます。 スポンサーによって提案されたブランコは、アナリストやプログラマーが分析、製造したものとなって、えらい違い…
トラックバック:0
コメント:0

続きを読むread more

Dora_Papaのプロジェクト・マネジメント(3) 「C章 ステークホルダー」

Dora_Papaのプロジェクト・マネジメント(3)  乱暴な話だが、日本の政治家には、どうして戦略がないように見えるのだろう。 また、ぐっと小さくなるが、日本企業の情報システム部にも、どうして戦略家がいないのだろう。 そのひとつの原因に、ステークホルダーの分析・対応能力が弱いということを挙げてみる。  「C章 ステークホ…
トラックバック:0
コメント:0

続きを読むread more

Dora_Papaのプロジェクト・マネジメント(2)「Y章 投資効果の説明」

Dora_Papaのプロジェクト・マネジメント(2) Y章 投資効果の説明に必要な、費用の把握 企画書の目的は、繰り返すようだが、投資承認の申請である。多くの企画案件を企画プロセスにのせて検討していくとき、途中で消えてゆくことは少なくない。 ビジネス環境の変化、もともと “Nice to have”の案件だった、ユーザーが経…
トラックバック:0
コメント:0

続きを読むread more

Dora_Papaのプロジェクト・マネジメント(1) 「Ⅹ章. 企画の終了」

多少、独断と偏見に満ちているが、プロジェクトは、百人百様であるということもあって、自分なりのプロジェクト・マネジメントに対する基本的な考え方をまとめてみたい。 私は、プロジェクト・マネジメントだけで飯を食っている人間ではないし、PMIには参加しているが、PMPも取得していない。 が、仕事の半分以上は、やはりプロジェクト・マネジメント…
トラックバック:0
コメント:0

続きを読むread more

プロセスがビジネスをITに結びつけるのか

 バンクーバー・パラリンピックで、金メダルを獲得する選手が現れました。 頑張った選手が結果をだしています。 私などは、結果はどうあれ、参加しただけで十分ではないかと私なら思いますが、選手にとっては、結果は当然重要なのでしょう。    プロジェクトの進捗会議で、よく予実進捗グラフが作られます。 予定や実績をどういう時点で捉えるかによっ…
トラックバック:0
コメント:0

続きを読むread more

「やってはいけない」シリーズとWBS

  2年ほど前、IT Proに「ITエンジニアのやってはいけない」が掲載されていた。 その頃は、人気ランキングでも、たいへん好評のようだった。 システム周りのことが多く、マネジメント系の話が少ないのが意外だ。 リンクは、下だが、最近でも、まだ、生きていた。 ただ、ITproに登録して居ないと見られないのかもしれない。 http:…
トラックバック:0
コメント:0

続きを読むread more

ITおじさんの昔話 - 文官と武官のたたかい -

 20年以上も前の、辛い、ある企業のITに関わる昔話ですが、いまとなっては良い時代だったのかもしれないと思います。   「文官」は、営業や経営に精通したユーザー部門の方や、システム部門に外から来たマネジメントの方のことを称し、「武官」はシステム部門生え抜きの技術職や、技術系のマネジメントの方のことを称して、お客様ご自身が語っていま…
トラックバック:0
コメント:0

続きを読むread more

共通フレーム2007 (ISO/IEC12207+α)第二版とBABOK

 久しぶりに本業の情報システムの話題。 共通フレーム2007は、IPAが進めている、ソフトウェア・ライフサイクル・プロセスの標準化だが、その第二版が昨年秋に出たことを忘れていた。 SECのメールで、知っていたはずだが、共通フレームは、超上流原理原則17条が面白いが、主たる内容には関心なかったのだ。 今回説明をきっちりお聞きして、結構使え…
トラックバック:0
コメント:0

続きを読むread more

ISO21500 プロジェクトマネジメント国際標準化

 ISO21500として、プロジェクトマネジメント国際標準化を、2012年に制定する目標で、ISOのTC236(PC236) のワーキング・グループが作業している。 その途中経過を知ることの出来るフォーラムが昨日、1/15に開催された。 九段会館が満員札止めになる盛況だった。 こんなに国際標準化に興味のある人が、沢山いるのだろうかとび…
トラックバック:0
コメント:0

続きを読むread more