プロジェクトマネジメントの基本が全部わかる本 の商品レビュー
プロジェクトマネジメントとは何か、その中でプロジェクトマネージャーの役割について、教科書のようにまとまっており、自分自身経験はないが概要は学べたと思う。本書のような流れでプロジェクトが進行し、課題をクリアしていきながら完了に至るのかということを想像できた。 1. プロジェクトと...
プロジェクトマネジメントとは何か、その中でプロジェクトマネージャーの役割について、教科書のようにまとまっており、自分自身経験はないが概要は学べたと思う。本書のような流れでプロジェクトが進行し、課題をクリアしていきながら完了に至るのかということを想像できた。 1. プロジェクトとはなにか 基本的な知識と考え方をおさえよう ・プロジェクト：いまある状態からあるべき状態にするために行う、スタートからゴールまで続く複数の業務（本書の定義） ・プロジェクトの目的：プロジェクトが向かうべき最終的な到達点 ・プロジェクトの目標：そのプロジェクトで達成すべき基準 ・プロジェクトの目標はQCDによって定義することができる。例えば、業務システムの開発（Q：要件定義で必須と合意した機能要件と非機能要件を実装する、C：初期費用の費用は1.5億円を想定する、D：リリースは2023年の8 月末を想定する） 2. 交渉 適切なパートナーシップを築こう 事前資料（言語化）→打合せ（非言語でカバー）→議事録（言語化）の順がおすすめ 3. タスクマネジメント チームでパスワークをしよう 4. プロジェクト計画 目標や進め方を決めよう ・プロジェクトの方針の意思決定はQCDの基準を基に行う ・開発手法の選択（ウォーターフォール、アジャイル（スクラム）） 5. 見積り 必要な費用とスケジュールを構造しよう ・概算見積りと詳細見積りを使い分ける ・概算見積り：発注者への提案や社内プロジェクトでの企画時点、プロジェクト計画、要件定義の段階 ・詳細見積り：要件定義や設計で不確実性をかなり潰した状態で提示（正式な見積り） 6. 契約 不利な条件を回避しよう ・請負契約（成果物に対価）と準委任契約（労働に対価） 7. 要件定義 やるべきことを決めよう ・プロジェクトで実現すべきこと（要件）を決める（定義する） ・①「要求（実現したいこと）」と「要件（実現すべきこと）」を切り分ける ・②決めるべきことをスケジュールの観点で見極める ・③ビジネス要件（Why）を固める。Why：なぜそれをやるのか？ ・④「実現すること」（What）の軸足と概要を描く ・⑤合意された事柄を資料化する（できるだけ図で表現。スライド作成ツールは使用しない） ・⑥法律など社会のルールを踏まえる ・⑦要件変更や追加要件のハンドリングをする 8. デザイン 顧客が本当に必要だったものを目指そう ・UI：目に見える画面のビジュアルや操作性などのデザイン ・UX：顧客体験などのデザイン 9. 設計 専門家に渡すバトンをつくろう ・①技術スタック（プログラミング言語やOS、ミドルウェア、フレームワークなど）を選定する ・②開発の「作法（ソースコード管理、コード規約、開発環境、デプロイ方法など）」を整える ・③設計書に求められる精度を確認する ・④設計書を作成する（基本設計から着手） ・⑤設計書をレビューする 10. テスト 事業リスクを最小限におさえよう 11. リリース 石橋を叩いて渡ろう 12. 保守改善 事業の成功につなげよう
Posted by
◯本書を読む目的 ・仕事で小さなプロジェクトを回す必要が出てきたため ・今後マネジメントフェーズになった時の予習 ◯感想 まずはリスクの観点で全体を俯瞰し、アクティブに調整を行うプロジェクトマネジメントとタスク進捗管理や予算管理に終始するプロジェクト管理を混同しないことが重要。...
◯本書を読む目的 ・仕事で小さなプロジェクトを回す必要が出てきたため ・今後マネジメントフェーズになった時の予習 ◯感想 まずはリスクの観点で全体を俯瞰し、アクティブに調整を行うプロジェクトマネジメントとタスク進捗管理や予算管理に終始するプロジェクト管理を混同しないことが重要。 プロジェクトは不確実性が伴うものなので、計画段階からスケジュールや予算にバッファーを持たせるべき。 本書のプロジェクトの定義やQCDに関する交渉を有するという観点で考えると、ソリューション営業もプロジェクトの一部だと感じた。 そう考えると自分も普段大なり小なりプロジェクトマネジメントを実行している身ということになるため、より成功率を上げることを意識したい。
Posted by
# 背景・手に取ったきっかけ 異動を機にプロジェクトマネジメントの要素が求められるようになり、学び直しのため # 所感 過去にプロジェクトマネジメントをやっていたときには成果物の雛形や様々なツールが整備されていたり、自社サービスかつ付き合いの長いベンダーと一緒にやることが多く、...
# 背景・手に取ったきっかけ 異動を機にプロジェクトマネジメントの要素が求められるようになり、学び直しのため # 所感 過去にプロジェクトマネジメントをやっていたときには成果物の雛形や様々なツールが整備されていたり、自社サービスかつ付き合いの長いベンダーと一緒にやることが多く、やりやすい環境だったのに対し、今回は新規の体制、社外の顧客相手のプロジェクトであったため、本書で体系的に、一般論として学べるのは大変助かった。 なんとなく感覚的にやっていたことが間違ってなかったと自信になったり言語化することができたのと、抜けてることにも気づけたり補うための教科書になった。今後も担当するプロジェクトのフェーズに合わせて本書で振り返ろうと思う。
Posted by
題名通りの本。 あちらこちらにメンバーの離職や鬱の可能性が書かれており、うーんSEの仕事ってホントにハードなんだな、自分よくがんばってるわ、、などと思ってしまった。プロジェクト特性によって考えることが全く違うので、これ一冊で自分の知りたいことがわかるということはありえないが、そう...
題名通りの本。 あちらこちらにメンバーの離職や鬱の可能性が書かれており、うーんSEの仕事ってホントにハードなんだな、自分よくがんばってるわ、、などと思ってしまった。プロジェクト特性によって考えることが全く違うので、これ一冊で自分の知りたいことがわかるということはありえないが、そういうこともあるんだなーということはわかった。
Posted by
- ネタバレ
※このレビューにはネタバレを含みます
WBSの書き方や要件定義の書き方の工夫を学んだ。 〇〇が〇〇をする。というふうに、主語と動詞をしっかり書くこと。能動態で書くと、わかりやすい資料になる。 それ以外は、全体の概念把握としては良い本だった。読みやすかった。
Posted by
▼感想 ・これまで数冊プロジェクトマネジメントに関する本を読んできましたが、上位に値するくらい内容量もわかりやすさも良かったです。 ・当方は、「PJ計画」、「要件定義(非機能要件含む)」、「テスト」が特に理解が深まりました！
Posted by
評価3.5 PMとはざっくりどんな感じなのかを知るために本書を手に取った。 網羅的に基本的なことが紹介、解説されていて入門者にはとてもよかった。
Posted by
・関係者（発注者/ベンダー/メンバー/関連企業）が対等に話し合える関係性を築く ・プロジェクトマネージャーが多忙もしくは能力不足で全体観を失わないようにする マネジメントは管理だけではない 管理：状況確認（計画との差分）、作業アサイン →計画に固執する マネジメント：管...
・関係者（発注者/ベンダー/メンバー/関連企業）が対等に話し合える関係性を築く ・プロジェクトマネージャーが多忙もしくは能力不足で全体観を失わないようにする マネジメントは管理だけではない 管理：状況確認（計画との差分）、作業アサイン →計画に固執する マネジメント：管理＋目的達成に必要な判断、全体像の把握、事前調整 →リスク把握し、アクティブな調整を行い、計画にフィードバックさせる ■交渉 ・説明資料と議事録は文書化 ・フォーメーションを組む：重要度、費用と進捗課題は人を分けるなど ■タスクマネジメント ・タスクを洗い出す→優先順位つける→メンバアサイン→振り返りＫＰＴ ★タスク名は「○○を○○する」で記載 いつまでに、は期限ではなく工数で記載 ・ガントチャートの欠点 タスクの抜け漏れ、 納期に合わせたスケジュールになりやすい（逆線表） 追加、変更管理が煩雑 メンバが「学生症候群＝ぎりぎりにやる」になりやすい ・メンバアサイン 背景、目的も伝える 完了条件を認識合わせる（優先度、期限とともに） ★定期的な振り返り ■プロジェクト計画 ・目的、前提条件 座組（体制図）、意思決定者、利害関係者、予算、日程、要求 を確認する （目的、前提条件を優先的に確認。後から変更難しい） ・開発体制 スクラム（≒アジャイル）開発はメンバスキル必要、予算＆日程が流動的 →納期・予算厳守の開発には向かない ■見積 ・工数見積もり→費用と日程を組み立てるが鉄則 ・ざっくり見積もり：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
- 1
- 2