Let's BPS

Just an initial demo map, so that you don't start with an empty map list ...

Get Started. It's Free
or sign up with your email address
Rocket clouds
Let's BPS by Mind Map: Let's BPS

1. 担当

1.1. 白戸さん

1.2. 佐宗さん

1.3. 林さん

2. 効率を上げる仕組みの構築と共有

2.1. アウトプット

2.1.1. 可視化

2.1.1.1. 改善の効果計測

2.1.2. デモ

2.1.2.1. 早めのフィードバック

2.2. やること

2.2.1. デモ

2.2.1.1. フィードバックの定義

2.2.1.2. デモの仕方の定義

2.2.1.2.1. より良いフィードバックをもらうため

2.2.1.3. ナレッジ

2.2.1.3.1. 保存場所の選定

2.2.1.3.2. データ設計

2.2.1.3.3. 何を?

2.2.2. 可視化

2.2.2.1. 計測方法の定義

2.2.2.2. 計測に必要なデータ定義

2.2.2.3. どう見せる化?

2.2.2.4. ステータス

2.2.2.4.1. 未実施

2.2.2.4.2. 改善中

2.2.2.4.3. 改善した

2.2.3. 計画

2.2.3.1. 開始はいつ

2.2.3.2. 今季の目標

2.2.3.2.1. 月単位

2.3. 目的

2.3.1. 実施した改善内容の効果と他チームへの共有

2.3.2. 手戻りを減らすためのフィードバックループ(仕組み)の作成

2.4. 担当

2.4.1. 坂尾さん

2.4.2. 佐宗さん

2.4.3. 林さん

3. 開発とテストに運用観点を盛り込む

3.1. アウトプット

3.1.1. ナレッジ

3.1.1.1. 情報

3.1.1.1.1. 他部門からの情報

3.1.1.1.2. お客様からの情報

3.1.1.1.3. プロジェクトからの情報

3.2. やること

3.2.1. データ設計

3.2.2. 保存先選定

3.2.2.1. 現状エクセル

3.2.3. フロー

3.2.3.1. 更新方法

3.2.3.2. 変更管理

3.2.3.3. 展開

3.3. 目的

3.3.1. インシデントの削減

3.3.2. 考慮漏れ削減

3.3.2.1. 最終的には設計時に観点を考慮できるようにする

3.3.2.2. お客様の運用に耐えられる

3.3.3. 全プロジェクトで標準化

4. 自分たちがユーザーになる

4.1. 目的

4.1.1. お客様のシステム要件での動作検証

4.1.2. システム要件関連のインシデント削減

4.2. やること

4.2.1. インフラ設計

4.2.2. 現状とのGAP分析

4.2.3. ナレッジ

4.2.3.1. BPOチームからの情報取得

4.2.3.1.1. どうやってもらうかも含め

4.2.3.2. 運用現場再現PJの引き継ぎ

4.3. インプット

4.3.1. クラウドサービスのリリース管理で使用

4.3.2. テスト環境に運用現場再現PJの情報を盛り込む

4.4. 担当

4.4.1. 芳村さん

4.4.2. 白戸さん

4.4.3. 佐宗さん

5. 開発プロジェクトとインシデントの共存

5.1. やること

5.1.1. プロジェクト状況の可視化

5.1.1.1. バーンダウンにインシデントも含むようにする

5.1.1.2. プロダクトバックログのリファイン

5.1.1.2.1. インシデントとプロジェクトスコープの優先順位の見える化

5.1.2. インシデント情報共有

5.1.2.1. 情報

5.1.2.1.1. お客様運用情報

5.1.2.1.2. 考慮漏れ

5.1.2.2. 最終的なアウトプットは観点にまとめる

5.2. 目的

5.2.1. インシデントもプロジェクトの成果とする

5.2.2. プロジェクトスコープとインシデントの優先順位付け

5.2.3. 観点を取り込む

5.2.3.1. 実際にお客様から上がってきたインシデント

5.3. 課題

5.3.1. 会社がなんというか。。。

5.3.2. 優先順位を誰が決める?

5.3.2.1. 矢野さん?

5.3.2.2. 丸山さん?

5.3.2.3. 社長?

5.4. 担当

5.4.1. りき

5.4.2. 白戸さん

5.4.3. 佐宗さん

6. ドキュメントの充実化

6.1. やること

6.1.1. StyleCopの徹底

6.1.1.1. DocyGenによるモジュール仕様書作成

6.1.2. 設計資料作成

6.1.2.1. その設計に至った経緯

6.1.2.2. 調査内容

6.1.2.3. 格納先の選定

6.1.2.3.1. Confluenceで統一したい

6.1.2.3.2. OneNote廃止

6.1.2.4. ドキュメントの管理方法定義

6.1.2.4.1. ドキュメントの構成

6.1.2.4.2. 最新版の管理方法

6.2. 目的

6.2.1. 他部門への情報発信による部門間の齟齬を減らす

6.2.2. 人の入れ替えによるオーバーヘッドを減らす

6.2.2.1. スムースに開発へ

6.3. アウトプット

6.3.1. 営業

6.3.1.1. 製品コンセプト

6.3.1.1.1. 提供タイミングとかは丸山さんと社長がボールを持つ

6.3.2. PS/SSP

6.3.2.1. 仕様書

6.3.2.1.1. 概要図レベル

6.3.2.1.2. システム要件

6.3.3. SSC

6.3.3.1. 運用コンセプト

6.3.3.1.1. 設計・実装時に想定した使われ方

6.3.3.1.2. 何のために必要な機能か

6.3.4. Team

6.3.4.1. 仕様書

6.3.4.1.1. 基本設計書

6.4. 担当

6.4.1. 平岡さん

6.4.2. 芳村さん

6.4.3. 佐宗さん

7. パワーランチ

7.1. 毎週水曜でいい?

7.1.1. 水曜休みなら木曜