デジタルトランスフォーメーションのための超高速開発基盤！　Vol.3

デジタルトランスフォーメーションのための超高速開発基盤！ Vol.3

デジタルトランスフォーメーションの波が押し寄せる中、ビジネスとITの関係にも新しい形が模索されています。その1つの解として、今ふたたび超高速開発に注目が集まっています。超高速開発というと中には懐疑的な目を向ける方もいるかもしれません。確かにこれを従来のシステム構築ツールの延長としてとらえると失敗の恐れがあるでしょう。その真の目的とは、単なる開発スピードの向上でもコスト削減でもありません。記事では、ビジネス変革ツールとしての超高速開発を解説します。（全5回連載）

Vol.3　デジタル破壊から新しい創造へ、ビジネス変革のための開発とは

生き残る企業と淘汰される企業の違い

デジタル破壊が進み、従来のビジネスの常識が次々に覆されています。もちろんこれまでも旧来のものを破壊し、新たな創造を行うことによってビジネスは進化を遂げてきました。しかし、IoT、ブロックチェーン、クラウド、ビッグデータなど、様々な新しいテクノロジーが急速に浸透しつつある今、その破壊と創造はかつてないほどの勢いで進んでいます。

たとえば米国では、配車アプリのUberがタクシー業界に、宿泊予約のAirbnbがホテル業界に強力なインパクトを与えました。金融業界では新興のFintech企業など、いずれもテクノロジー企業が既存企業の領域に食い込み、そのまま業界全体を変革していく様が見て取れます。これと同様のことは日本のどの業界でも起こり得ます。その時、貴社はイノベーションを起こし飛躍する企業になれるでしょうか。分かれ道はすぐそこまできています。来るべきデジタルトランスフォーメーションに備え、すぐにでも体力の強化を始めるべきです。

超高速開発が注目される理由とは

この変革の核にはビジネスとITのシームレスな連携があります。CIOと情報システム部門に求められる役割は、従来のようなシステムの保守・運用ではなく、新しいビジネスの形をITで創造することになりつつあります。経営/ビジネス部門と情報システム部門の関係は強化され、より積極的なものになっていくはずです。

しかし、現状では既存システムがボトルネックになってしまっているのも事実です。硬直化、肥大化した既存システムは、小さな変更を加えるのにも大がかりな改修を必要としています。かつてビジネスを効率化するために作られたシステムですが、今となってはこれが改革を阻んでいるのです。そして、この既存システムに代わる新しい時代のシステム開発として、超高速開発に注目が集まっているというわけです。

「スピードアップ！」「コスト削減！」では新しいことはできない

ここで一旦、過去を振り返ってみましょう。超高速開発が国内で小さなブームになったのは2010年代の前半頃。まだ記憶に新しい方も多いのではないでしょうか。当時はデジタル破壊の概念は今ほど明確ではなく、超高速開発は概ね外注コスト削減を目的として導入されていました。

しかし、これからのデジタルトランスフォーメーションを乗り切るためには、当時とは少し観点を変える必要があります。経営層→情報システム部→SIerという従来のシステム発注の枠組の中で「従来と同じものを、いかに安く、速く作るか」ではなく、「未来への備えとなるか、変革につながるか」という点に注目したいのです。

また、「仕様書からコードを自動生成するツール」なのに、正しい仕様書が書けずに手戻りが発生するという問題は、当初からついて回っています。この問題についてはここでは詳しく触れませんが、以前の連載で触れたモデリング手法「DMN（Decision Model and Notation）」、自立的な業務の可視化分析手法「BPEC/B-NASS」に解決の糸口を見出すことができるでしょう。

デジタルトランスフォーメーションを成功させる超高速開発

超高速開発といえども、従来と同じ使い方をしただけでは、コスト削減などの「従来通りの効果」しか得られません。抜本的な改革が求められている今、既存の機能の再現ではなく、革新的な機能を実装することにフォーカスする必要があるのです。未だ形のない将来のビジネスを表現するには、プロトタイプをどんどん作成して検証していくべきであり、その時、超高速開発が実に使える手法だということです。

そして、同時に必要になってくるのが開発と変更要求に耐えうるリソースセットを広範に見つける方法となるビジネスルールアプローチです。ビジネスからの変更要求でシステムの仕様ががらりと変わってしまったとしても、ビジネスルールありきの体制を敷いておけばそう恐れることはないのです。

ビジネスルールの分離を適切に行うためには、BRMS（Business Rule Management System）のようなツールを採用することも必要になります。Progress CorticonのようなBRMSならば平易な表現でルールが記述されるため、ITの専門家でなくとも仕様を読み解くことができるようになり、経営/ビジネス部門と情報システム部門の関係はより緊密になるはずです。

BRMSとは？