PROMCODE
次世代プロジェクト管理データ交換アーキテクチャ協議会
日立製作所における実証実験報告書

第1版

2013 年 10 月 22 日

株式会社日立製作所

1Copyright ©

Hitachi, Ltd. 2013 All rights reserved.

本書は，本書に記載した要件・技術・方式に関する内容が変更されないこと，および出典を明示いただくことを条件に，無償でその全部または一部を複製，翻訳，転載，引用および公衆送信することができます．なお，全体を複製，翻訳，転載または公衆送信する場合は，本書にある著作権表示を明示してください．
本書の著作権者は，本書の内容に関して，その正確性，完全性その他一切を保証するものではなく，その利用等により生じた損害について，法律上の構成のいかんを問わずいかなる責任も負いません．

Eclipseは，開発ツールプロバイダのオープンコミュニティであるEclipse Foundation, Inc.により構築された開発ツール統合のためのオープンプラットフォームです．
OracleとJavaは，Oracle Corporation およびその子会社，関連会社の米国およびその他の国における登録商標です．
Microsoft, Windows, Microsoft Office および Excel は Microsoft Corporationの米国およびその他の国における商標です．
その他，記載されている会社名，商品名，またはサービス名等は，各社の登録商標，または，商標である場合があります．

2

目次
1

日立製作所における実証実験 ............................................... エラー! ブックマークが定義されていません。
1.1
目的 ................................................................................................................................................................... 41.2
実証実験の内容................................................................................................................................................ 61.2.1
実証実験のユースケースとシナリオ.................................................................................................... 61.2.2
実証実験に適用したデータ ................................................................................................................... 6
1.2.3
プロジェクトモデルの設計 ................................................................................................................... 7
1.3
実証実験の環境................................................................................................................................................ 81.3.1
実証実験の環境 ....................................................................................................................................... 8
1.3.2
開発ソフトウェア ................................................................................................................................... 91.4
実証実験の結果.............................................................................................................................................. 10
1.5
実証実験の評価.............................................................................................................................................. 12
1.5.1
期待効果 ................................................................................................................................................. 12
1.5.2
課題 ......................................................................................................................................................... 121.6
まとめ ............................................................................................................................................................. 133

1 目的
日立製作所における実証実験の目的は，次の 2 つである．
(1) PROMCODE 仕様(PROMCODE ドメインモデルと OSLC 基盤)，PROMCODE アダプタソフトウ
ェアの実プロジェクトへの適用性を評価すること．
(2) 上記適用の際の課題を認識すること．
上記実験目的に沿い，実験における評価・検証項目を，表 1 の通り設定した．

表 1 実験における評価・検証項目
技術的観点# 評価・検証項目
評価・検証内容
進捗管理データ 各拠点で管理している作業進捗データを，プロジェクトマネージャ(以下，1への変換PM)の求める形式の進捗管理データに変換できるか？
拠点間でのデー2
拠点間で作業進捗データを滞りなく受け渡しできるか？
タ授受各拠点で，ツール導入のインフラ要件(ネットワークや稼動マシン等)を容易開発現場のツー3に満たせるか？
ル導入難易度
また，各拠点で，ツールのセットアップを容易に行えるか？
交換データのマ 拠点個別の作業進捗データを変換するためのマッピング仕様を容易に設計
4
ッピング定義の できるか？
難易度
また，同仕様にもとづくマッピングの定義を容易に行えるか？
ツールサポート
5
ツール実装，各種サポート等の運用の難易度は？の難易度
導入難易度の観点4

また， PM の開発拠点(以下，PM 拠点)と，それ以外の開発拠点との間のデータの授受は，表 2 に示す 2 種類の方法が考えられるため，双方のパターンについて，実験を行うこととした．
表 2 データ授受パターン
パターン名パターン A(Pull 型)

説明
PM 以外の拠点の組織規模が大きく，HTTP サーバの設置とインターネット公開が可能な場合．

