IT人材不足緩和のカギは「ローコード開発」　セールスフォース・ドットコムが描くアプリケーション開発の未来

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

田中宏樹氏：ありがとうございます。このセッションは「Salesforceで変わるこれからのアプリケーション開発と開発者の働き方」です。それではさっそく始めさせていただきます。

まず、Salesforceはみなさまの支えがあってはじめて成長できるビジネスです。Salesforceをふだん利用してくださっているみなさまはもちろん、多くのセッションの中から本日このセッションを選んで足を運んでくださったみなさま、そして、コロナウイルス等で大変なところ今日のために準備をしてくださった関係者のみなさまに、まずはこの場を借りてお礼を言わせていただきます。ありがとうございます。

それでは本題に入っていきます。その前に本日のスピーカーの紹介をさせていただきます。私はセールスフォース・ドットコムでデベロッパーエバンジェリストをさせていただいております、田中宏樹と申します。どうぞよろしくお願いします。

少し経歴をご紹介させていただきます。私は高校からカナダに留学しておりまして、大学もそのままカナダの大学に進学しました。大学時代はソフトウェア工学のオプションつきで、コンピュータサイエンスの学位を取得して卒業しました。その間、主にコンパイラの理論の学習であったり、簡単なJavaのコンパイラを構築したりしました。

卒業後に帰国して、日本の大手IT企業に就職できたのですが、そこで証券の営業員向けCRMシステムの開発における上流工程、いわゆる概要設計や品質保証を担当して、そのあと保守・運用なども担当しておりました。

ただ、やはりどうしてもコードが書きたいと思っており、そのときにたまたまセールスフォース・ドットコムからお声がけをいただきました。

私はそのときセールスフォース・ドットコムという会社は知らなかったのですが、一応面接に入る前に「業務時間の何パーセントをコード書いてますか？」って聞いてみました。そうしたら「80パーセント」って言われたんですね。その瞬間、私は面接に進むことを決めました。

結果として、エンジニアとして入社し、コードを書きながら4年間エンジニアをしておりました。その間、約270社ほどの案件に携わりました。主に画面の開発やSalesforceの機能のフィジビリティー確認が多かったのですが、スキルがついたおかげで趣味で参加していたSPAJAMやMUFGハッカソンといったところでもいい成績を残せることにつながりました。

そして去年、Developer Evangelistへと社内転職いたしました。今はSalesforceの開発に携わっている開発者の方に向けて、最新の製品情報や開発のTipsなどを紹介しています。

ただ、今回はSalesforceの開発者にかかわらず、IT企業やユーザー企業で一般的な開発に携わっている方々も対象にした内容になっていますので、どうぞ最後までお付き合いいただければと思います。

DXを推進するために、システムの内製化が積極化

本日お話しする内容なんですが、このようなことを中心にお話しさせていただく予定です。

今世界中で急速に広まっているデジタルトランスフォーメーション、DXと訳されたりしますが、これに適用するため、近年、多くの企業でシステムの内製化を推進する動きが見られるようになりました。

また、さらなるイノベーションを促進するために、政府が小学校にプログラミング教育の必修化を計画していたり、Salesforceをはじめとするプラットフォーマー各社が、より多く人材がアプリケーション開発に参加できる環境の整備を進めています。

これからの10年、アプリケーション開発の現場がどのように変化していくと予想できるのか、開発者はどのようなスキルやマインドセットを身に着けていく必要があるのかをお話しいたします。後半は、今後も広がり続けるデジタルトランスフォーメーションに対してセールスフォース・ドットコムは企業としてどのようなソリューションを提供しているのか。そしてそれらをどのようにみなさんに使っていただけるのかをお話したいと思います。

みなさん日々感じていらっしゃるかもしれませんが、ビジネスは大きく変化しています。高速に進化するテクノロジーに合わせてユーザーの期待値がどんどん上昇しています。企業においても新しい顧客体験を提供してより多くの顧客を獲得するための競争が激しくなっています。

