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.3k
アジャイルであり続けるために技術スキルと向き合う
Scrum fest sendai 2022
TK
August 27, 2022
Tweet
Share
More Decks by TK
See All by TK
私のチームが実践しているスプリントに集中するための取り組み
tkredman
0
1.9k
覗いてみよう!現場のスクラムチーム
tkredman
0
2.8k
「守破離の守!」スクラムガイドをみんなで読んでみた。
tkredman
0
1.5k
効果的なスプリントプランニングのトライ
tkredman
0
93
アジャイルに向かう組織に聴いてほしいアジャイルへの第一歩
tkredman
0
43
スクラム開発と向き合うことでスクラムを習得する
tkredman
0
89
たった一つの質問でマインドセットの灯をともせ!
tkredman
0
18
Other Decks in Technology
See All in Technology
Introduction to OpenSearch Project - Search Engineering Tech Talk 2025 Winter
tkykenmt
2
140
LINE NEWSにおけるバックエンド開発
lycorptech_jp
PRO
0
320
アジャイルな開発チームでテスト戦略の話は誰がする? / Who Talks About Test Strategy?
ak1210
1
660
Global Databaseで実現するマルチリージョン自動切替とBlue/Greenデプロイ
j2yano
0
130
Autonomous Database Serverless 技術詳細 / adb-s_technical_detail_jp
oracle4engineer
PRO
17
45k
大規模アジャイルフレームワークから学ぶエンジニアマネジメントの本質
staka121
PRO
3
1.3k
エンジニア主導の企画立案を可能にする組織とは?
recruitengineers
PRO
1
270
IoTシステム開発の複雑さを低減するための統合的アーキテクチャ
kentaro
1
120
プルリクエストレビューを終わらせるためのチーム体制 / The Team for Completing Pull Request Reviews
nekonenene
1
170
Oracle Database Technology Night #87-1 : Exadata Database Service on Exascale Infrastructure(ExaDB-XS)サービス詳細
oracle4engineer
PRO
1
200
AWSを活用したIoTにおけるセキュリティ対策のご紹介
kwskyk
0
420
困難を「一般解」で解く
fujiwara3
7
1.5k
Featured
See All Featured
The Art of Programming - Codeland 2020
erikaheidi
53
13k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
59k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
21
2.5k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
4
430
How to train your dragon (web standard)
notwaldorf
91
5.9k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
10
520
We Have a Design System, Now What?
morganepeng
51
7.4k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.3k
Making Projects Easy
brettharned
116
6k
Scaling GitHub
holman
459
140k
Designing for Performance
lara
605
68k
Music & Morning Musume
bryan
46
6.4k
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歩ずつなのはそうだけど
◦ 特に少しのことが確実な積み上げになりやすいと思う ◦ 積み上げるほど加速するしそれが普通になってくる
ご清聴ありがとうございました!