Excelで文字の一括置換を行う方法(外部プログラムからの操作)

Excelファイル(.xlsx)は複数のxmlファイルを圧縮して構成されています。
解凍することでxmlファイルの形式として開けるようになり、通常のテキストエディタで編集することが可能になります。
これを利用することで、全てのシートに対して、オブジェクト内(例えば吹き出し内)の文字も含めた文字の一括置換が可能になります。
(Excelの機能では、オブジェクト内の文字を検索したり置換したりすることができません)

以下、手順例です。

1.Excel形式のファイルを用意する

2.拡張子を「.xlsx」から「.zip」へ変更する

3.2のファイルをLhaplus等で解凍する

4.サクラエディタのgrep置換等の機能で文字の一括置換をかける

※本文中の文字は xl\sharedStrings.xml に定義されます。
※図形中の文字は xl\drawings\drawing*.xml に定義されます。
※drawing*.xml に関しては、半角文字と全角文字が入れ替わる箇所で、xmlファイル上で別々の定義になるので注意が必要です。例えば、「hogeほげ」という文字については、xmlファイル上で「hoge」と「ほげ」という文字に分割されます。

5.Lhaplus等で再度圧縮する

※1のファイル名のフォルダの直下で作業を行う必要があることに注意

6.圧縮されたファイルについて、拡張子を「.zip」から「.xlsx」へ変更する

7.6のファイルを開いて置換されたことを確認

※「~の一部の内容に問題が見つかりました。可能な限り内容を回復しますか?」と聞かれるかもしれませんが、「はい」で良いです。


なお、7-Zipを用いれば、解凍や圧縮をコマンドラインから行うことが可能になります。 また、サクラエディタにはコマンドラインからマクロを読みこませる機能もあります。 これらの機能を組み合わせれば、バッチファイルから複数のExcelファイルに対して一括置換を行うことも可能になります。


いかがでしたでしょうか。

このように、xlsxファイルは複数のxmlファイルで構成されているため、解凍・再圧縮を行うことで外部プログラムからの操作が可能になり、作業を効率化できる可能性があります。
少々強引な方法にはなりますが、知っておくと使える場面があるかもしれません。

JavaScript:async・awaitの例外処理

JavaScriptのasync・awaitについては以前の記事で簡単に触れましたが、例外処理を行う場合には別途注意が必要であるため、続きの記事を書きます。

async・awaitで例外処理を行う場合、メソッドチェーンで受け取る方法と、try-catchで受け取る方法があります。
これらの方法について、紹介していこうと思います。

サンプルコードはNode.jsで実行しています。


awaitで呼び出される関数では、Promiseオブジェクトを返す必要があります。
通常はresolveで返しますが、例外処理を行う場合はrejectを返す必要があります。
これは、例外をメソッドチェーンで受け取る場合も、try-catchで受け取る場合も変わりません。

なお、rejectで返されたPromiseオブジェクトをメソッドチェーンでもtry-catchでも受け取らなかった場合は、UnhandledPromiseRejectionWarningが発生しプロセスが終了するので、注意が必要です。


rejectでPromiseオブジェクトを返された場合は、メソッドチェーン「.catch」で受け取ることが可能です。
「.catch」で受け取った場合は、「.catch」内の処理が実行され、戻り値は取得できません。
(戻り値はundefinedになります)
resolveで返された場合は、「.catch」内の処理が実行されません。

なお、メソッドチェーン「.catch」の前にメソッドチェーン「.then」を入れることで、resolveで返されたPromiseオブジェクトをこれで返すことができます。
「.then」で受け取った場合は、「.then」内の処理が実行され、戻り値は取得できません。
(戻り値はundefinedになります)
また、rejectで返された場合は、「.catch」の前に定義した「.then」内の処理が実行されません。

以下、サンプルコードです。

【サンプルコード】

・sample.js

【実行結果】

・①と③と④のコメントアウトを外した場合(resolveを.thenで受け取る)

・①と④のコメントアウトを外した場合(resolveを.thenで受け取らない)