パターン B(Push 型)

PM 以外の拠点の組織規模が小さく， HTTP サーバ設置とインターネット公開が困難な場合．

5

2 実証実験の内容
2.1 実証実験のユースケースとシナリオ本実験で想定したシナリオは，PROMCODE の「シナリオ 1」である．
パターン A(Pull 型)，パターン B(Push 型)それぞれに対し，次のユースケースシナリオを想定した．
(1) パターン A(Pull 型)のユースケースシナリオ：
1) (準備)：プロジェクト開始時，PM 以外の各拠点では，以下の準備を行っておく．
a) PM 拠点から随時 HTTP アクセス可能なサーバマシンを用意し，PROMCODE 準拠の作
業進捗データを応答で返すサーバソフト(3 節で詳述)をセットアップ，稼動させる．
b) 併せて，その拠点で使用する独自形式の作業進捗データを PROMCODE 準拠形式の作業進捗データに変換する「マッピング定義(3 節で詳述)」を作成しておく．
2) 各拠点のリーダーは，自拠点の作業進捗を更新する都度，上記 1)の HTTP サーバマシン所定ディレクトリに，最新版の作業進捗データを配置する．
3) PM は，所定のツール(3 節で詳述)を用い，各拠点の HTTP サーバから最新の作業進捗データを取得し，定型書式の進捗管理データに変換された状態で進捗状況を確認する．
(2) パターン B(Push 型)のユースケースシナリオ：
1) (準備)：プロジェクト開始時に，各拠点で以下の準備を行っておく．
a) PM 拠点：
各拠点から随時 HTTP アクセス可能なサーバマシンを用意し，HTTP で受信した
PROMCODE 準拠作業進捗データを，定型書式の進捗管理データに変換出力するサーバソフト(3 節で詳述)をセットアップ，稼動させる．
b) 各拠点：その拠点で使用する独自形式の作業進捗データを PROMCODE 準拠の作業進捗データに変換する「マッピング定義」を作成しておく．
2) 各拠点のリーダーは，自拠点の進捗情報を更新する都度，作業進捗データを PROMCODE形式に変換し送信するツール(3 節で詳述)を用いて，PM 拠点に進捗データを送信する．
※本シナリオでは，送信の際に進捗情報を PROMCODE 形式に自動変換し送信することを想定しているが，今回の実験では，該当する処理はパターン A で検証済みであるため，あらかじめ手作業で PROMCODE 形式に変換した進捗データを送信することで，擬似的に本場面を再現し実験した．
3) PM は，上記 1)のサーバソフトで定型書式に変換された進捗管理データを閲覧し，各拠点の進捗状況を確認する．

2.2 実証実験に適用したデータ実証実験に適用したデータは，産業系プロジェクト，金融系プロジェクト，各々，実際の開発現場の進捗管理データである．双方のデータともに，進捗管理の対象工程は，プログラミング～単体テストである．

6

2.3 プロジェクトモデルの設計
今回の実証実験に適用したデータにおいて，PM の求める形式の進捗管理データで表現されている情報項目を元に，PROMCODE ドメインモデルのクラス群にサブクラスを追加し，これらのサブクラスの属性として，必要となる情報項目を追加した．
追加したサブクラス群および情報項目群(サブクラスの属性)の抜粋を，図 1 に示す．

共通クラス

ScopeItem

Artifact

追加したサブクラス
プロジェクトサブシステム

機能

WorkItem

プログラ
ミング工程

ソースコードPCLプログラムID
言語区分
実行形態

レビュー予定日
レビュー実施日

Measure
PCL作成

コーディング

単体テスト

机上デバッグ

新規部LOC

改造部LOC

図 1 追加したサブクラス群および属性 (抜粋)

7

検査項目数

3 実証実験の環境
3.1 実証実験の環境パターン A(Pull 型)，パターン B(Push 型)の実証実験環境を，それぞれ図 2，図 3 に示す．

