アジャイルな受託開発を3年間やってみて

 アジャイルな受託開発を3年間やってみて

私のチームで実践しているスクラム開発の方法と、サービス・チームの状況に合わせて、どのように仕組みを調整してきたかをご紹介します。
2019/07/06のBattle Conference Under30での発表資料です。

F0493f5bcb4cc9fdccc54ae3e8ab6bd0?s=128

Kentaro Matsumoto

July 06, 2019
Tweet

Transcript

  1. アジャイルな受託開発を 3年間やってみて 松本健太郎 @matsu7874

  2. 私のチームでやっている スクラムっぽいアジャイルの話をします

  3. 松本健太郎(26) @matsu7874 • フォルシア株式会社 • 新卒4年目 • エンジニア • Rust,

    SQL, JS, Python, etc
  4. フォルシア株式会社 • 「見つからなければ、始まらない。」 ◦ 「見つからない」に起因する様々な課題を、フォルシアは解決します。 ◦ 検索を中心に意思決定をサポートする • Webアプリの受託開発 ◦

    新規開発もやるし ◦ 追加提案・追加開発もやるし ◦ 保守運用もやります ◦ 顧客サービスを一緒に育てていく楽しさ • 旅行・EC/MRO・福利厚生業界 • 最近はダイナミックプライシング・データクレンジングも
  5. アジャイル開発ってなに?

  6. アジャイルソフトウェア開発宣言 • プロセス・ツール • 包括的なドキュメント • 契約交渉 • 計画に従うこと •

    個人と対話 • 動くソフトウェア • 顧客との協調 • 変化への対応 <
  7. アジャイル宣言の背後にある原則 = 目的 1. 顧客満足を最優先し、 価値のあるソフトウェアを早く継続的に 提供します。 2. 要求の変更はたとえ開発の後期であっても歓迎します。 変化

    を味方につけることによって、お客様の競争力を引き上げま す。 ⇒受託開発をするにあたって、我々が実現したいこと
  8. で、実際どうなの?

  9. プロジェクト説明 • ECサイトの追加開発・保守・運用 ◦ 営業1~2人 + エンジニア2~3人体制 ◦ 営業は提案・契約・PjMまで ◦

    エンジニアは提案・実装・運用 • 2015年リリース後、サイトを段階的に拡大 • 私は2016年7月から参加 • 1つのコードで複数環境を動かしている ◦ 社内版・社外版みたいな
  10. メンバー紹介 私 スクラムおじさん アジャイル好き お兄さん

  11. 根性アジャイル 2016/07 - 2017/05

  12. 2016/07-2016/10 • スマホサイトリリース • これまでエンジニア1人担当チームだった ◦ お客さんと調整しながら、いい感じに開発を進めていた ◦ エンジニアの根性次第でめっちゃ効率よく開発できる •

    新人の私、アサイン!(実は次の担当者として育成)
  13. 2016/07-2016/10 • スマホサイト作ったエンジニア別プロジェクトへ • 私がメインの担当者として追加開発・保守をやる ◦ 頼まれたらやりますって言っちゃう(新人なので) ◦ 夜遅くなることもしばしば •

    スクラムおじさんが英語サイトを作る • 単体テストが無いね • 引継用の仕様書はちょっとあるね
  14. スクラムの時代 2017/05 - 2018/10

  15. 2016/07-2016/10 • 英語サイトリリース • スクラムおじさん「しっかりスクラムやりましょう!」 ◦ 毎週の進捗をポイントで測れるんですって? ◦ 持続可能な開発の見通しが立てられるんですって?

  16. バックログとストーリーポイントの導入 • すべてのタスクに優先度とコストを付ける ◦ 優先度は営業さんがつけた ◦ コストは技術の私がつけた ◦ スクラムマスターは私がやる •

    結構面倒くさかったがベロシティを計測する事ができた
  17. 2週間スプリントの導入 • メリハリが利いて良い ◦ 初期開発と違って明確な終わりが無いので、区切りは大切 • リリースサイクルとのギャップがあった ◦ 2週間固定ではなかった ◦

    リリース作業分のポイントを確保
  18. 2016/07-2016/10 • スクラムおじさんチーム移動! ◦ 回り始めはサポートするけど • 新卒1年目の営業・エンジニア追加 ◦ リリースするコードは私がレビューする

  19. 2016/07-2016/10 • 同期のエンジニア追加(当時2年目) ◦ 2年目(専任), 1年目(専任), 2年目(サポート)のエンジニアチーム • ストーリーポイントやめた ◦

    大変な割にベロシティが分かる恩恵が少ない(チケット数とかで近似可能) • デイリースクラム(夕会)の実施 ◦ 情報共有と気軽に質問するためにあったほうがよい • 全てのMRを相互レビュー ◦ 各機能のリリース許可をもらってからコードレビューしていた
  20. 2016/07-2016/10 • 立て続けに退職が発生 • 属人化を減らせ ◦ いつでも引継げるようにドキュメント書く ◦ 環境構築しやすくする •

    リリース頻度を2週間に1回
  21. リリース頻度を2週間に1回に • 顧客と相談 --> 双方にメリット ◦ リリースには受け入れ体制が必要 ◦ リリース作業は大変なので予測可能にしたい

  22. 継続的に価値を届けるために 2018/10 -

  23. 2016/07-2016/10 • エンジニア(当時新卒2年目)がアサイン • メンバーに合わせた調整を行った

  24. 夕会はやめた • 困ったら即質問 ◦ 過去の経緯を調べるのは難しいので知ってる人に聞く ◦ 技術的な事も調べて分からないなら相談する • 進捗はSlackで共有 ◦

    大きめの作業について着手、完了は共有する ◦ commitとテスト結果はslackに流れる ◦ コンフリクトしないように開発時期や担当を決めれば十分 • 3,4年目で構成されているので場を強制しなくてもよい
  25. リリースのコストを下げる • UIテストの一部自動化 ◦ 環境が多いので影響範囲が広すぎる • 単体テストの追加 ◦ 自分が居なくなって困りそうなところは絶対書く ◦

    未来の担当者のために書く • コードの分離 ◦ 顧客の担当部署に合わせて分離した ◦ サイトが成熟期に入ったので、それぞれに最適化
  26. 結果: まあまあいい感じ

  27. 顧客満足のためのアジャイルな受託開発 • サイトとチームの段階に応じて開発スタイルを調整する • 未熟なエンジニアが無理・無茶できない仕組みを作る ◦ 相互レビュー ◦ デイリースクラム(夕会) •

    属人化防止とコストカットのために自動テストを書く • スクラムっぽいもの ◦ 2週間のスプリント ◦ デイリースクラムは自発的に非同期にslackで行う