無料マンガ・ラノベなど、豊富なラインナップで200万冊以上配信中！
無料マンガ・ラノベなど、豊富なラインナップで200万冊以上配信中！
新規事業・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章 保守改善―事業の成功につなげよう
※本電子書籍は同名出版物を底本として作成しました。記載内容は印刷出版当時のものです。
※印刷出版再現のため電子書籍としては不要な情報を含んでいる場合があります。
※印刷出版とは異なる表記・表現の場合があります。予めご了承ください。
※プレビューにてお手持ちの電子端末での表示状態をご確認の上、商品をお買い求めください。
※アプリの閲覧環境は最新バージョンのものです。
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 ブクログ
人に勧められて。
なんか見たことある著者だと思ったら人が壊れる方も書いていたのか
「プロジェクトの9割は炎上している」と言われるくらいだから、ここに書いてあることが全てできるというのは本当の理想なのだろうか
とにかく認識の違いをなくしましょう、抜け漏れをなくしましょうと繰り返されていたが、ユーザー側から見たプロジェクトはどんな感じなのか気になった
同じこと考えているのなら両者あまりに不憫
メンバーのやる気うんぬんって隠されたらどうしようもないんじゃないか？目に見える態度や成果で判断するのか？
メンバーってどうやって選ばれるんだ？
やる気のある若手潰そうとする人間がいるらしいが、どう考えても仕事に責任感持っている人間がプロジェクトにいた方が使いやすくないか…？
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のパレートの法則についても今のプロジェクを見回してみてなるほどと納得。
⑧リリース時期について
検討事項
・関わるメンバーや連携するシステムの担当者の稼働が確保できる日にする
・体調不良等も見越して誰が誰をカバーするか決めておく
・トラブルに即応するための監視体制も整えておく
避けるべきこと
・長期休暇前にリリースを設定すること
長期休暇前は他の業務も立て込み、作業が想定通り進捗せず生煮えの状態でリリースに取り掛かる可能性が高まるため。
また、トラブルが発生した場合担当者の休日が潰れ、不満、離任につながる
→長期休暇前にリリース設定日は避けるという頭はなかったので今後意識しておこうと思いました。
以上、冗長になりましたが感想です。
※アプリの閲覧環境は最新バージョンのものです。
新刊やセール情報をお知らせします。
プロジェクトマネジメントの基本が全部わかる本 交渉・タスクマネジメント・計画立案から見積り・契約・要件定義・設計・テスト・保守改善まで
