馬場直道（ばば なおみち）

親がPC好きで、小さいころから家のPCでゲームするなど親しんでいました。その影響もあってか、高校生くらいの頃から将来はコンピュータ使った仕事をやりたいと考えていましたね。

高校ではパソコン部に入り、周りの仲間と一緒にVisual Basicでトランプゲームとかを作ってました。

自分の考えたことがカタチになって動くのがとても気持ちよかったし、自分が作ったプログラムを周りの皆に遊んでもらって「楽しいじゃん」と言ってもらえるのがうれしかったです。そんな流れの中で、大学は情報工学科を専攻して、この業界に入りました。

私の性格や考えからして、やっぱり大企業の大きな組織の一部で言われたことをやるのは自分には合わないのかな、と感じていて、できれば全員の社員の顔がわかるくらいの小さい規模で、仲間が皆目の届く範囲にいてアットホームな感じで働ける職場がいいな、と思っていました。そのほうがいろいろ仕事も任せてもらえるし、たくさん経験できるかな、と。

そんな中、会社説明会をいろいろ見た中で、雰囲気が一番アットホームで和気あいあいと仕事ができそうだったビルドシステムに入社を決めました。

入社してからの実際の雰囲気もほぼ入社前に想像していた通りで、先輩や同世代はじめ、皆でチームとして一緒に成長していると実感できる職場だと思います。

2006年に入社してすぐに、某社の駐車場管理システム案件でJavaの開発に携わりました。

ラッキーなことにそのプロジェクトの当時の担当の先輩がものすごいJava使いで、オープンソースにも造詣の深い方だったので、おかげでプログラミングの実装面はかなり鍛えられたと思います。

また、このお客様とは今も取引を続けていただいており、これだけ長くおつきあいさせていただける案件を担当できたというのは本当にありがたい経験ですね。

その後入社６年目に、某官公庁のBI系データ分析系のプロジェクトに入りました。

さまざまなデータを分析してより効果的に業務を支援するという要件で、データベース周りの処理（SQL）をたくさん書く仕事を通じてデータベースの扱い・スキルを磨きました。

その時の上司が技術面に詳しいのはもちろん、人を育てるのが大変うまい方で、多くの仕事を任せてもらえました。自分の考えや意見をよく聞いて取り入れてくれたので、成長している実感も得られました。

さらに、マネージャーというポジションにあるエンジニアの在り方として、単なるプロジェクト管理だけでなく、あくまで技術的なスキルの裏付けのもと「こうしたほうがいい」という判断ができて、かつお客様へ明快に説明できる、というスタンスを今も常に心掛けているのは、この上司の存在と教えがとても大きいと思います。

その他の業務としては、ユーザ企業の内製化支援にも携わっています。

私自身は、ユーザ企業におけるIT化やDX推進は、最終的にはご自身で内製化していただくのが一番コスパ良く有効なシステムを構築できる開発スタイルと考えています。

一時的に外注委託すればもちろんシステムはできますが、それなりのコストがかかりますし、DXは作って終わりではなく常にユーザ自身の成長とともに変化・成長し続けないといけません。ですから可能な限り内製化して、ユーザ自身の手で常にアップデートできる体制にしておいたほうが、確実に良いと思います。

そのようにユーザ自身がシステムを組むハードルを下げる意味で、ローコードツールは強力な武器になると思います。

このような考えのもと、2013年に当社として初めてローコードツール（Outsystems プラットフォーム）を導入すると同時に、某建機メーカー向けプロジェクトでのローコードツールでの開発と、同社のエンジニアに対する技術支援・教育などを担当しました。

2016年からは、さらに進化したローコードツールであるMendixプラットフォームを導入し、システム構築や内製化支援を多く手掛けています。

これまでOutsystemsやMendixをはじめいくつか活用してきましたが、ローコードツールの導入にあたってはいくつかポイントがあります。

①なるべく標準コンポーネントの範囲で利用する
ローコードツールはコンポーネント（部品）ひとつひとつが良くも悪くもある程度完成されているので、その仕様に合うように要件を誘導しないと、多くのカスタマイズコストがかかってしまいます。

また、要求に合わせて無理にカスタマイズしようとすると、スピードが犠牲になったり、バージョンアップ時に保守性が悪くなったり、カスタム部分に対応できる人が限られたり、などの問題が出てくる場合があります。

これらの特性はどのローコードツールでも基本は同じと思いますが、まずはツールの仕様や特性をできるだけ活かす形で要件を誘導していったほうが良い結果になることが多いと思います。

②オプションコンポーネントを活用して、できることの幅を広げていく
Mendix Marketplaceでさまざまなコンポーネントが提供されていますが、常に新しいものや改良されたものが結構なスピードで追加されるので、アンテナを貼って調査しておき、引き出しを増やしておくことが効率化につながります。

③コンポーネントをカスタマイズ・自作する
標準コンポーネントでどうしても対応できない要件については、Mendixコンポーネント自体を開発する必要があります。当社にはコンポーネント改造のスペシャリストもいるので、Mendixのコンポーネントだけでは対応できない特殊な部品カスタマイズが可能です。

また、よく求められる要件に対応するコンポーネントについては、特定のプロジェクトに向けた個別カスタマイズではなく、汎用性ある形で開発することで、より多くの案件に対応できるだけでなく、Mendix Marketplaceを通じた公開や共有販売も可能になります。

