あらすじ
新規事業・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 ブクログ
プロジェクトマネジメントのようなことをやってきて、改めてあの仕事はこう言語化できるのか、こう意味があったのか、と気づきが滅茶苦茶ある本だった。
プロジェクトマネジメントを全くやったことがない人には、ピンとは来ないけど教科書的な理解をするのだと思って読むといいかもしれない。
プロジェクトマネジメントのようなことをやったことがある人（ただしベテランではない人）には刺さりまくると思う。
Posted by ブクログ
人に勧められて。
なんか見たことある著者だと思ったら人が壊れる方も書いていたのか
「プロジェクトの9割は炎上している」と言われるくらいだから、ここに書いてあることが全てできるというのは本当の理想なのだろうか
とにかく認識の違いをなくしましょう、抜け漏れをなくしましょうと繰り返されていたが、ユーザー側から見たプロジェクトはどんな感じなのか気になった
同じこと考えているのなら両者あまりに不憫
メンバーのやる気うんぬんって隠されたらどうしようもないんじゃないか？目に見える態度や成果で判断するのか？
メンバーってどうやって選ばれるんだ？
やる気のある若手潰そうとする人間がいるらしいが、どう考えても仕事に責任感持っている人間がプロジェクトにいた方が使いやすくないか…？
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 ブクログ
プロジェクトマネジメントの流れを全部説明する本
流れとしてわかりやすく書いてあってまとまってる
プロジェクト：スタートとゴール、不確定要素、複数人
交渉：ヒアリング、同期非同期、ツール、議事録、共有、体制
タスクマネジメント：ジョブ型、能力見積り、①洗出し②優先順位③依頼④振返り、パスチャート
プロジェクト計画：①ヒアリング：目的前提座組期間②契約③マイルストーン
見積り：概算、詳細：積み上げ、バッファ
契約：請負、成果物・研修、準委任
要件定義：要求要件、ビジネス要件、
デザイン：ペルソナ、全体像
設計：コード規約、設計書、
テスト：テストとはなにか、テスト定義、計画、マネジメント
リリース：日程体制、リリース計画、リハーサル、関係者説明
保守改善：損益分岐点、固定費
Posted by ブクログ
プロジェクトマネジメントもプロダクトマネジメントも「ほぼ同じ」というザックリな視点ではあるが、「基本がわかる本」というコンセプトなのでこれで十分。プロジェクトを業務委託先と進めていく上で理解しておかなくてはいけないキーワードがしっかり盛り込まれている。
プロジェクトマネジャーならば、この本をすべて頭に入れてからスタートしてほしいところだ。
こういうプロジェクトマネジメントに必要な知識、手順がまとまっている使いやすいサイトって無いのかなぁ。経営理論やマーケティング理論もそうか。概念としては体系立てられているが、マニュアルレベルの個別対処となるとその時の状況、自社のリソース、自分やメンバーのスキルなど半分以上がケース・バイ・ケースの変数に依存するので動き方が異なってくるもんなぁ。プロジェクトも同じだよね。PMBOK（ピンボック）通りの手順だと石橋叩いてる途中でリソースが尽きちゃいます。
僕はプロジェクト・オーナーの立場で携わるので本書の第6章「契約」は特に勉強になった。手元においておくとしよう。
Posted by ブクログ
オーディブルにて。
仕事で必要になったので知恵を借りたくて読んだ。システム開発以外でも、という前置きだが、やはりプロジェクトマネジメントというのはシステム開発がメインなのだなと感じた。そのため当てはまらないことも多いが、必要な情報は得られた。
Posted by ブクログ
タイトル通りですが、プロジェクトマネジメントの基本が記載されている本です。この手の本はのいいところは、知識が体系的に、かつ網羅的に整理されているので、自身の知識が整理できて良いところにあるかと思います。SEからPMになった人なら1年目でも、いきなりPMみたいな人は3年目ぐらいの人が読むと、やっていることの整理と足りない箇所が見えるかなと思いました。
一方、実際のプロジェクトはこの本以外の応用力がどうしても必要だと感じています。例えばP.257の松竹梅のプロダクト改善費用のところです。ここでは三段階で出すと選びやすいと紹介されています。それもありますが、最初から追加開発のない一つだけのプランで出して契約すると、後々バグが出たときに追加費用について言ってくれなかったみたいな問題が出るのに対し、三段階で出すことで相手側が追加開発のあるプランを選ばなかった事実が残せ、返答として対応できませんと跳ね返すことができます。
こういうのは箇所箇所にどうしても存在しますが、経験しながら積み上げていくしかないところもあり、応用編という本があってもしょうがない気もします。そして、基本無くして応用力もないので、経験が浅い人はじっくり読んで基礎固める、ある程度わかってる人は基礎がちゃんとあるのか確認するためにざっと一読する、どちらにせよ何かしらの意味合いをくれる本だと思います。
以下抜粋
- さまざまなミスや遅れを抱えながらも80点ぐらいを維持できていれば、かなり優秀なプロジェクトマネージャーだといえます。しかし、プロジェクトマネージャー自身が完璧主義に陥っていて「自分はマイナス20点だ」と思い込んでいると、それが引け目となって適切な交渉ができなくなることがあります。（P.52）
- 人間が無理をして続けられるのは、人にもよりますが、おおむね３か月から長くても半年程度が限界です。２か月以上無理のある状態が続いていたら、一旦プロジェクトを止めて全体を見直すと良いでしょう。（P.89）
- 工数は1、3、5、10、15・・・と5人日以上の工数は5人日刻みで出すことをおすすめします。（P.131）
- バッファがどれぐらい必要なのかはプロジェクトの性質や大きさによって異なりますが、1.2〜1.5ぐらいの計数を掛けて出すことが一般的です。（P.133)
Posted by ブクログ
仕事でプロジェクト管理なんてやらないし、
そもそもチームで仕事、とかあまりしないし、
どこに出しても恥ずかしくない門外漢です。
あまりに馴染みがなくて、
いい感じに睡眠導入剤代わりでした。
「片付けをプロジェクト管理してみたら汚部屋が生まれかわった」に出てきた言葉はこういうことか、と遅ればせながら納得。
ペルソナの設計、とか面白かった。
要件定義、とか考えたこともなかったが、
目指すところを見据えておく、という点では
フィードフォワードの考え方にも通じるのかなとか。
仕事で使うのは想定できないけど、
片付け、引越し、ダイエット、老後の生活、親の介護などなど、応用出来たらいいなと思ってる。
Posted by ブクログ
システム開発のプロジェクトマネジメントを学ぶには良い本
プロジェクトマネジメントとは玉拾い
プロジェクトマネージャーは、プロジェクトとメンバーを守るのが仕事
プロジェクトとは今ある状態からあるべき状態にするために行う。スタートからゴールまで続く複数の業務と定義
・能力の高いソフトウェアエンジニアの見積精度は高い、やってみないとわからないというのは、能力不足か責任回避。見積もりをさせると実力がわかる
○見積り
プロジェクトの炎上が多い。組織では、ざっくり見積もりが使われているケースが頻繁にある。
適切なプロセスを踏めば、見積る対象にもよりますが、数日から1週間程度で精度の高い見積りを出すことは可能
● パラメトリック見積り：特定の係数モデル（FP法，COCOMOICOCOMOtなど）
を利用し、重み付けをして工数を算出する手法
●三点見積り法：作業毎に最頻値・楽観値・悲観値を設定し、値を掛け合わせて工数を算出する手法
●類推見積り：過去の類似するプロジェクトを参考に必要な工数を類推する手法
●ボトムアップ見積り：成果物や作業を分解してそれぞれの構成要素の工数を算出し、積み上げて全体の工数を見積る手法
意思決定者やプロジェクトメンバーへの説明が行いやすく、かつ要件と工数の調整が行いやすいのはボトムアップ見積りの手法
○契約
・発注者に成果物を納品し、その成果物に対価を支払ってもらうのが請負契約。発注者の代わりに行った専門的な労働の対価について支払いを受けるのが準委任契約。
・2020年4月に民法が大幅に改正され、請負契約と順位任契約の内容が大きく変化
・大手の事業会社ほど比較的新しい考え方である準委任契約を避ける傾向があり、見積もりが容易かつ契約書の雛形がある。請負契約を担当者が採択したがる。
・何をやるかが明確でなく、見積もりが大きく振りやすい要件定義、設計までを順位任契約の小さい実装、テストを請負契約とするなどの折衷案も有効。
#請負・準委任のポイント
①「瑕疵」→「契約不適合」
判断基準が「客観的な欠陥」から「契約で合意した内容との齟齬」に変わった。契約書・仕様書での成果物の定義が以前より重要になった。
②注文者の権利が拡大
修補・損害賠償に加え、「追完請求」「代金減額請求」が新たに認められた。
③準委任に「成果完成型」が明文化
事務処理への報酬（履行割合型）に加え、成果達成を報酬条件とする類型が合法化された。ただし成果は「報酬の条件」であり「義務の内容」ではないため、請負と異なり完成できなくても損害賠償は生じない。
○要件定義
・検討すべき事柄の全体像を図にしていく。スライドは紙面の制限があるので推奨しない。正しい書き方より伝わる書き方
・As isとto beを書く
・ITに関連する新規事業で引っかかりやすいのは、個人情報保護法、著作権法、出資法、資金決済法、特定商取引法、特定化子メール法、プロバイダ責任制限法、景表法、薬機法、医療広告ガイドライン、出会い系サイト規制法などです。ビジネス要件が固まった段階で法務担当や弁護土に相談してチェックをしてもらう
○デザイン
・顧客自身も自分が本当に欲しいと思ってあるものを表現できない。その上で関係者がイメージするものは全てずれていく
・プロトタイプでUXを育てる
○テスト
・削られがちだが全体工数の3割くらいは目安
7つの原則
1.テストは「欠陥がある」ことしか示せない
2.全数テストは不可能
3.早期テストで時間とコストを節約
4. 欠陥の偏在
5.殺虫剤のパラドックスにご用心
6.テストは状況次第
7.「バグゼロ」の落とし穴
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とはざっくりどんな感じなのかを知るために本書を手に取った。
網羅的に基本的なことが紹介、解説されていて入門者にはとてもよかった。
