スクラム開発はうまくいってる？ その効果をメンバーに聞きました！
Incrementsが開発している情報共有サービスQiita Team（キータチーム）では、約6カ月前からスクラム開発を導入し始めました。「そろそろ効果やメリットなどが実感できるころでは？」と考えたWork:Q編集部は、開発メンバーのエンジニアであるtakashiさんにお話を聞いてみました。
聞き手・文／Work:Q編集部 話し手／takashi
takashi
中川峰志（なかがわ・たかし）／Railsアプリケーション開発やビルドプロセスの改善に携わりIncrements入社。現在はフルリモートで開発に携わり、Qiita Teamを担当。
見える化やチーム感を持った開発を目指してスクラム開発を導入
それでは早速なのですが、Qiita Teamにおけるスクラム（※）開発の実際についてお話を伺います。まずはQiita Teamでのスクラム開発の編成について教えてください。
※スクラム（名詞）：複雑で変化の激しい問題に対応するためのフレームワークであり、可能な限り価値の高いプロダクトを生産的かつ創造的に届けるためのものである。1
チーム編成は、プロダクトオーナーが1人、スクラムマスターが1人、残りがエンジニアです。僕はエンジニアのメンバーとして参加しています。
※スクラムマスター：スクラムの理解と成立に責任を持つ。そのためにスクラムマスターは、スクラムチームにスクラムの理論・プラクティス・ルールを守ってもらうようにする。1
いつからスクラム開発を取り入れたのか、なぜスクラム開発を取り入れたのかといった導入に至る経緯を教えてもらえますか。
導入したのがだいたい6カ月前です。導入以前のQiita Teamの開発では、個人をベースにした形で開発を進めていました。なので「この4半期はこれやります」といった個人の意思で担当が決まり、チケット（※）を切る、切らないも担当になった人の自由。たまにミーティングもありましたが数えるほどで、良くも悪くも個人にお任せというスタイルだったんですね。
それだとプロダクトマネージャーやメンバーとしては、進捗状況や開発にどれくらいの工数がかかってるかが見えにくいですし、チームとして機能しているとは言えないところもあり、スクラム開発を導入してQiita Teamにおける開発をより良くしていこうと取り組んだのがきっかけです。
※チケット（チケット型駆動開発）：プログラム開発手法の一種で、作業をタスクに分割しBTS（Bug Tracking System／バグ管理システム）のチケットに割り当てて管理を行う開発スタイル。2
導入して半年なので、まだそれほど時間が経っておらず、試行中だとは思いますが、実際の取り組みとして、どのようにスクラム開発を進めているんでしょう。
Qiita Teamでは、スプリントを2週間としていて、2週間に一度、水曜日にスプリントレビューとスプリントの振り返りが設けられています。ほかにデイリーのスタンドアップミーティングがあって、毎日14時に全員が集まって、昨日何をやったかと今日何をやるかを報告する会があります。何か相談事があったらそこで相談しています。スタンドアップミーティングの開始時間を14時としているのは、Incrementsのコアタイムが13時〜17時なのが理由です。
※：スプリント：スクラムの中心はスプリントである。これは、「完成」した、利用可能な、リリース判断可能なプロダクトインクリメントを作るための、1カ月以下のタイムボックスである。1
※：スプリントレビュー：スプリントの終わりにインクリメントの検査と、必要であればプロダクト・バックログの適応を行うものである。スプリントレビューでは、スクラムチームと関係者がスプリントの成果をレビューする。1
スクラム開発の流れ 3
非同期・分散型の環境によるスクラム開発を試行
スタンドアップミーティングはデイリースクラムと呼ばれるものですよね。朝会としてやっているところもありますが、それをアレンジしているんですね。
そういった、例えば普通に行われているスクラム開発の取り組みとは違った、Qiita Teamでのスクラム開発の取り組みがほかにもあったら教えていただけますか。
※デイリースクラム：開発チームが活動速度を合わせ、次の24 時間の計画を作る 15 分間のタイムボックスのイベントである。前回のデイリースクラムから行った作業の検査と、次回のデイリースクラムまでに行う作業の予想を行う。1
僕がフルリモートで仕事をしていることもあり、リモートのメンバーがいる前提で、非同期・分散型の環境でスクラム開発を試している点が通常とは違っているところだと思います。
例えばスタンドアップレポートというレポートを毎日、提出しているんですが、それはスタンドアップミーティングで共有する「昨日は何をやって、今日は何をやるか」をレポートにしたものです。チームに共有して、14時のスタンドアップミーティングの時にその内容を報告します。
毎日のレポートを作成しているのは、テキストで作業記録を残しておくというのと、リモートで起こりがちなメンバーとの齟齬がないようにしているためです。
同じようにリモートならではの取り組みとしては、普通はプランニングポーカーと呼ばれるカードを使って、対面でタスクを見積もりますが、リモートだとそれができないので、Pointing Porkerというインターネット上のツールを使っています。
Qiita Teamの開発だと2、4、8、100のポイントがあって、1ポイントで半日の単位にしています。2だったら1日。4だったら2日ですね。これでタスクを見積もっています。
テキストでの明文化や便利なツールを利用して、リモートでのスクラム開発をうまく回すための工夫をされているんですね。では、フルリモートを実践されている立場にいるtakashiさんが何か気を付けていることはありますか。
相談事を思いついたらちょっとしたことでもメモしておいて、スタンドアップレポートに書くようにしています。GitHubにもコメントを残すようにしていますね。とにかくテキストはマメに残すように気を付けています。あとはビデオ通話もよく使っています。
スクラム開発は、実践していくうちにスピードが上っていくと言われているようですが、チームとしてスピードが出てきたと感じましたか。
4カ月目、5カ月目くらいからスピードが上がってきたと思います。本当に最近ですね。タスクの見積もりの精度が上がって、前に比べると「これくらいでできると思ったんですけど、やってみたらできませんでした」みたいなことが減ってきました。
進捗の見える化、コミュニケーションの活性化などのメリットが
まだ導入してから間もないので、目覚ましい効果というのは難しいと思いますが、takashiさんが現時点で感じているスクラム開発のメリットについては、どんなことがありますか。
最初に話題に出ていましたが、スクラム開発を導入する前は、みんなが4半期ごとに1つの機能を担当して開発を進めていたので、進捗があまり見えていなかったのが、見えるようになったという点ですね。
2週間に1回の振り返りで、見積もりに対してどれくらい遅れてるのか、どれくらい進んでいるのかが分かって、プロジェクトの進捗度合いが把握できるようになりました。
あとは、僕はいま1つのプロジェクトをずっとやってるんで別なんですが、ほかのエンジニアを見ていると、手が空いてることがなくなったっていうのがありますね。タスクがずっと積まれていて、次々にタスクをやっていけばいいので。
導入前だと4半期の期間で何かしらの機能を開発するという取り組み方だったため、それが期間中に終わってしまったら何をやるかというのは、見えていなくて、手持ち無沙汰というか、待ち時間になってしまうみたいなことがあったんですけど、それがなくなりました。
タスクが明確になったのは、プロダクトバックログ（※）でQiita Teamに何が必要とされているかが把握できるようになったからで、これもスクラム開発を導入したメリットです。
また、スタンドアップミーティングを毎日行うのが半ば強制的にルール化されているのもいいと思います。何か困りごとがある時に「この後ちょっと話しましょう」って言えたり、コミュニケーションを取る機会が得られますから。
※プロダクトバックログ：プロダクトに必要なものがすべて並べられた一覧であり、プロダクトに対する変更要求の唯一の情報源である。（中略）今後のリリースで実装するプロダクトのフィーチャ・機能・要求・要望・修正をすべて一覧にしている。1
確かに導入前のような個人ベースの取り組みだと、話すきっかけを作りづらかったり、「大したことじゃないから共有しなくてもいいか」といった感じで、チームの意思疎通が進まないケースも考えられますね。
では、反対にスクラム開発をやっていて、ここはもうちょっと変えていきたいなと思ってる点はありますか。
スクラム開発でQiita Teamの開発チームがいま何をやっているのかが、ほかの社員には見えづらいという点です。スタンドアップレポートも共有はしていますが、あくまでタスクに取り組んでいる前提で書いていて、「このタスクをこなすことで、機能がこうなっていく」といったことまでは、スクラム開発に関わっていない外部の社員には分かりませんから、そういった部分が分かりやすく伝わればいいなとは思います。
全社ミーティングで伝えるような機会があるといいのかもしれませんが、現状は月に1回なので、あまり細かくは伝えられないということは考えられますね。他社でも開発チームとそれ以外のメンバーとのコミュニケーションについては、同じような悩みを抱えていそうです。そのあたりは確かに何かしらの取り組みができるといいですね。また効果が見えてきたらお話を伺わせてください。本日はありがとうございました！
Incrementsでは、一緒にQiitaとQiita Team、Qiita Jobsを改善したいエンジニアを募集しています💪
まずは気軽に、一緒にランチを食べませんか。
興味のある方はこちらのボタンをクリック↓
3.Ryuzee.comさまのこちらの記事を参考に再配布させていただきました。
Increments
Incrementsは、「エンジニアを最高に幸せにする」をミッションにしているスタートアップです。エンジニアの方々が幸せに開発できるために、エンジニアの方々が嬉しいと思ってくれるために、私たちはソフトウェアの開発に取り組んでいきます。
Qiita
Qiitaは、知見を共有しスキルを高めることができる、プログラミングに特化したオープンな情報共有コミュニティです。
Qiita Team
Qiita Teamは、チームの生産性を高めるために開発された社内向け情報共有ツールです。チームメンバーが簡単、気軽に情報を書き込んで、それが適切なメンバーと共有され、共有された内容について活発にコミュニケーションを取ることができるサービスです。
Qiita Jobs
Qiita Jobsは、エンジニアに特化した転職支援サービスです。会社ではなくチームを探す。採用担当ではなくチームメンバーと話す。人事ではなく自分が配属チームを決める。Qiita Jobsはあなたに最適なチームで最高の仕事をするきっかけを提供します。
Qiita Team に新しくファイル添付機能、書式設定ツールバーが追加されました！（2017/09/07）