例えば電子決済です。電子決済は比較的新しい技術ですが、それを利用できない店舗では不便さを感じてしまうほど、消費者がその便利な体験に慣れ始めているのです。つまり、今のビジネスでは、最新のテクノロジーの活用でイノベーションを創出しつつ、ユーザーの期待値を超える体験を提供することで競争力の強化が必要な時代になっています。

とはいえ、そんななか多くの企業は課題を抱えています。次々と生み出されるテクノロジーを追いかけながら、新たな活用方法を考えなければいけません。これまで通りの外注によるアプリケーション開発では、テクノロジーの進化に追いつけないと感じ始めています。そのため、より高速なアプリケーション開発の体制や仕組みが必要だと考え始めているわけです。

結果として、こちらにあるように、約25パーセントのユーザー企業で、すでに社内システムの上流工程の内製化を始めているそうです。

プログラミング思考を身に着けた人材の増加

一方で、そのようなユーザー企業を開発者たちは、いったいどのように見ているのでしょうか？　そういった企業で働けば、最新のテクノロジーにキャッチアップできると考えている開発者もいるようです。ユーザーとの距離が近くて直接的で正直な評価を受けられるということで、主体性とやりがいを感じられるといった前向きな開発者も増えています。つまり、開発者を含むIT人材にとって、ユーザー企業はより魅力的な職場になってきています。

この動きはIT人材市場へも影響を及ぼし始めました。IT企業に集中していたIT人材は他業種の企業に散らばり始めています。日本は長年慢性的なIT人材不足に悩まされていると言われていますが、これはイノベーションを生み出す力をどんどん低下させてしまいます。このままではビジネス・企業・業界によらず、日本全体の成長力や競争力の低下につながると予想されています。

それに対して、政府も対策を進めています。みなさんもご存じの通り、2020年に小学校でプログラミング教育の必修化が検討されています。

ただ、文部科学省によると、プログラミング教育はプログラミング的思考などを育むことが目的で、コーディングを学ぶことが目的ではないとしています。

私の解釈も入っていますが、プログラミング的思考というのは、意図した活動を実行するため、実現するためにどのアクションをどう組み合わせればいいか、それを論理的に考えて結果を予想する力だと思います。

例えば、私が今から前に3メートル出たいとします。このときに私ができるアクションは「前に進む」と「右を向く」だけだったとします。この「前に進む」と「右を向く」という2つのアクションを組み合わせて前3メートルに移動した場合、私はテーブルに阻まれているので、まずは右を向かなければいけません。

そして前へ出た上で、今度は左を向かないといけませんが、「左を向く」というアクションを持っていません。したがって、右に3回向くことで左を向くわけです。そしてまた前へ出て左を向くためにまた右に3回回ります。こうすることで、また左を向いて、前へ出て、右を向くと、3メートルほど前に出られるわけです。

こういった基礎的なアクションを、前にテーブルがあるからできないという理由で右を向きましたが、これは条件分岐ですね。その上で、3回右に回るを繰り返して左を向くというアクションは、繰り返し、ループになります。

こういったコーディングに近いことを考えながら、それを現実世界に当てはめて組み合わせて、自分がやりたい行動に置き換えていく。実行する前に組み立てて、それを予想する力。こういったものを学んでいると解釈しています。

結果として、コードは書けないけれどもプログラミングの考え方を理解した人材が、早ければ今から10年後には人材市場に溢れてくるのです。

ローコード開発環境の整備への投資が活発に

とはいえ、プログラミング教育だけではイノベーションを起こせる人材は足りないと思っています。なぜなら、ビジネス視点で言えば、テクノロジーというのは活用できなければ意味がありません。テクノロジーを活用するには、やはりアプリケーション開発が必要です。プログラミング的思考だけではコードは書けないので、イノベーションを起こすには不十分だと思っています。

