1. 全体の管理【★一色】
1.1. 上申・予算管理・全体計画【★一色】
1.1.1. QSライセンスプラン検討
1.1.2. 川崎・貿易交渉
1.1.3. 開発順序・ユーザ試行順序の計画【★一色・内藤】
1.1.3.1. 優先度・実装難易度・業務移行難易度からの順序の検討
1.1.3.2. 内藤内製販売系QSの取り扱い
1.1.4. 外部委託の計画
1.1.5. 社内・会社間のコミニュケーション方法の検討＆作成【 ★一色】
1.2. 業務移行
1.2.1. ユーザ展開
1.2.1.1. ユーザ教育【★内藤、上田】
1.2.1.1.1. QS習得
1.2.1.1.2. 説明会
1.2.1.1.3. ユーザ教育
1.2.1.2. 全社案内【★一色、上田】
1.2.2. 現行調査（結果を設計に落とし込み）【 ★内藤、一色】
1.3. 開発
1.3.1. 構成管理の管理監督【★西野】
1.3.1.1. QSの構成管理
1.3.1.1.1. アプリ・QVD等の試行・テスト・リリースの物件管理【 ★一色】
1.3.1.1.2. エクセル統計・新統計・ナビ統計・QV・次期統計の分野管理・スペース訳 【★一色】
1.3.1.1.3. アカウント・グループ分け・権限管理設計【 ★一色】
1.3.1.2. 構成管理のドキュメント更新の監督【 ★西野】
1.3.1.3. 統計アステリアと内製アステリア調整【 ★西野】
1.3.1.4. 技術サポート【★一色】
1.3.2. 仕様・設計
1.3.2.1. 過去データ移行
1.3.2.1.1. 方針検討【★一色】
1.3.2.2. 現新差異の明確化（見た目）【★一色】
1.3.2.3. 現新差異の明確化（データ）【★一色、内藤】
1.3.2.4. 現新のユーザPJメンバ説明【★一色】
1.3.2.4.1. 現新差異の方針の検討・ユーザPJメンバとのコミットメント【 ★一色】
1.3.2.5. Oracle蓄積設計【★一色】
1.3.2.6. マート・QVD物理設計（管理的）【★一色】
1.3.2.7. プロト
1.3.2.7.1. ユーザPJメンバ説明・フィードバック・決定【 ★一色】
1.3.2.8. ユーザPJメンバとの決定事項証跡残し【 ★上田】
2. GBCメンバ
2.1. データ流開発
2.2. 画面開発
2.3. QlikSenceアプリ管理（モック・プロト・リリース）
2.4. QlikSenceユーザ管理の方式設計（スペース分け・権限管理）
2.5. Oracle⇒SystemWalaker⇒Qlikの自動化の 設計・開発
2.6. 開発機関連
2.6.1. Oracle管理 インスタンス以降
2.6.1.1. 過去Oracle関連ドキュメントのアップデート
2.6.2. アステリア開発機インストール＆設定
2.6.2.1. 過去アステリアドキュメントのアップデート
3. 富士通＆都築テクノ
3.1. ハード調達～設置
3.2. ネットワーク設定
3.3. Oracleインストール （インスタンス未満）
4. ユーザ部門PJメンバ
4.1. 画面仕様の了解
4.1.1. プロトに対して利用者とともに評価 （指摘と了解）
4.1.2. 新統計とエクセル統計の統一について可不可を判断する （二次加工以降にインパクトが大きい）
4.2. 現行調査
4.2.1. 情シスに対して現状Navi統計で利用しているRNEを提供する （情シスで移行対象テーブル特定、抽出方法・集計方法の把握のため）
4.3. 業務移行
4.3.1. 「モック⇒五月雨リリース⇒並行期間」にて二次加工、三次加工の 動作確認と改修を自走で行う
4.4. 社内展開
4.4.1. 五月雨リリースの評価後OKについて、 部内・配下部門への正式リリースを宣言する
4.5. データの仕様
4.5.1. 新システムの部課変換の方式について情シスと検討し決定する
4.5.2. 新システム立ち上げ時の過去データ遡り作成期間、立ち上げ後の過去データ蓄積期間、 旧システムのアーカイブ・取り出し方法について情シスと検討し、決定する
4.5.3. 新システムの入力元の方式（EAGLE or 現状CSV）について情シスと協議し決定する
4.5.4. 先リリースの「QV⇒QS」の入力元と 先行移行システムの違いについて了解する ・QVだったもの＝データは変わらない ・QV以外であったもの＝入力がEAGLEになり誤りが是正される（是正の可能性がある）
4.6. 課題管理
4.6.1. 開発中・並行稼働・正式リリース後の部内・配下部門での 課題を抽出し、課題管理台帳に計上する（作業は情シス）