本記事はリンクアンドモチベーション Advent Calendar 2023の15日目です🎄
[ はじめに ]
こんにちは！リンクアンドモチベーションの鵜木(@nokki_y)です！
本日は今年のVue Fes Japan 2023で発表した『 価値を生む技術提案 ~フロントコードのリライト事例から学んだ提案の重要性~ 』について、その題材となったプロジェクトでの失敗経験をチェックリスト形式でまとめました。
リライトやリアーキを推進する際の参考にしてみてください！
注意事項
本記事は、リライトプロジェクトの失敗談を題材にしますが、プロジェクト自体は失敗を乗り越えて成果が出ています。このあたりの詳細はVue Fes Japan 2023で発表したスライド内にあります。
また、これは学術的根拠や有名な著書に基づくものではありません。実際に起きた失敗談から作成したリストなので、主観が含まれる部分もあるかもしれません。ご注意ください。
※スライドタイトルが『Vue.jsを活用して開発リードタイムが1/3になった話』になっていますが、内容は『価値を生む技術提案』になります。
[ チェックリスト ]
- 提案・計画
- 設計
- 実装
- 展開
-- 提案・計画
リードエンジニアの工数が十分に確保されているか
私たちのプロジェクトでは、私がリードエンジニアを務めながら他チームのマネジメント業務も兼任した結果、工数が圧迫され、プロジェクト開始直後にスケジュールの遅延が発生しました。
リードエンジニアに他の業務を兼務させたくなる気持ちは理解できますが、リライトプロジェクトは負荷が非常に大きくなる傾向があります。
リードエンジニアの能力に依存する部分もありますが、リードエンジニアの負荷が高くなる場合は、専任での担当が望ましいと思います。
定量的な目標が定められているか
私たちのプロジェクトは目標を定めずに開始し、結果としてアーキテクチャの品質評価が難しくなり、プロジェクトの優先順位や失敗時の軌道修正の方向が不明確になりました。
目標設定にプレッシャーを感じることもあるかもしれませんが、この目標がプロジェクトの進行方向を示すものです。そのため、納得でき、意味のある目標設定に努めることをおすすめします。
実行責任者(リードエンジニア)と説明責任者が別々にアサインされているか
リライトプロジェクトは多くのリソースが必要とされ、そして期間の長いプロジェクトになる傾向があります。そのためマネジメントレイヤーへの状況説明を求められる機会が何度もあります。
このとき、組織の規模によって異なりますが、リードエンジニアによる各マネジャーへの状況説明が負担となる可能性があります。その場合、説明責任者を別途設けることをおすすめします。
実際に私たちのプロジェクトでは、途中からグループのマネジャーが説明責任を引き受け、リードエンジニアはグループマネジャーへの状況説明のみに集中することで、負担が軽減されました。
仕様が明確な既存機能から新しいアーキテクチャを適応する計画になっているか
私たちのプロジェクトでは、新しいアーキテクチャを新機能の開発で初めて適用しました。しかし、その新機能の仕様が複雑だったため、開発チームは新しいアーキテクチャの不確実性と新機能の不確実性の両方に取り組む必要があり、大きな混乱が生じました。
新しいアーキテクチャは多くの不確実性を内包しているため、初回適応では仕様が明確な既存の画面から始めることをおすすめします。
いきなり正解を作るのではなく細かく改善を繰り返す前提・計画になっているか
リライトプロジェクトは、初回のリリースがゴールではなく、新しいアーキテクチャを通して開発生産性を向上させることが目的となります。
しかし、一回の設計で最適なアーキテクチャを生み出すことは、なかなか難しいと思います。実装フェーズでの考慮漏れや、リリース後の運用フェーズでの不都合が往々にして発生します。
これらを解消し、開発生産性を高めるためには継続的な改善が必要となります。そのため、プロジェクトの初期段階から周囲との期待値調整では、継続的な改善の計画を含めておくことをおすすめします。
-- 設計
リードエンジニアの相談相手が明確になっているか
リードエンジニアの能力によって異なりますが、個人的にはリライトに伴う再設計は冗長な設計になり易いと考えています。リライトが必要な開発現場の状況を知ってしまっている分、新規でアーキテクチャを設計する場合とは異なり、「次は同じような状況にしたくない」というような気持ちが生まれてしまうためです。
私たちのプロジェクトでも、リードエンジニアに相談相手がいない状態で設計された最初のアーキテクチャはとても冗長な設計になりました。しかし、相談相手を設定し再設計を行った結果、アーキテクチャは徐々にシンプルになりました。
目標達成に沿った設計となっているか
前述の「リードエンジニアの相談相手が明確になっているか」と重複しますが、リライトに伴う再設計は冗長になりがちです。
一方で、中・大規模システムのソースコードを再設計する場合、拡張性を無視することはできません。このとき、拡張性をどの部分に持たせるかは、設定された目標によって決まります。したがって、目標に沿った設計を意識することが非常に重要です。
-- 実装
チーム内のエンジニアからフィードバックを受ける機会が設定されているか
設計した人以外のエンジニアが実装する際に、初めて発覚するような設計上の考慮漏れは十分に発生する可能性があります。そのため、実装フェーズでのフィードバックを受け、それを改善に活かすことが大切です。
しかし、開発に携わるメンバーの多くは、新しいアーキテクチャの使用に意識が傾きがちで、その改善には注目しづらいです。そこで、新しいアーキテクチャの改善に意識を向けさせるためにも、フィードバックを得るための場を設定することをおすすめします。
-- 展開
展開先のチームに協力者がいるか
私たちのプロジェクトでは、新しいアーキテクチャの初期リリース後、他のチームへの全体的な展開時に、新しいアーキテクチャが十分に利用されていない状況に直面しました。理論上、新しいアーキテクチャは開発の生産性を高めると認識されていましたが、実績がほとんどなく、不確実性が高いため、各プロジェクトで懸念が生じていました。その結果、生産性は低いものの確実性が高い既存のアーキテクチャが選ばれる傾向にありました。
この状況を変えるためには、新しいアーキテクチャがなぜ必要か、そしてそれが開発組織の目指す未来にどう貢献するかを、背景とともに何度も説明する必要がありました。しかし、一人で全員にこれを繰り返し伝えることは現実的でありません。そのため、啓蒙が必要な場合は、各チームのリーダーを中心に協力者を作ることをおすすめします。
展開先のエンジニアからフィードバックを受ける機会が設定されているか
前述の「チーム内のエンジニアからフィードバックを受ける機会が設定されているか」はアーキテクチャの設計に対するフィードバックが中心となりますが、こちらはアーキテクチャの使い方に対するフィードバックが中心となります。
私たちのプロジェクトで、新しいアーキテクチャが浸透しなかったもう一つの要因は、キャッチアップが難しいことでした。一応、展開当初からアーキテクチャのガイドラインを用意していたものの、高いキャッチアップコストの問題は容易には解消されませんでした。
この問題に対応するため、私たちは各エンジニアから新しいアーキテクチャに関するフィードバックを収集し、開発状況を観察しながら改善を重ねました。（まだ試行錯誤の段階ではありますが）現在はチュートリアル形式のドキュメントとスキャフォールド(Scaffold)を整備することで、エンジニアが新しいアーキテクチャをより理解しやすくなるよう努めています。
[ さいごに ]
生成AIの発展により、日々の開発業務が少しずつ楽になっていると感じる一方、今回のような不確実性の高い業務はなかなか楽にならないな、と感じています。
今回、自分たちのリライトプロジェクトを振り返り収集したチェックリストは、ここに挙がった項目をすべて解消すれば、必ず成功する、というようなものではないですが、それでも何らかの形で誰かの役に立てばいいな、と思っています。