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.5k
効果的なスプリントプランニングのトライ
tkredman
0
100
アジャイルに向かう組織に聴いてほしいアジャイルへの第一歩
tkredman
0
43
スクラム開発と向き合うことでスクラムを習得する
tkredman
0
98
たった一つの質問でマインドセットの灯をともせ!
tkredman
0
23
Other Decks in Technology
See All in Technology
ファインディにおける Dataform ブランチ戦略
hiracky16
0
220
メモ整理が苦手な者による頑張らないObsidian活用術
optim
0
150
Ktor + Google Cloud Tasks/PubSub におけるOTel Messaging計装の実践
sansantech
PRO
1
340
robocopy の怖い話/scary-story-about-robocopy
emiki
0
410
【CEDEC2025】現場を理解して実現!ゲーム開発を効率化するWebサービスの開発と、利用促進のための継続的な改善
cygames
PRO
0
430
経験がないことを言い訳にしない、 AI時代の他領域への染み出し方
parayama0625
0
270
【Λ(らむだ)】最近のアプデ情報 / RPALT20250729
lambda
0
130
Power Automate のパフォーマンス改善レシピ / Power Automate Performance Improvement Recipes
karamem0
0
280
AI駆動開発 with MixLeap Study【大阪支部 #3】
lycorptech_jp
PRO
0
280
MCPに潜むセキュリティリスクを考えてみる
milix_m
1
890
Railsの限界を超えろ!「家族アルバム みてね」の画像・動画の大規模アップロードを支えるアーキテクチャの変遷
ojima_h
4
530
AI によるドキュメント処理を加速するためのOCR 結果の永続化と再利用戦略
tomoaki25
0
170
Featured
See All Featured
Building an army of robots
kneath
306
45k
Build The Right Thing And Hit Your Dates
maggiecrowley
37
2.8k
Being A Developer After 40
akosma
90
590k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
29
9.6k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
A Tale of Four Properties
chriscoyier
160
23k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
5.9k
Designing for Performance
lara
610
69k
The Straight Up "How To Draw Better" Workshop
denniskardys
235
140k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.4k
Side Projects
sachag
455
43k
A Modern Web Designer's Workflow
chriscoyier
695
190k
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歩ずつなのはそうだけど
◦ 特に少しのことが確実な積み上げになりやすいと思う ◦ 積み上げるほど加速するしそれが普通になってくる
ご清聴ありがとうございました!