開発プロセスを改善してみた

前数ヶ月は大規模な機能のリリース時期でした。次のプロジェクトに進む前には特に大きな開発はなく、主に小さなバグを修正し、既存の機能の改善に取り組んでいました。開発がそれほどタイトではなかったため、この季節はプロセスの改善にもっと集中する時間がありました。

背景

まず、開発中に直面した状況についてお話ししましょう。各チームや組織で直面する問題は異なるため、背景を理解し、改善したい問題を把握することは非常に重要です。今回の開発において明らかに問題を引き起こしていた状況はいくつかあります。

組織に関わる人が多い

私が現在参加しているのは金融関連の開発で、FX（外国為替）、株式、投資信託などのプロダクトがあります。比較的大きな機能は別途処理されることが多い（例えば、FXは別のアプリを開発）ですが、大部分の機能は同じウェブサイトの下で実装され、各プロジェクトを担当する開発チームが処理します。これにより：

• 共有モジュールに手を加えるたびに複数のチームが関与し、メンタルの負担が大きくなります。コードを変更すると壊れるのではないかと心配し、問題を直視するのではなく回避策を選びがちです。
• 複数のプロジェクトが並行して開発されている場合、衝突が起こりやすくなります。例えば、プロジェクトAでデスクトップ版を実装したが、同時に進行中のプロジェクトBではまだ実装されていない場合、両プロジェクトの統合時に衝突が発生します。

チームがすべてのリソースを把握できない

例えば、QAの際にはすべてのプロジェクトのスケジュールに合わせる必要があり、QAのリソースは限られているため、機能が早く完成していても、QAを行うまでに1ヶ月、2ヶ月待たなければならないことがあります。このコストは非常に高いです：

• 開発者は1、2ヶ月後には実装の詳細を忘れてしまい、思い出す時間を費やさなければならない。
• QAが問題を提起してから修正する際、全体の反復プロセスが非常に長くなります。
• 特定のAPIや実装が他のチームの修正を待たなければならず、相手のスケジュールを把握できないため、チームの開発進度が停滞します。

複雑なQA環境

理想的には、QA環境は一つだけであるべきです。

しかし、プロジェクトが並行して進行し、テスト環境が限られている中で、新たなテスト環境を構築するコストが高い場合、QAが二つの環境で同時に行われることがあります。テスト環境が不足する中で、開発とQAが同じ環境を共有することは、いくつかの問題を引き起こします：

• QAが問題に直面した際、それが本当にバグによるものか、開発者が新機能をテストしているのか分からなくなります。
• QA環境の不足がコミュニケーションコストを非常に大きくします。チームが大きいため、連絡を取るチャンネルも非常に多くなります。
• テストアカウントの準備プロセスが煩雑で、各環境にはほとんどが不完全または使用できないアカウントがあります。

不完全なスプリント

現在、チームはScrumを使って開発していますが、前のプロジェクトを離れて以来、Scrumが非常にスムーズでなくなっていることに気づきました。考えられる原因は以下の通りです：

• チーム内には異なるプロジェクトを担当するエンジニアもいて、Sprint Goalが形骸化している。
• QAリソースを調整できず、テストを進めることができない。
• 進捗の追跡が不十分で、優先順位がAであるはずなのに、同僚がBを進めていることがよくあります。
• 明確な目標や反復がない。

このような状況から、チームが理想的なスプリントに必要な条件を満たしていないかもしれません。多くのリソースが他のところに拘束されている状態では、スプリントが最適な選択肢ではないかもしれません。

改善プロセス

大部分の問題は開発側で解決できないものであるとはいえ、開発環境に関しては何らかの対処ができると考えています。

改善を進める際、まず動機と達成したい目的を考える必要があります。そこで、第一歩として現在直面している問題と可能な解決策を簡潔にまとめた文書を準備しました。

主な目的は以下の通りです：

• 開発チームが異なるブランチのコードを自由に切り替えられるようにすること。これは非常に重要です。なぜなら、私たちの開発チームが担当するプロジェクトは異なるため、同時に複数のプロジェクトが進む中で時々「環境を貸して、テストが終わったら返すよ」となることがあるからです。
• QAと開発チームが同じ環境を共有しないようにすること。これにより、問題が発生してもその原因を確認できない状況がなくなります。

この文書を作成した後、チーム内での議論を始めました。この議論にはいくつかの目的がありました：

• 皆が似たような問題を抱えていることを確認し、互いの状況を理解すること。
• 同僚にとっては、彼らも異なる考慮点を持っており、これらの考慮点が改善をスムーズに進めるかどうかの鍵になること。
• 意見を出し合い、私の考えに欠陥があるかもしれないので、皆の考えを集めればより良い解決策が見つかるかもしれません。

実装よりも、全体的な改善プロセスに重点を置きたいと思っていましたが、ここでは私の実施方法について簡単に説明します：