図 2 パターン A(Pull 型) 実証実験環境

図 3 パターン B(Push 型) 実証実験環境

8

3.2 開発ソフトウェア
本実験における開発ソフトウェアの一覧を表 3，表 4 示す．
表 3 パターン A(Pull 型) 実験の開発ソフトウェア一覧#1

開発ソフトウェア
PROMCODE アダプ
タソフトウェア
改造

開発言語
Java

2

PROMCODE データ変換ツール

RExcel○マクロ(VBA)

機能説明
PROMCODE アダプタソフトウェアに対し，本実験用に次の機能追加を行った．
(1)本実験用にカスタマイズした PROMCODE モデルの RDF/XML
表現向け XML ネームスペースを追加．
(2)PROMCODE 準拠データへの変換時に固定値を出力するマッピ
ング定義機能(例：工程名，等)(3)変換前の作業進捗データのセル値として，数式が記入されていた場合に，数式の演算結果を得る機能(例：テスト項目件数値が，正常条件数，異常条件数，境界条件数の合計で算出されるよう，数式で設定されている場合，等)(4)マッピング定義において，セル参照値の数式演算を定義する機能(例：変換前の作業進捗データに記載されている机上デバッ
グ時解決件数と単体テスト時解決件数からバグ解決件数を合計にて算出，等)
OSLC コンシューマとして動作し，OSLC プロバイダ(本実験においては，上記#1 の PROMCODE アダプタソフトウェア)からPROMCODE 準拠進捗データを取得して，PM 側で想定している定型書式の進捗管理データに変換出力する．

表 4 パターン B(Push 型)実験の開発ソフトウェア一覧#1開発ソフトウェア
PROMCODE データ
送信ツール

開発言語
R
Excel○マクロ(VBA)

2

PROMCODE データ受信サーバ

Java

機能説明
OSLC コンシューマとして動作し，あらかじめ用意した，PROMCODE 準拠形式に変換済みの RDF/XML 準拠進捗データを，OSLC プロバイダ(本実験においては，下記#2 の「PROMCODEデータ受信サーバ」)に送信する．
OSLC プロバイダとして動作し，OSLC コンシューマ(本実験においては，上記#1 の「PROMCODE データ送信ツール」)より送信された PROMCODE 準拠進捗データを受信し，PM 側で想定している定型書式の進捗管理データに変換出力する．

9

4 実証実験の結果
1 節で述べた，実証実験の評価・検証項目別の結果を表 5 に示す．
技術的観点では，パターン A(Pull 型)，パターン B(Push 型)とも，データの変換と HTTP を介したデータの受け渡しは可能であることを確認できた．
導入難易度の観点では，実験期間中の作業から，ツールカスタマイズはマッピング定義のみならば作業工数は 4 時間程度と小さいが，前提として若干の習熟が必要である事が判った．導入初期は，現場への支援者のサポートが必要である．併せて，ネットワーク等の設備を事前に考慮する必要がある．
表 5 実験結果# 評価・検証内容

1
技術的観点

進捗管理
データへの変換

2

拠点間でのデータ授受

3

開発現場のツール導入難易度

5

導入難易度の観点

4

交換デー
タのマッピング定
義の難易度

ツールサ
ポートの難易度結果
開発拠点の独自書式の作業進捗データから
PROMCODE 準拠進捗データへの変換は，各拠点で管理しているPROMCODE アダプタソフトウェアへの若干の機能作業進捗データを，PM追加(表 3 項番 1)で可能となった．の求める形式の進捗管 ○PROMCODE 準拠進捗データから PM の求める進捗管理データに変換できる
理データへの変換は，個別のプログラム開発 (パターか？
ン A(Pull 型)の場合：表 3 項番 2，パターン B(Push型)の場合：表 4 項番 2) で可能となった．
HTTP で直接通信のできる拠点間であれば，データの授受を滞りなく行える見込みが得られた．
拠点間で作業進捗デー
顧客先等，HTTP 直結不可の場合は，PROMCODE のタを滞りなく受け渡し ○データ交換方式(RESTful Web)をそのまま適用するこできるか？とはできない．この場合は，例えばデータのメール受け渡しを併用する等の工夫が必要となる．
各拠点で，ツール導入のPM 拠点または PM 以外の拠点，少なくともいずれかインフラ要件(ネットワ
で HTTP サーバマシンの用意，セットアップ(～数人ークや稼動マシン等)を日)とインターネットへの公開(イントラ/専用線直結容易に満たせるか？
△ でない場合)が必要(表 6)．
また，各拠点で，ツールのセットアップを容易に行えるか？
拠点個別の作業進捗デマッピング作業に慣れた専門の作業者を置く運用がータを変換するための可能であれば，現状のマッピング定義で通常時の運マッピング仕様を容易用は可能(必要作業工数：表 7)．に設計できるか？
△ ただし，PROMCODE アダプタソフトウェアの提供機
また，同仕様にもとづく能範囲内でマッピングが行えなかった場合の対応をマッピングの定義を容考慮要．
易に行えるか？
HTTP(S)によるデータ授受を想定したセキュリティツール実装，各種サポー対策が必要．
ト等の運用の難易度△
また，本番環境向けのツール実装は，現状，個別のは？
開発が必要．

10

表 6 ツール導入に必要な環境と作業
パターン名パターン A(Pull 型)
パターン B(Push 型)

PM 拠点
R マクロ等)のクライアントツール(Excel○導入(HTTP 接続要)HTTP サーバ機の確保，セットアップ(～数人日) ，公開要

PM 以外の拠点
HTTP サーバ機の確保，セットアップ(～数人日)，公開要
R マクロ等)のクライアントツール(Excel○導入(HTTP 接続要)表 7 マッピング作業に必要な作業工数
マッピング作業者
開発現場作業者

習熟した専門作業者

1 プロジェクトあたりのマッピング工数～数人日程度(大部分は学習コスト)～４時間程度説明
現状のマッピング定義は，OSLC の生のリソースタイプやプロパティへのマッピングであり，その理解がまず必要．
加えて，組織向けにカスタマイズされたプロジェクトモ
デルの理解が必要．
慣れれば難しくはなく，作業量も小さい．

11

5 実証実験の評価
5.1 期待効果
形式の異なる進捗情報の変換を自動化する際に，各拠点の作業進捗データ→PROMCODE データ，PROMCODE データ→PM 向け進捗管理データ，の双方で，再利用可能な共通技術(ツールやライブラリ等)が利用できるようになれば，自動化のツール等を短期間・低コストで実現できるようになること．

5.2 課題PROMCODE の弊社内への導入に向けた課題を挙げる．
(1) 適用の際，特に社内での施策立ち上げ時点におけるサポート部門等での，稼働環境確保，カスタマイズ対応が必要であると考える．
(2) 今回実証実験で検証した範囲のほか，弊社内で利用されている他のツールの進捗管理データ，品質管理情報も，収集する対象として継続して検討していく．

12

6 まとめ
今回の実証実験により，次の事が判った．
(1) PROMCODE モデルを介したプロジェクト進捗情報の変換は，今回選定した 2 つのプロジェク
ト事例において，可能だった．
(2) 開発現場への導入の際にクリアを要すると思われる主な課題：(PROMCODE のスコープ外と思われる課題を含む)
1) HTTP 直結不可の環境への導入方法
2) マッピング定義専任者を前提とした運用，または開発現場が自らマッピング定義できる水準への平易化
3) PROMCODE アダプタソフトウェアの機能追加を要する場合の考慮

プロジェクト現場からの進捗など管理情報を効率的に収集するための施策として，PROMCODE での検討成果を，弊社社内ツール等に活用していく計画である．

13