プロジェクト実行ガイド大全 システム開発を１００％の成功に導く

投稿元：

レビューを見る

　PMのお勉強。
　浅く広くという感じだった。

・データ移行の要件定義には見極めが必要です。
□現システムのデータがきれいかどうか
　例えば、経年のうちに項目の意味を変えて使っていることや、正しく入力していないで業務で適宜判断している場合などがある
□きれいなデータであっても、現→新マッピングが１：１になるかどうか
　新システムへの切替を機会に、項目を分離させるなど新しい業務要件が入る場合がある

　情報・コミュニケーション基盤の考え方について
「一元管理の原則」
　プロジェクトドキュメント／情報が複数ツールに分散しないこと。意味情報でくくることができる単位（例えば、要件定義書全部、設計書全部など）で異なるツールを選択することは許容。複数利用は混乱しやすく、プロジェクト生産性と品質が劣化するため排除
「重なり排除の原則」
同じドキュメント／情報が参照用にコピーされて複数ツールに存在しないこと。デグレを誘発し、コピー反映の工数をとるため排除
「全員直接アクセスの原則」
機能が充実していても全員がアクセスできない場合は選択しない。誰かの手を介して＝工数を使って参照利用となり、タイムラグが発生するため排除

投稿元：

レビューを見る

『プロジェクト実行ガイド大全』大場京子（日経BP社, 2018）
【感想】
・こちらは上の2冊よりもプロダクト寄り。開発案件を推進していくための具体的なノウハウが書かれている（テスト工程も詳しく書かれている）

投稿元：

レビューを見る

IT部門側の立ち位置でプロジェクト計画を立てるときの
考えるポイントについて触れている本。

概論を知るには良いとは思いますが、
画面設計の一部が要件定義で実施されていることは、
必ずしも一般的な進め方なのだろうか？と疑問に感じた。
ラフスケッチや必要な画面数については触れると思うが、
設計そのものは基本設計以降に行うことが多いので、
あまり一般的な進め方にはマッチしていない気がする。

こういう前提が無いと失敗するから
あえてこんな進め方を推奨している等が無いと、
違和感から入ってしまって分かりにくいかなと思った。
実際にやっているプロジェクトもあるわけで、
進め方は企業ごとプロジェクトごとに違ってよいが、
そこはさすがに書いた方が分かりやすいのにと感じた。

また、テストや移行、教育・広報系の話が
ちょっと薄い気もした。
あくまでガイドという位置づけなのでしょうがない
ような気もしないでもないですが、
であればもっと簡略化しても良かったと思いました。

【勉強になったこと】
・スコープ判断のタイミングと流れ
　1. プロジェクト定義フェーズ
　　1-1. 投資見立て
　　1-2. 概算見立て
　　1-3. 概算見積もり
　2. 要件定義フェーズ
　　2-1. 仮見積もり
　　2-2. 正式見積もり

・テスト工程を検討する際のポイント
　工程ごとのテストの目的・範囲を決める
　どこの環境をいつ使うかを決める
　データ準備の取り扱いを決める
　サブシステム間連携の実施タイミングを決める

・アプリ機能構成図は、後々テスト範囲を図示する際に
　必要となってくるので、プロジェクト定義の段階で
　概要レベルまで作成しておくこと。

投稿元：

レビューを見る

ざっと流して読んだ。IT部門の視点から、プロジェクトの進め方や流れがわかり易くまとめられていると思う。