私たちの産業は常に変化しています。しかし、変化は大変なことです。特に、顧客のニーズとビジネスのゴールを満たすことができるツールとシステムを構築済みの場合、変化はとても難しくなります。新しい市場に参入しようとしたり、顧客の望む方向に進もうとしたりするとき、既存のアーキテクチャの限界が白日の下に晒されます。"Nティアのアプローチに移行したとき柔軟なアーキテクチャを導入しました。SOAはさらに柔軟さを与えてくれます。次の5年、マイクロサービスの導入が私たちをここに連れ戻してくれないとどうしてわかるのでしょうか。"
現在の技術に依存している世界のビジネスでは、この点に対して多くの非難やはっきりとしないメッセージがあります。一般的には、"保守派"、特にITが変化を難しくしている、と診断されています。私も、数えきれないくらいのミーティングで、素晴らしいアイディアや成功の可能性のあるアプローチが、ITチームを動かすのが大変であるということに誰かが気付いたことによって潰えてしまう、ということを経験しました。
従来のITチームは既存システムの大部分の知識を把握しています。これによって、彼らは大きな尊敬と権威を勝ち得ています。ITチームが変化を受け止めないと、変化は起きません。イノベーションに対する打ち勝ちがたい障害になります。
このような現象はどこからやってくるのでしょうか。私の経験では、最良のITチームはリスク回避的であり、変化に抵抗します。彼らの最優先事項はすベてが機能する状態を維持することだからです。それゆえ、技術が高速に変化すると、自分たちがその高速な変化に押し流されていることがわかり、反射的に極端に慎重になります。変化を歓迎しつつすでにあるものを動かし続けるという能力は働いている環境の性質によって決まります。多くのITチームは、市場のあらゆる技術について専門家レベルの知識を要求しつつ、何が起きてもデータの流れを維持するように要求するマネジメントによって疲弊させられています。暗い目をした運用担当者がいないと技術的なミーティングは終わりません。そして彼らは、新しい技術がいかに既存システムに負荷を与えるかを表明することで議事に暗い影を投げかけます。
組織はボートに似ています。小さければ軽快で必要に応じて素早く進む方向を変更できます。クルーズ船のように大きくなると狭い場所では方向が変えられません。大きな進路変更をするには多量のエネルギーとしっかりとした計画が必要です。運動量の保存と水の摩擦の話なのです。組織にとって猛スピードで進路を変更することは荒っぽいことなのです。人と同じように、組織もむち打ちになる可能性があります。人の場合も組織の場合も、着実な進路変更は実現可能で安心できます。
私の比喩の中の水(と摩擦)の大部分は文化を指し示しています。その企業全体の文化、そして、その文化の中で機能する下位文化も含みます。例えば、運用担当者は変化に抵抗します。彼らはイノベーションによって判断されるのではないからです。パフォーマンスとシステムの稼働時間で評価されます。これによって現状を維持することにもっとも価値を置く文化が育まれます。この文化が開発者のほうに移っていくと、次第にビルドの失敗に関心を払う文化になっていきます。これは必ずしも悪いことではありません。これによってしっかりとしたテストとより良いコードが生まれるようになります。しかし、新しいビジネス要件と厳しい納期の中に投げ込まれるとかつては自由に動き回っていた開発者チームでも変化に対する抵抗が増します。安全でリスクを呼び込むイノベーションを回避することに固執する方が健全な場合もあります。
リスク回避は文化に埋め込まれ、構造、暗黙の価値とそれをサポートするアーキテクチャに反映されます。このようなアーキテクチャはかなり冗長で、データセンターで管理され、ほぼ完璧に監視され(それによって性能の些細な点まで絞り上げるという無益な雑務を作り出し)、セキュリティと抽象レイヤで守られています。安定がゴールであるものの、コストは上がり続けます。
複雑によって、新しい技術を重要でないプロジェクトで小さく導入することにさえリスク回避的になってしまいます。これらのプロジェクトは他のシステムが依存する中核的な機能に育つ場合が多いです。アジャイルの考え方を持った企業はこのようなシステムを分離してAPIで抽象化しますが、従来のIT運用ではこのようなシステムは完全に避けようとします。彼らは知識を従属させる必要があるからです。これによって技術の採用プロセスは複雑になり、対象の知識もチームが必ず身につけなければならない専門知識の一覧に加わります。結果、既存のシステムやプログラミング言語は歪みます。あるタスクを実現するのに不向きな技術で実現しようとするからです。例えば、cronでJavaアップレットを動かしてログをローテートする、といったようなことが発生します。
市場が動くと、これらのアーキテクチャの解明には多くの時間、労力、コストがかかります。私たちはさまざまな業界のリーダーがより小さい競合に破れるのを目撃しています。これはシステムと態度に長年積み重ねてきた(皮肉にも競争力を維持するために)リスク回避的態度が原因です。
単一のアーキテクチャでこれに対処することはできません。何年もの間、Nティアのアーキテクチャが一枚岩のメインフレームを壊し、分散コードベースがもたらした課題をアプリレベル、データレベルの冗長性とサービス志向アーキテクチャによって対処しました。今日、マイクロサービスとAWS Lambdaが推進する"function as a service"アーキテクチャが究極の解決策として迎えられ、勤勉な組織は時流に乗ってこれらの原則を導入しています。
これはある種の"カーゴーカルト"です。小さな企業が支持するベストプラクティスを、同じ効果を期待して盲目的に導入しています。良くて、多少の変化が起きるでしょうが、最悪の場合、職場環境はさらに好ましくないものになります。ある手法をその目的や組織固有のニーズにどの程度合致するかを理解せずに導入し、既存の厳格なやり方を置き換えてしまうからです。
最良の組織は敏捷さを中核の価値とゴールにしています。市場を押さえられるかどうかを元に意思決定をしません。次に何が来るのかを見ています。未来を予測しようとするのではなく、常に"what-if"ゲームをします。
例えば、もし、ウエアラブルが再び盛り上がったらどうなるか。あなたのビジネスにとってどういう意味があるのか。機会はどこにあるのか。既存のアーキテクチャでどのように対処するか。そのためには何をする必要があるか。
私はこの問いに対して、APIという回答をなんども繰り返しています。きちんとした理由があります。しっかり設計され、管理されているAPIは特定のユースケースと疎結合になっています。また、独立して運用でき、個別にスケールできるので新しい技術が出てきたときに素早く適用できるデータアクセス環境を構築するのに便利です。しかし、APIはより大きなシステムの上の薄いレイヤに過ぎません。成功するかどうかを決めるのはより大きなシステムの方です。
また、このような場合は、技術よりも文化の方が大きな役割を果たします。成功を褒め称え、失敗を罰しますか。アジャイルな見方では成功を祝い、失敗を分析し、会社にはひとつひとつの失敗から学びを引き出す見方が求められます。そのような学びが組織全体を前に動かす助けになるのです。またこれは、99.99999%ではなく99%のアップタイムを提供することしかできないということを許容し、ダウンタイムをエレガントに扱えるようにシステムを設計する、ということを意味します。
これは、初期のFacebookのマントラである"素早く行動し破壊せよ"とは違います。もっとも彼らは、株式公開してからすぐにこのマントラを放棄しましたが。これは、部分的にしか従うことができない無謀な考えです。かわりに私は、"計画的に動いて、失敗を受け入れ学習せよ"と言いたいです。キャッチーではありません。しかし、より現実的な方法であり、開発とデプロイのプロセスから成長と学びを得ることができます。
もちろん、大事なものを無用なものといっしょに捨ててはいけません。ITチームはシステムに依存するもののために性能と稼働時間を最適化することに対して優先順位を付ける必要があります。会社の成功を支援する貢献者の繋がりが弱くなることは誰も望んでいません。エレガントの障害を起こし、素早く復旧し、障害の間は、性能に関する情報を可能な限り提供するようなアーキテクチャを実現することも意味しています。
この点にマイクロサービスアーキテクチャを採用する主要なメリットがあります。コードベースとサービスを複数の独立した小さなアプリケーションに分割し、サービス経由で通信するようにすることで、ひとつのサービスの失敗がシステム全体のクラッシュを生み出すリスクを小さくできます。また、内部の強い結合にも自覚的であるべきです。障害の連鎖を生み出す可能性があるからです。それぞれのマイクロサービスはそれぞれがコントロールできる範囲にのみ責任を持ち、ひとつのサービスがダウンしたら、グレイスフルにダウンするように設計する必要があります。つまり、インプロセスのデータは障害をおこしたサービスが復旧したら高速に検索できるようにどこかに保存しておく必要があります(例えば、Redisのようなキーストアに)。また、エンドユーザーがアクションできるようなエラーメッセージ(エンドユーザー自身が問題を解決する方法やサポートチームに連絡する方法)を提供することも必要です。性能を監視してアラートが上がったら正しいチームに連絡します("DevOps"とは開発者にも連絡がいく、ということです)。また、関連する情報をロギングして、素早く検索して確認できるようにしておきます。
もし、長年積み重なったリスク回避によって作り上げられたレガシーなシステムに取り組んでいる場合でも希望はあります。今のESBツールは一枚岩のアプリケーションを個別のサービスに抽象化し、障害を緩和し、システムダウンをよりグレイスフルにしてくれます。ESBツールを使うことで、問題のあるシステムを特定し、システム全体を完全に置き換えることに時間を使わずに、必要に応じて置き換えたり、新しくしたりできます。
また、並行して、新しい開発にはマイクロサービスアーキテクチャのようなよりアジャイルなパラダイムを導入します。従来の運用の役割は用心深い門番から顧客中心のサービスプロバイダに変わる必要があります。真のDevOps環境では、システムの専門性を身につけることの負荷はすべての技術的利害関係者で共有されるべきです。一握りの技術の完璧な専門家になることは誰も期待されていません。システムを構成するすべての技術の最低限の理解を皆が身につけていることが期待されます。その上で、中核となるいくつかの部分について高い専門性を獲得している、ということも期待していいかもしれません。自分自身が単なる"プログラマ"ではなくJavaプログラマであると考えているなら、キャリアの中で成長するのに苦しんでも驚かないでください。
変化は良いことです。しかし、ビジネスのゴールとビジネスの資産の現実によって適切に制御される必要があります。単に人気のアジャイル手法を導入するだけでは不十分です。自分の組織にとってベストなアジャイルのモデルを見つける必要があります。長く待てばその分だけ、より素早い連中に奪われるリスクが上がります。
ポジティブな変化はトップから生まれたり、開発チームから生まれたりするかもしれません。その変化を育てるには、自ら取り組む姿勢を見せて、失敗と成功を同じ学習機会と捉える文化を構築する必要があります。これが組織全体の習慣になれば、長期的な成功も確かなものになるでしょう。
己を見つめ直しても困ったことにはなりません。自分自身が悩みの種になっていないか確認してください。潜在的なコスト、混乱、崩壊について反射的に正当化するのは止めましょう。"私がイノベーションの障害になっているか"と自分自身に問いかけてください。
著者について
Robert Zazueta氏はTIBCOでデジタルプラットフォーム戦略のグローバルディレクターとして、デジタルトランスフォーメーションについて戦略的アドバイス、ガイダンス、リーダーシップを提供しています。15年以上のウェブ開発の経験と4年のビジネス開発の中で、氏はさまざまなAPIを開発、設計、利用、支援、管理し、パートナーとの統合を行ってきました。また、NARWHL.comのメンテナンスもしています。このサイトはAPI開発のためのデザインフレームワークを説明しています。