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

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

Transcript

1. ©アイレット株式会社 第四開発事業部 第三開発セクションリーダー 西田 駿史 第４回PM育成プロジェクト資料（公開用抜粋版） 2023/12/11
2. キックオフ 2
3. PM育成プロジェクトの目的　（人事戦略セクションより） 3 
 ◆PM育成研修実施の目的：
 iretのPM人財をPM未経験社員から育成するため。
 
 
 ◆受講者に求めること：
 現役PMの元、実案件ベースのOJTや講習、ロールプレイでの実践的な経験を通し
 iretのPMとしての案件推進のノウハウ獲得を目指す。
 
 
 ◆研修後について
 ・受講者によるアクションプランの作成
 ・研修で学んだことの蓄積・活用についての追跡調査（半年〜1年予定）
 　　・対象：参加者本人 / 上長及びチームメンバー
 　　・内容：アクションプラン及び研修で学んだことの実践状況
 
 

4. 研修の方針 4 • プロジェクトの各工程におけるPMの心得を実際のプロジェクト成果物や講師の実体験と合わせて学んでいく • 世の中のプロジェクト管理における教科書的な内容だけでなくアイレットでの案件推進に活きる知識を伝える 研修内容 要求/要件定義 営業/RFP/見積/提案/受注 上流工程　　　　　　　　　　　　　　　　　　下流工程 運用・保守 基本設計 受入テスト 総合テスト 結合テスト 製造 詳細設計 単体テスト 企画 製 造 工 程 テ ス ト工 程 対応するテスト 納品/検収/保守契約 ※ただし講師の個人的見解を多分に含みます 4
5. 第１回 〜Youは何しにPM研修へ〜 5
6. プロジェクトマネジメントとは 6 プロジェクトマネジメントとは？

7. プロジェクトマネジメントとは 7 「みんなが気持ちよく仕事できるようにすること」 『なれる！SE4 誰でもできる？プロジェクト管理』より
 「みんな」とはプロジェクトのステークホルダー（プロジェクトに関心を 持つ人）つまり発注元顧客、決済者、プロジェクトメンバー、他ベン ダー、エンドユーザー
8. プロジェクトマネジメントとは 8 PMBOKではプロジェクトは「独自性」と「有期性」という言葉を用いて定義され ている。
 プロジェクトに「独自性」があるということは「初めてやる」ものであり、「有期性」が あるということは「明確な始まりと終わり」がある。
 つまりプロジェクトマネジメントというのは、「初めてやる」プロジェクトを「問題なく 期間内」にマネジメントするという究極の難しさを孕む。
 『プロジェクトのトラブル解決大全　小さな問題から大炎上まで 使える「プロの火消し術86」』より文言引用
 PMによってプロジェクトの成否がほぼ決まる。
 責任重大🥶

9. PMに求められるスキル 9 • ビジネスの理解（お金の流れ、契約書、法律）
 • プロジェクトマネジメント手法の体系的な理解とプロジェクトに合わせ たテーラリング
 • プロジェクトを取り巻く要素（業務、要件、設計、技術）への理解
 • プロジェクトの情報を蓄積/整理/取得/共有/活用する
 • 人間力（リーダーシップ、メンタリング、ファシリテーション、ユーモア、 資料センス、ポジティブシンキング、アドリブ力、交渉力、決断力、スト レス耐性、etc…）

10. PMに求められるスキル 10 ビジネスの理解（お金の流れ、契約書、法律）
 プロジェクトには大きなお金が動く、営業がいるとはいえお金の話が出 来なくてはいけない。
 契約形態や法律に関しても意識しておかなければ思わぬ落とし穴にハ マることも。
 商流が複雑だったり大企業相手のプロジェクトになるとこの傾向が強ま る。
 ボランティアではないため自社の売上やコストも意識する必要がある。

11. PMに求められるスキル 11 プロジェクトマネジメント手法の体系的な理解とプロジェクトに合わせた テーラリング
 プロジェクトマネジメントにはセオリーがあり、体系的な手法、ドキュメン トも存在する（PMBOK）。
 ただし、いついかなる時もそれらが当てはまるとは限らない。
 プロジェクトには独自性があり、常に有効な銀の弾丸は存在しない。
 セオリーを押さえた上でプロジェクトに応じて組み合わせ、アレンジして 取り入れていくテーラリングを行っていくことが必要。

12. PMに求められるスキル 12 プロジェクトを取り巻く要素（業務、要件、設計、技術）への理解
 プロジェクトには多くの専門家が集まっている。
 PMはそれら関係者の言ってることを完璧でないにしろ、誰かの手を借り ながらにしろ理解出来なくてはならない。
 専門家たちをまとめ上げるのに無知でいてリーダーシップをとれるはず がないし、顧客の信用も得られない。
 特にエンジニアという人種は無知な人をリスペクトしない。

