【感想】プロジェクトマネジメントの基本が全部わかる本 交渉・タスクマネジメント・計画立案から見積り・契約・要件定義・設計・テスト・保守改善まで

橋本将功 / 翔泳社
(16件のレビュー)

総合評価:

平均 4.2
8
1
5
0
0

ブクログレビュー

"powered 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のパレートの法則についても今のプロジェクを見回してみてなるほどと納得。

    ⑧リリース時期について

    検討事項
    ・関わるメンバーや連携するシステムの担当者の稼働が確保できる日にする
    ・体調不良等も見越して誰が誰をカバーするか決めておく
    ・トラブルに即応するための監視体制も整えておく

    避けるべきこと
    ・長期休暇前にリリースを設定すること
    長期休暇前は他の業務も立て込み、作業が想定通り進捗せず生煮えの状態でリリースに取り掛かる可能性が高まるため。
    また、トラブルが発生した場合担当者の休日が潰れ、不満、離任につながる

    →長期休暇前にリリース設定日は避けるという頭はなかったので今後意識しておこうと思いました。

    以上、冗長になりましたが感想です。
    続きを読む

    投稿日:2024.06.15

  • akari1102

    akari1102

    題名通りの本。
    あちらこちらにメンバーの離職や鬱の可能性が書かれており、うーんSEの仕事ってホントにハードなんだな、自分よくがんばってるわ、、などと思ってしまった。プロジェクト特性によって考えることが全く違うので、これ一冊で自分の知りたいことがわかるということはありえないが、そういうこともあるんだなーということはわかった。続きを読む

    投稿日:2024.05.23

  • たくや

    たくや

    このレビューはネタバレを含みます

    WBSの書き方や要件定義の書き方の工夫を学んだ。
    〇〇が〇〇をする。というふうに、主語と動詞をしっかり書くこと。能動態で書くと、わかりやすい資料になる。

    それ以外は、全体の概念把握としては良い本だった。読みやすかった。

    レビューの続きを読む

    投稿日:2024.05.11

  • oto-san

    oto-san

    ▼感想
    ・これまで数冊プロジェクトマネジメントに関する本を読んできましたが、上位に値するくらい内容量もわかりやすさも良かったです。

    ・当方は、「PJ計画」、「要件定義(非機能要件含む)」、「テスト」が特に理解が深まりました!続きを読む

    投稿日:2024.03.13

  • ケビン

    ケビン

    評価3.5
    PMとはざっくりどんな感じなのかを知るために本書を手に取った。
    網羅的に基本的なことが紹介、解説されていて入門者にはとてもよかった。

    投稿日:2024.02.11

  • tamamushiiro

    tamamushiiro

    ・関係者(発注者/ベンダー/メンバー/関連企業)が対等に話し合える関係性を築く
    ・プロジェクトマネージャーが多忙もしくは能力不足で全体観を失わないようにする

    マネジメントは管理だけではない
     管理:状況確認(計画との差分)、作業アサイン
      →計画に固執する
     マネジメント:管理+目的達成に必要な判断、全体像の把握、事前調整
      →リスク把握し、アクティブな調整を行い、計画にフィードバックさせる
    ■交渉
     ・説明資料と議事録は文書化
     ・フォーメーションを組む:重要度、費用と進捗課題は人を分けるなど
    ■タスクマネジメント
     ・タスクを洗い出す→優先順位つける→メンバアサイン→振り返りKPT
     ★タスク名は「○○を○○する」で記載
      いつまでに、は期限ではなく工数で記載
     ・ガントチャートの欠点
      タスクの抜け漏れ、
      納期に合わせたスケジュールになりやすい(逆線表)
      追加、変更管理が煩雑
      メンバが「学生症候群=ぎりぎりにやる」になりやすい
     ・メンバアサイン
      背景、目的も伝える
      完了条件を認識合わせる(優先度、期限とともに)
     ★定期的な振り返り
    ■プロジェクト計画
     ・目的、前提条件
      座組(体制図)、意思決定者、利害関係者、予算、日程、要求
      を確認する
      (目的、前提条件を優先的に確認。後から変更難しい)
     ・開発体制
      スクラム(≒アジャイル)開発はメンバスキル必要、予算&日程が流動的
      →納期・予算厳守の開発には向かない

    ■見積
     ・工数見積もり→費用と日程を組み立てるが鉄則
     ・ざっくり見積もり: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達成が目的ではない
     プロダクト改善費用
      保守運用のみ、保守運用+改善、保守運用+大型改善
      それぞれの対応工数を見積もる
     ファネルモデルを作る
    続きを読む

    投稿日:2024.02.03

Loading...

クーポンコード登録

登録

Reader Storeをご利用のお客様へ

ご利用ありがとうございます!

エラー(エラーコード: )

本棚に以下の作品が追加されました

追加された作品は本棚から読むことが出来ます

本棚を開くには、画面右上にある「本棚」ボタンをクリック

スマートフォンの場合

パソコンの場合

このレビューを不適切なレビューとして報告します。よろしいですか?

ご協力ありがとうございました
参考にさせていただきます。

レビューを削除してもよろしいですか?
削除すると元に戻すことはできません。