[IPA] デスマらないために「超上流から攻める IT 化の原理原則17ヶ条」が思った以上に使える件 [要件定義] | oshiire*BLOG
「超上流」という言葉自体はとても気に入らないけれども、IPA 独立行政法人 情報処理推進機構 が作って公開している「超上流から攻める IT 化の原理原則17ヶ条」が、当たり前のことを当たり前に並べてあってとても役に立つ。 原理原則 17箇条 ユーザとベンダの想いは相反する 取り決めは合意と承認によって成り立つ プロジェクトの成否を左右する要件確定の先送りは厳禁である ステークホルダ間の合意を得ないまま、次工程に入らない 多段階の見積りは双方のリスクを低減する システム化実現の費用はソフトウェア開発だけではない ライフサイクルコストを重視する システム化方針・狙いの周知徹底が成功の鍵となる 要件定義は発注者の責任である 要件定義書はバイブルであり、事あらばここへ立ち返るもの 優れた要件定義書とはシステム開発を精緻にあらわしたもの 表現されない要件はシステムとして実現されない 数値化されない要
![[IPA] デスマらないために「超上流から攻める IT 化の原理原則17ヶ条」が思った以上に使える件 [要件定義] | oshiire*BLOG](https://cdn-ak-scissors.b.st-hatena.com/image/square/bfb41ba2bfefb166491d5d3e83380136f2017ab2/height=288;version=1;width=512/http%3A%2F%2Foshiire.to%2Fwp-content%2Fuploads%2F2015%2F01%2F17principles-300x212.png)
何がプロジェクトの成否を分けているのか？
大プロジェクトの成否は、多くの場合会社の命運を握る。そのため、会社のエースを投入し、莫大なコストと時間をかけて挑むものの、必ず成功するものでもない。どちらかと言うと、大きなプロジェクトほど失敗の方が多いのではないだろうか。では、何がプロジェクトの成否を分けているのか。本稿では長年プロジェクトマネジメントに携わってきた筆者が成功のポイントを紹介する。 筆者は長らくコンサルタントとして国内外・規模の大小を問わずプロジェクトに携わってきました。 その中で、成功するプロジェクトもあれば、残念ながらそうではないプロジェクトも目にしてきました。今回は「何がプロジェクトの成否を分けるのか？」と、それを考えるヒントとして、各々のプロジェクトに見られる共通項を紹介したいと思います。 まだまだ、行き当たりばったりの日本のプロジェクト これは、ある日本の大手製造業の企画部門にお勤めの方と会話していたときの話しで
プロジェクトマネジメントスキル 実践養成講座
エンジニアとしてキャリアアップを考える際、ぜひ身に付けておきたいのがプロジェクトマネジメント（PM）のスキルだ。特に近年のシステム開発プロジェクトは低予算化・短期化が進んでおり、ただでさえ計画どおりにプロジェクトを運営することは困難になっている。こうした中、多くの現場で「経験のあるプロジェクトマネージャが不足している」という声を聞く。 しかし、PMスキルを実際に習得するとなると、これがなかなか難しい。ちまたにはPMBOK（Project Management Body Of Knowledge）をはじめとするPM関連の本があふれ、体系的に学習できる素材はそろってきた。しかし、実践的なものは少なく、理論と現場のギャップに戸惑うことも多々あろう。 そこで、この連載では実際の現場でよく見られるシチュエーションを取り上げながら、PMの実践的な勘所をケーススタディ形式で紹介していく。これからプロジェ
それは知識ですか、スキルですか、資質ですか？ | タイム・コンサルタントの日誌から
東大で大学院生にプロジェクト・マネジメントを教えていたら、「自分は計画を立てるのが元々あまり上手ではないが、どうしたらいいでしょうか」という質問を受けた。プロジェクト計画の立案、とくにその中心になるＷＢＳの作り方について説明し、二人一組でちょっとした演習をした後のことだ。WBSを作るだけなら誰にでもできるが、良いWBSを作るのは、案外難しい－－そういう話をしたら、出てきた質問だった。 秀才タイプの人は、自分の弱点を人前にさらすのをきらう。だから逆に、この率直な質問には好感がもてた。わたしは学生にこう聞いてみた。 －－失礼だけど、あなたは英語の会話は得意ですか? 相手はちょっと質問の論点から外れたことに戸惑ったようだが、答えた。 「えっと・・、いや、苦手です。」 －－じゃあ、得意になるためにはどうしたらいいと思いますか。 「うーんと。やっぱりたくさん練習するしかない、ですか?」 －－そう。そ
プロマネのハードスキルとソフトスキル | タイム・コンサルタントの日誌から
「ハードスキル」と「ソフトスキル」という用語をはじめてきいたのは、2003年のことだったと思う。米国で参加した会議におけるPMコンサルタントの講演で、この区別を知った。プロジェクト・マネジメントに携わる人間のスキルを、「ハード」と「ソフト」に二分する思考方法は、そのときまで私の中には無かった。 米国の思考法は、つくづく「分けていく」思考法だな、と思う。分類し、分析し、分業する。全体を部分に細分化して、それぞれの特徴・特性を多面的に把握する。そして目的合理性の見地から、それらを使い分け、組み合わせていく。だから道具立ては専門分化したツールの集合体になる。PMBOK Guideの構成を思い出してほしい。まるでゴルフバッグに入ったクラブの束みたいだ。あるいはナイフとフォークを何本も並べるフルコースの食事のようだ。（これに対し日本人は最初から最後まで一膳の箸だけですませる。最小限の道具だけで何でも
プロジェクト・マネージャの「やってはいけない」---目次 - プロジェクト・マネージャの「やってはいけない...：ITpro
プロジェクト・マネジメントのアンチパターンを徹底解説 プロジェクト・マネジメントにはセオリーがある。セオリーを知らずに，あるいは軽視して，失敗するプロマネは少なくない。現場でたたき上げたベテランの凄腕PMが，現場でプロマネがやってはいけないことを解説する。 関連サイト： ■メール編 ■やる気編 ■要件定義編 ■会議編 ■報連相編 ■協力会社対応編 ■品格編 ■課題管理編 ■変更管理編 ■コミュニケーション編 ■外注管理編 ■姿勢・資質編 ■計画＆進捗管理編 ■品質編 ■姿勢編 理由無き要求は機能化してはいけない プロジェクト事務局を軽視してはいけない 過去の成功体験にとらわれてはいけない 自己研鑽を怠ってはならない 目的を忘れてはいけない ■プロジェクト完了編 完了条件をあいまいにしてはいけない 完了報告会を省いてはいけない 成功・失敗要因を不明確なままにしてはいけない フィードバックを忘
Part1 あなたは作成できますか？
WBSを作成する際には，思い込みや楽観的な予測を排除し，抜け・漏れのないように作業を定義する必要がある。加えて，WBSで規定する作業内容は適切な粒度まで分解し，記載する表現は分かりやすく，そして目指すべきゴールにたどり着けるものでなければならない。WBSの作成は，未知のプロジェクトを“先読み”するということでもある。定石がないだけに，WBSの作成には特有の難しさがある。 実際，WBSの作成はどれくらい難しいのか。これを検証するために，Part1では雑誌「日経SYSTEMS」の読者4人の協力を得て2009年11月末，ある例題を解いてもらった（写真1）。みなさんもぜひ，WBSの作成に挑戦してほしい。 提案作業をWBSとして定義する ここで取り上げる例題は，提案作業に関するWBSを作成するものである（図1）。ある日，あなたのもとに提案依頼が舞い込んできた。内容は「プロジェクト・マネジメント（PM
Microsoft Projectの代替ソフトウェアとしてプロジェクト管理が可能でガントチャート表示もできるフリーソフト「OpenProj」
Windows、Mac、Linuxのいずれでも動作が可能で、JRE1.5以上がインストールされていれば問題なく利用できるのがこの「OpenProj」。ガントチャート、ネットワークダイアグラム、WBSとRBSチャート、レポートの印刷とPDFによる出力、コスト計算などなど、プロジェクト管理に必要なほとんどの機能が備わっています。 また、Microsoft Projectのファイルを開いたり保存することも可能です。ただのビューワーではなく、実際に編集できるのでかなり便利。メニューなどはほとんど日本語化されており、抵抗なく使うことができます。 ダウンロードとインストール、実際の表示などは以下から。 Home | Serena Open Source and Hosted Project Management Software http://openproj.org/ 今回はWindows用を使うの
あるＳＥのつぶやき: プロジェクト管理メモ
プロジェクト管理はオンラインの情報だけで学べるものではないとは思いますが、情報がなくならないようにメモしておきます。 ■プロジェクト管理 プロジェクトマネジメント入門：ITpro プロジェクトマネジメント連載記事インデックス プロジェクトマネジメントの理論と実践：ITpro 計画部分を重視したプロジェクトマネジメント連載記事インデックス プロマネ最強マニュアル---目次：ITpro プロジェクトの火消し方法解説記事インデックス プロジェクト・マネージャの「やってはいけない」---目次：ITpro プロジェクトマネジメントアンチパターン解説記事インデックス なぜプロジェクトは失敗するのか インデックス － ＠IT自分戦略研究所 プロジェクト失敗理由の連載記事インデックス EnterpriseZine：コーナー：実務で役立つプロジェクトレビューの心得 リスク管理などのプロジェクト管理解説記事イ
「プロジェクト・ブック」はスゴ本
建築デザイナー向けだが、システム屋のわたしにも効果大のスゴ本。 本書は、建築タイポロジーの解説ではないし、建築デザイン・テクニック集でもない。仮に本書が建築デザインについての形式論・類型論だったなら、わたしにとって、何の役にも立たないだろう。 しかし、デザイナーとしての才能やテクニックに関係なく、つくるキモチに焦点を当てている。たとえば、場のつくりかた、発意の仕方、他者との共有方法を理解することで、どういう瞬間にプロジェクトが「まわって」いるかを感じとれる。いちいち具体的で、かつ、そのままITプロジェクトにハマる。 デザインプロジェクトに効く63のキーワードと、現場の会話ログを追いかけるうちに、プロジェクトを「まわす」のに建築もシステムも大差なく見えてくる。つくる「モノ」は違えども、つくる「コト」は同じなのだから。 ■1 場所をつくる 大きなテーブル、広い壁、ライブラリー、気持ちのいい椅子
わたしの7つの「ふりかえり」
[チームリーダーは「アジャイルレトロスペクティブズ」から盗め]の続き。わたしの「ふりかえり」をふりかえってみる。 ■01 定期的に、ふりかえる 実は、定期的なふりかえりは、したことがない。たいていは、プロジェクト終了直後や、さらにずっと後になって、「あんな時代もあったね」と語ることはあっても。ただし、「笑って話せる日」は絶対こない。笑わず小声で真剣に「あの二の舞だよ」、あるいは「まだ学習してへんのかッ」と刺す。 そういうチーム運営を定期的にふりかえる必要性に気づいただけでも、本書に感謝しないと。 まずいチーム運営は、トラブルという見えやすい形でフィードバックをもらっていた。メンバーの不満や、作業プロセスのボトルネック、品質チェックの不備は、プログラマの喧嘩や明白なサボタージュ、収拾のつかないバグズライフに化す。 そして、「トラブルの対処」という形で皆の不満を吸い上げたり、手順書を見直したり
わたしが知らないスゴ本は、きっとあなたが読んでいる: チームリーダーは「アジャイルレトロスペクティブズ」から盗め
「なんで、こんな非効率なやり方なんだ?」この疑問、よくあるどころか毎日だ。 たとえば、情報がうまく共有されていないとか、ある人がボトルネックになっているとか。不平を言うと「じゃぁオマエがやれ」と押し付けられるので、最近では不言実行で最適化を図っている[参考]。 あるいは、評論家になっていっぱしのクチをきくが、現場を変える努力も勇気もないくせにブログで薀蓄たれ流す。ネット弁慶カッコワルイ（誰とはいわんが、わたしも含まれるので自戒）。 たしかに、「前と同じやり方」で仕事は回るが、「やり方」が改善されないまま。成果物はレビューされるが、仕事のプロセスはレビューされない。かくして非効率性は引き継がれ、不満は澱のように溜まってゆく。 こいつをなんとかする試みが、「アジャイルレトロスペクティブズ」。舌噛みそうな名前で、サブタイトルの「『ふりかえり』の手引き」というほうがピッタリだね。 つまり、プロジェ
わたしが知らないスゴ本は、きっとあなたが読んでいる: プロジェクトは冒険だ！「仕事を100倍楽しくするプロジェクト攻略本」
薄くて濃い一冊。 プロジェクトを「まわす」にあたり、本当に必要な内容だけを吟味してまとめてある。ある意味、いさぎよい。頁数を水増し→煽り文を追加→ハードカバーにして、2倍の値段で売っているそこらのビジネス本と180度違う。テクニックよりも心得を重視しており、トム・ピーターズのように読んだ側からソノ気にさせる。 プロジェクトは冒険だ、そして、キミは勇者だ。王さまの話を聞き、仲間を集めてパーティーを編成し、レベルアップに勤しみ、最高のクリアを目指す――なんのことはない、昔っからゲーム相手にしてきたことと一緒。 あのときの「ワクワク感覚」そのままに、プロジェクトの現場を捉えなおしてくれる。この視点はありそでなかった。いちいち激しく頷きながら読む。 本書のエッセンスは、デマルコの「マネジメントの4つの本質」に尽きる。「デットライン」に、こうある。 適切な人材を雇用する その人材を適所にあてはめる
第1回 20年は遅れているITプロマネ | 日経 xTECH（クロステック）
近年，システム開発のプロジェクトマネジメントについての関心が高まっており，プロジェクトマネジメントに関する資格を取る人も増えています。しかし，そのために「システム開発の失敗事例が減ってきた」という話はあまり聞きません。 システム開発プロジェクトは，建築やプラント建設，船や工作物などの機械組み立てのプロジェクトと比べて，失敗事例があまりにも多く，納期どおりに完成する例は多くありません。実際，日本情報システム・ユーザー協会（JUAS）の「ユーザ企業IT動向調査 2006」でも，500人月以上の大規模プロジェクトでは相変わらず5割近くで工期遅れ，4割近くで予算超過が発生しています。スケジュールが遅れ，その結果としてコストが増加することが当然と受け取られています(図1）。 図1●プロジェクトは基本的に成功するもの プロジェクトは，プロジェクト・マネジャーがしっかりと顧客とメンバーを把握して，品質（
わたしが知らないスゴ本は、きっとあなたが読んでいる: プロジェクトを成功させる魔法の言葉
あいにく銀の弾丸の持ち合わせはないが、うまくいくプロジェクトでよく使われていた言葉は確かにある。耳にしたときは聞き流していてた言葉を、この本は思い出させてくれた。ここでは、そんな「魔法の言葉」を紹介する。 ネタ元は「目標を突破する実践プロジェクトマネジメント」。ふつう、図書館で読んだ本はそれっきりだが、こいつは買って周りにばら撒く。薄くて分かりやすくて、すぐにやってみようという気にさせるところがいい。 ■ もし、問題があるとすれば、それは何ですか? 朝会や進捗会議で「何か問題はありませんか?」という質問はよくするしされる。けれども答えはいつも決まっている→「特にありません」。でもって、不具合が起きると、「あのとき聞いたのにッ」←→「こうなるとは思ってなかった」となる。 身に覚えない? これを、冒頭の質問にしてみると、アラ不思議、いくらでも出てくる。「問題ない?」には無反応だったのが、「これ
有能なプロジェクトマネージャを育てるには（3）
前回、前々回に引き続き、2007年問題ともいわれているノウハウ継承の問題について、特にプロジェクトマネジメント能力の育成に焦点を当てて考えていく。今回は特にプロジェクトの運営について考える。 団塊世代が組織から去りつつあるいま、プロジェクトマネージャの量的不足・能力不足を懸念する企業が多い。3回目となる今回は、前回、前々回に引き続きシステム開発のプロジェクトマネジメント能力育成について考える。 少ない経験を生かす仕組み作り プロジェクトマネージャの量的・質的な問題が懸念される中で、育成に必要な「経験の場――適当な内容や規模のプロジェクトがなかなかない」という問題を抱えている会社が少なくない。数少ない経験の機会を有効に生かせる手立てが求められている。 経験を生かす人とそうでない人 同じような仕事を担当して、同じような課題や問題に遭遇し、同じような経験をしてきたはずの人たちの間において、年月と
有能なプロジェクトマネージャを育てるには（2） ― ＠IT情報マネジメント
前回に引き続き、2007年問題ともいわれているノウハウ継承の問題について、特にプロジェクトマネジメント能力の育成に焦点を当てて考えていく。今回は特にPMBOKの使用法などについて考える。 団塊世代が組織から去りつつあるいま、プロジェクトマネージャの量的不足・能力不足を懸念する企業が多い。2回目となる今回は、前回に引き続きシステム開発のプロジェクトマネジメント能力育成について考える。 システム開発プロジェクトマネジメントでPMBOKを参考にすると PMBOKは教科書ではなく参考書 プロジェクトマネジメントに関する知識というと、「PMBOKを教科書にして勉強しよう」という方がときどきおられる。PMBOKは、いろいろな分野で行われる“プロジェクト”という仕事のやり方を分析能力にたけた人が整理し、プロジェクトマネジメントの一般的・共通的な枠組みとして整理したものだ。 少し極端ないい方をすると、「共
有能なプロジェクトマネージャを育てるには（1）
団塊の世代が定年を迎えようとしている。しかし、団塊の世代が持っているノウハウは若い世代に受け継がれているのだろうか。今回から3回にわたって、2007年問題ともいわれているノウハウ継承の問題について、特にプロジェクトマネジメント能力の育成に焦点を当てて考えていく。 団塊の世代が組織から去りつつある現在では、プロジェクトマネージャの量的不足・能力不足を懸念する企業が多い。システム開発のプロジェクトマネジメント能力の育成について、今回から3回にわたって考えてみる。 問題とその背景 団塊の世代が歩んできた道 団塊の世代を中心にその前後を形成する世代は、日本企業のIT化の進展とともに、その中で能力をはぐくんできた。この世代の人たちが社会で活躍を始めた1970年代は、日本企業が本格的に情報システム化に取り組みだした時期でもある。 オンライン化やデータベース化などにより、情報システムが業務の形態を抜本的
わたしが知らないスゴ本は、きっとあなたが読んでいる: ウォーターフォールはこう使え（まとめ）
この連載を始めたのは、Waterfall 2006を見たから。ついカッとなって書いてしまった。今は反省している。この連載は体系的じゃないし、blog よりむしろ出版物の形で問うべき。何よりも、今週の睡眠時間を大幅に犠牲にしてきたので、眠くてたまらん。 …というわけで、ここでは総括＋補足して締める。 ウォーターフォール・モデルとは、プロジェクト構造化モデルと言い換えられる。その特徴として、以下のことが挙げられる。（その1） プロジェクトを構造化し、段階を踏んで要素成果物を構築する 次に、必要な要素成果物を適切なタイミングで持ち寄り、組み上げる 要素成果物を構築する工程はスパイラル・モデルを適用できる。しかし、組み上げる工程は逐次的であることが求められる プロジェクトを構造化することにより、プロジェクトを「見える化」できる。全体と部分、出来てるところと空白のところが分かる。未確定事項がオープン
わたしが知らないスゴ本は、きっとあなたが読んでいる: ウォーターフォールはこう使え（その5）
ウォーターフォールの怨嗟の的になっているのは「ドキュメント」だろう。使うかどうかも分からぬような大量のドキュメントを書かされる。しかも顧客の一言で大幅に書き直しを命ぜられる。さもありなん。だが、ここでは、ウォーターフォール・モデルにおけるドキュメントの必要性を強調する。 ドキュメント＝契約書 なぜドキュメント化が嫌われるのか? SEの立場から言うと、ちゃんと検討していないまま、「とりあえず」ドキュメント化をさせられるから（結果、後から手直しが多発する）だろう。PGの立場からすると、理解してコードに落とすだけの内容を、なぜ語弊の出る日本語に書き直さなければならないか、疑問に思うだろう。 本当の問題はSE/PGがドキュメントを書いていること。あるいは、片手間にドキュメントを書いていることをなんとかすべき。本来なら専門部隊を準備するか、リソースを明示的に割り当て、執筆期間を設ける必要がある。 こ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
