ローコードでITとビジネスのギャップを埋める方法
従来の開発は、ここ数年で大きく進化しました。かつては、開発はプロのコーダーによってのみ行われ、彼らはアプリケーションをできるだけ効率的に作成することだけに集中していました。アプリケーション開発の背後にあるビジネス上の根拠は、コーディングの決定にほとんど影響しませんでした。開発者の責任は、指示されたアプリケーションを、できるだけ少ないコード行で愛情を込めて作成することだけでした。
ただし、このようにアプリを計画して構築することは、両端から線路を敷設するようなものです。一方の端では市場計画に細心の注意とスキルを注ぎ、もう一方の端ではコーディングに細心の注意とスキルを注ぎ込むことができます。しかし、ビジネス チームと開発チームが中間で出会うと、構築した線路が一直線に並んでいないだけでなく、一方のチームがトロッコ用の線路を構築し、もう一方のチームが新幹線用の線路を構築していることに気付く可能性があります。
そのため、企業はビジネスとプログラミングの両方の知識を持つ人材、つまり中間から軌道を組める人材を頻繁に採用しています。ガートナーは、このクラスのプロフェッショナルを ビジネス技術者 そしてそれらを次のように定義する 「社内外の業務で使用するためにテクノロジーや分析機能を構築するが、IT 部門の外部に存在する従業員」 ガートナーは次のように推定している。 ビジネステクノロジストは労働力の41%を占める.
ビジネステクノロジストの影響
コード作成者の時代、ビジネス リーダーは開発チームに「この市場のニーズを満たすアプリが必要です」と伝えていました。開発プロセスはブラック ボックスの中に消え、数か月後には完成したアプリケーションが完成していました。
このシステムの問題は、数か月後には市場がまったく異なる状況になる可能性があることでした。 Mendix, ロアルド・クリュイトは、「アプリケーションは時代遅れになる」と言います。彼が言いたかったのは、アプリケーションの開発が完了する頃には、そのアプリケーションを作成するきっかけとなったビジネス ニーズに対する理解が進化しているということです。
アプリケーション配信エコシステムにビジネステクノロジストが存在することで、開発プロセスにおいて常にビジネスニーズが最優先されます。ガートナーによると、ビジネステクノロジストを多分野にわたる開発チームに統合することで、 チームのパフォーマンス率が2倍になるガートナーは、2024 年までにテクノロジー サービスの 80% がビジネス テクノロジストによって構築されると予測しています。
このパフォーマンスへの影響を最大化するために、企業はビジネス テクノロジストのスキルと、アプリケーションの最終的な納品ではなく継続的な反復を重視する開発プロセスを組み合わせています。これにより、反復サイクルごとにビジネス ニーズを継続的に評価し、それをアプリケーションが生成しているビジネス価値と比較できます。
採用において重要な資質
企業は、提供する顧客体験で差別化を図ろうとする傾向が強まっている。しかし、ガートナーの調査によると、顧客体験リーダーの70%が プロジェクトの作成に苦労するカスタマー ジャーニーの知識を持つビジネス テクノロジストを雇用することは、開発プロジェクトをカスタマー エクスペリエンスのニーズに合わせるための重要な方法です。ビジネス テクノロジストを従業員に組み込むことは、広範な開発経験を必要としないローコードおよびノーコード プラットフォームによって、はるかに容易になりました。革新的なアイデアを持つ従業員は、最小限のプラットフォーム トレーニングを受けるだけで、そのアイデアを実現できます。
開発の民主化により、組織は採用を決定する際の優先順位を変えています。革新的なソリューションやコア アプリケーションを作成するチームを構築する場合、候補者の技術的知識や開発の専門知識をそれほど気にする必要はなくなりました。履歴書で適切な箇条書きを探す必要もなくなりました。
代わりに、創造性、ビジネス感覚、分析能力など、やや無形かもしれないが組織の成功に不可欠な資質で候補者を判断できます。採用基準は、ツールの使い方をよく理解している人を見つけることから、ツールを使用して何を構築するかをよく理解している人を見つけることに変わります。
構築方法を変える
組織がアプリケーションの構築のために雇用する人材が変わると、必然的に、組織がそれらのアプリケーションを構築する方法も変わります。企業全体にわたる複雑なソリューションを作成する時代は終わりに近づいています。こうしたタイプのプロジェクトには、ビジネス テクノロジストが組織から排除している、詳細な開発の専門知識が必要です。また、IT チームにリソースと制御を集中させる必要がありますが、ローコード ツールによってこの組織モデルは時代遅れになっています。
代わりに、組織はアプリケーション開発を分散化する必要があります。各チームがニーズに最適なソリューションを知っていることを信頼し、それらのチームにそれらのソリューションを構築するためのツールを提供する必要があります。長年、コンプライアンスリスクや互換性のないシステムを恐れる組織は、開発責任の外部委託、つまり「シャドーIT」を推奨していませんでした。しかし、ビジネステクノロジストは シャドーITを影から追い出す.
これは、アプリケーション開発が自由放任になったということではありません。効果的なソリューションをタイムリーかつ効率的に構築するには、調整とリーダーシップが依然として重要です。従うべきモデルはいくつかあり、 Mendix は、これらのモデルに沿って顧客を組織化する支援の経験があります。
卓越したセンターたとえば、組織は開発の専門知識、再利用可能なコンポーネント、ガバナンスガイダンスの中央リポジトリを作成し、ビジネスチームが専門的なソリューションを構築する際にアクセスできるようにします。そして、それらのチームは次のように構成できます。 フュージョンチーム コーディング、販売、市場分析、物流、コンプライアンスなど、さまざまな専門知識を持つメンバーを集めて、特定の期間内に特定の製品を作成します。
フュージョン チームに関する詳細情報は次のとおりです。
誰もが同じ仕事をしている：成功を築くこと
アプリケーション開発の民主化の最終目標は、次のようなツールの助けを借りて、 Mendix ローコード プラットフォームの目的は、IT 担当者が片側から、ビジネス担当者が反対側からという形で線路を敷くのをやめることです。私はそれが理解できませんでした。営業、人事、IT、マーケティングのいずれの部門であっても、全員が同じビジネス目標から始めるべきですよね? ですから、候補者の経歴やトレーニング、専門知識に重点を置くのはやめましょう。彼らが私たちのビジネスの成功に貢献するかどうかに重点を置き、その成功を築き、会社を拡大するために必要なツールを彼らに提供しましょう。