OutSystems という衝撃

どうも。あうとです
ローコードを比較検討したときの衝撃を受けた話です

OutSystems の何に衝撃を受けたか

ローコードの導入に伴い、様々な比較検討を行なった中で、衝撃を受けた点をまとめます。衝撃を受けた内容をビジネス目線、マネジメント目線、エンジニア目線の3つの観点で整理しました

ビジネス目線

ビジネス変革のスピードとシステム構築の時間軸のギャップの解消

コーポレート IT 部門にいるとビジネス部門の要求があっても、提供時期が遅くなりがちで、半年待ちや1年待ちということはよくあるケースではないでしょうか

これらの課題を解決するためにローコードやノーコードによる市民開発というアプローチも取られている。ちょっとした便利ツールであれば構わないが、ビジネスのコアな部分のシステムを市民開発型で実現することは現実的ではなく、個人的にはあまり賛成はできない。もちろん会社規模、部門編成状況、エンジニア組織状況によって一概には言えません

こういった時間軸の目線でいうと従来のフルスクラッチ型の開発よりも、圧倒的にユーザ部門の期待に答えることができる仕組みであると感じた。システムや機能のローンチが1ヶ月早いだけで、ビジネス効果が違うということを理解していくべきと感じます

システム開発時の社内プロセスが煩雑な中で、プロトタイピングができる

社内でフルスクラッチ型の開発を行う際に、予算面やスケジュール面の調整を行いりん議など社内プロセスを通している間に、OutSystems によるシステム開発では、プロトタイピングが完了できる

特に VUCA 時代の昨今においては要件定義したものが、ローンチした際には状況が変わっているということ、数年で使わなくなること、改修要望が来ることは多々起こりがちです

新規事業でも MVP 開発をする際に利用する、業務システムでもプロトタイプを作成したあとに予算やスケジュールの策定を行うなどよりアジャイルなシステム開発が可能になってきます

OutSystems によるシステム変更の容易さはもちろんですが、プロトタイピング型でシステム構築することがビジネス目線で必須になると感じます

エンジニアの主体的なシステム開発が可能になる

従来の情シス的な開発の進め方に於いては、ビジネス部門からの要望でシステムを開発することがほとんどだと思います。生成 AI を含めたテクノロジーが非常に発達した昨今では、ビジネス部門のニーズから起因する受動的なシステム開発ではなく、エンジニア部門の主体的なシステム開発が求められている状況であり、今後加速していくと思っています

こうした背景の中で前述した OutSystems のプロトタイピング型開発行えることが、エンジニアの主体的なシステム開発が可能になり、ビジネス的価値を生み出せると感じます

マネジメント目線

エンジニアに価値の高い仕事に注力してもらうことができる

エンジニアの価値という話なので、会社によって様々だとは思います。私の会社の場合は事業会社であるが、IT によって収益を上げにくい BtoB 型のビジネスもでるのため、IT 投資が遅れがちで IT エンジニアも少ない状況です

こうした環境においてエンジニアに求める価値としては、ビジネスへの貢献と言っても生産性の向上や効率化といった目線が強くなりがちです。そうした環境においてのエンジニアの価値はコアなテクノロジーは子会社にまかせていき、IT 戦略を描き、システムのグランドデザインを描き、ビジネス課題を理解し、課題解決を推進することが価値となってきます

アプリケーションやインフラなどのテクノロジーよりもビジネス課題の解決できる人材が価値が高くなっていきます。自社に必要なエンジニアの定義ができ、価値の高い仕事にリソースを注力することができるようになります

自社のエンジニアをコアコンピタンスに集中させることができる

価値という話をしましたが、すべてのシステムを OutSystems で構築することが良いとは思いません。コモディティー化されない、独自の仕組みや差別化要因とすべきシステムは、従来のフルスクラッチ型のシステム開発も積極的に進めていくことが大事です

エンジニア不足時代に突入している中で、Ousytems とフルスクラッチ型の開発をうまく組み合わせることで、エンジニアリソースの選択と集中を描けるようになると感じました

事業会社のエンジニアに求められるものはビジネス変革やビジネスへの貢献が可能になる

