SQL、R、Shinyを活用した柔軟なダッシュボードの構築と日本での導入課題

Published on: | Last updated:

コロナが始まる少し前、誰かがpurrrとかglueを使ってSQLデータベースに柔軟なクエリを投げてみる方法をあれこれ模索していたらしい。いや、正直その頃の自分は何してたっけ……まあいいや。最近では七十箇所ほどのテーブルやカラム情報をconfigファイルにまとめておいて、purrrでテーブルごとにループ処理、その結果をなんとなくマージするような仕組みに落ち着いてきたそうだ。うーん、サーバーとかDBの接続先も同じファイルにまとめてあるらしい。 ggplot2やreactable、それから時々だけどggiraphも加えてダッシュボード化しているとのこと。でも実際にはデータ整形にはdata.tableが多用されているみたいで、「ま、いいか。」ってくらい手作業多め?今のところRStudioで手動実行が主流という印象を受けるし、定期実行への移行はまだ検討中なのかな、と勝手に想像してしまう。えっと、この前SCODASというスコットランドのデータ分析コミュニティ内ミーティングでもこのアプリのお披露目があったっぽい。しかし細部については日によって微妙に話が違ったりするかもしれなくて…そんなもんだよね。本当、この組み合わせ自体は業務現場でもまあまあ見かける気がするけど、自分だけ?

参考元: https://www.johnmackintosh.net/blog/2022-06-14-dbexplorer/
purrrでテーブルごとにループさせて、最後に結果をマージする流れ——これ、Rユーザーならまあまあ目にする気がする。うーん、なんか普通っぽいけど意外と便利だよね。この間、configファイル開いたら、サーバーの接続情報とかカラム構成とか全部きれいにまとまってて、「そうそう、こういうのあると新しいテーブル足しても余計な手間減るな」って思った……いや、実際はたまに設定漏れたりして困るんだけど。えっと、それはさておき、本筋戻すけどglue使えばSQLクエリを柔軟に組み立てられるから、その都度ちょっとずつ条件変えてる人もいるようだ。短い文になっちゃったな。作業内容ごとにクエリ微調整できる感じ?たぶん多いよ。でも—ああ、自分でも思うけど—結局管理とか実行の面倒くささは残りがち。それで、自動化どうしようかなって議論もずっと終わらない雰囲気だった。ま、いいか。

Related to this topic:

Comments

  1. Guest 2025-12-29 Reply
    あー、この前ね、シンガポールのプロジェクトでShinyのダッシュボード使ってみたんだけど、まじで日本より全然導入早くてちょっとびっくりしたんだよね。でもさ、日本だと例の承認フロー?あれがやっぱ長いし、あと説明用の資料作らないと進まないとか、正直めっちゃ手間取る感じ。あと地味にSQL連携も引っかかるというか…なんかうまく噛み合わない場面多くて困ったなーと思った。
  2. Guest 2025-12-13 Reply
    最近さ、SQLとR、それからShinyでダッシュボード作ってたんだけど…なんか日本の現場って、どうしてもシステム間連携とかセキュリティの壁がやたら分厚い気がする。あ、接続設定も地味に面倒だし、細かいけど毎回「あれ?また…?」みたいな。で、一番時間取られるのがIT部門とのやり取りだったりして。「これここからアクセスできるようにしたいんですけど」「いや、その申請出してください」みたいな流れで何回もメール往復する感じ。これ、自分だけなのかな? あとさ、「もうちょっとグラフ大きくできない?」とか「このボタン位置変えてよ」とか、ユーザー側のリクエストが突然飛んでくること多すぎて…正直「今それ言う!?」みたいなタイミングもある。自分はとりあえず「検討します」って一旦預かるんだけど、結局そのまま難航したりすること結構多い…。 みんなこういう時どうしてる?融通効かせたいけど現実的に厳しいとこも多いし…。失敗談とか「こうしたらちょっと楽になったよ」とかあれば本当に知りたい。それとも単純に自分が不器用なだけなんかなぁ?