なので、コードを書けなくてもアプリケーションを開発できるようなツールが必要になります。そんな夢のあるツールを作っている人たちがこちらにいるわけですね。

今、ローコードでアプリケーションを構築できる開発環境の整備が進んでいます。ローコードと呼ばれる、コードを書かずにマウス操作や設定変更のみでソースを自動生成できる技術があるんです。ここに並んでいるような多くのプラットフォーマーたちがローコード開発環境への投資を始めています。

またGartnerによると、2024年までにローコード開発がアプリケーション開発全体の65パーセント以上を占めると予想しています。これもコードを書かずにアプリケーションを開発する時代が近づいていることを示唆しています。

では、ローコードによるアプリケーション開発が広がることの影響は何なのでしょうか？　IT企業やIT部門に限らず、プログラミング的思考を持った人材が開発に参加できるようになるわけです。

こういった人材はシチズンデベロッパーと呼ばれています。専門的なコーディングスキルを必要としないので、このシチズンデベロッパーの開発への参加が期待されていて、将来的にはIT人材不足も緩和されていくと期待できます。

まとめると、10年後にはプログラミング的思考を持っている人材が今よりも進化したローコード開発に出会うので、アプリケーション開発の現場がどんどん変わっていくと予想できるわけです。

「ローコード」とは何か？

さて、そもそもローコードとは何なのでしょうか？　ローコードというのは、2014年、米国Forrester Research社が誰でも開発を行うことのできる手法を指す言葉として使ったのがはじまりです。マウス操作で部品を組み合わせたりキーボードで値を入力するだけでアプリケーションの構築が可能になるものです。

とはいえ、実際には実現できることに非常に多くの制限があります。そのため、複雑な要件を抱えている開発者からはどうしても敬遠されている状況にあります。

そもそもローコード開発のはじまりはモバイル開発です。当時、モバイル開発はマルチデバイス対応。iPhoneだったりAndroid、いろんなデバイスがありました。それに対応しながら、複雑な要件にも対応しながら、かつ革新的なUIを生み出し続けなければいけませんでした。そのためには、コーディングによる開発ではやはり間に合わなかったので、開発速度を上げるためにローコードが注目されたのです。

ところが、やはりモバイルアプリに要求される多彩な表現を提供するには、ローコードではとても最適とは言えなかった状態でした。その結果、モバイルアプリでのローコード開発はどんどん下火になっていきました。

その後、新たなローコードの活用方法が見つかりました。ユーザー企業は高速なアプリケーション開発手法を求めています。とくに社内で利用する業務アプリケーションについて言えば、UI/UXよりも業務の効率化、いかに業務を効率化できるのかが重要視されていたので、ローコード開発との相性がすごくよかったのです。

また、ローコードは専門的なコーディングスキルを必要としないので、少ない学習コストで習得可能というところも、人材を確保できない企業にとっても朗報ですね。そういった流れで、業務アプリケーション開発分野でのローコード開発に注目が集まっています。

ローコード開発のメリット

もう少しローコードへの理解を深めるために、ローコードのメリット・デメリットとを整理しておきましょう。まずはメリットからです。

少し繰り返しになる部分もありますが、ローコードの開発では、マウス操作で部品を組み合わせたりキーボードで値を入力するだけでアプリケーションロジックを自動生成できます。また、多くのビジネスでは同様の業務があります。したがって、一定数の部品が揃っていれば、ほとんどの業務ロジックがカバーできてしまいます。

通常の開発においてもみなさんはCI/CDを使って開発の効率化・自動化をしているとは思うんですが、やはりコードを書くのと書かないのではスピードに大きく差が出てます。そういった意味では高速化というところに1つメリットがあります。

2つ目は、学習コストが低いため、人材育成と確保が容易になること。専門的なコーディングスキルを必要としないので、変数・ループ・条件分布などの基本的なプログラミング的思考を持っていれば、非常に少ない学習コストで習得が可能です。

