The Tarchitecture Roadmap †
Context †
あなたはプロダクトリリース中に、複数のアプリケーションを構築することを期待されている。
あなたは特定の市場とその市場が求める機能や利点が明確化された、マーケットマップとフィーチャー/ベネフィットマップを手にしていることだろう。
あなたは一つまたはそれ以上の市場をサポートするすでに存在するアーキテクチャを持っているかもしれない。
Problem †
技術的な変化をどう管理/投資していけばよいか？
Forces †
- たとえどんなに良く構成されたアプリケーションでも、技術的な変化が過去の推論を無効にする可能性がある。
- テクノロジーは通常地平線から現れ、もしテクノロジーが計画されたものなら順応するのに十分な時間がある。
- 開発者は彼らがどこに進んでいるか理解することを好む。
- 開発者は新しいことを学ぶことを好む。
- 開発者は不十分に実装された機能か性能の技術的な改善を管理する方法を求めている。この方法は不足している機能と性能の両方が他の人間に理解され、修正したいものとして認識させる
- テクノロジーは市場が望むかもしれない新しい機能となる可能性がある。
- マーケティングは新しいテクノロジーに適合するためだけの機能を要求するかもしれない。
- 競合者の新しいテクノロジーへの適合はあなたを不利で受け身な状態にするかもしれない。
- 技術的な人々は新しく現れたテクノロジーについて論争するかもしれない。ある時は論争が問題についてもっと学ぶ方法になる。コンセンサスに達する唯一の方法は多くの場合、膨大なディスカッションによって可能となるだろう
Solution †
テクノロジーマップを作成することは、どうあなたのアーキテクチャが発展するかを示すことになる。それはキーとなるマーケットセグメントが望む利点が、特定の技術でどう生み出させるか示した、マーケットマップとフィーチャー/ベネフィットマップと関連しているべきだ。
重要なマイルストーンであればいつでもこのマップをレビューすることは、半年に一回行うよりもよいと思っている。重要な内部的なマイルストーンの例としては、コードのフリーズや製品の出荷時、50%の現在の顧客が最新バージョンへのアップグレードをすべきと思っている時などだ。重要な外部的なマイルストーンの例としては、競合相手の新しい製品のリリースの問題、新しい特許の出現や、技術的なスタッフが重大な技術の継続性の欠如に気づいたときならいつでも、また市場でなにか起こった時はいつでも該当する。
ターキテクチャロードマップを作成し管理していくことは、少なくともチームの中の一人が新たな開発フィールドのための外的な環境を見ることが必要とされている。
もしマーケティングが既存の技術でサポートできない機能（直接的にまたはパフォーマンス/コストのカーブの理由から）を見つけたときは、ターキテクチャロードマップがこのニーズに合う新たなあらゆるテクノロジーが出現していないかを見て、期限を決めて環境をスキャニングするためにチームが集中し続けるための助けとなる可能性がある。
Resulting Context †
良いニュースとは、あなたがあなたの製品のための技術的な未来を明確に約束できるかもしれないことだ。
悪いニュースとは、あなたのチームが十分な方針をもっていなければ、チームはすべての可能な未来を探検したいという、恐ろしい、ただの新しいもの好きシンドロームとなるかもしれないことだ。
Related Patterns †
- Market Map
- Feature/Benefits Map
担当者のつぶやき †
みんなの突っ込み †
