書籍「システム開発・刷新のための データモデル大全」に業務システム開発のコアがぎっしり詰まっている
当コラムで何度か登場していますが、データモデリング名人の渡辺幸三氏（モデリングツール X-TEA の作者でもあります）が新著を出版しました。その名も「データモデル大全」です。凄いタイトルです。
当ホームページではローコード開発ツール「TALON（タロン）」を紹介していますが、私たちがこのTALONという製品を作ったそもそのも大きなきっかけが渡辺氏の過去に書かれた書籍類にあります。（その辺りの経緯は過去のコラムに書いています。）最近ではIT勉強宴会というNPO法人の勉強会や、ローコード開発コミュニティなどでご一緒させて頂く機会がありますが、お会いしてお話しする度に色々な発見があります。本書は渡辺氏の過去に出版した物の集大成のような位置付けになるのでは？と勝手に思っています。タイトルの通り、データモデルに関する本当に基礎の部分（なんと帳簿に記帳する所からデータモデルが必要となる場面まで用意されています！）から、最終的にはかなり高度なデータモデリングの実例まであり、凄い読み応えで業務システムに関わる人必読の書です。大きな流れとしては、以下の様になっています。
- データモデルの必要性を理解する物語（１章）
- 主キーの重要性について（２章）
- データモデルを文脈では無く、記号として考えてみる（３章）
- データモデリングの進め方（４章）
- 企業活動をまるごとモデリングしてみる（５～１０章）
１では、システムの専門家でなくても、業務システムにデータモデルが如何に重要かが良くわかります。
２では、主キーにトピックを絞っていますが、主キーだけをテーマに１章割いてる所が非常に面白いです。主キーに向く項目、向かない項目があるという話や、複合主キーについてなどあまり読んだことの無い、けれど重要な内容が書かれています。
３では、現実業務の意味的世界から離れて、記号としてのデータモデリングを説明しています。この中に１４問ほどのミニ問題集があるのですがかなり面白いです。やってみると意外と難しいと思うのではないでしょうか？
４ではプロセス指向アプローチ（POA）、データ指向アプローチ（DOA）といった観点からデータモデルをどうやって導き出していくべきかが語られます。個人的には一番膝を打った章になります。創造指向によるデータモデリングという話が出てきますが、私自身もデータモデルを１５年以上行ってきて、詰まる所これに尽きる！と思っています。これについては少し個人的な話を後述します。今現在システム開発に携わっている方は、ひとまずこの章を見てみるのが良いかなと思います。
５については、企業システムの１部を担っている業務システムについて、業務システムとはなにか？仕訳・決算とはなにか？といったかなり根源的な説明（なんと、仕訳からB/S、P/Lを経て決算までをデータモデルの観点から説明しています）から、商品の扱い方、契約、発注・仕入、受注・出荷といったほとんどの企業で必要となる業務をモデリングしていきます。ここからどんどん深堀が進み、製造業向けの設備負荷調整や、在庫と受払について、商社の業務モデル、予算と実績と来て、最後には国家予算の歳入・歳出をモデリングしています。非常に多くの業務が登場しますが、データモデルに落とし込んでみると類似性に気づきます。この辺りは３章で語られている特性をデータモデルが持っているからだと思います。
私たちがTALONを説明する際に、「データモデルが最重要です、その結果生まれるUIは一瞬で出来るべきだと考えて作ったツールです」と言い続けて来ましたが、その考えはこの書籍にほとんどすべて網羅してあります。（TALONを作った動機についてはTALON動画チャンネルの1本目の動画「作った動機」でお話ししていますのでよろしければご覧ください。）
最後に、４章を読んでいて思い出した話がありますのでその話をして終わりにします。もう１０年以上前ですが、あるお客様の新規システム開発をした時の事です。予算管理業務のシステム設計をしていたのですが、現状行っている業務を教えてもらい、どの様なシステムにしていこうかと打ち合わせを重ねていたのですが、担当の方が物凄く複雑で膨大な時間が掛かる事をしていました。製造業の予算管理で、製品構成が非常に複雑なために、製品単位の予算を作るのに非常に苦労していました。単純に積み上げ計算ではだめで、勘所があり、個々の部品に対して色々と調整をしていました。そのため、１度全体の予算を作ったら、その予算の変更はとてもできないので１発勝負になるという事でした。何度も実際の作業を見せてもらっているうちに、１からデータモデルをして、各種のマスタ情報を用意し、共通性のある部分はマスタ情報で積み上げて、ボタン一つで全体の予算を作り、その後でマスタを微調整をして、再度ボタン一つで作り変えて何度もトライ出来る仕組みを提案しました。この方が精度も上がっていくし、何より調整作業に時間を割けるので精度が格段に上がると思って提案しました。
しかし、担当の方は今の方法で長年業務をしているので、新しいイメージを伝えることが非常に困難でした。当時はスクラッチ開発でシステム開発をしていましたので、画面をパッと作って見せる事も出来ませんでした。データモデルと業務フロー、画面イメージだけではどうしても伝わらず、困った私は、絶対悪いようにしないからこれで作らせて下さいと頼みました。担当の方は、今の業務に固執している訳ではなく、出来れば予算作成は何度も作り直したいという思いは持っており、ただ私が完成した姿を明確に伝えられず不安を抱えていたという状況でしたのでしぶしぶですが許可を頂きました。（空気は微妙になりましたが。。）結果無事にシステムをリリースできたのですが、その時の担当の方とのやり取りが強烈に印象に残っています。
担当の方が丁度予算作成中の時に席に行き、どんな感じですか？と聞いたら、物凄い笑顔でこんな事をおっしゃいました。「見てよ、これ！ボタン１つで全部やり直せるんだよ！何度でも試せるから色々試行錯誤出来るよ！ほら、こうやって！」。
開発の過程で色々とあった不安やしんどさが完全に吹き飛びました。やはり言われた要望の下でただ作るのではなく、目的が何かをキチンと考えて、提案する事が絶対に必要だと強く感じました。また、そこでデータモデリングの重要性を改めて感じると同時に、頭の中で浮かんだシステムがもっと早く形になればこのプロジェクトももっとスムーズに進んだのになぁと思いました（私の伝える力が足りなかったのですが）。それでデータモデリングが出来たら即動くシステムが欲しいと思い、TALONの開発を進めました。
それでは今回はこの辺で。
文＝古関雄介