Mendixの成り立ち

どうやって始まったのか？

2000年代初頭、Mendix創業メンバーはソフトウェア開発に関わる中で、せっかく長い時間をかけて構築しても、顧客を満足させられないことが多いことに気づきました。要件定義書などのドキュメントを大量に作成し、長時間の会議を行っても、ビジネスを進めたいビジネス側とソフトウェアを構築するIT側のギャップは埋まりませんでした。 このギャップを埋めない限り、ビジネスに本当に役に立つソフトウェアとは言えません。この問題に取り組むことから、Mendixは始まりました。

開発者の視点

IT側はこの問題を解決するため、フローチャートやユーザインタフェースのモックアップ、プロセスマッピングなどの視覚的なツールを使い、コーディングを始める前に完全にビジネス側と一致させるというアイディアを用いて進めようとしました。 一方、IT側は以下のような問題を長い間解決できずにいました。 ・ソフトウェアの構築は要件定義と設計の段階でほぼ完了し、コーディングは単調な作業にな　

　る。 ・プログラミングの多くは反復的なタスクとなってしまう。 ・アプリケーション全体でみるとOS、DB、フロントエンド、バックエンドといった特定のスキ

　ルごとでの分業となり、大きなリードタイムが必要になる。

ビジネス側の視点

ビジネス側は、IT側に対して以下のような疑問を持っていました。

・なぜ開発者はビジネスニーズを明確に理解するのが難しいのか？ ・なぜ多くのプロジェクトは失敗するのか？

・なぜいつも無駄な時間とコストがかかるのか？

どうしたらビジネス側とIT側間のギャップが埋まり、さらにそれぞれの部署にある問題を解決できるのか？ さまざまな試行錯誤の結果、視覚的にモデルを作成し、モデルが自動でアプリケーションとして稼働する方式（モデル駆動開発（MDD））の実現を目指すことにしました。

MDDに着手

このアプローチのポイントは以下の2点です。 ・ビジネス側とIT側双方のイメージを抽象化 ＝従来のコーディングよりも高い抽象化レベルで

　アプリケーションモデルを定義します。 ・自動化 ＝その後、このモデルは自動で解釈される機能によってアプリケーションに変換され

　て実行されます。 このMDDのアプローチでは、コードを生成するのではなくモデルを作成し、このモデルが自動実行されます。モデルは、自動的に解釈して実行されるソフトウェア アプリケーションに変換されます。これによりコードを生成する必要がなくなります。 MendixのMDDは全て視覚的に進めることができます。 これはビジネス側から見て常に要件が実現されていることを確認することができると同時に、IT側が抱える問題点も解決できる可能性を生み出しました。

ギャップを埋める開発プロセス

Mendixは、ビジネスとITのギャップを埋めるためにはテクノロジー以上のものが必要であると考えています。ビジネス側の利用者、IT側の開発者などの関係者があらゆるステップで関わり、構築したものを素早くリリースしてすぐに確認してフィードバックするという、反復的でアジャイルなプロセスが必要です。

このプロセスはどんなソフトウェア開発プロジェクトにも適用できます。高速で視覚的なMDDと反復的なアジャイルプロセスの独自の組み合わせにより、開発が大幅にスピードアップします。 それは同時にビジネス側の満足とIT側の開発者の多くのフラストレーションを取り除くことにつながり、ビジネスを成功へと導きます。 こうして、Mendixは誕生しました。

なぜ“Mendix”という名前なのか？

Mendixの由来は、「修復する(mend)」という意味を持つ動詞です。これは、破損、破れ、不具合などを修復することを意味します。

Mendixは、ビジネスとITの間の根本的なギャップをうまく「修復」することによって、ソフトウェア主導型の世界でビジネスの成功の支援に全力で取り組んでいます。