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.1k
アジャイルであり続けるために技術スキルと向き合う
Scrum fest sendai 2022
TK
August 27, 2022
Tweet
Share
More Decks by TK
See All by TK
私のチームが実践しているスプリントに集中するための取り組み
tkredman
0
1.8k
覗いてみよう!現場のスクラムチーム
tkredman
0
2.4k
「守破離の守!」スクラムガイドをみんなで読んでみた。
tkredman
0
1.3k
効果的なスプリントプランニングのトライ
tkredman
0
66
アジャイルに向かう組織に聴いてほしいアジャイルへの第一歩
tkredman
0
34
スクラム開発と向き合うことでスクラムを習得する
tkredman
0
78
たった一つの質問でマインドセットの灯をともせ!
tkredman
0
13
Other Decks in Technology
See All in Technology
TypeScript Quiz (Encraft #12 Frontend Quiz Night)
uhyo
6
660
Cloud Friendly(?) Jenkins. How we failed to make Jenkins cloud native and what we learned?
onenashev
PRO
0
110
#51 “Empowering Azure Storage with RDMA”
cafenero_777
3
210
ビジネスロジックを「型」で表現するOOPのための関数型DDD / Functional And Type-Safe DDD for OOP
yuitosato
29
12k
Autopsy of a Cascading Outage from a MySQL Crashing Bug
jfg956
0
200
Introducing Pkl
enomotok
0
100
単回帰分析について数式を追いながら実装してみた
kentaitakura
0
500
Kubeflow Pipelines v2 で変わる機械学習パイプライン開発
asei
4
340
エンジニア候補者向け資料2024.03.28.pdf
macloud
0
2.9k
Autify Company Deck
autifyhq
1
30k
技術広報経験0のEMがエンジニアブランディングをはじめてみた
coconala_engineer
1
140
8週連続ウェビナー_イチから学ぶFivetran
cmsuzu
0
170
Featured
See All Featured
We Have a Design System, Now What?
morganepeng
42
6.7k
The Language of Interfaces
destraynor
150
23k
The Cult of Friendly URLs
andyhume
73
5.6k
Practical Orchestrator
shlominoach
180
9.7k
Building Better People: How to give real-time feedback that sticks.
wjessup
350
18k
Code Review Best Practice
trishagee
54
15k
GitHub's CSS Performance
jonrohan
1023
450k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
14
1.3k
The Illustrated Children's Guide to Kubernetes
chrisshort
28
46k
Agile that works and the tools we love
rasmusluckow
323
20k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
225
51k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
34
8.8k
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歩ずつなのはそうだけど
◦ 特に少しのことが確実な積み上げになりやすいと思う ◦ 積み上げるほど加速するしそれが普通になってくる
ご清聴ありがとうございました!