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

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

松本健太郎(26) @matsu7874 ● フォルシア株式会社 ● 新卒4年目 ● エンジニア ● Rust, SQL, JS, Python, etc

Slide 4

Slide 4 text

フォルシア株式会社 ● 「見つからなければ、始まらない。」 ○ 「見つからない」に起因する様々な課題を、フォルシアは解決します。 ○ 検索を中心に意思決定をサポートする ● Webアプリの受託開発 ○ 新規開発もやるし ○ 追加提案・追加開発もやるし ○ 保守運用もやります ○ 顧客サービスを一緒に育てていく楽しさ ● 旅行・EC/MRO・福利厚生業界 ● 最近はダイナミックプライシング・データクレンジングも

Slide 5

Slide 5 text

アジャイル開発ってなに？

Slide 6

Slide 6 text

アジャイルソフトウェア開発宣言 ● プロセス・ツール ● 包括的なドキュメント ● 契約交渉 ● 計画に従うこと ● 個人と対話 ● 動くソフトウェア ● 顧客との協調 ● 変化への対応 <

Slide 7

Slide 7 text

アジャイル宣言の背後にある原則 = 目的 1. 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。 2. 要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。 ⇒受託開発をするにあたって、我々が実現したいこと

Slide 8

Slide 8 text

で、実際どうなの？

Slide 9

Slide 9 text

プロジェクト説明 ● ECサイトの追加開発・保守・運用 ○ 営業1~2人 + エンジニア2~3人体制 ○ 営業は提案・契約・PjMまで ○ エンジニアは提案・実装・運用 ● 2015年リリース後、サイトを段階的に拡大 ● 私は2016年7月から参加 ● １つのコードで複数環境を動かしている ○ 社内版・社外版みたいな

Slide 10

Slide 10 text

メンバー紹介私スクラムおじさんアジャイル好きお兄さん

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

2016/07-2016/10 ● スマホサイトリリース ● これまでエンジニア１人担当チームだった ○ お客さんと調整しながら、いい感じに開発を進めていた ○ エンジニアの根性次第でめっちゃ効率よく開発できる ● 新人の私、アサイン！（実は次の担当者として育成）

Slide 13

Slide 13 text

2016/07-2016/10 ● スマホサイト作ったエンジニア別プロジェクトへ ● 私がメインの担当者として追加開発・保守をやる ○ 頼まれたらやりますって言っちゃう（新人なので） ○ 夜遅くなることもしばしば ● スクラムおじさんが英語サイトを作る ● 単体テストが無いね ● 引継用の仕様書はちょっとあるね

Slide 14

Slide 14 text

スクラムの時代 2017/05 - 2018/10

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

バックログとストーリーポイントの導入 ● すべてのタスクに優先度とコストを付ける ○ 優先度は営業さんがつけた ○ コストは技術の私がつけた ○ スクラムマスターは私がやる ● 結構面倒くさかったがベロシティを計測する事ができた

Slide 17

Slide 17 text

２週間スプリントの導入 ● メリハリが利いて良い ○ 初期開発と違って明確な終わりが無いので、区切りは大切 ● リリースサイクルとのギャップがあった ○ ２週間固定ではなかった ○ リリース作業分のポイントを確保

Slide 18

Slide 18 text

2016/07-2016/10 ● スクラムおじさんチーム移動！ ○ 回り始めはサポートするけど ● 新卒１年目の営業・エンジニア追加 ○ リリースするコードは私がレビューする

Slide 19

Slide 19 text

2016/07-2016/10 ● 同期のエンジニア追加（当時２年目） ○ 2年目(専任), 1年目(専任), 2年目(サポート)のエンジニアチーム ● ストーリーポイントやめた ○ 大変な割にベロシティが分かる恩恵が少ない（チケット数とかで近似可能） ● デイリースクラム（夕会）の実施 ○ 情報共有と気軽に質問するためにあったほうがよい ● 全てのMRを相互レビュー ○ 各機能のリリース許可をもらってからコードレビューしていた

Slide 20

Slide 20 text

2016/07-2016/10 ● 立て続けに退職が発生 ● 属人化を減らせ ○ いつでも引継げるようにドキュメント書く ○ 環境構築しやすくする ● リリース頻度を2週間に1回

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

夕会はやめた ● 困ったら即質問 ○ 過去の経緯を調べるのは難しいので知ってる人に聞く ○ 技術的な事も調べて分からないなら相談する ● 進捗はSlackで共有 ○ 大きめの作業について着手、完了は共有する ○ commitとテスト結果はslackに流れる ○ コンフリクトしないように開発時期や担当を決めれば十分 ● 3,4年目で構成されているので場を強制しなくてもよい

Slide 25

Slide 25 text

リリースのコストを下げる ● UIテストの一部自動化 ○ 環境が多いので影響範囲が広すぎる ● 単体テストの追加 ○ 自分が居なくなって困りそうなところは絶対書く ○ 未来の担当者のために書く ● コードの分離 ○ 顧客の担当部署に合わせて分離した ○ サイトが成熟期に入ったので、それぞれに最適化

Slide 26

Slide 26 text

結果：まあまあいい感じ

Slide 27

Slide 27 text

顧客満足のためのアジャイルな受託開発 ● サイトとチームの段階に応じて開発スタイルを調整する ● 未熟なエンジニアが無理・無茶できない仕組みを作る ○ 相互レビュー ○ デイリースクラム（夕会） ● 属人化防止とコストカットのために自動テストを書く ● スクラムっぽいもの ○ 2週間のスプリント ○ デイリースクラムは自発的に非同期にslackで行う