13. PMに求められるスキル 13 プロジェクトの情報を蓄積/整理/取得/共有/活用する
 プロジェクトは情報の塊であり、進行の都度新しい情報が生まれてい く。
 それらを漏らさないよう蓄積し、アクセスしやすく整理し、状況に適したも のを取得し、関係者に共有し、プロジェクトの推進に活用していく。その ためのプロジェクトインフラを整える。

14. PMに求められるスキル 14 人間力（リーダーシップ、メンタリング、ファシリテーション、ユーモア、資 料センス、ポジティブシンキング、アドリブ力、交渉力、決断力、ストレス 耐性、etc…）
 メンバーを引っ張るリーダーシップ、メンバーを鼓舞するメンタリング、 MTGを円滑に回すファシリテーション、アイスブレイクのユーモア、伝わる 資料を生み出すセンス、困難な状況を逆転するポジティブシンキング、初 見の状況に対処するアドリブ力、プロジェクトのために必要なことを通す 交渉力、物事を前に進めるための決断力、困難に直面しても逃げ出さな いストレス耐性、その他色々。
 ※プロジェクトメンバーの誰かがそれを補うこともある

15. PMに求められるスキル 15 PMすごすぎん？

16. PMに求められるスキル 16 PMはプロジェクトの花形🌸
 責任は重いがプロジェクトを成功に導ける唯一人の存在
 『大いなる力には、大いなる責任が伴う』
 『With great power comes great responsibility』
 映画『スパイダーマン』より

17. プロジェクトの成功とは 17 プロジェクトのQCDを守ること
 QCDはトレードオフの関係と言われる
 炎上するとこれらをさらに犠牲にしなくてはいけない🔥
 炎上プロジェクトはQCDの駆け引きになりタフな交渉が必要になる
 だから炎上しないよう最善を尽くす🥺
 
 Quality
 品質 
 Cost
 予算 
 Delivery
 納期 品質を求めすぎると 
 コストと納期に響く
 納期がきついと
 コストと品質を調整しないといけない 
 予算がカツカツだと
 納期と品質が守れなくなる 

18. まとめ 18 • プロジェクトマネジメントはとても難しい
 • PMは多様なスキルが必要だがその分希少価値がある
 • QCDを守ることがPMの使命であり責任

19. 宿題 19 あなたが
 
 • このPM研修で学びたいこと
 • PM研修で学ぶことをアイレットでのキャリアにどう活かしていきたいか
 
 を次回までに考えてきてください。
 ※宿題は毎回出すので忘れないように👹

20. 第２回 〜案件はどこからくるか〜 20
21. 研修の方針 21 • プロジェクトの各工程におけるPMの心得を実際のプロジェクト成果物や講師の実体験と合わせて学んでいく • 世の中のプロジェクト管理における教科書的な内容だけでなくアイレットでの案件推進に活きる知識を伝える 今日話すこと 要求/要件定義 営業/RFP/見積/提案/受注 上流工程　　　　　　　　　　　　　　　　　　下流工程 運用・保守 基本設計 受入テスト 総合テスト 結合テスト 製造 詳細設計 単体テスト 企画 製 造 工 程 テ ス ト工 程 対応するテスト 納品/検収/保守契約 ※ただし講師の個人的見解を多分に含みます 21
22. 企画 22 クライアントが何か実現したいと思う時企画 が立ち上がる
 それは新しいビジネスだったり、社内の問題点の改善だった り、問題を抱えた既存システムの改善、偉い人の思いつき だったり様々

23. 企画 23 企画は企画書やRFP（提案依頼書）という形にまとめられて外 部のベンダーの協力が必要な場合は提案依頼が行われる（ま とめられてないときもある）
 このときクライアントだけの力ではまとめ切ることができないと きコンサルが入ってまとめることがある

24. RFP 24 提案依頼書。要はこういうものを作りたいという情報を出すから 各社提案してくれという文書。
 
 RFPを作るための情報提供をベンダーに依頼するRFI（情報提供 依頼書）というものもある（あまり見たことはない）

25. 見積 25 RFPや顧客へのヒアリングをベースにどれだけコストがかかる か見積もる。
 
 顧客のお財布事情（予算）と駆け引きしつつ、この時点で要求 を落としたり、無茶なことを引き受けないよう前提条件を握る。
 
 この時点では精度が低いため概算見積もりとし、要件定義後 に改めて精緻化することもある。

26. 提案書 26 見積だけで済む場合もあるが顧客への更なるアピールや複数 社コンペの場合に用意する。
 
 見積もりだけでは伝わらない、「実際にこんなふうにRFPを実現 しますよ」ということを伝えるための資料
 
 顧客が偉い人に予算を出してもらうための資料としても使われ るので非常に重要。

27. 受注 27 晴れて提案が通り、プロジェクトが成立したら受注となる。
 
 契約書、発注書を取り交わしキックオフの日程を決定する。
 
 キックオフでは正式なプロジェクトの座組やマスタースケジュール、コ ミュニケーション手法、プロジェクト管理手法を合意する。

