プロジェクトマネジメントのスキルセット

	A
1	スキルセットの紹介記事
2	一人前のプロマネってどんな人？プロジェクトマネジメントのスキルセットとは-誰も教えてくれないプロマネのコツ https://mmth.pro/ja?p=1882
3
4	スキルセットの考え方と見方
5	・スキルセットを全て使うのは BtoB の新規サービス/システム構築の場合が多い（必ずしも全てのプロジェクトで全ての領域/項目が必要なわけではない）
6	- 自社サービス開発などでは割愛できる部分もあるが、強弱の違いで全く検討が抜けると失敗に繋がりやすい
7	- 例えば、ツールを導入する業務改善プロジェクトではプロジェクト計画+見積り+要件定義の一部+タスクマネジメント+テスト+リリースなど、プロジェクトに合わせて取捨選択を行う
8	・もちろん一人で全てをやる必要はないが、統括的な立場で俯瞰できる人は必要
9	- 得意不得意分野を分担してフォーメーションを組んで実施するのが現実的
10	- 全ての領域を一通りできるようになるには、様々な案件を担当する必要があるので年単位での育成が必要になる
11	- 全てを一人称でキッチリできる人はたぶん1%もいない
12	・統括的な立場で俯瞰できる人がいない場合は、プロジェクトの難易度によっては途中で瓦解する
13	・「プロダクト」マネジメントでも事業観点で見た場合、やるべきことの全体像は変わらない
14	・各領域の難易度は予算3000-5000万円規模を超えると一気に複雑度が増すので、プロマネのアサインはスキル感を注意する必要がある
15	- 放任アサインは鬱/職務放棄/離職リスクが高い
16	・組織として各領域でジュニア/シニアでレベル感を設定し、それを元にアサインを行うことが重要
17	- 基本はジュニア+シニアのタッグ制が育成および稼働分散の観点でオススメ
18
19	・項目の重要度は下記の通り
20	★★★ どんなプロジェクトでもプロマネが責任を持って担当するべき項目
21	★★　デザイナー/エンジニア/ディレクター/SE などの専門家に任せてレビュー的な立場で関わってもよい項目（ただし、プロジェクト全体としてアウトプットがどう関連するかはチェックすること）
22	★　　プロジェクトによっては割愛しても問題ない項目
23
24	スキルセット運用例（評価・教育）シート
25	・スキルセットの運用例として参考につけているシート。PM は育成に時間がかかり組織側も業務の広範さと複雑さを理解していない事が多いため、このリストを使って認識を合わせるとすれ違いが起きづらい。
26	- 実経験上、PMやディレクターの離職理由の大部分が経営層の業務不理解によるものだと思われる
27
28	この資料の利用について（著作権など）
29	・このリストは第三者への販売等の商用以外では自由に使っていただいて構いません。
30	ただ、作者（橋本将功@パラダイスウェア株式会社）にフィードバックをいただけると、アップデートの際に考慮に入れますのでより多くの人が便利になる可能性があります。
31	フィードバック連絡先：
32	paradisemaker@gmail.com
33	https://twitter.com/paradisemaker
34	https://www.facebook.com/masayoshi.hashimoto

	A	B	C	D	E	F
