skillup

技術ブログ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

執筆者:


comment

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

関連記事

no image

ディレクション時に重要な視点

ディレクション(ベンダーや内製時)時に留意するポイント Contents1 開発ルールの構築2 アサインと人材スクリーニング3 言葉の共通化(特にアウトプット)4 問題化のキャッチアップ5 リソースの …

no image

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

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

no image

テーブル設計に関するメリデメ

昨日も書いた記事なんですが、基本的に実装にしても設計にしてもこれが最強っていう手法はなくて(あったとしたら全員がそれを使うのでそもそも選択肢という概念がなくなる・・)メリットデメリットをしっかりと考慮 …

no image

エンジニアの評価指標の策定について

営業の方であれば、月間の売上以外に新規の見込み数や、見込み客でも確度別の分類数など様々な指標で評価されることが一般的だと思います。 これらは「結果」に対する指標なのですが、それ以外でも見込み客に対する …

no image

使える設計書作成に関して

私自身、この仕事を7〜8年やっておりますが、設計書作成については常に悩まされておりました。 設計書のメリット・デメリットとしては以下のようなものですかね。 メリット メンバー間での仕様の認識を統一でき …

アーカイブ