• フロントエンドはSPAを実行しているため、ビルドしたJavaScriptをアップロードするだけで異なるブランチのコードを自由に切り替えられます。これにより、開発はQAと環境を共有する必要がなくなり、異なる開発チームも自由に環境を切り替えられるようになります。
• クエリパラメータを使用して異なる環境を切り替えますが、クエリパラメータを常に保持するのは面倒で、特にアプリにはリダイレクトのロジック（例えば、支払い後のリダイレクトページ）があるためです。
• deploy preview（Netlifyに似た機能）を実装し、PRを提出するたびに開発チームが直接URLをクリックしてデモを見ることができるようにします。

整理を進める中で、これらの方法にはいくつかの問題があることが分かりました：

• デプロイ時にフロントエンドで別のnode.jsサーバーを実装し、簡単な認証サーバーやいくつかのAPIを提供する必要があります。したがって、純粋なフロントエンドだけではなく、ファイルアップロードの方法は誤解を招きやすく、変更が必要なコードベースも大きくなり、反発を招く可能性があります。
• deploy previewは動的DNSのサポートが必要ですが、社内ではプライベートクラウドを使用しており、APIが利用できるかどうかは不明です。また、ログイン機能などは他のページにリダイレクトしてSSOを行うため、実装上ドメインに制限があり、deploy previewで生成されたドメイン名が拒否されてログインに失敗することがあります。ログイン不要な機能にとっては確かに有効ですが、コストパフォーマンスが合わない効果的ではない結果となります。

その途中、別のエンジニアも同様の問題を感じ取り、改善プロセスに自発的に参加してくれました（最初は孤軍奮闘することになると思っていました）。彼と一緒に問題を整理し始めました。最初にdeploy previewの概念を説明すると、彼は理解し、既存の提案に新しいアイデアを提示しました。

「動的DNSのコストは高いので、nginxを使ってリダイレクトを行うのはどうですか？」

現在のデプロイ方法に基づいて、新しいマシンを新たに構築し（社内プライベートクラウドで数回クリックするだけでできます）、既存のマシンのnginxにリダイレクトロジックを追加します。

特定のクッキー値がある場合は開発用のマシンにリダイレクトし、ない場合はそのままにします。こうすることで、元のコードベースには一行も変更を必要とせず（JenkinsスクリプトやAnsibleスクリプトを少し変更する程度）、元のデプロイ方法を再利用できるため、開発コストが大幅に削減されます。

このようにして提案が決まり、その後他のチームの意見を尋ねましたが、基本的に皆は前向きな態度を示しました。最後にSREチームに確認しても問題ありませんでしたので、全体の実装が終わりました。

改善後

正直なところ、ただの文書では実質的なものを感じるのは難しいですが、デモを見てもそうです。しかし、実際に使用してみて初めて感じるものがあります。皆が新しい環境切り替え機構を使い始めると、好評を得て、本当にプロセスが改善されたことを実感しました。

所感

この改善プロセスには、合計で三ヶ月以上かかりました。関与するチームが多かったため、時間がかかりました。最初は焦らずに進めることが重要で、そうしないとチームの理解を失いやすくなります。この過程で私も多くのことを学びました。

1. まず文書を書く

文書を書くことはチームの共通理解を築く第一歩です。文書作成の際には、実装方法に過度に重点を置くのではなく、問題解決や可能な解決策に焦点を当てて、チームからより良い提案を引き出すことが重要です。これにより、チームはこの提案が自分一人のものではなく、みんなで話し合って生まれたものであると感じることができます。

2. 個人ではなく全体を基にする

この改善が良い評価を得られた理由の一つは、この問題が私一人のものではなく、チームの多くの人が同様の痛点を抱えていたからです。改善を進める際には「こう書いた方が楽だから」「この技術に慣れているから」といった個人的な理由だけでなく、これらの改善が本当に利益をもたらすかどうかを考えなければなりません。そうすることで、他の人々が支持してくれるでしょう。

3. 技術に過度に執着しない

正直なところ、今回は特に技術的な要素は使っていません。単なる条件分岐を追加しただけですが、全体の効用は非常に高いです。多くのエンジニアは技術そのものに過度に執着しがちですが、解決すべき問題を見失うことがよくあります。技術は人間にサービスを提供するためのものであり、この事実を無視すると、技術そのものの意義が失われてしまいます。

4. 他のチームを恐れない

この改善には他のチームの協力が必要だったため、時には尻込みしてしまうことがあります。多くの人は面倒だと感じ、煩わしいことを避けたがりますが、自分の仕事を終えることに満足しているのです。しかし、問題と解決策を正確に説明できれば、多くの場合、他の人々はあなたを支持してくれます。時には相手の考慮点が障害に聞こえることもありますが、過度に推測する必要はありません。

5. 同じ志を持つ仲間を見つける

この改善が成功した大きな要因の一つは、当時一人のエンジニアがこの問題に興味を持っていたことです。彼はバックエンドエンジニアで、構造の面についてもより深く理解していたため、後のnginxの解決策に繋がりました。しかし、志を共にする仲間は出会うのが難しいので、出会ったら大切にしていきたいと思います。