玄天黄地

学生時代、箸にも棒にも掛からなかったアホの子が、やっと普通のアホになれるか?

PostGIS に初めて挑戦

これは FOSS4G Advent Calendar 2020 の記事です(2020-12-08 記述ですが、2020-12-17 以降に加筆修正します)。

QGIS は2011年から使っている私ですが、QGIS 以外の FOSS4G 関連ソフトウェアは使ったことがありませんでした。仕事場の後輩筋の中には、PostGIS も含めてヘビーユーザはもちろん居りますが、上級マネジャーだからという理由で自分は手を動かさずに来てしまいました。(要するにサボリですね)
 
さて数ヶ月前、今の仕事場周りの DX 対応を議論していた際に、仕事場で使うデータが相互に連携できていない点をどうするか、という問題が話題になったことがありました。データ単体は、最低限度の機械可読性は満足できているのですが、相互に関係するデータを組み合わせようとすると、突然ハードルが上がります。理由は簡単で、個々の DB を整備した人たちが、自己完結なデータしか作ってこなかったのです。当時(昭和末~平成中期まで)は、個別のプロジェクトで整備される DB に、関連する DB との整合性はあまり考慮されない空気があったのでしょう(その頃は私は別組織で働いていましたので、正確なところは分かりませんが)。令和の世になって、遅ればせながら関連データベースが簡単にマッシュアップできなければならないという認識が広がった時点で、そういうデータ整備をしてこなかったよね、という気づいた訳です。
 
今の仕事場関連のデータは、根拠法令があります。アナログ時代から厳然と存在している法令ですから、規程ぶりはデジタルに適しているとは限りません。ただ、「基礎となる地物があって、それに紐付く付属的な構造物が沢山ある」という体系は、アナログかデジタルかは関係ないと考えます。私の仕事場は、基礎となる地物の構造を表現する DB を管理していますので、根拠法令の考え方を IT 的に表現できればよいことになります。別に珍しい話ではなく、会計法の考え方を IT 的に表現できれば良い財務ソフトができる、というのと何も変わらないでしょう。
付属的な構造物は、他組織が整備する DB に格納されています。これまでは必ずしも連携が良くなかったのですが、「お互いに、根拠法令の考え方に忠実に IT 化しましょう」という申し合わせが成立すれば、DB 群は相互に整合するはずです。現在、ウチの組織では、自らが整備している DB を特定の顧客にガチガチにチューニングした様式で整備していますが、相互に整合する DB 群を使うべき相手はそれよりもずっと広いので、DB の構築方法も変更しなければなりません。

長々と抽象的な話を書いて参りましたが、このような経緯で、 PostGIS にウチの DB を入れてみることにしたのです。
 
ーーー
 
PostGIS に DB を投入する試みは、11月下旬に一旦成功したと部下から報告がありました。まあ、短期間で最低限度のデモが可能となるよう、最初の仕様は絞ったので、できて当たり前です(←技術力がないのに、偉そうなことを言う奴)。こういう試みの必要性を、関係業界に広く周知するために、これまでもプレゼンは書いてきたのですが、実際のデータとシステムを用意してプレゼンできなければならないので、自分のマシンにも PostGIS を入れてみることにしたのでした。サンプルデータを import するところまでは自力でやりましたが、本番環境(それなりに大量のデータ)を restore するところだけは部下の手を借りました。

第一段階として、年内に QGIS から PostGIS に格納された業務DB を読み出して、関係する他のデータと組み合わせて見える化する、というところまではなんとかできるようになりました。
第二段階は、仕事関係の組織(親会社的な組織)の高級指揮官にデモを見せて、仕事場の DX に使えることを示すことと、実際にベータテストを引き受けてくれる部署からできるだけ大量のフィードバックをもらう仕事が続く予定です。
 
ーーーー

DX を実行する部門(同時に DX の恩恵を受けるはずの部門)は、平時の仕事が IT から遠い部分が多いので、高い技術レベルを求めてもすぐにはうまくはいかないと思っています。こちらはバックヤードに PostGIS を使ったデータサービスを立ち上げることになりますが、ユーザには QGIS の使い方、QGIS から DB を直結させてネット越しに利用する際の方法などを説明することはできても、それ以上を求めるのは無理だと思っています。そういう意味では、PostGIS が稼働するデータサービスの部分と、実際の利用場面で用いられるアプリの部分とは、完全に分離できるようにシステムを設計しなければうまくいかないでしょう。関連 DB 群はデータサービスの側に属しますが、その DB を更新する人々はサービス側という認識を持つ必要はなく、部分最適な考え方として、目の前の DB に日々正しいデータを入れることに専念してもらうことになるはずです(まるで、レジ係の人が正しくレジ打ちをするかのように)。

DX で業務改善といっても、現場の隅々がいきなり IT に強くなるわけではないので、部分最適全体最適と矛盾しないように、全体最適を適用する側の方で工夫する必要が出てきます。私のいる組織は強権的なことができないからこそ、こういう解になります。これが独裁的な組織ならば、有無を言わせず新しい(効率的な)システムに従わせれば済む話なのです。
 
ーーーー
 
少し大きなことを申しましたが、こういう「こっそり仕込んだ大きな話」に PostGIS のような Open Source Software が使用できるようになったことが、DX が成立する(少なくともトライできる)背景要因として大きいと思います。もしも、これを 2005 年に Oracle でやろうとしていたならば、「こんなに大金をつぎ込むんだから、現場も不退転の決意で新しいシステムに馴染め」とか、「現場が混乱しないで済むように、徹底的に業務プロセスの改善方法を示せ」とか、「業務が完全に遂行できることを、あらかじめ実データを使って実演しろ」といった注文が来ていたかも知れません。そこには Lean Startup や Agile Software/System Development の考え方が入る余地がありませんから、うまくいかなかったのではないかと思います。私は、遅れてくることにはこういう良いこともあるんだ、と逆説的に捉えることにしました。
 
ーーーー
 
公開直後に追記(不細工!)
 
現場側に QGIS を持ってきたのには訳があります。
実は、「数ヶ月前、今の仕事場周りの DX 対応を議論していた際に、仕事場で使うデータが相互に連携できていない点をどうするか、という問題が話題になった」仕事会合において、 現場のあるセクションで、QGIS を普段使いしているチームが見つかったのです。そのチームでは、自己流DX を QGIS を利用してトライしていて、データ側がきれいでないためにうまくいかないでいる、という状況でした。
なので、QGIS とある程度相性が良い PostGIS でデータ側を対処しようと思い立ったのでした。