あらすじ
新規事業・DXを成功に導く
普遍的なPMスキルを習得しよう
チームで仕事をするには欠かせないプロジェクトマネジメント（PM）。
一般的なビジネススキルであるにもかかわらず、
多くの人が我流で進めた結果、数々の失敗を経験しています。
その理由は、基本を正しくおさえられていないからです。
そこで本書では、
なにを対象としたどのような規模のものであっても活用できる
PMの基本スキルを丁寧に解説します。
プロジェクトマネージャー一筋22年の著者・橋本将功が
これまで経験した失敗から学び得た全知見を注ぎ込み、体系化しました。
B to C・B to Bの両業態から、ITプロジェクトをはじめとしたさまざまな業種まで、
PMスキルを大幅に底上げする知識と実践方法が惜しみなく公開されています。
とくに
・新規事業やDXに携わるマネージャー
・受託プロジェクトのマネージャー
・PMの基本を学び直したいビジネスパーソン
・プロダクト開発に挑戦するスタートアップの経営者、エンジニア、デザイナー
にとっては必読の一冊でしょう。
●目次概要
序章 プロジェクトマネジメントのスキルの全体像
第1章 プロジェクトとはなにか―基本的な知識と考え方をおさえよう
第2章 交渉―適切なパートナーシップを築こう
第3章 タスクマネジメント―チームでパスワークをしよう
第4章 プロジェクト計画―目標や進め方を決めよう
第5章 見積り―必要な費用とスケジュールを構想しよう
第6章 契約―不利な条件を回避しよう
第7章 要件定義―やるべきことを決めよう
第8章 デザイン―顧客が本当に必要だったものを目指そう
第9章 設計―専門家に渡すバトンをつくろう
第10章 テスト―事業リスクを最小限におさえよう
第11章 リリース―石橋を叩いて渡ろう
第12章 保守改善―事業の成功につなげよう
※本電子書籍は同名出版物を底本として作成しました。記載内容は印刷出版当時のものです。
※印刷出版再現のため電子書籍としては不要な情報を含んでいる場合があります。
※印刷出版とは異なる表記・表現の場合があります。予めご了承ください。
※プレビューにてお手持ちの電子端末での表示状態をご確認の上、商品をお買い求めください。
感情タグBEST3
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 ブクログ
「プロジェクトマネジメントの基本"的な心構え"が全部わかる本」っていう書名の方が正確ではないか？例えば、WBSって何、どんな情報が整理されているべき、どうやって作る、みたいな具体的な方法論はほとんど省かれていますので。
一方、不満な点はそれくらいで、心構えについては、ジュニアPMからシニアPMまで一読を推奨できるレベルで体系的に整理されていてgoodでした。
Posted by ブクログ
突然PLにアサインされてしまって右往左往しながらプロジェクトを推進している立場で読み、体系立ててプロマネを解説されていて「まさに今欲しかったのはこれだ！」となりました。
プロジェクトの進め方自体は現場や会社ごとに色が出るものですが原理原則がわかる、という点で価値の高い内容だと思いました。
基本中の基本ですがQCDはトレードオフであること、プロジェクトのフェーズ、ステークホルダーの解説は再認識の意味でも私は役に立ちました。
Posted by ブクログ
経験に基づく、プロジェクトの落とし穴を見せてくれて塞ぎ方も示してくれる本。
PM未経験者にも分かりやすく勉強になる。
野良で適当にやっていると、知らずにアドリブでやっている取組が多いが、それを具現化しつつポイントも把握できるのがありがたい。
Posted by ブクログ
要件定義〜保守のフェーズごとに、どのような部分を意識すればよいのか記載されており、基本として十分な情報量だった。
★印象に残った内容
・「いわれた通りにやる」は「いわれなければやらない」と表裏一体
・要求の項目は「○○したい」という表現にし、要件の項目は「○○する」という表現にします
・テストは責任の追求ではなく対策の追求
・テストで報告が多く上がるのは悪いことではない
・保守運用の費用が削られる主な理由は、それが「事業的な価値を生み出さない費用」だと思われているからです。
Posted by ブクログ
プロジェクトマネージャーだけに限らず、
システムに関わる人(ベンダー、ユーザー側共に)全員に読んでほしい一冊。
本書を読めば、ベンダー側にとってはプロジェクトのどの部分に気をつければ良いかを理解することができ、逆にユーザー側にとってはシステム開発の各工程にどういう意味があるのかを理解することができます。
本の構成としては商談開始、要件定義〜リリース、運用保守までの各工程で章立てされています。
それぞれで何をやればいいか、やらなかったらどうなるか、具体的なエピソードで書かれているため、理解しやすくてよかったです。
また、見積もり手法やビジネスモデルの類型などそれぞれ種類が示され、解説されていたのも良いポイントでした。
読んだ中で印象に残った点は下記の通りです。(備忘も兼ねてますので冗長になってます。興味ある部分のみ読んでください)
※以下ネタバレ注意
①スケジュール管理について
ガントチャート法だと管理が面倒
クリティカルパス法で管理すると良い
→進捗管理工数の削減は悩みの種の一つだったので、ぜひ試してみたいです。
② ベンダー選定の観点
その企業ならではの提案があるか
(言われたことだけをやる企業ではないか
判断するため)
見積もりが安すぎないか
(スキルや見積もりの精度が低い可能性があり、プロジェクト進行上のリスクとなるため)
→見積もりが安すぎないかという観点はなるほどと思いました。IT業界では特に安かろう悪かろうなんだとしみじみ感じました。
③アジャイル開発を採用できる条件について
下記条件を満たさない場合、ウォーターフォールよりも上手くいかない可能性あり
条件1.素早い意思決定
意思決定が開発プロセスに含まれているため
意思決定が止まると開発全体が止まる
条件2.プロジェクトメンバーの要求レベルが高い
スクラム開発は短期間で適切な要件や設計を行う必要があるため、基本的なスキルや経験が必要になる
また、品質を管理するレビュアーが重要となるが、各領域の知見を持っている必要があるため調達が難しい
上記メンバーを揃えるためには一人当たりの単価は高くなることが想定される
条件3.外部システム連携がない
設計や実装、テストフェーズを足並み揃える必要があるので、スクラム開発を使用するとかえって非効率になる可能性もある
条件4.プロジェクト全体の予算スケジュールを調整できる
スクラム開発では動くものをつくり、フィードバックをしていくという流れになる
スクラム開発の中で要件や仕様が変更されていくため、一定の継続的投資があることが前提となる。
→日本の大企業では意思決定に時間がかかる、一度決まった予算に弾力性がない、システムが大きいため外部システム連携もある、というようにアジャイルに向かない理由があることを再確認できました。
世間では一概にアジャイルがいいという流れになっていますが、顧客に合った開発スタイルを志向していくべきだと思いました。
④ 準委任契約と請負契約
IT業界では契約自体では完成物が決まっておらず、正確な発注内容を資料化することが難しい。そのため、請負契約では不公平な契約になりやすく失敗の原因になるため、基本的に順委任契約を目指す
ブレが大きい要件定義や設計段階を準委任、それ以降を請負とする手もある。
どうしても請負でと迫ってくる客には準委任契約と請負契約でバッファの割合を変えて顧客に提示する手もある。
→契約の交渉は難しいことが多いが、上記のような手もあるのだなと思いました。
⑤ビジネス要件の調査方法について
1〜12の順で調査
1.市場調査
どのような競合他社があるのか確認
調査報告書や新聞、書籍、雑誌などがあるが
簡易に実践する場合はウェブ検索でも可
2.競合調査
競合となる企業の売り上げやポジションを探るまた、プロダクトを実際に使用し、機能や見せ方、売り方を見る
社内システムの検討の際も、世の中のシステムにどのようなものがあるか調査すると有意義
3.ビジネスモデル
市場調査や競合調査を参考に自社でどのようなビジネスモデルを構築する必要があるか検討する
ビジネスモデルの検討手法としては下記の通り
Ⅰ.ビジネスモデルキャンバス
Ⅱ.リーンキャンバス
Ⅲ.4p分析→商材、価格、流通、販促の4つの要素を一つにまとめたフレームワーク
Ⅳ.4c分析
顧客にとっての価値、顧客が費やすお金、
顧客とのコミュニケーション、顧客にとっての利便性
4.KPIツリー
収益構造に無理がないか調べる
見た目が分かりやすいため、意識合わせやディスカッションに最適
5.ペルソナ設計
プロダクトを利用するユーザーがどのような人物なのか決めていく手法
6.ユーザーヒアリング
ペルソナに該当するユーザーにヒアリングし、
対象となるテーマにどのようなペインがあるか
プロダクトにニーズがあるか確認する手法
7.カスタマージャーニーマップ
ペルソナで設計したカスタマーが日々どのような生活を送っているのか、どのようなペインを解決するのか確認する手法
プロダクトにどのような機能が必要か客観的に俯瞰することができるようになる
8.ユーザーストーリーマッピング
ペルソナで設計したユーザーがペインを解決するためにプロダクトをどのように利用するか確認する手法
機能の優先度をチェックする
9.ユースケース
ユーザーが目的を達成するための
ユーザーとプロダクトのやり取りを明確に示したもの
※要件の抜け漏れを防ぐため全ての画面において行う
10.業務フロー
業務の流れや判断の分岐をフロー図で表す手法
業務システムの開発など、toBのプロダクトでは必須と言える手法
11.グロース設計
プロダクトが成長していく際、何が必要で
誰が何をやるのか明確にする
12.UI.UX
画面や使い心地などのデザインを検討するプロセス
→SEとして顧客の業務を理解し、提案していく必要がある。業務調査の手法については気になっていたので一連のフローを知れて良かった。
⑥要件定義にて合意した資料のポイント
1.できるだけ図で表現する
ホワイトボードやミロなどのオンラインツールで描くようにする
業務に関してフローチャートにして合意を取ると良い
2.スライド作成ツールで作成しない
要件定義資料はパワポは避ける
要件定義資料は多くの前提条件や検討の経緯を踏まえて決められるものなので、結論だけでなく、検討の経緯や他の資料との関連は記載しておく必要があるので紙面の限りがあるものは避ける
visioやdraw、lucidchart.miroなど概念図を整理できるツールを見つけておくとよい
3.正しい書き方よりも伝わる資料
正しい書き方よりも伝わる資料を作ることが大切
4.ASIS TOBEを作成する
今どうなっているかを漏らさないように気をつける
→具体的なツール名が記載されてたのが良かった。
⑦ソフトウェアの7原則について
1.テストは欠陥があることしか示せない
→テストはソフトウェアが完全なことを示すものではなく、欠陥を早期に発見するためにあるもの
2.全数テストは不可能
→テストは指数関数的に増えていくため、
限られた予算の中で効率的に欠陥を発見するための方法を検討する必要がある
3.早期テストで時間とコストを節約
→フェーズが進めば進むほど影響調査の範囲は拡大していくため、早期フェーズで実施することが大切
4.欠陥の偏在
パレートの法則にある通り、8割のバグは2割の場所で発生する
複雑な部分が偏在することが原因
5.殺虫剤のパラドックスにご用心
同じシナリオ、同じデータで新規のバグは発見できないのでそのテストで何を発見するかを明確にしておく
6.テストは状況次第
Wi-Fiが届いている環境でのテストで問題なかったとしても一般的な動作環境ではうまく動作しないなど状況により異なる場合がある
7.バグゼロの落とし穴
欠陥をなくすことで処理が遅くなったり、機能が一部制限されるなど利便性が悪くなる場合もある
バグがクリティカルか、トレードオフとして失われる機能がないか確認すること
→限られた工数の中でテストを検討することが当たり前なんだなと思いました。4のパレートの法則についても今のプロジェクを見回してみてなるほどと納得。
⑧リリース時期について
検討事項
・関わるメンバーや連携するシステムの担当者の稼働が確保できる日にする
・体調不良等も見越して誰が誰をカバーするか決めておく
・トラブルに即応するための監視体制も整えておく
避けるべきこと
・長期休暇前にリリースを設定すること
長期休暇前は他の業務も立て込み、作業が想定通り進捗せず生煮えの状態でリリースに取り掛かる可能性が高まるため。
また、トラブルが発生した場合担当者の休日が潰れ、不満、離任につながる
→長期休暇前にリリース設定日は避けるという頭はなかったので今後意識しておこうと思いました。
以上、冗長になりましたが感想です。
Posted by ブクログ
▼感想
・これまで数冊プロジェクトマネジメントに関する本を読んできましたが、上位に値するくらい内容量もわかりやすさも良かったです。
・当方は、「PJ計画」、「要件定義(非機能要件含む)」、「テスト」が特に理解が深まりました！
Posted by ブクログ
プロジェクトを進める上で幅広く必要とされる知識やマインドセットをかなり幅広く抑えている。聞いたことのある概念や用語は多いが、それをスキルセットとして自分の中に落とし込めていないものがとても多いので、こういう本を手元に一つ置いておきたい。
様々な局面でのコミュニケーション(同期・非同期)の取り方や、ウォーターフォールとアジャイル(の中でもスクラム)の開発の使い分けなど、参考になった。
Posted by ブクログ
・感想
PMに立つ上で基礎知識をかなり分かりやすくまとめた書籍。
定期的に読み直し、知識のアップデートを図る必要有。
復讐をよくおこなって35歳までには身につけたい。
・Todo
・PJはスタートとゴールが決まっており、
QCDの観点はトレードオフになる。
企画:プロジェクトの企画意図や必要性の検討
見積:ベンダーに見積を取って費用やスケジュールの評価
決裁:費用対効果やスケジュールの妥当性を検討し、社内決裁の上でベンダーに発注
PJ計画:プロジェクト計画を立てて開始する
要件定義:要件の定義とデザインを行い、開発するシステムの大枠を決める。
設計:設計を行い、システムの仕様を詰める
実装:システムの実装を行い、追加要件・仕様のハンドリングを行う
テスト:テストを行いシステムが適切に実装されているか確認する。
リリース:事前に決めた手順にしたがってリリースと現場への導入
保守改善:システムが適切に動くよう保守。必要に応じて機能改善
★スタートから無理な予算やスケジュールになっていないか妥当性を確認。
※適切な人材も配備しておくようにすること。
→PJの全体像を共有しておく。
関係者（発注者、ベンダー、メンバー、関連企業）が対等に話し合える関係性がない。
PJマネージャーが多忙もしくは能力不足で全体感を失っている。
この３つは失敗要素に繋がりやすい。
★PMはプレイヤーとして多忙で全体間、必要作業整理が遅れないようにする。
★マイクロマネジメントをするとメンバーの自律性（指示待ち）をなくす。
★メンタルを常に正常に保っておくこと。
＝タスクを抱えすぎない。
・ITでよくあるリスク
管理画面の実装を想定していない。必要工数を過小評価する。
システムの外部連携に必要な工数や体制の過小評価
一部ユーザー意見を聞いて要件定義や設計、実装を行う。
★PMは管理だけではなく、困難な状況でも協業して目的を達成したりプロセスを維持する必要がある。
→打ち合わせで進捗を管理するだけ、タスクをメンバーに振るだけ、Excelで予算や稼働時間の調整をするだけ のマネジメントは不用。
★PJ実態をリスクの観点で把握してアクティブな調整を行い、それを計画にFBしていく必要がある。
★PJは基本不確実で当初の予定通りには進まない。
→不確実性を減らしQCDの高い基準の達成には、計画の承認や要件定義の際に意思決定者や関連するキーパーソンの判断、調整が必要不可欠。
★交渉の前面に立たないPNは各関係者から信用されずプロジェクト継続性にも支障をきたす。
やるべき交渉や調整をメンバーに丸投げしないこと。
・PJを適切に進める点で完璧主義はネガティブに働くことを意識しておく。
★多角的な情報を集めて、みんなの意見を聞きながら関係者に方向性を指し示すやり方を行うこと、
★同期、非同期のコミュニケーションを使い分けて相談しにくいことは同期のコミュニケーションを取ること。
※リアルタイムか非リアルタイムか。
・10人しか居ない会議で3人しか話さないのは7人の工数を無駄にしている。
★議事録を必ず取ることでPJの言った言わないを防ぐ。
決定事項は関係ないと思えるような人にも共有すること。
・フォーメーションを組んで交渉すること。
★PJを進める上で注意すること
・PJを進める中での懸念点をあらかじめ説明する
・エビデンスを主体に説明資料を作成する
・最終的な着地点を明確にする
・会社間の交渉内容はあらかじめ組織内で合意しておく。
★ハードな交渉は必要最低限に絞り、PJを適切に完了するためには何が必要なのかを明示し、そこ
に理解を得られるよう努力すること。
そしてハードな交渉ほど事前に組織内で合意をとっておくこと。
・タスクマネジメントはタスク管理ではない
★アサインを決める際はそのタスクを実行出来るだけの技術や経験があることは前提として、更にマインドもよく見なければならない。
・そのポジションに必要なタスクをこなせるかを能力とマインドの観点でチェックするように
★言い訳や責任回避の姿勢が見られプロジェクト進捗に影響する場合は上層部に掛け合って早めにアサインを変更してもらうようにする。
→不可能な場合はサポートする体制を組む、クリティカルパスのボトルネックにならないタスクのみを割り当てて全体進行に影響しないようにする工夫が必要。
★トラブル報告する際はメンバー個人の問題ではなく、プロジェクトの課題として報告するように。
また事前に懸念点として意思決定を行う上層部に認識を共有しておくこと。
★見積でタスクの遂行能力を見極める。
やってみないとわからない というスタンスのメンバーは経験不足で能力が低いか、責任回避的でタスクに積極的に取り組むマインドがないかのどちらか。
タスクは〇〇を〇〇すると記載
必要なことを達成する為にどうすべきか洗い出し、
優先順位を決めて、誰がいつまでに実施するかをリスト化。
★いつまでには期間ではなく工数を記載。
粒度が大きくても良いので抜け漏れなく。
★タスク組み立て後はガントチャートを活用し、優先順位をつける。
クリティカルパスを使って穴を埋めていくことが理想。
★タスクを依頼する際はPJ上の背景や理由を説明すること。
★人が無理し続けられるのは3ヶ月から長くても半年。2ヶ月以上無理が続く場合はPJを止めて全体を見直すこと。
★担当者のレベルが低い場合はサブタスクまで分解してあげる
タスクを丸投げすると、アウトプットの質が低かったり方向性が異なってやり直しが発生しやすくなる。
変化の激しいPJは毎週、そうでないPJは月一や四半期で振り返り会を行う。
テーマは良かったこと、改善したいこと、課題、今後努力したいことを出し合う。
プロジェクトが停滞した場合は
・メンバーのスキルが低い＝ミスマッチであることを伝えてPJの判断としてアサイン変更
・アサイン担当の稼働が逼迫＝マネジメント不足。負荷分散のために他者へタスクを振る、プロジェクト全体のスケジュールを調整すること。
★PJ計画の立て方。
・ヒアリング PJの要件を確認、提案
・座組とチームビルディング PJの体制を整える
・アサイン 誰に何を依頼するか決める
・目的 プロジェクトの真の目指すべきところをとらえる
・QCD プロジェクトの判断基準を決める
・会議体と意思決定フロー 適切なプロジェクト推進方法を決める
・契約形態 請負か準委任かを確認
・マイルストーン 進捗を関係者で共有
・情報共有のやり方 意思疎通の仕組みを作る
★キーパーソンを決めながら行っていくこと。
★ヒアリングで重点的に聞くこと
目的 何のためにPJをやるのか
前提条件 必ず守る必要がある条件はなにか
座組 PJメンバーや連携が必要な企業はどこか
意思決定者 決済権限を持つ人
利害関係者 得をする人、損をする人は誰か
予算 適切な予算があるか
スケジュール 適切な実施期間があるか
具体的にやりたいことはなにか。
エゴはプロジェクトを推進する力になるが実現可能性の観点で前提条件や目的もよく検討すること。
★外部ベンダーを使う際は有望企業を3ー4社集めること。
・その企業ならではの提案があるか
・見積もりが安すぎないか
★誰にいつまでに何を決めてもらわないとプロジェクトが予定通りに進まないのかをプロジェクト計画にマイルストーンとして明確に記載する
ウォーターフォール
フェーズ毎に区切るので進捗確認がしやすかったり、各フェーズ予算やスケジュールを明確にしやすい。
デメリットは要件定義や設計フェーズはドキュメント主体なので理解力や想像力が関係者に求められる。
アジャイル
基本はプロダクトを確認しながら開発が出来るが以下を満たさないとウォーターフォールより時間がかかる。
①素早い意思決定が出来ること
※意思決定が止まると開発全体が止まる
②プロジェクトメンバーの要求レベルが高い。
各工程について習熟している必要がある。
基本的な考えが備わってないと混乱する可能性もある。
各ポジションをスキルが高いメンバーで固められない場合はウォーターフォール型を取ること。
フロントエンド 画面
バックエンド アプリケーションやデータベース等
インフラ
利用するフレームワーク
③外部システムやサブシステムとのシステム連携がある。
既に公開のAPIなら問題ないが、今後の拡張において未公開だと不適切である
④プロジェクト全体の予算やスケジュールを調整出来る
契約形態もはっきりとさせておくこと。
マイルストーンをハッキリさせ、各ポイントで報告入れることを明示する。
アジャイル（スクラム）開発がマッチするのはIT予算が複数年で継続的に組まれており、優秀な開発チームを継続的に維持できる企業であること。
見積は工数を見積もってそこから費用とスケジュールを組み立てることが鉄則。
概算見積の金額ブレ幅は4倍から0.25倍まである。
概算はバッファを積んで高めに出すこと。
★プロジェクトはモノを買う時より安かろう、悪かろうになる。
★ざっくり見積は類似案件から出せるが出した責任はPMや実行チームが追う為絶対に言われてもその場では出さない。
すぐに見積るので一旦持ち帰りますと回答すること。
見積手法の種類
パラメトリック見積
特定の係数モデルを利用し、重みづけして工数を算出
三点見積もり法
作業毎に最頻値、楽観値、悲観値を設定し、値を掛け合わせて工数を算出
類推見積もり
過去の類似プロジェクトを参考に見積
ボトムアップ見積もり
成果物や作業を分解してそれぞれの構成要素工数を算出し、積み上げて全体工数を見積る。
ざっくり見積もりは
プロジェクト目標を達成する為に誰が何をやらなければならないかを細分化して、メンバーのタスク（作業）レベルにまで落とし込む。
★基本工数は5人日以上は5人日刻みで出すことを推奨。
そこからその人の1日あたりの単価をかける。
→決まった予算枠やスケジュールとマッチしないときに何を削れば対応できるか調整しやすくなる。
見積もり明細には対応項目毎に工数と単価を明記して記載しておくと明朗会計で信頼されやすくなる。
★一色の記載があるものは積み上げ式ではなく信頼性が低いので、相手に突っ込むこと。
・PJバッファは1.2-1.5くらいの係数をかけて出す。
※バッファを消化しなかった場合は請求金額を安くする、機能追加やドキュメント整備など追加対応を実施するなどでPJ満足度を上げる。
見積費用は説明できるようにしておくこと。
なにを削れば擦り合わせられるかの調整も想定しておくこと。
要件や仕様が変わると工数が変動し、それを見積もる必要があることは関係者に都度説明しないといけない。
請負契約 発注者に成果物を納品し、その成果物に対価を支払ってもらう
準委任契約 発注者の代わりに行った専門的な労働の対価について支払いを受ける
請負契約で注意すること
成果物はなにか。
チーム内部のドキュメントと顧客納品のドキュメントは品質が大きく異なる。
※成果物の工数は適切に見積もる必要有。
何を持ってプロジェクトを完了とするか。
結合、総合テストが完了している、第三者の脆弱性テスト報告内容を確認したりする。検収定義を契約書やプロジェクト計画書で文書化しておくこと。
それは本当に対応が必要か。
締結時に記載内容をよく確認すること。
一方的な内容になってないか。
損害賠償が青天井になってないか上限額が記載されているか。
※重過失の場合はこの限りではないと記載する。
★準委任契約はどのくらいの期間と工数を使えばどのような成果を得られるかを資料サンプルやプロジェクト計画、業務報告のサンプルで早めに示してお金を払う理由を納得してもらうこと。
★偽造請負には要注意。
・発注者は受注者の労働者に指揮命令や業務管理を出来ないようにする
・発注者と受注者の体制を明確に分ける
請け負った業務内容や就業場所を細かく記載するようにする。
★支払いサイトをしっかり確認し、中小企業が倒産しないようにすること。
★要件定義
要求（実現したいこと Want） と 要件（実現すべきこと Must） を切り分ける
決めるべきことをスケジュールの観点で見極める
ビジネス要件（Why）を固める
実現すること（What）の軸足と概要を描く
合意された事柄を資料化する
法律など社会のルールを踏まえる
要件変更や追加要件のハンドリングをする。
・市場調査
プロジェクト対象がどのような規模でどのような競合他社があるのかを調査する。
※調査はWeb検索や各種調査報告書、新聞、書籍、専門データベースなど。
・競合調査
売上や市場でのポジション、どのような機能や売り方、見せ方をしているかを分析。
・ビジネスモデル
自社のビジネスモデルを検討。
想定収益が想定費用と比べて安すぎないか、継続的な成長のための再投資が可能か
ビジネスモデルキャンバス
顧客、提供価値、チャネル、顧客との関係、収益、リソース、活動、パートナー、コストを一枚に。
４P分析 商材、価格、流通、販促
４C分析 顧客にとっての価値、費やすお金、利便性、コミュニケーション
ペルソナ設計と分析
カスタマージャーニー
ペルソナが日々どのような生活や仕事をして、開発プロダクトとどう関わるのか、どのようなペインを解決するのか。
ユーザーストーリーマッピング
ユーザーから見たプロダクトの中での機能や特徴の位置付け
何が必須機能や特徴なのか。
ユースケース
ユーザーがプロダクトを利用して、特定の目的を達成するまでのユーザーとプロダクト双方のやりとりを明確に定義したモノ。
システムアーキテクチャ
プロダクトがどんなインフラ構成で稼働するか、連携システムはどこにあるのかを図示する。
具体的にどんな技術を利用し、どんな専門家が必要かを把握する
シーケンス図
ユーザーの作業やプログラム、データの流れや概要を図示する。
ER図、テーブル定義書
プロダクトで利用するデータをどのように構造化するかを定義。
API一覧
どんなAPIを利用するかを一覧化。
★合意された事柄を資料化する。
なるべく図で表現。
※Powerpointでらなく、絵で描くと良い。
インデックスは必ず入れる
業務改善やプロダクトリニューアルは、
AsIS/ToBeを入れること。
★要求提出や要件についての意思決定はそのままだと時間がかかるので提案型で要件をとりまとめるアクティブな対応が必要。
要求をヒアリングとしてとりまとめ、実際にプロダクトに落とすとどうなるかを要件定義のフレームワークやプロダクトのデザインイメージに落とし込み、最終判断を仰ぐようにする。
A案かB案の2択に絞ると進みやすい。
→やり直しと停滞が一気に減って効率化に繋がる。
★打ち合わせではアイデアを募る 発散の場なのか、
要件や仕様を判断する 収束なのか を明示するようにする。
デザインはペルソナ（代表的なユーザー像）設計をしっかりとすること。
★プロダクト全体像のデザインの仕方
類似するプロダクトのUI/UXを学習する
ユーザーにとって何がメインの画面や機能かを検討する
検討内容をUIに落とし込む。
意思決定者が口出しして進まない場合は幅広い方向から複数案を提示して選択する。
★設計
技術スタック（プログラミング言語やOS、ミドルウェア、フレームワーク、ライブラリ等技術の組み合わせ）を選定
PMは言ってることを理解できるようにしておく必要有。
開発の作法 を整える
設計書に求められる精度を確認
設計書を作成
設計書をレビューする。
技術選定時はGoogle trendsを使って流行度合いや技術のメリデメを比較検討する。
デプロイ 開発したソフトウェアをサーバー上に展開・配置して利用できるようにすること。
テスト環境 実装画面や機能をテストする環境
ステージング環境 本番環境に類似する環境で表示内容の確認や性能面をテストする環境
本番環境 リリース後にプロダクトが動作する環境
どんなプロジェクトでも設計書は残すこと。
※リプレイス時や改修時の調査工数を減らすため
★テストは責任の追求ではなく、対策を追求すること。
★piyolog などを定期的に見て、事件や事故を定期的にチェックしておく。
Posted by ブクログ
プロジェクトマネジメントの経験はないですが、そちら側からの視点に興味があり、読み始めました。
プロジェクトの全体像などが、分かりやすく書かれており、すごく読みやすかったです。実際の質問などがカテゴリ毎に掲載・著者が回答しておりましたので、イメージをしやすかったです。
Posted by ブクログ
ソフトウェア開発プロジェクトのマネジメントについてのスキルを整理した一冊。
マネジメントするべき「プロジェクト」とは何であるのか、という解説から始まり、成功に至るために必要なステークホルダーとの交渉、決めるべきこと、各フェーズで求められていることが網羅されている。
いちソフトウェア開発者としてキャリアを築く中で、自然に身につけていたなと思う内容もあれば、これまであまり意識出来ていなかったなと思うところも。
本書は、そういった経験則で語られがちな内容を言語化し、通して学べる形で書籍化されている点が非常に良かった。
私自身は現在プロジェクトマネージャーになる予定も経験もないが、管理される側として、あるいは今後のキャリアの参考として、非常に勉強になった。
Posted by ブクログ
プロジェクトマネジメントもプロダクトマネジメントも「ほぼ同じ」というザックリな視点ではあるが、「基本がわかる本」というコンセプトなのでこれで十分。プロジェクトを業務委託先と進めていく上で理解しておかなくてはいけないキーワードがしっかり盛り込まれている。
プロジェクトマネジャーならば、この本をすべて頭に入れてからスタートしてほしいところだ。
こういうプロジェクトマネジメントに必要な知識、手順がまとまっている使いやすいサイトって無いのかなぁ。経営理論やマーケティング理論もそうか。概念としては体系立てられているが、マニュアルレベルの個別対処となるとその時の状況、自社のリソース、自分やメンバーのスキルなど半分以上がケース・バイ・ケースの変数に依存するので動き方が異なってくるもんなぁ。プロジェクトも同じだよね。PMBOK（ピンボック）通りの手順だと石橋叩いてる途中でリソースが尽きちゃいます。
僕はプロジェクト・オーナーの立場で携わるので本書の第6章「契約」は特に勉強になった。手元においておくとしよう。
Posted by ブクログ
受発注からリリース、保守まで「もめそうなところ」を挙げて、それを防ぐようなポイントと心構えを整理している。KPIツリーとかペルソナとか、具体の部分は本書にはなく、別の本で勉強してくださいというスタンスかなと。
Posted by ブクログ
情報システムの構築についての、そしてそれを受注する側の目線で書かれたプロジェクトマネジメントの解説本。ある意味、今のわたくしには直接関係ない本なのだが、具体的にわかりやすく原理原則から説き起こしてくれるので、読んでいて勉強になった。どのような分野でも、よくわかった人の解説は面白いものだ。ましてや自分が仕事で逆の立場にたったこともある分野なので、もっと早く読んでおくべきだった
Posted by ブクログ
期待値が高かったせいか物足りない印象。
アジャイル要素低め。
確かに基本が薄く広範囲に説明されている。
決定に時間がかかるようならScrum向かないは参考になる。
基本だからなぁ、
Posted by ブクログ
プロジェクトマネジメントの全体像を俯瞰して捉えることができる。
扱うテーマはIT系のプロジェクトだが、転用すればその他のプロジェクトにも生かせるだろう。
実際に行う段になった際に、この本をマニュアルのように横に置いて順に進めていくと良いかも。そのうえでこの本の内容では解決できない問題を部分的に深度の深い本で補うと良いと思う。
Posted by ブクログ
プロジェクトマネジメントとは何か、その中でプロジェクトマネージャーの役割について、教科書のようにまとまっており、自分自身経験はないが概要は学べたと思う。本書のような流れでプロジェクトが進行し、課題をクリアしていきながら完了に至るのかということを想像できた。
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 ブクログ
題名通りの本。
あちらこちらにメンバーの離職や鬱の可能性が書かれており、うーんSEの仕事ってホントにハードなんだな、自分よくがんばってるわ、、などと思ってしまった。プロジェクト特性によって考えることが全く違うので、これ一冊で自分の知りたいことがわかるということはありえないが、そういうこともあるんだなーということはわかった。
Posted by ブクログ
WBSの書き方や要件定義の書き方の工夫を学んだ。
〇〇が〇〇をする。というふうに、主語と動詞をしっかり書くこと。能動態で書くと、わかりやすい資料になる。
それ以外は、全体の概念把握としては良い本だった。読みやすかった。
Posted by ブクログ
評価3.5
PMとはざっくりどんな感じなのかを知るために本書を手に取った。
網羅的に基本的なことが紹介、解説されていて入門者にはとてもよかった。
Posted by ブクログ
見積もりと実績でスキルチェックを行う
見積もりが曖昧な場合はスキル不足かモチベーション不足
タスクは具体的にxxをyyするの形で
見積もりは工数で
スケジュール管理はクリティカルパスベースで
依頼時は優先度、完了条件、期限を明確に
プロジェクト計画
ヒアリング
目的
前提条件
座組
意思決定者
関係者
予算
スケジュール
やりたいこと
座組
アサイン
ベンダー選定
提案があるか
価格が不当に安くないか
目的
qcd
会議体、意思決定フロー
ステークホルダー
開発方法
アジャイル
意思決定が早い
メンバーのスキル要件が高い
レビューアーは特に
外部連携はリスク高め
スケジュールや予算は柔軟性が必要
契約形態
マイルストーン
関係者がいつどんな判断が必要になるか
情報共有の方法
ツールの使い方
見積もり
概算見積もりと詳細見積もりを使い分ける
要件定義前
要件定義、設計後
3点見積もり
契約
請負契約
納品した成果物に対する対価
成果物の定義
ドキュメントをどうするか等
検収の定義
損害賠償の範囲
準委任契約
労働に対する対価
作成する資料
進め方
報告方法
善管注意義務
工程で契約形態を変更するのは有効
偽装請負
支払い
方法
サイト
取引期間の締め日から支払いまでの期間
監査の立ち入り要件
アクセスログの提供方法などれんけいほうほうを明確に
