Share
Embed
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で行う