開発チームが20人から4人に、殺伐とした開発環境で気づいたこと
株式会社ビットキーの佐藤拓人氏は、Home事業部でテックリードやエンジニアリングマネージャーを務める。同社は、「テクノロジーの力であらゆるものを安全で便利に気持ちよく『つなげる』 」をミッションに掲げ、2つの事業部を抱えている。佐藤氏の所属するHome事業部は、スマートロックを中心に、暮らしをつなげるコネクトプラットフォームを目指してソリューションを展開している。
Home事業部は、2021年から2022年にかけて、事業の拡大に伴い開発チームのスケールを図ったが、1年半後にはスケールするどころか当初の20分の4人しか残っていなかった。
当時は事業フェーズとして、0→1から1→10へと転換する変革期だった。その中での開発リソース不足で、厳しい開発になってしまったという。当時の体制では最低限の機能開発はできても、継続的にプロダクトを進化させていくことは難しい。
佐藤氏はこの「魔の1年半」で、「世の中に対して価値を継続的に提供するためには、持続可能な開発が重要だと気づいた」と話す。とはいえ現在の開発チームは、殺伐とした開発から脱却し「和気あいあいとしている」という。
どのように持続可能な開発チームへと進化したのか、失敗を分析して実行した改善策を詳しく解説した。
失敗を分析して分かった4つのポイント
佐藤氏は失敗の原因を分析し、影響度の大きかった4点を挙げた。1つ目に「デリバリー優先で、人の時間と心を犠牲にしていたこと」を指摘し「最速でマーケットに価値提供するために、QCDのCは一旦無視して、最低限のQを保ちながら、Dに全部振っていた」と振り返る。これにより、運用の負債が残ってしまい、顧客が設定を変更する際などに開発の手作業が発生することもしばしばだった。なにより、プレッシャーと時間に追われて開発メンバーの心が疲弊していた。
「当時は、できる・できないではなく『やる』前提で、どうやったら実現できるのかだけを徹底的に考えていた。そのやり方が悪いわけではないが、代わりに犠牲にしていたものを理解できていなかったのが反省点です」（佐藤氏）
2つ目には、「属人的で高い能力を前提とした開発プロセス」を挙げた。当時は要件定義から優先度の判断まで、すべて個人で行っていた。これはもちろん、ビジネスの状況やプロダクトの構成を理解していることが前提となる。「場合によってはウルトラCの解決方法を発案してようやく対応できることもありました」と佐藤氏。タイトな開発スケジュールの中で問題が起きても即時解決して、なんとか巻き返す。これを「個」の力だけに頼って行っていたのだ。あまりに属人的なので、自分で一通りできるようになるまでのハードルが高い。よって、メンバーは疲弊し自己効力感も上がりにくかったという。
3つ目に、「プロダクトの全体像を把握しづらかったこと」を挙げる。先ほどのグラフにあった通り、2021年から一気に機能を増やしていった。この時、「1人1プロジェクト」の形で開発しており、各々の判断で実装していた。その結果、知らない間によくわからないディレクトリが作成されるなど、プロダクト全体を把握しづらい状況が発生していたという。
最後の4つ目に、「脆いアーキテクチャ」を挙げた。プロダクトの全体像がわからないまま機能リリースと修正を続けた結果、絶妙なバランスで実装が成り立っていた。そのため、バグを直すための修正が、さらに新たなバグを生んでしまう状態だった。これも開発メンバーの疲弊につながったという。
持続可能な開発のために、4つの改善策とは
4つの要因に対して、どのような改善策をとったのか。佐藤氏はそれぞれに対して実際に行ったアクションを紹介した。
まず1つ目に、デリバリー優先から人優先へと方針転換した。佐藤氏は「デリバリー優先はビジネスを前に進めることができ、リリースしたら喜ぶ人も多い。自分もベンチャー出身で、難しいことに挑戦しているのだから仕方ないという意識があったが、これがよくなかった」と省みる。
そこで、開発チームとしてはどんなチームを目指すのか、中長期的な目線を意識するようにした。また、チームだけでなく会社として人を優先するべきだという発信を強く行った。
そして「やりたい」「やりたくない」という気持ちを大切にすることで、「人優先」の開発を実現した。例えば、メンバーが「なぜこれをやらなければいけないのかわからないから、やりたくない」という状態はありがちである。この場合、ビジネス的な意図が伝わっていないことが多いので、適切に説明することが重要だ。また、そもそもやらなくてよい問い合わせ対応などの作業については、削減するための改善活動を定期的に行っている。そのうえで、「やりたい」を創造するための活動に取り組んでいる。
「開発者は『こういう技術がやりたい』という興味を持っていることが多い。仕事の開発とは別に、興味のある技術について議論する技術研究会を定期的に開催しています。目指すは、疲弊しない楽しい開発です」（佐藤氏）
2つ目に、「属人的で高い能力を前提とした開発プロセス」に対する改善策として、自立可能なプロセスへ移行したと説明した。当時の反省点として、佐藤氏は「元々スクラムを用いた開発をしようとしていたが、高いデリバリーを実現するために、各々の裁量でよろしく実行していた」ことが問題だったと振り返る。結果、「チーム開発ではなく、個人開発の集合体」となってしまっていた。
そこで、属人的な開発プロセスから脱却するために、スクラムを再導入するというシンプルな改善策をとった。ここで重要なポイントは「効率ではなく、自律可能な状態になるかを優先すること」だと佐藤氏は強調する。目先の効率を追い求めてデリバリーを最適化すると、中長期的には属人化につながり、問題が発生するからだ。
3つ目に、プロダクトの全体像が把握しづらい問題に対する改善として「メンタルモデルの醸成」を挙げた。属人的な開発を重ねた結果、自分の実装した領域以外がどのような背景で作られ、どのような処理になっているのかわからない状態になっていた。ここで問題なのは、「単に知識として共有されていないだけでなく、考え方の素地がそろっていないこと」だと佐藤氏は語った。
具体的なアクションとしては、モブプログラミング（以降、モブプロ）やイベントストーミング、sudoモデリングなどを実施し、特定のフォーマットに沿って情報を共有整理できるようにした。また、クリーンアーキテクチャや実装のポリシーを整備することで、ディレクトリ構成や責務の認識を合わせた。そうすることで、新しい開発や修正が発生した時に「こういう構造になっているからここに追加すればいい」という判断が最速で実現できるようになったという。
最後の4つ目に、脆いアーキテクチャを改善するための「壊れにくい仕組みづくり」を紹介した。当初は、ロジックが散乱していてどこかを修正したら思わぬところにバグが出るという状態だった。この原因は疎結合・高凝集が実現されていないこと、実装の構成に一貫性がないことだったと佐藤氏は振り返る。また、インターフェースがわかりづらいことも問題だった。再利用性を高めるためにさまざまなオプションを指定できるようになっていたり、メソッド名と中身が異なったりという複雑性があった。
これらの課題を解消するため、ドメイン駆動設計（以降、DDD）の実装パターンを利用し、特定のルールが必ず適用される仕組みにした。また、インターフェースの精査を行い、特にAPIやコアなドメインを優先度高く改善するようにした。インターフェースについてモビングで議論・実装する場も用意したという。
この「壊れない仕組み作り」は、「3つ目のわかりづらさの解消と対になっている」と佐藤氏は語る。モブプロなどを通して概念や考え方を共有して、共通認識をとっただけでは、他の見えないところで予期しないロジックが働いている可能性は残る。
「ロジックでちゃんと守られていて、特定のルールが必ず適用されている状態を実現したうえで、メンバーの共通認識もそろっていると、認知負荷を下げた開発ができると思います」（佐藤氏）
佐藤氏は改めて「魔の1年半」を振り返り、「もともとのやり方が全くだめだったとは限らない」と話す。例えば、0→1のフェーズであればデリバリー優先の戦略をとることが最適かもしれない。その中で反省点は、「やり方が複数あってそれぞれにメリット・デメリットがあると理解していなかったこと」だと佐藤氏。当時のやり方が絶対よいと思い込み、フェーズが変わる節目にもかかわらず、その変遷に合わせて使い分けられなかった。その失敗から、チームやフェーズに応じた方法を使い分ける柔軟性が必要だという教訓を得た。
佐藤氏は「疲弊しない、持続可能でハッピーな開発ライフを目指して、この知見を活用していただけたらうれしいです」とセッションを締めくくった。
