振り返りこそエンジニアの本領

Transcript

1. 振り返りこそ エンジニアの本領 Sep 4, 2026 X:@negimaboy̲1293 Tamagawa.dev#3 Negima
2. $ whoami Negima(根本 銀河) 2023卒 • NTTデータフィナンシャルテクノロジー 決済イノベーション事業部 • クレジットカード会社向けサービスのSRE・性能試験TL・AI導入支援など • ソフトウェアアーキテクチャの話が好き
3. 私はIT業界の 人ではなく仕組みで解決する 雰囲気が好きです
4. 私の好きな文化 例えば • 先日別案件の同期が大トラブルを起こしてしまった ‣ 厳密にはトラブルの一端となった作業の手順書を書いてしまっていた • 事後対応は多方面まで影響が伸びたが、周囲は彼を責めることはしなかった ‣ 振り返りをしっかり行うように諭すことが多かった この文化の源泉が振り返りにあるんじゃないかと思った
5. 振り返りについて 「振り返り」とは • スクラムで「レトロスペクティブ」と呼ばれているアレ • (うちは)KPTのフレームワークに沿い隔週1時間枠を設けて実施している ‣ Keep、Problem、Tryのこと。 Keepはよかった点、Problemは課題点、TryはK・Pを受けての次のアクション • 基本的な流れはK・Pの選定→深掘り対象のP選定→Try策定の流れ
6. 振り返りについて 振り返りの本質 • 我々エンジニアはドメインやユーザの課題を構造化し、 ものづくりをしている • 振り返りも何らかのフレームワークに従い、 自チームの課題に対して深掘りを行なっている 対象の課題が「ユーザ」か「自チーム」かだけで やっているのはどちらも「課題の構造化」なのでは？
7. 振り返りについて 周りを見ても... • うまく回せているチームは質の高い振り返りを実施できている → 課題を構造化する適切な作法を身につけている気がする • トラブル続きのチームだと振り返りを回す時間がない →自チームの課題と向き合う時間がなく、チームとして構造化するスキルも身に つかない悪循環に陥る
8. 仕組みで解決するために 最初の件に戻ると • エンジニアは構造化の手数が多いからこそ、仕組みから解決する方法に フォーカスできる • その同期も責任を感じすぎずに業務復帰でき、 「振り返りによって視野が広がった」と刺激を受けていた 周りを助けるためにも、 日頃から振り返りの時間を用意すべし
9. まとめ • 振り返りとは自分たちの「課題の構造化」を行う場であり練習場でもある • 日頃から構造化に慣れているエンジニアだからこそ、誰かのせいにすることなく 仕組みで解決するアプローチができるのかもしれない • 振り返りこそ(課題と向き合い構造化することが多い)エンジニアの本領
10. Enjoy your hacking！