Please enable JavaScript.
Coggle requires JavaScript to display documents.
10/22 テーマ：運用Gを効率良く、精度高く進めるには？, 12/17テーマ：運用Gを効率良く、精度高く進めるには？,…
10/22 テーマ：運用Gを効率良く、精度高く進めるには？
:smiley:
Keep
続けて行きたいこと
:warning:ルール
・発揮した価値や、改善から成果につながったこと を記入
・取り組んだ結果、周りから「褒めて」もらったことを考えてみる
（望）
松永さんとの毎日作戦会議
課題の認識合わせが進んだ
立木さんとの毎日作戦会議
課題の認識合わせが進んだ
エスカレMTGでのペア調査
調査完了できてないものが無くなった
モニタリング
金額ズレ
データ不整合
エラー検知
エラー検知後のフロー整備
要件確認：松永さんに確認→矢野さんに投げるの流れ（小久保）
早期にリリース延期の判断ができた（松永）
issueの詳細についてペアプロで確認するようにした（立木）
一件だけだがissueの解消ができた（立木）
ペアで仕様を確認したことで、レビュー工数が減った（立木）
立木さんとのissue解消のミーティング（古川）
望さんと毎朝進捗・課題を確認（松永）
毎日ERPの機能を触る（古川）
PDF運用はPDF運用Tで進行して問題なく進行できている（大川）
:star:
Try
実践したいこと
:warning:ルール
・「しっかり」や「きちんと」といった抽象的な表現を避けよう
・具体的にどういう行動をとるのか分かる内容を記載しよう
・次スプリントのスケジュールに落とし込める範囲で記載しよう
ANDPADの理解
金曜日に実施される ERP機能勉強会 に参加する（古川）
金曜夕方の機能勉強会のやり方を具体化する（立木）
金曜のユーザー解像度UP勉強会を継続開催し、後から見られるようにドキュメント化にも注力（小久保）
テスト環境の整備、商用に近いデータ（松永）
Stagingで整備する
小改善
仕様の具体化、画面、アウトプット例を作成する（松永）
小改善のフローの整理
時間軸、テスト環境アップからの修正
（望）
リリースまでタスクの洗い出し、スケジューリング（松永）
要件定義完了チケットを増やす（小久保）
お客さんとスケジュールを握らない、色々な要因でスケジュールがずれる（望）
時間の確保
朝イチで片付けられることのルーチン化（小久保）
チームのパフォーマンスの可視化
追加されたissueと解決したissueの数を週次で可視化する（立木）
金額ズレ、スクラムチケットの Github Issue化（望）
:!?:Problem
改善したいこと
:warning:ルール
・「Problemを共有するのがチームの成果を導く」という意識を持つ
・「なぜそうなったのか？」を深掘りして考える。
・Problemが多い人を詰問するのではなく、共に解決策を考える。
小規模フロント改善系が着手出来てないのがあり
→改善しやすいようにNuxt化を進めたい（小久保）
小改善が遅延する（望）
データ修正工数が可視化できていない（望）
暫定対応は着手できているが、恒久対応に着手できていない（望）
認識合わせのMTGコストが高い / 毎日30min（望）
エスカレMTGのMTGコストが高い / 毎日30min（望）
スクラムリスト、金額ズレリストからのEGタスク落とし込み（望）
小改善のrspec、レビューが後回しになる（望）
小改善の遅延（松永）
リリースまでのスケジュール設定がない
要件設定に漏れがある
PRレビューが溜りがち（古川）
最近朝一でレビューするようにしてみた
issueの数に対してはまだ修正速度が足りない（立木）
いろいろな細かい作業で時間を取られるケースが多い（立木）
staging2のデプロイにかかる時間の見積もりが甘かった（立木）
issue改善でプログラムの修正はすぐできたとしても、それがどこの機能なのかわかってない（古川）
改修済のチケットのUATに着手できない（松永）
UATに時間がかかる（松永）
対応内容が読み取れない
使い方や挙動がわかならない箇所も多い。ドキュメントもあまりない。
→勉強会で徐々に解消（小久保）
developの変更が大きくローカル維持するの大変だった
:warning:ルール
・時間は1時間
・振り返り（10分）→Keep（10分）→Prblem（10分）→Try（30分）の順
・基本一人一件（すごく共有したいものがある場合がもう一件）
・ゴールは、Tryの具体化
12/17テーマ：運用Gを効率良く、精度高く進めるには？
:smiley:
Keep
続けて行きたいこと
:warning:ルール
・発揮した価値や、改善から成果につながったこと を記入
・取り組んだ結果、周りから「褒めて」もらったことを考えてみる
フロント関わるものは要件定義してチケット起こし、引き続き「開発着手前」を増やす（小久保）
課題があればチームに共有しNextActionを取ることができている（望）
SS→Backlog移行を開始した（松永）
脆弱性対応のペアプロで修正の方向性の意思統一が取れるのでよい（古川）
リリース前日にはリリース予定のPRがマージされているようになった（立木）
スクラム定例に、仕様確認のチケットを持ち込んで解決（松永）
古川さんとリリース作業ができるようになった（立木）
:star:
Try
実践したいこと
:warning:ルール
・「しっかり」や「きちんと」といった抽象的な表現を避けよう
・具体的にどういう行動をとるのか分かる内容を記載しよう
・次スプリントのスケジュールに落とし込める範囲で記載しよう
Backlog運用＆カテゴリー管理を定着させる（松永）
github連携を考える
issueの優先順位をもう少し細かく見る（立木）
優先度が高く、軽ボリュームのチケットを１件／W 古川さんに渡す（松永）
slackに上がってくるエラー系通知に目を通してみる（古川）
日にちではなく、1日の中で時間区切って、Backlog700件の対応してみる（小久保）
軽微なバグを修正する時間を週1くらいは作る（立木）
（EDI連携を早く実装する）
金額づれ対応残分のチケット化（松永）
起票されたチケットを軽く紹介する場作る？（小久保）→スクラム定例で「今週起票チケットの紹介」コーナーを再開
:!?:Problem
改善したいこと
:warning:ルール
・「Problemを共有するのがチームの成果を導く」という意識を持つ
・「なぜそうなったのか？」を深掘りして考える。
・Problemが多い人を詰問するのではなく、共に解決策を考える。
脆弱性の解消以外が進みづらくなっている（立木）
ベストエフォートなので、見通しがつきにくい（松永）
backlog700件からフロント課題を抜き出す時間取れてない（小久保）
脆弱性対応以外のタスクを完全に放置してる（古川）
チケット起票したものがいつ対応されるのか見ずらい→人少ないから仕方ない><（小久保）
金額づれ対応がスコープから漏れがち（松永）
リリース内容の確認が遅れがち（立木）
:warning:ルール
・時間は1時間
・振り返り（10分）→Keep（10分）→Prblem（10分）→Try（30分）の順
・基本一人一件（すごく共有したいものがある場合がもう一件）
・ゴールは、Tryの具体化
11/19テーマ：運用Gを効率良く、精度高く進めるには？
:smiley:
Keep
続けて行きたいこと
:warning:ルール
・発揮した価値や、改善から成果につながったこと を記入
・取り組んだ結果、周りから「褒めて」もらったことを考えてみる
矢野さんとの勉強会
→UI改善に向けて改善要望をストックしていく
シートのステータスを色分けしてみた（松永）
チケットにアウトプットを明確に記載する（松永）
ANDPAD機能勉強会は引き続き参加する（古川）
PDF運用はPDF運用Tで進行して問題なく進行できている（大川）
スクラム定例を２部構成にした、後半で要件確認（松永）
リリースのマージ期限に全てのPRが揃った（立木）
issueの解消が進んでいる（立木）
金額ズレの監視を追加/修正するフローがある程度見えた（立木）
:star:
Try
実践したいこと
:warning:ルール
・「しっかり」や「きちんと」といった抽象的な表現を避けよう
・具体的にどういう行動をとるのか分かる内容を記載しよう
・次スプリントのスケジュールに落とし込める範囲で記載しよう
要件未確定チケットを選別し、スクラム定例で確認（松永）
CREチームが整備してくれてるドキュメントを、
ERPチームのオンボオーディング資料としても良いかも
https://88-oct.atlassian.net/wiki/spaces/OCT/pages/614466286/AP
（小久保）
UATを実施する時間を設定する（2時間） 松永
大川さん・小泉さんと相談して、なんとなくのスケジュール立てる→
Nuxt化する１画面目決める（小久保）
ES検索周りのテスト自動化方法をtricknoteさん交えて相談する（古川）
一旦全体でどのくらいの時間を使ったかを計測していく（大川）
フロントちょっとでも関わりそうなチケットは、
定義してっちゃう（小久保）
PDFは依頼箇所＋関連書類も確認してから実装する（大川）
朝一でPRレビューやる（古川）
１週間の中で、実行予算・スクラム・Nuxt化で、それぞれどの位の配分で時間使っていくかざっくりとでも決める（小久保）
エスカレ定例で、判断を悩むケースは改修案までは出し切る（松永）
レビューの観点を増やす（コードの問題や影響範囲の検討）（立木）
:!?:Problem
改善したいこと
:warning:ルール
・「Problemを共有するのがチームの成果を導く」という意識を持つ
・「なぜそうなったのか？」を深掘りして考える。
・Problemが多い人を詰問するのではなく、共に解決策を考える。
UAT未確認を確認扱いにしてしまった（松永）
フロントだけでサクサク進むチケットの見極め難しい（小久保）
タスク管理がスプレッドシートとgithub issueの２つあるので
優先度の確認しづらい（古川）
Nuxt化を１画面でも進めて、UI改善進めやすくしたい
（矢野さんからもUI変えるだけで、
ユーザーの不満解消できるとこ多いとい言われてる）小久保
エスカレチケットの対応内容が曖昧のまま実装に入ったケースがあった（松永）
ES検索周りの影響範囲がわかってなかったのでリリースの切り戻し作業が発生してしまった。
ES検索周りも自動テストする仕組みが必要（古川）
実装済（UAT未着手）がたまってきた（松永）
developの変更が大きくローカル維持するの大変だった（大川）
実行予算との時間配分が明確出なかった（大川）
PDFリリースした直後の修正が2回あった（大川）
ややレビューが甘い傾向があった。わかっているからapprove的な読み方をしてしまった（立木）
:warning:ルール
・時間は1時間
・振り返り（10分）→Keep（10分）→Prblem（10分）→Try（30分）の順
・基本一人一件（すごく共有したいものがある場合がもう一件）
・ゴールは、Tryの具体化
1/14
:!?:Problem
改善したいこと
:warning:ルール
・「Problemを共有するのがチームの成果を導く」という意識を持つ
・「なぜそうなったのか？」を深掘りして考える。
・Problemが多い人を詰問するのではなく、共に解決策を考える。
Nuxt化を進められて無い。。。（小久保）
リリース時に1分間サービスが落ちてしまった（立木）
ERP通常運用に割く時間取りたい（小久保）
対応件数が多すぎてリリースノートの整備にかなりの工数を取られた（立木）
JIRA-Backlog連携が煩雑（両方に導線貼るなど）（松永）
PRレビューが追いつかない（古川）
PRがマージされた後issueのcloseをしてなかった（古川）
要件確認の時間が取れない（松永）
Backlogに要件をわかりやすくして開発の手戻りを減らす（鈴村）
:smiley:
Keep
続けて行きたいこと
:warning:ルール
・発揮した価値や、改善から成果につながったこと を記入
・取り組んだ結果、周りから「褒めて」もらったことを考えてみる
zenhubを運用し始めたので、issueの状態がわかりやすくなった（立木）
UAT時間を週２で1時間確保（松永）
今回のリリースで大量に修正が入った（立木）
Backlog運用を開始し、検索性が上がった（松永）
脆弱性対応のpermit系が一段落した（古川）
Backlog運用を開始して案件管理がしやすくなった（鈴村）
Backlog見やすい！状況がわかりやすい！（小久保）
午前中に建築業界系の動画(15分程度)を見るようにした（古川）
金曜朝の勉強会で、矢野さんがUI改善案を見せてくれて、言葉で聞いてた改善要望が、より具体的に理解できた。（小久保）
:star:
Try
実践したいこと
:warning:ルール
・「しっかり」や「きちんと」といった抽象的な表現を避けよう
・具体的にどういう行動をとるのか分かる内容を記載しよう
・次スプリントのスケジュールに落とし込める範囲で記載しよう
要件定義のスピードをあげる。(鈴村)
backlogの運用フローをまとめる（松永）
より能動化＆自動化
脆弱性対応のタスクが多く頭がボーッとしてくるのでこまめにリフレッシュしてみる（古川）
PRにmigrationが存在する時のレビューを気を付ける（立木）
レビュー観点をCIでチェックしてコメントするようにする（立木）
週1回1時間でも、運用系の対応時間確保（小久保）
週1回、矢野さんの要望を吸い上げる時間を確保（鈴村）
リリースノートの作り方を簡略化できないか検討する（立木）
Nuxt化の動き、プロダクト横断でも進めようとしてるみたいなので、注視・上手く乗る（小久保）
:warning:ルール
・時間は1時間
・振り返り（10分）→Keep（10分）→Prblem（10分）→Try（30分）の順
・基本一人一件（すごく共有したいものがある場合がもう一件）
・ゴールは、Tryの具体化
2/12：雛形
:smiley:
Keep
続けて行きたいこと
:warning:ルール
・発揮した価値や、改善から成果につながったこと を記入
・取り組んだ結果、周りから「褒めて」もらったことを考えてみる
:star:
Try
実践したいこと
:warning:ルール
・「しっかり」や「きちんと」といった抽象的な表現を避けよう
・具体的にどういう行動をとるのか分かる内容を記載しよう
・次スプリントのスケジュールに落とし込める範囲で記載しよう
例）修正箇所別にチケットを分ける（松永）
:!?:Problem
改善したいこと
:warning:ルール
・「Problemを共有するのがチームの成果を導く」という意識を持つ
・「なぜそうなったのか？」を深掘りして考える。
・Problemが多い人を詰問するのではなく、共に解決策を考える。
:warning:ルール
・時間は1時間
・振り返り（10分）→Keep（10分）→Prblem（10分）→Try（30分）の順
・基本一人一件（すごく共有したいものがある場合がもう一件）
・ゴールは、Tryの具体化
テーマ：雛形
:smiley:
Keep
続けて行きたいこと
:warning:ルール
・発揮した価値や、改善から成果につながったこと を記入
・取り組んだ結果、周りから「褒めて」もらったことを考えてみる
:star:
Try
実践したいこと
:warning:ルール
・「しっかり」や「きちんと」といった抽象的な表現を避けよう
・具体的にどういう行動をとるのか分かる内容を記載しよう
・次スプリントのスケジュールに落とし込める範囲で記載しよう
例）修正箇所別にチケットを分ける（松永）
:!?:Problem
改善したいこと
:warning:ルール
・「Problemを共有するのがチームの成果を導く」という意識を持つ
・「なぜそうなったのか？」を深掘りして考える。
・Problemが多い人を詰問するのではなく、共に解決策を考える。
:warning:ルール
・時間は1時間
・振り返り（10分）→Keep（10分）→Prblem（10分）→Try（30分）の順
・基本一人一件（すごく共有したいものがある場合がもう一件）
・ゴールは、Tryの具体化