Tweet
Tweet

Slide 1

Slide 1 text

©アイレット株式会社 第四開発事業部 第三開発セクションリーダー 西田 駿史 第４回PM育成プロジェクト資料（公開用抜粋版） 2023/12/11

Slide 2

Slide 2 text

キックオフ 2

Slide 3

Slide 3 text

PM育成プロジェクトの目的　（人事戦略セクションより） 3 
 ◆PM育成研修実施の目的：
 iretのPM人財をPM未経験社員から育成するため。
 
 
 ◆受講者に求めること：
 現役PMの元、実案件ベースのOJTや講習、ロールプレイでの実践的な経験を通し
 iretのPMとしての案件推進のノウハウ獲得を目指す。
 
 
 ◆研修後について
 ・受講者によるアクションプランの作成
 ・研修で学んだことの蓄積・活用についての追跡調査（半年〜1年予定）
 　　・対象：参加者本人 / 上長及びチームメンバー
 　　・内容：アクションプラン及び研修で学んだことの実践状況
 
 


Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

第１回 〜Youは何しにPM研修へ〜 5

Slide 6

Slide 6 text

プロジェクトマネジメントとは 6 プロジェクトマネジメントとは？


Slide 7

Slide 7 text

プロジェクトマネジメントとは 7 「みんなが気持ちよく仕事できるようにすること」 『なれる！SE4 誰でもできる？プロジェクト管理』より
 「みんな」とはプロジェクトのステークホルダー（プロジェクトに関心を 持つ人）つまり発注元顧客、決済者、プロジェクトメンバー、他ベン ダー、エンドユーザー

Slide 8

Slide 8 text

プロジェクトマネジメントとは 8 PMBOKではプロジェクトは「独自性」と「有期性」という言葉を用いて定義され ている。
 プロジェクトに「独自性」があるということは「初めてやる」ものであり、「有期性」が あるということは「明確な始まりと終わり」がある。
 つまりプロジェクトマネジメントというのは、「初めてやる」プロジェクトを「問題なく 期間内」にマネジメントするという究極の難しさを孕む。
 『プロジェクトのトラブル解決大全　小さな問題から大炎上まで 使える「プロの火消し術86」』より文言引用
 PMによってプロジェクトの成否がほぼ決まる。
 責任重大🥶


Slide 9

Slide 9 text

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


Slide 10

Slide 10 text

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


Slide 11

Slide 11 text

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


Slide 12

Slide 12 text

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


Slide 13

Slide 13 text

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


Slide 14

Slide 14 text

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


Slide 15

Slide 15 text

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


Slide 16

Slide 16 text

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


Slide 17

Slide 17 text

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


Slide 18

Slide 18 text

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


Slide 19

Slide 19 text

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


Slide 20

Slide 20 text

第２回 〜案件はどこからくるか〜 20

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

企画 22 クライアントが何か実現したいと思う時企画 が立ち上がる
 それは新しいビジネスだったり、社内の問題点の改善だった り、問題を抱えた既存システムの改善、偉い人の思いつき だったり様々


Slide 23

Slide 23 text

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


Slide 24

Slide 24 text

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


Slide 25

Slide 25 text

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


Slide 26

Slide 26 text

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


Slide 27

Slide 27 text

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


Slide 28

Slide 28 text

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


Slide 29

Slide 29 text

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


Slide 30

Slide 30 text

第３回 〜作るために何を決めるか〜 30

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

要求/要件定義 32 このプロジェクトで実現すべき要件を定義すること。
 RFPを挟まなかった場合など要件以前のレベルが決まっていない 場合さらに前段に要求定義を行うこともある。
 要求定義
 なにをなんのために行いたい か決める
 クライアントの要望・希望・実現 したいことを定義する
 
 要件定義
 要求を実現するために何を行う のか決める
 要求のうち実現するものとその 実現方法を（大まかに）定義する


Slide 33

Slide 33 text

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


Slide 34

Slide 34 text

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


Slide 35

Slide 35 text

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


Slide 36

Slide 36 text

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


Slide 37

Slide 37 text

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


Slide 38

Slide 38 text

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


Slide 39

Slide 39 text

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


Slide 40

Slide 40 text

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


Slide 41

Slide 41 text

第４回 〜どうやって作るのか〜 41

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

