【初学者】バッチ開発?何それ美味しいの?状態からかじってみる。
皆さんこんにちは、お久しぶりです。PaZooです。
最近めっきり寒くなりましたね。どうにもこうにもアウトプット力の低下を感じてきたので、今更ながら「バッチ開発のあいうえお」を勉強していこうと思います。
バッチとは何ぞ?
「ひとまとまりにデータを一括して処理を行うもの」のことを指します。
バッチ処理のメリットとしては、「早い、安い、効率イイ」の三拍子が兼ね備えた処理方式です。
バッチは、大量のデータを効率よく処理するのに向いており、低コストでの運用が可能であることから、分析や集計、AI持論にも効果的。
めっちゃいいじゃん、バッチ。
WebAPIとの違いはなに?
とはいえ、よく分からんままに作ってみると「よくわからんけど動いた!でも考慮漏れ半端ねえ!」なchaos状態になることが
目に見えました。ええ、そりゃあもう浮かびましたよ。
というところで、じゃあ「 **Web API** と **バッチ処理** の違いって何よ?」と疑問符が頭に浮かんだので、表にまとめてみました。
ひとえに該当すると断定はできませんが、おおよそざっくりと説明しています。
| 観点 | Web API | バッチ処理 |
| 処理方式 | リクエスト都度リアルタイムに処理 | まとめて一括処理(決まったタイミングで実行) |
| 実行タイミング | クライアントから呼ばれたとき | スケジュール(例:毎日0時)やトリガーで実行 |
| 応答速度 | 速い必要あり(通常ミリ秒〜秒) | 長時間でも許容される(数分〜数時間) |
| 用途 | アプリ間通信、オンデマンド処理 | 大量データ処理、日次・月次処理 |
| データ量 | 少量〜中量の即時処理 | 大量データ向け |
| エラー対応 | 即時返却・リトライ制御必要 | 再実行・リカバリ処理が前提 |
| スケーラビリティ | 高い(負荷分散で対応) | 処理時間とリソースの確保が課題 |
| 設計のポイント | レスポンス速度、ステートレス性 | 処理効率、耐障害性、再実行性 |
| 代表的な利用例 | REST API / GraphQL API 呼び出し | バッチジョブ(ETL処理、集計処理) |
| メリット | 即時性・柔軟性・インタラクティブ | 大量データを効率よく処理できる |
| デメリット | 高頻度アクセスで負荷が増大 | タイムラグが発生、即時性なし |
オンラインバッチ・オフラインバッチ
オンラインバッチとオフラインバッチについて、整理してみました。
設計・運用時に気をつけるポイントも多く、たかがバッチ、されどバッチです。
オンラインバッチ
ユーザー操作やAPIからトリガーされ、比較的短時間で終わるバッチのことを指します。
2. 同時実行数に注意
多数のユーザーが同時に実行すると負荷集中しやすい。
キューイング・スロットル・リソース制限が必須。
3. 冪等性(リトライ安全性)の確保
通信エラーなどで複数回実行される可能性がある
→ 同じ処理を何度実行しても結果が壊れないように設計する必要がある。
4. ロック競合に注意
データ更新を伴う場合、他のオンライン処理と衝突しやすい。
5. 例外処理は即時対応が必要
エラーが「ユーザー操作の失敗」になるため、回復策を即返す必要あり。
6. スケールアウト設計必須
同時アクセスの影響を受けるため、水平スケールしやすい構造にする。
オフラインバッチ
オフラインバッチとは、深夜・定期実行など、ユーザー操作と独立したバッチのことを指します。
1. 長時間処理が許容されるが、締切がある
日次・月次処理は“その日中に終わる保証”が必要。
長時間化すると翌日のシステムに影響する。
2. 大量データ処理による負荷増大
DB負荷やI/O増加により、他の業務システムに影響を与えないよう調整が必要。
夜間とはいえ、他のサービスと共有しているリソースに注意。
3. 再実行しやすい設計(リカバリ性)
バッチは途中失敗することを前提に、
→ 中断点から再開できる
→ 差分処理が可能
などの設計が必要。
4. データ整合性の確保
大量更新・削除を行うため、トランザクションや分割処理の検討が必要。
5. 依存バッチの連携管理
複数バッチの依存関係(A → B → C)を明確に。
どれかが遅れると全体スケジュールが崩れる。
7. 実行環境の安定性
OSアップデート、ネットワーク・ストレージのメンテナンス時間と衝突しないよう調整。
-
- -
バッチ開発に携わったことがあれど、ビジネス要件からシステムへ落とし込むほど関わっていたわけではないので非常に勉強になる。
純粋に「バッチだから」っていう理由で軽視されていうものではないですね、これは。
下手したら業と闇が深いバケモンを生み出す可能性がなきにしもあらずです。
そして、ログ設計や監視などは今回触れず、今後触れる予定です。
というか簡単にまとめられるもんじゃねえなコレ。と思っている。
また目に留まったら読んでいただけると幸いです。
【小枝】現場で役に立つ!社内マニュアルの作り方
皆さん、お久しぶりです。PaZooです。
以前の記事が一年前と時の流れの速さに恐ろしさを感じつつ、秋の寒さが身に染みている今日この頃。
さて、今回の記事についてのお題は「現場で役に立つ!ナレッジ系ドキュメントの作り方」です。
「この手順がない!ほな作るか~」「この手順あるけど更新されてない!」とか、よく耳にしますよね。
そんなあなたにお届けする小枝が今日のお題目となっております。
| ◆この記事の要約 |
| 社内マニュアルのメリット・デメリットが分かる |
| 分かりやすい社内マニュアルの作り方 |
| 活用を促進させる管理・運用方法が分かる |
1.社内マニュアルのメリット・デメリット
社内マニュアルとは、業務の目的や流れをまとめたもので、社員間でのノウハウを共有することを目的としたドキュメントです。
◆メリット
・知識の属人化を防ぐ
・業務品質を一定水準に保つ
・業務理解度が高くなる
知識の属人化を防ぐ
現場でよく発生し得る状況が「OJT担当がいなくなった」「今教えてほしいけど周りに質問できる人がいない…」といった場面をよく耳にします。
社内マニュアルで、業務範囲や内容が明確化すると、特定の誰かしか行えない「属人化」した業務を生まれにくくすることが出来ます。
マニュアルが整備されていない状況だと、変更が行われても周知がなかったり引継ぎが出来ないという事態が発生してしまい、
最悪の場合、取引先との関係性にも問題が生じる恐れもあります。
社内マニュアルがあることで取引先と円滑に進められ、属人化を防止させるメリットがあります。
業務品質を一定水準に保つ
ただ社内マニュアルがあればイイというものでもありません。
社内マニュアルとは、標準的な業務手順が記載されるため、誰でもマニュアルに沿って手順を踏めば業務品質を一定水準に維持することが出来ます。
人によって教え方が違ったり、説明の仕方が違うと抜け漏れが生じるため、品質の担保が難しくなってしまうのです。
社内マニュアルを作ることで業務品質のばらつきをなくし、一定水準の品質を保つことができるようになるメリットがあります。
業務理解度が高くなる
新人が入ってきたり、転入者など業務を新しく覚えようとする社員が社内マニュアルを見ることで、早く業務を習得することが出来ます。
マニュアルがないとどんなことが起こるでしょうか。
先輩たちのOJT頼みで、業務で忙しくなかなか質問や相談が出来ず、誰にも助けを求めることが出来ない状態となってしまい、
戦力として動くことができなくなってしまいます。
また、専門的な用語や社内用語ばかりが記載された社内マニュアルだと新人や転入者にとっては理解することに時間を割いてしまいます。
時間を割きながらも業務が理解できず、戦力化できない新人や転入者が早期離職してしまうのも時間の問題です。
ターゲット層を把握したうえで、専門的な用語や社内用語は使わずに社内マニュアルを作成しましょう。
2.分かりやすい社内マニュアルの作り方
「早速マニュアルを作っていくぞ!!」と意気込むのは良いことですが、
何故社内マニュアルを作るか、目的を明確化していますか?
取引先がどのような社内マニュアルを運用しているのか把握していますか?
どのくらいのドキュメント類が存在していて、必要なドキュメントは具体的にどんなものか把握していますか?
まずはこれらを洗い出すところから始めることをおすすめします。(ドキュメントづくりはきりがないので…)
◆道筋
- 目的を明確化する
- 作成するまでのスケジュールを組む
- 社内マニュアルを何で作るのかを決める
- 標準化(マニュアル化)する業務を決める
- マニュアルの構成を作成する
- 構成に沿って本文を作成する
まずは誰に向けて社内マニュアルを作るのかを明確化しておき、
作成するまで多くの手順を踏むことが多くあるためWBSを引くことをおすすめします。
私は、開発工程単位で分けてマニュアルを作成するようにスケジュールを組んでいました。
そして、取引先に対して「社内マニュアル作成するので、完了したら乖離がないかチェックをお願いします!」とお伺いを立てる必要も。
取引先へ頭出しを行い、調整を行うとよりスムーズに動くことが出来ます。
社内マニュアルの管理ツールについては、「GitLab」や「取引先のサーバー上で作成されたRedmine」、「ローカルで起動させるWebサイト」などを用いて作成しました。
私はよくHTML形式やマークダウン形式でまとめています!
取引先の中にはExcelやスプレッドシートなど、活用される現場もあるかと思います。
活用できる管理ツールを使って社内マニュアルの作成に取り組んでください。
特に気を使ったポイント
・社内マニュアルのなかでパンくずリストの作成
・マニュアルの中で検索機能を作成
・取引先で取り組む開発工程単位で社内マニュアルを作成
また、作成する際は『見栄えよりも分かりやすさを意識して、端的に、平易ば表現や用語を使って文章だけでなく表やイラストで表現する』という部分を意識しました。
3.活用を促進させる管理・運用方法
社内マニュアルを作成すると、よく起こるのが「誰からも活用されず、メンテナンスもされずそのまま置きっぱなし」という状況です。
この状況を発生させないようにするにはどうすればいいのか。
私の場合は、必然的にマニュアルが活用される仕組みを作り、社内マニュアルを管理しています。
◆ポイント
- 新人や転入者が入ってきた時に受入マニュアルとして読んでもらう(マニュアルを使う場面を増やす)
- 定期的にチーム内でマニュアルに対して評価をしてもらう(作りっぱなしにしない)
- マニュアルを見直し、質を高める(取引先と乖離がないかチェックしてもらい、業務へ活用してもらう)
- 改訂履歴を残す(誰がいつどんな理由で変更したのか管理することで今までの業務の流れが見える)
まとめ
社内マニュアルがあると、業務内容を理解する手助けとなります。
「マニュアルがないから不便だなあ」と思っているそこのあなた!あなたの周りにも同じ悩みを持つ人がたくさんいます。
まずは1ページ、いや半分でも紙やExcel、テキストなどにまとめ始めてはいかがでしょうか?
きっと明日の誰かの助けとなり、知識となるでしょう。
では、今回はここまで!ご拝読ありがとうございました。
業務プロセスを整備!BPM(ビジネスプロセスマネジメント)とは
どうもお久しぶりです。
最近(というかめっきり)、更新できておらずすみません。私は元気です。
さて、最近めっきり(とうとう自分で言った!)更新が出来ていない理由としては以前携わっていた業務から離れて、新しい業務に入ることになり、システムの理解や仕様を学んでおりました。
自身の理解を整理するために、今回は「BPM(ビジネスプロセスマネジメント)」についてまとめていきます。
BPM(ビジネスプロセスマネジメント)とは
BPMとは「ビジネスプロセスマネジメント(Business Process Management)」といい、その名前の通り、
企業戦略と業務プロセスとの整合を取りながら分析を行い、かつ最適化し、継続して改善サイクルを確立・運営する手法のことを指します。
ちなみに、ビジネスプロセスモデリング(Business process modeling:BPM)という言葉もありますが、こちらは図形を用いたワークフロー図を通して各業務プロセスをモデル化することを指します。
ビジネスプロセスマネジメントの一手段として、ビジネスプロセスモデリングがあると考えると違いが分かりやすいかと思います。
当記事でのBPMは「ビジネスプロセスマネジメント」について取り扱いますので、ご了承下さい。
欧米企業でBPMがハマる理由と日本に馴染まない理由
日本ではあまり馴染みのないBPMですが、欧米ではオーソドックスだといえます。
その背景として、欧米企業では「プロセスオーナー制度」というものがあり、業務プロセスの可視化、改善、運用評価の責任を取る人が明確に決められており、この活動を支援するための専門組織がIT部門に設けられています。
この仕組みはビジネス側の各事業部が事業戦略上の施策を検討するうえで、現状の共通理解や課題の所在を明確化するために利用されています。欧米では、恒常的な経営ツールの一つとして根付いています。
では、何故日本に馴染みがないのでしょうか。
その理由の一つとして、日本の企業にはプロセスがなじまないという見方が有力です。
保守的な企業風土が影響し、合理的であればやってみようという考え方が定着しておらず、合意形成を重んじる日本では浸透しなかったようです。
欧米のようにトップダウンの強い意志がなければBPMは成功しないので、日本に馴染みがないのも頷けますね。
まとめ
今回は、BPMとは何ぞや?というところを書いてみました。
次回はBPMNやツールの選定について記事として取り上げるので、気になった方はぜひご覧ください。
【DBflute】PostgreSQL11以降でProcedurePmbが生成できない問題【解決】
モイ!お久しぶりです。PaZooです。
皆さんお元気ですか。私はついさっきまでくたばってました。。。
何故くたばってたかって??それは表題の通りです。
それでは早速お話していきましょう。
事の発端
むかーしむかし、あるところにテスト用DBを構築したそうな。
で、突っ込んだDBはPostgreSQL12でした。
そして、作ったSP(function)はreturns table記法です。
以前6ヶ月前くらいに一度DBfluteを実行していて、成功していた実績がありました…
が!!!!!今流してみると。。
すっとこどっこいProcedurePmbが生成されないじゃない!!!何故?!!!
ひじょーーーーーーに焦りました。。
そりゃだって現場で「嘘つき」って言われるじゃん!!!
(いたもん…トトロいたもん…の気持ちでした。。)
枕を濡らして眠った夜。神様が現れて秒速解決。
現場から「どうなってんの!調べて!!」と言われ、早3日。
悔しい思いと、トトロいたもん…の気持ちを持ち合わせたぐしゃぐしゃな私。
真っ暗な部屋で一人。青い鳥で一言。
「助けてクレメンス…」
その声は某青いロボットに頼る某少年のように、製作者様へとたどり着いたらしく。。
なんとお声掛けいただきました…!!そして風のように秒速で解決。。
どうやら原因は、JDBCのバージョン(42.2.11以降)によるものらしい。
解決策は、JDBCのバージョンダウン(42.2.10)を行うこと。
具体的には、PostgreSQL11以降に現れた「ストアドプロシージャ」によってgetProcedures()はストアドプロシージャ専用のものとなったためfunctionでは取得できなかったことが背景のようです。
DBfluteはJDBCを同梱してくださっている親切設計なのですが、JDBCのバージョンを変更したい場合は、DBFluteクライアントの extlib ディレクトリ にJDBCのバージョン(42.2.10)を配置してあげると実行JDBCを変更してくれます。
セットアップについては公式サイトをご覧ください!
dbflute.seasar.org
「extlibフォルダなんてないよ!!」
…なければ作ればいいじゃない!!!extlibフォルダを新しく作って、JDBCを配置してあげてください!
実行Pathをどこかのファイルに定義する必要はなく、自動で切り替えてくれます。
また、切り分けとしてストアドファンクションの構成が問題なのか調べてみました。
新しいJDBCのバージョン(42.2.11以降)では、カーソルでやってみたり色々検証しましたが、returns table記法に限らずfunctionはすべて取得できませんでした…。
「じゃあとにかく古いJDBCを指定すればええやん?!」というわけでもなく。古すぎるJDBCだと「認証型うんちゃら~サポートしてないよ!」というエラーが出ます。
これらの検証結果があり、今回は42.2.10を指定しています。
DBfluteユーザーの皆様でPostgreSQL11以降を導入する(若しくは検討している)方、バージョンアップを検討している方へ…ぜひブログ記事を見てくれ…届いてくれ…!
ちなみに、公式サイトにて今回の事象についての回避策を記載していただけるとのことでした!
また、今後はどちらもサポートしていけるように検討していただけるみたいです。
製作者様、神!!!!!
まとめ
私と同じ事象が発生した方は、解決策として挙げている内容をぜひ検証してみてください!
それと、製作者様とコンタクトできたのはみんな大好き青い鳥(Twitter)でお声掛けいただきました。
MLやSlackへの参加も行っていましたが、コミュ力ブロンズな私。
「製作者様にお声掛けするタイミングってなかなか難しいぞ…」と思い、青い鳥でつぶやいたことが今回のターニングポイントだったのかもしれません。
DBfluteで困ったときはつぶやいてみると、もしかしたらあなたの前にも神様が現れるかもしれません…!
製作者様、本当にありがとうございました!!!
twitter.com
ちょっくらコンビニ(社内イベント登壇)に行ってきた話。
皆さんこんにちは。管理人のPaZooです。
今回お話するのは、『社内イベントに登壇してきた』という内容です。
実はこのイベント、今回AdventCalendarの記事に取り上げられているイベントでして当記事では参加者から見たイベントへの熱意が楽しめる記事となっています。
企画者から見たイベントへの想いが綴られた記事は以下のリンクからどうぞ!
それでは、早速書いていきます。
プロローグ
ある日のこと。
「あーーーどうにか人前で話して緊張しない強いメンタルがほしいーーー」
ここぞとばかりにサンタさんにお願いしていたのですが、こればっかりはどうにもこうにもいかないものだったらしく私の言葉は空しく空を切ることに。
ここ最近を振り返ってみると、人前に立って話すきっかけが多くそのたびに緊張しまくってヘタこいていました。
そんなある日のこと。神様はどうやら空から見ているらしく。
『PaZooさん、社内イベントに出てみない??』
まるで「今からコンビニ行かねえ?」のレベルで軽ーくある人からお誘いを受けました。
ここでいう”社内イベント”というのは、自社内にいるすべての技術者が集まって技術的な話をするイベントのことです。
うちの会社は、SESと呼ばれる業界にいるため社外で働いている人もいれば社内で働いている人もいます。
そのため、あまり他の技術者と交流することができず結果的に現場に出ている人は割と孤独を感じる日々を送りがち。私も例に漏れずそのひとりです。
うーーーーーーん、行く。一緒にハーゲン〇ッツ買いに行こ。
誘われたことをうれしく思い、にんまりしながら、まるでコンビニに行くかのようにあっさりと社内イベントへ参加することを決めました。
ここで、事件は起きる。
「参加しまっす!」と意気込んだのは良いものの、何を題材に話そうか。
結局話すネタは現場で行っている話を簡素化して、世間的に通ずる「小ネタ」みたいな仕事の進め方について取り上げることにしました。これでネタはまあいいだろう。
ここでふと考えたことが頭をよぎり、ぴたっと動きが止まりました。
「そういえば、今回の社内イベントってどのくらいの人の前で話すんだろう…」
そうなのです、完全に墓穴なのです。
うちの会社、かなりの規模で人が所属しておりひじょーーーーーーに人が多い。そんな中に私のようなお豆腐メンタルな人間が出る幕はなかったのです。
大人数の前で、魅せるプレゼンをしたことがない。というかそんなに人前で話すことに慣れていない私にとって、誘いを受けた後の祭りだったのです。
そして僕にできること
少人数グループだとある程度主導権を持って話すことができる。だけど、人に魅せるプレゼンなんてしたことない。
そんな私が行きついたのは、「ひたすらに前を向いて経験を積むこと」でした。
具体的にいうと、練習のためにビデオやボイスメモを取って自分のプレゼンを見返したり、プレゼン資料の展開スピードに合ったトークが出来ているかチェックしたり。
在宅勤務というのもあり、仕事が終わったらすぐに資料の見直しに入ったりビデオ録画でプレゼン練習をしたり本番までひたすらに練習を重ねました。
資料の作成については、直属の上司に相談してとにかく分かりやすい資料にすることを心掛けました。資料の作成も経験値がものを言います。
いい資料とは何なのか。毎日考えて消して修正して…の繰り返しでした。
そして僕ができたこと
本番当日。もちろん非常に緊張していました。
練習したとはいえ、やはり色んな人の前で発表するというのは経験にないものです。
頭が真っ白になりながらも、その日は何とかプレゼンを終え、帰宅。(めちゃくちゃ家にいるんですけどね。)
後日のアンケート回答を見ると「5W1Hの大切さ」や「分析やヒアリングしながら行動し、しっかり振り返りをすることの流れ」などプレゼンを通して伝えたかった内容がきちんと伝えることができたようで、嬉しいお言葉を頂くことが出来ました。
うん、やっぱりうれしい。自分の考えを誰かに伝えて、分かってもらえるのは非常にうれしい。
そんな喜びの気持ちをかみしめながら「今後も継続して、人前に出て話す機会をどんどん増やして続けていこう」、と決めたPaZooでした。
社内イベントはいいぞ
あくまでも私の価値観ですが、技術者としてプレゼン能力は必須だと感じています。そんな中で得た今回の機会は私にとって非常に大きなチャンスとなりました。
今回得た経験では、「分かりやすいプレゼン資料づくりのスキル」や「人に分かりやすく伝える技術」を身につけることができたように感じています。
もちろん今後も継続して続けていきます。(スキルは一朝一夕で身につくものではありませんからね!)
「人前で話すことに慣れていない!」や「現場でプレゼン資料作ることなんてないし…」という方。ぜひ社内イベントで発表しましょう。
技術者界隈では様々なイベントがありますが、まずは身内から話すと経験を積むことが出来てレベルアップにもつながりますよ。
こんないいイベントを作ってくれたまてぃーセンパイ、運営の方、本当に心から感謝いたします。ありがとうございました!
まてぃーセンパイの記事は以下のリンクからどうぞ!
ここまで読んでくださり、ありがとうございました!!
【ER図】リレーションシップについて勉強してみた。
皆さんこんばんは。管理人のPaZooです。
もう年の瀬ですね、早いものです。(毎年言ってる気がします)
さて、今回も時間差なAdvent Calendar ということで。
以前当ブログでご紹介した『ER図リレーションシップ』について、より勉強してみようということでまとめてみました。
最後まで読んでくださるとうれしいです^^
ER図のおさらい
ER図とは、皆さんもご存じのとおり 「E=エンティティ(実体)」「R=リレーションシップ(関連)」を用いたデータモデル図です。
エンティティがテーブルを、リレーションシップが関連性を示しています。
詳しくはこちらの記事でもご紹介しているので、興味がある方はぜひご覧ください!
今日のメイン!リレーションシップについて
「リレーションシップ」は関連という意味を持つよ、とお伝えしました。
より詳しく説明をしますと参照整合性制約のことを表します。
ER図では関係性のあるエンティティ同士で、条件に合った線を引いていくことで表現することができます。
書き方としては、以下の三種類を使い分けて設計していくことになります。
依存リレーションシップ

