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

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

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月から参加 • １つのコードで複数環境を動かしている ◦ 社内版・社外版みたいな
10. メンバー紹介 私 スクラムおじさん アジャイル好き お兄さん
11. 根性アジャイル 2016/07 - 2017/05
12. 2016/07-2016/10 • スマホサイトリリース • これまでエンジニア１人担当チームだった ◦ お客さんと調整しながら、いい感じに開発を進めていた ◦ エンジニアの根性次第でめっちゃ効率よく開発できる • 新人の私、アサイン！（実は次の担当者として育成）
13. 2016/07-2016/10 • スマホサイト作ったエンジニア別プロジェクトへ • 私がメインの担当者として追加開発・保守をやる ◦ 頼まれたらやりますって言っちゃう（新人なので） ◦ 夜遅くなることもしばしば • スクラムおじさんが英語サイトを作る • 単体テストが無いね • 引継用の仕様書はちょっとあるね
14. スクラムの時代 2017/05 - 2018/10
15. 2016/07-2016/10 • 英語サイトリリース • スクラムおじさん「しっかりスクラムやりましょう！」 ◦ 毎週の進捗をポイントで測れるんですって？ ◦ 持続可能な開発の見通しが立てられるんですって？
16. バックログとストーリーポイントの導入 • すべてのタスクに優先度とコストを付ける ◦ 優先度は営業さんがつけた ◦ コストは技術の私がつけた ◦ スクラムマスターは私がやる • 結構面倒くさかったがベロシティを計測する事ができた
17. ２週間スプリントの導入 • メリハリが利いて良い ◦ 初期開発と違って明確な終わりが無いので、区切りは大切 • リリースサイクルとのギャップがあった ◦ ２週間固定ではなかった ◦ リリース作業分のポイントを確保
18. 2016/07-2016/10 • スクラムおじさんチーム移動！ ◦ 回り始めはサポートするけど • 新卒１年目の営業・エンジニア追加 ◦ リリースするコードは私がレビューする
19. 2016/07-2016/10 • 同期のエンジニア追加（当時２年目） ◦ 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で行う