夏に開催している Wagby Tech Meet in Okinawa が今年も無事に終わりました！参加者の皆さま、二日間おつかれさまでした。
今年は趣向を変えて恒例の屋外ビーチパーティを、ラグナガーデンホテルの宴会場に変更してみました。そのため当社スタッフの準備時間が減り、お客様とお話しする時間が増えたことはよかったと思います。お料理もおいしかったので大満足でした。
もちろんパーティだけではありません。今年の Tech Meet のプログラムは次のとおり。
| 7/24 | 14:00-14:50 | データモデリングとWagby |
| 15:00-15:50 | スクリプトによるローコード開発 | |
| 16:00-16:40 | DojotoolkitによるUIカスタマイズ方法 | |
| 16:50-17:10 | Wagby R9.3.0 中間報告 | |
| 7/5 | 10:00-10:50 | カスタマイズ事例紹介 |
| 11:00-11:20 | Software BOMについて | |
| 11:20-11:30 | Wagby Developer Days 2024 企画案内 |
私が最初のセッションでお話しした「データモデリングとWagby」が好評でしたので、少しこの話をします。
上流設計の一丁目一番地は、データモデリング
はじめに、私が現時点で解釈しているデータモデリングの意義を明らかにします。
どのような活動を行いたいか、そのために必要な情報は何かを定め、それを支えるための正確で揺れのないデータを収集、保全するための仕組みを考えること。
さて"モデリング"とは、切り口によって形が変わることを含む用語です。上流の要求が変われば、自ずとモデリングの視点も変わります。そのためデータモデリングは当然、上流工程で行うべきです。さらにいえば、集めることのできるデータの質と量から、業務が規定されます。要求を理想としたとき、現実的視点を与えるのは（収集可能な）データです。
ではデータモデリングは上流工程の、どのタイミングで行うべきでしょうか。
多くのプロジェクトでは、業務の処理（プロセス）から可視化しようとします。これにはUIデザインも含まれることが多いでしょう。誰がどういう業務をすると、こういうアウトプットが得られる、そのためにこういうUIがあるといい、という考えはもちろん必要です。そして、その処理とUIを支えるデータはどういう構造になっているか、という検討も必要になります。
さて、もし業務処理ごとにサブシステムとして分割検討されると、閉じた業務処理の中でデータが規定されることでしょう。結果として処理単位でデータの重複、意味違いが生じる可能性が高くなります。これはもちろん、よろしくありません。このまま設計を進めてしまうと、最終的に無駄な「データ連携」という処理が入り、つじつまあわせをすることになってしまいます。
これを避ける最良の方法は、業務の概要から、こういうデータ構造になるだろうと仮定したデータベースをはじめに設計することです。その上で、この処理はこのデータを参照する、このデータを更新する...というように、処理とデータを対応づけます。このようにすることで、データの重複や意味違いが早い段階で整理されます。業務全体をとおして「データ辞書」が整備されるわけです。このメリットはもう一つあり、解釈違いをなくすことで、実は不要だった業務処理というのがみつかることもあります。業務の再デザインにつながるきっかけになります。
これはDXとも実に相性がいいことがわかります。DXは業務の一部に先進的テクノロジを導入して改善するものではありません。新しい目的にそって業務を再デザインするときに、可能な限りデジタル技術を活用しようという一連の活動であり、ここでいう業務の再デザインには、扱うデータの質と量の変化を伴います。データモデリングは切り離せません。
よいデータモデルからは、「各人が最小限の入力工程で」「必要なデータだけをリアルタイムに把握でき」「次の活動を行うための情報を得る」ことを支援するアプリケーションが構築されることでしょう。
データモデリングと相性のいいWagby
Wagbyはデータモデリングを行うツールではありません。データモデリングの成果物をWagbyの設計情報として入力することで、そのデータモデルから即座に動くアプリケーションを用意します。つまり、アタマの中で考えたデータモデルを、具体的なアプリケーションとして操作することで、そのデータモデルの妥当性を早い段階で検証できるということです。
ここからわかることは、次のとおりです。
- データモデリングは一回だけ行うものではない。仮説を検証し、不備を修正するという繰り返しの中で鍛えられるものである。
- データモデリングの成果物としてER図などを出力しても、この妥当性を理解するのは難しい。具体的なアプリケーションとして操作してはじめて気づくものである。
- 従来のスクラッチ開発で、データモデルを何度も作り直す余裕は、なかった。Wagbyのようなローコード開発ツールは、つくったアプリを気軽に捨てられるということがメリットになる。
ゆえに、上流設計が終わったので、ここからWagbyで開発するというような分断的な発想でのプロジェクトは、Wagbyの効果を活かせません。上流工程の、しかも最初の段階でデータモデルを仮説的に構築し、検証するというところからWagbyを使うというのが正しい発想です。
基本設計の前に、データ移行を行おう
仮説となるデータモデルを構築し、そこからWagbyでアプリケーションに変換したとします。このあと各処理の詳細な手順を整理することになるのですが、その前に、既存データの移行を行おう、ということもお伝えします。つまり「要件定義」から「アプリケーション = 動く仕様書」を導き、さらに実データも投入して検証するということです。
多くのプロジェクトで、データ移行は最終局面で行うとしています。ところが、実データを移行するタイミングで「重複しないと信じていた商品コードに、9999というコードが存在し、かつ重複していた」「顧客コードがnullだった」などのデータ品質問題が露見することは珍しくありません。お客様も想定外なので、関係者一同、窮してしまいます。恐ろしいほどの手戻りが発生します。
基本設計前にデータ移行することで、この手の問題を早期に見つけることは、手戻りの可能性を大きく減らすため、プロジェクトの成功率を格段に高めることができます。実データの品質を高める議論は、実際には要件定義に含めるべきテーマのはずです。
まとめ：DXを支える「基幹」をデザインしよう
業務で扱うデータを把握することが DX の基盤になります。むしろ、業務全体で流れるデータを誰も正確に把握していないような設計を行うこと自体が不思議なくらいです。データモデリングとはすなわち業務データの把握ですので、大変な仕事です。大変ですが意味のある、最も重要な仕事でもあります。最初から100点のデータモデルを設計するのではなく、仮説と検証を繰り返してデータモデルを鍛えるという発想が大切で、そのためには静的なデータモデルを動くアプリケーションに変換し、検証できるようにするツールとして Wagby を捉えてください。
上流設計はまだまだ属人的で、非エンジニアリングなところが多いです。見方によってはエンジニアにとって残されたフロンティアです。Excelで設計書を書いている場合ではありません。
