待ったなし “New Normal時代の DXプラットフォーマー” 〜 実現の近道は行動力とIT活用力 〜セミナーで伝えきれなかったお話
セミナーの内容
9/3 にオンラインセミナー「待ったなし “New Normal時代のDXプラットフォーマー”〜 実現の近道は行動力とIT活用力 〜」でお話する機会がありました。
私が話したかった内容は DX に必要なアーキテクチャを Apache Kafka を使って考えるという内容でした。
しかし、20 分という短い時間の中では伝えたい内容も資料の中に盛り込むことができず、なくなく断念したものもあります。
伝えたかった内容 — アジリティ
DX の最終目標は売上の拡大であると思います。
DX でビジネスをドライブするためには以下の観点での工夫が必要になります。
- 競合がイミテーション(模倣・真似)しにくいビジネスモデルを最初から考慮する(例えばビジネスモデルで特許を取得する)
- 競合がイミテーションすると競合の部門間でカニバリゼーション(共食い)が発生するビジネスモデルを考える
カニバリゼーションの例としては(IT 業界の話ではないですが)、歯ブラシにおける LION vs Johnson & Johnson の話が有名です。
以下、東洋経済オンラインから引用させていただきました。
https://toyokeizai.net/articles/-/5796?page=4
リーダーの事業同士のカニバリ懸念を引き起こし、同質化を回避する戦略を「事業の共食い化」という。
ジョンソン・エンド・ジョンソン社が奥歯までしっかり届く「リーチ歯ブラシ」を発売した。ヘッドが小さいため「奥まで届く」のである。
それは消費者にとって虫歯を防げるという価値があるだけではない。競合であるライオンは歯磨き粉シェア №1であるため、歯磨き粉の消費が減ってしまうため同様の歯ブラシを作れないという「事業の共食い化」を狙ったのである。
業界 №1 におけるイミテーションは経営戦略の一つとして普通に使われている手法のため、競合によるイミテーションを回避するのは DX を展開する上で非常に重要です。
イミテーションを回避できなかった場合、競合よりも先に新機能や UI の変化をユーザーに提供する必要が出てきます。よりよい体験を継続的にユーザーに提供し続ける必要があるのです。派生開発やウォーターフォールといった手法で取り組もうとしても、スクラムやアジャイル開発に取り組んでいる競合がいたら先を越されてしまうでしょう。
DX を語る上で暗黙的に当たり前になっているかもしれませんが、こうした企業文化を変更する必要があります。Red Hat は TOBE 像をお客様の代わりに描くことはできませんが、アジャイルな社内文化を醸成するお手伝いや TOBE 像を描くお手伝いをすることはできます。
伝えたかった内容 — スケーラビリティ
もし仮に DX が軌道に乗って利用者数が増加してきたとします。この時、組織やシステムが利用者と同時にスケールできない場合、機会損失を生じます。システムを作った後からスケール可能な仕組みに置き換えるようではタイミングとして最悪です。
もし水平スケールが不可能な仕組みを取り入れていたら、垂直スケールアップに莫大な費用が発生する可能性も考えられます。スケール可能な仕組みでシステムを考えておく必要があります。
スケーラビリティのあるシステムを考慮する上である程度犠牲にしなければならない可用性の部分では、回復性のあるプラットフォームや可観測性・管理力を備えたツールを利用します(Kubernetes やそのエンタープライズ版である Red Hat OpenShift)。
クラウドネイティブ
DX を実現する上で必要な組織・システムの特性として、Cloud Native Computing Foundation が定義するクラウドネイティブをご紹介しました。
https://github.com/cncf/toc/blob/master/DEFINITION.md
クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどの近代的でダイナミックな環境において、スケーラブルなアプリケーションを構築および実行するための能力を組織にもたらします。 このアプローチの代表例に、コンテナ、サービスメッシュ、マイクロサービス、イミュータブルインフラストラクチャ、および宣言型APIがあります。
これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現します。 これらを堅牢な自動化と組み合わせることで、エンジニアはインパクトのある変更を最小限の労力で頻繁かつ予測どおりに行うことができます。
Cloud Native Computing Foundationは、オープンソースでベンダー中立プロジェクトのエコシステムを育成・維持して、このパラダイムの採用を促進したいと考えてます。 私たちは最先端のパターンを民主化し、これらのイノベーションを誰もが利用できるようにします。
ステートからイベントへ
従来のようなステートを取り扱うシステムはこうした回復性のあるプラットフォーム上で動作させるには考慮すべき事項が多数発生してしまいます。また、スケーラビリティにも制約が出てきます。そこで DX を取り組む上ではステート中心のアプリケーションから不変(イミュータブル)であるイベントを取り扱うようにすることで、回復性のあるプラットフォームに適したアプリケーションを構築することができるようになります。
セミナーではチェンジイベントを中心にご紹介しましたが、本来お伝えしたかったことはドメインイベントをアプリケーションで取り扱うようにすることです。
Red Hat ではこうしたドメイン駆動設計(DDD)におけるドメインイベントを体験しながら考えていくワークショップもご用意しています。
Apache Kafka & Apache Camel & 3scale API Management
イベントを大量に取り扱う必要がでてくる時に必要なのが Log Based Message Broker(LBMB) である Apache Kafka になります。イベントを格納するイベントチャネルとして使用します。
またセミナー中では Distributed Integration Platform として Apache Camel も紹介させていただきました。既存システムや SaaS のアウトプットをイベントに変換して Apache Kafka に投入し、DX システム群に渡す役目を担います。これを ESB のような一枚岩ではなく分散した環境で実現することが可能です。
そして顧客接点をデジタル化して多様化し API から収益をあげることも可能になります。ここでは 3scale API Management を利用することができます。
近い将来のアーキテクチャ — Knative Eventing
セミナーでは語ることができませんでしたが、上記は Knative というサーバーレスを含んだ技術でそのまま置き換えることが可能なアーキテクチャになっています。
Kafka はそのまま Knative Eventing における Kakfa Channel として利用できます。もしくはイベントの発生源 Kafka Source として利用可能です(この場合は Kafka にデータが格納されたことでイベントが発生する)。
DIP つまり Camel の箇所にはサーバーレスを取り入れることが可能になり、アプリケーションが使用されていない状態においてはコンテナを 0 までスケールインさせることができます。また、Camel Quarkus を使用することで Linux ネイティブなアプリケーションとして導入することができます。リクエスト受信時に例え 0 までスケールインされていたとしても、瞬時に起動するアプリケーションを短いコードで記述することができます。
また、到着したイベントのフィルタリングも yaml ベースで記述することができるようになっています。
最後に
短い20分のセミナーの中で語ることのできなかった内容を含ませていただきました。Red Hat ではプロダクトだけではなく、アジャイルに関連したサービスもご提供しており、DX を進める上で困ったことがあればお気軽にご相談いただければと思います。
