失敗を分析して分かった4つのポイント
佐藤氏は失敗の原因を分析し、影響度の大きかった4点を挙げた。1つ目に「デリバリー優先で、人の時間と心を犠牲にしていたこと」を指摘し「最速でマーケットに価値提供するために、QCDのCは一旦無視して、最低限のQを保ちながら、Dに全部振っていた」と振り返る。これにより、運用の負債が残ってしまい、顧客が設定を変更する際などに開発の手作業が発生することもしばしばだった。なにより、プレッシャーと時間に追われて開発メンバーの心が疲弊していた。
「当時は、できる・できないではなく『やる』前提で、どうやったら実現できるのかだけを徹底的に考えていた。そのやり方が悪いわけではないが、代わりに犠牲にしていたものを理解できていなかったのが反省点です」（佐藤氏）
2つ目には、「属人的で高い能力を前提とした開発プロセス」を挙げた。当時は要件定義から優先度の判断まで、すべて個人で行っていた。これはもちろん、ビジネスの状況やプロダクトの構成を理解していることが前提となる。「場合によってはウルトラCの解決方法を発案してようやく対応できることもありました」と佐藤氏。タイトな開発スケジュールの中で問題が起きても即時解決して、なんとか巻き返す。これを「個」の力だけに頼って行っていたのだ。あまりに属人的なので、自分で一通りできるようになるまでのハードルが高い。よって、メンバーは疲弊し自己効力感も上がりにくかったという。
3つ目に、「プロダクトの全体像を把握しづらかったこと」を挙げる。先ほどのグラフにあった通り、2021年から一気に機能を増やしていった。この時、「1人1プロジェクト」の形で開発しており、各々の判断で実装していた。その結果、知らない間によくわからないディレクトリが作成されるなど、プロダクト全体を把握しづらい状況が発生していたという。
最後の4つ目に、「脆いアーキテクチャ」を挙げた。プロダクトの全体像がわからないまま機能リリースと修正を続けた結果、絶妙なバランスで実装が成り立っていた。そのため、バグを直すための修正が、さらに新たなバグを生んでしまう状態だった。これも開発メンバーの疲弊につながったという。
