ビジネス側からの要請による、ノーコード／ローコードの急速な浸透
――それでは、お二人のご経歴を踏まえつつ、Salesforceも含めた業務系サービスで「ノーコード／ローコード」が注目されている背景や経緯についてお聞かせいただけますか。
及川：私は2007年に日本法人のCTOとなり、米国本社R&Dとの橋渡しや日本の顧客企業に対する顔役になるなど、さまざまな役割を担ってきました。現在はCTOとしての役割を担いながら、グローバリゼーションに関するアーキテクト全般を専門に、米国本社でもコードを書いています。米国ではエンジニアとマネジメントのキャリアは別ルートなので、私も1人のエンジニアとして開発の現場に立ち続けてきました。
田中：私は現在、デベロッパーエバンジェリストとして開発に関わる情報の発信や、デベロッパーのスキルアップなどをテーマに支援を行う立場にあります。なので、ビジネス部門に対してというよりも、実際にSalesforceで開発に取り組んでいる人たちと関わる機会が多いです。
もとはカナダの大学でコンパイラ構築を学び、帰国後は金融系システム会社で上流工程に携わっていたので、実はWebに関わるようになったのは2015年にセールスフォース・ドットコムに入社してからです。以降、ノーコード／コーディング開発で200社近くの案件に携わり、営業チームとも交流が増える中で、改めて「これはビジネスを進化させる重要なツール、プラットフォームになる」という確信を得ました。また、ノーコード／ローコードの活用においてはユーザーブログにいろいろと助けられた経験もあって、デベロッパーに「ノーコード／ローコード開発は皆さんの強い武器になる」ということを伝えるべくデベロッパーエバンジェリストを希望したという経緯があります。
及川：経営視点から見ても、「ビジネス目標を実現するためのIT」をバックアップするものとして認識され、注目されているのは間違いないですね。ITのプライオリティーは概して低く見られがちですが、それでも昨今はビジネス目標を達成するにはITが不可欠という認識があるのでしょう。しかしながら、その目標を達成するために要求されるシステムやツールがちゃんと提供できているのかといえば、たいていの場合できていません。膨大なバックログの中に隠れています。したがって、経営陣が求めるタイミングで求めるシステムを提供するという意味で、「ノーコード／ローコードによる開発は必須」と言っても過言ではないかと思います。
そしてもう1つ、実は何人かのCFOにも聞いたのですが、サービス系のシステムは定額制なので、予測不能で突然大きなコストが動く大規模投資より断然好まれるのです。そうした予測可能なコストという面からも、ノーコード／ローコードが注目されていると聞きます。
田中：少し意外でしたが、そのようなことからも注目されているのですね。現場から経営層、そして財務系からも注目されているとは知りませんでした。
私の立場から見ても、よく言われているように、世の中的にはビジネス要請あってのノーコード／ローコードという印象があります。ビジネス側はインフラやネットワークなどよりも、早くビジネスの強みとなるコアの部分を作ってほしいと考えています。特に昨今のコロナ禍もあって、ネット上でサービスやビジネス、業務などを早々に展開したいというニーズがあり、迅速性に対する要望が高まっています。しかし、高速化が進む一方で、担保するべき品質やセキュリティとのトレードオフになりかねないという懸念も生じています。
そんな中でも、社員が使う業務アプリは、斬新なUX/UIが不要で、すぐに作れてすぐに使えて、すぐに効果が見えるというのが好まれることもあって、ノーコード／ローコードと相性が良いです。また業務アプリは作って終わりではなく、社員トレーニングが必要で定着化に時間がかかり、リリース後にも修正や改善が必要です。ノーコード／ローコードなら、そうした要求にも迅速に答えることができます。そうしたビジネスや社会状況とノーコード／ローコードの強みがフィットしたことで急速に注目されるようになったのだと思います。
実は、エンジニアにとって”当たり前の延長線上”
――やはりビジネス側からの要請が普及を牽引しているのですね。とはいえ、エンジニアにとっても大きな影響があることは間違いありません。次はそれぞれのお立場から見た”エンジニアにとって”のノーコード／ローコードの価値や意味について、お聞かせいただけますか。
及川：会社に言われるまでもなく「エンジニアなら当然」というところでしょうか。昔からエンジニアの世界では、「車輪の再発明はするな」というように、既にあるライブラリやフレームワークを使わずにイチから開発することや、「ゴールデンハンマーの法則」のように、ある技術に成熟したらそれだけで何でも解決しようとすることなど、目的と手段の関係を取り違えることの愚かしさについて散々言われてきました。「コードを書かずに、あるものはうまく使う」というのはエンジニアにとって基本中の基本で、ノーコード／ローコードもその延長線上にあると思っています。
田中：確かにコンパイラは100%コードを書きますが、その上のプログラムでは借り物ばかりです。プログラミング言語の習熟が必要といえど、実態はその言語に紐づくライブラリやAPIを大部分利用します。プログラミングをできるだけ少なくする、書かなくするというのは、エンジニアなら当然考えていることであり、及川さんがおっしゃるように”当たり前の延長線上”なのです。
及川：ノーコード／ローコードとまではいかなくても、コードを書かない部分は相当の割合になっているはずです。エンジニアは手元の道具で最大のパフォーマンスを発揮すること、そして自分のモチベーションとしてライブラリなどの引き出しを増やすこと、そうした目的でノーコード／ローコードを選んでいる。実際、何かを実現したい時にまずはGitHubに使えるものを探しに行くし、Pythonが分析でよく使われるのもAIのライブラリが充実しているからです。そして、「良いコードが書ける」と「コードを最適に組み合わせられる」というのは、両立はしますがイコールではない。そもそも「良いコード」の中身が変わってきていて、仕事のスタイルも求められる結果も変わってきています。少なくとも職業デベロッパーは、必ず何らかのビジネスの要望を満たすアウトプットが求められ、時間やコストの制約もつきまとい、解決すべき問題も複雑化しています。そう考えると、誰でも量の差はあれどノーコード/ローコードは必須ということになります。
田中：デベロッパーに求められる時間やコストの制約をクリアするには、開発速度に負うところが大きいので、私もノーコード／ローコードを「開発の自動化」の1つとして捉えており、その最たるメリットは開発速度の高速化にあると考えています。一般的な開発のライフサイクルである、設計〜コード、ビルド、テスト、リリース、デプロイ、運用監視という流れの中で、ビルドからデプロイにかけてはCI/CDで自動化していると考えれば、コード部分はノーコード／ローコードがそれに該当するのではないかと。設計情報を入れると、自動的にコードが吐き出される。「コードを書く量が減る」だけでなく、付随する設計書の簡便化やテスト量の削減などによって、時間やコストを抑制することができます。
及川：コンパイラ構築からキャリアを出発させている田中さんとしては、コードやプログラミングの進化という観点からも、ノーコード／ローコードへの移行を自然に受け取られているように見えます。
田中：それはあるかもしれません。よく「ノーコード／ローコードは開発の民主化」であり、人材不足の解消のために意図したもののように語られますが、プログラミング言語の歴史から見てもノーコード／ローコードへの移行は自然なことだと思います。バイナリ、アセンブリ言語、高級言語、スクリプト言語というように進化する過程で、特定分野に特化しながら細分化してきています。先程Pythonの話もありましたが、言語は機能を絞り、特定の用途に限定しながら、利用者を増やしてきたというわけです。同じようにノーコード／ローコードも通常のプログラミングに比べて自由度は低くなるけれど修得は容易になっています。その結果、使える人が増えるのは魅力的なことです。
及川：早く簡単に開発できる環境が整うというと、一見ビジネス側だけにメリットがあるように聞こえるかもしれませんが、実はエンジニアにとっては自然な流れです。使いようによっては大きな価値があるというのはもう少し浸透してもいいかもしれません。実際、自分の仕事の価値をわかっている人は、自然とコードを書かない価値もわかっていると思います。
田中：速度が上がれば同じ期間でたくさんのプロジェクトに関わることができ、知見も経験も増えて力が付き、仕事もしやすくなります。またノーコード／ローコード技術を提供している企業のサービスは本当に多くのユーザーに使われており、その大量のユーザーからのフィードバックを受けて機能開発しているのですから、Salesforceの場合でいうと、いわば約15万社分のベストプラクティス集になっています。つまり、一企業の担当者が考える設計より、15万社の知見のほうが遥かに合理的ということも少なくありません。私も顧客企業が実現したい機能の意図を汲み取って、それをノーコード／ローコードで提案して採用された経験が何度もあります。単に依頼を受けるデベロッパーから、ビジネスオーナーの意思決定に介入してビジネスプロセスを変えていける存在になれるというわけです。
ユーザー価値の理解がカギ？ ノーコード／ローコード時代におけるデベロッパーのキャリアと組織
――しかし、ノーコード／ローコードの価値や意味が一般的には十分に理解され、浸透されているわけではなさそうです。現在の仕事とキャリアを考える上で、企業や組織はどのような対応が必要だと思われますか。
田中：確かにデベロッパーのキャリアを育くむのは企業だと思うので、企業自体の姿勢はとても重要なポイントです。ノーコード／ローコードに価値を感じている企業と、感じていない企業、はたまた積極的に排除しようという企業に分かれるにあたっては、いくつか原因があると思うのですが、とりわけ「ユーザーとの距離」に違いがあるのではないかと感じています。
デベロッパーとユーザーとの距離が近い、つまり直接フィードバックを得られる環境では、作ったものに対して「助かっている」などのポジティブなものも得ることができます。そうしたデベロッパーはノーコード／ローコードの価値を感じやすいでしょう。同じ評価が得られるなら、手数が少ないほうを選ぶのではないでしょうか。一方、ユーザーとの距離が遠いほど、バグ報告や不満などネガティブな情報ばかりが伝わります。誰しも仕事を認めてもらいたいと思っているわけで、こうなるとコードを書くことだけが楽しみになります。手段と目的が逆転してしまうと思います。そこにノーコード／ローコードが導入されたら、コードを書いてアウトプットを出すという喜びが得られなくなる。こうした環境にいる方は拒否感を示す方が多いです。
及川：基本的にデベロッパーは制約を嫌う人が多いです。この言語で、ライブラリで、というように制約を与えるととにかく拒否反応を示します。同様に「ノーコード／ローコードで」という制約を嫌うのだと思います。「好きに書かせろ」という気持ちがとにかく強いですから。
田中：それはありますね。ノーコード／ローコードは機能特化しているので、そのあたりはややこしくならないように、エコシステム的にちゃんとつながるか、APIが標準化されているかなどは、ちゃんと見極めてほしいです。デベロッパーの負担にもなりますから。さらに、現場と開発を近づける努力をする必要があり、ノーコード／ローコードでもコードでも、デベロッパーが作ったものが生み出す価値を正しく評価する仕組みを作っていく必要があります。またデベロッパー側にも、コードとノーコード／ローコードを使い分けていく工夫が必要になるでしょう。
及川：あとよくノーコード／ローコード嫌いのデベロッパーが言うのが、不自由さについてですよね。多くはSaaSで提供され、さらにSIerではないので、デベロッパーの要望などを聞き入れてもらえないことがほとんどです。基本的には、CFOが好むサブスクリプション形式で提供されているので、裏を返せばサービスとしていつ撤退されてしまうかもわからないという不安もある。
田中：価格や機能だけを見て、ビジョンやミッションを見ていかないと、自分たちのビジネスとは全く違う方向に舵を切られるリスクはあります。
及川：アンチパターンやベストプラクティスみたいなものはありますか？
田中：自社を上げるのはちょっと躊躇はありますが、個人的にはSalesforceのビジョンは好きです。ずっと一貫して、顧客のビジネスのために必要なものを真摯に考えて提供している。だからこそ、「こういう機能を出した」とアナウンスしても大きな反響があるわけではないです。斬新な機能をバーンと出して「いろんな使い方ができますよ」というのではなく、ユースケースが限られる中で「こういう場面で使ってください」というように、本当に必要な人に必要なものを届けている。だから「こういうの欲しかった」と、気づいていなかった課題にソリューションが先回りして出てくることに助かっている人が多い。でも、Salesforceのそのビジョンを知らない人には違和感を覚える人もいるようです。デベロッパー個人というより、組織の問題かもしれませんが。
及川：職業デベロッパーである以上、組織の目標に貢献することが重要な目標ですし、デベロッパーとしての価値につながるので、組織だけの問題ではないと思います。
たとえばセールスフォース・ドットコムでも、「V2MOM」という独自の目標管理手法を長年にわたって活用してきました。ビジョン（Vision）、価値（Values）、方法（Methods）、障害（Obstacles）、基準（Measures）の頭文字で、これによって全員の意思統一を図ることが組織の成功に不可欠としています。つまり、トップの目標があって、それをすぐ下の人が受けて自分の目標とし、というように全社隅々まで共有することが大切なのです。つまりは、自分ににとっての顧客は誰なのかを正しく理解する。しかし、先程田中さんがおっしゃっていたように、それが見えていないとコードを書くことがモチベーションになり、ノーコード／ローコードを導入すると途端に自分の目標を奪われたような気がしてしまう。さらに、自分たちのビジネスに何が必要なのかも判断できない。ノーコード／ローコードだからというより、デベロッパーのキャリアを考える上で、組織が目標やビジョンを伝えられていないことから生じる弊害といえるでしょう。
マインド、職能、協業など、ノーコード／ローコードで開発現場はどう変わる？
――デベロッパーが自律的にキャリアを考え、仕事をする上で、ノーコード／ローコードの価値を正しく理解し、活用していくためには、組織や上層部はどのような働きかけを行っていけば良いのでしょうか。
田中：かなり厳しい言い方になってしまうかもしれませんが、及川さんが話されていたように、デベロッパー自身がまずは考えることが大切なのではないでしょうか。そもそも社会は変化し、ビジネスもそれに合わせて変化します。ビジネスに対して価値を提供しているエンジニアも同じで、変化に対応できなければどんな職種でも廃れていきます。私自身、ノーコード／ローコードがこのまま開発の主流になっていくかはわかりませんが、少なくとも、今のままではいられないことは明らかだと考えています。常に最先端にいる必要はありませんが、周りが変わりはじめた時にそれに乗っていくマインドは必要で、たとえば「ユーザーから言われた通りに作る」というマインドから、「ノーコード／ローコードなら速くこう作れる」とビジネス側に向けて提案できるデベロッパーにシフトしていくこともその1つだと思っています。
及川：田中さんの意見には諸手を挙げて賛成です。あえて組織側に求められることというなら、一般的な会社のIT部門で、時代の流れに合わせて効率性を求めるのであれば、アジャイル開発を基本にしたプロダクトオーナー制で、バックログ管理と優先順位付けをしっかりとスクラムを組んでシステム化していくこと。そして、それらの情報が透明化され、経営陣がしっかり把握できていることが大前提だと思います。そうでないと、デベロッパーから適切なタイミングでシステムを提案することができません。
田中：採用の場面でもスキルの条件が変わりそうです。実際、ノーコード／ローコード開発の現場では誰がやるかという話になるそうです。現在、言語ごとでの採用が一般的ですが、今後はノーコード／ローコードもその1つになるのではないかと思います。人気のノーコード／ローコードは職種や部門を問わずに使われ、かつ特定の目的に機能特化して細分化されているので、金融系など業界別エンジニアがあったように、決済系など業務別という分野が出てくるのではないかと思います。そうしないと経験も積めないし、提案もできないです。
及川：まさにそうです。職業デベロッパーとしては、あるものを組み合わせて可能な限り早く、いいものを作るというのが命題なので、ノーコード／ローコードもコードも、言語や業種も関係なく、プラスアルファの部分では業務についての開発経験を持つことが重要になりますから。ノーコード／ローコードは特定の業務、もしくはビジネス要件を満たすための「組み合わせを作る」というのが仕事になり、それもプログラミングの1つと認識されるようになると思います。
田中：誰でも使えるという意味では、よく言われるように非デベロッパーとのコラボレーションとして仕事の仕方も変わってくるかもしれません。しかし、現状としては一定の論理思考力やシステム設計の基礎的な知識が必要なので、まずはデベロッパーがアドバイスしながら、非デベロッパーが開発するという分担作業になると想像しています。実際、Salesforceのコミュニティでも、そうした場面はよく見受けられます。現場とデベロッパーのコミュニケーションが密になり、じきに共同作業も行われるようになり、そのためにも変更管理やバージョン管理が重要になってくるでしょう。ノーコード／ローコードでは一般的にそれが難しいのですが、Salesforceだと容易にバージョン管理が可能で、コマンドラインが苦手な非デベロッパーでもUI上で対応できるなど、共同作業しやすい環境が整いつつあるので、そう遠い未来ではなさそうです。
及川：そうなった時の組織の管理としては、まだ方法論として絶対策があるわけではありませんが、顧客事例として業務部門の方がプロダクトオーナーになって成功したということはあります。これは理にかなっていて、少なくとも完成してから業務部門に見てもらうより、最初からスクラムに入ってもらったほうが効率的です。デベロッパー側も業務に対する理解を深めることができます。唯一とは思っていませんが、1つの手ではあると思います。とはいえ、業務部門の人がスクラムに入るというのはなかなか大変ですが。
変化に対応し、信頼と価値の源泉を意識することで見える”選択肢”
――今後、デベロッパーの仕事の中でコードを書くということがどのように変わっていくと思われますか。また、これからノーコード／ローコードに触れるであろうデベロッパーに向けてメッセージやアドバイスがあれば、お聞かせください。
田中：現在ノーコード／ローコードとそれ以外という分け方ですが、今コードが必要なシステム連携もAPIが進化して、どんどんノーコード／ローコードになりつつあることを鑑みると、業種・業界関係なくよく使われる部分はどんどんノーコード／ローコードに置き換わることは間違いないでしょう。そうなると、コードはノーコード／ローコード部分を作るか、至極ニッチな機能を作るかといった部分に限定されてくると思われます。
及川：コードの自動化は以前から大きなテーマですが、なかなか実現しないところを見ると、もう少しかかるかもしれません。「あるものを使え」を基本スタンスに、あるもの同士をつなぐところにコードを書くのが一般的になり、組み合わせる粒が大きくなるだけでプログラミングであることには変わりありません。ただ、すぐではないにせよ将来、業務系アプリ開発で、あるものを組み合わせるのが常識になるのは間違いないので、コードを書きたい人は別のキャリアを考える必要があるでしょう。ちょっと別の話になりますが、もう少し各社で内製化が増えて、人材の流動性があれば、職業デベロッパーも、もっと自分がやりたい仕事やキャリアを考えながら動けるようになるかもしれません。
田中：キャリアを考えた時、エンジニアとデベロッパーは違うという認識を持っていたほうがいいです。エンジニアは技術やテクノロジーをもってビジネスや社会課題を解決するソリューションを考える人たち、デベロッパーは逆で、ソリューションを実現するスキルを持っている人たちという意味です。つまり、アプリ系エンジニアとデベロッパーそれぞれに求められているものは全く違います。コードを書くのは大切ですが、ビジネス上価値のあるものを作るためにコードを書く、コードではなくアウトプットに対価が支払われるという考え方です。したがって、ノーコード／ローコードなのかコードなのか関係なく、必要なら選ぶというスタンスが大事です。
及川：私はもう「○○系」とかは関係なく、マイルールとして「仕事だ、うまくやれ」ということだと思います。あるものを使うのは当たり前で、最後はシンプルできれいなコードを自慢したっていい。要は視点の切り替えです。
そもそもSalesforceもCRMからはじまり、それを補完するためにプラットフォームが登場し、既存の機能をつなぐためのノーコード／ローコードがあり、どれだけその引き出しを増やすかがスキルになります。それは、ライブラリをどれだけ知っているかとほぼ同義です。それによって迅速かつ高品質に必要なものを作れば、優秀なエンジニアと認識され、評価されます。その意味で、その時知らなくても、新しい知識にすぐ適応できるかは重要になります。
田中：ノーコード／ローコード時代に向けて「何から勉強をはじめたらいいですか？」と聞かれることがありますが、「必要になったらその場で学ぶ」が基本だと思います。「嫌がらずに勉強すること」が大切です。
及川：はい、速さは大事です。あえて前もってやるなら、今あるプラットフォームで「自分が十分な引き出しを持っているか」を確認しておくことでしょう。
田中：引き出しを増やすという意味で、ぜひSalesforceのコミュニティが主催するハンズオンにも参加してほしいです。「Trailhead」という学習プラットフォームも用意されています。その中で「Salesforceを使うとコードを書かなくていいんだ」とパートナーになったり、「ノーコード／ローコードを広めたい！」という思いに至ったという人もいたりします。バグ調査が難しい、バージョン管理が難しいという声もありますが、それ以上に熱量を感じます。したがって、自社でノーコード／ローコードを導入したい時には、コミュニティに行って熱量を感じてもらえればモチベーションも上がり、さらに上司も一緒につれて行くと会社でのアクションにつながりやすいと思います。ハンズオンは、デベロッパー以外のシステム管理者にも好評です。
及川：田中さんも熱量が多いので、「ノーコード／ローコードを広めたい！」というマインドなのですが、ここはやはり「必要だから使う」というスタンスで考えていただきたいです。たとえば、セールスフォース・ドットコムでは、4つのコアバリューとして「信頼」「カスタマーサクセス」「イノベーション」「平等」を掲げています。中でも、「信頼」「カスタマーサクセス」を常に意識し、何が自分たちの信頼の基礎や価値となっているのか、一人ひとりが意識することを大切にしています。同様に、皆さんも自社のバリューや信頼の源泉がどこなのか、考えていただければ、今手掛けている仕事の見え方が変わってくると思います。そこにノーコード／ローコードが有効ならば、自然とそちらにシフトするでしょう。
――まさにノーコード／ローコードについての熱量と必然性とを実感しました。ありがとうございました。
