O’Reilly Software Architecture conferenceにて、Raffi Krikorian氏がシステムの書き直しに取り組む技術リーダー、アーキテクト向けに戦略と戦術を語った。氏のTwitter Engineeringでのバイスプレジデントとしての経験を引き合いにだし、再設計のプロセスを管理するための12のポイントを解説した。“完了”を定義すること、コードの品質を保つことなどについてだ。
Krikorian氏は現在、UberのAdvanced Technologies Centerを率いており、以前はTwitterでエンジニアリング部門のバイスプレジデントを務めていた。氏は、システムの再設計や書き直しのプロセスでは多くの問題に悩まされると話した。いつも複雑さを過小に見積もってしまうことや、顧客を完全に理解できないということ、システムの要件が頻繁に変わるということ、予定よりも時間がかかってしまうということなどだ。
Krikorian氏は、アプリケーションが顧客の要求に合致しないとき、スケールしないとき、同様の製品の機能にマッチしないときに再設計が発生するのが典型的だと言う。この講演では、システムの書き直しのケーススタディを紹介し、共通の落とし穴と、システム再設計に取り組みための戦略について話した。中心となるテーマは、可能であっても完全な書き直しを避けること、完全に書き直す場合であっても、再設計の前、再設計の最中は以下の12のポイントを考慮することだ。
- [ビジネスに対する価値を]維持する
- “完了”を定義する
- 漸進主義
- スタートラインを見つける
- データを無視しない
- 技術的負債をしっかり管理する
- [‘あつい’新しい技術的スタックのような]実態のないものを避ける
- 緊張の上昇に備える
- ビジネスを知る
- 政治に備える
- コードの品質に目を光らせる
- チームを準備する
それぞれのポイントを解説しながら、氏はアプリケーションの再設計中はビジネスのプロダクトマネージャは心配になるが、それは技術リーダーによって管理されなければならないと説明する。ビジネスと技術の利害関係者は協調して、成功する再設計にとって“完了”が何を意味するのかを定義しなければならない。いくつかの依存の仕様化の技法は要件を定義するのに応用されるが、既存のコードは新しいシステムの仕様に使われるべきではない。
Krikorian氏は、新旧のシステムで機能を全く同じにするのは難しい、と言う。既存のシステムがプロダクション環境で動いている間、新しい機能が追加され、このような追加は適切にドキュメント化されない可能性がある。
システムが本当は何をしているか、知っていますか。
"すでにしていることをするようにする”というのは想像以上に難しいものです。
ほとんどのプログラマは何を質問されているかも解りません。彼らが元々のシステムの設計者でなければなおさらです。
機能を実装するのは難しい、それゆえ、書き換えは漸進的に行うべきだ。アジャイルで継続的デリバリに基づいたプロセスが最も適している。新しいシステムは各イテレーションの終わりにはリリースできる状態になっている必要がある。書き換えた機能の定期的なデモもビジネス上の関係者にするべきだろう。また、Krikorian氏は書き換えで機能を搭載していくことを許可することに対して警告している。
機能実装はとても魅力的です。特に古いシステムで機能開発を止めている場合はそうでしょう。
しかし、それは潜在的に死を到る道です。
いつもの開発の間も止めてみたらどうでしょうか。
一般的に、アプリケーションのコードよりもシステムが扱うデータの変化のほうがゆっくりだ。Krikorian氏は、書き換えの間に偽のデータを使うのは、セキュリティの観点からよくない、と指摘する。テストは可能な限り本物のデータで行い、ダークローンチングやトラフィックシャドウイングのような技術を使う。新旧のアプリケーションの間でどのようにデータの整合性を取るのかにについても計画が必要だ。既存システムはパフォーマンスの点でもデータハンドリングの点でも管理されている必要がある。そして、書き換えに関する決定はデータを考えてされるべきだ。
技術的負債を管理するのはシステムの書き換えで重要な点だ。技術的負債を目を向けないとソフトウェアのエントロピーが増大してしまうからだ。技術的負債はふつう、ビジネスからの圧力、プロセスの不在、しっかりと定義された設計の欠如、エンジニアリングメンターシップの欠如で生じる。
Krikorian氏曰く、設計の品質に関する文化を育成する必要がある。リファクタリングを推奨し、継続的に設計し、コードの品質に関する実践を怠らない。開発時間の一定を技術的負債への対処に割り当てるべきだ。適切な対処をしなければ、現実のコードは複雑になる。普通、開発者はコードを書くよりも読むように時間を使うので、コードのレビューは“可読性”を高めるためにコードを構造化するのに有用だ。
Krikorian氏は書き換えでは“実態のないもの”を避ける必要がある、という。“話題’の新しい言語や技術スタックというようなものだ。確かにそうしたものは魅力的だ。短期的なモチベーションも上がり、採用にも使える。しかし、技術的リーダーは長期的な望みにとって利益となることをするべきだ。
書き換えの最中は喜ばしくない顧客が集まる可能性が十分にある。新規顧客は新しい機能を使えない。既存顧客は書き換えによって立ち往生してしまう。
ここに潜在的な戦いが生まれます。ビジネス側にはフラストレーションが生まれます。納期はほぼ間違いなく守られないのですから。
Krikorian氏は、書き換えを始める前は、“だれもこのようなことを考慮しない”と忠告する。この戦いは書き換え自体を壊してしまう可能性があり、技術的リーダーはこの問題を解決する必要がある。
開発チームにとっては、書き換えのために、ふたつに分かれることは一般的ではない。ひとつのチームが古いシステムをメンテナンスし、もうひとつのチームが再設計するという構成だ。このやり方は有効だが、技術的リーダーはふたつのチームの間に生まれる緊張に準備する必要がある。バグ修正、炎上の消火はストレスがたまる作業だ。ひとつのチームがこれをやらなければならず、もうひとつはやらなくてよい。Krikorian氏曰く、技術的リーダーは、既存システムを維持するチームに対するサポーターを開拓する必要がある。チーム間の進捗も定期的に伝え合い、書き換えに関する作業は透明にしておく必要がある。
書き換えが始まる前に、技術的リーダーはすべての利害関係者を知っておくのは重要だ。書き換えの非技術的な同期を特定し管理する必要がある。例えば、開発の速度を上げる、ハードウエアのコストを下げる、というようなことだ。氏が言うには、書き換えのプロセスとそれに対応するプロセスの報告はデータを用いる必要がある。コスト削減や機能追加の早さ、安定性、性能、信頼性などのメトリクスだ。逸話のようなもので報告するのは厳禁。試したことの結果も示す必要がある。
Krikorian氏は結論として、書き換えをする技術的リーダーやアーキテクトは常に不確かな立場に置かれる、という。エンジニアリングのリソースを使いながら、新しい機能は提供できない。書き換え作業自体は小さくして、継続的統合や継続的デリバリのような技法を使って日常の業務フローに組み込む。コードの品質は間近で見て管理しなければならない。
コンウェイの法則に従い、望ましい設計とチーム構造をアレンジする必要がある。Krikorian氏は次のように言う。
アーキテクチャはチームの構造を支配します。そして、チームの構造がアーキテクチャを支配するのです。
Raffi Krikorian氏のスライド“Re-architecting on the Fly”はSlideshareで見れる。O’Reilly Software Architecture Conferenceは2015年3月にボストンで開催された。カンファレンスのサイトでは詳細が確認できる。