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

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

キックオフ 2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

研修の方針 21 • プロジェクトの各工程におけるPMの心得を実際のプロジェクト成果物や講師の実体験と合わせて学んでいく • 世の中のプロジェクト管理における教科書的な内容だけでなくアイレットでの案件推進に活きる知識を伝える今日話すこと要求/要件定義営業/RFP/見積/提案/受注上流工程　　　　　　　　　　　　　　　　　　下流工程

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

試験サマリ 64

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

danishi

More Decks by danishi

Other Decks in Education

Featured

Transcript

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

キックオフ 2

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

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

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

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

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

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

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

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

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

まとめ 28 • プロジェクトが始まる前にもこれだけ工程があっていろんな努力がある  • クライアントは要件定義に入る前にすでにイメージ（期待、妄想）が膨らんでいる  • 請負と準委任の契約形態の違いを意識する

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

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

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

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

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

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

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

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

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

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

試験サマリ 64

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

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

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

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

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

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

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