つい先日も当社のエキスパートエンジニアがEXCEL帳票を作るツールを自作してMendix Marketplaceで公開しました。各所で使いやすいという評判をいただいています。

このような流通できるクオリティのものを作れるのは、MendixだけでなくJava開発などローコード以外のネイティブ環境での開発を経験している当社ならではの強みだと思います。

MendixはITを内製化しようとするお客様に最も有効に使えると思います。

Mendixはライセンスが年間でかかりますので、単発の開発だけで使って終わり、というのは正直もったいないですね。内製で常に開発し続けるスタイルでやるからこそ、このライセンス形態がフィットすると思います。

そうはいっても普通のユーザ企業で、開発にそれほど習熟していない方にとってはMendix自体の習得も大変ですから、はじめは我々のようなプロに発注していただいて、プロジェクトを通じて一緒に作りながら徐々にチームとしてノウハウを吸収していただくのがベストだと思います。また、長期のサポート契約を組んでいただければ、定期的なサポートを受けつつ内製化では対応できない難しい箇所を当社にご依頼いただくことも可能です。

ローコードツールを導入すればよいシステムができるわけではなく、しっかりした構想やシステム開発の手順を踏まないと、ダメなシステムが量産されてしまうことになりかねませんので、ツールの技術的な知識だけでなく、DXとはどういうものか、システム開発の勘所をしっかり理解しているプロと組んだうえで、技術・マネジメント両面からシステム化を推進することが重要だと思います。

Mendixなら、とりあえず動くものをPoC（Proof of Concept：試作開発の前段階における検証やデモンストレーション）的にさくっと作ってみることができます。

お試しで作る分には、インストールして、データを持ってきて、ちょいちょいっとコンポーネントを組み合わせれば割とすぐ目的のものが作れてしまうものも多いです。当初はライセンスすら買わなくてもお試しできてしまいますので、まずはもともとMendixが持っているコンポーネントをベースに動くものを作ってみる、というところから始めると良いと思います。

ちょっと気を付ける必要がある点としては、Mendixはまずデータやテーブルの構造を定義（ドメインモデル）した上で画面設計をする、という手順で設計されているので、データ中心の考え方に慣れていない方だと最初はちょっと戸惑うかもしれません。

しかし、ある程度の規模のシステムではデータモデルをきちんと設計していないと後が大変になりますし、特にMendixではデータ構造からある程度自動的に標準的な画面UIを生成する機能がありますので、慣れてしまえばかえって開発効率は良くなると思います。

ある程度動く画面を標準機能ベースでさくっと作って実際のユーザに見せると「これは大変だと思っていたけど意外と簡単にできそう」とか「これができるなら、こういう機能も欲しい」などの気づきを与えられることもあり、要件整理や新たなアイデア出しがスムーズかつ効果的になります。

案件にもよりますが、感覚的にはさまざまなお客様の要件は、標準機能＋オプションコンポーネントで８割程度は満たせるくらいMendixのコンポーネントはよくできていると思います。

残りの２割をどれくらいのコストかけて実現するか、については、
・本当に必要な機能なのか？
・コストをかけてでも実装したほうがいいのか？
などをPoCベースで具体的に議論できるようになるので、ありがたいですね。

SIerという立場では、複数のお客様の案件を掛け持ちしたり、ひとつのお客様の中でさまざまなバージョンのシステムを同時に管理するケースもあるのですが、Mendix Modelerを使うとそれぞれバージョンが違っていたりしても同じ環境で統合管理して簡単に切り替えられるのがとても助かっています。

バージョンを上げるとパフォーマンス改善したりする例もあるので、新しいバージョンや機能を気軽に試せるというのはローコードツールの場合とても重要なポイントなのですが、これだけ多くの案件を掛け持ちでやっていてもそれほど苦にならないというのはSIerの立場としてはとても助かっています。

また、仕様についてお客様と合意をとるプロセスとして、設計書を描いて確認をとるプロセスは大切ですが、ドキュメントが最低限で済むのもありがたい点のひとつですね。

もちろん最低限のドキュメントとして概念ER図、システム全体構成図（画面遷移図）、画面のUI概念図くらいは記述しますが、詳細ER図や画面項目定義などはMendix自体でも確認できますし、テーブル項目一覧やJavaDocに相当するようなコメント情報はドキュメントとしても落とせる、というのはとてもありがたいです。

Mendix自体を動かすだけなら標準のMendixCloudでも良いのですが、非機能要件によってはコンプライアンスやセキュリティの理由でそれでは満たせないことがあります。その場合は別途ご用意いただくAWSなどで動かすことになるのですが、これまで私はアプリ開発を中心に携わってきましたので、そのあたりのインフラ知識を強化して成長していきたいですね。

そういった幅広い知識を身に着けることで、要件のバリエーションに対応できるとともに、スピードや安定性に関しても自信をもって提案できる、どこでもどんな案件でも通用するエンジニアになりたいです。

もうひとつは、Mendixを使えるお客様、パートナーをもっと増やしたいです。

先ほど申し上げたように、ユーザ企業のIT化は内製化したほうがよいとの考えを持っていますので、そういうインハウスエンジニアの方々の支援に継続して取り組みたいです。

当社のマーケティングチームではMendix自体の普及啓蒙活動にも積極的に取り組んでいますが、そのような活動と両輪で、私はいわば「コーチ」として現場でのサポート活動を通して顧客からの信頼を得ながらパートナーや仲間を増やしていきたいと思っています。