Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

TK
August 27, 2022

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

Scrum fest sendai 2022

TK

August 27, 2022
Tweet

More Decks by TK

Other Decks in Technology

Transcript

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

    Retty株式会社

    今井貴明

    Scrum Fest Sendai 2022 

    2022/08/27 


    View full-size slide

  2. 自己紹介

    ● TK (Imai Takaaki)

    ● エンジニア

    ○ 2015〜SIer

    ○ 2021〜Retty株式会社

    ● @t_k_redman


    View full-size slide

  3. 今日のお話


    View full-size slide

  4. アジャイルな開発に”エンジニアとして”どう貢献する?

    この姿勢は
    首が凝る

    View full-size slide

  5. ● 関わり方も様々だし役割もいろいろある

    ● 今回はあくまでもエンジニアとしてという話

    ものづくりへの関わり方はたくさんある


    View full-size slide

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


    View full-size slide

  7. ● 「うちもアジャイルを”やろう!”」という施策がきっかけ

    ● 知っていくうちに本質を突き詰めていくような考え方に深く共感
    した

    ● 自分たちもそんな風にものづくりをしたいと思った

    なぜアジャイルを探求し始めたのか


    View full-size slide

  8. ● アジャイルを社内に推進する人(途中から野良化)

    ○ プロジェクトヒアリング&支援

    ○ ドキュメントの社内展開

    ○ セミナーや勉強会開催

    ● 小さめの開発を拾ってはスクラムを試したり

    ○ 事例化したりしなかったり

    前職の私のお仕事


    View full-size slide

  9. ● 組織にアジャイルを広めるのは一筋縄ではいかない

    ● でも、みんながアジャイルを深く知りさえすれば、アジャイルな
    ものづくりをする理想の環境が実現できるはず!

    必要なのはアジャイルの理解?


    View full-size slide

  10. ● この世界を実践しているところを見てみたい!

    ● どれほどこの考え方が浸透しているのだろう

    転職するときに考えていたこと

    We are one!

    View full-size slide

  11. RettyにJoinしてから


    View full-size slide

  12. ● みんなアジャイルやスクラムのことを考えていると思っていた

    ● 実際そんなことはなくてあくまでも「自分たちの開発の進め方
    はこう」として捉えられていた

    ● そんな環境にエンジニアとして入った自分は何をしていけるだ
    ろう?

    Rettyに入って


    View full-size slide

  13. ● それまでと同じように立ち振るまった

    ● 自分の知っていること、分かっていることを活かす動き

    自分のできることをやっていった

    それ改善
    した方が…
    チームの課題を見つけて
    あるべき姿を意見する
    他部門との壁を感じたので
    直接会話しに行って現状を把握する
    本来こうある
    べきでは

    View full-size slide

  14. ● 最初のピアレビューで上がってきた評価はイマイチ

    ● 自分の中ではそんなに悪くない動きだと思っていた

    ○ 実際それ自体が悪かったとは今でも思ってはないけど

    予想外のフィードバック

    行動の意図がよくわからないこと
    がある
    ごもっともな指摘をしてはいるけど
    実際どうしていけば?

    View full-size slide

  15. ● 最初のピアレビューで上がってきた評価はイマイチ

    ● 自分の中ではそんなに悪くない動きだと思っていた

    ○ 実際それ自体が悪かったとは今でも思ってはないけど

    予想外のフィードバック

    行動の意図がよくわからないこと
    がある
    ごもっともな指摘をしてはいるけど
    実際どうしていけば?
    どうしてこうなった?

    View full-size slide

  16. ● チームから評価されてるのは「手を動かしている人」

    ○ アジャイルについて考えているか否かは関係なくそういう
    動きになっている

    周りを見渡してみた

    このプルリクでコスト 20%
    削減できます!
    ここのソースコード
    お掃除しました!
    この部分はテストを
    足しておこう

    View full-size slide

  17. ● チームから評価されてるのは「手を動かしている人」

    ○ アジャイルについて考えているか否かは関係なくそういう
    動きになっている

    周りを見渡してみた

    このプルリクでコスト 20%
    削減できます!
    ここのソースコード
    お掃除しました!
    この部分はテストを
    足しておこう
    自分の経験の中にはない事ばかりで
    それをマネするには知らないことが多すぎた

    View full-size slide

  18. ● 組織やチームから期待されているのは、エンジニアとしての責
    任を果たすことなのではないか

    ● 自分のやっていることはその期待値を満たすものだったの
    か?

    自分は”エンジニアとして”期待されている


    View full-size slide

  19. エンジニアとしてできることをしている人たちがいる

    ● エンジニアとしてアジャイルな開発に貢献するってどうやるん
    だっけ?


    View full-size slide

  20. ● 自分が知ってきた中で思い浮かぶことというと・・・

    ○ 質の良いソースコードを書こう

    ○ テストコードは書くべき

    ○ 継続して運用していける仕組みを作ろう

    ● 「こういうことが必要なんだ」とは前から学んできたけど、もっと
    言うとどういうこと?

    “エンジニアとして”と言ったらこんなこと?


    View full-size slide

  21. 質の良いソースコードを書こう

    ● 例えば・・・

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

    View full-size slide

  22. テストコードは書くべき

    ● 例えば・・・

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

    View full-size slide

  23. 継続して運用していける仕組みを作ろう

    ● 例えば・・・

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

    View full-size slide

  24. ● それらが大事であることをずっと見聞きはしていた

    ○ 近くで見たことで、エンジニアにしかできない貢献として解
    像度をあげることができた

    ● こういうことを日々考えていくのがエンジニアとしての一つの貢
    献

    自分が信じていたものの解像度が上がった


    View full-size slide

  25. おわりに


    View full-size slide

  26. 役割によってどう貢献するかは変わる

    ● 思想や開発方法論の探求はそれはそれで良いと思う

    ○ 個人的にはそっちが楽しいみたいなところがある

    ● どの役割で関わるかによって必要なスキルは変わる

    ○ 価値を届ける開発についてずっと考えていたのにエンジニ
    アとしてそれを実現する引き出しはほぼ空だった

    ● いろんな視座で関わることで学ぶことは多い


    View full-size slide

  27. 目の前のことをコツコツやっていく

    ● シンプルなことのはずだけどできてない

    ○ 遠くの理想像をずっと見ていると気づいたら何も進んでい
    ないことは結構ある

    ○ 遠くをみることも必要だけどバランス大事

    ● 何事も1歩ずつなのはそうだけど

    ○ 特に少しのことが確実な積み上げになりやすいと思う

    ○ 積み上げるほど加速するしそれが普通になってくる


    View full-size slide

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


    View full-size slide