デジタル化社会を生き延びる
現代的な企業システムへの進化

今月号から新たにスタートする本連載。『15Stepで習得Dockerから入るKubernetes コンテナ開発からK8s本番運用まで』の著者である日本IBM テクノロジー事業本部 ハイブリッドクラウドCTO 高良真穂氏が、「コンテナによる企業システムのモダナイゼーション」をテーマに、コンテナ技術が企業システムに与える影響と変革を解説していく。本連載からビジネスにつながるヒントを見つけ出せるだろう。

 社会がデジタル化された未来を見据えて、企業の生き残りを願うならば、業務システムのモダナイズの必要性が見えてくる。ところが業務システムを数多く抱える企業は、モダナイズの価値や意義を見いだせないという憂慮すべき現状がある。この問題について、誰もが一度は利用した経験がある宿泊施設の仲介サイトを例に考察してみたい。

 次の図1左側は、宿泊仲介のWebサイトだ。ホテル、旅館、リゾートマンションなどの中から、予算、食事、温泉などを比較して、気に入ったところを予約できる。仲介業者のフレームワークに沿って、宿泊事業者が情報を登録することで、Webサイトが成り立っている。

 一方で、図1右側に表した統合型仲介サイトも登場してきている。旅行したい地域の宿泊施設を決めると、航空券や鉄道のチケット予約、現地のレンタカー予約が提案される。まとめて予約することでお得な割引が適用される。何よりも、宿泊と移動を別々に手配する手間がなく、パック旅行のような手軽さがある。この図1の左右を比較して、どちらが生き残るかは明白だ。

 この右側の仕組みは、各社の業務システムの機能の一部をAPIサービスとして公開することによって、統合型仲介サイトと連携している。APIとは「Application Programming Interface」の略で、APIサービスはプログラムなどのマシンを相手に開設されたWebサーバーである。人がWebページをアクセスするのと同様に、他の事業体のシステムが、検索や注文を実施できるようにインターネットへ向けて公開されている。

 このようなAPIサービスの連携は、個人を相手にしたBtoCだけではなく、企業間の取引であるBtoBを含め、さまざまな応用がある。例えば、ビジネスでの出張、住居契約と引っ越し業者、自動車の購入と駐車場業者などだ。製造業においては、個人の趣味嗜好が重視されるようになり、少量の生産量で多彩なオプションを選択できることが望まれる。この要求に応えるには、サプライチェーンを構成する各社がAPIサービスで連携することで、ユーザー満足度と在庫最適化を両立しなければ生き残れない。

プログラム言語に依存しないREST

 次に、業務システムをモダナイズするための技術や開発手法について解説を進めていく。APIサービスを社外へ公開する技術では、「REST API」がデファクト・スタンダードになっている。RESTは、「REpresentational State Transfer」の略で、特徴を表す適当な訳語が見当たらないので、筆者は「URLによるプログラムインターフェース」と意訳している。これは厳格な規格ではなく、シンプルでスケーラブルなAPIを設計するための「設計原則」である。

 RESTを使うことの利点は、Webページをアクセスするのと同じHTTPを利用できることだ。他の分散システムのプロトコルと比べても分かりやすく、URLによって対象機能が表現され、HTTP GET/PUTなどのメソッドによって操作が決まる。そのためプログラム言語に依存せず共通的な表現と操作が可能となる。

 さらにREST APIでサービスを公開するために、特別なソフトウェア製品を購入する必要はなく、オープンソースソフトウェアのプログラム言語のフレームワークで実装できる。このことからREST APIは多くの人に受け入れられ、普及している。例えば、AWSなどクラウドの利用を、プログラムによって運用を自動化するAPIもRESTが標準になっている。

マイクロサービスによる開発機動力

 ビジネスのデジタル化が進むと、ソフトウェアの改修なしにビジネス変化に対応できない時代がやってくる。しかし、従来のカルチャーで開発されたソフトウェアの改修には、少なくとも1年程度を要することも稀ではない。これではリリースされる頃には、ビジネス環境は次の段階を迎えているかもしれない。この課題にはアジャイル開発手法が有効である。この特徴は、小さな開発サイクルを何度も繰り返すこと。および、詳細な仕様書を作るよりも、ユーザーが実際に使えるソフトウェアを作ることを重視する。このような開発手法によって、仕様変更に柔軟に対応でき、各サイクルのリリースまでの期間を数週間程度に短縮できる。

 アジャイル開発を実践するためには、「マイクロサービス」と「コンテナ技術」は欠かせない。これらは開発サイクルを頻繁に繰り返すことを容易にする技術的な効果があるためだ。ところが、マイクロサービスの捉え方には混乱を感じる。情報システム部門の責任者と議論すると「マイクロサービスの粒度はどうすれば良いですか?」という質問を必ず受ける。その名前から連想を誘発すると思うが、その背景には「Service Oriented Architecture」(SOA)の影響がある。SOAは、一つの業務処理に相当する単位でサービスに分解して、業務システムを再構成するもので、変化への対応を迅速化する思想があった。しかし、マイクロサービスは業務単位に分割することを強く推奨するものではない。マイクロサービスが重視するのは、業務システムの開発規模をちょうど良いサイズに維持することで、開発チームのパフォーマンスを最大にすることにある。

 ただしマイクロサービスは良い点ばかりではない。マイクロサービスに分割することは、ソフトウェアの複雑度が増し、機能の重複も許容しなければならない。そのため開発者と運用者の負担が大きくなることから、システムが小さな規模のうちから、マイクロサービスとして細分化するべきではないとされている。

 ここまで述べてきたように、社会のデジタル化のなか企業の情報システムは、社外へ開かれたシステムへと変貌し、取引先企業や消費者とつながる経済圏(エコシステム)の一部となる。この時代の要求に答えるためマイクロサービスやアジャイル開発手法が確立されてきた。しかし、このような変化に対応できない、言い換えると、業務システムをモダナイズしない企業の衰退は、疑いの余地がない。

 マイクロサービスは痛みを伴うアーキテクチャであるが、その欠点を克服して、ビジネスの力に変える潮流がある。次回は、その世界的なオープンソースの活動について話を進めて行きたい。