基本設計・詳細設計 43 外部設計、内部設計と呼ぶこともある。
 ぶっちゃけ明確に区切りがあるわけではなくプロジェクト、会社によって異なる が、より実装レベルに近いものを詳細設計と呼びがちである。
 
 基本設計まではクライアントにもエンジニアにも伝わる資料であることが重要。 なぜなら多くの場合、基本設計まで顧客レビューが入ることが多く設計書がディ スカッションにも使われるからである。詳細設計はエンジニアがわかれば基本 問題ない。
 
 要件定義で決めたことを具体的にどう実現していくか実装に落とし込むところま で見据えて、設計フェーズでドキュメント化していく。


Slide 44

Slide 44 text

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


Slide 45

Slide 45 text

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


Slide 46

Slide 46 text

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


Slide 47

Slide 47 text

第５回 〜俺たちは何を作っているのか〜 47

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

製造工程 49 開発工程とも
 
 順調に行ってれば本来PMが一番暇になるフェーズ。
 暇にならない場合はこれまでの進行がよくなかったり、役割分担、チームビル ディングが悪いと思った方がよい。
 


Slide 50

Slide 50 text

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


Slide 51

Slide 51 text

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


Slide 52

Slide 52 text

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


Slide 53

Slide 53 text

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


Slide 54

Slide 54 text

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


Slide 55

Slide 55 text

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


Slide 56

Slide 56 text

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


Slide 57

Slide 57 text

第６回 〜これちゃんと作れたのか〜 57

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

結合テスト 59 結合試験、IT（Integration Test）とも。
 単体テストが終わった機能同士を結合してテストを行う。
 
 機能間の仕様の噛み合わせ不一致を検知してシステムとしての健全性を確認 するのが目的。
 機能数が多くシステムが複雑になればなるほどテストの工数も増える。


Slide 60

Slide 60 text

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


Slide 61

Slide 61 text

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


Slide 62

Slide 62 text

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


Slide 63

Slide 63 text

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


Slide 64

Slide 64 text

試験サマリ 64

Slide 65

Slide 65 text

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


Slide 66

Slide 66 text

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


Slide 67

Slide 67 text

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


Slide 68

Slide 68 text

第７回 〜お金をもらうって大変〜 68

Slide 69

Slide 69 text

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

Slide 70

Slide 70 text

納品 70 受入テストが通りシステムが完成し、それを納めるフェーズ。
 プログラムは形がないものなので、代わりに受領できるものとしてソースコード やドキュメントを納めることが多い。
 
 納品物は基本的に発注時に定められ以下のようなものを納めることが一般的 （請負契約では）。
 ● 設計ドキュメント（要件定義書、基本設計書）
 ● プログラム（ソースコード、リポジトリ）
 ● テスト仕様書、テスト実施結果報告書、マニュアル
 発注時に定義されているとはいえ、納品物のフォーマットやレベル 感は早めに合わせておきましょう。
 顧客によってはMS Word形式で欲しいなど作成コストのかかる方 法を求められることも。
 納め方についても注意が必要。令和にCD ROMに焼いてくれなん てことも…。


Slide 71

Slide 71 text

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


Slide 72

Slide 72 text

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


Slide 73

Slide 73 text

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


Slide 74

Slide 74 text

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


Slide 75

Slide 75 text

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


Slide 76

Slide 76 text

第８回 〜俺たちの戦いはこれからだ〜 76

Slide 77

Slide 77 text

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

Slide 78

Slide 78 text

運用・保守 78 運用とは、システムが日々動くための作業を行うこと
 例えば日常的なオペレーションであるユーザー登録であったり、システム監視 であったりシステム運用のために必要な作業を指す。
 
 保守とは、運用していく中で起きるトラブルを正常化するための作業を行うこと で、問い合わせ対応や不具合修正、各種OS、ミドルウェア、ライブラリのアップ デート、パフォーマンスチューニングなど定常的に行わないがシステム運用の 中で発生するものを指す。
 
 運用はシステムの持ち主である顧客が行う場合が多いが（運用まで任されるこ ともある）、基本的に保守はベンダーが請け負うことがほとんど。
 
 保守運用フェーズに入っても規模によってはPMが必要になる。


Slide 79

Slide 79 text

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


Slide 80

Slide 80 text

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


Slide 81

Slide 81 text

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


Slide 82

Slide 82 text

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


Slide 83

Slide 83 text

最終回 〜俺たちの戦いはこれからだ〜 83

Slide 84

Slide 84 text

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


Slide 85

Slide 85 text

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