プログラム管理を成功させる為に必要な3つのこと ·...
TRANSCRIPT
プログラム管理を成功させる為に必要な３つのこと
2014年12月19日
グラビス・アーキテクツ株式会社
1
Agenda
1.GLAVIS Architects のご紹介 1.会社概要 2.弊社実績（抜粋）
2.プログラム管理を成功させる為に必要な３つのこと
1.プログラム管理とは？ 2.プログラム管理はなぜ難易度が高いのか？ 3.プログラム管理を成功させるために必要な３つのこと
3.プロジェクトマネジメント事例
1.プロジェクトの成果 2.プロジェクト概要 3.プロジェクトの特徴と成功要因 4.管理フレームワーク
4.PMツールの紹介
1.プログラム管理の重要性 2.プロジェクト管理ツール「Compass」 3.プロジェクトコラボレーションツール「Glavisサイト」
GLAVIS Architectsのご紹介
© 2014 GLAVIS Architects Inc.
3
経歴 2001年アンダーセン（朝日アーサーアンダーセン株式会社）に入社し、大規模システム導入に掛る業務設計、システム設計に従事。 ベリングポイント株式会社（現プライスウォーターハウスクーパース株式会社）へ社名変更後、パブリックセクター戦略チームにて、中央省庁の調達支援、ITコスト削減、システム導入PMO、IT関連政策立案支援、新技術実証実験、海外IT調達の調査研究事業、また大手通信キャリアのマネジメント体制構築等のプロジェクトなど、公共機関向けのコンサルティング経験およびプロジェクトマネジメント実績多数。当時最年少でマネージャに昇格。 2006年よりパブリックセクター戦略チームの自治体サービスの立ち上げとサービス統括を担う。自治体や医療機関の総合計画・情報計画策定、公会計導入、CIO補佐官、ITマネジメントなど数多くのプロジェクトを提案、受注、推進する。 2008年より、北海道事務所の立ち上げと事務所の管理責任者を担当するための北海道へ移住。地元技術者集団と東京の大規模クライアントとのビジネスマッチングを多数実現。 2010年、グラビスアーキテクツ株式会社設立。 2012年、情報処理推進機構のクラウド基盤構築プロジェクトにおいてプライムコントラクターとして統合プロジェクト管理業務を受注。7プロジェクト5事業者総勢約120名のプログラム管理の総括責任者として、EVMを用いた厳密なプロジェクト管理により全プロジェクトを遅延なく稼働させることに成功。その成功した手法を元にプロジェクト管理ツールを自社開発。 2014年、ePublic Intelligence GLAVISをオープンし、経営とテクノロジーに特化したレポート公開、また公共並びに上流工程への参入支援サービスとして、提案書等資料作成や政策、プロジェクト管理等の提供やリサーチ、資料作成支援等のインテリジェンスサービスをスタート。
主な資格
PMP（Project Management Professional）
主な社外活動 鳴門市CIO補佐: 2006/4～2009/3 北海道大学経済学研究科講師: 2008/4～現在 株式会社クニエ顧問（アソシエートパートナー） 2014/10～現在
関連執筆活動 地方財務 2007/01: 「失敗しない電子自治体の進めかた」
代表経歴 古見彰里
4
業務実績（抜粋）
特定公害に関する認定申請、給付業務に掛るシステム刷新プロジェクトにプロジェクト責任者として参画。提案作成、受注から、プロジェクト管理、リリースまで全ての工程に対してマネジメント。
Case
A
某独立行政法人 システム開発、導入、運用保守 行政・独法制度 プロジェクト管理
スクラッチシステム開発管理
Iハイブリットクラウド基盤の構築において、7プロジェクト5事業者（最大時120名）のプログラム管理を担当。最新のクラウド技術を用いた基盤構築において、EVMを用いた厳密なプロジェクト管理を遅延なく稼働に導く。
Ca
se
C
某独立行政法人 プロジェクト管理支援業務 マルチベンダーコントロール プログラム・プロジェクト管理
クラウド技術を用いた基盤構築管理
Case
B
某製造業 プロジェクト管理支援
業務改善（BPR） プロジェクト管理
パッケージ（ERP）導入 自動車部品の調達に掛かる業務改善及びマスターデータ管理の効率化を実現。またその後のシステム導入（SAP）に掛かるプロジェクト管理を実施。自社内外プロジェクトの統合管理を担当し、プロジェクトを成功に導く。
市役所における業務システムの刷新に向けた方針策定を担当。市の情報化推進プランおよびITガバナンスにおける課題整理とシステム刷新のロードマップ、事業プランの策定、クラウド技術の活用検討。
Case
E
某政令指定市 業務システム刷新可能性調査 IT戦略
業務システム最適化 クラウド技術を用いた基盤構築管理
Case
D
某中央省庁 プロジェクト管理支援
マルチベンダーコントロール クライアント課題管理
プロジェクト管理 某省の人事給与システムの導入に伴うPMO業務を実施。公共機関における人事給与システム導入実績を持ち、PMO実績の豊富な弊社要員を2名配置。
中央省庁、独立行政法人、地方自治体に対するコンサルティングサービスの立ち上げ、プロジェクト管理人材の育成と営業展開に対するコンサルティングを実施。
Case
G
某公共系SIer 業務システム刷新可能性調査 営業戦略 人材育成
新事業の立ち上げ
Case
F
某ITメーカー プロジェクト管理支援
海外動向リサーチ 政策動向リサーチ
事業戦略 2020年の東京オリンピックに向けて、海外からの入国者の激増を見据え、政府機関に対する新たなソリューションの開発と営業展開に向けた事業戦略立案を支援。
某省ウエブシステムの政府共通プラットフォームへの移行並びに予算策定支援、調達支援を実施。
Case
I
某中央省庁 業務システム刷新可能性調査 調達支援
政府共通プラットフォーム移行 最新クラウド技術（仮想化による集約と冗長化）
Case
H
某中央省庁 プロジェクト管理支援
政府共通プラットフォーム移行 最新クラウド技術（仮想化による集約と冗長化）
業務システム最適化計画 某省外局の基幹系システムのサーバー集約および冗長化の検討並びに政府共通プラットフォームへの移行にかかる計画を策定。
プログラム管理を成功させる為に必要な３つのこと
© 2014 GLAVIS Architects Inc.
6
プログラム管理とは？
プロジェクトマネジメント
特命使命による価値事業
個別性、有期性、不確実性
プログラムマネジメント
全体使命による価値事業
多義性、拡張性、複雑性、不確実性
多義性
拡張性
複雑性
不確実性
※PHP研究所発行「P2Mプロジェクト＆プログラムマネジメント 標準ガイドブックより
7
プログラム管理はなぜ難易度が高いのか？
発注者
受注者
管理者
プロジェクト プロジェクト プロジェクト プロジェクト
プロジェクト プロジェクト プロジェクト プロジェクト
管理者
発注者、受注者が同じ認識に立つ
プログラム管理
プログラム管理
GA
P
GA
P
GA
P
この管理上のG
AP
を埋める必要がある
管理に関する共通言語が存在しない
各PJの状況を横断的且つ定量的に把握できない
各PJの状況を横断的且つ定量的に把握できない
社内標準としてプロジェクト管理手法が確立していない
プロジェクトの評価を行う専門性を持ち合わせていない
8
プログラム管理を成功させるために必要な３つのこと
主体性と予防視点
プログラム マネジメント
管理ルールの統一・ モデル化
• 他人事ではないか？ • 基本的な姿勢を共有しているか？ • 逆算志向で整理しているか？ • 経験を活かしているか？
• 複合的な課題に関係者全体で役割を割り当てているか？
• スケジュールの依存関係は整理されているか？
• 相手の視点にたっているか？
• 管理のルールはあるか？また関係者で正しく共有認識を形成しているか？
• 可能な限り定量的な管理を用いているか？
• ツール化し、人に依存させていないか？
プログラムマネジメント事例
© 2014 GLAVIS Architects Inc.
10
プロジェクトの成果
大規模かつ マルチベンダー
■6プロジェクト4事業者、最大時約120名の大規模プロジェクト
本プロジェクトは6プロジェクト4事業者で実施し、最大時120名の大規模プロジェクトであった。そのため、管理文化の異なる事業者と技術者が存在し、正しい現状把握すら困難な状況であった。これに対し、プロジェクトの管理ルールを統一し、PMO※1が一括して報告を取りまとめるなど、プロジェクトガバナンスの強化を図りコミュニケーションロスを排除した。
短期間
■ 一般では実現困難な大規模プロジェクトを1年半で完遂
2013年3月末に稼働させなければならない短期間の制約条件があった。顧客が抱えているｲﾝﾌﾗに係る課題を解決するために必要な対策を打ち出し、CIO補佐官によるCOCOMOⅡを用いた各プロジェクトの合理的な規模の算出とともに、関係者の協議による実現内容の優先順位を踏まえ、EVM※2を用いた工数実績の把握と調整を行うことで、現実的なプロジェクトの遂行とQCD※3を確保した。
資産化
■現実的なプロジェクト管理方法論の資産化
机上の方法論ではなく、マルチベンダー、大規模プロジェクトにおいてQCDを確保する現実的なプロジェクト管理の方法論を確立した。また、この方法論を文書化（明文化）し、ツール化することで、資産形成を行い、今後の様々なプロジェクトでの活用を可能とした。
※1:Project(Program) Management Office ※2:Eraned Value Management ※3:Quality Cost Delivery
11
プロジェクトの課題・背景
最適化されたサービスレベルや可用性、新旧技術の互換性やコスト高構造などの課題を踏まえ、大きく4つのプロジェクトを実行することにより、高可用性の実現とシステム資源の有効活用を目標として本事業を実施した。
個々のサービスレベル及び個別部分の最適化目標により稼働している。
システム障害時の可用性が一元的に安定していない
現行の基幹システムは数世代前のシステムであるため、アプリ、H/Wの新しい技術との互換性において不安定な稼働となっている。
コスト高になる恐れがある上に、可用性の低下が重要な課題となっている。
本調達の背景にある課題 目標
高可用性の実現とシステム資源の有効活用 （１）クラウドコンピューティング構成技
術を活用した共通基盤システムの導入
（２）グリッドプラットフォーム（グリッドコンピューティング基盤）構築に向けた実証実験
（３）グリッドプラットフォームの構築及び機構内システムへの導入
（４）共通基盤システム及び機構内システムにおける運用・監視の統合
手段
クラウドコンピューティングの構成術を活用し、機構内システムの最適化と統制及び統合の実現を目指す。
リスク把握や業務継続への対策等の統制面での課題を克服しながら、コスト削減を実現する保守・運用の体制構築を目指す。
各センターでの情報共有やPJサイト、開発環境の構築を可能とするプラットフォームの構築、システム開発負荷の軽減を目指す。
12
特徴 目的を共有する複数プロジェクトの管理とプログラム管理 （6プロジェクト4事業者、全て予定通りに完了）
統合管理PMO（弊社）
外部データセンター
庁内
庁内サーバールーム
リソースプーリング（日本電気）
Ⅰ
基幹 (日立製作所）
Ⅱ Ⅲ
UI・認証 UI・認証 UI・認証 UI・認証
拠点間分散処理（ネットワンシステムズ）
Ⅴ Ⅵ Ⅶ
UI・認証
Ⅳ
その他 クラウド サービス
外部
分散処理 開発基盤
仮想化環境（日立製作所）
SaaS
PaaS
IaaS
Private Public
運用保守（日立製作所）
ネットワーク
サーバー
ネットワーク
サーバー
仮想化環境
運用保守
連携
第三者監視 サービス
（伊藤忠テクノソリューション
ズ）
監視
顧客側 情報管理部門 標準管理要領
標準管理要領
ツール
調整力
プログラム管理
報告
プロジェクト概要
13
プロジェクトの特徴と成功要因
プロジェクトの特徴 プロジェクトの成功要因
大規模かつマルチベンダー （6プロジェクト5事業者、最
大時120名）
新技術 （分散基盤、監視SaaS、マルチハイパーバイザー仮想化等）
短期間での遂行 （約1年～1年半の期間で3年
から4年分のプロジェクトを遂行）
システム管理グループの体制
考慮のポイント
生い立ち、文化の違いを踏まえたコミュニケーション
ロスの排除
システム管理グループに負担の少ない遂行
スコープ、優先順位、実現範囲の合理性
プロジェクト間の依存関係の把握
主体性と予防視点
プログラム マネジメント
管理ルールの統一・ モデル化
• 報告体系 • 是正より予防 • PJ憲章（心得） • コミュニケー
ション • 逆算カレンダー
• 統合WBS※1 • マルチ課題管理 • 資産再利用
• 標準管理要領 • EVM • TRM※2 • COCOMOⅡ • ITダッシュボー
ドの活用 • ツールの活用
※1:Work Breakdown Structure ※2:Technical Reference Model
14
管理フレームワーク
プロジェクト成果物
納品
定期報告資料
立上げ 計画 実行 監視
コントロール 終結
プロジェクト憲章
プロジェクト実施計画
スコープ管理計画
進捗管理 計画
コスト管理 計画
コミュニケーション
管理計画
プロジェクト成果物
議事録
報告資料 EVM 完了報告
残課題
WBS
スケジュール
リスク課題 管理表
リスク管理計画
品質管理 計画
納品物
品質報告
是正要求
WBSディクショナリ
15
具体的なドキュメント類 事業推進に係る基本方針
取組 姿勢
ＩＰＡの掲げる事業全体の目的・目標を理解し、自社の作業の範囲のみならず、事業全体として必要と考える提言について積極的に行うこと
個別プロジェクト間での積極的な協力関係を築き、事業全体としての課題の解決に努めること 「できない」はなく、「できる」為に必要な前提などを建設的に提言すること 受動的にならず、事業全体において必要な事項について能動的に行動すること 本件の遂行に当たっては、問題点や課題の指摘にとどまらず、その有効な解決策の提示とそれに係る必要な調査も行うこと 本件の円滑な遂行を実現するため、必要な時に積極的に調整等を行うこと。また、問題や課題の早期発見に努め、主体的かつ迅
速に、その解決に取り組むこと 仕様書に定めた作業は、現時点で想定される範囲で記述したものである。今後、各作業等に変更が生じた場合は当機構と協議の
上、柔軟に対応すること
役割
プロジェクト間の責任範囲はＩＰＡが責任もって提示し、個別プロジェクトにおけるベンダー管理、打ち合わせ調整等はＰＭＯが責任を持って実施すること
仕様書に基づき、定義された作業を遂行するものの、事業全体の視点から更に必要な作業を発見した場合には、ＰＭＯに課題提起すること
その上で、ＰＭＯと協力の上、必要な作業を行うべく、積極的な調整を行うこと（変更管理、ＭＲの活用、優先度の低い作業とのトレードオフなど）
別途定める、ＩＰＡ、ＰＭＯ、個別プロジェクトのＲＡＭに記載のある担当が、それぞれの領域において責任をもって要件を協議し、意思決定を行うこと
ルール 原則ＩＰＡ及びＰＭＯがリリースする標準管理要領を遵守すること 個別プロジェクト間のコミュニケーション等において、標準管理要領に記載のないルールの必要性を認識した場合には、ＰＭＯ
に課題提起をするとともに、対応案を提示すること
品質
仕様書、要件定義において定められた事項を正しく履行すること 個別プロジェクトは、要件定義、基本設計においてＩＰＡの承認を得ることと、その承認された要件定義、基本設計が正しくテ
ストされていることを証明するためのトレーサビリティを確保すること 日本語、体裁、用語の統一化を徹底し、コミュニケーションミスを予防すること 個別プロジェクトは、要件の把握において、その道のプロフェッショナルとしてＩＰＡに背景、技術の特性などを説明しＩＰＡ
における要件の導出を支援すること 成果物はタスクの開始時期に作成方針を必ずＩＰＡ、ＰＭＯと合意すること。レビューの手順やプロセスはＰＭＯの指示に従い
実施すること
16
具体的なドキュメント例 ドキュメント作成の留意点-プロジェクト計画書作成の留意点
•課題の分類方法や進捗の報告ルール等が独自の様式、方法に則ってしまっている。
記述方法の確認
誤字脱字の確認 ・文書上に誤字脱字はないか。 ・日本語表現は適切か。
用語の統一 ・同義にも関わらず異なる表現がないか。 ・同じ単語にも関わらず異なる表現がないか。
記述項目の過不足確認 ・記述項目に抜け漏れはないか。 ・各項目に記載された内容は適切か。 ・曖昧な記載内容はないか。
- •プロジェクトマネジャーとプロジェクト責任者 •プロジェクトマネジャーとプロジェクトマネージャー •進捗報告書と進捗状況報告書
•制約条件に前提条件が記載されている •スケジュールにマイルストーンが明示されていない •体制図に役割が記載されていない、明示されていない
記述内容の確認
作業範囲、実施内容について ・調達仕様書と整合しているか。また、WBS、WBSディクショナリに正しく展開されているか。
スケジュール、マイルストーン ・スケジュールやマイルストーンは他のプロジェクトのスケジュールも踏まえた適切なマイルストーンが配置されているか。
マネジメントプロセス •品質管理、進捗管理、課題管理等、標準管理要領に即した記載となっているか。
•仕様書に記載されている成果物がプロジェクト計画書に記載されていない。 •スコープの記述では「要件定義」がスコープに含まれているのに、工程の記述やWBSでは要件定義が含まれていない。
-
参考例 レビューポイント
17
具体的なドキュメント例 逆算スケジュール –カレンダーの活用-
MON TUE WED THE FRI SAT/ SUN
8/6 7 8 9 10 11
12
13 14 15 16 17 18
19
20 21 22 23 24 25
26
27 28 29 30 31 9/1
2
3 4 5 6 7 8
9
10 11 12 13 14 15
16
17 18 19 20 21 22
23
IBR向け資料作成
PMOプレIBR
IPA/PMOレビュー
貴社準備作業 IPA/PMO作業 凡例：
PMOレビュー
IBR向け資料修正
キックオフ会議
IBR※1準備説明
フィードバック
提出
提出
IBR向け資料修正 提出
IBR向け資料作成
IPA/PMOレビュー IBR
進捗報告資料作成 提出 事業進捗報告会議
事前参加 フィードバック
事業進捗報告会議
参加 提出 進捗報告資料修正
仕様書に基づいた要件の
具体的な実現イメージの事前打合せ
仕様書に基づいた要件の
具体的な実現イメージの事前打合せ
※1:Integreted Baseline Review
18
具体的なドキュメント例 ポータルの活用
19
具体的なドキュメント例 EVMの活用
9/5 9/12
9/19,11/9
,11/23～11/30
9/26～10/19
10/26～11/2
11/16
0.6
0.8
1.0
1.2
1.4
0.6 0.8 1.0 1.2 1.4
CPI
SPI
Aシステム 【管理責任者：XXXX㈱／YYY】
ブルズアイチャートのSPI < 1.0、及び、SPI < 1.0（左下の象限）の場合はプロジェクトの進捗遅れ、コスト超過を意味する。 本プロジェクトでは、0.9を2回以上連続して記録した場合、是正処置案の提出を求める。
SPI : スケジュール効率化指数 CPI：コスト効率化指数
進捗遅れ、コスト超過の状態
進捗は遅れているものの、コスト超過は発生していない状態
進捗は計画通りだが、コスト超過は発
生している状態
進捗、コストともに計画通りに進んでい
る状態
20
具体的なドキュメント例 標準管理要領
21
2 月27 28 29 30 31 1 2 3 4 5 6 7 8 9 10 11 12月 火 水 木 金 土 日 月 火 水 木 金 土 日 月 火 水
Lv1 Lv2
1 1.1 現状のネットワーク環境のリスクと課題分析 予定 12/2 12/201 1.1 現状のネットワーク環境のリスクと課題分析 実績 12/2 12/201 1.2 リスク回避策と課題解決策の検討、施策案の作成 予定 12/16 12/271 1.2 リスク回避策と課題解決策の検討、施策案の作成 実績 12/16 12/272 2.1 ネットワークの TOBE 像の作成 予定 12/23 1/172 2.1 ネットワークの TOBE 像の作成 実績 12/232 2.2 ネットワーク概要方式書の作成 予定 1/6 1/312 2.2 ネットワーク概要方式書の作成 実績 1/62 2.3 セキュリティ対策素案の作成 予定 12/9 1/172 2.3 セキュリティ対策素案の作成 実績 12/93 3.1 仮想化基盤① 予定 12/9 1/173 3.1 仮想化基盤① 実績 12/9 1/293 3.2 仮想化基盤② 予定 1/20 3/143 3.2 仮想化基盤② 実績 1/203 3.3 リソースプーリング管理システム① 予定 12/9 1/173 3.3 リソースプーリング管理システム① 実績 12/9 1/293 3.4 リソースプーリング管理システム② 予定 1/20 3/143 3.4 リソースプーリング管理システム② 実績 1/203 3.5 拠点間分散処理基盤① 予定 12/9 1/173 3.5 拠点間分散処理基盤① 実績 12/9 1/293 3.6 拠点間分散処理基盤② 予定 1/20 3/143 3.6 拠点間分散処理基盤② 実績 1/203 3.7 新技術の活用検討 予定 12/23 3/83 3.7 新技術の活用検討 実績 12/234 4.1 既存個別システム 予定 12/2 2/284 ※他タスクとの重複範囲が広いため工数をMPに振替 実績 12/24 4.2 中期計画に基づいた新規構築予定の個別システム 予定 12/2 2/284 4.2 中期計画に基づいた新規構築予定の個別システム 実績 12/25 5 共通基盤システム拡張に向けた方式リスクの抽出と対策案作成予定 2/24 3/215 5 共通基盤システム拡張に向けた方式リスクの抽出と対策案作成実績
ネットワーク分析・整理
共通基盤システム拡張に向けた方式リスクの抽出と対策案作成
中期計画に基づいた新規構築システム及び既存システムの共通基盤移行・再構築計画の策定支援
拡張機能やシステム資源の整理・配置、追加機能分析
ネットワーク方式素案作成
岡崎 100%
岡崎 100%
岡崎 30%
伊藤 80%
伊藤 80%
古見
岡崎 30%
古見 30%
岡崎 100%
松島 80%
松島 80%
岡崎 30%
松島 100%
松島 100%
松島 80%
終了
共通基盤システム拡張計画策定PJプロジェクト開始日： 2013/11/15
進捗報告基準日 2014/2/5※ctrl+shift+m でイナズマ線を引き直します。
作業責任者 進捗率 開始
具体的なドキュメント例 WBSガントチャート
各プロジェクトの作業進捗状況をイナズマ線で表現することで、注力して確認すべきタスクを明確にする。
末端のタスク単位でWBSディクショナリを作成する。
22
区分 プロジェクトキックオフ準備
責任者 担当者A 担当者名 担当者A、担当者B、担当者C、 担当者E、担当者G
開始日（計画） 2012/4/2 終了日（計画） 2012/4/13
期間（日） 10 出来高計画値（人日） 8
クリティカルパス No コスト 56,000
目的・プロジェクトのスタートに必要な前提資料の確認及び最新の調達状況を把握すること
アプローチ・過去の検討資料を入手する
・対象システムの調達準備状況、調達状況を把握する・ステークホルダーを確認する・既存個別プロジェクト受託業者の設計書類を確認する・各個別プロジェクトの制約条件を再確認する（調達、構築期間、予算等）
成果物または中間成果物中間成果物 ・なし
成果物 ・キックオフ資料
完了基準・キックオフ会議の開催及びキックオフの内容についてステークホルダーの合意を得ること
具体的なドキュメント例 WBSディクショナリ
予めタスクごとのコストを算出し、事前に合意形成を図ることでコスト超過を予防する。
作業ステップを詳細に洗い出し、発注側、受注側双方で合意することで作業の手戻りを予防する。
タスクの完了状態を双方で合意することでタスク完了の認識違いを予防する。
プロジェクト管理ツールのご紹介
© 2014 GLAVIS Architects Inc.
24
発注者
受注者
管理者
プロジェクト プロジェクト プロジェクト プロジェクト
プロジェクト プロジェクト プロジェクト プロジェクト
管理者
EVMにより定量的なプロジェクト管理
プログラム管理
プログラム管理
GA
P
GA
P
GA
P
※EVMによる進捗管理手法を義務づけ
この管理上のG
AP
を埋める必要がある
業務・システム 最適化ガイドライン
情報システムに係る 政府調達の基本指針
EVMによる管理を実現できるツールが国内に存在しない
各PJの状況を横断的且つ定量的に把握できない
各PJの状況を横断的且つ定量的に把握できない
社内標準としてプロジェクト管理手法が確立していない
プロジェクトの評価を行う専門性を持ち合わせていない
プログラム管理の重要性
25
プロジェクト管理ツール 「Compass」
ポータル／ガジェット
課題・リスク・TODO管理
WBSガントチャート
情報カレンダー
期限や期日 の表示
状況 集計 WBSの進捗や課題等情報サマリを表示 WBSの管理及びWBSDを管理
課題やリスク、TODOを管理 プログラム／プロジェクトのイベントを表示
プロジェクト管理ツールの機能概要を以下に示します。
状況 集計
ﾏｲﾙｽﾄｰﾝ 表示 統合管理
組織管理者,PMO etc.
各プロジェクト /プログラム
グラフ等の活用により、状況や状態が視覚で理解しやすい画面レイアウトで構成されています。加えて、
ポータルサイト管理機能により個人ごとに利用頻度が高い情報を自由に配置できます。
左記以外
文書管理
リソース管理
その他、MSProject、Redmineとの連携機能追加を予定
26
プロジェクトコラボレーションツール 「ePublic Platform GLAVISサイト」
テクノロジー等の特定分野に特化したレポートやノウハウ集の閲覧
レポートや記事、ファイル検索
メッセージによる双方向コミュニケーション
協業企業との資料テンプレートや提案書、報告書ひな形、ナレッジ
資料の共有
個別のノウハウやレポートを参照
27
Author
古見 彰里 Akinori Komi グラビス・アーキテクツ株式会社 代表取締役 北海道大学経済学研究科 講師 株式会社クニエ アソシエイトパートナー [email protected] 東京事務所： 東京都港区赤坂二丁目20番5号 03-6441-3931 080-4166-7666 札幌事務所： 北海道札幌市白石区本郷通13丁目南5番9号 011-866-1288
28
６