スクラム崩壊からの復活、神Excel手順書ベースの運用からAnsibleでの自動化へ――泥臭い現場の取り組みに学ぶ、明日から使える開発ノウハウ：明日の開発カンファレンス 2018（1/2 ページ）

より良いサービス、より良いモノを作るため、現場で泥臭く試行錯誤を重ね、前進し続けている現場のエンジニアの「声」を、「明日の開発カンファレンス 2018」で行われたセッションの中から拾ってみた。

[高橋睦美，＠IT]

　より良いサービス、より良いモノを作るため、開発現場は日々試行錯誤している。書籍で学ぶ方法論も大いに役に立つが、何より参考になるのは、自分たちと同じように現場で泥臭く試行錯誤を重ね、前進し続けている現場のエンジニアの「声」だ。そのような生の声を、2018年4月17日に開催された「明日の開発カンファレンス 2018」で行われたセッションの中から拾ってみた。

黄ばむTrello、崩壊するスクラム……次々変わる異なる課題に立ち向かったSmartHRの挑戦

　サービスの拡大や企業の成長に伴って、取り組むべき課題は変化し、最適な解決方法もまた変化する。クラウド人事労務ソフト「SmartHR」も、成長過程の3つのフェーズごとに直面した異なる課題に対し、異なるアプローチで解決を図ってきたそうだ。同社の芹澤雅人氏は「クラウド人事労務ソフト『SmartHR』を支える開発チームの作り方」と題するセッションを通して、フェーズごとに直面した異なる課題を、どんなアプローチで解決していったかを説明した。

プロダクトの黎明期

SmartHRの芹澤雅人氏

　第一フェーズはプロダクトの黎明期だ。SmartHRは2015年11月にローンチし、TechCrunch Tokyoのスタートアップバトルでも優勝を飾ったサービスだが、当初ターゲットにしていたのは、自社と同じようなIT系の小さなスタートアップ企業だった。それが、認知度が向上するに連れてユーザー層が広がり、100人規模のスタートアップ企業にも採用されるようになってきたという。

　「10人と100人では大きな違いがあります。10人規模の企業の労務管理は、社員が不定期に入ってくるたびに社長が片手間でやるもの。けれど100人規模になると、毎月数人程度は入退社があります。月次のルーティンワークとして、労務担当者が処理する仕事になってきます」

　月次処理として回すには、足りない機能がいろいろあることが明らかになってきた。そこで、ローンチ前にはどう逆立ちしてもできなかった、実際に利用しているユーザーへのヒアリングを行い、具体的な要望や使い勝手を把握し、サービスに反映していった。

　「SmartHRはSaaSなので、個別の要望に全て応えてカスタマイズしていったらとんでもないことになります。そこで『10社から要望があれば実装する』というルールにしました。さらに、このフェーズで入社した10年以上労務の実務経験を持つプロダクトオーナーに、機能設計を主導してもらうようにしました」

システム基盤の限界、プロダクトに対する要望の多様化

　次に直面したのは、システム基盤の限界だった。顧客が1000人規模の非IT企業にも広がってきたことで、扱う情報量が当初の想定以上に増加。結果として想定以上の負荷が加わってサーバの輻輳（ふくそう）が頻発する事態に陥った。

　「またしても抜本的な修正が必要になりました」

　開発現場では別の課題が生じていた。サービスや組織の拡張に伴って、エンジニアや営業、マーケティングといった具合にチームが細分化され、必然的にプロダクトに対する要望が多様化した。

　「するとどうなるかというと、Trelloが崩壊するんですね。タスクの優先度付けができず、いつまでたっても消化されない未処理チケットが増えて、画面がどんどん黄ばんできました（笑）。そこで月並みではありますが、Trelloに代えて『JIRA』を導入しました。好みが分かれるとは思いますが、僕は結構気に入っています」

　この時期からSmartHRでは各チームのリーダーが1週間に1回集まるようにし、JIRAで起票されたバックログに記した要望をやるか、やらないか、やるとしたらどのスプリントでやるかを決めるようにした。

　「この作業は、『じゃ、これは3週間後にやろう』といった具合に、将来のスプリントの計画が立てられるのが良いところです。この結果、対応時期の不明な要望チケットがなくなり、バックログが常にクリーンな状態になりました。向こう1〜2カ月くらいのスプリントの計画が分かるので、開発者の精神的な安定にも役立ちました」

　また、会社としての規模も拡大してきたことを踏まえ、「今のSmartHRにとって一番大切なことは何だろう」と全社合宿で話し合って決めるようにした。あれもこれもやるのではなく、一番優先すべきことは何かの指針を全社で共有することで、開発者としても「これは今やらなくていもいい」と気楽に言えるようになった。

　「こうした取り組みを通じて、数千人規模でも耐え得るサービスを実現していきました」

スクラムの崩壊、チームが抱える課題の多様化

　その後も順調に成長を続けた同社。成熟に向かう中で、またしても新たな課題に直面した。

　1つ目はスクラムの崩壊だ。スクラムガイドによると、スクラムチームの最大人数は9人程度とされているが、規模が大きくなり、とうとう限界に達した。具体的には、タスクが専門化するにつれて、明示的に手を上げなくても「このタスクはあの人がやってくれるだろう」という暗黙のアサイン、他人任せ、タスクの偏りが増えるようになった。プロダクトオーナーシップとは真反対の考え方だ。同時に、工数の見積もり作業そのものが肥大化し、1つのスプリントの所要時間も増大してきた。

　この問題に対し芹澤氏らは、チームを分割して解決を試みた。ちょうどSmartHRの新たなアドオン機能の開発が本格化したタイミングだったこともあり、プロダクトタイプごとにチームを分割した。その結果、「すごくうまくいった」と芹澤氏は振り返る。

　また、ガチガチにスクラムガイドに沿って進めるのではなく、ところどころSmartHRの現状に合わせてカスタマイズすることにしたのも功を奏した。

　もう1つのピンチは、チームが抱える課題が多様化してきたことだ。技術的なアプローチだけでは限界があると考え、制度面に踏み込んで解決に取り組んだ。一対一での対話に加え、チームの枠を超えてエンジニアが集まる「エンジニア定例会」を実施してみたところ、チームビルディングを始め、課題についてさまざまな解決のアイデアが生まれてきたそうだ。

「遊び心」を保ったまま、制度や仕組みを整備していく

　このようにSmartHRは、一歩進むたびに新たな課題に直面しては、愚直にそれを解決する方法に取り組んできた。

　「サービスもまだまだ完成にはほど遠く、できていることはまだ氷山の一角です。人事労務領域をすべからく効率化すべく、テクノロジーでハックしていきますし、組織についても同様に、毎日のように新たに直面する課題を解決すべく、もともとSmartHRが持っていた『遊び心』を保ったまま、制度や仕組みを整備していきます」