KUFU における SmartHR の開発

はじめに

社内の勉強会で現在の開発についてまとめてみたので公開します。
みなさんの意見も是非お聞かせください

そもそもアジャイル開発ってなに？

まず、前提知識として、我々はなぜアジャイル開発をしているのか、どういった手法があるかを簡単に説明する。

ウォータフォール開発の問題点

ドキュメント等の成果物で進捗が管理しやすいが、見た目の進捗は分かっても真の進捗は最後まで分からない。
ユーザは最初に見積もったシステム機能の7％をよく使うが45%は全く使わない。

アジャイル開発とは

最初から正しく決定できるわけがないと認め、学習と改善を前提としてわざと決定を遅らせる。
プロトタイプを何回か作り、設計にユーザを巻き込むユーザ中心設計（UCD）を取り入れる。
無駄な会議、無駄な設計、無駄なテスト、無駄なドキュメント等の無駄をなくすリーン開発思考。

スクラム開発とは

アジャイル開発を行うためのフレームワーク。

プロダクトオーナー、スクラムマスター、チームメンバーという役割を分けてそれぞれの責任を全うさせる。
バックログは誰のために、何のために、それを実現するのかを認識することで開発の目的をブレさせないようにする。
スプリント期間中に必ず終わると宣言できるバックログを組む。
バックログが全て終わるようにチームみんなで全力で開発に取り組む。
デイリースクラムで問題点を把握し、問題を先送りせず、すぐに解決する。

これらを行うことで、__課題を発見し改善を行う自律的なチーム作り__を行える。

SmartHR の開発手法について

次に、SmartHR の開発手法について紹介する。
SmartHR においてもアジャイル開発を行っており、スクラム開発手法を取り入れ、無駄を省き健全に開発できるように心がけている。
しかし、我々の様な小さな会社においては、完全に開発者が開発に専念すれば良いわけでわなく、通常のスクラム開発とはいくつかの点で異なる。

まず、プロダクトオーナーとスクラムマスターの様なロールを分けない。
なぜなら、役員、社員を含めた__全員にプロダクトマネージャやスクラムマスタの価値観が必要__となるからだ。
その価値観とは以下の4つに集約されるだろう。

1. 事業目標を理解すること。
2. 健全な開発が出来るように努力すること。
3. コアユーザについて理解すること。
4. 必要最低限の品質担保を自動化すること。

事業目標を理解していれば、タスクの優先度が判断出来るようになる。
健全な開発が出来るように努力すれば、その障害を問題提起してカイゼンを行える。
コアユーザについて理解する事で、最適な UX を判断することが出来る。
必要最低限の品質担保を自動化することで、ユーザデリバリーのスピードがあがる。

このように、同じ価値観を持つことで自律した開発を行うことが可能となり、開発スピードがあがる。

ただし、全ての従業員がこの価値観を共有してなければ破綻してしまう。
会社のフェーズや規模により、高い専門性が必要となったり、価値観の共有が難しくなったり等、開発手法がフィットしなくなった場合は__常に開発手法のカイゼン__を心がけ、より良いものを導入する。

ストーリの洗い出し

Trello に膨大なストーリが追加されており、それを週次で消化している。
そのストーリはどの様な原因で追加されるのか。

年間計画から出る大きな機能追加

基本的に、会社の状況によって 1Q 単位程度でスケジュールを見直しが発生する。
事業戦略的に必要な機能で、サービスの存続に必要となる機能。

1. モックを作成し検証を行う。
2. 目的を達成できる小さなストーリを作成する。
3. 特定のユーザへ限定公開し、フィードバックを受ける。
4. カイゼンを行い、ある程度の品質を達成したらユーザ全体に公開。
5. ユーザが欲しいだろう機能を優先して順次開発し完成度を高める。

ユーザからのフィードバック

サポートチャット上や、営業のヒアリングで多い要望。
実装する事によって、ユーザ体験が向上し、離脱率や退会率、満足度を上げる機能。
場合によっては「年間計画から出る大きな機能」になる場合もある。

1. SmartHR が担当すべき機能かどうか、サービスのポジションと照らし合わせ取捨選択する。
2. ユーザがなぜ欲しいのか、その根本的な欲求を考えストーリを作成する。
3. 開発を終えたら、フィードバックを頂いたユーザへの報告を行う。

システムのカイゼン

運用、開発にあたってのボトルネックをカイゼンする。
開発スピードの向上や運用の効率向上となる機能。

1. 週次の KPT で問題点を提起する。
2. 問題点を解決するための機能を良く話し合い、ストーリを作成する。
3. 後回しにならないよう、1週につき１つカイゼンが出来るように努力する。

バグ

ある機能の目的達成のために障害となるもの。
ユーザ体験を低下させないように、優先度高く解決。
場合によってはシステムのカイゼンの機能になる場合もある。

1. ユーザからの報告やドッグフーディング、開発中に発見。
2. 障害を取り除けるよう、ストーリを作成する。
3. 修正が完了したら、不具合の対象となったユーザへ報告を行う。

開発ミーティング（スプリント計画）

