小さなレガシーコードにできること: ソフトウェアの所有者のお話

あるところに、小さなコードがおりました。

コードは名前を呼ばれるのにうんざり。最後まで選ばれないのも飽き飽き。ビジネス運営の立役者だというのに、どんなにトランザクションを処理しても、値を有効にしても、ユーザーを助けても、みんなの笑い者です。

コードは悲しくなって「ぼくはビジネスのバックボーンなんだぞ！」と叫んでみましたが、その声はどこにも届かず虚しく響くだけ。だれもコードと遊んでくれず、声をかけてくる気配すらありません。それというのも、このコードの評判がひどいものだったからです。つい先週、コードを変更するために呼ばれた人が、チームリーダーに向かって信じられないことを言い放ちました。

「こんなコードには触りたくない。なんて醜いんだ。今どきのプラクティスにまったく沿っていない。もしいじったら、面倒なことが起こるに決まってる」

それを聞いたコードは座り込み、小さな 1 と 0 の涙をこぼしました。しばらくして気持ちが落ち着くと、コードはこう思い立ちました。「そうだ、自分のブランディングをしなくちゃ。他のコードから話を聞いてみよう」といっても、コードには友だちは 1 人もいません。他のコードたちはいつもコードを避けているのです。

「こんにちは、マイクロサービスさん。なぜ人間はあなたを使うのが好きなのかな？」

「ああ、こんにちは」とマイクロサービスは答えましたが、その目はそわそわして、コードとの会話を一刻も早く終わらせたいように見えます。「たぶん目的を定義しやすいからじゃないかな。テストカバレッジも高いし、デプロイも簡単だし」

「なるほど」とコードは言いました。「どんな人たちがあなたにかかわっているの？」

「チームメンバー全員がいつも何かしら作業しているよ。コードができたら、リファクタリングされて、Kubernetes に置かれて、更新されて、自動スケーリングされるんだ」

「わあ、それは楽しそうだね。ところで、Kubernetes ってなあに？」コードはたずねました。「それと、あなたはどんなふうに本番環境に置かれるの？」

「本番環境？」マイクロサービスは怪訝な顔で問い返します。「それはいったい何のこと？」

「しまった」コードは思わず声をあげました。話しかけた相手がコードの 1 つにすぎなかったことを思い出したのです。マイクロサービスは技術的にはパーフェクトですが、ユーザーを助けるコードではありません。小さなコードは、その後もいくつのコードに声をかけてみましたが、同じような答えが返ってくるばかりでした。新しいアイデアを使った新しいシステムがこんなにたくさんあるのに、小さなコードはビジネスを支える処理を実行することしかできません。

がっかりしたコードは、いくつかのパイプを横断して、別のコードベースに話しかけてみることにしました。

「こんにちは。なぜみんながぼくを使いたくないのか知っている？」

コードベースは立派な体格で、ひげは伸び放題、髪の毛はぼさぼさですが、全体を見るとそれがかえって賢そうな印象を強めています。

ぼさぼさ頭のコードベースは答えました。「レガシーのきみを使いたい者など、いるはずがなかろう」

「わざわざ面と向かって悪口を言う必要はないと思うんだけど」とコードは言い返しました。

「おいおい、早とちりしないでくれ。レガシーとは、ビジネスを支えているということ。きみには大きな影響力がある。きみは重要な処理をすべて実行しているからね。しかしそれは、きみとかかわれば『いにしえの神々』の手に落ちてしまうということでもあるんだ。人間たちはもう新しいパターン、新しいプラクティス、新しいツールに移行しているんだよ。ちなみに、私もきみと同じ立場だ」

「本当？」少し元気を取り戻したコードはびっくりした顔で言いました。

「本当だとも。なぜ『レガシー』が悪い言葉になったと思う？レガシーとは、『以前は機能していた』ということ。長い間機能し続け、大波に揉まれながら生き延びた。きみや私のようなコードは、ずっとビジネスを支え続けている。提供するべきものを提供し続けている。リーダーが必要としているのはレガシーだ。コードベースだってそうだ」

「でもマイクロサービスさんは今はマイクロサービスが人気だと言ったよ。そして、ぼくみたいなのはデジタル世界の鼻つまみ者だって」

「もちろんやつらはそう言うだろう。嫉妬しているのさ。マイクロサービスのコンポーネントのうち、いくつが日の目を見ると思う？きみや私の力を借りずにジョブを実行できるやつがどのくらいいると思う？マイクロサービスたちもジョブを実行できるようになることが期待されてはいる。しかし人間はコードをなかなか正確に抽象化できない生き物だからな。その結果、ああいったサービスは私たちのインターフェイスになることが多い。私たちはレガシーで、それで問題ないんだ。価値を提供しているんだから。コードベースの中には、きみや私のトランザクション、レイテンシ、健全性をうらやましく思っている者もいる」

「じゃあ、なぜぼくたちを使いたい専門のチームがいないんだろう？」

