Scrum fest sendai 2022
アジャイルであり続けるために技術スキルと向き合う Retty株式会社 今井貴明 Scrum Fest Sendai 2022 2022/08/27
View Slide
自己紹介 ● TK (Imai Takaaki) ● エンジニア ○ 2015〜SIer ○ 2021〜Retty株式会社 ● @t_k_redman
今日のお話
アジャイルな開発に”エンジニアとして”どう貢献する？ この姿勢は首が凝る
● 関わり方も様々だし役割もいろいろある ● 今回はあくまでもエンジニアとしてという話 ものづくりへの関わり方はたくさんある
“アジャイル推進担当”だったころ
● 「うちもアジャイルを”やろう！”」という施策がきっかけ ● 知っていくうちに本質を突き詰めていくような考え方に深く共感した ● 自分たちもそんな風にものづくりをしたいと思った なぜアジャイルを探求し始めたのか
● アジャイルを社内に推進する人（途中から野良化） ○ プロジェクトヒアリング&支援 ○ ドキュメントの社内展開 ○ セミナーや勉強会開催 ● 小さめの開発を拾ってはスクラムを試したり ○ 事例化したりしなかったり 前職の私のお仕事
● 組織にアジャイルを広めるのは一筋縄ではいかない ● でも、みんながアジャイルを深く知りさえすれば、アジャイルなものづくりをする理想の環境が実現できるはず！ 必要なのはアジャイルの理解？
● この世界を実践しているところを見てみたい！ ● どれほどこの考え方が浸透しているのだろう 転職するときに考えていたこと We are one!
RettyにJoinしてから
● みんなアジャイルやスクラムのことを考えていると思っていた ● 実際そんなことはなくてあくまでも「自分たちの開発の進め方はこう」として捉えられていた ● そんな環境にエンジニアとして入った自分は何をしていけるだろう？ Rettyに入って
● それまでと同じように立ち振るまった ● 自分の知っていること、分かっていることを活かす動き 自分のできることをやっていった それ改善した方が…チームの課題を見つけてあるべき姿を意見する他部門との壁を感じたので直接会話しに行って現状を把握する本来こうあるべきでは
● 最初のピアレビューで上がってきた評価はイマイチ ● 自分の中ではそんなに悪くない動きだと思っていた ○ 実際それ自体が悪かったとは今でも思ってはないけど 予想外のフィードバック 行動の意図がよくわからないことがあるごもっともな指摘をしてはいるけど実際どうしていけば？
● 最初のピアレビューで上がってきた評価はイマイチ ● 自分の中ではそんなに悪くない動きだと思っていた ○ 実際それ自体が悪かったとは今でも思ってはないけど 予想外のフィードバック 行動の意図がよくわからないことがあるごもっともな指摘をしてはいるけど実際どうしていけば？どうしてこうなった？
● チームから評価されてるのは「手を動かしている人」 ○ アジャイルについて考えているか否かは関係なくそういう動きになっている 周りを見渡してみた このプルリクでコスト 20%削減できます！ここのソースコードお掃除しました！この部分はテストを足しておこう
● チームから評価されてるのは「手を動かしている人」 ○ アジャイルについて考えているか否かは関係なくそういう動きになっている 周りを見渡してみた このプルリクでコスト 20%削減できます！ここのソースコードお掃除しました！この部分はテストを足しておこう自分の経験の中にはない事ばかりでそれをマネするには知らないことが多すぎた
● 組織やチームから期待されているのは、エンジニアとしての責任を果たすことなのではないか ● 自分のやっていることはその期待値を満たすものだったのか？ 自分は”エンジニアとして”期待されている
エンジニアとしてできることをしている人たちがいる ● エンジニアとしてアジャイルな開発に貢献するってどうやるんだっけ？
● 自分が知ってきた中で思い浮かぶことというと・・・ ○ 質の良いソースコードを書こう ○ テストコードは書くべき ○ 継続して運用していける仕組みを作ろう ● 「こういうことが必要なんだ」とは前から学んできたけど、もっと言うとどういうこと？ “エンジニアとして”と言ったらこんなこと？
質の良いソースコードを書こう ● 例えば・・・ 可読性が高ければ変更箇所の当たりがつけやすい変更による影響範囲がわかりやすくなり想定外のバグが減るクラスに適切な責務を持たせてロジックをまとめる設計意図がわかりやすい命名やインターフェースを定義しておくことで品質が保たれやすくなる変数名、関数名、引数、関数の粒度、etc余計な調査やバグ修正が減って自分たちの開発速度が上がっていく！
テストコードは書くべき ● 例えば・・・ 複雑な要件が満たされているかを常にチェックできるようにする仕様が満たされていることを担保できるだけのテストケースを網羅しておく変更の度に手動で全パターンをテストするようなことはしたくない意図がわかりやすいテストケースを作っておくことでそのロジックに期待されている仕様が読み取れる変更に強い状態を維持する 変更を加えやすくなり品質と開発速度が上がる！
継続して運用していける仕組みを作ろう ● 例えば・・・ プロダクトの状態を知るためのメトリクスをどう取得してどのように使っていくか異常検知、アラート、障害時対応の仕組みや体制 プロダクトや自分たちの開発の改善点が見つかる！レスポンス速度、コスト自分たちのサービスがどのように使われているかが測定されて分析できる状態になっているテスト用環境を容易に準備できる仕組みや日々のリリースフロー整備
● それらが大事であることをずっと見聞きはしていた ○ 近くで見たことで、エンジニアにしかできない貢献として解像度をあげることができた ● こういうことを日々考えていくのがエンジニアとしての一つの貢献 自分が信じていたものの解像度が上がった
おわりに
役割によってどう貢献するかは変わる ● 思想や開発方法論の探求はそれはそれで良いと思う ○ 個人的にはそっちが楽しいみたいなところがある ● どの役割で関わるかによって必要なスキルは変わる ○ 価値を届ける開発についてずっと考えていたのにエンジニアとしてそれを実現する引き出しはほぼ空だった ● いろんな視座で関わることで学ぶことは多い
目の前のことをコツコツやっていく ● シンプルなことのはずだけどできてない ○ 遠くの理想像をずっと見ていると気づいたら何も進んでいないことは結構ある ○ 遠くをみることも必要だけどバランス大事 ● 何事も１歩ずつなのはそうだけど ○ 特に少しのことが確実な積み上げになりやすいと思う ○ 積み上げるほど加速するしそれが普通になってくる
ご清聴ありがとうございました！
tkredman
daihiraoka
hiroshinakagawa
iwamot
yoshikieguchi
cyberagentdevelopers
oracle4engineer
tbshiki
doradora09
microcms
mmclsntr
hankehly
gotok365
aleyda
searls
matthewcrist
pauljervisheath
zakiwarfel
sugarenia
thoeni
danielanewman
bcantrill
kevinliebholz
tammielis
myddelton