洗い出したストーリを開発が行えるよう、詳細な仕様や設計を考える週次のミーティング。
この場で仕様や設計を洗い出す事で、ミーティングの回数を減らすことが出来る。

候補の選択

ベロシティや残タスクの確認を行い、今回のスプリントで行うストーリを選択する。
この段階で開発者以外の人にも候補を選択しておいてもらう。

• ４つの種類のストーリをまんべんなく入れるように努力する。
• バグ、ユーザからのフィードバック、大きな機能追加、システムのカイゼンで優先度が高くなる傾向。

ストーリポイント出し

時間ではなくある作業の相対的なポイントを出す。

現在はこのストーリが 1 ポイントとなっている。

1. ストーリの実現方法を、ソースコードを見ながら検証し、設計や実現方法を詳細に洗い出してしまう。
2. スクラムポーカを使ってポイントを出す。
3. ポイントにズレがあった場合は、その懸念点や、より良い解決方法を話し合う。
4. ストーリの粒度が大きい場合は、デリバリーが出来る単位で分割を行う。
5. 詳細まで検証ができなかった場合はバッファを幾分か持たせても良い。

ストーリの決定

現在、ベロシティ指標として 3 週間のストーリポイント移動平均を利用している。
基本的にベロシティが安定することが大事。

1. 移動平均値や全体の平均値を参考に、今週のストーリポイントを推測。
2. 優先度の高いものからストーリを追加する。
3. ４つの種類のストーリをまんべんなく入れるように努力する。

開発

ストーリが決定したら、開発に着手する。

朝会

朝会では15分程度で、現在の進捗確認や作業を行う上での問題点を報告する。
ミーティングが長引くような議題は、朝会終了後に担当者同士で話合う。

1. 昨日やったこと。
2. 今日やること。
3. 開発するにあたっての問題点。

Doing(WIP) の制限

Doing が複数ある場合、いくつかのストーリが手付かずになり無駄となってしまう。
必ず一人一つまでに制限し、完了までの障害があるならばすぐに相談する。

コードレビュー

完成したらプルリクエストを作り、みんなでレビューする。

1. ソースコードは複雑ではないか。
2. 単体テストが十分か。
3. UI が適切か。
4. 負荷は少ないか。
5. セキュリティの心配はないか。

等をレビューし、コメントした人が LGTM した場合にマージすることが出来る。

UI に変更がある場合は、画像や動画を貼り付けて確認を簡単に行えるように。
相談はなるべくログが残るように心がける。

デリバリー

レビューが完了したら、次の日にステージングで確認を行い、問題点がなければデプロイを行う。
完成した機能を、ユーザへなるべく早く届けることを心がける。

# 今後、レビューが完了次第デプロイ出来る環境を作ろう。

ユーザへのアウトプット

デリバリーが完了したら、ユーザへその旨の報告を行う。
ユーザが開発の現状を知ることで、満足度の向上や抱える不安感を払拭することが可能となる。

• 新機能の場合は、使い方やどんな点で便利になったかを記載しブログに投稿する。
• 不具合改修の場合は、影響のあったユーザへサポートチャットで報告を行う。

作業のコミットについて

基本的に残業して、ストーリを解決することを良しとはせず、効率のよい仕事を心がける。
残業が多くなった場合は、工数の見積もりが間違っていたと認識して次回のストーリを調節する。
早く帰って、早く酒を飲もう。

ペアプロ

研修中や、難しい実装の場合はペアプロを行う。
経験者の開発方法を知ることや、二人いることで相談や問題解決をすぐ行える。

振り返りミーティング

スプリントが終了したら振り返りミーティングを行い、次のスプリントのカイゼンを行う。
__継続的な学習と改善をこのミーティングで行う__ことが出来る。

KPI

今スプリントの KPI を発表し、現在の事業の状況を全員に共有する。
現在の事業の状況を知ることで、開発者としてだけでなく、事業目標の統一を計る事が出来る。

KPT

• Keep は良かったこと。
• Problem は問題点。
• Try は問題点の解決方法や次のスプリントでやりたいこと。

これらを付箋に書いて、発表し次回スプリントに活かす。
Keep は褒め称え、Problem は皆で解決策を探る。
Try は、次のスプリントで状況を確認し、完了出来たら褒め称える。

まとめ

SmartHR の開発は単純なスクラム開発ではなく、もっとリアルタイム性の高いデリバリーと開発を行う事を目標としています。
そして、ユーザからのフィードバックとユーザへのアウトプットが開発サイクルに入り、ユーザとの接点が多い__ユーザ中心設計が組み込まれた開発スタイル__となっています。
まだまだ理想の環境には遠いですが、今後もカイゼンしていきますのでよろしくお願いします！

参考

開発チームを改善するためのスクラムTips（8）：5分で分かる、「スクラム」の基本まとめ (1/2) - ＠IT
【CyberAgent】技術情報／TechReport - テックレポート／SCRUMによる実践的アジャイル開発手法 | 株式会社サイバーエージェント
SCRUM/アジャイル開発の入門資料を全力でまとめてみた - 酒と泪とRubyとRailsと
スクラムのリーン