アーキテクチャの進化と成熟：機能 vs 能力（Architectural Evolution and Maturation: Features versus Capabilities） †
サマリ †
アーキテクチャの成熟と進化とは、機能と能力の相互作用である。技術的負債は負うな、返済せよ！
詳細 †
- アーキテクチャの新規構築に注目が行きがちだが、実際は既存のアーキテクチャのお守りをすることの方が多い。
- アーキテクチャを進化させることの方が、一から作ることよりも実際は面白い。
- 自分たちが本当に成功したかを知るのは、アーキテクチャの進化を通してだからだ。
- アーキテクチャの進化と成熟のプロセスは、顧客が実際にシステムを使うことによって駆動される。
- 顧客のフィードバックは、システムの次期リリースを計画する段階でもっとも集められ、吟味される。
- 次期リリースは、要件として挙げられた機能（features）によって定義される。
- 機能が実装可能かどうかは、アーキテクチャの能力（capabilities）に左右される。
- 機能と能力の相互作用こそが、アーキテクチャの進化である。
- この機能と能力の相互作用が面白いのは、それが技術的進歩の中で起こることだ。
- 新しい技術をキャッチするのは、顧客でなく開発チームの中からのこともある。
- いずれにせよ、アーキテクチャの進化と成熟を、機能と能力の両輪で考えることが大事。
機能
- 機能（feature or function） ＝ 製品ができること、またはすべきこと
- 必要とされる全機能のセットが製品の要求となり、ドキュメント化される
- 『ある要求が機能かどうかをテストするには、「製品は〜であることが求められる」または「製品は〜できるべきだ」と言い換えてみる。』
- サポートされるプラットフォーム：「製品はSolaris 2.8とWindows XP上で動作することが求められる」
- ユースケース：「製品は新規ユーザを登録できるべきだ」
- パフォーマンス：「製品は受話器が外れた信号を受信してから100ミリ秒以内に発信音を送ることが求められる」
- 機能の記述には、ユースケースが優れている。
- 機能を、アクターのゴールといった、特定のコンテキストの中に位置づけられるため。
- アクターにとってのゴールが特に重要なのは、そこからPMがビジネスやライセンス、価格といった価値提案を導き出せるから。
- 機能を管理するには、マーケティングが優先度を付けるのがベスト。実装するには、開発チームが技術的依存関係を明確にするのがベスト。
- 機能間には、依存などの関係性があるため。
- 良いアーキテクチャというのは、求められる機能を簡単に実装できるもの。
能力
- 能力（capability） ＝ ある機能セットを支えるアーキテクチャの基礎力。
- マーケティングに、なぜこの一連の機能がこのアーキテクチャでは簡単には実装できないかを説明するときに、その重要性が分かる。
アーキテクチャの成熟と進化
- アーキテクチャの成熟と進化の相互作用は、時間とリリースサイクルの関数になる。
- 通常、最初のリリースで全ての機能を実装できることはない。
- リリース後すぐに顧客のフィードバックは集まらないので、2回目のリリースでは積み残しの機能が実装される。
- 従って、最初のアーキテクチャは変更されず、その代わりに成熟する。
- システムが3、4回のリリースまたは2、3年を経て、初期の機能がだいたい実装されると、PMは顧客のフィードバックを集めて、将来のリリース計画を練ることになる。
- このとき、開発チームは新規機能のための能力を開発することになり、アーキテクチャの進化が始まる。
- もちろん、アーキテクチャ進化がすべて顧客の要望でのみ駆動される訳ではない。
- 新しい技術を積極的に取り入れようという姿勢の企業は、自らアーキテクチャ進化を起こすこともある。
- アーキテクチャの成熟と進化は、循環的である。
- 成熟期においては、新規能力はあまり導入されない。
- 実際のシステム使用経験、フィードバックを通してのみ、能力は成熟する。
- 究極に手入れの行き届いたアーキテクチャでは、能力は削除されることもある。
- システムの完全な再構築をしなければいけないときに限り、この成熟／進化サイクルが断ち切られ、能力の実装が開発チーム関心の大部分を占めるようになる。
- 再構築のよくある動機：既存システムが本来あるべき能力を持たず、追加のコストがあまりに大きい場合。
- 再構築を始めるときは、アーキテクトが欠けている能力をしっかり把握するようにしよう。
- 拡大する顧客ベースに新しい機能をなるべく早く提供しようとするとき、再構築をしたくなる。
- しかし、ちゃんとマネージしないと大変なことになる。
アーキテクチャの劣化
- アーキテクチャの劣化は簡単に起こる。
- 市場の圧力が強いとき、普段は分別のあるエンジニアリングマネージャでも暴走することがある。
- 色々な理由付け：競合に重要な顧客を奪われるぞ！ 重要な顧客が次バージョンへアップグレードしてくれないぞ！ どうしても必要な売上に遅れが出るぞ！
- こうした無理は、将来の機能開発コストを跳ね上げる。
- 必要なアーキテクチャの能力が追加されてないので、今後の新規機能開発が窮地に陥る。
- さらに悪いことに、開発チームの士気も落ちる。
- 急場しのぎで新規機能を実装することは、開発チームが技術的負債（technical debt）を背負うことになる。
- 負債の元本 ＝ 本来必要な能力の開発に関するコスト。
- 負債の利子 ＝ その能力がない中で機能を維持し続ける負担。
- 利子はリリース毎に積み上がっていって、最後はアーキテクチャ全体を廃棄しなければいけないかもしれない。
- 時には本当に重要な市場の窓に合わせる必要があったり、重要な顧客のためにやる必要があることもあるが、たいていは焦った重役の自己満足に過ぎないことの方が多い。
- 負債は必ず返済しなければいけない。実装すべき機能が欠けているアーキテクチャ能力を必要とするなら、できる限り負債を負うな。
- 「今払うのか、それとも後で利子と罰金付きで払うのか」
アーキテクチャの能力を取るか機能のアジャイルさを取るか（Architectural Capability or Feature Agility?） †
- ドキュメント管理システムの例。
- ユーザがドキュメントを検索、整理できると同時に、新規ドキュメントが外部ソースからも定期的に入ってくる。
- ある要求セット：新規ドキュメントに対する定義済みクエリの格納および実行。
- 別の要求セット：ドキュメントの変更に対するEメールによる通知。
- どちらの機能も、通知メカニズム（notification mechanism）というアーキテクチャ能力がないと実装できない。
- このシステムの課金モデルの話。
- 当初はFortune 2000企業向けに売っていて、固定または同時アクセスユーザ数に対する恒久または1年のライセンスモデルだった。
- しかし、法律事務所に売るには、原価回収のために利用量に応じた課金が必要だった。
- 新しいビジネスモデルを考えるのは簡単だが、それを可能にするアーキテクチャ能力を実装するのははるかに難しい。
- このアーキテクチャ能力を実装するまでは、新しいマーケットセグメントには参入できない。
- 2つめは、トライアル版のあるシステムの話。
- トライアル版は強力なマーケティングツールだが、ソフトウェアを保護する特殊なツールが必要。
- ある顧客がこのトライアルのパラメータをもっと柔軟にして欲しいと要求してきたが、アーキテクチャ的に難しく、結果的に大きな設計変更をしてそのアーキテクチャ能力を実装する必要があった。
- 機能と能力の違いに関する好例：製品マーケティングがUIを多言語にローカライズしてくれとリクエストしてきた場合。
- 各言語へのL10Nはそれぞれ1つの機能。
- 一方で、L10Nを可能にするI18Nはアーキテクチャの能力。
- 他の例：ワークフロー、妥当性検証ルール、カスタマイゼーション、・・・
エントロピー削減：リリース毎の技術的負債の返済（Entropy Reduction: Paying off Technical Debt after Every Release） †
- 開発チームには、「アジャイル」であろうとなかろうと、ある程度コードの質への妥協が必要。
- そうした妥協は、取り除かないとソースの質は劣化していく。
- 製品リリースの一定間隔毎に、エントロピー削減（entropy reduction, ER）が必要。
- ERの重要なメリット：
- ソースコードレベルでの品質の維持。
- 開発チームの士気の維持。
- システムの保守性、拡張性の実質的な向上。
- 開発チームのソースコードへの理解度の向上。
- コーディング標準への準拠。
- ERは機能追加や変更ではない。ゴールはシステムの振る舞いを変えずに、内部をきれいにすること。
- ERはメジャーリリース毎、だいたい9〜12ヶ月毎、に実施する。
- 通常のリファクタリングは開発期間中にやっているはずなので、ERでやるのはリリースに間に合わせるために後回しにしたリファクタリングや、大きめで複雑なリファクタリング。
- ERセッションを始める前には、ルールやガイドラインを決めておくのが重要。
- ER中に新しい機能や能力を追加しない、など。
- なるべくPMをERに関わらせない。ERは純粋な開発アクティビティ。
- 機能テストがあるなら必ず実施すること。ER後は、必ず完全な回帰テストをしてから製品リリースすること。
- チームによってERへの意欲が異なる。
- ERを受け入れているチームは、管理しやすい。
- ERに熱狂的すぎるチームは要注意。アーキテクチャを変更しようとする。
- 過去は熱心だったがダメなマネジメントに潰されたチームは、ERを強制しないとやらないかもしれない。（？？？）
ERのベストプラクティス
- ERを実施する前は、ER計画を立ててピアレビューすること。
- 例えば、ERの通常の実施期間で完了できそうもないタスクが盛り込まれることがある。
- ERのベストプラクティス
- コードタグを使え。 -- TODO、REDO、HACKなどのコメント。
- リズムを確立せよ。 -- いいリズムがあれば、開発終盤で週80時間労働もいける。その後の回復も早い。
- ER活動をタイムボックス化せよ。 -- 1〜2週間がベスト。3週間で1回試したら、マネジメントが大変だった。
- ERの成果をそのままリリースするな。 -- 単体テストだけでなく、完全な回帰テストが必須。
- 言葉の選択を慎重に。 -- 「技術的負債」「エントロピー削減」という言葉は、人によって響き方が違う。場合によっては、「技術的負債の返済」「アーキテクチャ改善」といった言葉に変える。
- ERでは、重要だと思う他の価値も強化しよう。 -- ソースコードの品質、期日を守ること、責任あるマネジメント、など。
- ERが本当に実施できると分かるまで、チームに約束するな。 -- 途中でCEOに割り込まれて、あわやERセッションを実施できなくなりそうなことがあった。約束していたERセッションを実施できていなかったら、私の信用は失墜していた。
担当者のつぶやき †
- 能力（capability）の訳が難しいですね。「ケイパビリティ」は何となく嫌だな・・・
みんなの突っ込み †
