「アジャイルな受託開発」を3年間やって得たもの

「アジャイルな受託開発」をやった結果

松本健太郎 氏：「アジャイルな受託開発を3年間やってみて」というタイトルで、松本健太郎が発表させていただきます。よろしくお願いいたします。

（会場拍手）

今日は私のチームでやっているスクラム開発っぽいアジャイルの話をします。先ほどのセッションでもアジャイルのお話だったので、この会場に来ていらっしゃる方はアジャイルの話が大好きな方なのかなと思っています。

私の自己紹介なんですが、フォルシア株式会社という会社で新卒4年目のエンジニアをしています。Webのエンジニアなんですが、最近はRustを書く業務もけっこう増えてきている感じです。あと競技プログラミングも趣味なので本戦も楽しみにしています。

フォルシアという会社の紹介をさせてください。フォルシアは検索を中心にWebアプリの受託開発を行っている会社です。新規の開発からそのあとの追加開発や追加の提案、保守運用まで同じ担当者が一気通貫でやることが多い会社です。

受託でありながら開発から運用まで担当できるので、顧客サービスを一緒に育てていくという楽しさがあります。あと最近は自社サービスとしてダイナミックプライシングやデータクレンジングなどにも取り組んでいます。

今日はアジャイルの話をするんですが、簡単にちょっと紹介をします。アジャイルソフトウェア宣言という2001年にまとめられたドキュメントだと、スライド左側のプロセスとか包括的なドキュメントに的確に従うことよりも、右側の個人との会話やソフトウェア、顧客との表情変化の対応というところに重きを置いています。もちろん左側のことも大事なんだけど右にも趣を置きましょうという宣言があって。

その背後にある原則として何が必要なのかというと、顧客満足を最優先し、価値あるソフトウェアを早く書けるように提供します。

例えば、要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによってお客様の競争力を引き上げます。これはまさに受託開発をするにあたって我々がやりたいことが書かれているという感じなんですね。

アジャイルは概念としては非常に良いと。実際にやってみてどうなのか？　という話をこのあとしていきます。

フォルシアのプロジェクト説明と経緯

みなさんにも具体的にイメージしてもらいやすいようにプロジェクトの説明をさせてください。

とあるECサイトの初期開発が終わって、その追加開発と保守と運用をやっていくというプロジェクトです。

時期によってメンバーは変動するんですが、営業が1か2人、エンジニアが2か3人という体制でやっています。営業は提案するだけじゃなくて契約から実際のプロジェクトまでを担当していて役割が広いです。エンジニアもお客様と直接話をして「こういう改修はどうですか？」とか言いながら実際に実装して運用までやっていくようなワークスタイルがあります。

サイト自体は2015年にリリースで、そのサイトを段階的に拡大していくような中で私は2016年の7月から参加しています。特徴としては1つのコードで複数サイトを動かしているため、けっこう複雑な作りになってしまっていたんですね。

誰がいつ働いていたのかのメンバー紹介を3年分します。この話の中で一番重要なのは、一番上の水色の私と黄色のスクラムおじさんと下に営業のアジャイル好きお兄さんがいて、そのあたりが重要になってきます。

このあと3つの時代があるんですが、まず1つ目の「根性アジャイル」について説明させていただきます。

2016年の7月からですね。これはちょうどスマホサイトがリリースした時期で、これまではエンジニアが1人のチームだったんですね。その1人のエンジニアがお客様と調整をしながら「どう書くか」「どういう順番で作っていくか」みたいなことを決めて実装していた。

これはエンジニア個人の根性次第でめちゃくちゃ効率良く開発ができます。つまり、開発の全体のことを知っているのでコンフリクトすることもないですし、ガンガン開発をしていけるというスピード重視の体制ですね。ここで新人の私がアサインされます。

次にスマホサイトを作っていたエンジニアが別のプロジェクトへ移動になって、私がメインの担当者に繰り上がると。そこからスピード開発をしていくんですが、新人なのでよくわからないなりに頼まれたら「やっちゃいます」って言っちゃうんですね。お客様に喜んでほしいという気持ちがあるので、頼まれたらやっちゃう。それで夜遅くなって疲れるときとかもあるんですね。

