プロマネ現場読本

読書記録

 HOME > 読書 > プロマネ現場読本


プロマネ現場読本


プロマネ現場読本
デスマーチを乗り切るために持っておくべき知識のすべて


著者: 坂本直紀
出版社: 翔泳社
サイズ: 単行本
ページ数: 339p
発行年月: 2008年10月

概要

できるプロジェクトマネジャーは問題が大きくなる前に、危機を察知し、適切な対処ができる。
現場で培われた智恵の結晶でさらなるスキルを磨く。
WBS、提案依頼書、開発提案書、プロジェクト計画書、スケジュール表など現場ですぐに使えるテンプレートを満載。


目次

プロジェクトマネジャーになろう
基礎編 プロジェクトマネジャーになるための準備
 システム開発の基礎
 ビジネス活動として捉えるシステム開発
 プロジェクトマネジメントの基礎
実践編 事例で学ぶプロジェクトマネジメント
 提案活動
 全体計画
 要件定義
 基本設計
 実装
 結合テスト
 システムテスト
 受入支援
 次のプロジェクトへ
 シネジョイ座席予約システム提案依頼書
 座席予約システム開発提案書
 座席予約システムプロジェクト計画書

memo

------------------------------------------------
[2009/3/13(金) 5:08] P.339/339
   ⇒【6日(月〜土)で読破するためには、一日に57ページのペースで読む必要がある。】
   ⇒【P.298〜338の付録は価値あり。コピーしておくと良いかも。】
   ⇒【関係ないが瑕疵対応で検索してたら偶然見つけたリアルですマーチのブログ:http://katsu-note.blogspot.com/2007/08/blog-post_21.html】
------------------------------------------------
[2009/3/12(木) 5:15] P.213/339
   ⇒【6日(月〜土)で読破するためには、一日に57ページのペースで読む必要がある。】
   ⇒【P.298〜338の付録は価値あり。コピーしておくと良いかも。】
   ⇒要件と仕様の違い
    ・要件:ユーザーがシステムに期待する要求。
    ・仕様:要件や設計について、ユーザー企業と開発ベンダーとが合意した内容。
   ⇒構成管理ツール:Subversion(CSSやVSSのようなもの)
    ・チェックインルール:単体テストを通ったソースコードをチェックイン
    ・ブランチ作成ルール:カットオーバー前は、ブランチしない。
    ・タグ打ちルール:各工程の終了時と納品時、カットオーバー時にタグを打つ。
   ⇒チームワークの醸成:ゴールと息抜きの共有が有効。
------------------------------------------------
[2009/3/11(水) 5:12] P.161/339
   ⇒【6日(月〜土)で読破するためには、一日に57ページのペースで読む必要がある。】
   ⇒【P.298〜338の付録は価値あり。コピーしておくと良いかも。】
   ⇒スコープ管理計画
    ⇒要件のトリアージとサインオフ。
     ・トリアージ:個々のシステム要件を優先順位付けすることによって、システム要件を取捨選択する要件定義の手法。
      ⇒もともとは災害医療の分野で使われている言葉。
      ⇒災害によって大量の傷病者を症状に応じていくつかのレベルに分類し、救命措置の優先順位をつける行為。
      exp)
       Aランク:今回の開発で必須の要件
       Bランク:今回の開発でなるべく実現したい要件
       Cランク:先送りして良い要件
     ・サインオフ:要件定義工程や基本設計工程の中で作成するドキュメント成果物(工程成果物のうち、要件定義書や基本設計書などの各種ドキュメント)
      に対して、ユーザー企業担当者がその内容を確定すること。
      (英語意味:文章の執筆を終わらせること。)
   ⇒Tracはバグのデータベース、バージョン管理、wiki間のハイパーリンク情報を提供する。 また、Subversion、Git、Mercurial、Bazaarといったバージョン管理システムへのウェブインターフェースも提供する。またテスト管理システムTestLinkとも連携可能。 現在のバージョンのTrac(0.11以降)では、フロントエンドにGenshiというテンプレートシステムを用いている。0.10以前はClearSilverというテンプレートシステムを標準で利用していた。    ⇒下請法:下請け代金支払遅延等防止法:納品後60日以内に支払いを済ませないといけないなどのルール。
   ⇒定量的な見積り方法:ファンクションポイント法
    ⇒システム見積りのための実践ファンクションポイント法:児玉公信著:日本能率協会マネージメントセンター刊、2006年
     ⇒【今までの実践では積み上げ見積りしかしていないので、それでは概算見積りとなり精度が低いので、この本で学習すべき】
------------------------------------------------
[2009/3/10(火) 4:24] P.114/339
   ⇒【6日(月〜土)で読破するためには、一日に57ページのペースで読む必要がある。】
   ⇒【P.298〜338の付録は価値あり。コピーしておくと良いかも。】
   ⇒開発プロジェクトにおける二つのスコープ
    ・プロジェクトスコープ:プロジェクトの中で実施すべき「作業」の範囲
     ⇒要件定義から受入支援までのなかで実施する作業の範囲
      ⇒WBSを利用する。
    ・プロダクトスコープ:プロジェクトの成果物が満たすべき「機能や特性」の範囲
     ⇒要件定義の中で定義するシステム要件
      ⇒機能要件、非機能要件、インフラ要件
   ⇒見積り方法
    ・積み上げ法:要件が明確でない場合は、KKDの積み上げ法で。精度向上には複数人数で同一の見積りをたてて検証する。
    ・ファンクションポイント法
   ⇒TBA:To Be Assigned
   ⇒提案書には「弊社の理解」を入れておくと効果的。
------------------------------------------------
[2009/3/9(月) 5:10] P. 59/339
   ⇒【6日(月〜土)で読破するためには、一日に57ページのペースで読む必要がある。】
   ⇒アジャイル:俊敏:システム要件が曖昧でユーザー企業と試行錯誤しながら開発を進める必要がある場合に効果あり。
    ⇒イテレーション:開発を反復的に何度も繰り返りて行う場合に、一回分の繰り返しのことを言う。
   ⇒請負契約、準委任契約。
    ⇒「準」委任契約でない、委任契約は法律行為の委託に対して適用されるが、法律以外の事務処理の委託に対しての適用は準がつく。
     ⇒システム開発は法律行為ではないので準委任契約となる。
    ⇒一括請負契約とは、要件定義〜受入支援までの全ての作業をまとめて一つの請負契約で締結する。
   ⇒基本契約:個々の個別契約の中に請負契約や準委任契約が含まれる
    ⇒複数の契約を継続的に契約する可能性がある場合、例えば初期開発、二次開発、三次開発を行う場合など、
     初期開発は個別契約であり、その個別契約の中で要件定義と受け入れ支援は準委任契約、基本設計からシステムテストは請負契約とする場合などがある。


関連項目

・デスマーチ



ひゅうじ ぺーじ
Huge Page

HOME

プロフィール

サイトマップ

リンク


カスタム検索