28. まとめ 28 • プロジェクトが始まる前にもこれだけ工程があっていろんな 努力がある
 • クライアントは要件定義に入る前にすでにイメージ（期待、 妄想）が膨らんでいる
 • 請負と準委任の契約形態の違いを意識する
 • 営業フェーズとのバトンタッチをミスると出だしでコケるので プリセとの連携は綿密に

29. ちょっと先の宿題（案件提案シミレーション） 29 『超上流から攻めるIT化の事例集：各社資料一覧』の『RFP事例(要件定義)』を読み込 み提案書と見積もりを作って2023/XX/XX(X)の提案ワークで部長、副部長を顧客に 見立ててプレゼン提案を行っていただきます🔥
 
 やり方は問いませんのでこの後の研修の内容も踏まえつつ良い提案をみなさんで協 力して考えてください（相談はウェルカムです）！
 予算：3000万円
 スケジュール：2023/12キックオフ、2025/1リリース 
 提案骨子：クラウドを利用したアイレットならではの提案 
 必要なもの：提案書、概算見積
 プレゼン時間：30分
 その他：
 ・利用言語の指定は無視して得意なものを提案してよい。 

30. 第３回 〜作るために何を決めるか〜 30
31. 研修の方針 31 • プロジェクトの各工程におけるPMの心得を実際のプロジェクト成果物や講師の実体験と合わせて学んでいく • 世の中のプロジェクト管理における教科書的な内容だけでなくアイレットでの案件推進に活きる知識を伝える 今日話すこと 要求/要件定義 営業/RFP/見積/提案/受注 上流工程　　　　　　　　　　　　　　　　　　下流工程 運用・保守 基本設計 受入テスト 総合テスト 結合テスト 製造 詳細設計 単体テスト 企画 製 造 工 程 テ ス ト工 程 対応するテスト 納品/検収/保守契約 ※ただし講師の個人的見解を多分に含みます 31
32. 要求/要件定義 32 このプロジェクトで実現すべき要件を定義すること。
 RFPを挟まなかった場合など要件以前のレベルが決まっていない 場合さらに前段に要求定義を行うこともある。
 要求定義
 なにをなんのために行いたい か決める
 クライアントの要望・希望・実現 したいことを定義する
 
 要件定義
 要求を実現するために何を行う のか決める
 要求のうち実現するものとその 実現方法を（大まかに）定義する

33. すごいわかりやすい例 33 要求定義
 • 外出先で雨が降ると濡れてしまって困るので雨に濡れないよう にしたい
 • 雨が降っていない時も携帯できるようにしたい
 要件定義
 • 広げたビニールを棒で支え頭上を覆うことにより雨を弾くように する
 • ビニールを開閉できるようにすることでコンパクトに持ち運ぶこと ができるようにする

34. すごいわかりやすい例 34 そうして生まれたプロダクトがこれ
 

35. 要件定義書 35 要求を分析し、要件を具体化、言語化、図式化、方法論化しスコープと実現方法にズレがな いように定義してドキュメントにし合意したものが要件定義書。
 
 一般的に要件定義書は以下のようなドキュメントを作成する。
 ※物理レベルの設計は行わず論理レベルに留まることがほとんど 
 ※もちろんプロジェクトの性質や工期、工数、納品物定義によって用意す るドキュメント数や種類、粒度は異なる 
 • 業務一覧
 • 業務フロー図（旧・新）
 • 機能一覧
 ◦ 画面一覧
 ◦ 帳票一覧
 ◦ バッチ一覧
 ◦ I/F一覧
 ▪ API一覧
 • テーブル一覧
 ◦ ER図
 ◦ CRUD表
 • ワイヤーフレーム
 • 画面遷移図
 • システムフロー・データフロー
 • ユーザーロール定義・権限一覧
 • 用語集
 • フィット＆ギャップ一覧
 • システム俯瞰図
 • システム処理定義書
 • 運用計画書
 • 移行計画書
 • その他
 ◦ プロジェクト管理資料
 ▪ WBS、課題管理表、QA 表、体制表、etc…
 ▪ 議事録
 ◦ 非機能要件定義書（※）

36. 非機能要件定義 36 最初の傘の例だと
 • 重量は1kg以内とする
 • 量産コストは1本500円以内とする
 • 盗難対策のためGPSを搭載すること
 • 強い風雨の際は機能しないことを許容する
 など
 システムの主たる目的となる機能以外に満たしておく必要がある 要件を非機能要件という。