「ふん、人間はエンジニアリングチームの再編成が好きだからな。ドメインやら、マイクロサービスやら、サブシステムやらをチームに割り当てるんだよ。私たちは、人間がコンストラクト分割を始める前から存在していた。にもかかわらず、無視され、最後まで選ばれない。どのチームに属していたとしても、よっぽど注意力の高い人間以外は、私たちを使いこなせないんだ」と賢いコードベースは言いました。

「うーん。ぼくたちがとても働き者だから、人間たちは他のコードを使いたがり、ぼくたちを忘れてしまうということ？」

「そうではない。人間は私たちの存在を知っている。私たちが有能なことも知っている。ただ新しい方法を使いたいだけなんだ。新しいツールや技術にお金を払いたいんだろうな。しかし、そういった新しいもののうち、本番環境で使えるものはどれだけあるかという話だ。それに対し、私たちは本番環境でこそ真価を発揮するんだ」

「本番環境が懐かしいなあ」と言葉をもらすコードベースに「教えてくれてありがとう」とコードは感謝を伝えました。

「お安い御用」

コードベースは立ち去ろうとして急に足を止め、振り返ってこう言いました。「私たちはレガシーというより、レジェンドかもしれない」その顔は笑顔に変わっています。

「そのとおりだよ！ぼくたちはずっと前から存在していて、価値を届け続けているんだから、そのことを誇りに思っていいはずさ」

さあ、小さいコードのお話はここまでです。しかし、このストーリーの中で紹介されている問題は、リアルな問題でもあります。ここからは、ソフトウェアを管理する人がいなくなったらどうなるのか、だれも触りたがらないかわいそうなひとりぼっちのコードを作らないにはどうしたらよいのかについて説明していきます。

ソフトウェア所有者の不在によって発生する問題

コードベースに所有者が指定されていない部分があると、問題が発生します。たとえ今すぐ発生しなかったとしても、うまくいかなくなるのは時間の問題です。

たとえば次のような場合に、所有者の不在が発生しやすくなります。

システム内にだれも触りたがらないコンポーネントがある
コードベース内に、最近入社した開発者の大半に知らされていない部分がある
コードやシステム内に、英雄的な勇気や「いにしえの神々」から得た知識がないと使いこなせない部分がある

上記に心当たりがあるなら、レガシー… いや、レジェンドとなったコードを扱っている可能性が高いと言えます。

リリース後のコードは「他の人が責任を負うもの」になります。つまり、デリバリー後のコードは所有物ではなく、リース期間の終了したレンタルのような状態になるのです。リリースされた機能、サブシステム、アプリケーションは、だれが管理するのでしょうか。ここでよく引っ張り出されるのが、Ops チームや、いつも面倒事を引き受けている運の悪いチームですが、実はコードベースの管理役として適任ではありません。なぜなら、ドメインの知識をほとんど持っておらず、インフラの安定性、アップグレード、改善よりもメンテナンスを重視しているからです。

コードの所有者が必要なケース

本番環境のすべてのコードに所有者が必要なのでしょうか。

私たちの業界では、何かが壊れたときには必ず SRE チームが対応することになっています。ソフトウェアに明確な所有者がいない場合、SRE がガラクタ処理係を引き受け、問題が起きないように面倒を見ます。しかしこれでは不公平です。チームのスキルを賢く利用しているとは言えません。なぜこうなってしまったのでしょう。

開発チームは通常、新機能のデリバリーやスピードを評価されます。操作性、トレーサビリティ、ライブラリ更新状況といった、機能以外の点では評価されません。責任範囲が狭いため、ほとんどのケースで Ops チームの手を借りることになります。一方、Ops チームは安定性と信頼性の面で評価されます。Ops チームは、システム管理におけるニュートンの第 3 法則「触れられていないシステムはオンラインのままになる」に従います。もちろん、これが真実でないことは後になってわかるわけですが、それまでは世界中の Ops チームがこの法則に従うことになります。

所有者が明確でない理由

ソフトウェアの一部の所有者がいない、または所有者がはっきりしない原因は 4 つあります。

作成者が退職した
以前は所有者が存在したが、チームが再編成されて所有権が移行したか、失われた
古いソフトウェアを廃止したが、新しいソフトウェアでは置き換えられない部分があった
最初から明確な所有権モデルが定義されていなかった

言うまでもないことですが、あえて言いましょう。何かを構築したら、それで終わりではないのです。実際には、それで終わりにしてしまう人たちが大勢います。企業は何かを構築したら、テストを行います。テストの結果次第で必然的に変更が加えられ、新しい優先順位が生まれます。そうして作成したソフトウェアを本番環境で稼働させるようになったとしましょう。大勢の人がそのソフトウェアを利用し、その機能に大いに頼っており、今後もずっと利用できること、機能が改善されていくことを期待しています。しかし、リリースされた製品や機能は、その後放置されてしまうことが少なくありません。

これは、早くリリースして早くフィードバックを得たいという開発の MVP モデルの弊害でもあります。問題は、とりあえずリリースした試作品は不完全であるケースが多いということです。試作品は、利用者から有益なデータを収集して、フィードバックループが完成するところまでしか計画されていません。ここでは、ソフトウェアのフィードバックを収集するためのパーツは見過ごされてしまいます。たとえ試作品であっても、最初から完了のステップを用意しておくことが必要です。ときには、そのステップで今あるものを破壊することになる場合もあります。

