「ソフトウェア式年遷宮」
スキルマップをうまく運用しても、難しいスキルの継承はあります。プロダクト全体を横断するような文脈や、過去からの歴史的経緯によって選択された仕様に関する知識などです。また、スキルマップで失われつつあることが可視化されていても、システムの基幹部分に関することは手を入れづらく、スキル継承の機会をそもそも得られないこともあります。そこで、それらに対処するために「ソフトウェア式年遷宮」という考え方をご紹介します。
「式年遷宮」とは伊勢神宮などが有名ですが、神社などの社殿を維持するための手法です。20年ごとなどの一定の周期を定め、現在の社殿の隣にまったく同じ社殿を新しく建てます。それを交互に繰り返すことにより、長期間に渡ってまったく同じ社殿の姿を維持し続けます。周期性により、それを建築する宮大工のスキルも継承されていきます。
ソフトウェアの場合はまったく同じものを作り直す、というのは現実的ではなく、式年遷宮の完全なメタファーにはならないのですが、一定の周期で行われることが望ましい、という点と、エンジニアのスキル継承の観点で「式年遷宮」を参考にすべきところが共通しているので、ここでは「ソフトウェア式年遷宮」という名前をつけてこの手法を紹介してみたいと思います。
「ソフトウェア式年遷宮」とは
ソフトウェアを長期間運用していると、システムの根本部分に手を入れる必要が生じてきます。例えば、開発に使用しているプログラミング言語や、アプリケーションフレームワークのバージョンアップにより、それまでの古いバージョンとの互換性が失われることがあります。データベースなどのミドルウェアのバージョンも同様です。利用者の拡大により、ソフトウェアそのものを大きく拡張したくなることもあります。データベースのパーティショニングや、インフラをオンプレミスからクラウドに移行してスケールアップが容易にできるようにしたい、などです。
わたしのチームが扱っているMackerelでも、ローンチしてからこれまでの5年の間にこのような大きな変更を何度か経験しています。最初に、将来的なスケールアップを見越してデータセンターで運用していたシステムを、AWSに完全移行しました（注1）。次にOSS製品を使っていた時系列データベースが、利用者の拡大によりキャパシティを超えそうな問題に突き当たったのと、より柔軟な拡張性を手に入れるために自作の時系列データベースに刷新しました（注2）。現在はAngularJSを用いて作られているフロントエンド全体をReactに移行するプロジェクトが進行しています（注3）。
こういった、システムの根本部分に大きく手を入れることを怠っていると、ある時点で新規開発が不可能なほど技術的負債が積み上がり、フルスクラッチしかプロダクトを継続する手段が取れない、という事態に陥ることがあります。そうなる前に、周期的に手を入れ続けて、プロダクトを構成する要素を新しい状態に維持し続けることが望ましいです。
プロダクトを構成するための周辺環境は、ここ数年で大きく変化しています。オンプレミスな環境での運用から、クラウドプラットフォームを利用した運用が一般的になり、現在はその上でさらにコンテナ技術を用いた、よりスケーラブルな環境へと世の中が移行しつつあります。Mackerelでも現在、各サブシステムのコンテナ化が進行しています。「ソフトウェア式年遷宮」を意識することで、こうした世の中の進化に追随し、運用するプロダクトをよりモダンな世界へ導いて運用負荷を下げたり、より新しいチャレンジに取り組みやすい環境を作ったりすることができます。それにより、プロダクトそのもののビジネス価値をより高めるための選択肢を増やすこともできるでしょう。
注1
Speaker Deck 「Mackerel インフラ基盤 AWS 移行の舞台裏」 大野一樹 著、2017年10月
注2
Speaker Deck 「AWS で実現した Mackerel 時系列データ1分粒度長期保存の裏側」 id:astj 著、2018年2月
注3
Speaker Deck 「Mackerel のフロントエンドフレームワーク移行 序章」 Susisu 著、2020年5月
「ソフトウェア式年遷宮」による技術継承
次に、「ソフトウェア式年遷宮」のもう一つの大きな要素である、エンジニアの技術継承に焦点を当てます。
我々が取り扱うプロダクトについて、最も詳細に全貌を把握しているエンジニアは誰でしょうか？ そのプロダクトの新規構築に携わったエンジニアであるとわたしは思っていますが、これに異論のある人は少ないだろうと思います。
プロダクトを5年とか10年とか、長期に渡って運用していく場合、最初の構築に携わったエンジニアがそれと同じ期間プロダクトに張り付いていることはほとんどありません。異動や退職によって人は常に入れ替わっていくものです。また、プロダクトに新しい観点をもたらす新陳代謝の観点でも、一定の周期で人が入れ替わることは望ましい場合もあります。Mackerelでもローンチ後3年ほど経過したタイミングで、新規構築を手掛けたエンジニアメンバーがゼロになり、エンジニアの総入れ替えが完了しました。
人の入れ替わりは新陳代謝という意味ではポジティブに考えるべき要素ですが、一方でスキルの維持という視点ではネガティブに作用してしまうこともあります。これを最小限に抑えるため、最初に紹介した「スキルマップ」が有効に働くわけですが、それをもってしても失われる要素はあります。プロダクト全体を横断するような文脈や、歴史的経緯に基づく判断基準などです。こういった「失われたもの」を取り戻したり、「プロダクトに一番詳しいエンジニア」の世代交代をはかったりするために「ソフトウェア式年遷宮」が効果を発揮します。
「ソフトウェア式年遷宮」は、プロダクトを構成する根本部分の要素に手を加えることを言います。「ソフトウェア式年遷宮」のプロジェクトにメインで携わるエンジニアには、チームに入って比較的日の浅い人を割り当てるべきです。
例えば、アプリケーションフレームワークのメジャーバージョンアップを適用するプロジェクトなどを考えるとイメージがつきやすいと思いますが、こういったプロジェクトは、プロダクトを構成するソフトウェアのあらゆる部分に目を通さなければなりません。場合によっては、過去のドキュメントを掘り起こし、現行の仕様がなぜそうなっているのかを調査する考古学的なアプローチが必要になることもあります。
「ソフトウェア式年遷宮」の担当エンジニアは、こういった過程を通じてプロダクトの全貌の理解へと迫っていくことになります。また、プロダクトの全貌を把握し、それを新しく置き換える作業を経ることで、さらにその先の理解へと進みます。ここまで書くと、もうお分かりかと思いますが、「ソフトウェア式年遷宮」が完了して以降、その「プロダクトに一番詳しいエンジニア」は、新規構築メンバーから、「ソフトウェア式年遷宮」プロジェクト経験者へと世代が移行しています。逆に、式年遷宮によって新しく置き換えられた要素については、プロダクトの新規構築メンバーの方が理解が浅い状態になっていることでしょう。これを周期的に繰り返すことで、そのプロダクトの主軸を担うエンジニアの世代交代がうまくいくのです。
プロダクトを長期間運用するにあたって、そのために必要な知識・スキルを維持し続けることはとても難しいことです。そのためには意識的な取り組みが不可欠となります。今回ご紹介した2つの手法は、わたし自身がMackerelというプロダクトに5年間携わった経験上、スキルの維持・継承にとても有効に作用した手法です。「ソフトウェア式年遷宮」などはなかなか気軽に実施できるものではありませんが、「スキルマップ」はちょっとした手間で明日からでも始められるやりかたかと思います。ぜひ、皆さんの現場で実践してみてください。
プロダクト開発の最新情報をゲットするには、会員登録がおすすめ！
ProductZineのメルマガに登録いただくと、新着記事やニュースなどプロダクト開発の最新情報をお届けします。4~5月は不定期配信になります。
