Slide 1
Slide 1 text
出張！Railsウォッチ
in 銀座Rails#20
森 雅智 / @morimorihoge
2020/04/17
1
特集：～Excelと仲良くするという選択～
Slide 2
Slide 2 text
About Me
● 森 雅智： @morimorihoge
● BPS株式会社でRailsの受託開発チームをやってたり、週1大学非常勤で
Web開発を教えてたりします
● Ruby/Rails歴は11年くらい。Web開発は17年くらい
● 銀座Ralis #10でActiveRecordでVIEWを使おうという話をしました
About BPS & TechRacho
● Web受託開発や電子書籍製品開発をやっている会社です
● TechRachoという自社技術Blogを運営しています
○ 3年半ほど前から平日毎日更新してます
○ https://techracho.bpsinc.jp/
● お仕事相談、転職相談、TechRachoへのご意見など気軽にどうぞ
○ https://www.bpsinc.jp/
2
Slide 3
Slide 3 text
Railsウォッチとは？
技術ブログTechRachoで毎週連載しているRails / Ruby界隈を中
心とした雑多な情報を提供する技術雑談マガジン
3
Slide 4
Slide 4 text
これまでの出張Railsウォッチのピックアップテーマ
● Rails6新機能特集
○ 銀座Rails#12: 複数DB対応
○ 銀座Rails#13: ActionText、Trix
○ 銀座Rails#14: ActionMailbox
● Railsアプリケーション開発に関する雑多なテーマ
○ 銀座Rails#15: production、development、staging環境について
○ 銀座Rails#16: 機能開発の設計レビューについて
○ 銀座Rails#17: リソース管理スコープについて
● 開発一般な話
○ 銀座Rails#19: 開発チームの冗長化について
4
※過去のスライドはTechRachoにて公開しています。「TechRacho 銀座Rails」あたりで
検索するとヒットしますので興味のある方はどうぞ
Slide 5
Slide 5 text
Excel（Google Sheet）
と仲良くするという選択
5
※業務システム開発初心者向けな内容です
Slide 6
Slide 6 text
えっ・・・Excel・・・
6
● そう、あのExcelです
○ 最近ではGoogle Sheetsも広く使われるようになっている
● Webエンジニア界隈では何かと悪いイメージが多い印象
○ Excel方眼紙
○ マクロによって組まれた謎のネ申Excel
○ スクショをExcelに貼り付けて共有
○ Windowsの資料がMacで崩れまくる（またはその逆）問題
○ そもそもMac版Excelが重くて辛い問題
○ ファイル名に日付をつけて `20200417_商品一覧_v3_森修正済み_v2.xlsx`とかになる現象
今日は「辛い」ExcelではなくてまともにExcelを使う話です
Slide 7
Slide 7 text
前提
● いわゆる社内システムやB2C向けWebサービスの管理画面系を想定
● 登場人物
○ Webシステム側はエンジニアがRailsで開発
○ 実際の管理・運用は運用担当者（非エンジニア）が担当
○ Webサービスの利用者については今回考慮外とする
● 扱うデータ
○ ECサイトの受発注データや商品データなど、いわゆる業務システムでごくごく一般的なマスタデータ
＋トランザクションデータ的なもの
○ データ量はメインのトランザクションデータ（例：注文データ）で月間100～数万件程度までのものを
想定
7
Slide 8
Slide 8 text
運用担当者・エンジニアそれぞれから見たExcel
● 運用担当者視点
○ データ編集：取引先からのデータもExcelなので、そこから まとめてコピペできるようにExcelだと嬉し
いなあ
○ データ閲覧：WebのシステムだとExcelみたいに リッチなフィルタがかけられないし、データの抽出が
やりにくくて不便なのでExcelでやりたい
○
● エンジニア視点
○ データ編集：異常データが入れられないようにせっかくvalidationをかけたりしているので、Excelとか
じゃなくてWebのフォームからやってほしいなあ
○ データ閲覧：普通のWeb
8
Slide 9
Slide 9 text
Excel（Sheets）メリット・デメリット
● メリット
○ 扱える人が圧倒的に多い
■ そこそこ年が上の人でもWord、Excelなら使える、という人が一定以上いる
○ きちんと使いこなせば必要十分に高機能
■ 本屋に行けば買えるようなExcel中級者向け情報あたりで一般的な業務で欲しがられそうな
機能はほぼ網羅できる
● デメリット
○ Office（Microsoft 365等）が必要なため使えない環境の人もいる
■ Google Sheetsも会社によっては利用できない可能性がある
○ マクロや数式が複雑化し始めると将来的に手に負えなくなりがち
■ 出来上がったネ申Excelは見た目や使い勝手は良いが、ソフトウェアとしてメンテナンスする
のが厳しいケースが多い
■ 「このExcelをWebシステムにして欲しいんだけど」案件 をやったことある人は分かる
9
Slide 10
Slide 10 text
ありがちだけどエンジニアとしては辛い要望
● Excelのこの機能を実装して！
○ 昇順・降順・フィルタ程度ならともかく、任意条件を組み合わせたり式を使ったりを考え始めると非常
につらい
■ ※UI面ではフロントエンド系のライブラリもあったりはするが、件数が大量になった時にまとも
に使えるのかという問題は残る
○ やればできなくはないけど、とても大変（工数がかかる）
● このExcelを取り込めるようにして！（神Excelを取り出しながら）
○ まともな表形式のデータであれば問題はないが、 セル結合や隠し列、隠しシート などがあると辛い
ことがある（ひどい場合はファイル参照していてリンク切れてたりなども）
○ システム化がそれほど進んでおらず、それまで担当者が手作業で行ってきたようなサービスの場
合、表記ゆれが存在することも
○ これらもやればできなくはないけど、とても大変（工数がかかる）
10
Slide 11
Slide 11 text
11
Q: これらの「技術的にやればできるけど、とても工数がか
かっちゃう」機能が実装されることはあるのか？
Slide 12
Slide 12 text
12
A: 実装されることはほとんどの場合においてない
Why？
-> エンジニアのリソースは大抵常時枯渇しているため、工数
が大きすぎるとひたすら後回しにされがち
ただ、運用改善の放置はオペミスの原因にもなりやすく、放
置しておくと思わぬ障害の原因になったりする
Slide 13
Slide 13 text
エンジニアサイドとして何ができるかを考える
● 運用担当者の要望をそのまま全部実装しようとすると破綻するが、現実的な工数
の範囲で運用担当者が幸せになれる方法を検討してみる
13
● WebアプリにExcelの機能を実装するのではなく、WebアプリとExcelをなるべくシーム
レスに繋ぐ方法を考える
○ CSV（TSV）ファイル
○ Excelファイル
○ クリップボードコピペ
人間 -> システム、システム -> 人間の両方向から検討していく
Slide 14
Slide 14 text
CSV（TSV）を使う
● CSV（TSV）は古から存在するデータ受け渡し方式で、今でもよく使われる方法の一
つ
● メリット
○ 構造が単純で、Ruby以外の言語でも扱いやすい
○ Rubyなら外部Gemが不要でライブラリが利用可能 ` require ‘csv’`
○ ファイルをparseする処理が軽い
● デメリット
○ 方言が多い（文字コード、クォーテーションで囲むか、改行文字の扱い、NULLの扱いなどなど）た
め、異なるシステム間でやり取りさせる場合に注意が必要
○ 1ファイル1表しか入らない ので、関連のあるデータを投入する場合には複数ファイルを渡す必要が
ある
○ アップロード前に「CSV出力」する手順を踏む必要があるため、多少サポートが必要になるかもしれ
ない
14
人間 -> システム（インポート）
Slide 15
Slide 15 text
Excelファイルを使う
● Excelを読み込めるGemを使う
○ roo-rb/roo や weshatheleopard/rubyXL など
● メリット
○ ユーザーが作ったExcelファイルをそのままアップロードして取り込みできる
○ 複数シートを扱うことができる ため、1ファイルに複数の表データ を入れて送信することができる
● デメリット
○ マクロなどを使われてしまうと正しく読み込めなくなることがある
○ サイズ規模、ライブラリ等にもよるが、CSVよりは確実に遅い
15
人間 -> システム（インポート）
この方式の場合、エンジニア側でExcelテンプレートを作って渡した方が事
故率が下がります
Slide 16
Slide 16 text
● Excelのセル範囲を選択してテキストエリアに貼り付けてもらう方式
○ テキスト貼り付けすると、タブ区切りテキストになる（Google Sheetsも同様）
● メリット
○ ファイルに保存する手順が不要なため、とても お手軽
○ 文字コードなどはブラウザが仲介してくれるため、サーバー側で考慮不要になる
■ ※改行が含まれているデータもダブルクォートでいい感じに囲まれます
● デメリット
○ あまりにも長大なデータを貼り付けるとブラウザが重くなったりすることがある
■ 数万行とかは結構厳しい
Excelコピペを使う
16
人間 -> システム（インポート）
大量のデータ洗替とかの用途でなければ割とオススメです
Slide 17
Slide 17 text
CSV（TSV）を使う
● しんぷる！
● メリット
○ format.csv などをうまく使うとRails wayで実装することもできて気持ちいい
○ シンプルな全件出力で良ければ実装工数をかなり小さくすることができる
● デメリット
○ 出力が大きすぎるデータになると同期処理では間に合わなくなるため、非同期ジョブで特定ディレク
トリに出力するなどの対応が必要になってくる（めんどくさい）
○ 担当者がExcelで取り込む際に「CSVからインポート」機能を使わないとUTF-8が化けるなどの一手
間がかかる
17
システム -> 人間（エクスポート）
Slide 18
Slide 18 text
Excelを使う
● Excel書き込みが可能なGemを使う
○ zdavatz/spreadsheet、randym/axlsx など
● メリット
○ 担当者がそのままExcelで開ける
○ 大変になるのであまりオススメはしないが、頑張れば印刷readyなレベルのExcelを作ることも可能
● デメリット
○ CSVに比べると処理が重くなりがち。特に大量のデータになるとメモリ周りは気にした方がよいかも
しれない
18
システム -> 人間（エクスポート）
Slide 19
Slide 19 text
Excelコピペを使う
● Excelに貼り付けできる文字列をサーバー側から提供する
○ readonlyなテキストエリアを用意してもいいし、JSで[COPY]リンクなどを用意しても良い
● メリット
○ 開いているExcelにそのまま貼り付ける ことができる（欲しいデータだけpickupして貼り付けていくと
いったユースケースでうまくマッチする）
● デメリット
○ 一部特殊な書式変換 が必要なため、Excel専用機能として実装する必要がある（口述）
19
システム -> 人間（エクスポート）
Slide 20
Slide 20 text
Excelコピペの注意
● 先頭が”0”で始まる文字列は書式によっては0が消えてしまうので「=””」で囲ってや
る必要がある
○ 例） 0001 -> 1（数値に認識される）
○ 例） =”0001” -> 0001（文字列と認識される）
● 桁数の多い数値も同上
○ 例） 123234345678789890 -> 1.232E+17（数値に認識される）
○ 例） =”123234345678789890” -> 123234345678789890（文字列と認識される）
● 改行を含むデータはダブルクォートで囲めば良い
20
システム -> 人間（エクスポート）
Slide 21
Slide 21 text
Excelと仲良くするまとめ
● 管理機能はとかくエンジニア工数が削られがちだが、エンジニア工数が削られる
分、運用担当者がExcel等を使って運用改善をできるルートを作ってやるとうまく回
ることがある
○ 運用担当の人にExcel使いがいるなら 特にうまく機能します
○ ※ある程度以上大規模なシステムになると俗人化して逆効果になることもあるので、システム規模
に合わせて検討しましょう
● ファイルアップロード/ダウンロードだけでなく、テキスト <-> Excelのコピー＆ペース
トは実装の手間も少な目なので、最小の手間でなんとかしたい場合には候補にし
ても良いかもです
21
Excelという言葉だけで拒否反応を示さずに、手持ちの手札でなるべく良い成果
を出すことを考えられると手数が広がります
レガシー技術も最新技術も何でも武器にできると強くなれます
Slide 22
Slide 22 text
次回以降もブラッシュアップしていきます
感想・リクエストなどあればTwitter
#ginzarails
@morimorihoge
@hachi8833
までお声かけください
22