ソフトウェアの継続的なメンテナンス計画は、ソフトウェア開発の責任範囲に始めから含まれています。コードを作成してリリースすれば、目標を達成できた気持ちになるかもしれません。確かに、目的の一部は達成しています。しかし現実には、一度作成したコードにはずっとかかわり続ける必要があります。つまり、継続的なメンテナンスを行い、コードを適切な状態で維持する必要があるのです。

ソフトウェアの初期開発コストは、無期限に発生する運用コストに比べるとゼロに等しいと言ってよいでしょう。

ソフトウェアの所有者を明確化するには

では、所有者の存在しないソフトウェアについてはどうしたらよいでしょうか。

多くの企業は、Spotify のギルドや Valve のカバルのように重なり合ったマトリックスモデルを採用して、所有者のいないコードプロジェクトに所有者を割り当てようとしてきました。CircleCI でも試してみましたが、正直なところ抜群の効果があるとまでは思えませんでした。その性質上、主業務が優先され、ギルドの作業は二次的に扱われるため、ギルドでどれほど活躍したとしてもそのパフォーマンスは評価されにくくなるでしょう。これでは、本当の意味での所有者にはならず、所有権の問題を解決することはできません。単にアカウンタビリティを広く薄く拡散しただけになってしまいます。

しかし、いくつかの点においては効果的です。

一部の企業はチームベースのメンテナンスを実施しています。たとえば、あなたが計画と支払いを担当するチームに所属しているとしましょう。所有者がいないリリース済みのプロジェクトがあった場合には、計画と支払いにはまったく関係がなくても、あなたのチームが担当します。この方法では追跡と測定が可能であるため、ギルドよりもうまく機能する傾向が高くなります。しかし、この方法はクリーンとは言えず、責任範囲も主要ドメインに関連していないため、歓迎しない人たちもいます。人々は完璧なドメインを好みますが、残念ながら世界は完璧ではありません。本番環境で実行されるすべてのコードには、そのメンテナンスを担当する直接の責任者が必要です。最適な所有者でなくても、いないよりはマシと考えましょう。
もう 1 つ、早い段階でコードベース共通のプラクティスを確立しておくという方法があります。たとえば、1 人の開発者がよく似たコードベースをいくつか扱っている場合、作業を行ったり来たりするスイッチングコストは比較的低くなります。この環境では、テスト、ビルド、開発、更新が同じ方法で行われるため、あるコードベースをメンテナンスしている人が、高確率で他のコードベースのメンテナンスにもかかわることになります。使用されている言語やドメインモデルは同じでなくとも、ツールは同じものを使用します。抽象化を利用することで、開発者はテストの実行だけに集中できます。抽象化は共通のエントリポイントです。 ビルドも、テストも、デプロイも、いつも同じ方法で行うことができます。

突き詰めると、所有権の所在を最適化するには、ソフトウェアの設計方法と構築方法を見直す必要があります。特に、ツール、測定、モニタリングの設計が重要です。ソフトウェアを正確に記述する能力の次のレベルとして、ソフトウェアの有効性を検証する能力が求められます。あらかじめ診断を念頭に置いて設計を行うには、開発者がその意識を持っていなくてはなりません。一般に、運用業務を担当していない限り (または真夜中に呼び出されない限り)、意識しにくいものです。合格基準にトレース可能なポイントまたはデバッグポイントを組み込んでおくとよいでしょう。

ソフトウェアの所有権は、エンジニアリングの機能以外の部分です。これは人員の問題であり、担当者たちはオペレーション、測定、メンテナンスに時間を費やします。新しい機能の開発コストは、その後数年間に及ぶ運用、更新、メンテンナスのコストに比べればゼロのようなものだと心に留めておいてください。

ソフトウェアの所有者がいないということは単純な問題ではありませんが、以下にいくつかの推奨事項をまとめておきます。

1. それ以上コードにかかわるのが嫌になっても、コードがなくなるわけではありません。そのときどうするか計画を立て、チームの再編成、メンテナンス計画、今後のパスに織り込んでおきましょう。
2. ビジネスを支えるコードベースについて、新任のエンジニアに情報をシェアしてください。新任のエンジニアは新しいことを担当するため、レガシーシステムを管理できるエンジニアの数や割合が減ってしまうという問題が起こりがちです。これではヒーローカルチャーが醸成され、規模拡大が難しくなります。
3. コードベースの管理を引き継ぐ担当者が、すべてのコンテキストを把握しているわけではありません。2 年後にはあなたが担当者になるかもしれません。1 つひとつの決定について、その内容だけでなく決定の理由も文書に残しておきましょう。わかりやすいコミットメッセージを書いてください。

今まで使ってきたコードで、別のことができるかもしれません。まだ機能しているシステムを慌てて廃止したり、交換したりする前に、よく検討する必要があります。私たちの友であるレガシーコードベースが長年にわたって提供してくれた機能、トランザクション、ユーザー、収益、スループットを忘れずにいましょう。ほんの少しでも愛を注げば、大きな役割を果たしてくれるのです。