コンポーザブルなビジネスとソフトウェア開発の実現：構成可能性の可能性【前編】

「構成可能性」を導入することで、ビジネスやソフトウェア開発の柔軟性が高まる。だが構成可能性とは何だろうか。構成可能性を基礎から解説する。

[Cliff Saran, Adrian Bridgwater，Computer Weekly]

　Red HatのCEOジム・ホワイトハースト氏（現IBM社長）が、基調講演で「コンポーザブル（構成可能）性」という言葉をキーワードとして使ったのは約10年前のことだ。「構成可能な技術の時代について、そして構成可能な技術の構築を開発者がどのように支援するのかについてお話したい」

　アプリケーションは、構成可能な方法で開発する方がモノリシックなアプリケーションを構築するよりもはるかに柔軟で容易になる。

関連記事

• APIは万能ではない――APIではなくRPAを使うべき理由
• コネクターを必要としないAPI開発を実現する「APIスキーマ」

　「個別にテストしてデプロイできる小さなモジュールとしてコードを作成すれば、アプリケーションの統合が容易になり更新がはるかに迅速になる。それは競争上大きな利点になる」と話すのは、IFSのアントニー・ボーン氏（業界担当バイスプレジデント）だ。

　この構成可能性によって、ワークフローの簡素化やビジネスプロセスの最適化を目的としたRPA（ロボティックプロセスオートメーション）、AI、ハイパーオートメーションなどのツールの適用が極めて容易になる。

iStock.com/Traitov

　CoralogixのCEOアリエル・アサラフ氏は、構成可能なビジネスを組み立てていく最初の要素は構成可能な思考だと考えている。「自分の考え方が全ての行動に影響する。決定の指針になるのは何を構成するかだけではない。いつ、どのように構成するかも指針になる。構成可能性という考え方を構築することで初めて、ビジネスアーキテクチャや技術スタックに構成可能性を導入できる」

　では、全てのパーツが独立して機能するように会社や製品をモジュール化するにはどうすればよいのか。

　そこで重要な役割を果たすのが抽象化だ。構成可能なビジネスというアサラフ氏の構想では、組織の技術スタックからビジネスアーキテクチャまで、モジュールに一定レベルの抽象化を与えることでアジリティーを高めることができる。

　同氏は次のように補足する。「抽象化には効果が低減するポイントがある。抽象化し過ぎて全てを『原子』レベルまで分解すると、構成を土台からやり直すことになるので全てが遅くなる」

　アサラフ氏の構想では、各モジュールは完全に自律している必要があるが、各モジュールを連携させることが大きな課題になる。「自律性と抽象化をうまく両立させる必要がある」と同氏は語る。

既製コードの再利用

　Perforce Softwareのロッド・コープ氏（CTO：最高技術責任者）は、ソフトウェア開発者はウィジェットレベルで作業するのではなく、再利用可能なデータベース、クラウド、仮想マシンを話題にするようになったと感じている。導入が急拡大しているオープンソースもそれ自体が構成可能な開発の一形態だ。

　コープ氏が指摘するように、自動化されたIaC（Infrastructure as Code）を使って既製の「Ansible」「Chef」「Puppet」などのインフラコンポーネントをニーズに合わせてカスタマイズするだけならば、アプリケーションの開発速度を上げるのに役立つ可能性がある。

　最終的には、十分テストされたピースを組み立て、アジリティーと品質を高め、高速かつ大規模に提供できるようになるとして同氏は次のように話す。「開発者にとってのメリットは、基本的なビルディングブロックの作成に費やす時間が減ること。より多くのコードをより迅速に提供できること。うまくいけばすぐに使える革新的な思考に費やす時間が増え、アプリケーションに独自の貢献を追加できるようになることだ」

後編では、構成可能性を高めるAPIの利用と注意点、さらなる将来の展望について解説する。