37. 非機能要件定義書 37 一般的に非機能要件定義書では以下のようなドキュメントを作成したり、項目を定義する。
 • 非機能要件定義書
 ◦ 可用性
 ◦ 運用・保守性
 ▪ 監視
 ▪ セキュリティ
 ▪ ログ
 ◦ 性能・拡張性
 ◦ データ移行
 ◦ 効果目標
 ◦ 技術要件
 ◦ 環境
 ◦ 教育
 • インフラ構成図
 ◦ ハードウェア構成図
 ◦ ネットワーク図
 • セキュリティチェックシート
 ※要件定義書とかぶる部分もある

38. 資料整理のコツ 38 • 資料を作るだけではなく、それを整理しないとプロジェクト関係者が 情報にアクセスしにくくなり、見てもらえなくなったり重複した資料が 発生する。
 • なるべく検索性のよいファイル管理ツールを使うとよい。格納ファイ ルの中身まで横断して全文検索ができるようなものがベター（Wiki、 Google Driveなど）
 • 賛否別れるかもしれないが１ファイルにつき１つの役割が望ましい。 1つのスプレッドシートなどにシートを増やして全ての情報を集めて いるケースがたまにあるが逆に取り回しが悪くなる。

39. 資料整理のコツ 39 • うまく資料を階層化することでどこに何があるか確認しやすくなる
 • どこに何を入れるかをプロジェクト内でルール化し浸透、徹底させることが重要
 ※番号をつけるのは任意のフォルダ名で並べるためのテクニック
 プロジェクト名
 ├───00.プロジェクト管理
 │ ├───提案依頼書（RFP）
 │ ├───見積・提案書
 │ ├───スケジュール（WBS）
 │ ├───課題管理
 │ ├───議事録
 │ └───etc...
 ├───10.要件定義
 │ ├───業務フロー
 │ ├───システム構成
 │ ├───機能一覧
 │ ├───移行設計
 │ └───非機能要件
 │ │ ├───インフラ構成
 │ │ └───ネットワーク構成
 │ ├───議事録
 │ └───etc...
 ├───20.基本設計
 │ ├───画面・帳票定義書
 │ ├───バッチ設計書
 │ ├───I/F設計書
 │ ├───テーブル設計書
 │ └───etc...
 ├───30.詳細設計
 ├───40.製造・単体テスト
 ├───50.結合テスト
 ├───60.総合テスト
 ├───70.受入テスト
 ├───80.カットオーバー
 ├───90.運用保守
 └───XX.その他
 

40. まとめ 40 • 要件・非機能要件定義はこのプロジェクトで何をどう実現するか 決定しステークホルダーと合意を得る重要フェーズ。ここが甘いと 後工程で破綻する。
 • 要件・非機能要件定義書は次工程の大切なインプット、成果物が ダメだと出来上がるシステムもダメになる（GIGO）。
 • システム開発は壮大な伝言ゲーム。その出発点が要件定義。
 上流から下流まで実現すべきことを齟齬なく伝えていくための工 夫を惜しまない。

41. 第４回 〜どうやって作るのか〜 41
42. 研修の方針 42 • プロジェクトの各工程におけるPMの心得を実際のプロジェクト成果物や講師の実体験と合わせて学んでいく • 世の中のプロジェクト管理における教科書的な内容だけでなくアイレットでの案件推進に活きる知識を伝える 今日話すこと 要求/要件定義 営業/RFP/見積/提案/受注 上流工程　　　　　　　　　　　　　　　　　　下流工程 運用・保守 基本設計 受入テスト 総合テスト 結合テスト 製造 詳細設計 単体テスト 企画 製 造 工 程 テ ス ト工 程 対応するテスト 納品/検収/保守契約 ※ただし講師の個人的見解を多分に含みます 42
43. 基本設計・詳細設計 43 外部設計、内部設計と呼ぶこともある。
 ぶっちゃけ明確に区切りがあるわけではなくプロジェクト、会社によって異なる が、より実装レベルに近いものを詳細設計と呼びがちである。
 
 基本設計まではクライアントにもエンジニアにも伝わる資料であることが重要。 なぜなら多くの場合、基本設計まで顧客レビューが入ることが多く設計書がディ スカッションにも使われるからである。詳細設計はエンジニアがわかれば基本 問題ない。
 
 要件定義で決めたことを具体的にどう実現していくか実装に落とし込むところま で見据えて、設計フェーズでドキュメント化していく。

44. 基本設計・詳細設計資料 44 一般的に基本・詳細設計書は以下のようなドキュメントを作成する。
 ※論理ではなく物理レベルの設計を行う 
 ※もちろんプロジェクトの性質や工期、工数、納品物定義によって用意す るドキュメント数や種類、粒度は異なる 
 • UML
 ◦ DFD、クラス図、シーケンス図、ア クティビティ図（フローチャート）、 ユースケース図、etc…
 • 画面設計書（画面デザイン）
 • 帳票設計書
 • バッチ設計書
 • ジョブスケジュール設計
 • I/F設計書
 • API仕様書
 • 共通処理定義書
 • 命名・コーディング規約
 • ログ設計
 • テーブル定義書
 • コード定義書
 • メッセージ一覧
 • パラメーターシート
 • システム構成図
 • 運用手順書
 • 移行手順書