加えて、IT部門の開発者だけでなく、営業部や企画部、事業部のふだんはユーザー側の社員もシチズンデベロッパーとしてアプリケーションの開発に参加できるので、人材不足の解消にもつながります。

そして3つ目が、開発者の負担が減って、システム全体の品質が向上するというところです。シチズンデベロッパーの参加によって、アプリケーション開発に必要な人材が揃えられるようになります。そのため個々の開発者の作業の負担が減ります。それも開発者が多くの機能をコードを書かずに構築できるようになるので、より価値があって重要でおもしろい機能の開発に集中して取り組めるようになります。

このように、自動生成と負荷分散、役割分担というところによって、システム全体の品質向上にも取り組めるチームになっていくと予想できます。

デメリットと今後の進化

では、デメリットを見ていきましょう。

複雑な要件に対応できません。現状では複雑な表現に対応できるほどの応用は利きません。複雑な要件を基礎的な部品を組み合わせて実現しようとすると、必要以上に手数が増えてかえって時間がかかるだけでなく、結局スパゲティコードのような複雑なものができあがってメンテナンスができなくなってしまうので、そういったものはできるだけ避けるべきです。

ただ、これも基礎的な部品だからダメなのであって、ユースケースに合わせて部品の粒度が変わればもっと使いやすいものになるはずです。

例えば、私はさっき3メートル前に出るために「右に向く」と「前へ向く」というアクションしか持っていませんでしたが、もし「私が前へ出る」と「前の障害物を避ける」というアクションを持っていれば、もっとシンプルにいけたはずです。

ただ、そうすると私は前にしか進めないということになります。聞こえはいいのかもしれませんが、汎用性が低いんです。「右を向く」というアクションを持っていたから、このテーブルを迂回することもできましたし、もっと遠くに行くことも、もっと右に寄ることもできましたし、左に寄ることもできたわけです。

つまり、ユースケースの研究が進めば、最適な粒度の部品を揃えられるようになって、もっと使いやすくなります。

デメリットの2つ目は、シチズンデベロッパーにとって複雑すぎるということですね。いくら学習コストが少ないと言っても、シチズンデベロッパーの方が開発に参加するにはやはり敷居が高いと言われています。

ここもローコード開発環境のUI/UXをどんどん洗練していって、学習リソースからテクニカルな用語をどんどん消していけばよりとっつきやすいものになっていくと思うので、これからの10年の進化に期待しているところではあります。

開発言語の進化とローコードの位置づけ

もう1つ別の視点、開発言語の進化という視点からローコードの位置づけを見てみましょう。

1940年頃に登場した低級言語、アセンブリ言語などは細かい単位でCPUに直接命令を送れるので自由度が非常に高いんです。自由度が高い反面、複雑性が高くなってしまう。どうしても書くコードが長くなってしまう。そういったところでやはり難しいので、利用者が限られてしまいました。

その後1950年頃、Cをはじめとした高級言語がどんどん出始めてきました。この頃になると、処理がどんどん想像しやすくてモデルの構築も簡単になってきたことで、より多くの開発者が開発に関わり始めました。一方で、セキュリティへの配慮や想定されるユースケースによって言語はどんどん枝分かれしていって、それぞれの言語での自由度は狭まってきました。

このように、開発言語は時代によって、機能もユースケースも絞ることで、より多くの開発者の参入を受け入れてきたわけです。

振り返って、ローコード開発も思い出してみましょう。ローコードで実現できることは少ないので、やはり開発手法としてはどうしてもコーディングに比較して劣ってしまいます。

なので、手法としては退化しているんじゃないかと思われることも多いのですが、利用シーンを業務アプリケーションの開発に絞ってみると、再度注目されている特徴がありますし、機能を絞ることによってシチズンデベロッパーの開発への参入を受け入れているという側面があります。

つまり、業務アプリケーションの開発に限っていえば、成長途中ではありますが、ローコードの開発手法はある意味進化系であると言えると思います。