開発チームは何年にもわたって過負荷のバックログに対処してきましたが、2022 年以降、より多くの組織がローコード/ノーコード ツールを採用し、「シチズン開発者」が増加すると予測しています。最近のApp Developer Magazine のトレンド記事 では、市民開発者が日常的に使用するツールがアプリ開発のさまざまな側面を担うだろうと述べています。これは、すべてのエンタープライズ アプリを意味するわけではありません。複雑なアーキテクチャを必要としないアプリ、またはハード SLA でミッション クリティカルとはみなされないアプリを意味します。記事では次のように述べられています。
設計からコードに移行する際に、コストと時間を最大に節約できる秘密は、「コードに変換」してそこからカスタマイズできる、よく考えられた一連の UI パターン、つまり UI コントロールを使用することにあります。
これは、App Builder ™ のようなデザインからコードまでのツールによく適合しており、UI コントロールと一般的な UI パターンにマップする定義されたデザイン システムにより、大幅な時間の節約が見出されます。デザインがコードである場合、デジタル リーダーが直面する 2 つの大きな問題に対処することになります。
歴史的に、テクノロジーリーダーは過去のブラックボックス/コード生成アプリケーションに「噛まれ」てきました。 1990 年代と 2000 年代、多くの ORM のようなツールの約束は、何よりも「約束が過剰で、提供が不十分」でした。コードはおそらく本番環境に対応していましたが、編集できず、再利用できず、自動テスト製品にも準拠していませんでした。現在、このレガシーは、本番環境に対応したテスト可能なコード出力でアプリの配信を真に加速できる最新のツールに悪影響を及ぼしています。
Information Week の 最近の記事で、ローコード開発者とシチズン開発者は当初から進化してきましたが、まだ成長の余地があると述べました。ローコード、ノーコードのプラットフォームは本当に進化する必要があります。特に、ローコードには、内部アプリだけでなく消費者向けのアプリケーションを提供するための UX および設計の専門家からの入力 (および UX プロセス) を含める必要があります。コードが運用準備ができていてテスト可能であっても、アプリケーションのエクスペリエンスがユーザーの期待を満たさない場合、演習全体が失敗となります。
設計チームが通常の反復的な設計プロセスの一部としてユーザーと関係者を含める場合、開発チームが使用可能なコードで得られる柔軟性と相まって、これらのツールに対する認識は変わります。テクノロジー リーダーが、たとえば、一般的なアプリ開発サイクルにおける数週間から数か月の時間の節約に価値を見出している場合、デザインからコードまでのローコード ツールの導入は簡単な決定になります。
UIプロトタイピング、デザインシステム、ユーザーテスト、アプリ構築、コード生成を統合したローコードプラットフォームに関しては、絶対位置コンポーネントを持つ一連のSketchアートボードでさえ、人工知能ヒューリスティックを通じて適切なWebレイアウトに変換されます。このような複雑な問題をツールでうまく解決すると、これらのツールへの信頼と依存度が高まります。Gartner と Forrester の先行調査を見ると、今後 5 年間でローコードはソフトウェアを構築するための主要なオプションになると予想されています。テクノロジーリーダーは、企業がユーザーエクスペリエンスデザイン、ユーザーテスト、コード出力の観点からローコードの動きを見て、ステークホルダーにより良いエクスペリエンスをより迅速に提供している場合、ローコードの動きに対抗するのが難しいと感じるでしょう。
他のツールと同様に、個人やチームが新しいものを採用することは困難です。しかし、ツールを保持し、ツールとプロセスの上に軽量のツールを重ねて、ソフトウェアの提供を劇的に改善できるとしたらどうでしょうか。Code Magazine の記事「Eliminate Waste During Designer to Developer Handoff」では、反復設計スプリントの概念と、これをプロセスに追加し、App Builderや統合設計システム (Indigo.Design) などのツールを使用して設計スプリントのコラボレーションを支援し、最終的に設計からコードを取得して製品アプリで使用できる方法を紹介しました。
デザインスプリント は、新しい製品、サービス、または機能を市場に投入する際のリスクを軽減することを目的として、デザイン思考を使用する、時間に制約のある 5 フェーズのプロセスです。これをさらに一歩進めて、このプロセスをアジャイル開発プロセスのスプリントのように考えます。あなたの目標は、開発プロセスを先取りしながら、問題に対処し、仮定を検証し、プロトタイプを作成し、機能やエピックのユーザーテスト を行うことです (2 週間、3 週間、またはそれ以上かかるスプリントのタイミングを計ることができます)。つまり、アジャイルという用語は、アプリケーション開発者だけでなく、デジタル製品チーム全体も含まれます。App Builder、このレイヤーを既存のツール(SketchやFigmaなどのデザインツール)に追加して、ユーザーテスト、コラボレーション、開発者WYSIWYGを追加し、開発者がVisual Studio Code、GitHubなどの選択したツールを引き続き使用できるようにすることができます。
実際には、設計チームは設計を繰り返し作成し、関係者からのフィードバックやユーザーによる設計のテストに基づいて変更を加えます。ユーザーテストを伴う反復設計は、開発者より 1 スプリント早く設計アクティビティを実行するため、アジャイル プロセスによく適合します。スプリント 1 では、設計チームが最初の機能セットを設計し、関係者のフィードバックを得て、ユーザーとともに設計を迅速にテストし、設計を繰り返します。ユーザビリティテストは、忠実度の低いプロトタイプを使用して迅速に実施できます。開発チームは、その後のスプリントでユーザーテストによる最終的な設計に取り組みます。この 2 つのトラックのスプリント プロセス (1 つは設計、もう 1 つは開発) は、標準化されたツールと堅牢な設計システムと組み合わせることで、確実に成功を収めます。
アプリケーションは単独で構築されるわけではありません。複数の関係者、顧客を含めた反復的な設計プロセス、効果的なユーザー テスト、シームレスなコラボレーションが、成功する製品を生み出します。しかし、「開発者がデザイナーに知っておくべき 7 つのこと」 で述べたように、「開発者への需要が高まっているにもかかわらず、技術的人材の不足が広く文書化されており、開発者とデザイナーの役割と両者の間の力関係が根本的に変化しています。かつてデザイナーは美しいインターフェイスを考案することだけに責任を負っていましたが、現在ではユーザーのフロントエンド UI/UX エクスペリエンス全体を定義することが求められることが多くなりました。また、過負荷の開発者に対する直接の門番であるため、プロジェクトを開発に引き渡す前に、無関係なコーディングや明確さの欠如につながる可能性のあるものを排除することが重要です。」
テクノロジー リーダーとして、プロセスだけでなくコラボレーションやコード出力も改善できるツールに注目することが重要です。開発者を雇うのは難しく、デザイナーは Web 開発や Web レイアウトの専門家ではありませんが、ツールを使用するとこれらの複雑さが解消され、以前は数週間または数か月かかっていた作業が、数分または数時間で同じことが可能になります。
クラウドベースのWYIWYG App Builderを使用すると、開発者はSketchファイルやAdobe XDファイル、または事前に作成されたテンプレートを実際のUIコンポーネントにすばやくマッピングし、デザインを実際のコードとして即座にプレビューし、Angular、Blazor、Web Components、Reactで本番環境に対応したコードを生成してGitHubにアップロードしたり、お気に入りのIDEにダウンロードしたりできます。