45. 資料作成のコツ 45 • 「神は細部に宿る」。資料は可能な限り細かさ美しさ、分かりやす さを追求しよう。
 • 表現したいものに応じて柔軟にドキュメンテーションツールを選定 しよう。１画面で伝えたいならパワポ、計算やマスを使って表すな らExcel、帳票など印刷するものならWord、広い図面が必要なら 作図ツールなどなど。
 • API仕様書などは製造工程にそのまま使えるようなツールを選定 すると製造工数の圧縮につながる（例：OpenAPI）
 • どのようなフォーマット、粒度で作成するかは作り始める前に同意 を得ておくと根本からひっくり返されない。

46. まとめ 46 • たとえ理解してもらうのに苦労しても顧客に設計書のレビューは 絶対行ってもらい合意を得る。こうすることで後々のトラブルを防 げる。そのために設計書の理解しやすさにこだわること。
 • エンジニアが作るのに迷わないよう、間違ったものを作らないよ う、エンジニアにとっても情報の不足がないドキュメントを目指す。
 • PMが自分で手を動かす必要はないが作るものを理解し、監修し たりアドバイスできると信頼される。

47. 第５回 〜俺たちは何を作っているのか〜 47
48. 研修の方針 48 • プロジェクトの各工程におけるPMの心得を実際のプロジェクト成果物や講師の実体験と合わせて学んでいく • 世の中のプロジェクト管理における教科書的な内容だけでなくアイレットでの案件推進に活きる知識を伝える 今日話すこと 要求/要件定義 営業/RFP/見積/提案/受注 上流工程　　　　　　　　　　　　　　　　　　下流工程 運用・保守 基本設計 受入テスト 総合テスト 結合テスト 製造 詳細設計 単体テスト 企画 製 造 工 程 テ ス ト工 程 対応するテスト 納品/検収/保守契約 ※ただし講師の個人的見解を多分に含みます 48
49. 製造工程 49 開発工程とも
 
 順調に行ってれば本来PMが一番暇になるフェーズ。
 暇にならない場合はこれまでの進行がよくなかったり、役割分担、チームビル ディングが悪いと思った方がよい。
 

50. 開発工程に入る前に 50 開発工程に入りました！ですぐ開発がスムーズに進められるかというとそうではない。
 開発工程に入る前に以下のようなことを開発メンバーで認識合わせておくとスタートダッシュが切 れる🚀
 ※プログラミング言語やフレームワーク、ソース管理手法などは提案、要件定義時に合意しておいたほうがよい。 
 • 利用プログラミング言語
 • 利用フレームワーク・ライブラリ
 • ローカル開発手順書
 • ソース管理手法、ブランチ運用ルール
 • 共通モジュール定義
 • 命名・コーディング規約
 • コードレビュールール
 • 開発課題管理ルール
 • ライブラリ管理ルール
 • テストコード
 • CI/CD
 • 単体テストフォーマット
 • 仕様・実装問い合わせフロー
 • 開発リーダー（サブシステムごとに分けて もよい）
 • フロントエンド、バックエンドなどの役割分 担
 • 開発定例ミーティング

51. 開発工程の注意点 51 • 技術的にチャレンジングな機能など実現可能性が設計時点では確証 が得られないものは、なるべく早めに小さなプロトタイプを作って、技術 的に可能であることの裏どりをしておくとリスクが少ない。
 • 開発メンバーの実装能力にばらつきがある場合は、あらかじめ実装能 力の高いメンバーにお手本の機能を作らせてそれを横展開させて作る ように進めると、品質のばらつきをある程度防げる。
 • プロジェクト全体のコードの品質に責任を持つ役割のメンバーを作る。 放置すると汚いコードは増殖していくことを心得る（割れ窓理論）。
 • PMが直接実装を行うのは最終手段。メンバーを信じて任せ切ること

52. 単体テスト 52 古くは純粋なプログラムモジュール単体のテストを指したが、最近は一機能に 閉じたテスト（機能テスト）の意味合いで使われることが多い。
 
 テストコードで検証する最小単位（ユニットテスト）が本来の意味の単体テストに 近いかも。
 
 テストコードを書くにしろ書かないにしろ、いち実装担当者で検証できる範囲を 単体テストとしておくと進捗管理が楽。

53. 単体テストのフォーマット 53 単体テストの仕様書、エビデンスまで成果物として提出を求められることは稀だがどの ように単体テストを行うか定義しておくことは品質の確保に繋がる。
 
 前提として機能単位の仕様を満たしているかのチェックを行う必要がある。
 
 そのためのフォーマットとしてよくあるパターンは以下のようなもの。
 • テスト仕様書を起こすパターン（＋αエビデンスを添付）
 • 詳細設計書にチェックリストがついててそのままテスト仕様書になるパター ン（＋αエビデンスを添付）
 • テストコードの合格とコードレビューで担保するパターン
 • Pull Requestの中でチェックリストを儲けて、テストコードとともに担保するパ ターン（＋αPRの中に実施エビデンスを残す）
 ※これらの組み合わせもあり得る

