超速で開発・リリースするための6つのこと

「サイボウズ・アドベントカレンダー」の8日目です。ちょうど真ん中まできました（これまでの記事一覧）。

---

こんにちは。kintone 開発チームの刈川です。いきなりですが、皆さんはどのくらいの頻度でアプリやサービスをリリースしていますか？

1週間？ 1ヶ月？ 1年？

規模によると思いますがクラウドサービスではリリースのスピードが大事です。せっかくいいアイデアを思いついたのに、それを実現するまでに果てしない時間と労力がかかるとしたら…。ユーザの意見を取り入れるまでに半年も一年もかかっていたのでは、ユーザは他サービスに移ってしまうかもしれません。そこで今回は、私たち kintone チームが取り組んでいる「スピーディな開発・リリース」のための手法を簡単に紹介したいと思います。

アイデアを形にする

アイデアというのは形にするまでがゴールです。開発現場ではこのことをリリースと呼び、リリースをするまでにはたくさんのプロセスがあります。 設計、実装、テスト、デプロイ、運用…

この中で私のようなプログラマが担当するのは設計や実装、そしてユニットテストなどです。その後はQAによる各種試験を経て、サービスのデプロイ・リリース作業をインフラチームにバトンタッチします。このようにリリースまでには多くの人が関わります。これを全て手作業で行うとそれなりの時間を要することでしょう。 素早くリリースするためにはこのサイクルを短くすることが重要になります。

kintone チームではこのサイクル中のプロセスを自動化したり、開発手法の改善を日々行ったりして省力化を試みています。以下で紹介しましょう。

1. 自分達で開発したものは自分達で使う

ドッグフーディング（自社製品を自社内で使い倒す）という言葉があります。よりよいものを提供するためには、より多くのフィードバックが必要です。しかし、誰かが使わないとフィードバックは得られません。そこで kintone チームではチーム内のコミュニケーションのほとんどを「開発中の」 kintone で行っています。また、リリースされた安定版を使っていると開発中のバージョンに緊急度の高い不具合があった場合にすぐに気付けなくなるという恐れがあります。

2. 変更を push したら自動で即反映する

常に最新のものを使い続けるためには、そのための環境を用意しなくてはなりません。kintone チームでは Git によるブランチ管理と Jenkins による自動ビルドを行っており、メインブランチに変更が push される度にドックフーディングしている環境が更新されます。ドックフーディング環境はメンバー全員が使っているので、もしバグを含んだ push をすると自分達の業務に支障をきたす恐れがあります。それを避けるためにチーム全員が push 前の品質意識を持つようになります。

変更を push すると自動テストが走り、アーカイブがビルドされ、私たちが使っているコミュニケーション用の環境に自動でデプロイされる。

3. テストが赤くなったら即対処！疑わしき者は晒しage

変更をブランチに push したら、 Jenkins 先生による採点が始まります。テストにコケると、そのコミットをした人の名前が全社員が見ることのできる掲示板上に晒し上げられます。これは恥ずかしい！急いで修正せねば！

私がテストでコケて Jenkins 先生に叱られているところ。自慢ではないが、通算では私が一番先生に叱られていると思う。（本当に自慢ではない）

以前はメールによる通知をしていたのですが、メールだとすぐに埋もれてしまうし、誰が責任を持つべきかが分かりづらかったのでこのような形に落ち着いています。また、掲示板上で公開することで他のメンバーからのアドバイスをもらいやすくなるという利点もあります。 継続的デリバリーでは「テストがコケたら今の作業を中断してでもすぐにテストに通るように修正すべき」であると述べています。これはいつでもリリースができるように備えておかなければならないためです。

4. 開発期間をイテレーションで区切る

kintone チームでは約2ヶ月の開発期間を取っています。そしてこの2ヶ月を2週間くらいに区切ってこれをイテレーションと呼んでいます。イテレーションが終わるごとにチーム内で振り返りを行い、問題点や改善案を明確にして以降のイテレーションで実行します。また、営業や QA、DOC などの関係者向けにそのイテレーションで作った機能の「お披露目会」をしてフィードバックをもらっています。

5. 技術的負債を返済する期間を設ける

開発中、怪しいコードに出会うとリファクタリングをしたくなるのがプログラマの性。しかし大幅に時間がかかりそうな場合はその欲望をぐっとこらえ、「技術的負債」という形でチーム内に共有しています。この技術的負債はイテレーションの合間や次のバージョンへの準備期間などにまとめて時間を取って、できそうなものからどんどん「返済」していきます。

次々に登録されていく負債。やりたい気持ちを抑え、今はタスクに集中するのだ。

6. やることリストをふせんに貼り出してみる

イテレーションごとにやらなければいけないタスクをふせんにして貼りだす、という取り組みも行なっています。このボードを見ることで何ができていなくて現在何に取り組んでいて何が完了しているのかが一目瞭然になります。

「まだ」「やってる」「やってやった」に分類。ふせんの色にこれといった意味はない。

おわりに

簡単にですがスピーディな開発・リリースを行うための手法をいくつか紹介しました。日々の業務改善は私たちもまだまだ模索しているところです。良い方法を見つけたなら「とりあえずやってみる」ことが大切だと思います。この中でひとつでも皆さんの参考になるものがあれば幸いです。

---

明日は「メッセージがダメならチャットすればいいじゃない 〜サイボウズLive と Facebook API〜」をお送りします。お楽しみに。