12
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

GaiaxAdvent Calendar 2016

Day 10

レガシーな開発プロセスからスクラムを導入したまでの話

Posted at

この記事は Gaiax Advent Calendar 2016 10日目の記事です
この1年間、開発プロセスの改善について取り組んできたのでそのことについて書きます。

はじめに

私はGaiaxに入社してからAIRYというプロダクトに所属しています。AIRYは2014年にリニューアルしましたが、歴史としては2006年からと Gaiaxの中では長い事業になります。プロダクトは約3年前にリニューアルをして、メンバーも数回入れ替えがあったのですが、開発のプロセスは見直されることはなく伝統的に引き継がれてきていました。しかし今年に入ってから事業の成長スピードについていけないことが課題になり始めていたので2016年は開発のプロセスを見直すことにしました。

開発プロセスの変遷

私が事業に所属をしていたころから、進め方として営業の方や企画の方が考えた機能/企画を実装するという進め方でやっていました。開発の方も降ってくることをやるだけといういわば社内受託の状態になっていました。サービスを提供している事業に所属しているのに社内受注になっているっていうのはいいのか?ということがそもそも今回改善をしようと思ったきっかけです

なんちゃってスクラム期

最初はカンバンを導入してタスクの見える化を行いました。誰が何をやっているのか分からない、どのくらい残っているのか分からないということがチームで課題に挙がっていたので可視化するためにカンバンを導入してやってみました。最初はこんなにもタスクがあるのか、という感じで見えるようになって頑張っていこうと思えたのですが、やる順番が分からない、日々ToDoが増えていく割には終わらないということが課題になりました。
いま思い返すと、ただ個人でやろうと思っていたことをタスクにしていただけで、本人しか内容が分からなかったり、見えている以上にタスクが多く、あまり効果はありませんでした。

変わったこと

  • 完了までにやることが共有されるようになった
  • 誰が何のタスクをやっているのかみえるようになった
  • 何で止まっているのか見えるようになった
    課題
  • 本人しかわからないタスクがある
  • タスクの関連が見えない(工程とか順番)

カンバンプロセス期

なんちゃってスクラムのときはToDo/Doing/Doneのシンプルなものだったのですが、実施する順番を分かりやすくするためにプロセスごとに工程を設けたカンバンにして進めることにしました。カンバンを導入したものの今まで通り得意なこと、できることから取り掛かろうとしてしまい思った以上に終わらせるよりはじめてしまって結果的にリリースまで時間がかかってしまいます。そこでルールとして「終わらせることから始めよう」ということをおいて、取り掛かったタスクをチーム全員で終わらせに行くようにしました。リリースまで持っていけるものが増えていってはいたのですが、タスクによって進みにバラツキがでて、一部の工程でどうしても時間がかかってしまうことが課題でした。

そこで、そもそも開始からリリースまで一体どういうプロセスをたどっているのかをValue Stream Mappingに落としてみることにしました。すると結構やっていることが多く、本当にそれが必要なのかなどを話しました。あらためて見直してみるとなんでやっているんだろう?っていうタスクが多々あって儀式みたいになっているタスクまであってだいぶロスしていることがわかります。これらについて必要性の有無を議論して。タスクをなくしたり、順番を入れ替えたり統合したりしてプロセスを改善させました。

変わったこと

  • タスクの工程と順番が見えるようになった
  • 何をやったら次の工程に進めるのかみえるようになった
  • 始めたタスクを終わらせるようになった
    課題
  • 時間がかかる工程がある
  • 始めたのに終わらない
  • 隠れたタスクがある(タスクの粒度が大きい)

スクラムの導入

そのあとしばらくやっていたもののリリースまでのスピードは特にかわりませんでした。分析してみると1つのタスクが大きくなっていることと、期限が決まっていないものはやりすぎてしまっているということがわかりました。そこでPMOの提案でスクラムを導入しました(ここまで長かった)  いままでのことを踏襲して、ストーリを実現するまでのタスクの洗い出しと2週間というスプリントを決めて進めるということをルールにやっています。
2ヶ月くらいやってみていますが、以前のなんちゃってスクラム期やカンバンプロセス期に比べると2週間ごとに必ず成果があげられるようになったので効果は出てきていると思います。(なによりメンバーが続けたいと言っていることがデカイ) 

変わったこと

  • 2週間で必ず成果がでるようになった
  • 計画の段階でタスクの洗い出しと共有ができるようになった

現状の課題

スクラムを導入したからといって全てが解決するわけではないので、いま挙っている課題をざっと。

改善がはかどらない
スクラムを導入してみたものの日々のタスクに追われて改善に時間がなかなかとれていません。開発チームは開発のほかに運用を持っているのですが運用についての時間はとっていません。この辺りを計画に入れてみたら良さそうです。

誰かしか分からない情報がある
長く事業をやっているとどうしても事情を知っている人にだけ情報が溜まりがちになってしまいます。また元々の専門分野の知識や考え方などまだまだ共有ができていないため誰かが休んだりするとそこで止まってしまうことがあります。こちらはペア作業/ペアプログラミングを導入して情報の共有をしながら進めていっています。

なんであるのか分からない工程がある
カンバンプロセスの時にもやったのですが何のためにやっているのか分からない/効果がなさそうな工程や作業が残っていたりします。せっかくプロセスを変えたのであればこれらも常に見直していくともっと開発のスピードが事業のスピードに追いついていけるようになると思います。

まとめ

ざっと1年間を振り返ってみました。いまの状況になるまでなかなか紆余曲折してきましたが誰かが考えて執行するのではなくて開発チームで話して考えてここまで持ってこれたという意味ですごく意味があったことだと思います。プロセスの改善は終わりがないのですがこれからも開発チームも事業も一段と伸びていけるように進めていきたいと思います。

12
4
2

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
12
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?