54. 進捗の管理 54 • 進捗管理のためにWBSを活用する。細かくなってしまう場合は別途開発用 にブレークダウンした進捗管理表を作ってもよい。
 • バッファは積んでおくがその存在は開発者には知られないようにする （パーキンソンの第一法則「仕事の量は、完成のために与えられた時間を すべて満たすまで膨張する」）。
 • 実装者が多い場合は進捗管理を開発リーダーに行わせる。どこが詰まっ ているなどの実装レベルの話の目線が合う人間が間に入ることで管理や アドバイスが円滑になる。
 • 進捗が上がらないときは放置せず、上がらない原因をメンバーと協力して 見つけ対処を行う。社内外の協力が必要な場合は自らが調整役となり動く こと🔥

55. 昔話 55 私が新卒で入社した歴史のあるシステム会社では「一つのプログラムの進捗は 実装が終わって50%、単体テストが終わって100%」と口酸っぱく言われました。
 
 組み上がったつもりでもまだバグは隠れてて、その進捗は半分でしかないとい うことを表現していたのです。
 
 実際プログラマにごとに進捗見積の精度や匙加減が違うので、進捗率の定義 は事前に明確にしておくとよいでしょう。

56. まとめ 56 • PMは直接開発を推進する必要はない。全体の進捗管理とコミュ ニケーションの交通整理に努める。自身の経験からアドバイスを 行う。
 • 定期的に設計と間違った方向に進んでいないか、設計自体に間 違いがないか、メンバーを集めてレビューを行い目指すべき完成 形への認識を合わせ、常に少し先のゴールを掲示する。

57. 第６回 〜これちゃんと作れたのか〜 57
58. 研修の方針 58 • プロジェクトの各工程におけるPMの心得を実際のプロジェクト成果物や講師の実体験と合わせて学んでいく • 世の中のプロジェクト管理における教科書的な内容だけでなくアイレットでの案件推進に活きる知識を伝える 今日話すこと 要求/要件定義 営業/RFP/見積/提案/受注 上流工程　　　　　　　　　　　　　　　　　　下流工程 運用・保守 基本設計 受入テスト 総合テスト 結合テスト 製造 詳細設計 単体テスト 企画 製 造 工 程 テ ス ト工 程 対応するテスト 納品/検収/保守契約 ※ただし講師の個人的見解を多分に含みます 58
59. 結合テスト 59 結合試験、IT（Integration Test）とも。
 単体テストが終わった機能同士を結合してテストを行う。
 
 機能間の仕様の噛み合わせ不一致を検知してシステムとしての健全性を確認 するのが目的。
 機能数が多くシステムが複雑になればなるほどテストの工数も増える。

60. 結合試験のポイント 60 • システムの入り口（ログインなど）やコア機能から順に行うとスムーズ。 開発が遅延するなどして工程がオーバーラップした場合も入り口の開 発優先度をあげて枝葉の機能が後回しになるようにした方がよい。
 • データを入力する機能から行い、入力されたデータを参照する機能の 順にテストする。テストデータを手動で入れて検証するのは避ける。
 • 日付や時間の概念が絡むテストは念入りに行う、日付や時間をパラ メータ化して動かせるようにしておくとリアルタイムで実施しなくて済む。
 • なるべく本番に近い環境でテストできるように調整を行う。
 • なるべく本番に近いデータでテストできるようにする。
 • テスト専用環境を作った方がいい。

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

62. 結合・総合・受入試験のフォーマット 62 単体テストと違い結合試験は試験仕様書ともに結果の報告を求められることが多い。
 試験仕様書の顧客レビューも行われるが、結合、総合試験の実施自体はあくまでベンダー で完結するのがほとんど。
 
 逆に受入テストは顧客主導で行われ、テストケースの妥当性をベンダーがチェックすること になる。
 
 フォーマットとしては、機能、画面単位のテストケースを作成し実施するほか、インプットアウ トプットが関連する機能についてはテストケースを関連させて作成するのが一般的。
 シナリオ試験については実際の業務をなぞるような形でテストケースを作成していく。
 
 また、消化したケース数がわかるようなサマリのシートを用意することもある。

63. 試験工程の管理 63 試験はテスト実施者（テスター）をアサインし実施していく。
 
 試験進捗のサマリを作ってケースの消化数、NG数を可視化する。
 別途NG管理表を作り、不具合や仕様上のミスなどを検知し対処を行ってい く。
 NG表に記載するものは再現手順含めて詳細に記載させるようにする。チ ケット管理の仕組みを導入するのも良い。
 
 試験が止まってしまうようなNG（試験ブロック）は試験工程の進捗に大きく 関わってくるため最優先で対処する🔥

