急成長中SaaS企業の開発チームが取り組む「あえてスクラムと呼ばない」開発スタイルとは：開発現場を変えたくて悶々としているあなたに
うまくいっていないところを改善したい、自動化したい、モブプログラミングに取り組みたい……そんなさまざまな新しいチャレンジに取り組みたくても、目の前の仕事に追われてなかなか手が回らないという悩み、思い当たる人も多いだろう。そんな状況を打開していった、中小企業の業務を効率化するSaaSを提供し成長を続けているラクスの取り組みを聞いてみた。
人には得意、不得意や好みがある。決まった枠組みに沿って確実に仕事を進めていくのが得意な人もいれば、現状の問題点を洗い出して変えていきたい、何かもっと新しいことに取り組みたいという人もいる。
ラクスの配配メール開発課でクラウドサービスの開発に携わりつつ、チームの在り方そのものの改善（カイゼン）に取り組んでいる吉元和仁さんは、後者だ。開発の現場から出てくる新たなアイデアを実現するため、どのようにチームを変えていったのだろうか。
新たなことに取り組むために、まず整理整頓を――「5S活動」からのスタート
以前はSIerで働き、受託開発から組み込み開発、Web開発に至るまでさまざまな開発案件に携わって経験を積んできた吉元さん。これはこれでやりがいのある仕事だが、「実際に使っている人の声を近いところで聞きながら開発ができる自社開発に憧れがあって、ラクスへの転職を決めました」という。
入社してみると、顧客から落ちてきた仕様に沿ってその通り作るという枠組みから外れ、自分たち開発側の提案やアイデアを取り入れながらサービスを作り上げていくという、期待通りの世界に喜びを感じたそうだ。一方で意外と泥臭い作業もあちこちに残っており、まだまだカイゼンの余地があるな、というのも率直な印象だった。そこで、「この面倒くさい作業を何とかしたら、もっと開発に時間を割けるのに」と感じた作業や運用コストのかかる作業のカイゼンや自動化に取り組んできた。
1年半前、「配配メール」というサービスを手掛けるチームに異動してきてから、こうした問題意識はより強まったそうだ。
「当時たまたま人の異動が重なり、若手中心のチームだったこともあり、常にスケジュールに追われていました。リソースの効率的なやりくりが最優先で、カイゼンとかそういう話をする以前の状況でした」
吉元さんは前のチームでの経験を生かしてカイゼンや自動化に取り組もうとしたが、その前に取り組むべき問題が山積していた。
「目の前の開発に追われ、リポジトリのソースコード管理が不十分で、プロダクトコードの中に不要なコードが紛れていたり、ドキュメントを参照したくてもどこにどのドキュメントがあるか分からなかったりと、さまざまな問題がありました。チームのメンバーも『このままではいけない、何とかしたい』という問題意識は持っていたのですが、目の前の仕事に追われ、振り返りもカイゼンも全て後回しになっていました」
コーディングに関するルールやチェックリストもあるにはあったが、形骸化し、内容も古ければ使う側もおざなりという具合。まさに、「忙しさに追われるプロジェクト、あるある」だ。
そんな状態のチームのカイゼンを期待されて加わった吉元さんが最初に重視したのが「割れ窓理論」だ。「ルールがあっても、守らないのが当たり前」という状況を変えなければ、本来やりたいと考えていた自動化も何も始まらない。そこで、製造業やサービス業ではおなじみの「5S運動」をチームに持ち込み、タスクの整理整頓から開始した。
「やっていることがバラバラ、スコープもまちまちでは、どこから手を付けていいかも分かりません。そこで、まずウオーターフォール式の開発プロセスの各工程について『この工程の目的は何で、何をするのか』をチームに合うように定義し直し、ルールをしっかり決めた上で課題の洗い出しに取り組み始めました」
慢性化していたスケジュール遅延の解決に向け導入した「反復開発」
こうして活動を開始してから約半年。新たに加わったメンバーにも必要な情報がすぐ手に入るような環境が整ってきたが、なかなか解決できない課題があった。慢性的なスケジュールの遅延だ。
前述の通り、吉元さんたちのチームは新卒も含め若手エンジニアが多かった。ある程度の開発経験を持ち上流工程から下流工程まで一通り担えるメンバーは限られており、どうしても吉元さんら特定の人に負荷が集中しがちだった。本来の業務に加え、若手をサポートしながら全体のスケジュールも管理する……といった具合にマルチタスクを余儀なくされたが、どうしてもスイッチングコストは膨らむ。この結果、まず自分の仕事がなかなか予定通りに進まなくなってきた。
加えてチーム全体で見ても、計画通りに進まなくなっていた。「ウオーターフォール式の開発の終盤になって初めて『実は、できませんでした』となったり、無理やりスケジュールに合わせた結果品質が落ちたり、といった課題が生まれていました」
マネジメント関連の書籍から得た知識に加え、ちょうどそのころチームに加わった大塚正道さんの意見も取り入れながら、開発プロセスを変えた方がいいと考えて導入したのが、「反復開発」というやり方だった。
プロジェクトを「1週間のタイムボックス」に分割し、そのタイムボックスの中で計画、実行、振り返りを行い、繰り返していく開発手法だ。ピンとくる人も多いだろうが、スクラムの考え方を参考にしている。既に進んでいるプロジェクトへの影響を最低限に抑えながら、開発が計画通り進まない課題のカイゼンを模索した結果たどり着いたやり方だ。
こうした言葉で表現した理由の一つには、「いきなり『スクラムでやりましょう』と言ってしまうと、本当にうまくいくのかと周りから身構えられるし、完全に導入しようとすると現場の負荷も大きくなります。そこで、身の丈に合った形で、部分的に導入を始めました」という狙いがあった。
タスクをアサインされた個人の集まりから、目的を共有した「チーム」に
さて、反復開発を導入して、チームはどう変わっただろうか。1週間のタイムボックスの中で何をやるかを話し合って計画を立て、優先順位を付けて作業を進め、皆の記憶が鮮明なうちにしっかり振り返りを行う。同時にカンバンを導入し、今の状況を可視化するようにした。
この結果、以前は「人」単位でアサインされていたタスクが、「チーム全体」にアサインされる形になった。そして、チーム全員で同じ課題に取り組むことにより、これまで一部のメンバーに属人化していたスキルやナレッジをチームで共有し、若いメンバーが開発しながら成長していけるようになった。
また、以前は担当者任せだったスケジュール管理も、カンバン方式に変えてチーム全体で「見える化」したことにより、どこが予定通り進んでいて、どこがうまくいっていないかが一目瞭然になった。カンバン上になかなか移動しない付箋があれば、他のメンバーから「どこで悩んでいるのか」と声を掛けたり、協業したりできるので負荷が分散したという。
「以前はリスケ、リスケでしたが、反復開発を導入したことで安定して開発ができるようになり、スケジュール通りリリースできるようになりました。もう一つの大きな効果は、チーム内で意見が言いやすくなったことです。『モブプログラミングに挑戦したい』とか、『テストを自動化してみよう』といったさまざまなカイゼン提案が出てくるようになりました」
以前はなるべく人の手が空かないように仕事を割り振る、リソース優先のマネジメントに走りがちだった。例えるならば、ピースの大きさや形も考えず、やみくもに空いた部分に当てはめていくジグソーパズルのような感じだったそうだ。
だが、「反復開発という形で、毎週のようにチーム全員で仕事を見積もり、1週間後のゴールを決めて開発を進めていくことにより、意見を言い出せるし、問題があればカンバンですぐに分かります。心理的に安全を保障した形で進めていけていると思います」と吉元さんは話す。おのおのが黙々と作業に集中していたチームの空気も一変し、「にぎやかになりました。おしゃべりというより、どうすればいいものができるかという仕事の話がしやすい環境になりました」とも、吉元さん。
より多くの成果をチームとして生み出し、見本になるような存在に
今は、「開発時にこういうところが落とし穴になりがち」といった吉元さんのナレッジを少しずつ若手エンジニアにアドバイスしながら、チーム全体の力を高めていこうとしている段階だ。
エンジニアの例にもれず、吉元さんも「技術には興味があるけれど、マネジメントはちょっと……」と敬遠していた。けれどチームの立て直しを進めていくうちに、マネジメントの面白みを感じてきたという。
「個人でいくら頑張っても、生み出せる成果はたかが知れていますが、チームでやり方を変えれば違います。その意味で、マネジメントも面白いなって思いました」
まだ社内の他のチームに比べれば遅れている部分が多いと感じている吉元さん。「その分伸び代はあるし、効果も大きくなると思います」と、新たな取り組みを進め、いずれは「他のチームの見本となるようなキラキラしたチームにしていきたい」と宣言している。
吉元さんが「キラキラしたチームにしていきたい」と語るチームの将来像について、チームマネジャーの大塚正道さんに聞きました。
Copyright © ITmedia, Inc. All Rights Reserved.
拡大する中小企業向けSaaSの開発チームが取り組む、新しいエンジニアチームのモデルとは提供：株式会社ラクス
アイティメディア営業企画／制作：＠IT自分戦略研究所 編集部／掲載内容有効期限：2020年4月29日
