アジャイルであり続けるために技術スキルと向き合う

Scrum fest sendai 2022

Transcript

1. アジャイルであり続けるために技術スキルと向 き合う
 Retty株式会社
 今井貴明
 Scrum Fest Sendai 2022 
 2022/08/27 

2. 自己紹介
 • TK (Imai Takaaki)
 • エンジニア
 ◦ 2015〜SIer
 ◦ 2021〜Retty株式会社
 • @t_k_redman

3. 今日のお話

4. アジャイルな開発に”エンジニアとして”どう貢献する？
 この姿勢は 首が凝る
5. • 関わり方も様々だし役割もいろいろある
 • 今回はあくまでもエンジニアとしてという話
 ものづくりへの関わり方はたくさんある

6. “アジャイル推進担当”だったころ

7. • 「うちもアジャイルを”やろう！”」という施策がきっかけ
 • 知っていくうちに本質を突き詰めていくような考え方に深く共感 した
 • 自分たちもそんな風にものづくりをしたいと思った
 なぜアジャイルを探求し始めたのか

8. • アジャイルを社内に推進する人（途中から野良化）
 ◦ プロジェクトヒアリング&支援
 ◦ ドキュメントの社内展開
 ◦ セミナーや勉強会開催
 • 小さめの開発を拾ってはスクラムを試したり
 ◦ 事例化したりしなかったり
 前職の私のお仕事

9. • 組織にアジャイルを広めるのは一筋縄ではいかない
 • でも、みんながアジャイルを深く知りさえすれば、アジャイルな ものづくりをする理想の環境が実現できるはず！
 必要なのはアジャイルの理解？

10. • この世界を実践しているところを見てみたい！
 • どれほどこの考え方が浸透しているのだろう
 転職するときに考えていたこと
 We are one!
11. RettyにJoinしてから

12. • みんなアジャイルやスクラムのことを考えていると思っていた
 • 実際そんなことはなくてあくまでも「自分たちの開発の進め方 はこう」として捉えられていた
 • そんな環境にエンジニアとして入った自分は何をしていけるだ ろう？
 Rettyに入って

13. • それまでと同じように立ち振るまった
 • 自分の知っていること、分かっていることを活かす動き
 自分のできることをやっていった
 それ改善 した方が… チームの課題を見つけて あるべき姿を意見する 他部門との壁を感じたので 直接会話しに行って現状を把握する 本来こうある べきでは
14. • 最初のピアレビューで上がってきた評価はイマイチ
 • 自分の中ではそんなに悪くない動きだと思っていた
 ◦ 実際それ自体が悪かったとは今でも思ってはないけど
 予想外のフィードバック
 行動の意図がよくわからないこと がある ごもっともな指摘をしてはいるけど 実際どうしていけば？
15. • 最初のピアレビューで上がってきた評価はイマイチ
 • 自分の中ではそんなに悪くない動きだと思っていた
 ◦ 実際それ自体が悪かったとは今でも思ってはないけど
 予想外のフィードバック
 行動の意図がよくわからないこと がある ごもっともな指摘をしてはいるけど 実際どうしていけば？ どうしてこうなった？
16. • チームから評価されてるのは「手を動かしている人」
 ◦ アジャイルについて考えているか否かは関係なくそういう 動きになっている
 周りを見渡してみた
 このプルリクでコスト 20% 削減できます！ ここのソースコード お掃除しました！ この部分はテストを 足しておこう
17. • チームから評価されてるのは「手を動かしている人」
 ◦ アジャイルについて考えているか否かは関係なくそういう 動きになっている
 周りを見渡してみた
 このプルリクでコスト 20% 削減できます！ ここのソースコード お掃除しました！ この部分はテストを 足しておこう 自分の経験の中にはない事ばかりで それをマネするには知らないことが多すぎた
18. • 組織やチームから期待されているのは、エンジニアとしての責 任を果たすことなのではないか
 • 自分のやっていることはその期待値を満たすものだったの か？
 自分は”エンジニアとして”期待されている

19. エンジニアとしてできることをしている人たちがいる
 • エンジニアとしてアジャイルな開発に貢献するってどうやるん だっけ？

20. • 自分が知ってきた中で思い浮かぶことというと・・・
 ◦ 質の良いソースコードを書こう
 ◦ テストコードは書くべき
 ◦ 継続して運用していける仕組みを作ろう
 • 「こういうことが必要なんだ」とは前から学んできたけど、もっと 言うとどういうこと？
 “エンジニアとして”と言ったらこんなこと？

21. 質の良いソースコードを書こう
 • 例えば・・・
 可読性が高ければ変更箇所 の当たりがつけやすい 変更による影響範囲がわかりやすくな り想定外のバグが減る クラスに適切な責務を持たせて ロジックをまとめる 設計意図がわかりやすい命名やインター フェースを定義しておくことで品質が保たれ やすくなる 変数名、関数名、引数、関 数の粒度、etc 余計な調査やバグ修正が減って自分 たちの開発速度が上がっていく！
22. テストコードは書くべき
 • 例えば・・・
 複雑な要件が満たされているかを常 にチェックできるようにする 仕様が満たされていることを担保で きるだけのテストケースを網羅して おく 変更の度に手動で全パターンをテス トするようなことはしたくない 意図がわかりやすいテストケースを 作っておくことでそのロジックに期待さ れている仕様が読み取れる 変更に強い状態を維持する 変更を加えやすくなり品質と開 発速度が上がる！
23. 継続して運用していける仕組みを作ろう
 • 例えば・・・
 プロダクトの状態を知るためのメトリクス をどう取得してどのように使っていくか 異常検知、アラート、障害時 対応の仕組みや体制 プロダクトや自分たちの開発の 改善点が見つかる！ レスポンス速度、コスト 自分たちのサービスがどのように使わ れているかが測定されて分析できる状 態になっている テスト用環境を容易に準備できる仕組み や日々のリリースフロー整備
24. • それらが大事であることをずっと見聞きはしていた
 ◦ 近くで見たことで、エンジニアにしかできない貢献として解 像度をあげることができた
 • こういうことを日々考えていくのがエンジニアとしての一つの貢 献
 自分が信じていたものの解像度が上がった

25. おわりに

26. 役割によってどう貢献するかは変わる
 • 思想や開発方法論の探求はそれはそれで良いと思う
 ◦ 個人的にはそっちが楽しいみたいなところがある
 • どの役割で関わるかによって必要なスキルは変わる
 ◦ 価値を届ける開発についてずっと考えていたのにエンジニ アとしてそれを実現する引き出しはほぼ空だった
 • いろんな視座で関わることで学ぶことは多い

27. 目の前のことをコツコツやっていく
 • シンプルなことのはずだけどできてない
 ◦ 遠くの理想像をずっと見ていると気づいたら何も進んでい ないことは結構ある
 ◦ 遠くをみることも必要だけどバランス大事
 • 何事も１歩ずつなのはそうだけど
 ◦ 特に少しのことが確実な積み上げになりやすいと思う
 ◦ 積み上げるほど加速するしそれが普通になってくる

28. ご清聴ありがとうございました！