はじめに
はじめまして。@atsuo0oと申します。普段は@takahashisansanともに、マイクロサービスアーキテクチャを用いたシステムについてあれこれ考えることをしています。
前回の記事（マイクロサービスが開発・運用コストの削減にどう貢献するか考えてみた件）では、デジタル・トランスフォーメーション（DX）に取り組んでいく際に、DXを実現するための技術としてマイクロサービス（とそれに伴う種々の新しい技術）を導入することが開発・運用コストにどういった影響を与えるか、といった観点で整理をしていきました。
記事の冒頭ではマイクロサービスに対して、DXを実現するうえでの代表的な技術として、以下のように言及しています。
DXに取り組むためには、システムのアジリティ(いわゆる俊敏性)を高める必要があると言われており、世の中的にはそれに求められるナレッジが確立されつつあります。その代表格である「マイクロサービスアーキテクチャ」が2014年に提唱され、そろそろ日本でも普及期に入る段階であると理解しています。
しかし、現場で日々開発を行っている技術者の方は肌で感じているかもしれませんが、マイクロサービスを導入すればDXが全てうまくいくわけではありません。マイクロサービスはあくまで手段のひとつであり、マイクロサービスそのものがDXの達成に直結するものではないことには、注意が必要です。
とはいえ、「DXやるぞ！」という大号令があったとしても、「何から取り組めば良いのか…」と、途方に暮れてしまうのも事実であると思います。社内のシステムやサービスに対して、闇雲にDXの適用を検討していくことは、想像するだけでも困難さが浮かびます。特に、普段の業務を行っている現場サイドからしてみると、業務に対して違和感や不都合を感じる場面があったとしても、いまの業務を大きく変えてまでDXを実行する必要性は感じにくく、新しいことへの現場からの反発は当然のように起こり得ると思われます。
こうした経営側のDXに対する必要性と、現場側とのギャップを埋めるために重要となるのは、冒頭の引用に立ち返り、「そもそも、なぜシステムのアジリティを高めていく必要があるのか？」をきちんと明確にすることです。取り組みの目的を定め、関係者全体で目的を共有していかないと、「とりあえずPoC（やればなにか生まれるだろう）」「とりあえずMSA（なんか最近よく聞くし）」「とりあえずアジャイル（なんかすごいんでしょ）」といったように、手段が目的化する現象が横行してしまい、思うような感触が得られず、残ったのは疲弊した現場だけ…という事態につながってしまいます。
こういった懸念を踏まえて、今回の記事では「DXに取り組むうえで、なぜシステムのアジリティを高めていく必要があるのか？」を、自分なりにもう少し解きほぐしてみることで、DXの実現に向けてシステムを見直していく必要性がどこにあるのか、をもう一度確認していきたいと思います。
必要性が明確になると、そこに向けて取り組むべき技術的な課題が見えてきます。この段階ではじめて、マイクロサービス化を検討すべきなのか、アジャイル型開発を取り入れていくべきなのか、CI/CDやDevOpsの考えを導入して保守・運用のプロセスを改善していくべきなのか、などの新しい技術による解決策の具体的な検討が始められると考えます。
なので、今回の記事は、技術的な話よりかは、「上から突然『デジタルトランスフォーメーションだ！』と言われたけど、いったいどうすれば…」という、モヤモヤした気持ちの整理を中心に記述していきます。
果たしてQiitaで書くべき内容か？という疑問も若干浮かんでいますが、開発者などの技術畑の方だけではなく、DXという言葉に悩まされているすべての方の助けになれば幸いです。
※掲載内容は私個人の見解であり、所属する組織の公式見解ではありません。
DXの実行における課題とは何か？
そもそも、いまあるシステムに対してDXを実行していくにあたって、どういった課題があるのでしょうか。なぜDXへ取り組んでいくことや、システムのアジリティを高めていくことが難しく感じるのでしょうか。
経済産業省が発表した「DXレポート～ITシステム「2025年の崖」の克服とDXの本格的な展開～」の中では、各企業が保有しているITシステムが「レガシー化」しているとし、こうした古いシステムがDXの進行を阻害しているため、阻害要因を早めに取り除いていかないと2025年を境目に大変なことが起きるよ、という指摘をしています。（そもそもDXとはなにかといった話や、具体的にどういったワーストケースが起こり得るか、などは原典を参照ください）
その中では、DXによりビジネスをどう変えるかといった経営戦略の方向性を定めていく必要性とともに、以下のような実行における課題についても指摘しています。
- 「レガシー化」したシステムに新しい技術を適用してもハマらず、効果が限定的になってしまう点
- システムとビジネス・プロセス（実際の業務）が密になっているために、システムの刷新＝プロセスの刷新となってしまい、現場サイドからの抵抗が生じるであろう点
- 既存システムに対する保守・運用のコスト割合が大きいために、新しい技術への投資にシフトができていない点
こうした課題は、普段システムに携わっている方であれば実感があるかもしれません。いま使用しているシステムが複雑化しているため、新しい技術を適用しても効果が感じられにくい点であったり、そもそもいまの業務を大きく変えることは移行や教育のコストも伴うため、現場サイドからの反発が想定される点であったりなどです。
３つ目の課題については、前回の記事で、初期投資はある程度必要にはなるが、中長期的にみるとDXを実現することで運用コストが削減できる（はず）、ということを述べてきました。では、残り２つの課題の解決に向けて、どういったことが必要となるでしょうか？
これには大きく２つのアプローチが考えられます。
１つは、現行のビジネス・プロセスを精査することです。いまのビジネス・プロセスをもう一度ゼロベースで捉え直し、業務をしていくうえで感じている課題がなにか、ボトルネックとなっている部分があるとずればどこなのか、昔からの慣習だけで続けているものの、現在の業務や状況と合っていないプロセスがないか、といった観点で１つ１つのプロセスを確認していきます。この精査は、日々の業務を行っている方たちが感じている率直な違和感が重要になるため、ワークショップ形式やブレストなど、関係者全員が膝を突き合わせて考え抜くような、地道な作業の繰り返しが必要となります。
現場サイドの主観や意見に基づく課題の抽出と並行して取り組むべきもう１つのアプローチは、様々な情報のデータ化と、データを利活用・連携・分析していくことで客観的な視点から業務を捉えることです。客観的な視点からどこに課題があるかを、可視化したり数値化したりすることで、手をつけるべき領域や課題に優先度を付けることができます。
このような、データによる課題抽出のアプローチに取り組むために必要となってくるのが、様々な情報をデータ化するための仕組みと、そのデータを利活用し分析するためのITシステムです。
データを活用した仮説設定とすばやい検証
人やモノの状態や状況といった様々な情報をデータ化し、分析や可視化をすることで、これまでにはなかった新しい視点や洞察が得られるようになります。ただし、洞察＝答え、というわけでは決してなく、この段階ではあくまでデータから導き出された仮説のレベルです。データを用いて現状を可視化することで、みんなが体感的にぼんやり思っている、ボトルネックや作業のムダが発生していると思われる箇所を客観的に示し、対策の必要性を全員が認識できることが重要となります。
こうした洞察を得ていくためには、IoTなどの機器や技術を活用して、人の作業や機器の状態をインターネットを介して収集することとあわせて、データによる検証を行うシステムをできるだけ安く・早く・そして簡単に構築できることが求められます。なぜなら、こうした検証自体が多くのトライ＆エラーを繰り返すという前提に立つ必要があるためです。
例えば、AmazonなどのECサイトでショッピングしている際に、ある時にふとボタンの位置がこれまでと違っているように感じたり、同じキーワードで検索しても結果が異なって表示されたりしたが、違う時にアクセスしたら元に戻っていた、といった経験をしたことがあるかもしれません。これは、サービス提供側がユーザー体験の向上を図るために、自分たちが分析したい項目に基づいてユーザーがどういった行動を取るのかを実システムでテストしているためです（ABテストと呼ばれます）。簡単なテストを頻繁に行い、ユーザーの行動結果を分析するプロセスを素早く実施することで、従来型のITシステムでは実現できないようなスピードで、自分たちのビジネスと顧客体験の改善を継続的に続けています。
(
ABテストの概略図。複数の異なるユーザー体験を試行し、結果が良い方を正式に採用する。
また、TwitterやFacebookといったSNSなどは、ときどき新しい機能を突然リリースすることがありますが、それがユーザーに肯定的に受け入れられていないことがわかると、すぐに前の状態に戻すことがあります。方向性の間違いを素早く修正し、元に戻すことで、ユーザー体験へのネガティブな影響を最小限に抑えながら、起きた失敗はムダにせず次の改善に活かしていくことができています。
こうした企業に共通して備わっているものが、自分たちが考える仮説を簡単に実際のシステムに適用でき、またその変更に対する客観的な評価をすぐに検証できる仕組みを構築していることです。言い換えれば、"すばやい仮説の検証と修正のサイクルを継続して実行できるシステム"＝"アジリティの高いシステム"、と言うことができます。もちろん、そうした仮説の検証と失敗を認める文化やチャレンジができる風土、といった企業マインド的な部分も重要となってきますが…
DXとシステムのアジリティとの関係性とは
現場が実施するビジネス・プロセスの精査のアプローチは、言うは易しですが実際には非常に難しいのが実情です。課題となる領域がある程度絞られていれば、その領域に絞った検討ができますが、漠然とDXへ取り組む、というときにこのようなボトムアップなアプローチを取ると、得てして課題が発散してしまいがちで、結果的にどこから手をつけていいかわからない、ということになりかねません。そこに、データによる客観的な問題分析の結果を当てはめることで、DXを実行していくうえでシステムのアジリティを高めていく必要性を、実感と客観性の両面から捉えられるようになっていきます。
このように、２つのアプローチをどちらか片方だけではなく相互に実行していくことが、適切なDXへの取り組みにつながっていくことになります。ようやく、冒頭で掲げた疑問点である「DXに取り組むうえで、なぜシステムのアジリティを高めていく必要があるのか？」の全体像が見えてきた気がします。
システムとビジネスとが互いに融合し、データ分析の結果を用いた迅速なビジネス判断と、その判断をベースとした迅速なシステム改修、そして新たな洞察を得るための仮説立案と分析、のサイクルをすばやく回していくことで、企業としての強さを高めていけるようになります。
例えば、一部の小売・流通業界ではPOSシステムのデータを分析し、売れ筋の商品を把握することで売り場の配置を最適に修正するなどが実際に行われています。また、産業系の業界では熟練者のスキルを後継者へどのように伝達していくかが課題となっており、ノウハウ継承のために、スキルのデータ化と保存、そしてスキルを伝達していくシステムの仕組みを構築する動きが始まっています。
さらに、こうしたシステムを構築することは、いままで蓄積してきたデータや分析によって生み出されたノウハウを、他のシステムやサービスと連携させることによる新たなイノベーションの創出にもつながっていきます。
例えば、金融業界ではオープンAPIと呼ばれるAPI連携の仕組みによって、家計簿アプリなどサードパーティ製のサービスと銀行口座とが連携して、ユーザーが複数の口座を一括でスマートフォンなどから管理することができるようになっています。ユーザーに対する利便性向上だけでなく、そうした利便性が新たなサービス利用への呼び水となって業界全体の活性化につなげていくことが狙いです。
このように、最終的に解決したいビジネス上の課題に対してすばやい解決を目指すためにアジリティの高いシステムを構築することが、DXへの最初の足がかりであり、重要な一歩であると言うことができると思います。
具体的にどうしていくか？
具体的には、マイクロサービスアーキテクチャのようにサービスやアプリケーションの単位を小さくすることで、変更に対する他のサービスなどへの影響をできるだけ少なくしたり、アジャイルのようなすばやい検証を開発プロセスの面から実現するための仕組みを導入することで、システム（とそれを改善していくプロセス）としてのアジリティを向上させ、ビジネス上の変化にすばやく対応できるシステムへ変わっていくことが、デジタル・トランスフォーメーションの一つの目指すべき形です。
昨今の様々なマイクロサービス導入事例にフォーカスをしてみると、まずは自分たちの業務やシステムを注意深く整理し、複雑に入り組んだシステムの中から周囲への影響度の小さい機能、もしくは今後のビジネスとして重要になる機能（システムやアプリケーションの変更可能性が高いと判断した機能）をマイクロサービス化していく、スモールスタートなプロセスを取ることが定石となっています。
前の項までで述べてきたように、データによる可視化をベースとした仮説を立てて優先度が高い課題に絞っていくことで、マイクロサービス化をすべき機能やサービス、といったものがある程度見えてくると思います。小さく切り出してその仮説に対する効果を検証することで、DXの実行難易度や現行業務への影響度、コストやスケジュールなどの感覚も掴むことができるようになります。
また、こうした一部機能を切り出していく際に重要となるのが、既存システムとの連携です。マイクロサービスとして切り出した際に、既存システム内にあるデータベースを参照したり、データの読み書きを実行するケースがあるかもしれません。こうした連携を実現する際に、既存システム側にAPIを設け、外部からのアクセスを許容する仕組みが必要になってきます。また、マイクロサービスとして切り出したサービスが外部向けにAPIを公開することで、他のサービスなどとの連携を促進し、前述した新たなイノベーションを創出する入り口として機能していくことになります。
段階的なマイクロサービスの適用
既存システムとのもう一つの連携手段として、既存システム内に機能自体は残しておき、新しく切り出したサービスと並行で運用していく方法が挙げられます（ストラングラーパターン）。これは、ネットワークアクセスを適切に振り分けるストラングラーファサードと呼ばれるゲートを設けることで、既存システムと新しいサービスとの間でアクセス流量をコントロールするデザインパターンです。こうした仕組みを適用することで、仮に新しいサービス側で問題が発生した際に、ファサードの流量制御を行うことで現行システムへの影響を最小限に抑えられます。また、上で述べてきたようなABテストも比較的容易に実行できるようになります。
ストラングラーパターンによるリスク分散
DXは、様々なトライ＆エラーや想定外の問題が発生する可能性が高い取り組みです。これらに代表される救済措置をシステムとして設け、リスクヘッジを適切に検討しておくことで、トライアルへの心理的な障壁や技術的な障壁を下げることができます。
さいごに
今回の記事では、「DXに取り組むうえで、なぜシステムのアジリティを高めていく必要があるのか？」を解きほぐすことで、DXを今後進めていくためにシステムの刷新が必要になってくることを説明してきました。ポイントは以下です。
- 人やモノの状態や状況をデータ化し、分析することでいまのビジネスの問題・課題を発見する
- 問題・課題への対策を仮説として立てて、素早く検証していく
- このサイクルを継続的に回していくために、新しいデジタル技術を取り入れながらITシステムのアジリティを高めていく
デジタル・トランスフォーメーションという言葉自体がバズワードのようになってしまい、いろいろな人の視点や立場によって捉え方が異なっている状況であると思います。繰り返しになりますが、こうした状況の中で取り組みを進めていくにあたって最も重要となるのが、現場や情報システム部門などの関係者が一体となってDXを達成するための目的を共有していくことです。
きっかけはトップダウンによる大号令かもしれませんが、日々の現場での働きに根ざして、何を技術で検証するのか、何を技術で解決していくのか、を関わる人全員が意識しながら取り組んでいくことで、初めてDXが達成されていくのだと考えています。
謝辞
今回の記事執筆にあたり、図中で利用させていただいたアイコンは以下のサイトのライセンス条件に従って利用させていただきました。
この場を借りて感謝いたします。