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

by TK

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

今日のお話 

Slide 4

Slide 4 text

アジャイルな開発に”エンジニアとして”どう貢献する？  この姿勢は首が凝る

Slide 5

Slide 5 text

● 関わり方も様々だし役割もいろいろある  ● 今回はあくまでもエンジニアとしてという話  ものづくりへの関わり方はたくさんある 

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

RettyにJoinしてから 

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

● それまでと同じように立ち振るまった  ● 自分の知っていること、分かっていることを活かす動き  自分のできることをやっていった  それ改善した方が… チームの課題を見つけてあるべき姿を意見する他部門との壁を感じたので直接会話しに行って現状を把握する本来こうあるべきでは

Slide 14

Slide 14 text

● 最初のピアレビューで上がってきた評価はイマイチ  ● 自分の中ではそんなに悪くない動きだと思っていた  ○ 実際それ自体が悪かったとは今でも思ってはないけど  予想外のフィードバック  行動の意図がよくわからないことがあるごもっともな指摘をしてはいるけど実際どうしていけば？

Slide 15

Slide 15 text

● 最初のピアレビューで上がってきた評価はイマイチ  ● 自分の中ではそんなに悪くない動きだと思っていた  ○ 実際それ自体が悪かったとは今でも思ってはないけど  予想外のフィードバック  行動の意図がよくわからないことがあるごもっともな指摘をしてはいるけど実際どうしていけば？どうしてこうなった？

Slide 16

Slide 16 text

● チームから評価されてるのは「手を動かしている人」  ○ アジャイルについて考えているか否かは関係なくそういう動きになっている  周りを見渡してみた  このプルリクでコスト 20% 削減できます！ここのソースコードお掃除しました！この部分はテストを足しておこう

Slide 17

Slide 17 text

● チームから評価されてるのは「手を動かしている人」  ○ アジャイルについて考えているか否かは関係なくそういう動きになっている  周りを見渡してみた  このプルリクでコスト 20% 削減できます！ここのソースコードお掃除しました！この部分はテストを足しておこう自分の経験の中にはない事ばかりでそれをマネするには知らないことが多すぎた

Slide 18

Slide 18 text

● 組織やチームから期待されているのは、エンジニアとしての責任を果たすことなのではないか  ● 自分のやっていることはその期待値を満たすものだったのか？  自分は”エンジニアとして”期待されている 

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

質の良いソースコードを書こう  ● 例えば・・・  可読性が高ければ変更箇所の当たりがつけやすい変更による影響範囲がわかりやすくなり想定外のバグが減るクラスに適切な責務を持たせてロジックをまとめる設計意図がわかりやすい命名やインターフェースを定義しておくことで品質が保たれやすくなる変数名、関数名、引数、関数の粒度、etc 余計な調査やバグ修正が減って自分たちの開発速度が上がっていく！

Slide 22

Slide 22 text

テストコードは書くべき  ● 例えば・・・  複雑な要件が満たされているかを常にチェックできるようにする仕様が満たされていることを担保できるだけのテストケースを網羅しておく変更の度に手動で全パターンをテストするようなことはしたくない意図がわかりやすいテストケースを作っておくことでそのロジックに期待されている仕様が読み取れる変更に強い状態を維持する変更を加えやすくなり品質と開発速度が上がる！

Slide 23

Slide 23 text

継続して運用していける仕組みを作ろう  ● 例えば・・・  プロダクトの状態を知るためのメトリクスをどう取得してどのように使っていくか異常検知、アラート、障害時対応の仕組みや体制プロダクトや自分たちの開発の改善点が見つかる！レスポンス速度、コスト自分たちのサービスがどのように使われているかが測定されて分析できる状態になっているテスト用環境を容易に準備できる仕組みや日々のリリースフロー整備

Slide 24

Slide 24 text

● それらが大事であることをずっと見聞きはしていた  ○ 近くで見たことで、エンジニアにしかできない貢献として解像度をあげることができた  ● こういうことを日々考えていくのがエンジニアとしての一つの貢献  自分が信じていたものの解像度が上がった 

Slide 25

Slide 25 text

おわりに 

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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