プロジェクトマネジメントの基本が全部わかる本 の商品レビュー
・関係者（発注者/ベンダー/メンバー/関連企業）が対等に話し合える関係性を築く ・プロジェクトマネージャーが多忙もしくは能力不足で全体観を失わないようにする マネジメントは管理だけではない 管理：状況確認（計画との差分）、作業アサイン →計画に固執する マネジメント：管...
・関係者（発注者/ベンダー/メンバー/関連企業）が対等に話し合える関係性を築く ・プロジェクトマネージャーが多忙もしくは能力不足で全体観を失わないようにする マネジメントは管理だけではない 管理：状況確認（計画との差分）、作業アサイン →計画に固執する マネジメント：管理＋目的達成に必要な判断、全体像の把握、事前調整 →リスク把握し、アクティブな調整を行い、計画にフィードバックさせる ■交渉 ・説明資料と議事録は文書化 ・フォーメーションを組む：重要度、費用と進捗課題は人を分けるなど ■タスクマネジメント ・タスクを洗い出す→優先順位つける→メンバアサイン→振り返りＫＰＴ ★タスク名は「○○を○○する」で記載 いつまでに、は期限ではなく工数で記載 ・ガントチャートの欠点 タスクの抜け漏れ、 納期に合わせたスケジュールになりやすい（逆線表） 追加、変更管理が煩雑 メンバが「学生症候群＝ぎりぎりにやる」になりやすい ・メンバアサイン 背景、目的も伝える 完了条件を認識合わせる（優先度、期限とともに） ★定期的な振り返り ■プロジェクト計画 ・目的、前提条件 座組（体制図）、意思決定者、利害関係者、予算、日程、要求 を確認する （目的、前提条件を優先的に確認。後から変更難しい） ・開発体制 スクラム（≒アジャイル）開発はメンバスキル必要、予算＆日程が流動的 →納期・予算厳守の開発には向かない ■見積 ・工数見積もり→費用と日程を組み立てるが鉄則 ・ざっくり見積もり：What（何を実現するか） 通常の見積もり：How（どうやって）、Who（誰が）で見積もる ・プロジェクトバッファ 1.2～1.5の係数をかける リスク低い＝やること明確 1.2倍 ■契約 請負契約 チェックポイント ・成果物の完成義務：成果物の定義 ★検収の定義 ・契約不適合への対応 ・損害賠償事項：上限額の設定 追完請求（補修）、代金減額請求 準委任契約 チェックポイント ・作成資料、具体的作業、報告の共有 ・善管注意義務：通常期待される注意義務 （PMとして期待されることをやっているか） ■要件定義 ・「要求＝やりたい」と「要件＝すること」を切り分ける ・ビジネス要件（Why）を固める ・実現することの軸足と概要を描く システムアーキテクチャ、機能要件一覧、非機能要件一覧 画面遷移図、シーケンス、ER図（データ構造）、API一覧 ・資料化 できるだけ図で表現：draw.io 正しさより伝わる資料 BA（Asis/Tobe)を作る：現状把握を怠らない ・要件変更/追加要件は期限を切って対応 ■デザイン ・ユーザーインタビュー 既存のプロダクトの客観的評価に向く 新規プロダクトには向かないことが多い ・ロゴ、フォント、トーン＆マナー、顔を決める ★全体像をデザイン 類似プロダクトUI/UXを学習する ユーザーにとってのメイン画面、機能を検討する →基本的パーツを作る 検討内容をUIに落とし込む デザインを育てる：プロトタイピング ■設計 ・技術スタックの決定 言語、OS、ミドルウェア、フレームワーク、ライブラリ、インフラスペック ・開発作法の整える ソースコード管理、コード規約、開発環境 デプロイ方法、コンテナ採用判断、仕様ツール ・設計書記載精度を決める ・技術的負債を見極める ■テスト ・ソフトウェアテストの7原則 ★各テストの定義を確認する リグレッションテスト、受入(検収)テスト、負荷テスト ・テスト計画、マネジメント テスト全体管理者を置く 責任の追及ではなく対策を追求する チケット（タスク）で管理する 定期報告を行う ■リリース トラブル発生時の対応を検討する ■保守改善 PJ目的は事業としての成功を実現する。QCD達成が目的ではない プロダクト改善費用 保守運用のみ、保守運用＋改善、保守運用＋大型改善 それぞれの対応工数を見積もる ファネルモデルを作る
Posted by
プロジェクトとは、 いまある状態からあるべき状態にするために行う、スタートからゴールまで続く複数の業務 と本書では定義している。
Posted by
- ネタバレ
※このレビューにはネタバレを含みます
プロジェクトマネジメントもプロダクトマネジメントも「ほぼ同じ」というザックリな視点ではあるが、「基本がわかる本」というコンセプトなのでこれで十分。プロジェクトを業務委託先と進めていく上で理解しておかなくてはいけないキーワードがしっかり盛り込まれている。 プロジェクトマネジャーならば、この本をすべて頭に入れてからスタートしてほしいところだ。 こういうプロジェクトマネジメントに必要な知識、手順がまとまっている使いやすいサイトって無いのかなぁ。経営理論やマーケティング理論もそうか。概念としては体系立てられているが、マニュアルレベルの個別対処となるとその時の状況、自社のリソース、自分やメンバーのスキルなど半分以上がケース・バイ・ケースの変数に依存するので動き方が異なってくるもんなぁ。プロジェクトも同じだよね。PMBOK（ピンボック）通りの手順だと石橋叩いてる途中でリソースが尽きちゃいます。 僕はプロジェクト・オーナーの立場で携わるので本書の第6章「契約」は特に勉強になった。手元においておくとしよう。
Posted by
プロジェクトを進める上で幅広く必要とされる知識やマインドセットをかなり幅広く抑えている。聞いたことのある概念や用語は多いが、それをスキルセットとして自分の中に落とし込めていないものがとても多いので、こういう本を手元に一つ置いておきたい。 様々な局面でのコミュニケーション(同期・非...
プロジェクトを進める上で幅広く必要とされる知識やマインドセットをかなり幅広く抑えている。聞いたことのある概念や用語は多いが、それをスキルセットとして自分の中に落とし込めていないものがとても多いので、こういう本を手元に一つ置いておきたい。 様々な局面でのコミュニケーション(同期・非同期)の取り方や、ウォーターフォールとアジャイル(の中でもスクラム)の開発の使い分けなど、参考になった。
Posted by
見積もりと実績でスキルチェックを行う 見積もりが曖昧な場合はスキル不足かモチベーション不足 タスクは具体的にxxをyyするの形で 見積もりは工数で スケジュール管理はクリティカルパスベースで 依頼時は優先度、完了条件、期限を明確に プロジェクト計画 ヒアリング 目...
見積もりと実績でスキルチェックを行う 見積もりが曖昧な場合はスキル不足かモチベーション不足 タスクは具体的にxxをyyするの形で 見積もりは工数で スケジュール管理はクリティカルパスベースで 依頼時は優先度、完了条件、期限を明確に プロジェクト計画 ヒアリング 目的 前提条件 座組 意思決定者 関係者 予算 スケジュール やりたいこと 座組 アサイン ベンダー選定 提案があるか 価格が不当に安くないか 目的 qcd 会議体、意思決定フロー ステークホルダー 開発方法 アジャイル 意思決定が早い メンバーのスキル要件が高い レビューアーは特に 外部連携はリスク高め スケジュールや予算は柔軟性が必要 契約形態 マイルストーン 関係者がいつどんな判断が必要になるか 情報共有の方法 ツールの使い方 見積もり 概算見積もりと詳細見積もりを使い分ける 要件定義前 要件定義、設計後 3点見積もり 契約 請負契約 納品した成果物に対する対価 成果物の定義 ドキュメントをどうするか等 検収の定義 損害賠償の範囲 準委任契約 労働に対する対価 作成する資料 進め方 報告方法 善管注意義務 工程で契約形態を変更するのは有効 偽装請負 支払い 方法 サイト 取引期間の締め日から支払いまでの期間 監査の立ち入り要件 アクセスログの提供方法などれんけいほうほうを明確に
Posted by
プロジェクトマネジメントの経験はないですが、そちら側からの視点に興味があり、読み始めました。 プロジェクトの全体像などが、分かりやすく書かれており、すごく読みやすかったです。実際の質問などがカテゴリ毎に掲載・著者が回答しておりましたので、イメージをしやすかったです。
Posted by
いまある状態からあるべき状態にするために行う、スタートからゴールまで続く複数の業務をプロジェクトと定義し、プロジェクトをどのように進めればよいのか解説した図書。プロジェクトの流れに沿って解説があり、イメージしやすい。これらの能力を身に着けられるとうれしいなぁ。なお著者がIT業界で...
いまある状態からあるべき状態にするために行う、スタートからゴールまで続く複数の業務をプロジェクトと定義し、プロジェクトをどのように進めればよいのか解説した図書。プロジェクトの流れに沿って解説があり、イメージしやすい。これらの能力を身に着けられるとうれしいなぁ。なお著者がIT業界でのプロジェクトに多く関わっているため、IT業界の例が多め。
Posted by
ソフトウェア開発プロジェクトのマネジメントについてのスキルを整理した一冊。 マネジメントするべき「プロジェクト」とは何であるのか、という解説から始まり、成功に至るために必要なステークホルダーとの交渉、決めるべきこと、各フェーズで求められていることが網羅されている。 いちソフトウ...
ソフトウェア開発プロジェクトのマネジメントについてのスキルを整理した一冊。 マネジメントするべき「プロジェクト」とは何であるのか、という解説から始まり、成功に至るために必要なステークホルダーとの交渉、決めるべきこと、各フェーズで求められていることが網羅されている。 いちソフトウェア開発者としてキャリアを築く中で、自然に身につけていたなと思う内容もあれば、これまであまり意識出来ていなかったなと思うところも。 本書は、そういった経験則で語られがちな内容を言語化し、通して学べる形で書籍化されている点が非常に良かった。 私自身は現在プロジェクトマネージャーになる予定も経験もないが、管理される側として、あるいは今後のキャリアの参考として、非常に勉強になった。
Posted by
現場感のあるアドバイスが数多くあり、プロマネでなくプロジェクトメンバとしても大変参考になる本だと思いました。
Posted by
最近話題のプロジェクトマネジメントの本。 またもや翔泳社の50%ポイント還元キャンペーンにつられて買ってしまった。 最近、開発もやってるのにプロマネのような仕事もやらされてて、読んでみた。 自分はプロマネにはむいていないのだろうなと思う(この本に書いてある事例と比べるとかなり小...
最近話題のプロジェクトマネジメントの本。 またもや翔泳社の50%ポイント還元キャンペーンにつられて買ってしまった。 最近、開発もやってるのにプロマネのような仕事もやらされてて、読んでみた。 自分はプロマネにはむいていないのだろうなと思う(この本に書いてある事例と比べるとかなり小規模なプロジェクトではあるけど)。 設計の次がテストというのがなかなか興味深い。 一瞬、「製造工程はどうすればいいんだ」と思ったけど、第3章のタスクマネジメントがそれにあたるのだろうなと思った。ここが一番重要だからね 後、いたるところに、QCD(Quality：品質、Cost：コスト、Delivery：納期)という言葉がでてくるのだけど、それだけプロジェクトを成功に導くために重要な概念なのだろうなと思った。今やってるプロジェクトは、全部ダメになりそうな気がする…(Qualityぐらいはよくしたいのだけど、納期が短すぎて簡単なテストすらする余裕がない…) プロマネとして大きすぎる負担を引き受けて心身を病む人がいるっていうのは、なんかわかる気がする。自分も、なんかうまくいかないなと悩んでる。そもそも、自分の考えに自信がなくて不安しかない。 「顧客のいう通りに機能を実装したら、そこがセキュリティの穴になって後で大問題」というのは、7payの話かな。セキュリティを保つと不便になることもあるからね。このへんは、難しいけど、セキュリティへの考慮は重要ということなのだろう。 チャットで和気あいあいしてるのに、優秀な人がやめていくという話が面白かった。優秀な人ほど馴れ合いのネガティブな影響に気づきやすいとのこと。なんとなく分かる気がする(自分の場合、ただたんに雑談が苦手なだけだけど) なお、著者によると、能力の高いソフトウェアエンジニアが出す見積もりは極めて正確だとのこと。本当、見積もりを正確にだせるようになりたいけど、なかなか難しいんだよ…(能力が低いだけ…) 後は、ビジネス要件の話については、重要なことだろうなと思った。「なぜそれをやるのか」というのが分からないと、モチベーションも低くなりかねないしね。まあ、今やってるプロジェクトは、「なぜそれをやるのか」をうまく説明できないのだけど…(しいていうと、他に仕事がないから) なお、要件定義資料にはスライド作成ツールは使わないほうがいいとのこと。なぜなら、広さに制限があるとのこと。なるほど。やっぱり、Excelを使うのがいいという事か。というと、そういうわけではなくて、Visio、draw.io、Lucidchart、miro、Whimsical、Cacooというツールを利用するのがいいらしい。やっぱり、そうだよね…。 後、設計を残すことは大事とのこと。今やってるプロジェクトは、途中で設計作るのやめた。そもそも、どういう仕様にすればいいのかが分からない所がおおすぎて、直接プログラムに落とし込むことに。品質絶対悪くなるよなと思う。 とりあえずこの本に書いてあったことを心に留めて、プロジェクトを進めていきたい。
Posted by
- 1
- 2