これまで記載したように、事業のコアコンピタンスを見定め、エンジニアに価値の高い仕事にリソースの選択と集中を進められるようになるわけですが、ビジネス変革やビジネスへの貢献という集中を進めていく必要があります

エンジニアにビジネス変革やビジネスへの貢献を求めるということはマネジメント側からはマインドチェンジを促していく必要があり、非常に難しい問題ではありますが、 OutSystems を用いることによってマインドチェンジを促すことができると感じました

非 IT エンジニアの採用や育成が容易になる

事業会社だが、 IT 事業会社ではないため、非 IT エンジニアが多く存在しています。DX という流れを受け、非 IT エンジニアのキャリア変更により、IT　エンジニアを希望する方も増えてきています。一方で IT エンジニアは数多くいるわけではありません。非 IT エンジニアに IT エンジニアの基礎を勉強して、実装してもらうことは環境的には難しい

こうした状況で OutSystem を用いて IT エンジニアの基礎を習得してもらい、Web アプリケーションの基礎を理解してもらうことができるために、人材育成にも有効的だと感じました

小規模から中〜大規模への対応力

ローコードを検討していた際に、システムの規模の大小問わず対応できるものを優先していきたいと考えていました。これは少ない IT エンジニアが複数のローコードやノーコードを対応していくことは困難であると判断したからです

OutSystems を用いることによって、小規模システムから中〜大規模のシステムまで網羅的に対応ができるため、育成や限りあるリソースの選択と集中が可能になると判断しました

IT エンジニア目線

Web アプリケーションのお作法から逸脱しておらず、直感的であること

他のローコードではシステム開発を容易にするために独自の概念や仕組みを用意して、より開発しやすいように工夫されているものが多くあります。しかし、エンジニアにとってはそれが弊害となり、覚えることが増えてしまい習得障壁が高くなっていきます

一方で OutSystems の場合は3層 Web アプリケーションを把握しているエンジニアにとっては理解が容易です。JS/CSS, Logic, Database などこれまで学んできた知識をそのまま活かせると感じました。逆に OutSystems から Web アプリケーションの仕組みを理解した人は、OutSystems 以外のマネジメントにもチャレンジしやすいということになります

汎用的なライブラリの作成が容易であること

マイクロサービスや汎用性、共通化がなされていないシステムが多い環境のため、システムや担当者のサイロ化が起こっています。この状況のなかでシステムを切り替えていくことは時間と費用が膨大にかかってしまいます。

これらの課題を解決するために他の SaaS との連携や OutSystems をもちいることにより、ドメイン別のシステムへの変更やマイクロサービス化、共通ライブラリ化を推進できると感じました

これからの WEB アプリケーション開発

もう少し簡素に書こうと思ったのですが、長文になってしまい、衝撃が何だったのか分かりにくくなってしまいました

Cloud を利用した開発から SaaS をつなぎ合わせていく構成へ

AWS, Azure, Google Cloud など様々な Cloud 技術をしっかりと理解することも必要ですが、そこまでの技術力がなくても、OutSystems を習得することでビジネス的な価値を出す事が可能です。以下の3つのシステム分類を進めることにより、様々なエンジニアのスタイルにも適用することができると感じました

• コアコンピタンスの差別化を行うためのコアシステム

• OutSystems を用いたコアシステムの周辺の柔軟なシステム

• コモディティー化された SaaS を用いたシステム

これらの3つの分類でシステムを構成し、そのシステムの中心にデータ基盤を配置し、すべてを IaaS で繋いでいく構成になっていくのではないでしょうか。ローコードを検討していただけなのですが、OutSystems に出会うことによって、ここまで描くことができたことが一番の衝撃でした

生成 AI がローコードを作る時代へ

さて、最後に PowerApps も AppSheet も AI を用いたアプリケーションが組み込まれ始めています。おそらく OutSystems もその流れを受けて AI でのアプリケーション構築ができるようになる日がまもなく来ると思います

その日まで OutSystems の仕組みをしっかり理解しておくことが AI でのアプリケーション開発時代に於いて、さらにエンジニアの価値がでてくると感じています