• facebook
  • twitter
  • rss

開発にスクラムを導入した経緯と今後について

弊社エンジニアの石津(写真左)と小山(写真右)

永井(人事:モデレーター):今日はお二人に現在の開発体制になるまでの経緯について改めて聞いていこうと思います。

そもそも二人が入った時のうちって、どういう開発体制だったんでしたっけ?

石津:小山さんがちょうど1年くらい前に入社したんでしたよね?

小山:そうですね。当時は、DriveOn(コンシューマー向け)、DriveOps(法人向け)に社員エンジニアがそれぞれ1人ずつ立っていて、フリーランスのエンジニアにタスクを適時アサインしていくスタイルでした。

永井:たしかにそうでしたね。

小山:開発計画に関しても、Githubのインシューに、事業側から落ちてきたものをバンバン積んで行くという感じで、ちょっと溢れてしまってる感もありましたね。

石津:要望が爆発していた感じですかね?(笑)

小山:そうそう。

永井:開発も事業側からの要望によってどんどんつくるものも変わっていってしまうような状態だったってことですかね。

小山:理想形のようなものは、海外のプロダクトなども参考にしつつ、あったとは思うんですが、かなり手探りでやっている状態だったと思います。

二人の間に置かれているティッシュの箱。なぜこんなにも高く積む必要があるのか。これもスクラム?

永井:そうなると、各チケットをこなすにしても、何を優先してやらなければいけないかとかは、その時々の事業側における Urgency によって決めていたという感じですよね。

小山:ですね。そうやってつくりつつ、かつ当時すでに使ってくれているユーザーさんたちもいたので、そこで何か不具合などがあるとまずはそこを調査してトラブルシュートして、みたいな感じになっていたので、その辺はカオスっぽくなっているところはありました。

石津:そういう平行状態での開発だったわけですよね

小山:そもそもつくろうとしているものに対してのリソースも足りなそうでしたし。

永井:なるほど。小山さんが入った時そういう状況だったということで、その後ちょっとして石津さんが入ることになるわけですが、小山さんとしてはどのあたりから「スクラムやろうかな」とか考えていたんですか?

小山:入って1–2週間くらいで、これはちょっと大変そうだぞというのは気づきました。で、スクラムは前職で導入した経験があったので、だいたいこんな感じでやればいけるというのがわかっていたので、あとはどう導入するかなんですが、一旦まずは開発の進め方というよりはコードそのものをなんとかしようと思って、2ヶ月くらいはリファクタリングしてたんですよ。

永井:それはまず DriveOps(法人向け)の方の?

小山:ですね。で、リファクタリングしながら、このまま進めるとこの先のサービスとしてのスケーラビリティに不安があるからどうすればいいかなーとひとりで考えていて、ただ当時のリソースだけではやるにもやれないという状況でもあったので、その頃から前職で一緒に働いてよく知っていた石津さんのようなイメージのエンジニアが必要だとは感じていました。そう思っていたら、たまたま石津さん的な人というよりは本人を獲得できたので(笑)、じゃあやろうかとなりました。

永井:ひとりではさすがに厳しいけども、石津さんが来たんだからこれはなんとかなるだろうという予感があったんですかね。

小山:そうですね。ただ、とはいえ2人だけでやるのも結構きついんですけどね(笑)

石津:笑

小山:それで、石津さんがジョインしてからは「じゃあいつもの進め方でやりましょうか」という話になり、アジャイル的な動きを始めたわけですが、とはいえ今までやってきたことをすべていきなり変えるというわけでにもいかないので、一旦12月からまずは2人で始めましょうってやってみました。

石津:そんな感じでしたね。

小山:スプリント1は石津さんと僕だけですね、たしか。で、スプリント2から八木田さんが登場したんですね。

超新星のごとく入社した八木田(写真左)必殺コーディネートのグレー・オン・グレー。

石津:そうでしたね、突然の登場でしたよね。1週間くらいで入社が決まったりとかで。超新星がきた感じでしたよね。

小山:あれがなかったら(八木田さんが登場してなかったら)、まだ今のプラットフォームはできてなかったですからね。

永井:八木田さんもとてもいいタイミングで入ってくれましたよね!

小山:ホントそうですね。当時、経営陣から事業計画や将来の展望など聞いていくなかで、じゃあこういう展開になればこういうものが必要だよなとか、DriveOps単体でサービスを提供して行くというよりは、プラットフォーム上で提供する1サービスという扱いになっていくよなあと考えていくと、そのままだとちょっと使い勝手が悪くなりそうだぞ、と。あとは、エンジニアがもっと増えていくときに、分業しにくいつくりでもあったんですね。

永井:なるほどなるほど。

石津:ふふふ、そうでしたね。

小山:なので、一旦立て直しが必要だったのと、あとは車に限定しないプラットフォームとしてつくった方がいいよね、というのもあったので、絶対に必要な土台としてのプラットフォームをつくろうと。

