Upgrade to Pro — share decks privately, control downloads, hide ads and more …

PM育成プロジェクト資料(公開用抜粋版)

Avatar for danishi danishi
December 12, 2023

 PM育成プロジェクト資料(公開用抜粋版)

社内で実施したプロジェクトマネジャー育成研修の抜粋資料。
Google Slidesで作ったら太字が潰れました…。

Avatar for danishi

danishi

December 12, 2023
Tweet

More Decks by danishi

Other Decks in Education

Transcript

  1. PM育成プロジェクトの目的 (人事戦略セクションより) 3 
 ◆PM育成研修実施の目的:
 iretのPM人財をPM未経験社員から育成するため。
 
 
 ◆受講者に求めること:
 現役PMの元、実案件ベースのOJTや講習、ロールプレイでの実践的な経験を通し
 iretのPMとしての案件推進のノウハウ獲得を目指す。


    
 
 ◆研修後について
 ・受講者によるアクションプランの作成
 ・研修で学んだことの蓄積・活用についての追跡調査(半年〜1年予定)
   ・対象:参加者本人 / 上長及びチームメンバー
   ・内容:アクションプラン及び研修で学んだことの実践状況
 
 

  2. PMに求められるスキル 9 • ビジネスの理解(お金の流れ、契約書、法律)
 • プロジェクトマネジメント手法の体系的な理解とプロジェクトに合わせ たテーラリング
 • プロジェクトを取り巻く要素(業務、要件、設計、技術)への理解
 •

    プロジェクトの情報を蓄積/整理/取得/共有/活用する
 • 人間力(リーダーシップ、メンタリング、ファシリテーション、ユーモア、 資料センス、ポジティブシンキング、アドリブ力、交渉力、決断力、スト レス耐性、etc…)

  3. プロジェクトの成功とは 17 プロジェクトのQCDを守ること
 QCDはトレードオフの関係と言われる
 炎上するとこれらをさらに犠牲にしなくてはいけない🔥
 炎上プロジェクトはQCDの駆け引きになりタフな交渉が必要になる
 だから炎上しないよう最善を尽くす🥺
 
 Quality
 品質

    
 Cost
 予算 
 Delivery
 納期 品質を求めすぎると 
 コストと納期に響く
 納期がきついと
 コストと品質を調整しないといけない 
 予算がカツカツだと
 納期と品質が守れなくなる 

  4. すごいわかりやすい例 33 要求定義
 • 外出先で雨が降ると濡れてしまって困るので雨に濡れないよう にしたい
 • 雨が降っていない時も携帯できるようにしたい
 要件定義
 •

    広げたビニールを棒で支え頭上を覆うことにより雨を弾くように する
 • ビニールを開閉できるようにすることでコンパクトに持ち運ぶこと ができるようにする

  5. 要件定義書 35 要求を分析し、要件を具体化、言語化、図式化、方法論化しスコープと実現方法にズレがな いように定義してドキュメントにし合意したものが要件定義書。
 
 一般的に要件定義書は以下のようなドキュメントを作成する。
 ※物理レベルの設計は行わず論理レベルに留まることがほとんど 
 ※もちろんプロジェクトの性質や工期、工数、納品物定義によって用意す るドキュメント数や種類、粒度は異なる

    
 • 業務一覧
 • 業務フロー図(旧・新)
 • 機能一覧
 ◦ 画面一覧
 ◦ 帳票一覧
 ◦ バッチ一覧
 ◦ I/F一覧
 ▪ API一覧
 • テーブル一覧
 ◦ ER図
 ◦ CRUD表
 • ワイヤーフレーム
 • 画面遷移図
 • システムフロー・データフロー
 • ユーザーロール定義・権限一覧
 • 用語集
 • フィット&ギャップ一覧
 • システム俯瞰図
 • システム処理定義書
 • 運用計画書
 • 移行計画書
 • その他
 ◦ プロジェクト管理資料
 ▪ WBS、課題管理表、QA 表、体制表、etc…
 ▪ 議事録
 ◦ 非機能要件定義書(※)

  6. 非機能要件定義 36 最初の傘の例だと
 • 重量は1kg以内とする
 • 量産コストは1本500円以内とする
 • 盗難対策のためGPSを搭載すること
 •

    強い風雨の際は機能しないことを許容する
 など
 システムの主たる目的となる機能以外に満たしておく必要がある 要件を非機能要件という。

  7. 非機能要件定義書 37 一般的に非機能要件定義書では以下のようなドキュメントを作成したり、項目を定義する。
 • 非機能要件定義書
 ◦ 可用性
 ◦ 運用・保守性
 ▪

    監視
 ▪ セキュリティ
 ▪ ログ
 ◦ 性能・拡張性
 ◦ データ移行
 ◦ 効果目標
 ◦ 技術要件
 ◦ 環境
 ◦ 教育
 • インフラ構成図
 ◦ ハードウェア構成図
 ◦ ネットワーク図
 • セキュリティチェックシート
 ※要件定義書とかぶる部分もある

  8. 資料整理のコツ 39 • うまく資料を階層化することでどこに何があるか確認しやすくなる
 • どこに何を入れるかをプロジェクト内でルール化し浸透、徹底させることが重要
 ※番号をつけるのは任意のフォルダ名で並べるためのテクニック
 プロジェクト名
 ├───00.プロジェクト管理
 │

    ├───提案依頼書(RFP)
 │ ├───見積・提案書
 │ ├───スケジュール(WBS)
 │ ├───課題管理
 │ ├───議事録
 │ └───etc...
 ├───10.要件定義
 │ ├───業務フロー
 │ ├───システム構成
 │ ├───機能一覧
 │ ├───移行設計
 │ └───非機能要件
 │ │ ├───インフラ構成
 │ │ └───ネットワーク構成
 │ ├───議事録
 │ └───etc...
 ├───20.基本設計
 │ ├───画面・帳票定義書
 │ ├───バッチ設計書
 │ ├───I/F設計書
 │ ├───テーブル設計書
 │ └───etc...
 ├───30.詳細設計
 ├───40.製造・単体テスト
 ├───50.結合テスト
 ├───60.総合テスト
 ├───70.受入テスト
 ├───80.カットオーバー
 ├───90.運用保守
 └───XX.その他
 

  9. 基本設計・詳細設計資料 44 一般的に基本・詳細設計書は以下のようなドキュメントを作成する。
 ※論理ではなく物理レベルの設計を行う 
 ※もちろんプロジェクトの性質や工期、工数、納品物定義によって用意す るドキュメント数や種類、粒度は異なる 
 • UML


    ◦ DFD、クラス図、シーケンス図、ア クティビティ図(フローチャート)、 ユースケース図、etc…
 • 画面設計書(画面デザイン)
 • 帳票設計書
 • バッチ設計書
 • ジョブスケジュール設計
 • I/F設計書
 • API仕様書
 • 共通処理定義書
 • 命名・コーディング規約
 • ログ設計
 • テーブル定義書
 • コード定義書
 • メッセージ一覧
 • パラメーターシート
 • システム構成図
 • 運用手順書
 • 移行手順書

  10. 資料作成のコツ 45 • 「神は細部に宿る」。資料は可能な限り細かさ美しさ、分かりやす さを追求しよう。
 • 表現したいものに応じて柔軟にドキュメンテーションツールを選定 しよう。1画面で伝えたいならパワポ、計算やマスを使って表すな らExcel、帳票など印刷するものならWord、広い図面が必要なら 作図ツールなどなど。


    • API仕様書などは製造工程にそのまま使えるようなツールを選定 すると製造工数の圧縮につながる(例:OpenAPI)
 • どのようなフォーマット、粒度で作成するかは作り始める前に同意 を得ておくと根本からひっくり返されない。

  11. 開発工程に入る前に 50 開発工程に入りました!ですぐ開発がスムーズに進められるかというとそうではない。
 開発工程に入る前に以下のようなことを開発メンバーで認識合わせておくとスタートダッシュが切 れる🚀
 ※プログラミング言語やフレームワーク、ソース管理手法などは提案、要件定義時に合意しておいたほうがよい。 
 • 利用プログラミング言語
 •

    利用フレームワーク・ライブラリ
 • ローカル開発手順書
 • ソース管理手法、ブランチ運用ルール
 • 共通モジュール定義
 • 命名・コーディング規約
 • コードレビュールール
 • 開発課題管理ルール
 • ライブラリ管理ルール
 • テストコード
 • CI/CD
 • 単体テストフォーマット
 • 仕様・実装問い合わせフロー
 • 開発リーダー(サブシステムごとに分けて もよい)
 • フロントエンド、バックエンドなどの役割分 担
 • 開発定例ミーティング

  12. 単体テストのフォーマット 53 単体テストの仕様書、エビデンスまで成果物として提出を求められることは稀だがどの ように単体テストを行うか定義しておくことは品質の確保に繋がる。
 
 前提として機能単位の仕様を満たしているかのチェックを行う必要がある。
 
 そのためのフォーマットとしてよくあるパターンは以下のようなもの。
 • テスト仕様書を起こすパターン(+αエビデンスを添付)


    • 詳細設計書にチェックリストがついててそのままテスト仕様書になるパター ン(+αエビデンスを添付)
 • テストコードの合格とコードレビューで担保するパターン
 • Pull Requestの中でチェックリストを儲けて、テストコードとともに担保するパ ターン(+αPRの中に実施エビデンスを残す)
 ※これらの組み合わせもあり得る

  13. 進捗の管理 54 • 進捗管理のためにWBSを活用する。細かくなってしまう場合は別途開発用 にブレークダウンした進捗管理表を作ってもよい。
 • バッファは積んでおくがその存在は開発者には知られないようにする (パーキンソンの第一法則「仕事の量は、完成のために与えられた時間を すべて満たすまで膨張する」)。
 •

    実装者が多い場合は進捗管理を開発リーダーに行わせる。どこが詰まっ ているなどの実装レベルの話の目線が合う人間が間に入ることで管理や アドバイスが円滑になる。
 • 進捗が上がらないときは放置せず、上がらない原因をメンバーと協力して 見つけ対処を行う。社内外の協力が必要な場合は自らが調整役となり動く こと🔥

  14. 結合試験のポイント 60 • システムの入り口(ログインなど)やコア機能から順に行うとスムーズ。 開発が遅延するなどして工程がオーバーラップした場合も入り口の開 発優先度をあげて枝葉の機能が後回しになるようにした方がよい。
 • データを入力する機能から行い、入力されたデータを参照する機能の 順にテストする。テストデータを手動で入れて検証するのは避ける。
 •

    日付や時間の概念が絡むテストは念入りに行う、日付や時間をパラ メータ化して動かせるようにしておくとリアルタイムで実施しなくて済む。
 • なるべく本番に近い環境でテストできるように調整を行う。
 • なるべく本番に近いデータでテストできるようにする。
 • テスト専用環境を作った方がいい。

  15. 総合・受入テスト • 総合テストに分類される
 ◦ システム間連携テスト
 • 総合テスト・受入テストに分類される
 (顧客手動で行うことがある)
 ◦ ユーザーテスト


    ◦ 業務シナリオテスト
 ◦ 並行稼働テスト(現新比較テスト)
 ◦ 非機能テスト
 ▪ 負荷試験
 ▪ 脆弱性試験
 ▪ 障害試験(アラート、リカバリ、リストア、DR)
 61 総合試験、ST(System Test)とも。
 他システムとの連携も合わせてシステム全体としての統制をテストする。
 
 受入試験、UAT(User Acceptance Test)とも。
 顧客が完成したシステムを自らの要件が満たされてるか確認するためのテスト。ユーザー主 導で行われることが一般的だが、非機能テストについては開発ベンダー自身が実施する場合 もあるが、顧客が用意したベンダーによって実施されることがある。

  16. 納品 70 受入テストが通りシステムが完成し、それを納めるフェーズ。
 プログラムは形がないものなので、代わりに受領できるものとしてソースコード やドキュメントを納めることが多い。
 
 納品物は基本的に発注時に定められ以下のようなものを納めることが一般的 (請負契約では)。
 • 設計ドキュメント(要件定義書、基本設計書)


    • プログラム(ソースコード、リポジトリ)
 • テスト仕様書、テスト実施結果報告書、マニュアル
 発注時に定義されているとはいえ、納品物のフォーマットやレベル 感は早めに合わせておきましょう。
 顧客によってはMS Word形式で欲しいなど作成コストのかかる方 法を求められることも。
 納め方についても注意が必要。令和にCD ROMに焼いてくれなん てことも…。

  17. 安定した運用を続けていくために必要なこと 79 • 十分な各種ログ、メトリクス、監視体制
 • 保守しやすいコード(可読性、変更容易性)
 • デグレを起こさないコード管理
 • リスクの少ないデプロイ


    • パフォーマンスの安定したインフラ
 • 問い合わせが発生しにくい作り(親切なUI、メッセージ、わかりやすい仕様)
 • 整備された仕様書、運用ドキュメント
 • 整備された問い合わせフロー
 • タスク、不具合のチケット管理
 • 属人性のない持続可能な保守体制
 • 必要十分な保守工数