子テーブルの存在が親テーブルに依存している場合に、依存リレーションシップで表現されます。
ここで言いますと、製造元テーブルが親でソフトウェアテーブルが子です。
製造元テーブルにデータが存在して、初めてソフトウェアテーブルが成り立ちます。
その証拠に、子テーブルの主キーは親テーブルの主キーであることが分かります。
親なくして子の存在はありえないので、分かりやすいかと思います。
非依存リレーションシップ

子テーブルの存在が親テーブルに依存しない場合に、非依存リレーションシップで表現されます。
ここでいう親は顧客マスタテーブル、子は製造元テーブルにあたります。製造元テーブルでは、顧客マスタテーブルが保持しているデータを必要とせず存在することができます。
多対多リレーションシップ

最後は、少し特殊な多対多リレーションシップです。
例えば、製造者マスタと製造元マスタが多対多の関係になります。
しかし、ここで注意点。
ER図の論理モデルでは表現することができますが、物理モデルにこのまま反映することができないので中間テーブルを用意して1対多として表現をします。

中間テーブルを新たに作成することで、多対多リレーションシップを表現することが可能となります。
【GAS】特定列の文字を指定文字に一括変換したいときの小ネタ【スプレッドシート】
おはやうございます、管理人のPaZooです。
Advent Calendar4日目の記事にしては小ネタのような気もしますが、まあよかろう。。
さて、今回仕入れたネタは「GAS」です。
タイトルにもある通り、「GASで特定列の文字を指定文字に一括変換したい!」という時に使えます!
管理人は、現場でスプレッドシートからCSVへ変換したいときに文字列にエスケープ文字「\r\n」・「\n」・「\r」が含まれている場合に空白文字に削除したかったので今回の実装を行いました。
スプレッドシート

