はてな
プロジェクトチームの体制とは？
メンバーの役割は？
こんな疑問を持つサラリーマンの悩みを解決できる記事です。
私は現在の会社で多くの業務改革を推進したことで、今では「社内の業務を効率化し、毎年多くの人員やコストの削減」を実現してきました。
今回は社内の働き方改革で業務改革を新たに担当することになった方向けに、
プロジェクトチームの体制と役割について解説していきます。
Contents
プロジェクトチームの体制とはなに？
体制はプロジェクトを推進するため、
チームメンバーの指揮命令関係、役割と仕事を決めたものです。
また、メンバーの所属部署や指揮命令など線や図でわかりやすく示したのが体制図です。
体制では以下の点に気をつけましょう。
所属を明確にする
メンバーの所属がわからなければ、そのメンバーの役割もよくわかりません。
所属があるからこそ、そのメンバーのやるべき役割や仕事が出てくるわけです。
部署などの所属を明確にすることで、その部署が業務改革に必要とされる仕事を分別します。
プロジェクトの責任者は1人にする
プロジェクトを決定する責任者が2人以上あると、誰がプロジェクトの方針を決めるか不明であり、なかなか方針が決られず、
プロジェクトの進捗に支障が出る恐れがあります。
責任者は業務を管轄する部署（業務所管部）の管理職（リーダー）をオススメします。
意思決定を明確にする
基本的に体制図では上から下に線が引かれています。
上下の線は指揮命令の関係を示しており、上の意思が下に伝わることで意思決定を実現します。
右左に線を引いて意思決定を不明確することはやめましょう。
業務改革の工程ごとの体制と役割
業務改革の工程ごとに体制を変えていきプロジェクトを推進していきます。
体制を変えるのはそれぞれの工程の作業内容によってに適材適所な役割があるからです。
『【初心者必見】働き方改革で成果を出す、業務改革の進め方』にて説明した通り、(一度そちらを見ていただければ参考になると思います。)
基本的に以下の順の工程で業務改革プロジェクトが進みます。
- 業務改革の準備
- 現状業務の把握
- 業務改革を計画
- システム開発と業務改革後の管理
しかし、上記の記事で紹介した1~3の工程はシステム開発における上流の上流（主に要件定義）でしかありません。
今回は「4.システム開発と業務改革後の管理」の全工程の流れも考慮し、それぞれの作業工程に合致した体制を紹介していきます。
以下が体制ごとに大まかに区分した各工程と体制です。
- 要件定義(事前検討)
- 基本設計
- 詳細設計〜単体試験(DD/CT〜ITa)
- 結合試験〜総合試験(ITb/ST以降)
所属は主に3つを想定しています。
業務所管部・業務改革推進部・システム部
業務所管部：業務改革を行う業務を管轄している部署。ユーザーと最も関わりがあり、当部がユーザーであることもある。
業務改革推進部：業務改革を企画し推進する部署。業務所管部やユーザーを業務改革実現に向けてサポートする。
システム部：システムを設計開発をおこなう部署。業務改革の要件をシステムで実現します。
それでは、各体制について詳しく解説していきます。
1.要件定義(事前検討)
要件定義フェーズではやりたいことや求められる機能や性能などの業務要件をユーザーとビジネスアナリストが中心になり検討していきます。
プロジェクト全体の管理は業務改革推進部プロジェクトマネージャーが担当します。
検討結果はシステムアーキテクト担当者に引き継ぎ、基本設計時の見積もりや経営層への承認タスクなど実施する。
※「1.業務改革の準備」「2.現状業務の把握」「3.業務改革を計画」はここに含みます。
主な業務
プロジェクトマネージャー
- 業務要件定義を除く全体の意思を決定
- 方向性と目的を決定
- スケジュールの整理と管理
- 人員の割り当て
- 課題の整理と管理
業務リーダー/業務有識者
- 業務要件についての意思を決定
- 削減効果を明確化
- 現状業務の調査
- 課題の洗い出し
- 会社内の手続きを再確認
ビジネスアナリストリーダー
- 業務所管部等とのミーティングの進行や調整
- 業務要件のヒアリング(現状業務把握)
- 成果物をレビュー
- 業務改革後のフローの確立
- 業務所管部やユーザーをサポート
ビジネスアナリスト
- 業務要件についての成果物を作成
システムアーキテクトリーダー
- 業務要件を加味したシステム設計を提案
- システム適用後の運用について策定
- 業務改革についてのプロジェクト計画書を作成
- 開発工数の見積を作成
2.基本設計
基本設計フェーズでは開発予定のシステムの目的・機能・効果・運用後の問題有無などを検討していきます。
また、システムにいくらかかるか見積りも算出します。
プロジェクト管理は業務改革推進部からシステム部に代ります。
システムアーキテクト担当者が業務要件をシステム要件に落とし込んでいきます。
ビジネスアナリストは引き続きユーザーの業務観点でのサポートを行う。
システムアーキテクト担当者(リーダー)の下に他のシステムアーキテクト担当者を配置し、システムの詳細についての成果物を作成します。
「4.システム開発と業務改革後の管理」はここに含みます。
主な業務
プロジェクトマネージャー
- 業務要件定義を除く全体の意思を決定
- プロジェクトの方向性と目的を決定
- スケジュールの整理と管理
- 人員の割り当て
- 課題の整理と管理
業務リーダー/業務有識者
- 業務要件についての意思を決定
- システムを適応した時の効果を承認
- システムを適応した後の課題を確認
- 成果物をレビュー
- 投資対効果(ROI)を確認
- システム部による業務改革についてのプロジェクト計画書の作成を支援
システムアーキテクトリーダー
- 業務要件を加味したシステム設計を提案
- 開発工数の見積を作成
システムアーキテクト
- 初期のシステム設計の成果物を作成
ビジネスアナリストリーダー
- 業務所管部等とのミーティングの進行や調整
- 業務要件のヒアリング(現状業務把握)
- 成果物のレビュー
- 業務改革後のフローの確立
3.詳細設計〜単体試験(DD/CT〜ITa)
要件定義の結果を受けてシステムの詳細の仕様を決めていきます。
要件定義の内容を詳細にしていき、設計通りにプログラミングしてシステム開発していくのです。
先ほど同様にプロジェクト管理はシステム部のシステムアーキテクト担当者です。
ビジネスアナリストはプロジェクトを直接関与することなくなり、ユーザーの業務観点でのサポートを行います。
「4.システム開発と業務改革後の管理」はここに含みます。
主な業務
プロジェクトマネージャー
- プロジェクト全体工程のスケジュールを管理
- プロジェクトの方向性と目的を決定
- 課題の整理と管理
業務リーダー/業務有識者
- 各協議や成果物をレビューし要望を整理
- 課題を対応(QA対応)
システムアーキテクトリーダー
- デベロッパーの成果物にレビューを実施
- ユーザー向けにデモを実施
- ITb以降の各フェーズを策定
- システムについての課題を対応(QA対応)
デベロッパー
- 設計、実装、テストを実施
ビジネスアナリストリーダー
- 業務所管部とユーザーをサポート
4.結合試験〜総合試験(ITb/ST以降)
開発したプログラムが確りと仕様通りに動作するか確認します。そして、利用者が開発したシステムを実際に使って検証します。
システムアーキテクト担当者が中心となり、システム部の各システム関係チーム調整しテストと移行を進めます。
ユーザーはいくつかのテスト用の業務を準備してUATを実施します。
先ほど同様にビジネスアナリストはユーザーの業務観点でのサポートを行います。
「4.システム開発と業務改革後の管理」はここに含みます。
主な業務
プロジェクトマネージャー
- プロジェクト全体工程のスケジュールを管理
- プロジェクトの方向性と目的を決定
- 課題の整理と管理
- リリースが可能か判断
業務リーダー/業務有識者
- UAT対応
- 課題を対応(QA対応)
システムアーキテクトリーダー
- システムについての品質評価を実施
- UATをサポートする
- システムの移行を推進
- システムについての課題を対応(QA対応)
デベロッパー
- 課題やトラブルについて対応
- システム移行をサポート
ビジネスアナリストリーダー
- 業務所管部とユーザーをサポート