2022年になりました。読者の皆様、あけましておめでとうございます。
昨年はローコード開発、ノーコード開発というキーワードが一気に浸透した一年でした。私も運営に関わっている「ローコード開発コミュニティ」への参加希望者が増えていることからも、その勢いを感じています。
ところで、このようなブーム到来のあとは決まって「逆風」がやってきます。おそらく2022年は揺り戻しがくることでしょう。私が想定するツッコミは次のとおりです。
- 簡単なアプリは確かに素早く作れそうだ。しかし基幹系への適用は無理だろう。なぜならまともな方法論がないから。
- 市民開発者、というと聞こえはいいが、昔の EUC ブーム（End User Computing) の末路はどうなった？ 野良Excelの氾濫は好ましくない。
実は私たちは2006年のWagby市場投入から、ずっと似たような指摘を受けてきました。つまり、すでに耐性があります。これをしっかりと説明できるような「備え」を行うようにしましょう。この、やってくるであろう逆風下にあって実績を出せた企業だけが生き残る、と思うからです。
ローコード開発ツールで基幹系、のための方法論
私たちのこれまでの経験を、文章として整理しよう、というのが今年の取り組みの一つです。骨子は次のとおりです。
左側が望ましい構造で、右側は避けるべき構造です。
最初にデータ構造を規定しましょう。これをデータモデルと呼びます。そのデータをどう操作するのか、そして最後に利用者とのインタフェースを考えます。この整理について具体的な手順、成果物、べからず集、そして発注者（ユーザ企業）とSIerとの役割分担、責任分界点を示し、協力して進めていく体制を示そうと思います。「統合データベース」こそが基幹系の心臓部です。
しかし現実には多くの案件で、右側のアプローチが採択されてしまっています。これはサブシステムごとに開発しやすいという誤った解釈の産物でしかありません。開発の後半でデータ整合性の問題が浮上し、この対策と称して（本来は不要な）データ連携のためのコストが追加されてしまいます。このコストは今後何年にもわたって支払うべきものとして重くのしかかってきます。
問題があるとわかっているにもかかわらず、なぜ左側の構造は敬遠され、右側が（将来、高コストになるとわかっていながら）採用されてしまうのでしょうか。
データモデルに切り込むことは、必然的に部門間の調整が生じます。私見ですが、日本人がもっとも苦手なのが、この「縦割り組織の横串化」です。関係者との調整は人間関係の面倒さに直面し、大抵の場合、当事者は嫌われ者になります。ここに踏み込まなくてよいのが、サブシステムごとにつくってしまう右側の構造で、特に部門内の関係者だけで UI の同意さえとってしまえば、ひとまず作り切ることができます。これはサブシステム間のデータ連携の手間を見なかったことにするため、問題の先送りです。
開発を委託されたSIerの立場からは「要求通りに作ったので運用してください。運用の面倒さはお客様も納得されたでしょう？」となるのかもしれません。しかし私はプロとして、お客様にとってこの問題がどれほど重要で、あとになって禍根を残すか、を最初にきちんと説明したい、と考えています。
私がここにこだわるのは、企業が本当に乗り越えなくてはならない DX というテーマに、縦割り組織の横串化 = 統合データベースが絶対に必要、という気持ちがあるためです。せっかくのローコード開発ツールも、ここをおろそかにしては結局、今までと同じような高コスト体質で変更要求に弱いシステムを単に「いままでより早く開発できた」だけ、です。
他にも「大規模開発にありがちなコミュニケーションコストの削減」や「設計情報と実装の乖離をなくす」こと、「設計情報があるゆえの、影響分析の迅速な把握」といった興味深いテーマもありますが、ここでは割愛します。一丁目一番地はなんといってもデータ中心設計です。
この原則を遵守した基幹系開発の刷新を、ローコード開発ツールを使って実現すること。これが認められる価値になると考えています。このような案件を受注することはお客様の覚悟を問うため簡単ではありませんが、これが王道と言い続けてお客様にご納得いただける受注実績をつくることができるか、です。
ノーコード開発は野良アプリ濫造機、という懸念を払拭する
昔の EUC では、文房具化された一人一台の PC にそれぞれデータを保管する形で浸透しました。つまり統合データベースの欠如 = 社員の数だけ Excel データがある、ということが問題の本質であった、と考えています。ファイルサーバへ格納して全文検索システムでファイルを探す...というアイデアは、根本的な解決策ではありません。いわんや RPA を使って複数の Excel を連携させるというのは、涙ぐましい努力ではあるのですが、問題の先送りがここまできたかと嘆息せざるをえません。
しかしノーコード開発はクラウドでの展開が主戦場になりました。よってツールではなくプラットフォームと捉えることができます。そこでポイントになるのは、ここでもやはりプラットフォームで共通のデータベースを利用できるかどうか、でしょう。
市民開発者が統合データベースという考え方を踏まえてアプリを開発していくことが理想です。つまり個々人がばらばらに開発することを防ぐ仕組みを最初で備えておきたい、ということです。これを土台として、既存の社内システムのデータ再利用（既存のExcel含む）、そして複数のクラウドシステムとのデータ連携、へと視野を広げていくことが望ましいでしょう。
現場に任せるところと、しっかりと制御すべきところの責任分界点をどこに据えるか。この話はローコード開発における部門間調整の面倒さと変わりません。つまり「社内のデータの責任者は誰か」を明確にすることです。繰り返しになりますが、DXの根幹は、ここを抑えることができるか、にかかっていると考えています。
DX時代のシステム開発の理念を共有しつつ、現場を開発に巻き込む時代へ
ローコードノーコード市場の拡大を「誰でも簡単に開発できる魔法のツール」といって売り歩くことで果たすなら、今後予想される逆風に耐えられないでしょう。統合データベースの確立こそが DX 時代に重要であるということを組織内で共有し、その上で現場を開発に巻き込むことが、求められていることです。
そして開発で迷った時は（昨年の Wagby Developer Day 特別講演で羽生さんが言われた）「ノーモア コピペ、ノーモア 再入力」を思い出しましょう。念仏のように唱えることで、おのずと統合データベースに近づきます。
2022年のWagbyの営業活動は、この原則を忘れずにお客様に説明していく所存です。本年もジャスミンソフトをよろしくお願いします。
