Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
アジャイルであり続けるために技術スキルと向き合う
Search
TK
August 27, 2022
Technology
4
3.4k
アジャイルであり続けるために技術スキルと向き合う
Scrum fest sendai 2022
TK
August 27, 2022
Tweet
Share
More Decks by TK
See All by TK
私のチームが実践しているスプリントに集中するための取り組み
tkredman
0
2k
覗いてみよう!現場のスクラムチーム
tkredman
0
2.9k
「守破離の守!」スクラムガイドをみんなで読んでみた。
tkredman
0
1.6k
効果的なスプリントプランニングのトライ
tkredman
0
100
アジャイルに向かう組織に聴いてほしいアジャイルへの第一歩
tkredman
0
43
スクラム開発と向き合うことでスクラムを習得する
tkredman
0
99
たった一つの質問でマインドセットの灯をともせ!
tkredman
0
24
Other Decks in Technology
See All in Technology
AI駆動開発を推進するためにサービス開発チームで 取り組んでいること
noayaoshiro
0
250
Modern_Data_Stack最新動向クイズ_買収_AI_激動の2025年_.pdf
sagara
0
240
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
11
78k
衛星画像超解像化によって実現する2D, 3D空間情報の即時生成と“AI as a Service”/ Real-time generation spatial data enabled_by satellite image super-resolution
lehupa
0
140
【Oracle Cloud ウェビナー】クラウド導入に「専用クラウド」という選択肢、Oracle AlloyとOCI Dedicated Region とは
oracle4engineer
PRO
3
130
リセラー企業のテクサポ担当が考える、生成 AI 時代のトラブルシュート 2025
kazzpapa3
1
150
E2Eテスト設計_自動化のリアル___Playwrightでの実践とMCPの試み__AIによるテスト観点作成_.pdf
findy_eventslides
1
590
ACA でMAGI システムを社内で展開しようとした話
mappie_kochi
1
310
三菱電機・ソニーグループ共同の「Agile Japan企業内サテライト」_2025
sony
0
130
生成AIとM5Stack / M5 Japan Tour 2025 Autumn 東京
you
PRO
0
240
Git in Team
kawaguti
PRO
3
330
OpenAI gpt-oss ファインチューニング入門
kmotohas
2
1.2k
Featured
See All Featured
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
140
34k
Optimizing for Happiness
mojombo
379
70k
Product Roadmaps are Hard
iamctodd
PRO
54
11k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
358
30k
We Have a Design System, Now What?
morganepeng
53
7.8k
Build The Right Thing And Hit Your Dates
maggiecrowley
37
2.9k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
37
2.6k
RailsConf 2023
tenderlove
30
1.2k
The Straight Up "How To Draw Better" Workshop
denniskardys
237
140k
Rails Girls Zürich Keynote
gr2m
95
14k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
127
53k
Transcript
アジャイルであり続けるために技術スキルと向 き合う Retty株式会社 今井貴明 Scrum Fest Sendai 2022 2022/08/27
自己紹介 • TK (Imai Takaaki) • エンジニア ◦ 2015〜SIer ◦
2021〜Retty株式会社 • @t_k_redman
今日のお話
アジャイルな開発に”エンジニアとして”どう貢献する? この姿勢は 首が凝る
• 関わり方も様々だし役割もいろいろある • 今回はあくまでもエンジニアとしてという話 ものづくりへの関わり方はたくさんある
“アジャイル推進担当”だったころ
• 「うちもアジャイルを”やろう!”」という施策がきっかけ • 知っていくうちに本質を突き詰めていくような考え方に深く共感 した • 自分たちもそんな風にものづくりをしたいと思った なぜアジャイルを探求し始めたのか
• アジャイルを社内に推進する人(途中から野良化) ◦ プロジェクトヒアリング&支援 ◦ ドキュメントの社内展開 ◦ セミナーや勉強会開催 • 小さめの開発を拾ってはスクラムを試したり
◦ 事例化したりしなかったり 前職の私のお仕事
• 組織にアジャイルを広めるのは一筋縄ではいかない • でも、みんながアジャイルを深く知りさえすれば、アジャイルな ものづくりをする理想の環境が実現できるはず! 必要なのはアジャイルの理解?
• この世界を実践しているところを見てみたい! • どれほどこの考え方が浸透しているのだろう 転職するときに考えていたこと We are one!
RettyにJoinしてから
• みんなアジャイルやスクラムのことを考えていると思っていた • 実際そんなことはなくてあくまでも「自分たちの開発の進め方 はこう」として捉えられていた • そんな環境にエンジニアとして入った自分は何をしていけるだ ろう? Rettyに入って
• それまでと同じように立ち振るまった • 自分の知っていること、分かっていることを活かす動き 自分のできることをやっていった それ改善 した方が… チームの課題を見つけて あるべき姿を意見する 他部門との壁を感じたので
直接会話しに行って現状を把握する 本来こうある べきでは
• 最初のピアレビューで上がってきた評価はイマイチ • 自分の中ではそんなに悪くない動きだと思っていた ◦ 実際それ自体が悪かったとは今でも思ってはないけど 予想外のフィードバック 行動の意図がよくわからないこと がある ごもっともな指摘をしてはいるけど
実際どうしていけば?
• 最初のピアレビューで上がってきた評価はイマイチ • 自分の中ではそんなに悪くない動きだと思っていた ◦ 実際それ自体が悪かったとは今でも思ってはないけど 予想外のフィードバック 行動の意図がよくわからないこと がある ごもっともな指摘をしてはいるけど
実際どうしていけば? どうしてこうなった?
• チームから評価されてるのは「手を動かしている人」 ◦ アジャイルについて考えているか否かは関係なくそういう 動きになっている 周りを見渡してみた このプルリクでコスト 20% 削減できます! ここのソースコード
お掃除しました! この部分はテストを 足しておこう
• チームから評価されてるのは「手を動かしている人」 ◦ アジャイルについて考えているか否かは関係なくそういう 動きになっている 周りを見渡してみた このプルリクでコスト 20% 削減できます! ここのソースコード
お掃除しました! この部分はテストを 足しておこう 自分の経験の中にはない事ばかりで それをマネするには知らないことが多すぎた
• 組織やチームから期待されているのは、エンジニアとしての責 任を果たすことなのではないか • 自分のやっていることはその期待値を満たすものだったの か? 自分は”エンジニアとして”期待されている
エンジニアとしてできることをしている人たちがいる • エンジニアとしてアジャイルな開発に貢献するってどうやるん だっけ?
• 自分が知ってきた中で思い浮かぶことというと・・・ ◦ 質の良いソースコードを書こう ◦ テストコードは書くべき ◦ 継続して運用していける仕組みを作ろう • 「こういうことが必要なんだ」とは前から学んできたけど、もっと
言うとどういうこと? “エンジニアとして”と言ったらこんなこと?
質の良いソースコードを書こう • 例えば・・・ 可読性が高ければ変更箇所 の当たりがつけやすい 変更による影響範囲がわかりやすくな り想定外のバグが減る クラスに適切な責務を持たせて ロジックをまとめる 設計意図がわかりやすい命名やインター
フェースを定義しておくことで品質が保たれ やすくなる 変数名、関数名、引数、関 数の粒度、etc 余計な調査やバグ修正が減って自分 たちの開発速度が上がっていく!
テストコードは書くべき • 例えば・・・ 複雑な要件が満たされているかを常 にチェックできるようにする 仕様が満たされていることを担保で きるだけのテストケースを網羅して おく 変更の度に手動で全パターンをテス トするようなことはしたくない
意図がわかりやすいテストケースを 作っておくことでそのロジックに期待さ れている仕様が読み取れる 変更に強い状態を維持する 変更を加えやすくなり品質と開 発速度が上がる!
継続して運用していける仕組みを作ろう • 例えば・・・ プロダクトの状態を知るためのメトリクス をどう取得してどのように使っていくか 異常検知、アラート、障害時 対応の仕組みや体制 プロダクトや自分たちの開発の 改善点が見つかる! レスポンス速度、コスト
自分たちのサービスがどのように使わ れているかが測定されて分析できる状 態になっている テスト用環境を容易に準備できる仕組み や日々のリリースフロー整備
• それらが大事であることをずっと見聞きはしていた ◦ 近くで見たことで、エンジニアにしかできない貢献として解 像度をあげることができた • こういうことを日々考えていくのがエンジニアとしての一つの貢 献 自分が信じていたものの解像度が上がった
おわりに
役割によってどう貢献するかは変わる • 思想や開発方法論の探求はそれはそれで良いと思う ◦ 個人的にはそっちが楽しいみたいなところがある • どの役割で関わるかによって必要なスキルは変わる ◦ 価値を届ける開発についてずっと考えていたのにエンジニ アとしてそれを実現する引き出しはほぼ空だった
• いろんな視座で関わることで学ぶことは多い
目の前のことをコツコツやっていく • シンプルなことのはずだけどできてない ◦ 遠くの理想像をずっと見ていると気づいたら何も進んでい ないことは結構ある ◦ 遠くをみることも必要だけどバランス大事 • 何事も1歩ずつなのはそうだけど
◦ 特に少しのことが確実な積み上げになりやすいと思う ◦ 積み上げるほど加速するしそれが普通になってくる
ご清聴ありがとうございました!