【デジカルチーム ブログリレー3日目】
こんにちは、デジカルチームでソフトウェアエンジニアをしている穴繁です。
長年開発を続けてきたサービスを運用していると、「そろそろアレもコレも新しくしたいなぁ…でもサービスは止められないし、どう進めたものか…」なんて頭を悩ませることはありませんか？
今回は、まさにそのような状況で私たちが実践した「開発を止めない段階的フロントエンドリプレイス」について、計画・技術・組織という3つの観点からご紹介します。
これまでの計画編、技術編では、リプレイスプロジェクトの全体像や、それを支えた技術的な取り組みについてお話ししました。
www.m3tech.blog www.m3tech.blog
最終回となる本記事（組織編）では、プロジェクトを推進する上でのチーム体制や、円滑なコミュニケーション、そして品質を維持するための取り組みなど、組織的な工夫についてお話しします。
フロントエンドチームの結成
今回のリプレイスプロジェクトを推進するにあたり、まず専門のフロントエンドチームをタスクフォースとして結成しました。通常、専門チームを常に設置しているわけではありません。しかし、今回のリプレイスはプロジェクトの規模や技術的な難易度を考慮し、例外的に専任チームを立ち上げるという判断に至りました。
このタスクフォースチーム結成には、いくつかの狙いがありました。
まず、旧技術スタックへの対応を専任チームに集約することです。リプレイスが完了すれば無くなる旧技術スタックについて、チーム全員が習熟する必要はありません。この課題への対応を専任チームに限定することで、組織全体の学習コストを最適化できると判断しました。
次に、リプレイスプロジェクトへ集中的に取り組める体制構築も重要な狙いでした。専任チームを設けることで、必要な工数を確実に確保することを基本方針としました。ただし、長期間にわたるリプレイス作業では、モチベーション維持や新たな視点を取り入れることも不可欠です。そのため、現実の運営においては、一定機能開発タスクを並行して担当したり、逆にリプレイスに興味を持つチームメンバーがフロントエンドチームに参加したりと、状況に応じた柔軟な対応も行いました。これにより、プロジェクトへの集中を維持しつつ、チーム全体の活性化も図るというバランスを意識して進めました。
また、少数のメンバーで設計から実装までをスピーディに進めることも重要な目的の1つでした。それに伴って、リプレイスプロジェクトにおけるコードレビューのプロセスも、フロントエンドチーム内で完結するように仕組みを整備しました。リプレイスの前提や必要な知識を共有したメンバー同士でコードレビューを実施することで、レビューの質を高め、コード品質の向上を目指しました。
リスク管理と認識合わせ
リプレイスプロジェクトを進めるにあたり、チーム内で潜在的なリスクを洗い出し、共通認識を持つことは重要です。その中で有効だった取り組みの1つに、プレモーテムの実施があります。
プレモーテムとは、プロジェクト開始前に「もしこのプロジェクトが失敗するとしたら、それはなぜか？」という問いを立て、考えられる失敗要因を事前に洗い出す手法です。
実際にプレモーテムで挙がった失敗シナリオには、次のようなものがありました。
- ユーザーの混乱
- UIの色調変更や、ボタン・ツールチップといった共通コンポーネントの使用感が変わることによる操作性の低下。
- これまで明確に仕様定義されていなかった箇所の挙動が変化し、ユーザーの操作性が突然変わってしまう。
- デグレ
- iPad Safariや特定のWindowsバージョンなど、限定された環境でのみ発生する不具合をリリース前に検知できない。
- リプレイスに伴う変更が原因で、既存機能にレイアウト崩れなどの視覚的な不具合が発生する。
- 工数の肥大化
- リプレイス箇所のQAコストが想定以上にかかり、診療報酬制度の変更対応など、重要な開発タスクに十分なリソースを割けなくなる。
- リプレイス作業が長期化し、途中でプロジェクト自体が中断してしまう。
これらの意見からも分かるように、特にリリースによるユーザー影響や、プロジェクト全体の工数に関する懸念が多く挙がりました。
プレモーテムを通じてこれらのリスクを事前にチーム全体で共有し議論できたことは、プロジェクトの方向性を定める上で有益でした。例えば、一度に大規模な変更を行うことのリスクを再認識し、より安全な段階的リプレイスという方針を固めることに繋がりました。また、品質担保の重要性についてもメンバー間の認識が一致し、VRT（Visual Regression Testing）の導入といった具体的な取り組みを推進する後押しとなりました。
情報共有と知識の継承
大規模なリプレイスプロジェクトを成功させるためには、チームとしての総合力を高めることが不可欠です。特に、情報共有と知識の継承は、チームがスケールさせる上で重要な要素となります。私たちのプロジェクトは、決して独力では達成できない規模であり、チームメンバー間の効果的な連携が求められました。
そのために、次のような取り組みを意識的に行いました。
仕様書の整備と一元化
リプレイス作業の第一歩は、既存機能の振る舞いを正確に理解することです。しかし、プロジェクト開始当初は、最新化されていない・フォーマットが揃っていない仕様書が一部ありました。
そこで、いい機会だと捉え、仕様書の最新化とConfluenceへの集約作業を進めました。これにより、誰でも最新の仕様にアクセスできる状態を目指し、認識の齟齬を防ぐ基盤を整えました。
技術設計の共有
複雑な技術課題に取り組む際には、多様な視点を取り入れ、チーム全体で最適な解決策を模索することが重要です。そこで、次のような方法で技術設計に関する情報を共有しました。
- ペアプログラミングの活用: VSCode Live Shareなどのツールを活用し、ペアプログラミングやモブプログラミングを積極的に行いました。これにより、リアルタイムでの知識共有や、コードを通じた具体的な議論が促進されました。
- ドキュメントによる共有: 重要な技術的判断や設計方針については、ドキュメントとして記録し、チーム全体で参照できるようにしました。具体的には、次のような内容を整備しました。
- 旧フレームワークやライブラリから新技術へ移行する際の方針
- 新たに採用するライブラリの選定理由と比較検討の経緯
- 開発フロー
- モノレポ内の各パッケージが担う責務範囲
- カナリアリリースを含むデプロイ戦略の詳細
- 丁寧なコードレビューの実践: コードレビューは、単にコードの品質を担保するだけでなく、知識共有や学習の機会としても有効です。特に、次の点を意識してコードレビューに取り組みました。
- 新たにチームに加わったメンバーや、リプレイスプロジェクトに直接関与していないメンバーにも変更の意図や背景が伝わるよう、丁寧な説明を心がけました。これにより、レビューを通じてプロジェクトへの理解を深めてもらうことを目指しました。
- コードレビューは、レビュアー・レビュイー双方にとって学びの機会であると捉え、建設的なフィードバックを奨励しました。技術的な知見だけでなく、設計思想やコーディングスタイルについても議論を深めました。
Working Out Loudの実践
日々の業務の中で発生する細かな疑問や困りごとは、放置すると大きな問題に発展する可能性があります。そこで、Slackに #digikar-front という専用チャンネルを作成し、「Working Out Loud」*1 を実践しました。
このチャンネルでは、設計に関する相談、実装で困っていること、発見したTipsなどを気軽に共有し、それに対して他のメンバーが迅速にサポートする文化が自然と醸成されました。このようなオープンなコミュニケーションは、問題の早期解決だけでなく、チームの一体感を高める上でも効果的でした。
これらの情報共有と知識継承の取り組みを通じて、チームとしての学習能力を高め、複雑なリプレイスプロジェクトを推進していく力を養うことができたと考えています。
品質をチームで守る
リプレイスプロジェクトにおいて、改めて、リリース時の品質担保は重要課題の1つです。そのため、QAチームはもちろん、エンジニア自身も品質に対する意識を高く持ち、積極的に関与していくことが求められます。例えば、パフォーマンスの劣化など、非機能要件に関するデグレは、実際にコードを書いているエンジニアの視点があってこそ気づけるものも少なくありません。
具体的なフローとしては、まずエンジニアが実装した機能に対する受入基準を作成します。この受入基準をQAチームがレビューし、テスト観点に漏れがないかを確認します。その後、テスト実施を分担して行いました。
エンジニアが担当するテストケースとしては、例えば、リリース作業中の中間的な状態で発生しうるデグレのチェックやエラー監視ツール（Sentry）が正しく機能しているかの確認などがありました。
また、QAチームのテスト工数が逼迫している場合には、エンジニアがUIレベルのE2Eテストの一部を担当するなど、状況に応じて柔軟に協力し合う体制で進めました。このように、チーム全体で品質を守るという意識を持つことが、大規模リプレイスを成功させる上で重要だったと感じています。
おわりに
開発を止めない段階的フロントエンドリプレイスの実践シリーズとして、計画編、技術編、そして今回の組織編と、計3回にわたって私たちの取り組みを紹介してきました。大規模なリプレイスプロジェクトは、技術的な課題を解決するのはもちろん、計画、チームビルディング、リスク管理、関係各所との連携といった多岐にわたる要素が複雑に絡み合います。
このプロジェクトを通じて感じたことは、当たり前ではあるのですが、やめなければいつかは終わるということです。他のタスクが忙しくとも、必ずリプレイスを少しずつでも進めることを継続しました。一方で、プロジェクト初期の基盤構築フェーズや、地道なコンポーネント移行作業中は、なかなか目に見える進捗が得られず、苦しい時期もありました。しかし、安全な領域を1つずつ着実に増やしていくことで、ある瞬間から急に進捗が加速し、ゴールが見えてくるという感覚をチームで共有できたことは大きな財産です。
そして、このようなリプレイスは、エンジニアの力だけでは成し遂げられないというのが個人的な学びでした。プロダクトマネージャー、デザイナー、QAエンジニア、サポートチームなど、多くの関係者の理解と協力があって実現できたものです。改めて、このリプレイスに関わって頂いた全ての方に感謝します。
最後に、今後の技術動向にも少し触れておきたいと思います。近年、AI技術の発展は目覚ましく、ソフトウェア開発のあり方も変わろうとしています。コード生成、テスト自動化、ドキュメント作成など、リプレイスプロジェクトにおいても、AIが強力なサポート役となる未来はそう遠くない...というか既に来ていそうです。私たちも、常に新しい技術トレンドを注視し、より効率的で質の高い開発を目指していきたいと考えています。
この記事が、同様の課題に直面している開発者の方々にとって、少しでも参考になれば幸いです。最後までお読みいただき、ありがとうございました。
We are hiring!
私が所属するデジカルチームでは、クリニックの診療を支えるクラウド型電子カルテであるエムスリーデジカルを開発しています。 開発チームの紹介資料もありますので是非ご覧ください！
また、エムスリーではエンジニアを絶賛募集中です。 興味を持って頂けた方、カジュアル面談や採用へのご応募をお待ちしています。
*1:Working Out Loudについては、こちらの記事に分かりやすくまとまっています: https://blog.studysapuri.jp/entry/2018/11/14/working-out-loud
