APIエコノミー時代の
ローコード向け開発方法論
AGILE-DX
AGILE-DX（アジャイルディーエックス）は、APIエコノミーの拡大による開発プロセスの変化への対応および大規模なアジャイル開発を実現するためのローコード向けの開発方法論です。
組織の課題を解決致します
本サービスは様々な課題を抱えるお客様企業に適しています。
- 大規模なプロジェクトでアジャイル手法を導入したい
- 変化し続ける顧客のニーズに迅速に応えたい
- 開発効率を上げると同時に品質確保もしたい
日本国内のアジャイル開発導入が遅れている理由は
「自前主義」「外部ベンダー企業への依存」「CIO設置率の低さ」
世界各国ではアジャイル開発手法の普及が進み、採用率は年々高まっています。変化の激しいビジネスニーズに迅速に対応するアジャイル開発は現代に適したアプローチと言えますが、なぜ日本ではアジャイル開発の導入が遅れているのでしょうか。その理由として「自前主義」「外部ベンダー企業への依存」「CIO設置率の低さ」の3点が挙げられます。
「自前主義」による
新技術導入の遅れと人材不足
ビジネスモデル自体の確変を含めた新たな商品の開発を次々に行うことが求められている中で、自前主義での対応では規模や範囲の経済性によるコスト削減とスピーディーな開発ができなくなっている※1
「外部ベンダー企業への依存」による
生産性と意思決定のスピードの低下
ユーザー企業がベンダー企業に要件定義から丸投げの状態になってしまっているため、アジャイル開発のようにユーザー企業にコミットメントを強く求める開発手法を推進できない※2
「CIO設置率の低さ」による
IT活用での経営戦略の遅れ
日本企業で専任のCIOを設置しているのは全体のわずか3%で、専任と兼任を合わせても約14%に留まる。金融業界は約39％と高いが、包括的に日本のCIO設置率は低く、ITの有効活用が遅れていることが伺える※3
CIOによって整備されるビジネス
アーキテクチャの重要性
国内企業における大規模システムの導入フローは、 まず最初に「技術とベンダーを決定」し、「RFPによりプラットフォームやベンダーを選定」そして「システム要件定義」によりフィット＆ギャップ分析を実施します。そのうえで設計・実装に取り掛かりますが、要件定義を実施する前にベンダーを選定していることから、フィット＆ギャップの結果次第では設計や実装段階で工数が跳ね上がるという問題を抱えています。米国のシステム開発の例では、CIOによってビジネスアーキテクチャ（BA）とよばれる企業設計書を要件定義の前に整備しています。BAを土台としてシステム要件定義をを行い、それに伴い採用する技術とベンダーを選定することで、開発工程を最も最小にする選択をすることが可能になり、その後の設計・実装を計画通りの工数で進めることができます。
ビジネスアーキテクチャがなければ大規模なアジャイル開発は困難
国内で行われてるアジャイル開発の多くは、漠然としたシステム開発のイメージを元に要件定義や基本設計・詳細設計をチーム毎にパラレルに実施しています。しかし5～8名程度で実施する小規模な開発に適した手法と言われるアジャイル開発を大規模システム開発に採用すると「出来上がったそれぞれのパーツがかみ合あわない」という問題が多発します。しかし全体の設計書であるBAが存在することで、BAに従った要件の分解が可能になり、パラレルに開発を実行したとしても全体の整合性がとれた成果物を作成することができます。
米国企業が実施するアジャイル開発手法をそのまま導入するのみでは大規模アジャイルの実現は困難である現状、そして国内のCIOの設置率が低いことから、BAの有無により大規模アジャイルの成功率が大きく変化すると言えます。
DXレポートが求める「APIによる大規模なシステムの開発」
また、DXレポート※において「ベンダー企業の目指すべき姿」として、「要件変更を前提とした対応ができるアジャイル開発の活用ができる」「システムを小規模でモジュール化された機能に分割し、短サイクルリリースを実現ができる」そして「API/Web API ベースの疎結合構造により小規模サービス化が進み、大規模なシステムのコストとリスクを大幅に低減できる」の3点が挙げられています。
アジャイル開発の活用
要件変更を前提とした対応ができるアジャイル開発を活用できる
短サイクルリリース
システムを小規模でモジュール化された機能に分割し、短サイクルリリースができる
API ベースの疎結合構造
API/Web API ベースの疎結合構造により小規模サービス化が進み、大規模なシステムのコストとリスクを大幅に低減できる
※経産省 DXレポート「IT システム「2025 年の崖」の克服と DX の本格的な展開」
APIとはコンピューター間でデータをやり取りするための仕組み
APIとは、アプリケーション間でデータをやりとりする仕組みのことを指します。ユーザがWebにアクセスしデータを参照するといった日常的に行われているフローもAPIで実現されています。今日においては、Webサイト上で「Web API」として利用されており、また他社が提供するさまざまな機能をAPIを経由で互いに利用できるエコシステムを「APIエコノミー」と呼び、API経済圏とも呼ばれています。
2011年以降、世界中でREST APIの標準化が進み、様々なITシステム間で互いにデータ連携が可能になっている
APIエコノミーはシステム開発のスタイルを大きく変化
APIエコノミーはシステム開発のスタイルを大きく変えています。たとえば、配車システムを作ろうとしたら、地図のAPI、通信のAPI、決済のAPIを組み合わせ、UIを作れば、2週間ほどで大体できあがります。これは、自前主義をやめてコモディティ化されたサービスを活用してシステムを作る「新しい開発プロセス」です。
API中心のシステム開発は「国際的な競争力を確保」するための第３の選択肢
弊社はこれまでの「国際的に導入実績のあるパッケージソフトウェアの導入」と、「自前主義を前提とした外注依存のスクラッチ開発」に加え、「APIを組み合わせたシステム開発」が第三の選択肢になると考えます。
国際的に導入実績のある
パッケージソフトウェアの導入
自前主義を前提とした
外注依存のスクラッチ開発
API中心のシステム開発
APIエコノミー時代のローコード向け開発方法論「AGILE-DX」
昨今では、スクラッチ開発の多くがローコード開発に移行し、ソフトウェアはクラウド化の一途を辿っています。これから訪れる「APIエコノミー時代」においては「ローコード開発によるアプリケーション」そして「ローコード開発によるAPI」の2手に別れていくと考え、APIエコノミー時代に対応した新しい開発方法論として「AGILE-DX」をご提供しております。
APIエコノミーの拡大がアプリケーションの開発プロセスを変革しています
様々な部品をピッタリと結合しない状態でシステムを作り上げる
従来のシステム開発は、部品をきれいに設計し、パズルを合わせるように結合テストを繰り返し大きなシステムを作っていくフローが一般的であり、そのため「一つの部品が合わなければ周りの部品を全て作り変える」という非常に細かい作業が発生します。
AGILE-DXでは、多種多様なお互いの影響を受けないAPI同士を連携してシステムを作成するため、あらかじめパズルのピースが合致しないことを前提に開発を行います。繰り返し結合テストを行うのではなく、「イングレーション基盤で結合の開発を最後に行う」開発方法論です。
部品を結合するのではなく「サービスを統合」するアーキテクチャを採用
従来のAPIを活用した開発では、部品を組み合わせてコンポーネントを作成し、その後にアプリを作成しますが、AGILE-DXでは各部品が自律的に動作し、それらをインテグレーションの基盤で結合することで大規模なアプリケーションを作成するという、API利用に特化したメソッドで開発を行います。
これまでの密結合な開発
「AGILE-DX」の疎結合な開発