1. Keep（良かったこと）
1.1. 共通
1.1.1. 属人化させなかった
1.1.1.1. 常に全員での情報共有に努めた
1.1.1.2. UIのみ、APIのみ等、担当領域を絞らず全員が対応でき，仕様が解るようにタスク分割した
1.1.2. 標準の作り、操作方法を理解できた
1.1.2.1. COTOSの作りが理解できた
1.1.3. ★クリティカルな課題を各々のアイデア出しで解決した
1.1.3.1. 動的移行、ライセンス自動更新等
1.1.4. 脱CPQ
1.1.4.1. 属人からの脱出を果たせた
1.1.5. 保守チケット起票し標準改善ができた
1.1.5.1. ★標準の課題を見付け、改善に繋げた
1.1.6. ★検証・リカバリーの精度がとても高かった
1.1.6.1. A障害を未然に防いだ（NetRICOH連携でアドオンが消えた！）
1.1.6.2. 計上期間明細が二重に出来ていたが、日々の確認で気づくことができた
1.1.7. 情報交換・相談がし易い環境だった
1.1.8. 要員計画のリカバリー
1.1.8.1. 他PJに声をかけリカバリーを行った
1.2. ★（FB）移行作業
1.2.1. 差分移行の採用
1.2.1.1. 当日のリスクを軽減できた
1.2.2. クレンジングが完璧だった
1.2.2.1. 事前洗い出しが完璧だったので、当日問題が発生することがなかった
1.2.2.2. 電力のノウハウを生かしてデータチェックができた（office script）
1.2.3. ツール採用による作業時間短縮
1.2.3.1. SQL*Loaderを使用して環境間のデータ移動が簡単にできた
1.2.4. 手順詳細作成で移行作業の短縮ができた
1.2.5. 事前に恒久契約識別番号の問題をPG改修することで当日の作業軽減できた
1.2.6. 以前の移行で時間のかかっていたデータのインポートなどの時間短縮ができた
1.3. 初期流動
1.3.1. ★（FB）段階移行の自動化
1.3.1.1. カテCのハンド作業を軽減できている
2. Problem（改善/問題点）
2.1. 共通
2.1.1. 業務区の責任意識・巻き込みが出来なかった
2.1.1.1. UAT・リリース後に要望が多発した
2.1.1.2. 甘えすぎ！
2.1.2. 開発系を全部お任せにしてしまった
2.1.2.1. ログすら確認せず、結果皆さんの負荷となってしまった
2.1.2.2. 同じような確認を繰り返してしまった
2.1.3. 会議が多すぎる！
2.1.3.1. 資料作りに追われた
2.1.3.2. タスク調整がギリギリ
2.1.4. 三ツ木さんが甘え（丸投げし）すぎ！
2.1.4.1. 作業負荷が多くなった
2.1.5. ★（標準改善）資産管理ルールが曖昧な部分があった
2.1.5.1. マスタExcelの管理ルールを教えてもらうまで誰も知らなかった
2.1.5.2. 標準のルールが口伝になっている
2.1.6. ★開発のスケジュールがタイトだった
2.1.6.1. IT1が厳しかった
2.1.6.2. wishさんからの引継ぎが不完全だった
2.1.7. 要件がヒアリングしないと出てこない
2.1.8. ★（標準改善）マスタの構成が複雑化していて理解が難しい
2.1.9. カテＣの失敗に引き摺られた
2.1.9.1. 要員が確保できなかった
2.1.10. ★STで検証していない機能・シナリオが存在する
2.1.10.1. 自動更新案内メール
2.1.10.2. オンサイト有からの契約変更（web）
2.1.10.3. 自動更新日取得・更新バッチ
2.1.11. ★（標準改善）CPQ画面のレビューをしてもらっていない
2.1.11.1. 依頼したが、反応がなかった
2.1.11.2. エラーメッセージの提示がされないので、こちらで考えなければならなかった
2.1.12. cron設定が直前となってしまいリリース後にNCE固有ジョブが必要だったことに気が付いた
2.1.13. ★業務窓口が属人化している
2.1.13.1. 久保さんの理解不足！
2.1.13.2. 対応は早いが、適切な回答がこない！
2.1.13.3. 久保さんの言葉の解析がムズカシイ！
2.1.14. 朝会が長すぎる
2.2. ★（FB）移行作業
2.2.1. 手順の確認不足
2.2.1.1. STの並行となった為、移行準備が不十分だった
2.2.1.2. 遅延に繋がってしまった
2.2.1.3. 大量データを扱う想定がされていない手順が存在した
2.2.1.4. IFS帳票差分移行がうまくいかず結局やり直してしまった
2.2.2. RITOSが意地悪
2.2.2.1. 隠し持ってる情報が多く「聞いてない！」が発生。ＦＩＸするのに時間がかかった
2.2.3. 準備期間が不足していた
2.2.3.1. 段階移行、減数予約のリハが十分できていない
2.2.4. 移行手順作成後のリハーサルが必要
2.2.4.1. 確認する観点の確認・手順の作成が必要だった
2.3. 初期流動
2.3.1. 段階移行処理の課題があった
2.3.1.1. 障害発生とはならなかったが、テストが足りなかった