o365振り返り

Comienza Ya. Es Gratis
ó regístrate con tu dirección de correo electrónico
o365振り返り por Mind Map: o365振り返り

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. カテCの失敗に引き摺られた

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. 隠し持ってる情報が多く「聞いてない!」が発生。FIXするのに時間がかかった

2.2.3. 準備期間が不足していた

2.2.3.1. 段階移行、減数予約のリハが十分できていない

2.2.4. 移行手順作成後のリハーサルが必要

2.2.4.1. 確認する観点の確認・手順の作成が必要だった

2.3. 初期流動

2.3.1. 段階移行処理の課題があった

2.3.1.1. 障害発生とはならなかったが、テストが足りなかった

3. Try(改善/継続すること)