GASソースコード
function myFunction() {//元データ取得var SSCopyForm = SpreadsheetApp.openById("***SpreadsheetId***");var SSCopyFromSheetsName = SSCopyForm.getSheetByName("シート名をここに記載");
//元データの最終行var LastRow = SSCopyFromSheetsName.getLastRow(); //最終行を取得var LastColumn = SSCopyFromSheetsName.getLastColumn(); //最終列を取得
//元データの取得した最終列、最終行までに入力された値を取得するvar CopyValue = SSCopyFromSheetsName.getRange(1,1,LastRow,10).getValues();
//貼り付け先のスプレッドシートのIDを指定してシート名を指定するvar SSCopyTo = SpreadsheetApp.openById("***SpreadsheetId***");var SSCopyToSheetsName = SSCopyTo.getSheetByName("シート名をここに記載");
//シートクリアSSCopyToSheetsName.clear();
//コピーした値を貼り付けるSSCopyToSheetsName.getRange(1,1,LastRow,10).setValues(CopyValue);
//貼り付けた値から削除対象文字を検索SSCopyToSheetsName.getRange("I2:I"+SSCopyToSheetsName.getLastRow()) //I列を選択.createTextFinder('\r\n|\r|\n') //対象の改行コードを指定.replaceAllWith("");}
解説
①コピー元シートの情報を取得
//元データ取得var SSCopyForm = SpreadsheetApp.openById("***SpreadsheetId***");var SSCopyFromSheetsName = SSCopyForm.getSheetByName("シート名をここに記載");
//元データの最終行var LastRow = SSCopyFromSheetsName.getLastRow(); //最終行を取得var LastColumn = SSCopyFromSheetsName.getLastColumn(); //最終列を取得
//元データの取得した最終列、最終行までに入力された値を取得するvar CopyValue = SSCopyFromSheetsName.getRange(1,1,LastRow,10).getValues();
今回の実装では、「コピー元シートをコピー先シートに複製してから、改行コードを消してほしい」という要望が挙がっていたので上のコードではコピー元データを取得しています。
②コピー先シートの情報を取得し、コピー元シートの情報を貼り付ける
//貼り付け先のスプレッドシートのIDを指定してシート名を指定するvar SSCopyTo = SpreadsheetApp.openById("***SpreadsheetId***");var SSCopyToSheetsName = SSCopyTo.getSheetByName("シート名をここに記載");
//シートクリアSSCopyToSheetsName.clear();
//コピーした値を貼り付けるSSCopyToSheetsName.getRange(1,1,LastRow,10).setValues(CopyValue);
コピー先シートのシートクリアを行い、コピー元シート情報の値をコピー先シートに貼り付けます。
③貼り付けされたコピー先シートから削除対象文字を検索して空白文字に一括置換
//貼り付けた値から削除対象文字を検索SSCopyToSheetsName.getRange("I2:I"+SSCopyToSheetsName.getLastRow()) //I列を選択.createTextFinder('\r\n|\r|\n') //対象の改行コードを指定.replaceAllWith("");}
ここで、貼り付けされたコピー先シートから削除対象文字を検索するため
「createTextFinder() 」メソッドで削除対象文字の「'\r\n|\r|\n'」を指定。
はてな記法が使えなくてソースコードを引用で表現してます、すみません!
近いうち修正いれます!