2022年末に、当社にとって嬉しいニュースがありました。「TOHOKU DX 大賞2022」業務プロセス部門 最優秀賞にプラスエンジニアリング株式会社が選ばれました。
www.atpress.ne.jp
同社は多品種少量生産のERPシステムを構築するにあたり、最初はERPパッケージを選定していました。しかしどのパッケージを採用してもカスタマイズが避けられず、カスタマイズ込みの導入価格は予算オーバーでした。そのようなとき株式会社パルシスよりWagbyによる再構築の提案を受け、開発を委託しました。
このプロジェクト開始は 2011 年スタートでした。そのときの Wagby は R6 でした。
最初のリリースが無事に終了したあと、開発を行ったパルシス社は Wagby の販売パートナーになりました。
その後もパルシス社は継続してプラスエンジニアリング様の追加要望に応えていき、Wagby のバージョンも上げていきました。10年も継続した結果が今回の受賞につながっています。
その間、私たちもパルシス社から「Wagbyにこういう機能がほしい」というご要望をいただき、一部は共同開発という形でWagbyの機能強化に取り組んできました。
今回の受賞の報をいただいたとき、これまでの経験を思い出すと同時に、あらためてSIer とローコード開発の関係について、考えを巡らす機会になりました。
ローコード開発はスクラッチ開発の代替になっているのか
奇しくも、さった12月14日に、ローコード開発コミュニティ主催イベントで「ローコード開発はスクラッチ開発の代替になっているのか」というテーマのパネルディスカッションが開催されました。
パネラーからいろいろなコメントが出ていたのですが、ローコード開発ツールとの付き合いの深さと比例している印象でした。もちろん、SIerのエンジニアが「がっつりと」そのツールに取り組めば、ノウハウが蓄積されていくことは間違いありません。つまり問題はSIerの技術力ではなく、そこまでやるかどうかの動機付けが（会社として）あるかどうか、という話になります。
ここで昔から議論になるのが「ローコード開発ツールによって開発工数が削減されれば、SIerの売り上げが減る問題」です。この点が会社として深くコミットするかどうかの判断を悩ませているのでしょう。
私自身は2006年から東京を中心に Wagby の展開を図ったとき、すでに次の二点を説明していました。
- 単価をアップする。
- 売上ではなく、利益率に注目するように経営指標を変える。
ただし、この二点は聞いてはいただけるものの、納得されるか、というと微妙な距離感がありました。
まず単価アップといっても、工数減のインパクトを吸収できるほどではありません。また、エンジニアの人事評価問題にも影響があります。技術力による生産性向上ではなく、ツールによる生産性向上はどう解釈するか、です。
次に「競合他社に比較して（見積もり金額が下がることで）受注確度が高まる」という解釈は、営業に携わる人からは不評でした。ノルマ達成のために小さな案件をたくさん抱えるのは非効率だから、というのがその理由です。
また「ツール利用で不具合が減れば手離れがよくなるため、より多くの案件をこなしやすくなる」という説明も、逆に切れ目なく案件を獲得することの困難さを指摘されました。
これらに加え、そもそもこのようなツールがお客様の要件を完全にクリアできるのか、という懸念は常にあります。案件ごとに判断するしかありませんが、その判断のためにはある程度の経験が必要です。
つまり、SIer にとって、根強い反対意見を払拭できるほどのメリットを感じないということです。
パルシス社とジャスミンソフト社はどう考えたか
とはいえ少数ながらも、例えば今回のパルシス社のように Wagby をやりこむような SIer は実際に存在します。何社かは Wagby の販売パートナーになっていただいていますが、そうでないところでも Wagby のエンジニア育成に積極的なところがあります。
その動機付けの一つではないか、と私が感じているのは、お客さまとの関係性の再構築というテーマです。
これまでのSIerのビジネスモデルは「大量のエンジニアを集め、厳しい納期を遵守して、要件をクリアするシステムを開発することで売上を計上する」ものでした。このモデルは一時的に大きな売上を達成できますが、一方でエンジニアの要員確保の困難性、せっかくアサインしたエンジニアでも厳しい環境から生じる心身疲弊問題があることや、請負契約のため解釈の違いが裁判沙汰になる、といったリスクを抱えていました。
SIerがお客様にWagbyを提案するとき、同時にこの関係性の再構築を行なっている、と思います。もちろん各社に温度差はあるでしょうが、少なくとも次の点を意識しているのではないでしょうか。
- 少人数開発により、一時的に大量のエンジニアを集めるという業務から解放される。
- 少人数開発の開発者を自社（あるいは自社に近いパートナー）に集約し、管理コストを下げる。
- プログラミング能力によるスキル評価から、ツール活用を前提としたお客様の満足度評価に軸足を移す。
- お客さまと長くお付き合いする関係を構築する。そこには下請けではなく、対等な関係という意味合いも含まれる。
- お客さまにも開発に積極的に関わってもらうようにし、お客さま vs SIer という対立関係をなくす。
ここでポイントとなるのは「ツールベンダー（ジャスミンソフト）」をどう位置付けるか、です。
Wagbyを有効に活用しているSIerは「お客さま、ジャスミンソフト、そしてSIer」の関係構築に積極的に関わります。つまり単なるツール利用ではなく、３社が顔の見える関係となることで、より融通の効くパートナーになろう、ということです。
私はこの関係構築を一つの理想型とみています。システム開発は人間臭い面があります。メールなどでは伝わらない要件も、会話することで解決あるいは、もっとよい方法がみつかることは珍しくありません。一次受けのSIerの一部エンジニアだけがお客様と会話して、実際に手を動かす方は多重下請け構造の末端にいるという関係はまったく不毛です。
さらにツールベンダーを巻き込むことで、ツールの機能強化に、目の前の案件のニーズを含めさせることができます。「このお客さま案件を成功させるために、ツールを改善してほしい」という話ができるのは、遠い距離では難しいでしょう。ツールベンダーが国内にあることの意味がここにあります。
少人数開発の生産性の高さは、ツールの力だけではありません。このような風通しのよいチームになっているかどうかも重要なポイントと思います。
このための第一歩が、SIerとツールベンダーの深い関係構築です。これはなぁなぁになるという意味ではありません。よい緊張感を保ちつつお互い可能な限り情報を共有し、お客さまの課題解決に知恵を出すようにする、ということです。
日本の多くのSIerが苦手としているのは、この点だと感じています。なぜかツールベンダーとの関係構築を避け、自分流の解釈で進めようとするところが多いのです。早い段階で聞いてもらえれば即答できたことでも、納期直前に問い合わせされると解決できなくなります。
では深い関係構築ができるとお互いに何のメリットがあるのでしょうか。それが今回の受賞にあるように「お客さまのメリット」につながりやすい、ということです。ここで、お客さまのメリットは「納期、予算、品質」だけではありません。「安定した開発体制の提供」や「（ツール機能を活用した）コストを抑えた現実的な代替案の提示」も含まれます。
まとめますと、ローコード開発はスクラッチ開発の代替になっているのか、というのは技術面というより SIer による従来ビジネスモデルからの転換を含めた議論になっています。これまでの営業・開発スタイルを変えずにツールを採用しようとしてもメリットは少なく、懸念だけ注目されがちです。お客様との関係の再構築という観点でビジネスモデルを変える、という気持ちを持っていただけるかどうかがポイントです。
私たちジャスミンソフトは引き続き、パルシス社をはじめとするWagbyパートナーと連携してお客さまに喜んでいただけるような体制をつくっていきたい、と考えています。あらためてプラスエンジニアリング様、受賞まことにおめでとうございました！
