介護や医療、ヘルスケアなどの領域で、高齢社会に適した情報インフラを提供している株式会社エス・エム・エスの西村直人（@nawoto）です。私は2005年からソフトウェア開発においてアジャイル開発を実践しており、現在はアジャイル開発の考え方を軸にチーム開発の支援などを行っています。

エンジニア組織ではリリースを頻繁にできることが望まれますが、リリースすることに疲れたりしませんか？僕たちは「リリース疲れ」と呼んでいますが、疲れが溜まるようにどんどんリリースが辛いものに感じてきます。エンジニア以外に言ってもあまり理解してもらえませんが……。

そんな悩みを解決するべく、エス・エム・エスの開発チームで行ったのは、レゴを組み立てること。え、なんでレゴ？そんな「リリースレゴ」という取り組みについてご紹介します。

プロダクト開発を継続すると起こる「リリース疲れ」

事業は長く継続していくように構築されているもの。なので、ソフトウェア開発は一度リリースしたら終わりではなく、継続してお客様が利用できるよう、エンジニアは改善や改修のリリースを重ねていきます。

初回のリリースこそ達成感に満ちあふれますが、それ以降の機能改善のためのリリースはだんだんと日常化し、淡々とした作業になりがちです。いつしか「このリリースはきちんと事業に貢献できているんだろうか？」と、自分の仕事が事業に役立っているか疑問が生じるようになっていきます。

しかも、リリースは前向きな気持ちで臨めるものだけではありません。提供し始めてからの期間が長くなれば、リリースの中には古くなった機能の廃止や、苦労して導入したけれどあまり利用されなかった機能の停止などのリリースも増加していきます。こうしたリリースは、同じリリースでも前向きな気持ちで行うのは難しいものです。

時には、あまり利用されなかった機能を廃止するなどのリリースによって、一部のお客様にご迷惑をおかけすることが続き、リリースに対して恐怖心が芽生えてしまうエンジニアもいます。

こうした出来事が生じることもあり、継続してソフトウェアを提供していくと、「リリース疲れ」を起こします。仕方ないこともありますが、終わりのないリリースに士気が下がっていってしまう開発チームもありました。

「継続して良いソフトウェアを提供するために、この悪循環をどうにかできないか？」と悩んだシニアエンジニアと、さまざまな策を検討していたとき、ふと、かつての現場で行っていた「バグレゴ」を思い出しました。

バグレゴとは、バグが出てしまったときに、ブロックの「レゴ」を組み立てるというもの。これを応用して、リリースした分だけレゴをチームの皆で組み立てていったらどうだろうか？と提案。さっそくやってみることにしました。

「リリースレゴ」で開発現場に生まれたポジティブな変化

社内では「リリースレゴ」と名付けて、リリースのたびにレゴを組み立てています。リリースレゴのやり方は、以下の通りです。

①レゴを購入する。最終的に形になる「作品シリーズ」がおすすめ
②プロダクトをリリースをする
③レゴの手順書を見て、リリースした数だけレゴを組み立てる。先の手順は見ない

リリースレゴを実践してみたチームでは、リリース報告を夕方の定例MTGで行っていたので、そのMTGで手順に沿ってレゴを組み立てていきます。その日のリリースが1個であれば、レゴも手順に沿って1段階分だけ組み立てます。先の手順は見ないので、最初はどの部分を組み立てているのかすら分からない状況でした。

「これ何の部分だか全然分からないっすね」
「もっと早めにリリースできるものあった気がするね」

といった会話が生まれ、チームはリリースに前向きな気持ちに。今までは保守的に計画して週に1つずつリリースしていたのが、来週は2つリリースしよう、機能をなくすような後ろ向きなリリースも早くやってしまおう、という言動が見られるようになりました。

リリースしてレゴのブロックを積むという作業を1ヶ月〜2ヶ月続けた結果、やっとレゴの作品が完成。

完成したレゴを見たチームメンバーから、次はもっと大きな作品に挑戦したいなどの前向きな言葉も出てきて、リリースを楽しめる雰囲気が醸成できました。その結果、リリースの数はこれまでの2倍以上増え、後ろ向きなリリースだけでなく機能を改善するようなリリースも多く出るようになりました。リリースレゴを導入したことで、チームパフォーマンスが明らかに向上したんです。

たまたまレゴを選んだのですが、結果的には正解だったと思います。手順書の先を見ずにレゴを一つひとつ組み立てていくと、最初はいったい何を作っているのか把握できません。ですが、レゴの入っていたパッケージを見れば最終形態が分かるので、完成した状態を思い描きながら進んでいけます。このレゴづくりの体験は、ソフトウェア開発にも通じるところがあると感じました。

ソフトウェア開発も、いま自分の行っている仕事の成果が見えにくくなることがあります。リリースを重ねることによってプロダクトが成長し、事業にも貢献していることは確か。しかし、それは目に見えません。自分たちが積み重ねてきたリリースをレゴによって可視化し、貢献した軌跡をポジティブに捉えられる取り組みは、チームにとってプラスだったのではないかと思います。

※リリースレゴについては、当時のチームメンバーの寄稿したコラムが拙著『SCRUM BOOT CAMP THE BOOK【増補改訂版】』に掲載されているので、もっと詳しく知りたい方はぜひそちらも参照してみてください。

感情面も含めて合理的に考え、チームで学びをシェアする文化

「よくレゴを使ったアプローチなんか許されたね」
「遊んでるだけって思われなかったの？」

と気になる人もいるかもしれません。社内ではレゴを使った取り組みに対して難色を示す人はいませんでした。なぜなら、社内にはチームのパフォーマンスを最大化したい、という考えが広く浸透しているからです。

開発のパフォーマンスを最大化していくためには、「仕事に対する手触り感」や「恐怖心に向き合う」など、直接は仕事の成果につながらなさそうなことでも課題として捉え、解決していくべきだと考えています。そのために、開発の現場の最前線にいるエンジニアが解決策を考え、実行する自由があります。

あと、社内には、成功体験やノウハウを共有し、それを他のチームが積極的に真似するという文化があります。ある日、チームメンバーが社内Wikiであるesa内の広報エリアに、制作途中だったレゴの画像を載せたところ、他のチームから反応がありました。しばらくすると、いくつかのチームでリリースレゴに取り組み、ポジティブなコミュニケーションをする光景があちこちで見られるようになりました。

何事も相談しやすい雰囲気があって、自由に改善でき、成果の出た取り組みを他のチームでも活かせる会社の文化。この文化があるからこそ、エンジニア組織は強くたくましくなっていくのだと思います。