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