skillup

技術ブログ

ドキュメント作成 プロジェクト管理

プロジェクトマネジメントについて

投稿日:2021年4月29日 更新日:

ある程度、大規模なプロジェクトを経験させていただき、経験だけでなくプロジェクトマネジメントを体系的に理解しておきたいため、ポツポツと本を読んでます。

比較的初心者でも読みやすいと思った本としてを2冊メモ。

紙1枚に書くだけでうまくいく プロジェクト進行の技術が身につく本

プロジェクトの現状と目標を1枚絵で俯瞰して進めていこうという本です。

  • プロジェクトにおいて未知のものと、既知のものを分類する
  • 未知なものがわかっていないことが多いので、未知なものが出る前提で考える
  • 未知がどんどん膨らんでいくので未知のものを明らかにしていくプロセスが大切
  • 言語の認識を合わせる(よく出てくる頻出単語、〜までできた時のアウトプットの定義)
  • ファジーな言葉については図解や具体化を入れる
  • やりたいことの整理、整頓(要望そのものではなく、背景にある要求は何か、全体的にそれを解決する方法はないか。現在は何で代替していて、困っていることは何?)
  • 具体的なアウトプットのイメージ(モックや紙芝居)
  • 過去の類似のものなどないか
  • プロジェクトの成功は「理想と現実の間を往復し、本当にやりたかったことを実現すること」
  • 手段の目的化(過剰な書類、会議など・・・)に陥らないこと
  • 各工程におけるインプットとアウトプットの関係性を明確にイメージ
  • 現在の状況→対策(具体的な対策)→中間目標→勝利条件(プロジェクトの成功条件:数値化された定義)→未来のあるべき姿(プロジェクトの目標)をわかりやすく記述する必要がある。本ではこれを一枚絵「プ譜」として表現している
  • ありたい姿から逆算して具体的な行動を考える
  • 考えなくてはいけない要素は人材、予算、納期、品質、ビジネスモデル、環境、競合、外敵
  • 自分たちは何を持ち、何が不足していて、どんな環境に置かれているかを把握する
  • 勝利条件はできるだけ具体的にかく(戦略指標的なもの)売上1000万ではなく、新規や既存の顧客の分類や具体的な属性など対策をコントロールできるものにする
  • 勝利条件と目標は複数立てたほうがわかりやすいかも・・・
  • 具体的なプロジェクトを進めていく上で、プ譜をどんどん書き換えていく(プロジェクトは管理するのではなくて、編集する)

ネットでプ譜で検索すると結構色々出てくるのでサンプルを見てイメージがつきやすそうであれば真似てみるといいと思います。

もう1冊はスタンダードなWBSを使った本

図解 これ以上やさしく書けない プロジェクトマネジメントのトリセツ

  • プロジェクトとは「特定の目的」達成を「臨時の組織、構成員」で行うことであり、定型的な日常業務とは一線を画すことが多い
  • 当たり前だが特定の目的を明確化しておく必要がある
  • 上記の要因から制約条件、作業計画、スケジュール、コミニケーションチャネル、仕組みの明確化が必要
  • 企画、基本設計、詳細設計、製造、導入・運用のフェーズに分けられることが一般的
  • 企画と基本設計の段階でコストの大半が決まる
  • フェーズ間では必要になるスキルが異なることから人員が分けられることが一般的だが、現実的にはドキュメントだけで全ての情報を掬い上げることが難しいため、設計の意図などを聞くために企画〜基本設計のメンバーが存在している必要がある
  • それぞれのフェーズでのインプットとアウトプットを明確化しておくこと
  • ウォーターフォール(フェーズ間をきっちり分けて進行してさせていく)、スパイラル(プロトタイプなどを作り、工程間の行き来をする)
  • フェーズ間でWBS(WorkBreakdownStructure)を行う=構造化され、細分化されたタスクの詳細化を行う。
  • WBSの管理にはガントチャートが一般的。この時点で見積もりを行う
  • 起こりうるリスクについてリストアップし、リスクマネジメントを行う

2冊+自分の経験も踏まえを、共通すべきエッセンスなどを。

  • 目的の明確化→中間目標→タスクの詳細化(タスクの粒度は最低でも2日程度)
  • ルールや言葉などの明確な定義(タスクの終了など何を定義とするか)
  • 未知のトラブルを前提として考え、バッファを用意しておく
  • インプットとアウトプットのイメージの明確化
  • 進捗の可視化(全員がすぐに把握できるようになっておくこと)、リスクコントロール
  • スケジュールは生き物なので動的に変更すると考え、編集していく

-ドキュメント作成, プロジェクト管理
-

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

no image

テスト対策(単体テスト、結合テスト、総合テスト)

単体テスト、結合テストで発生した障害の分析(どんな障害が起こって、原因はなんで、再発防止に関してどうすべきか)なんかをやってます。 個人的に各フェーズで留意する点などを。 Contents1 共通2 …

no image

コレクションの頻出処理に関して

PHPでコレクションを使っていますが、慣れると本当に便利ですね・・・まあforeachとかでグリグリやってもいいのですが、無駄にコードが長くなります。 自分がコレクションでよく使う再頻出のメソッドなど …

no image

ファジープロジェクト対策 その2

前回に引き続き、大事だと思ったこと。一部単なるフレームワークの作り方的な内容になっているかも。 Contents1 テンプレート共通化2 バリデーション3 ログ出し4 異常系の処理5 新規プラグイン+ …

no image

テスト環境のデータ作りに関して

単体テスト以降の環境ですとテストのデータを作ることがなかなか大変だと思います。マスタなどはそのままもらうこともあると思いますので、主にトランザクションデータについて。 以前もこのネタに関しては色々書い …

no image

仕様の把握で見るポイント

新しい現場に入って技術的な部分はもとより仕様の把握などでポイントになる点などを。 Contents1 ER図2 ステータス変更3 プレイヤー(イベント)整理4 タイムテーブル5 マトリックス表6 ダミ …

アーカイブ