1	領域	重要度	具体的な作業内容	作業の説明	主な関係者	備考
2
3	プロジェクト計画	★★★	座組の整理	関係者の役割分担や意思決定のプロセスを整理する	全体
4	プロジェクト計画		- ステークホルダーのリテラシーチェック	プロジェクト遂行に必要な知識を持ち適切な判断ができるかを確認する
5	プロジェクト計画		- 受発注のマインドチェック	受発注に関して適切なマインドセットを持っているか（パートナーシップがあるか、丸投げしないか/受け身でないか）を確認する
6	プロジェクト計画		- ベンダーの選定調達・調整	関連ベンダーの選定調達と役割分担の調整ができるかを確認する
7	プロジェクト計画		- 意思決定フローの確認	プロジェクトの意思決定は誰が行うか、どのようなプロセスで行われるか
8	プロジェクト計画	★★★	プロジェクトリスクの整理	プロジェクトを実施するにあたって想定されるリスクは何か、関係者で認識を共有できるか	全体
9	プロジェクト計画		- 構築システムのリスク	構築するシステムや導入するツールにリスクはあるか		要件定義の先出し
10	プロジェクト計画	★★★	QCD（Quality/Cost/Delivery）の優先順位確認	品質/予算/スケジュールの優先順位はどうか	全体
11	プロジェクト計画	★★★	アサイン計画の構築	プロジェクトを遂行するために必要な専門知識と技術を持つ担当者やベンダーは揃っているか	全体
12	プロジェクト計画	★★★	適切な開発手法の選定	プロジェクト要件を満たすために適切な開発手法は何か	全体
13	プロジェクト計画		- ウォーターフォール	手法のメリットとデメリットは何か
14	プロジェクト計画		- スクラム	手法のメリットとデメリットは何か
15	プロジェクト計画		- プロトタイピングなど	手法のメリットとデメリットは何か
16	プロジェクト計画	★★★	費用算出	プロジェクトに必要な予算（工数+諸経費）は概算でいくらか	全体	概算見積り
17	プロジェクト計画		- 請負/準委任	ベンダー契約は請負か準委任か
18	プロジェクト計画	★★★	マイルストーンの設定	スケジュールにおいてマイルストーンとなるポイントはいつか、またその条件は何か	全体
19	プロジェクト計画		- 大枠の WBS作成	マイルストーンをクリアする上で必要な体制と実施事項は何か
20	プロジェクト計画	★★★	情報共有の仕組みづくり	プロジェクト遂行時に必要な会議体や情報共有ツールは何か	全体
21	プロジェクト計画		- 会議体	どのような会議体で検討を行うか
22	プロジェクト計画		- ツール	どのようなツールを使うか
23
24	契約	★★★	契約書レビュー	契約は合意内容を反映しているか	法務
25	契約		- 受注形態（請負/準委任）	受注形態は請負か準委任か
26	契約		- 成果物の合意確認	「成果物」は納品要件として設定されているか
27	契約		- 検収の定義確認	プロジェクトの検収は誰がどの形でやるか
28	契約		- 瑕疵対応の内容確認	瑕疵対応の内容はどのようなものか
29	契約		- 損害賠償条項のチェック	損害賠償の上限設定はされているか
30
31	見積り	★★★	工数	誰が何を何時間やるかが見積もれているか、管理工数やテスト工数は入っているか	全体
32	見積り		- 概算	概算見積りでいくらになるか、概算見積りの条件は正確に提示できているか
33	見積り		- 詳細	詳細見積りでいくらになるか、提示タイミングが適切か
34	見積り		- バッファ	工数のバッファは適切に見積もれているか
35	見積り	★★★	実行計画の作成	見積り工数を実行計画に落とせているか	全体
36	見積り		- アサイン計画	担当者のアサインはできているか
37	見積り	★★★	費用	単価等に間違いがないか	全体
38	見積り		- クライアント予算調整	クライアントの予算が合わない場合に調整ができるか
39	見積り	★★★	請求対応	計画や契約、実態に応じた請求ができているか	営業
40
41	交渉	★★★	提案/合意形成	各フェーズで必要な提案を行い、フィードバックを取りまとめて合意形成できるか	全体
42	交渉	★★★	リスク/コスト/スケジュール調整	発生したリスクや対応コストを説明しプロジェクト全体として対応について検討できるか	全体
43	交渉	★★★	ステークホルダーの利害調整	関係者の利害調整ができるか	全体
44	交渉		- クライアント/ベンダー調整	クライアントやベンダーに対して適切な調整ができるか
45
46	要件定義	★★★	ビジネス要件	ビジネス要件を合意できるか	事業担当者
47	要件定義		- 市場調査	ビジネスとして成立する市場があるか		特に新規事業の場合
48	要件定義		- 競合調査	どんな競合が市場に存在するか、どんな特徴を持っているか
49	要件定義		- ビジネスモデル	どんなビジネスモデルを形成するか		特に新規事業の場合、運用時にアップデート
50	要件定義		- KPIツリー	ビジネスとして成立させるためにどんな KPI を設定するか		運用時にアップデート
51	要件定義		- ペルソナ設計	サービスやアプリを利用する人がどんな人なのかを設計する		特に C向け、運用時にアップデート
52	要件定義		- ユーザヒアリング	ペルソナに該当する人物にヒアリングを行う
53	要件定義		- カスタマージャーニーマップ	ペルソナがどんな生活や仕事をする中でサービス/アプリ/システムに関わるか		特に C向け
54	要件定義		- ユーザーストーリーマッピング	ペルソナがサービスの機能をどんな流れで利用するか
55	要件定義		- ユースケース	どんな種類のアクターがいて、どんなことをどのサービス/アプリ/システムでやるのか
56	要件定義		- 業務フロー	どんな種類のアクターがどのシステムでどんな作業を行うのか		特に B向け
57	要件定義		- グロース設計	KPI をどんな施策で伸ばしていくのか		特に C向け、運用時にアップデート
58	要件定義		- UI/UX	サービス/アプリ/システムはどんなデザインや画面遷移、挙動をするのか
59	要件定義	★★★	システム要件	ビジネス要件を合意できるか	エンジニア、情シス
60	要件定義		- システムアーキテクチャ	どんなインフラ構成でサービス/システムが稼働するのか、連携システムはどこにあるのか
61	要件定義		- 機能要件	サービス/アプリ/システムはどんな機能を持っているのか
62	要件定義		- シーケンス図	サービス/アプリ/システムは業務や外部システムとどんな情報処理を行うのか
63	要件定義		- apiリスト	連携する api はどんなものが必要なのか
64	要件定義		- データ移行	移行するデータはどんな形式でどんな処理を行ってどんな形式に変換する必要があるのか
65	要件定義		- 非機能要件	サービス/アプリ/システムはどんな性能や安定性、セキュリティ、コンプライアンスを満たす必要があるのか
66	要件定義		- アクセス/トランザクション設計	サービス/アプリ/システムはどんな形式で外部と連携してどんな性能を担保する必要があるのか
67	要件定義		- SLA	インフラおよびアプリケーション側でどのような安定性を担保する必要があるのか
68	要件定義		- バックアップ	データバックアップをどのように設計するか
69	要件定義		- セキュリティ	サービス/アプリ/システムを実装する上でどのような脆弱性に留意する必要があるか
70	要件定義		- 脆弱性対応	脆弱性を考慮した上でどのような検査や対策を行うか
71	要件定義		- コンプライアンス（情報保護）	サービス/アプリ/システムで扱う情報を提供企業としてどのように扱うか
72	要件定義	★★★	追加要件のハンドリング	当初想定されていなかった追加要件のハンドリングを行う（優先順位、工数、スケジュールなど）	事業担当者、エンジニア	要件定義フェーズ後の整理も含む
73
74	タスクマネジメント	★★★	プロジェクト全体像の共有	メンバーに要件定義で合意したプロジェクトの全体像を伝える	全体	途中参加のメンバーに対するブリーフィング含む
75	タスクマネジメント	★★★	タスクの洗い出し	要件定義で合意した目的を達成するために必要なタスクを洗い出す	タスク担当者
76	タスクマネジメント	★★	調達	タスクを実行する上で必要なメンバーの調達を行う	採用担当者	採用や外部調達が必要な場合
77	タスクマネジメント	★★★	アサイン調整	タスクを実行する上で必要なメンバーのアサインを調整する	タスク担当者
78	タスクマネジメント	★★★	タスクアサイン	メンバーにタスクをアサインする（タスクの目的、完了条件、期限）	タスク担当者
79	タスクマネジメント		- 優先順位の判断	アサインしたタスクの優先順位を判断する	タスク担当者
80	タスクマネジメント	★★★	進捗管理	各メンバーのタスクの進捗状況をリアルタイムで把握する	タスク担当者
81	タスクマネジメント		- 課題の解決	タスクを進める上で障害となる課題をチームとして解決する	タスク担当者、課題関係者
82	タスクマネジメント		- リスクの判断・対応	発生したリスクの判断と対応を行う	タスク担当者、課題関係者
83	タスクマネジメント	★★★	情報共有	プロジェクト関係者に適切なタスク情報や議事録が共有できるようにツール選定を行い、運用ルールを設計運用する	全体
84	タスクマネジメント	★★	振り返りの実施	KPTなど、プロジェクトで都度振り返りを行う	タスク担当者
85	タスクマネジメント	★★★	工数調整	追加工数が発生した場合の調整を行う	全体
86	タスクマネジメント	★★★	予算調整	追加工数が発生した場合の費用調整を行う	全体
87
88	デザイン	★★	Visual Identity	サービス/アプリ/システムのキービジュアルを設計する	ディレクター/デザイナー、意思決定者
89	デザイン		- ロゴ	ロゴを設計する	ディレクター/デザイナー、意思決定者
90	デザイン		-トーン&マナー	サービス/アプリ/システムのトーン&マナーを設計する	ディレクター/デザイナー、意思決定者
91	デザイン	★★	サイトマップ	サイトマップを作成する	ディレクター/デザイナー、意思決定者
92	デザイン	★★	画面デザイン	画面デザインを作成する	ディレクター/デザイナー、意思決定者
93	デザイン	★★	画面コーディング	画面を html/css/js に落とす	エンジニア
94
95	設計	★★	技術スタックの調査選定	実装で使用する技術を選定する	エンジニア
96	設計		- 言語	実装で使用する言語を選定する	エンジニア
97	設計		- フレームワーク	実装で使用するフレームワークを選定する	エンジニア
98	設計		- サーバエンジン	実装で使用するサーバエンジンを選定する	エンジニア
99	設計		- ソースコード管理	ソースコードの管理方法を選定する	エンジニア
100	設計		- コード規約	ソースコードの記述ルールを策定する	エンジニア
101	設計		- 開発環境	開発環境の整備を行う（開発/ステージング/本番環境の切り分け）	エンジニア
102	設計		- デプロイ方法	ソースコードのデプロイ方法を選定する	エンジニア
103	設計		- コンテナ	コンテナの選定と利用方法を決める	エンジニア	使用する場合
104	設計	★★★	プロトタイピングのコンセプトの合意	プロトタイプで検証する内容を合意する	全体	プロトタイピングを実施する場合
105	設計	★★★	画面遷移	画面遷移を設計する	ディレクター/デザイナー/エンジニア
106	設計	★★★	画面仕様	画面仕様を設計する	ディレクター/SE/エンジニア
107	設計	★★★	設計レビュー（実装方針の判断）	各領域の設計が適切に行われているかを確認する	ディレクター/SE/エンジニア
108	設計		- 全般	各領域で全般的にクリアされているか確認する	ディレクター/SE/エンジニア
109	設計		- 機能要件	機能要件が適切にハンドリングされているかを確認する
110	設計		- 正常系/異常系（エラーハンドリング）	正常系/異常系が適切にハンドリングされているかを確認する	ディレクター/SE/エンジニア
111	設計		- 性能要件	設計上性能要件が満たされているかを確認する	ディレクター/SE/エンジニア
112	設計		- セキュリティ	セキュリティに留意した仕様になっているかを確認する（特に会員登録やログイン、会員情報変更や決済など）	ディレクター/SE/エンジニア
113	設計		- 脆弱性チェック	脆弱性に留意した設計になっているかを確認する	ディレクター/SE/エンジニア
114	設計		- インフラ	インフラが適切に設計されているかを確認する	ディレクター/SE/エンジニア
115	設計		- インフラ構成図	テスト/ステージング/本番環境の構成や冗長化やバックアップ構成などを確認する	ディレクター/SE/エンジニア	必要な場合は CDN やメールサーバも合わせて確認する
116	設計		- WAF/IPS/IDS など	セキュリティ要件で必要な場合、WAF/IPS/IDS が適切に導入されるかを確認する	ディレクター/SE/エンジニア
117	設計		- データベース	データベースが適切に設計されているかを確認する	ディレクター/SE/エンジニア
118	設計		- DBスキーマ	DBスキーマが効率的かつ網羅的に設計されているかを確認する	ディレクター/SE/エンジニア
119	設計		- API	API が適切に設計されているかを確認する	ディレクター/SE/エンジニア	API を構築する場合
120	設計		- 認証	認証設計が適切に設計されているかを確認する	ディレクター/SE/エンジニア
121	設計		- セッション管理	セッション管理がセキュアに設計されているかを確認する	ディレクター/SE/エンジニア
122	設計		- 認可	データ取得が適切に設計されているかを確認する	ディレクター/SE/エンジニア
123	設計		- 連携データ設計	画面や業務で必要なデータが適切に分割して設計されているかを確認する	ディレクター/SE/エンジニア
124	設計		- アプリケーション	アプリケーションロジックが適切に設計されているかを確認する	ディレクター/SE/エンジニア
125	設計		- 動作ロジック	動作ロジックが適切に設計されているかを確認する	ディレクター/SE/エンジニア
126	設計		- バリデーション	バリデーションが適切に設計されているかを確認する	ディレクター/SE/エンジニア
127	設計		- セッション管理・排他制御等	セッション管理や排他制御が適切に設計されているかを確認する	ディレクター/SE/エンジニア	必要な場合
128	設計		- フロントエンド	画面系が適切に設計されているかを確認する	ディレクター/SE/エンジニア
129	設計		- 動作ロジック	動作ロジックが適切に設計されているかを確認する	ディレクター/SE/エンジニア
130	設計		- バリデーション	バリデーションが適切に設計されているかを確認する	ディレクター/SE/エンジニア
131
132	テスト	★★★	品質担保の合意形成	限られたリソースで確保すべき品質について関係者と合意を形成する	全体
133	テスト	★★	テスト計画の作成またはレビュー	テストをどのように進めるか、何を重点的に確認するかの計画を作成もしくはレビューを行う	ディレクター/テストマネージャー、テスター
134	テスト		- システム間連携テスト	システム間連携（基幹）がある場合は特に注意して関係ベンダー等と調整を行う	全体
135	テスト		- シナリオテスト	業務フローをベースにユーザシナリオを作成して問題なく機能が使えるかを確認する	ディレクター/テストマネージャー、テスター
136	テスト		- 脆弱性試験	実装上の脆弱性が無いか、ある場合は改修できるかを確認する	ディレクター/テストマネージャー、テスター
137	テスト		- 受入試験	受託案件の場合はクライアントが何をどうやって確認するかの認識をすり合わせる	ディレクター/テストマネージャー、テスター
138	テスト	★★★	テスト体制の構築	テストを実施する体制を構築する	事業担当者、テストマネージャー、テスター
139	テスト		- アサイン	テストやチケットコントロールの担当者をアサインする	ディレクター/テストマネージャー、テスター
140	テスト		- 工数/スケジュール	テスト工数やスケジュールを明確化する	ディレクター/テストマネージャー、テスター
141	テスト		- 費用	テストにかかる費用を算出する	ディレクター/テストマネージャー、テスター	外注する場合
142	テスト	★★	テスター/エンジニアのタスクマネジメント	バグ報告のコントロールや改修対応、関係者への報告を誰がやるかを決める	ディレクター/テストマネージャー、テスター、エンジニア
143	テスト		- チケットコントロール	バグチケットを優先順位を判断しながら担当者にアサインする	ディレクター/テストマネージャー、テスター、エンジニア
144	テスト	★★★	関係者への報告	関係者に対してテスト状況を報告する	全体
145
146	リリース	★★★	リリース計画の作成またはレビュー	リリース手順や全体の役割分担を作成、またはレビューする	全体
147	リリース		- コンティンジェンシープラン（緊急時対応）の作成	リリース後の緊急事態時の判断基準や切り戻し対応を決める	全体
148	リリース	★★★	- リリース体制の構築	リリース時にどのような体制を張っておくかを決める	全体	連携システムがある場合は関連ベンダーの担当者も
149	リリース		- アサイン	誰が何をやるかを明確にしておく	全体
150	リリース		- 情報共有	トラブル連絡やリリース進捗の共有などの方法を決める	全体
151	リリース	★	ストア申請（アプリの場合）	ストアに申請する手順等を確認して実施する	全体
152
153	保守改善	★★★	保守・改善内容の合意形成	サービス/アプリ/システムの保守と改善内容の合意を形成する	全体
154	保守改善	★★	保守改善体制の構築	サービス/アプリ/システムの保守改善体制を構築する	カスタマーサポート/営業、エンジニア
155	保守改善	★★	死活監視体制の構築	サービス/アプリ/システムの死活監視体制を構築する	エンジニア
156	保守改善	★★	データ分析体制の構築	サービス/アプリ/システムの KPI やログ分析の体制を構築する	ディレクター、データアナリスト、エンジニア
157	保守改善	★	グロース体制の構築（必要な場合）	サービス/アプリ/システムのグロース体制を構築する	ディレクター
158	保守改善		- コンテンツ体制の構築（必要な場合）	コンテンツマーケティング体制を構築する	ディレクター、マーケティング担当、編集者、ライター
159	保守改善	★	広告運用体制の構築（必要な場合）	広告運用体制を構築する	ディレクター、広告担当

	A	B	C	D	F