②と③と④のコメントアウトを外した場合(rejectを.catchで受け取る)

参考:②と③のコメントアウトを外した場合(rejectを受け取らない)


rejectで返されたPromiseオブジェクトはtry-catchで受け取ることも可能です。
ただし、この場合、戻り値を参照しないように注意が必要で、参照してしまうとUnhandledPromiseRejectionWarningが発生しプロセスが終了してしまいます。

以下、サンプルコードです。

【サンプルコード】

・sample.js

【実行結果】

・そのまま実行した場合(rejectをtry-catchで受け取る)

・参考:⑤のコメントアウトを外した場合(try-catchで受け取る際に戻り値参照)


いかがでしたでしょうか。

JavaScriptのasync・await、特に例外処理は文法に少し癖があり、誤った記述をしても異常終了しないことがあるので、実際のシステム開発でも障害になりやすい所です。
awaitで待っていないように見える、例外発生時にだけ予期せぬ事象が出る、といった場合は、async・awaitの書き方が正しいか疑ってみましょう。

ドキュメント作成時の基本的な心構え

ドキュメント作成のコツについて一般的なことを書きます。
ドキュメントの良し悪しで意図が早く正確に伝わるかどうかが変わってくるので、スムーズに仕事をこなすには欠かせないスキルです。

ドキュメントには設計書からユーザ向けのマニュアル、運用手順等、色々種類がありますが、今回はどのようなドキュメントについても通じることを書きます。

【根→葉の流れで構造的に書く】

小説のように文章をつらつらと書くのではなく、適度に見出しを付けることが重要です。
また、その見出しは、根→葉の流れで構造的に書くことが重要で、見出しだけを見れば何がどこに書いてあるのかがわかるようにすることが理想です。
プログラム改修の設計書で言うと、以下のように書くのが良いでしょう。
 
 1.背景
  ……
 2.リリース日
  ……
 3.修正箇所
  3.1.プログラムA
   3.1.1.hoge対応
    ……
   3.1.2.fuga対応
    ……
  3.2.プログラムB
   ……
  3.3.プログラムC
   ……

【箇条書きや表や図で完結に書く】

・箇条書きの使用

並列である複数の事柄を書く時は、箇条書きを用いると文章が見やすくなります。
例えば、
「条件Aの時か、条件Bの時か、条件Cの場合に、hoge処理をする」
という文章は、以下のように書くとわかりやすくなります。

以下の何れかの条件に当てはまる時に、hoge処理をする。
 ・条件A
 ・条件B
 ・条件C

・表の使用

2×2かそれ以上の項目・条件が絡み合う事象を書く場合は、表を用いると状況をわかりやすく整理できます。

例えば、下記はリスクの対応策を表にまとめたものです。

これを表を使わずに表現すると、
「脅威に対しては回避と転嫁と軽減の戦略があり、回避とは…」
といういかにも冗長な文章になってしまいます。

・図の使用

複雑な事象を言葉で説明するのは難しいですが、図解するとわかりやすく説明できることが多いです。

例えば、理解が難しい概念である「モジュール強度」と「モジュール結合度」を図解した記事がこちらです。
「モジュール強度とモジュール結合度」の図解

日本語を読んでも何が言いたいのかわかりにくいと思いますが、図解することで意図を理解しやすくなると思います。

【誤解のない表現を使う】

・客観的な数値を示す

「性能が大幅に良くなった」「キャパシティに与える影響は軽微である」
といった主観的な表現だと、それぞれの受け手毎に異なる解釈をされる可能性があります。

ここは、異なる解釈をされないように、
「性能が10倍になった」「ディスク容量が100GBであるがデータ増加量は10MBである」
といった形で、客観的な数字で表すことが重要です。

・複数の意味で取られる日本語を避ける

例えば、「私は何度もコンソールがエラーを出力する所を見ました」という文章の場合、「何度も」の係り受けが曖昧であるため、以下の2つの意味で取られる可能性があります。
 ・私は「コンソールがエラーを出力する所」を何度も見た
 ・私は「何度もコンソールがエラーを出力する所」を見た

