不動産情報や住宅情報を簡単に検索できるサービスである
スクラム開発への取り組みで得られた大きな効果
- ──実際にスクラムに取り組んだことで、
どういった改善効果があったのでしょうか。 吉田氏:大きかったのは、
コミュニケーションの質が向上したことです。メンバー同士を近距離に配置することで、 基本的なコミュニケーションがとりやすくなっただけでなく、 コラボレーションが生まれたことも大きな変化です。たとえば開発を進めているとき、 デザイナー側から “これはこうしたほうがいい” といった形で意見が出てくるようになりました。このようにスクラムを導入することで、 これまでの開発よりも、 より活発なコミュニケーションが生まれました。また、 短いサイクルでリリースが行われフィードバックも都度得られるため、 不確実性が高い案件においてもチャレンジしやくすなったという効果もありました。 - ──SUUMOスマホサイトでは、
すべてのプロジェクトでスクラム開発を採り入れているのでしょうか。 吉田氏:プロジェクトの内容に応じてウォーターフォールとスクラムを使い分けています。実際にスクラムを検証したとき、
ウォーターフォールの案件すべてに適用できるような “銀の弾丸” 的な開発手法ではないことがわかったからです。先ほどお話したように、 コミュニケーションやコラボレーションの面ではスクラムにメリットがありますが、 課題と解決策が明確な案件に関しては、 今までの手法でやったほうが安定して進められることも見えてきました。それで、 プロジェクトの性質に応じて、 ウォーターフォールとスクラムを使い分けることにしたのです。 - ──具体的に、
どのようにウォーターフォールとスクラムを使い分けているのでしょうか。 吉田氏:課題や顧客ターゲットが明確で、
不確実性が低いものについてはウォーターフォールで開発します。逆に不確実性が高いもの、 あるいはリファクタリングや環境整備といったプロダクトの改善を目的とするものはスクラムで開発します (図1)。
山下氏:それともう1つ工夫があって、
異なる開発プロセスを同時に効率的に推進できるように、 開発基盤の整備やアーキテクチャ・ 品質担保を 「アーキ・ 基盤整備チーム」 が行っています。
JIRAのワークフローを積極的に活用
- ──課題管理に
「JIRA」 を使われているとのことですが、 実際に便利だと感じるのはどういった点でしょうか。 吉田氏:以前は課題管理にExcelや複数のツールを使っていて統一されていませんでしたが、
今はJIRAで統一でき、 打ち合わせはJIRAの画面を見ながら行っています。複数条件での絞り込みなど、 強力なフィルタリング機能があり、 ある協力会社に対応していただいている課題だけを絞り込んで表示できるなど、 非常に使い勝手がいいですね。 山下氏:スクラム開発では、
「JIRA Agile」 を使っています。カンバンで進捗状況を把握したり、 それぞれのスプリントにおけるプロダクトバックログの管理といった部分です。ワークフローも活用しています。便利なのは、 開発プロセスごとにワークフローを変えられるところです。ウォーターフォールで使うのは、 原則となるV字モデルのワークフローですが、 スクラム開発では独自のワークフローを構築し、 個別に最適化を行っています。 ウォーターフォールにおいては、
チケットの入力項目をカスタマイズしてウォーターフォール特有の項目を追加しました (図2)。たとえば見積りや実績工数をチケットに入力できるようになっていて、 独自のツールを使って予実管理を行っています。
吉田氏:スクラム開発では、
ワークフローのトランジション部分を工夫しました (図3)。たとえば 「IN PROGRESS」 から 「IN REVIEW」 になるタイミングはTrigger機能を利用し、 StashでPull-Requestした時点で自動的にステータスを変えるようにしています。さらに最近では、 「WATING FOR UAT」 になるとQAチームに自動でアサインするように設定しています。 こうすることで、
手作業を最小限にし、 開発やテストといったクリエイティブな作業により多くの時間を割けるようになっています。
Stashを選んだ理由と運用面のポイント
- ──今のお話にも出てきましたが、
ソースコード管理ツールとしてStashを採用されていますが、 ほかに比較したツールはあったのでしょうか。 山下氏:Stashを導入する際、
「GitHub Enterprise」 と 「GitLab」 も検討しました。いくつかの観点がありますが、 コスト面でメリットがあったこと、 そしてツール連携のしやすさなどの点から最終的にStashを選択しています。 - ──実際にStashを導入した際、
使い方や運用面などで戸惑われたことがあれば教えてください。 山下氏:既存のSVN環境からGitへの移行でいろいろと苦労しました。まずSVNで管理しているリポジトリをすべてGit化することになりますが、
移行対象のリポジトリだけでなく、 そのリポジトリに関連するツール、 たとえば開発環境やリリースを行うシェルスクリプトなども併せて作り替える必要があったためです。 開発ルール周りも苦労した点です。SVNとは異なり、
分散型バージョン管理のメリットを最大限活用するためにブランチモデルを設計するなど、 新しい開発ルールを作成しなければなりませんでした。また、 承認権限や命名規則、 コミットルールの整備など、 細かなルールも併せて考える必要があります。このように、 Stashを使うことよりも、 Stashをどう使っていくのかの検討に時間がかかりました。 吉田氏:開発メンバーの知識レベルをそろえるところも時間がかかった点です。全体で30~40人規模なので、
Gitの最低限の使い方といった知識レベルを合わせるのにも時間がかかっています。このあたりについては、 それぞれのチームの開発リーダーに協力してもらいながら徐々に進めました。 山下氏:苦労したのはどちらかというとGitの部分で、
Stashそのものの使い方で困ったことはほとんどありません。ここがStashの優秀なポイントだと思いますが、 git-flowをはじめとする一般的なワークフローにデフォルトで対応しているため、 開発ルールさえ決めてしまえば、 あとはそのまま使うだけでいい。このようにシンプルな設計になっているので助かっています。
Access-Key認証でセキュリティを確保
- ──実際にStashを導入して、
便利だと感じた点はどういったところでしょうか。 山下氏:Access-Key認証と呼ばれる、
リポジトリごとに設定できる公開鍵暗号方式の認証方法は重宝しています。リクルート住まいカンパニーにはセキュリティ面で非常に厳しいルールがあり、 自動リリースやCI連携をセキュアに実現する必要がありました。Access-Key認証を利用すれば、 それをシンプルに実現できるのはいいですね。
プロジェクトを効率的に進めるため、
柔軟に設定できるJIRAのワークフロー
JIRAにはプロジェクトの流れを定義し、
日本だけでなく、
アジア圏でもアトラシアン製品販売のトップエキスパートであるリックソフトのWebサイトでは、 各アトラシアン製品の体験版を提供しているほか、 アトラシアン製品専用のコミュニティも運営しています。まずはアクセスしてみては!
- リックソフトJIRAデモ環境
- https://
www. ricksoft. jp/ demo/