ホワイトボードも緑色で書くと目に優しい。そこまで気を遣う律儀な石津

石津:そうですね。「組織」という概念をつくりはじめたときも、ドメインの組み立てをしていて、走行とかデバイスとかをってそもそも誰の持ちものなんだっけ、とか考えまして。じゃあ「組織」の下におきましょうと。そういう再編成の話をしていく中で、今の「組織」というものが出てきましたよね。

小山:そこは2人で、プラットフォームのデータ構造どうしようという話をしながら、ユースケースなんかも考えていきつつ、いろんなパターンを考えて、「あ、それはちょっとカバーできてないや」みたいなことがないように、現実における使われた方をすべて洗い出していって考えてましたね。

石津:最初は、いきなり実装というよりは、そういう概念的なところを整理しましょうというのが多かったですね。あとは、当日動いていたものをどうコンバートするかとかもしつつ、当時新しいデバイスの開発も走り始めていたので、APIでデータが上がる・下がるというモックAPIをつくるところから実装が始まっていった感じですかね。

小山:だから、プロジェクトの進め方としていきなりスクラムが始まったというよりは、今のシステムを一旦見直しましょう、課題もあるねっていうところから、じゃあそれをどうしようかという大まかな見通しができて、それがいわゆるスプリント0みたいな時期で、コードを変更したりしつつその後の準備をしてました。負荷試験もしてみて、こりゃちょっとサーバコスト的にもシビアだぞということもあって。

カリスマ塾講師も黙らせるような熱弁を展開する石津。文字通り黙ってしまった小金澤(写真右)

永井:じゃあ本格的にスプリントが動き出したのは、年明け(2017年)くらいからとかですかね?

小山:12月後半くらいですかね。

石津:そうですね。

永井:そうなると、最初2人でやり始めたところに間もなく八木田さんが加わって、しばらく3人でという期間もあったのだと思いますが、そこから開発全体を巻き込んでいくに至った過程ってどんな感じだったんでしたっけ?

石津:そうですね、最初3人で進めていく中で、他のチームとの情報共有があまりうまくできてないねってことが課題になりました。で、それを解消していくために、まずは一緒にしやすいウェブ側でやろうということで、フロントエンドチームの開発を吸収してやりはじめて、その後スマホアプリのチームも人が増え始めてアプリを書き直すという話も出てきて、APIとかプラットフォームの方を叩くんだったらその話もしなくちゃね、という流れですね。最初の頃は別々で平行してやっていたものを、ある時点でひとつにまとめちゃいましょうと。

小山:たしか最初に3人で始める段階で、一応「あとでみんな一緒にやろうね」という宣言だけはしておいた感じですね。アプリも2月頃?から合流しますみたいな話はありました。

永井:なるほど、そういう経緯で他のチームがスクラムに取り込まれていった感じなんですね。それを経て、今ではポイント(?)でしたっけ、を振り当ててそれで工数管理して、みたいな仕組みになって。

石津:それでいうと、まだ今の段階でもストーリーポイントが精度高く割り当てられて開発のスピードが出ている、というところまではいってなくて、どちらかといえば、みんな横串でちゃんと情報共有がされている、というところに重点が置かれている状態ですね。

「シンガポールとジャカルタってこんな近い」と嬉しそうな小山

小山:そうですね。ストーリーポイントで工数を見積もるということより、開発を進めることや、進捗をしっかり管理する、ということにフォーカスしている状況ですね。

石津:もちろん、そこにちゃんとポイントも振れれば、最初にスプリントに入れる際もそもそもこれは入れれないよねとか、そういう話もできるようになりますね。ただ、それをちゃんとやるためには、各ストーリーでのアウトプットも明確にあって、かつみんなの共通認識としてこういうのものだったら、たとえば4ポイントだよね、とか、その辺の認識合わせが必要になってきます。今だと、調整中というステータスのものも多かったりするので、中身もわりと流動的で、昨日3ポイントだよと言っていたものが、よくよく話していくと3ポイントではないね、みたいなことが起きやすい状態ですね。

小山:そうですね。一般的には、企画でだいたいこういうものが欲しいというのが決まっていて、かつ理想ではワイヤーまでできている段階で、デザイナー、エンジニア陣に「こうです」と説明して、エンジニア側も工数見積もるためにちゃんとイメージできるまで質問をして、その上で「xx ポイント」と出していくわけで、それくらいやるとそれなりに正確なポイントになるはずです。

永井:そういうことですね。だから、どんどん追加で「やっぱりこうしよう」とか「こういう機能付け足して欲しい」とか仕様がどんどん変わったり追加されたりすると、前に振ったポイントが意味なかったねみたいなことになるってことですよね。

「そうは言っても飛行機で1時間くらいはかかりますよ」と真面目に諭す石津

石津:そうですね。だから、ポイント見積りもそうですが、その前提段階として、みんなが「このプロダクトはこうあるべき」という姿をちゃんと共通認識として持っていて、そこにギャップがないという状態を目指すべきかなと。