このようなことが設計書や手順書を書く中でも起こり得ます。

出来上がった文章を読み返して、複数の意味に取られないか考える癖を身に付けることが重要です。複数の意味に取られかねない時は、上手く書き換える必要があります。
特に、文章を短く区切る書き換えは、文章が分かりやすくなる可能性が高くお勧めです。
例えば、上記の例の場合、「コンソールは何度もエラーを出力しました。私はそれを見ました。」と書き変えると、意味が明確になります。

・要件、仕様等を明確にする

要件定義書なら誰がいつどのようにシステムを使うのか定義する必要がありますし、画面設計書なら画面項目のフォーマットや桁数等を定義する必要があります。

ドキュメントによって絶対に定義しなければならないポイントがあるので、そのポイントを落とさないようにすることが重要です。
もし定義が不十分だと、情報の受け手に自分の意図とは異なる解釈をされてしまう恐れがあります。

【情報の受け手に合わせて粒度を変える】

システムの利用者にとっては、システムをどのように操作すれば良いのかがわかれば良いので、詳しい仕様は冗長な情報になります。
逆に、システムの開発者にとっては詳しい仕様こそが重要になります。

このように、情報の受け手によって、どのような粒度で情報を求めているかが異なります。
受け手にとって粒度が細かすぎる場合は知りたい情報を誤解なく手早く知ることが困難になりますし、粗すぎる場合は知りたい情報を十分に知ることができなくなります。
ドキュメントを作成する際は、情報の受け手が誰であるかを想像して、適切な粒度で情報を提供することが重要になります。


いかがでしたでしょうか。

今回は、私がドキュメントを書く時に意識していることを列挙してみました。
ドキュメントはチームで仕事を進めていく上では欠かせないものですし、未来の自分が内容を思い出すためにドキュメントを読むこともあるので、今までドキュメントを重視してこなかった方は是非意識して書いてみてください。

なお、Slackのようなチャットツールでの会話でも、この記事で挙げたドキュメント作成のスキルを活かすことができます。
特に昨今はテレワークが普及しており、チャットツールでの会話も増えているかと思いますので、チャットでの意思疎通がスムーズにできるだけでも仕事ができる人だとみなされやすくなると思います。


境界値テストを行う場合には有効桁数に注意する

境界値テストについては、以前の記事にてデシジョンテーブルと共に紹介しました。
しかし、以前の記事では紹介しきれていないことがあるので、別に記事を書いて紹介しようと思います。


表題の通りなのですが、有効桁数については、コーディング時にも気を付ける必要がありますし、境界値テストを行う際にも気を付ける必要があります。
有効桁数を見誤ると、境界値付近の値が与えられた場合に意図せぬ挙動を示すことがあります。

例えば、株価に応じて処理を変える必要がある場面において、以下のような条件指定をしたとします。

そして、1つ目のif文と2つ目のif文の境界値を見るために、株価が99円・100円・101円・102円のテストケースを用意したとします。

これは一見正しそうに見えるのですが、有効桁数が見落とされており、バグを引き起こすコーディングであり、バグを発見できないテストケースです。
実は株価は1円単位とは限らず、0.1円単位のこともあります。
もし、ここで100.1円という株価が与えられた場合、1つ目のif文も2つ目のif文もすり抜けてしまい、意図せぬ分岐に進んでしまいます。
そして、テストケースでは100円より大きく101円より小さい値が設定されていないので、このバグを見つけ出すことができません。

正しくは、以下のようにコーディングするべきです。

そして、1つ目のif文と2つ目のif文の境界値を見るテストケースとしては、最小桁数での境界を見ることができるように、株価が99.9円・100.0円・100.1円のテストケースを用意するべきです。


いかがでしたでしょうか。

今回紹介した例は、私が本当に目にしたことがあるバグです。
金融案件のように数字を扱う案件では発生しがちなバグだと思うので、有効桁数に気を付ける必要があるということを心に留めておきましょう。