64. 試験サマリ 64
65. コラム：複数ベンダー入り混じる試験は大変 65 複数のベンダーとやりとりするシステム間連携のテストは試験NGがどちらの責任 かわからなくなりがちである。
 
 ただでさえベンダー間は意思疎通が取りづらいため、何か連携に不具合があった 時、どこに原因があってどちらの仕組みが悪いかを明確化できるような作りを検討 しておく。
 
 例えばファイルを交換するような連携であれば、向こうから受信したファイルをその まま無加工で一定期間保存したり、こちらから連携する前の情報をログ保存してお いたりと言った設計上の工夫があると原因を追いかけやすい。

66. こんなはずじゃなかった 66 受入試験工程は顧客が初めてシステムに触れることができるフェーズとなる。
 ここで今までドキュメントや想像の中でしかなかったものに触れることになるた め、膨らんだイメージとのギャップが大きいとたとえそれが仕様通りでも拒絶反 応を示されることも少なくない。
 要件から漏れていたがシナリオテストを行ってみたら実はこれが必要だったと いうのも往々にしてあること。
 
 明らかに要望なものは見送ったり既存の機能で代替できないか、あるいはQCD と駆け引きし提案するのが正しいが、それ以前にギャップを引き起こさないよう なPJ進行をし、顧客も作るものの目線が合った状態で進行していくようにしよ う。
 
 例えば開発中盤に動きのイメージを見てもらうなどのデモイベントを行うのも一 つの手。

67. まとめ 67 • 試験工程は今までの設計〜実装工程のある意味答え合わせのフェー ズとなる。これまでの取り組みが間違っていたらここで手痛い代償を払 うことになる。
 • どんなところでバグになりやすいか、テストのことも想定して設計を行っ ていくと予防になる。

68. 第７回 〜お金をもらうって大変〜 68
69. 研修の方針 69 • プロジェクトの各工程におけるPMの心得を実際のプロジェクト成果物や講師の実体験と合わせて学んでいく • 世の中のプロジェクト管理における教科書的な内容だけでなくアイレットでの案件推進に活きる知識を伝える 今日話すこと 要求/要件定義 営業/RFP/見積/提案/受注 上流工程　　　　　　　　　　　　　　　　　　下流工程 運用・保守 基本設計 受入テスト 総合テスト 結合テスト 製造 詳細設計 単体テスト 企画 製 造 工 程 テ ス ト工 程 対応するテスト 納品/検収/保守契約 ※ただし講師の個人的見解を多分に含みます 69
70. 納品 70 受入テストが通りシステムが完成し、それを納めるフェーズ。
 プログラムは形がないものなので、代わりに受領できるものとしてソースコード やドキュメントを納めることが多い。
 
 納品物は基本的に発注時に定められ以下のようなものを納めることが一般的 （請負契約では）。
 • 設計ドキュメント（要件定義書、基本設計書）
 • プログラム（ソースコード、リポジトリ）
 • テスト仕様書、テスト実施結果報告書、マニュアル
 発注時に定義されているとはいえ、納品物のフォーマットやレベル 感は早めに合わせておきましょう。
 顧客によってはMS Word形式で欲しいなど作成コストのかかる方 法を求められることも。
 納め方についても注意が必要。令和にCD ROMに焼いてくれなん てことも…。

71. 検収 71 顧客に納品物をチェックしてもらい「確かに受け取ったよ」と了承してもらうこと。
 
 SIerは一般的に納品基準ではなく検収基準で売上確定とするので検収をもらえ ないと請求ができず、お金がもらえないことに。
 
 プロジェクトが遅延したり、品質が悪かったり、納品物が揃ってない中で検収を もらうのは至難の業。
 気持ちよくお金を払っていただくためにもQCDを守ってプロジェクトを最後まで推 進しよう。

72. 期ズレに注意 72 すべての株式会社は会計期間（事業年度）を定めてその期間内に発生した キャッシュフローと資産をまとめた財務諸表を作成することが法律で決められて いる。
 
 プロジェクトの売り上げもその期のタイミングであらかじめ見込んでいるものな ので、検収が期の変わり目にズレ込むと売り上げの見込みが変わって問題に なるため、検収タイミングをズラさないよう注意が必要。
 
 もちろん顧客にも同じように期があるため、予算取りのなどで意識する必要が ある。
 
 プロジェクトを提案する時に納品タイミングが期ズレを起こしそうであれば分割 検収などができないかあらかじめ打診しておくことも大事。

73. 保守契約 73 システムは完成させて納めたら終わりではなく、運用開始することで価値を創 出し始める。
 
 そして、システムが健全に運用を続けて行くためには、適宜保守や改修を行っ て行く必要がある。
 
 そのための保守フェーズの契約を顧客が望むならここで取り付ける。
 
 どのような契約条件にするか、顧客が求めるサポート体制や
 システムの運用難易度、複雑性を鑑み
 見積もりを検討する。

