ユーザー価値の理解がカギ？ ノーコード／ローコード時代におけるデベロッパーのキャリアと組織
――しかし、ノーコード／ローコードの価値や意味が一般的には十分に理解され、浸透されているわけではなさそうです。現在の仕事とキャリアを考える上で、企業や組織はどのような対応が必要だと思われますか。
田中：確かにデベロッパーのキャリアを育くむのは企業だと思うので、企業自体の姿勢はとても重要なポイントです。ノーコード／ローコードに価値を感じている企業と、感じていない企業、はたまた積極的に排除しようという企業に分かれるにあたっては、いくつか原因があると思うのですが、とりわけ「ユーザーとの距離」に違いがあるのではないかと感じています。
デベロッパーとユーザーとの距離が近い、つまり直接フィードバックを得られる環境では、作ったものに対して「助かっている」などのポジティブなものも得ることができます。そうしたデベロッパーはノーコード／ローコードの価値を感じやすいでしょう。同じ評価が得られるなら、手数が少ないほうを選ぶのではないでしょうか。一方、ユーザーとの距離が遠いほど、バグ報告や不満などネガティブな情報ばかりが伝わります。誰しも仕事を認めてもらいたいと思っているわけで、こうなるとコードを書くことだけが楽しみになります。手段と目的が逆転してしまうと思います。そこにノーコード／ローコードが導入されたら、コードを書いてアウトプットを出すという喜びが得られなくなる。こうした環境にいる方は拒否感を示す方が多いです。
及川：基本的にデベロッパーは制約を嫌う人が多いです。この言語で、ライブラリで、というように制約を与えるととにかく拒否反応を示します。同様に「ノーコード／ローコードで」という制約を嫌うのだと思います。「好きに書かせろ」という気持ちがとにかく強いですから。
田中：それはありますね。ノーコード／ローコードは機能特化しているので、そのあたりはややこしくならないように、エコシステム的にちゃんとつながるか、APIが標準化されているかなどは、ちゃんと見極めてほしいです。デベロッパーの負担にもなりますから。さらに、現場と開発を近づける努力をする必要があり、ノーコード／ローコードでもコードでも、デベロッパーが作ったものが生み出す価値を正しく評価する仕組みを作っていく必要があります。またデベロッパー側にも、コードとノーコード／ローコードを使い分けていく工夫が必要になるでしょう。
及川：あとよくノーコード／ローコード嫌いのデベロッパーが言うのが、不自由さについてですよね。多くはSaaSで提供され、さらにSIerではないので、デベロッパーの要望などを聞き入れてもらえないことがほとんどです。基本的には、CFOが好むサブスクリプション形式で提供されているので、裏を返せばサービスとしていつ撤退されてしまうかもわからないという不安もある。
田中：価格や機能だけを見て、ビジョンやミッションを見ていかないと、自分たちのビジネスとは全く違う方向に舵を切られるリスクはあります。
及川：アンチパターンやベストプラクティスみたいなものはありますか？
田中：自社を上げるのはちょっと躊躇はありますが、個人的にはSalesforceのビジョンは好きです。ずっと一貫して、顧客のビジネスのために必要なものを真摯に考えて提供している。だからこそ、「こういう機能を出した」とアナウンスしても大きな反響があるわけではないです。斬新な機能をバーンと出して「いろんな使い方ができますよ」というのではなく、ユースケースが限られる中で「こういう場面で使ってください」というように、本当に必要な人に必要なものを届けている。だから「こういうの欲しかった」と、気づいていなかった課題にソリューションが先回りして出てくることに助かっている人が多い。でも、Salesforceのそのビジョンを知らない人には違和感を覚える人もいるようです。デベロッパー個人というより、組織の問題かもしれませんが。
及川：職業デベロッパーである以上、組織の目標に貢献することが重要な目標ですし、デベロッパーとしての価値につながるので、組織だけの問題ではないと思います。
たとえばセールスフォース・ドットコムでも、「V2MOM」という独自の目標管理手法を長年にわたって活用してきました。ビジョン（Vision）、価値（Values）、方法（Methods）、障害（Obstacles）、基準（Measures）の頭文字で、これによって全員の意思統一を図ることが組織の成功に不可欠としています。つまり、トップの目標があって、それをすぐ下の人が受けて自分の目標とし、というように全社隅々まで共有することが大切なのです。つまりは、自分ににとっての顧客は誰なのかを正しく理解する。しかし、先程田中さんがおっしゃっていたように、それが見えていないとコードを書くことがモチベーションになり、ノーコード／ローコードを導入すると途端に自分の目標を奪われたような気がしてしまう。さらに、自分たちのビジネスに何が必要なのかも判断できない。ノーコード／ローコードだからというより、デベロッパーのキャリアを考える上で、組織が目標やビジョンを伝えられていないことから生じる弊害といえるでしょう。
マインド、職能、協業など、ノーコード／ローコードで開発現場はどう変わる？
――デベロッパーが自律的にキャリアを考え、仕事をする上で、ノーコード／ローコードの価値を正しく理解し、活用していくためには、組織や上層部はどのような働きかけを行っていけば良いのでしょうか。
田中：かなり厳しい言い方になってしまうかもしれませんが、及川さんが話されていたように、デベロッパー自身がまずは考えることが大切なのではないでしょうか。そもそも社会は変化し、ビジネスもそれに合わせて変化します。ビジネスに対して価値を提供しているエンジニアも同じで、変化に対応できなければどんな職種でも廃れていきます。私自身、ノーコード／ローコードがこのまま開発の主流になっていくかはわかりませんが、少なくとも、今のままではいられないことは明らかだと考えています。常に最先端にいる必要はありませんが、周りが変わりはじめた時にそれに乗っていくマインドは必要で、たとえば「ユーザーから言われた通りに作る」というマインドから、「ノーコード／ローコードなら速くこう作れる」とビジネス側に向けて提案できるデベロッパーにシフトしていくこともその1つだと思っています。
及川：田中さんの意見には諸手を挙げて賛成です。あえて組織側に求められることというなら、一般的な会社のIT部門で、時代の流れに合わせて効率性を求めるのであれば、アジャイル開発を基本にしたプロダクトオーナー制で、バックログ管理と優先順位付けをしっかりとスクラムを組んでシステム化していくこと。そして、それらの情報が透明化され、経営陣がしっかり把握できていることが大前提だと思います。そうでないと、デベロッパーから適切なタイミングでシステムを提案することができません。
田中：採用の場面でもスキルの条件が変わりそうです。実際、ノーコード／ローコード開発の現場では誰がやるかという話になるそうです。現在、言語ごとでの採用が一般的ですが、今後はノーコード／ローコードもその1つになるのではないかと思います。人気のノーコード／ローコードは職種や部門を問わずに使われ、かつ特定の目的に機能特化して細分化されているので、金融系など業界別エンジニアがあったように、決済系など業務別という分野が出てくるのではないかと思います。そうしないと経験も積めないし、提案もできないです。
及川：まさにそうです。職業デベロッパーとしては、あるものを組み合わせて可能な限り早く、いいものを作るというのが命題なので、ノーコード／ローコードもコードも、言語や業種も関係なく、プラスアルファの部分では業務についての開発経験を持つことが重要になりますから。ノーコード／ローコードは特定の業務、もしくはビジネス要件を満たすための「組み合わせを作る」というのが仕事になり、それもプログラミングの1つと認識されるようになると思います。
田中：誰でも使えるという意味では、よく言われるように非デベロッパーとのコラボレーションとして仕事の仕方も変わってくるかもしれません。しかし、現状としては一定の論理思考力やシステム設計の基礎的な知識が必要なので、まずはデベロッパーがアドバイスしながら、非デベロッパーが開発するという分担作業になると想像しています。実際、Salesforceのコミュニティでも、そうした場面はよく見受けられます。現場とデベロッパーのコミュニケーションが密になり、じきに共同作業も行われるようになり、そのためにも変更管理やバージョン管理が重要になってくるでしょう。ノーコード／ローコードでは一般的にそれが難しいのですが、Salesforceだと容易にバージョン管理が可能で、コマンドラインが苦手な非デベロッパーでもUI上で対応できるなど、共同作業しやすい環境が整いつつあるので、そう遠い未来ではなさそうです。
及川：そうなった時の組織の管理としては、まだ方法論として絶対策があるわけではありませんが、顧客事例として業務部門の方がプロダクトオーナーになって成功したということはあります。これは理にかなっていて、少なくとも完成してから業務部門に見てもらうより、最初からスクラムに入ってもらったほうが効率的です。デベロッパー側も業務に対する理解を深めることができます。唯一とは思っていませんが、1つの手ではあると思います。とはいえ、業務部門の人がスクラムに入るというのはなかなか大変ですが。
