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