74. 打ち上げ 74 プロジェクトが完了したら必ず打ち上げを開きましょう🍺
 今までの苦労を労いあい、感謝しあう大切な機会です。
 
 チームが解散してもまた、別のプロジェクトで会った時、以前よりもさらによい関係 性でチームを推進できるはずです。
 
 業界は狭いので出会いを大事にしていきましょう。
 
 納品まで待たずともフェーズの節目節目で打ち上げや決起集会を行うのもチーム ビルディングによいです。

75. まとめ 75 • システムを作っても検収をもらえなければお金はもらえない。
 • 商売・ビジネスの視点を身につける。
 • 気を抜かず、次のフェーズに向けた準備も進めよう。

76. 第８回 〜俺たちの戦いはこれからだ〜 76
77. 研修の方針 77 • プロジェクトの各工程におけるPMの心得を実際のプロジェクト成果物や講師の実体験と合わせて学んでいく • 世の中のプロジェクト管理における教科書的な内容だけでなくアイレットでの案件推進に活きる知識を伝える 今日話すこと 要求/要件定義 営業/RFP/見積/提案/受注 上流工程　　　　　　　　　　　　　　　　　　下流工程 運用・保守 基本設計 受入テスト 総合テスト 結合テスト 製造 詳細設計 単体テスト 企画 製 造 工 程 テ ス ト工 程 対応するテスト 納品/検収/保守契約 ※ただし講師の個人的見解を多分に含みます 77
78. 運用・保守 78 運用とは、システムが日々動くための作業を行うこと
 例えば日常的なオペレーションであるユーザー登録であったり、システム監視 であったりシステム運用のために必要な作業を指す。
 
 保守とは、運用していく中で起きるトラブルを正常化するための作業を行うこと で、問い合わせ対応や不具合修正、各種OS、ミドルウェア、ライブラリのアップ デート、パフォーマンスチューニングなど定常的に行わないがシステム運用の 中で発生するものを指す。
 
 運用はシステムの持ち主である顧客が行う場合が多いが（運用まで任されるこ ともある）、基本的に保守はベンダーが請け負うことがほとんど。
 
 保守運用フェーズに入っても規模によってはPMが必要になる。

79. 安定した運用を続けていくために必要なこと 79 • 十分な各種ログ、メトリクス、監視体制
 • 保守しやすいコード（可読性、変更容易性）
 • デグレを起こさないコード管理
 • リスクの少ないデプロイ
 • パフォーマンスの安定したインフラ
 • 問い合わせが発生しにくい作り（親切なUI、メッセージ、わかりやすい仕様）
 • 整備された仕様書、運用ドキュメント
 • 整備された問い合わせフロー
 • タスク、不具合のチケット管理
 • 属人性のない持続可能な保守体制
 • 必要十分な保守工数

80. 保守の管理 80 保守フェーズにもPMがいる＝管理する必要があるということ
 
 保守契約時に定めた工数や責任範囲を超えてなんでもかんでもやらないよう 顧客と作業者をコントロールしていく。
 保守契約では確保工数を決めてその範囲で対応を行うことが一般的。そのた め稼働工数を管理する。
 
 保守運用フェーズは開発フェーズと異なり、タスクの増加に終わりがないが、作 業マイルストーンを切ったり、チケット管理を適切に行い、作業の証跡や課題を 消し込みしていくことが必要。
 
 保守の負荷が下がるよう、適宜ドキュメントや手順書を整備して提携定型作業 に落としていくことも大事。

81. 瑕疵と保守の切り分け 81 瑕疵担保責任（契約不適合責任）とは引き渡し後に不具合や、欠陥が見つかっ た場合、ベンダーがその修正責任を負うことをいう。
 
 法改正により瑕疵担保責任期間は「瑕疵を知った日から1年」となっている。
 
 このため瑕疵が出たら無償で対応する必要はあるが、それが確かに瑕疵
 なのかを見定められるよう、仕様や議事録などのやりとりはきちんと保存し、確 認できるように。

82. まとめ 82 • システムは運用して初めて価値を生み出す。保守運用こそ顧客に投資を還 元していくフェーズ
 • 属人化しない持続可能で安定した保守体制構築していく

83. 最終回 〜俺たちの戦いはこれからだ〜 83
84. 研修振り返り会 84 実際のプロジェクトでも折に触れてメンバーやクライアント と振り返りをしましょう。
 
 ふりかえりカタログ
 
 今回は上記から「学びと成長」、「ありたい姿」をホワイト ボードツールを使って実施します（50分）。
 

85. 最後に 85 研修お疲れ様でした！
 
 各々がPMとして羽ばたいていけることを願っています。