1			Aさん（キャリア3年目・ジュニアPM）
2	領域	具体的な作業内容	実績（メイン/サブ/無）	意欲（強い/弱い）
3
4	プロジェクト計画	座組の整理	サブ	強い	← このような評価軸を元に、プロジェクトマネジメントとして必要なスキルセットを業務としてやったことがあるか、今後の意欲があるかを把握して教育やアサインに活用する。 Aさんの場合はプロジェクト計画やビジネス要件に対する意欲が強く、サブとしての実績も積めているので、そこを伸ばしながらシステム面はテクニカルディレクター/SEと必ず組ませる、など。
5	プロジェクト計画	- ステークホルダーのリテラシーチェック	サブ	強い
6	プロジェクト計画	- 受発注のマインドチェック	サブ	強い
7	プロジェクト計画	- ベンダーの選定調達・調整	サブ	強い
8	プロジェクト計画	- 意思決定フローの確認	無	強い
9	プロジェクト計画	プロジェクトリスクの整理	サブ	強い
10	プロジェクト計画	- 構築システムのリスク	無	強い
11	プロジェクト計画	QCD（Quality/Cost/Delivery）の優先順位確認	サブ	強い
12	プロジェクト計画	アサイン計画の構築	サブ	強い
13	プロジェクト計画	適切な開発手法の選定	サブ	強い
14	プロジェクト計画	- ウォーターフォール	メイン	強い
15	プロジェクト計画	- スクラム	無	強い
16	プロジェクト計画	- プロトタイピングなど	無	強い
17	プロジェクト計画	費用算出	サブ	強い
18	プロジェクト計画	- 請負/準委任	サブ	強い
19	プロジェクト計画	マイルストーンの設定	サブ	強い
20	プロジェクト計画	- 大枠の WBS作成	サブ	強い
21	プロジェクト計画	情報共有の仕組みづくり	メイン	強い
22	プロジェクト計画	- 会議体	サブ	強い
23	プロジェクト計画	- ツール	メイン	強い
24
25	契約	契約書レビュー	無	弱い
26	契約	- 受注形態（請負/準委任）	無	弱い
27	契約	- 成果物の合意確認	無	弱い
28	契約	- 検収の定義確認	無	弱い
29	契約	- 瑕疵対応の内容確認	無	弱い
30	契約	- 損害賠償条項のチェック	無	弱い
31
32	見積り	工数	サブ	強い
33	見積り	- 概算	サブ	強い
34	見積り	- 詳細	サブ	強い
35	見積り	- バッファ	サブ	強い
36	見積り	実行計画の作成	サブ	強い
37	見積り	- アサイン計画	サブ	強い
38	見積り	費用	サブ	強い
39	見積り	- クライアント予算調整	サブ	強い
40	見積り	請求対応	無	弱い
41
42	交渉	提案/合意形成	サブ	強い
43	交渉	リスク/コスト/スケジュール調整	サブ	強い
44	交渉	ステークホルダーの利害調整	サブ	強い
45	交渉	- クライアント/ベンダー調整	サブ	強い
46
47	要件定義	ビジネス要件	サブ	強い
48	要件定義	- 市場調査	無	強い
49	要件定義	- 競合調査	無	強い
50	要件定義	- ビジネスモデル	サブ	強い
51	要件定義	- KPIツリー	無	強い
52	要件定義	- ペルソナ設計	サブ	強い
53	要件定義	- ユーザヒアリング	無	強い
54	要件定義	- カスタマージャーニーマップ	サブ	強い
55	要件定義	- ユーザーストーリーマッピング	無	強い
56	要件定義	- ユースケース	サブ	強い
57	要件定義	- 業務フロー	サブ	強い
58	要件定義	- グロース設計	無	強い
59	要件定義	- UI/UX	サブ	強い
60	要件定義	システム要件	サブ	弱い
61	要件定義	- システムアーキテクチャ	無	弱い
62	要件定義	- 機能要件	サブ	強い
63	要件定義	- シーケンス図	無	弱い
64	要件定義	- apiリスト	無	弱い
65	要件定義	- データ移行	無	弱い
66	要件定義	- 非機能要件	無	弱い
67	要件定義	- アクセス/トランザクション設計	無	弱い
68	要件定義	- SLA	無	弱い
69	要件定義	- バックアップ	無	弱い
70	要件定義	- セキュリティ	無	弱い
71	要件定義	- 脆弱性対応	無	弱い
72	要件定義	- コンプライアンス（情報保護）	無	弱い
73	要件定義	追加要件のハンドリング	サブ	強い
74
75	タスクマネジメント	プロジェクト全体像の共有	サブ	強い
76	タスクマネジメント	タスクの洗い出し	メイン	強い
77	タスクマネジメント	調達	無	強い
78	タスクマネジメント	アサイン調整	無	強い
79	タスクマネジメント	タスクアサイン	メイン	強い
80	タスクマネジメント	- 優先順位の判断	サブ	強い
81	タスクマネジメント	進捗管理	メイン	強い
82	タスクマネジメント	- 課題の解決	サブ	強い
83	タスクマネジメント	- リスクの判断・対応	サブ	強い
84	タスクマネジメント	情報共有	メイン	強い
85	タスクマネジメント	振り返りの実施	サブ	強い
86	タスクマネジメント	工数調整	サブ	強い
87	タスクマネジメント	予算調整	サブ	強い
88
89	デザイン	Visual Identity	サブ	強い
90	デザイン	- ロゴ	サブ	強い
91	デザイン	-トーン&マナー	サブ	強い
92	デザイン	サイトマップ	サブ	強い
93	デザイン	画面デザイン	サブ	強い
94	デザイン	画面コーディング	サブ	強い
95
96	設計	技術スタックの調査選定	無	弱い
97	設計	- 言語	無	弱い
98	設計	- フレームワーク	無	弱い
99	設計	- サーバエンジン	無	弱い
100	設計	- ソースコード管理	無	弱い
101	設計	- コード規約	無	弱い
102	設計	- 開発環境	無	弱い
103	設計	- デプロイ方法	無	弱い
104	設計	- コンテナ	無	弱い
105	設計	プロトタイピングのコンセプトの合意	サブ	強い
106	設計	画面遷移	メイン	強い
107	設計	画面仕様	メイン	強い
108	設計	設計レビュー（実装方針の判断）	サブ	強い
109	設計	- 全般	無	弱い
110	設計	- 正常系/異常系（エラーハンドリング）	無	弱い
111	設計	- 性能要件	無	弱い
112	設計	- セキュリティ	無	弱い
113	設計	- 脆弱性チェック	無	弱い
114	設計	- インフラ	サブ	弱い
115	設計	- インフラ構成図	サブ	弱い
116	設計	- WAF/IPS/IDS など	サブ	弱い
117	設計	- データベース	サブ	弱い
118	設計	- DBスキーマ	サブ	弱い
119	設計	- API	サブ	弱い
120	設計	- 認証	サブ	弱い
121	設計	- セッション管理	サブ	弱い
122	設計	- 認可	サブ	弱い
123	設計	- 連携データ設計	サブ	弱い
124	設計	- アプリケーション	サブ	強い
125	設計	- 動作ロジック	サブ	強い
126	設計	- バリデーション	サブ	強い
127	設計	- セッション管理・排他制御等	サブ	強い
128	設計	- フロントエンド	サブ	強い
129	設計	- 動作ロジック	サブ	強い
130	設計	- バリデーション	サブ	強い
131
132	テスト	品質担保の合意形成	サブ	強い
133	テスト	テスト計画の作成またはレビュー	メイン	強い
134	テスト	- システム間連携テスト	無	強い
135	テスト	- シナリオテスト	無	強い
136	テスト	- 受入試験	無	強い
137	テスト	テスト体制の構築	サブ	強い
138	テスト	- アサイン	無	強い
139	テスト	- 工数/スケジュール	無	強い
140	テスト	- 費用	無	強い
141	テスト	テスター/エンジニアのタスクマネジメント	メイン	強い
142	テスト	- チケットコントロール	無	強い
143	テスト	関係者への報告	メイン	強い
144
145	リリース	リリース計画の作成またはレビュー	サブ	強い
146	リリース	- コンティンジェンシープラン（緊急時対応）の作成	サブ	強い
147	リリース	- リリース体制の構築	サブ	強い
148	リリース	- アサイン	サブ	強い
149	リリース	- 情報共有	サブ	強い
150	リリース	ストア申請（アプリの場合）	無	強い
151
152	保守改善	保守・改善内容の合意形成	サブ	強い
153	保守改善	保守改善体制の構築	無	弱い
154	保守改善	死活監視体制の構築	無	弱い
155	保守改善	データ分析体制の構築	メイン	強い
156	保守改善	グロース体制の構築（必要な場合）	無	強い
157	保守改善	- コンテンツ体制の構築（必要な場合）	無	強い
158	保守改善	広告運用体制の構築（必要な場合）	無	強い