入れ替わりでもう1人、サポートのエンジニアとしてスクラムおじさんが入ってくるんですが、この人は大きめのプロジェクトもあるので行くという感じで、単体テストがない時や、引継ぎ用の仕様書はちょっとしかない感じの中で仕事が進んでいきます。

「スクラムの時代」がやってくる

それでスクラムの時代がやってきます。これは1年半ぐらい続きます。まずおじさんが英語サイトを作り終わって、運用もスクラムおじさんと一緒にやっていくとなったときに「ちょっとこれからはしっかりスクラムをやっていきましょう」と言ってきます。運用回していくルールが必要ですということですね。

「そうすると毎週の進捗が図れるんですって？」みたいな話があって、バックログとストーリーポイントを導入しました。

これはすべてのタスクに優先度とコストを付けるんですが、優先度は営業が付けて、コストは技術の私が付けて、スクラムマスターも私ががんばって「みんなで回していきましょう」みたいな話をしていました。けっこう面倒くさかったんですけどベロシティを計測できるようになりました。

もう1つ、2週間のスプリントを導入したんですね。これはメリハリが効くようになってすごいいいです。受託で継続的にサービスを動かしていく中にあって、「2週間で絶対にここまで作ろう！」というのはかなり良いですね。しかしリリースサイクルとギャップがあるので、リリースがある週・ない週だったりというのは、あまりマッチしていなかった感じです。

ここでスクラムおじさんのチーム移動。回り始めはサポートをしていただきながらやっていただいたんですが、その「スクラムをやっていくぞ！」という気持ちの原動力がきっぱりなくなってしまいました。一方で新卒の営業とエンジニアの追加です。

そのあと同期のエンジニアも追加して、これでエンジニアは2年目、1年目、2年目というエンジニアのチームでやっています。ここでストーリーポイントをやめました。なぜかと言うと、けっこうポイントを付けるのが大変なわりに、ベロシティがわかってもだいたいチケット数で近似できることがあって面倒くさいのでやめちゃいました。

あとはデイリースクラム。夕会をやって情報を共有したり、同じリクエストに関してはすべてレビューを通しています。夕会とかはいいですね。なぜかと言うと、わからないことがその日の夕方には絶対解決するので。強制的に聞けるタイミングを作るということですね。

このあと退職が続いてしまって、エンジニアもセールスも1人ずつ減ってしまいました。こうなると属人化を減らさないといけないなと思って、いろいろドキュメントを書いたり、構築しやすくなるものを作りました。

あとリリースの頻度を2週間に1回にしました。これはお客様にとっても必ず2週間に1回の木曜日にリリースをするテンポが決まると、受け入れのタイミング、いつに何をしないといけないねという現場のスケジュールがたてられるようになるんですね。

それはお客様にとっても私たちもそうで、けっこうよかったです。

継続的に価値を届ける時代へ

最後に「継続的に価値を届けるために」という時代がきて、エンジニアが代わりにもう1人入るんですね。そこにアジャストしました。

やっぱり夕会はやめました。なんでかというと「困ったらすぐに質問しましょう！」。進捗はSlackで共有をしていく。

なぜこういうことができるかというと、エンジニアは今まで1、2年目とかの若い人たちだったんですけど、徐々に2、3年目で経験を積んできて、ある程度自分で困っているなというのがわかるし、判断ができるように成長してきたことによって、強制的に何かやるというタイミングを外していくことができました。

最後にリリースのコストを下げる工夫をしました。単体テストを追加して、コードもお客様が管轄しているサービスごとに1つのコードベースになるように、切り分けてしまいました。これはサイトが成熟期に入ったので、開発スピードよりも安定性を重視したというかたちです。そうするといい感じになりました。

顧客満足のためのアジャイル開発をして、未熟なエンジニアが無茶できない仕組みを作ってあげると。それで開発スタイルをチームとかサイトの状況に合わせて調整していくこと。あと1つは、属人化はチームが継続的に動いていくためには防いでおくことが必要です。スクラムっぽいものをチームに合わせたかたちで導入しています。

以上で私の発表を終わります。質問のある方はあとで待っていますのでよろしくお願いします。ありがとうございました！

（会場拍手）