小山:そもそも、ある程度複雑なものを4–5ヶ月でスピード優先でつくろうとしていたということもありますし、エンジニアたちもみんなBtoBのWebサービスつくってましたという人たちでもなかったし、新しいエンジニアもそれなりのペースで入ってきたりしていたので、一旦はスプリント区切りにすることでその2週間で行われることがみんなに可視化・共有されたということが大きいですかね。

永井:なるほどなるほど。じゃあ今はわりと何がどれくらいで出来上がってくるみたいなことも、事業側に対してそれほど振れ幅なく提示できるようになってきたという感じなんですかね。

小山:そうですね、機能単位で何がいつごろできてきて、みたいなタイムラインはそれなりにまわるようになってきましたね。以前は、この期間内でこれを終わらすには何を削らなくちゃいけないか、みたいなやり方を強いられることもある状況でしたが、そういうのはなくなりましたね。

永井:今後の方向性というか、さらに良くしていくにはどうすればいいみたいなイメージはあるんですかね?

石津:今後エンジニアの人数がさらに増えていくのであれば、チームをちょっと分けるとか、ありえると思いますが、現状の人数であればしばらく今の体制のままやる感じですかね。朝はデイリースクラムやって、夕方は職種レイヤーでの情報共有やって、みたいな。あとは、改善できるところでいえば、成果物をみんなで確認するタイミングが月末の締め会*(弊社内で行なっている、月末にオフィス内で全社員参加でその次の振り返りを共有する会のこと)だけになってしまっていますが、それをもっと早いタイミングで、それこそデイリーでもいいですし、機能が完成次第でもいいと思うんですけど、フォードバックを早くもらえるような仕組みにしたいですね。

そうやって、できたものばすぐ見せる、みたいなのが根付いていくと、これはちょっと違ってるぞみたいな状態のまま進んでいくとか、あとで「あれ?これ違うよね」と巻き戻ししたりするようなことがなくなるので、良いかなと思いますね。たとえば iOSとAndroidのUIがちょっと違ってるねとか、そういうのもできるだけ早いタイミングで見つけられるようにしていくといいかなと。

小山:あとは、成果物のレビューするタイミングをみんな忙しくてなかなか難しいということであれば、週1とかで決めて集まって、その時にその週の成果物をデザイナーやディレクターもふくめてみんなに見てもらうというのでもいいとは思います。

永井:すいません、ちょっと話が戻るんですが、そもそもデイリースクラムと夕会って何をしていて、何が違うんでしたっけ?

「そろそろランチの時間じゃないですかね?」とさりげなくリマインドする石津

石津:朝の方は全体の共有で、自分が関わっていないストーリーでも、今どういう進捗なんだっけ、というのを聞いておくという感じですね。

永井:朝は全員で円陣を組んでやってるスタンドアップミーティングもあると思うんですが、あれは何かやってるんですか?

小山:あれは、一旦デバイスやファームウェアチームも含め、本当に全体レベルで各チームが共有することを確認してるような感じですね。その後、デバイスとファームは一旦別れて、それ以外でデイリースクラムとして今の進捗をユーザーストーリーベースでひとつひとつ確認していってます。

で、いわゆるアジャイル開発だと、1日1回はみんなで状況シェアしましょうねというのがあるわけですが、うちの場合はそれを朝にやってまして、夕会では、サーバサイドならサーバサイドとか、アプリはアプリとか、技術レイヤーごとに分かれて今日何してたとかどうだったとか相談するという立て付けですね。

石津:今後はさらに事業側を巻き込んだ形にできるといいかもしれないですね。

小山:そうですね、もちろん今の事業側のリソースだと毎回スクラムに顔を出してってのは難しいので、今やっているようなスプリント前の事前共有というのもやっているわけですね。あとは、アドホックに必要なコミュニケーションはとってます。

石津:あとは、ちょっと前まではフロントエンドはひとりしかいないという状況もあったりして(笑)、リソース的にあまり柔軟な手を打てなかったという制約もありましたが、最近は人も増えてきたので、事業プライオリティの変化に合わせて開発リソースも柔軟に対応させるみたいなこともでき始めてきている感じはしますね。

「最近新しいランチ場所を開拓できてないことは深刻な課題」と熱弁する小山

小山:これからは運用フェーズになっていくので、今後はこれくらいのタイミングでこういうものができてきますよ、という話ももっとスムーズに行くようになると思います。プランニングもしやすい状況になってきましたね。

永井:なるほどですね、まさにようやくスタートラインに立ったという状況なのだと思いますが、これからますます楽しみですね!僕らとしても早く提供したくてうずうずしているものがたくさんある中で、とはいっても中途半端にはいどうぞってわけにもいきませんし、いろいろもどかしい部分はあるわけですが、そこは実直に丁寧にやっていくしかないですね。

お二人ともお時間ありがとうございました!今度また時期を改めて開発体制の進捗を聞きたいと思うので、よろしくお願いします!

関連記事