キーポイント
- The uptake of low code software is so strong that it will almost certainly make its way into your organization.
- Most software engineers working in larger enterprises shouldn’t be concerned about this because they are good at the things that low code software is not yet good at.
- The key to surviving and thriving during this change is ensuring that your role encompasses responsibilities that low code can’t do yet.
- If your role is solely focussed on activities that low code software can perform you are at risk of being caught in a pinch point.
- Examples of pinch points include app/integration roles in small companies or small teams, and app developers working for app development companies.
私が若い頃、親友の叔父がパーティバスとの交通事故で亡くなりました。葬儀の悲しみの中で、誰もの頭に浮かんだひとつの疑問がありました — なぜ彼はその時、パーティバスに気付いて避けることができなかったのだろうか?ローコードソフトウエアによって企業のソフトウエア開発者が職を失っているという話を聞いた時、これと同じような疑問が私の心に浮かび上がったのです。バスを避けられたはずなのに!
親友の叔父が逃げられなかったのは、彼がピンチポイント(pinch point)、つまり、他に移動できない場所にいたためでした。今回の記事では、ソフトウェアエンジニアにとってのローコードのピンチポイントと、それを回避する方法を示します。
状況設定
パーティバスのアナロジを続けましょう。あなたは大手ないし準大手企業のエンタープライズソフトウェア開発者である、とします。あなたのチームは、企業が使用するさまざまなアプリケーションの開発、デプロイ、メンテナンスを日々行っています。自分たちでコーディングしたアプリケーションもあれば、"オフ・ザ・シェルフ"のアプリケーションをカスタマイズないしインテグレーションしたものもあります。
ある日突然、多数のビジネスユーザがローコードというパーティバスに乗って、自分自身でアプリケーション開発を始めていることに気付きました。心配するべきでしょうか?そうは思いません。
大企業ではピンチポイントはほとんどない
Blue Printが、続いてUIPathが登場した2010年以降、オートメーションによってドラマティックな影響を受ける金融や人事分野の同僚たちを目の当たりにしたことがあるかも知れません。これは、これらの運用領域に多数のピンチポイントが存在するためです。買掛金処理の大部分が自動化された場合、買掛金担当チームのメンバが別の役割に移行することは困難です — 従って彼らは、仕事をすべて失うこになります。
ですが、ソフトウェアエンジニアリングと買掛金管理は違います。あなたの仕事の大半は、企業に有意義な差異をもたらすソフトウェアを提供することで得られているのです。あなた自身が現在抱えている仕事を考えてみてください。ほとんどのITチームがそうであるように、新しいアプリケーションや既存のアプリケーションへの機能追加に対する需要が満たされないまま、山積みになっているのではないでしょうか。自動化を導入すればこのニーズをすべて解決できると考えるのは、速い自動車に乗れば火星に行くことができると考えるような話です。ローコードソフトウェアが作業の一部を担うようになったとしても、あなたには別の、作業可能なプロジェクトがあるでしょう。この権利をうまく利用すれば、大変なプロジェクトをローコードバスのパーティ参加者に移し替える、というようなことも可能かも知れません。
ソフトウェアエンジニアが行う仕事は、オートメーションの導入で縮小されるのではなく、かえって深いものになる可能性があります。
-- Ralph Aboujaoude Diaz、HFS Research
第2に、より基本的な問題として、ソフトウェアエンジニアリングには他の仕事よりも自動化が難しい側面があります — ローコードのパーティバスがドライブするには不向きな地域なのです。
例えばローコードツールが非開発者に対して、データを格納するテーブルの作成を容易にすることは可能ですが、そのテーブルを彼らが解決しようとするビジネス問題に対して最適な構造にするための支援はほとんどしてくれません。
さらにローコードツールは、非開発者によるアプリの開発やデプロイは簡単にしてくれますが、リスクやコンプライアンスのガイドラインに準拠するために、適切なステークホルダがプロジェクトの適切な部分に関与することを保証してくれる訳ではありません。
ローコードが企業に広まることで、エンタープライズソフトウェアエンジニアとしての職を失うよりも、コーディングに要する時間が少なくなることによって、仕事の他の部分にもっと時間を使えるようになる可能性の方が高いのです。
ほとんどのソフトウェアエンジニアにとって、自分の会社にローコードソフトウェアが導入されることは、退屈な反復作業を行う必要がなくなり、会社により多くの価値を提供する機会を与えてくれることになるでしょう。
-- Jan Oberhauser、CEO、n8n
パーティバスのアナロジはもういいよ!どんなプロジェクトの話をしているんだっけ?
ローコードソフトウェアは、プロセスオートメーションから、ユーザの作業の短縮や一貫的の向上を支援するアプリまで、さまざまなタイプのプロジェクトに使用することができます。以降の記事を読むにあたっては、次のシナリオのどれかひとつを思い描いてください。
- 不動産業者が顧客に対して、今後の契約日についてリマインダを送信するアプリ
- 医療表記(medical notations)を査読して、優先順位が適切でない可能性のある患者を識別する内部用(behind-the-scenes)アプリ
- 保険証券から関連するフィールドを抽出するマシンラーニングモデルを構築するアプリ
ソフトウエア開発の解剖学
エンタープライズソフトウェアプロジェクトの構成方法を取り上げた書籍はたくさんあります(Blair Reeves氏の"Blair Reeves' Building Products for the Enterprise"をざっと読んでみるとよいでしょう)。 この記事では便宜上、プロジェクトを4つのステージにカテゴライズしたいと思います。
- 計画と全体設計
- 構築
- 展開(デプロイ)
- 維持(メンテナンス)
ローコードが業務に与えるであろう影響を理解する一助として、これらのステージそれぞれにおける現在のローコードの能力を見てみましょう。
1. 計画と全体設計
4つのステージの中で、これはローコードソフトウェアに代替される最後のステージになると思います。計画と設計のステージには、必要なステークホルダの関与から、アプリを構築し維持する上で十分な予算とリソースの確保、適切なアプリを開発しているという確証に至るまで、すべてが含まれています。例えば、あなたが不動産会社に勤めていて、契約書を渡すのに時間が掛かりすぎているという苦情を顧客から受けている、と想定しましょう。問題の解決方法はいくつかありますが、あなたの会社にとってどれが最善かを決めるには、遅れの原因や、遅れを最小化できるさまざまな方法を理解する必要があります。このような分析は、すぐにはローコードソフトウェアで処理できるようにならないでしょう。
2. 構築
これが現在のローコードソフトウェアの中心的な機能です。全体的な設計ができれば、あなたのチームあるいはビジネスユーザは、ローコードソフトウェアを使うことで、従来よりも早くアプリケーションを量産することができます。プロジェクトのこのステージにおいて、ユーザがローコードソフトウェアを使うことのメリットは、ユーザが本当に必要なものを決める上で、ローコードソフトウェアの支援が得られる点にあります。ドラフトを作って詳細な要件や仕様について話し合わなくても、ユーザが自分のニーズに会ったものを得られるまで、ソリューションを繰り返すことができるのです。
ローコードが革新する重要な領域のひとつは、インフラストラクチャの複雑性を抽象化するその能力にあります — これによって専門家以外の人が、驚くほど複雑なアプリケーションを開発し、展開することが可能になります。
-- Rick Lamers、CEO、Orchest
このフェーズにはチームの関与が必要な領域が残っています — それは、例えば"不動産契約から関連するデータをどうやって抽出するか"というように、取り組んでいるビジネスに固有のものであるため、選択したローコードソリューションでは処理が難しい問題に対処することです。標準化されたインターフェースを持たない、官公庁のデータセットにアクセスするにはどうすればよいのか?リスクを基準としてクレームを分類可能なマシンラーニングモデルをどうやって構築するのか?しかし、社内に専門家がいなかったとしても、最近ではManaged Functionsのような新たなカテゴリのソフトウェア企業が現れて、このような特殊な要件を処理してくれるようになっています。
3. 展開(デプロイ)
このステージは現在のローコードソフトウエアにとっての無法地帯(wild west)とでもいうもので、各タイプのローコードプラットフォームがさまざまなアプローチを採用しています。
- RPA企業はモノリシックなコントロールセンタを構築して、アプリケーションのデプロイメントとメンテナンスを処理しています。この方法はデプロイメントとメンテナンスの問題を解決する一方で、チームにとっては、ローコードアプリのデプロイとメンテナンスのために、他のアプリのデプロイとメンテナンスとは別のツールを使用する必要が生じます。
- Microsoftではローコードアプリ用に、ビジネスユーザ用のグラフィカルなユーザインターフェースと、開発者の使用可能なコードベースのインターフェースという、2つのビューを開発しています。これによって開発者は、他で使用しているのと同じGitベースのワークフローを使用できるようになります。
- AWSとGoogleは、この問題への対処方法をまだ決めていません。
- 何百という他のローコードアプリケーションは、さまざまに異なるアプローチを採用しているのが現状です。
結論としてチームは、これをどのように処理するのか、誰が処理をすべきなのか、といった、いくつかのガイドラインを決める必要があります。この件に関しては、シリーズの以前の記事でも取り上げました。ガイドラインが設定されれば、ローコードプラットフォームが、そのガイドラインへの準拠を支援してくれるでしょう — ただし、これに関する責任はビジネスではなく、IT部門が負うのは当然のことです。
4. 維持(メンテナンス)
これは現在、対処の最も難しいステージです。メンテナンスには、故障/修理というアクティビティと、継続的拡張という2つが含まれます。ビジネスユニットの大半はこの作業を実施するように設定されていませんが、それでも関与は必要です。アプリケーションがジ自社開発の場合、ビジネスの観点からその挙動について知っているのは彼らだけだからです。
将来的にはこのフェーズをもっとうまく扱えるようになるでしょうが、適切な管理を行うためには、ソフトウェアエンジニアとビジネスによる共同作業が常に必要になると思われます。
避けるべきピンチポイント
あなたが大手ないし準大手企業のソフトウェアエンジニアで、ビジネスユーザと十分なコミュニケーションが可能なのであれば、過度に心配する必要はありません。企業に価値を加える方法が、いつでも見つかることでしょう。
しかし、ローコードがソフトウェアエンジニアたちに大きな影響を与えるであろう領域が2つあります。これらのいずれかに従事しているのであれば、現在よりも大きなトレンドに注意する必要があります。
- 中小企業(あるいは技術チームの小規模な技術チーム)
- アプリケーション開発企業
中小の企業では、カスタムアプリを開発するよりもローコードソフトウェアを使用する方がずっと理にかなっています。中小企業のCEOの観点から見てみましょう — CEOはいくつかのカスタムアプリを開発するReact開発者を採用する(その上で離職したり、退職したり、死亡したりしないように願う)か、ローコードソフトウェアを使ってアプリを開発するか、という選択をしなければなりません。後者を選ぶのは簡単です。これらの企業で雇用されているソフトウェア技術者たちは職を失うか、自社用のローコードアプリの開発へと移行することになるでしょう。
最大の失職が発生するのは、アプリ開発です。これらの企業の初級~中級レベルの開発者たちには、直接雇用されたエンタープライズソフトウェアエンジニアが可能なのと同じ方法で、自身のコミュニケーションスキルを活用する機会はほとんどありません。もしあなたがアプリの作成やETLパイプラインの構築を担当する初級ないし中級レベルの開発者で、オフィスを見回した時に同じ仕事をする同僚が何人もいるようであれば、自分自身のコミュニケーションスキルや対顧客スキルを強化する方法を考える時かも知れません。
結論
テクノロジの変化は、最初はゆっくりと、次には一度に、起こります。私たちは今、すべてが一度にローコードソフトウェアへと転換する、その分岐点にいるのではないでしょうか。今後数年間で、ソフトウェアエンジニアが行う仕事の内容は劇的に変わるでしょう。そして、あなたがピンチポイントを離れているならば、この数年間は非常によい年になるはずなのです。
"The Low Code Road"はManaged Functions CEOのDoug Hudgeon氏がInfoQのために執筆したシリーズ記事です。これまでの記事はこちらとこちらで読むことができます。
著者について
Doug Hudgeon氏はManaged FunctionsのCEOでもあります。Managed Fuunctionsは、企業のローコードおよびRPAチームのプロジェクトが直面する厄介な問題に対処するカスタムコンポーネントを提供することによって、プロジェクトデリバリの迅速化を支援するインテグレーション企業です。中でもユニークなのは、提供するコンポーネントがサーバレス関数として企業のクラウド(AWS、Azure、GCP)にデプロイ可能であるため、ソリューション全体をそれらのインフラストラクチャ上で運用することが可能な点です。さらに氏は、ビジネス上の現実的な問題をAWS SageMakerを使って解決する方法を記したManning(出版社)の書籍"Machine Learning for Business"の著者のひとりです。氏の言動はTwitter上で見ることができます。