n対nマッチングのロジック(C#のサンプルコード付き)

以前に、以下の記事にて、マッチング処理のロジックについて書かせていただきました。
マッチング処理のロジック – サイゼントの技術ブログ

以前の記事では1対1マッチングと1対nマッチングについて説明しました。
今回の記事では、より複雑なn対nマッチングについて補足します。

1対1マッチングは、マスタデータの1つのキー項目に対して、トランザクションデータの0~1つのレコードが対応するものでした。
1対nマッチングは、マスタデータの1つのキー項目に対して、トランザクションデータの0~複数のレコードが対応するものでした。
n対nマッチングは、マスタデータ側も1つであるとは限らず、トランザクションデータの1つのキー項目に対して、マスタデータの0~複数のレコードが対応するケースもある、というものを指します。

n対nマッチングでは、以前に参照したトランザクションデータのレコードが、再び参照される可能性があります。
ファイルに対してランダムにアクセスすることでこれを実現できますが、処理が複雑になるため、今回はファイルは順次読み込みのままで、読み込んだトランザクションデータのレコードを一時的に退避するロジックを提示します。

フローチャートと例は以下の通りとなります。
また、この記事に限りませんが、ソースコードをコピペする場合は、「[」を「[」、「]」を「]」、「>」を「>」、「<」を「<」、「&」を「&」に変換するようにお願いします。

【フローチャート】

【例】

・要件

商品名が管理されている商品マスタと、商品の販売履歴(トランザクション)をファイル形式で読み込み、商品名と販売日を別ファイルで出力したい。

・商品マスタのフォーマット

カンマ区切りの固定長ファイル。
商品コードと商品副コードでレコードを一意に特定できるようにデータをセットする。

・販売履歴のフォーマット

カンマ区切りの固定長ファイル。
商品コード・販売日でレコードを一意に特定できるようにデータをセットする。

・出力ファイルのフォーマット

・プログラムのフォルダ構成

・ソースコード(execute.bat)

・ソースコード(matching.cs)

・商品マスタのレコード(files\master.csv)

・販売履歴のレコード(files\transaction.csv)

・バッチ実行結果(標準出力)

・バッチ実行結果(files\matched.csv)


あけましておめでとうございます!
お久しぶりです。

去年は慌ただしかったので記事を書けずにいましたが、要望があり、再びブログを更新することにしました。
ブログ以外の執筆活動もあるため不定期の更新になりそうですが、折を見て更新を続けていきたいと思います。

改めまして、よろしくお願いします。

ソースコードの重複の排除を関数で学ぶ

「ソースコードから重複を排除して保守性を高める」という考え方は、実務で良いコードを書く上で重要な考え方です。
この考え方が身に付かない内はオブジェクト指向の理解も不十分になるのですが、いきなりオブジェクト指向から入るとこの考え方の重要性がわかりにくくなることがあります。

そこで、ソースコードから重複を排除することの意義を、関数の使い方から学ぶことが有効になることがあります。

今回は、関数を使うことでソースコードから重複を排除し、保守性が高まる例を挙げていきたいと思います。
(サンプルコードはJavaで記述します)


今回のサンプルコードでは、複数の商品の販売価格を計算します。
まずは関数を使わないサンプルコードから書いていこうと思います。

【サンプルコード(関数未使用・修正前)】

・FunctionTestMain.java

【実行結果】


先ほどのソースコードに対して、「店舗独自の割引額を考慮する」という修正を入れていきます。

関数を使用しない場合、割引額(discountRate)を掛けるという修正を複数個所に入れることになります。
これが、ソースコードに重複が発生している状態です。

ソースコードに重複が発生していると、一部だけ修正を漏らすことによるバグに繋がりやすくなります。
このバグを潰すために、テストする範囲も広がってしまいます。

【サンプルコード(関数未使用・修正後)】

・FunctionTestMain.java

【実行結果】


次に、ソースコードを一旦修正前の状態に戻して、関数を入れていきます。

販売額を計算する関数(salesPriceCalc)を入れることで、ソースコードから重複を取り除くことができています。

【サンプルコード(関数使用・修正前)】

・FunctionTestMain.java

【実行結果】


関数を使用したソースコードに対して、先ほどと同じように割引額を考慮する修正を入れます。

重複が関数により排除されているので、割引額を入れる修正は1カ所で済んでいます。
修正箇所が減っているため、修正漏れを心配する必要がなくなり、ソースコードの保守が容易になっています。
言い換えると、時間をかけずにバグが出にくい修正を行うことができるようになります。
修正が繰り返される実務のソースコードでは、これは重要なことです。

【サンプルコード(関数使用・修正後)】

・FunctionTestMain.java

【実行結果】


今回解説したことは、実際の新人研修でも教えることが多いです。
このような簡単な例を用いることで、ソースコードの重複の排除について、わかりやすく説明することができます。


ところで、突然の発表なのですが、このブログでの私の記事はこれが最後となります。
このブログの記事を読んだことがある、と意外な所から声をかけていただくこともあり、大変嬉しく思っています。
少しでも皆様のお役に立てていたのであれば幸いです。

今まで記事を読んでいただき、ありがとうございました!

試験工程管理の概論

SI業界では、開発に関する知識や経験が不十分なメンバーを試験工程の管理者として任命することが少なくありません。
本来であれば、応用情報処理技術者試験(最低でも基本情報処理技術者試験)に相当する知識、及びその知識を実務で使った経験を備えた者を管理者として任命するべきだと思うのですが、そうすることができない事情もあると思います。

そこで、今回の記事では試験工程の管理に必要な知識の概要を書いていきます。
現場毎で試験の進め方が微妙に異なりますので、現場の進め方に適宜合わせていただければと思います。

なお、当記事では、ウォーターフォール(要件定義→設計→製造→試験→リリース、という順番に沿って、数ヶ月~数年の大規模な開発プロジェクトを予定通りに進める開発手法)を前提とします。
アジャイル(要件をこまめに取り入れながら、1週間~数週間毎に小規模なリリースを繰り返す開発手法)の場合は、各々の開発者が試験に関しても自主的にコントロールする形になるので少し違う話になります。
(しかし、アジャイルのプロジェクトに関わる場合も、ウォーターフォールのプロジェクトで培った試験管理に関する知見を活かすことはできます)

【試験工程の分類】

試験工程はいくつかの工程(段階)に分かれます。
具体的には以下のように分かれます。

・単体試験(単体テスト、ユニットテスト、UT)

単独のプログラムを対象とした試験。
この工程では、プログラムの開発者自らが試験を行うことが多い。
あるプログラムから別のプログラムを呼び出すことがあるが、どちらかのプログラムが未完成の場合は「スタブ」や「ドライバ」といった仮のプログラムが使用される。
「スタブ」は呼び出し先のプログラムに相当する仮のプログラムであり、「ドライバ」は呼び出し元のプログラムに相当する仮のプログラムである。
試験で使用される仮のプログラムについては、比較的新し目の技術を使う現場では「モック」(完成品のような見た目に見せかけた仮のプログラム)と呼ばれることも多い。

・結合試験(結合テスト、IT)

あるプログラムから別のプログラムへの呼び出しの箇所の担保を取ることに着目した試験。
単体試験の延長線上のような体制で行われることもあれば、専任のテストチームが試験を実施することもある。

・総合試験(総合テスト、システムテスト、ST)

プログラム等の改修を行ったシステムについて、システム全体の挙動を確認する試験。
人数の少ないプロジェクトである場合や技術的なサポートが必要な場合は開発者が試験実施に携わる場合もあるが、原則としては専任のテストチームが試験を実施する。
他システムとの連携についても、この段階で行う。

・受入試験(運用テスト、UAT)

改修後のシステムについて、実運用上の問題がないかを確認する試験。
システムの実際の利用者が試験を実施するが、利用者が一般ユーザー(エンドユーザー)である場合、受入側の会社の社員が代わりに試験を行う場合が多い。

それぞれの試験の工程がウォーターフォールのプロセスの中でどのような立ち位置にあるのかは別の記事(ウォーターフォールモデルとV字モデル)に投稿していますので、よろしければそちらもご参照ください。

【試験工程のスケジュール】

それぞれの試験の工程では、一般的に以下のような順番で作業が行われます。
(いくつかの作業は省略される場合があります)

試験の計画の策定

試験項目の作成

試験の準備の実施(テストデータやテスト環境やテスト用プログラムの作成)

試験の実施とバグ対応(バグが頻出する場合はこの時点で品質強化を行う場合がある)

上長への試験結果の報告(試験の一部再実施や品質強化を指示される場合がある)

それぞれの作業については、プロジェクト初期の見積もり段階で
「どのような役割の人を何人投入して、いつからいつまで作業を行うのか」
という計画が原則として立っています。
この計画については、それぞれの作業についての工数を積み上げて計画が立てられている場合もあれば、全体の工数を見積もった後に「単体試験は全体の20%、結合試験は全体の15%…」といった形で概略的に立てられている場合もあります。
見積もりと計画についての詳細は、別の記事(「見積もり概論」社内勉強会用のパワポの公開)に投稿しています。
また、
「どのプログラムについてどのようなテストが必要か。そのためにどのような準備を行うのか。」
といった細かいことについては、各々の試験工程の序盤で行うことが多いですが、これは開発に携わっているメンバーでないと実施困難であり、必要となる知識も広範かつ各々のプロジェクトに寄る所も大きいので、この記事では詳細は書けません。
試験の準備の実施、その他バグ対応や品質強化の実作用についても同様に、開発に携わっているメンバーでないと実施困難な作業になります。

試験項目の作成方法については、いくつかのテクニックがあります。
キーワードだけ書いておくと、「ホワイトボックステスト/ブラックボックステスト」「デシジョンテーブル」といったテクニックが使われます。
(詳しくは、情報処理技術者試験の情報を参考にするのが良いと思います)
なお、試験項目を挙げ終わったら、試験の項目数を集計し、総件数/着手件数/完了件数を把握できるようにするべきです。
これは、試験工程の進捗を確認する上で必要になる情報の一つになります。

予定通りの試験実施を妨げる最も典型的な問題の一つとして
「特定のプログラムでバグが頻発し、そのことが原因で関連するプログラムの試験項目を消化できない」
という問題があります。
この問題の対処のために
「バグが頻発するプログラムについて追加レビューや追加テストを集中的に実施し、バグを見つけきって、見つかった全てのバグを直して、元の作業に戻る」
という追加作業を実施する場合があります。
この作業は、「品質強化」と呼ばれることが多いです。
品質強化については、別の記事(類似バグを効率的に見つけ出すための観点)に詳しくテクニックを紹介しています。

【バグ管理表の運用】

それぞれの試験工程では、試験で見つかったバグを一覧にして管理するためのバグ管理表(不具合管理表、障害管理表)を用います。
バグ管理表はExcel若しくはスプレッドシートで作成されることが多く、フォーマットのイメージについてはWEBで調べることができます(例:「バグ管理表」でGoogleでイメージ検索)。
プロジェクトによっては、BacklogやJiraといったチケット管理ツールが用いられる場合もあります。

バグ管理表には、一般的に、以下のような項目が含まれます。
それぞれの項目について、管理者が着目するべきポイントも合わせて説明していきます。

・通番、タイトル

見つかったバグを一意に特定するための情報です。
報告書上や会議の場でも、「『No.3 ○○システムで作成したユーザーでログインできない』の対応状況に関しましては…」といった書き方/言い方をするので、通番と完結なタイトルがあると便利です。

・発生日

バグが発見された日を記入します。
詳しくは後述しますが、試験工程の進捗を確認する一つの方法として、バグが何件発見されたのかを日毎に確認する、というものがあります。
その際に必要となる情報になります。

・ステータス

それぞれのバグについて、対応が現在どの段階にあるのかを記入します。
順番に書くと、最低限「起票」「原因調査中」「バグ修正中」「修正確認中」「対応完了」といった段階に分ける必要があるでしょう。
試験工程が予定通りに進んでいない場合、ステータスからどこがボトルネックになっているのかを掴める場合があります。
例えば、「起票」「原因調査中」「バグ修正中」で止まっているバグが多ければ、バグが多すぎて開発者の手が回っていないことが予想されますし、「修正確認中」で止まっているバグが多ければ試験担当者の手が回っていないことが予想されます。
どこがボトルネックになっているかで対策も変化します。例えば、開発者の手が回っていない状況で試験担当者を増やすことだけしても意味がありません(開発者が抱えている作業の一部を試験担当者に回す、という手を併用するなら意味があります)。
なお、バグではない事象が書き込まれたり、一つのバグが複数個所に重複されて起票されたりする場合もあるので、それを示すためのステータス(「バグではない」「重複起票」等)も必要でしょう。
詳しくは後述しますが、試験工程毎で見つけるべきバグ数を計測する場合があります。
その際に、バグとしてカウントする必要がないものは計測対象外とする必要があります。

・バグ内容

バグの内容やバグを発生させる手順を記入します。
ここを参照するのは基本的にバグを修正する開発者ですが、品質強化策を考えるヒントを得るための情報の一つにもなり得ます(ここからヒントを得るためには、開発に関する知見が必要になる場合があります)。

・原因、修正方法、対象プログラム

バグの原因や修正方法、修正する必要があるプログラム名、といった、バグ修正に必要な情報を記入します。
単純なバグであれば試験担当者が記入できる場合もありますが、基本的にはバグを修正する開発者が記入する項目であり、開発者のための項目でもあります。
この項目も、品質強化策を考えるヒントを得るための情報の一つになり得ます。
特に、対象プログラムについては、開発に関する知見が無くとも機械的に数を集計できる項目であるため、品質強化が必要なプログラムを特定する上で有用な項目になります。

・バグ修正予定日、完了予定日

開発者によるバグの修正が完了する予定日、及び試験担当者による修正確認が完了する予定日を記入します。
この項目は進捗管理に使用することができ、上がってきたバグの対応が試験期間内に終わるかどうかを確認することができます。
試験期間終了日が近づいてくればくるほど重要な意味を持ってくる項目です。

・発見するべき工程

そのバグがどの工程で発見するべきだったのか、ということを記入する項目です。
例えば、現在が総合試験工程である場合、システム内の修正対象外のプログラムとの連関で発生したバグなら「総合試験工程で見つけるべきバグ」となりますが、プログラム内の単純なロジックのミス(製造ミス、修正ミス)で発生したバグであれば「単体試験工程で見つけるべきバグ」となります。
これは、品質強化策を考える上で重要な項目になります。
ウォーターフォールでは「前工程が完全に終わってから次工程に進む」というのが前提となっており、この前提が崩れている場合、現工程の作業が前工程の問題により進めることができなくなり、予定通りに作業を完了させることができなくなります。
もし、前工程で発見するべきバグが多ければ、この前提が崩れているということになりますし、この前提が崩れているプログラムについては品質強化が必要となります。
これは私見ですが、目安として、前工程で発見するべきバグが全体の20~30%程度であれば品質強化を検討、50%を超えたら品質強化が必須、と考えて良いと思います。
現場によっては、品質強化を行うべきラインが計測・策定されている場合もあるので、そのような数字が現場あればその数字に従うべきです。

【バグの発生数と進捗の関係】

バグの発生数を見ることでも試験の進捗を見ることができますが、これには少々コツが必要です。
一般的には、一定のペースでバグの発生数し続けるということはなく、試験実施の初期はバグが発生しにくく、中期にバグが多量発生し、後期にバグの発生が少なくなる、という経緯を辿ります。

試験手順が確立していないため、バグがなかなか見つからない

試験手順が確立したため、順調にバグが見つかる

品質が向上し残りの試験項目もレアケースのみとなるため、バグが見つかりにくくなる

という流れに一般的にはなるため、先に挙げたような経緯を辿ることになります。
(これをグラフにして表したものをゴンペルツ曲線(信頼度成長曲線)と呼びます。詳しくは別の記事(ゴンペルツ曲線(信頼度成長曲線)とは)を参照して下さい。)

もし、このような経緯を辿らない場合は、何かしらの問題があることを示しています。

例えば、初期からバグが大量発生している場合や、いつまでもバグが大量発生し続ける場合は、プログラムの品質が悪いことが伺えますので、品質強化を考える必要があります。
逆に、試験手順が確立したのにも関わらずバグが発見されない場合は、テストケースの作り込みが甘いケースが考えられます。

なお、試験工程で見つけるべきバグ数については、現場によっては計測・策定されている場合があります。
そのような数字があれば、それに従ってバグ発生数が多い/少ないを判断すれば良いですが、無い場合は、肌感覚で判断せざるを得ない場合もあります。これには、開発に関する知見や開発経験が必要になります。


試験工程の管理者として任命された他社の若手が、試験工程について私に質問してきたことがあり、その回答として上記の文章を書きました。
質問者にのみこの文章を見せるのはもったいないので、公開に至りました。

COBOLのマッチング処理をC#で実装する

COBOLで使われているテクニックは過去のもののように思われがちですが、現在でもちょっとしたツールを作る時に役立ちます。
WindowsOS環境の場合は、ちょっとしたツールはC#で作るのが便利なので、今回はC#でCOBOLのマッチング処理を実装してみました。

今回は、下記の記事を参考に実装しています。
マッチング処理のロジック – サイゼントの技術ブログ

HIGH-VALUEを使う代わりにEOFを示すフラグ変数を使用しているので、その分だけ処理が複雑になっていることには注意してください。
また、この記事に限りませんが、ソースコードをコピペする場合は、「[」を「[」、「]」を「]」、「>」を「>」、「<」を「<」に変換するようにお願いします。

【フォルダ構成】

【ソースコード】

・execute.bat

・matching.cs

【実行前のファイル】

・files\master.csv

・files\transaction.csv

【実行結果】

execute.batをダブルクリックして実行する。

・files\matched.csv

・標準出力


Windows OSで作業や運用を行う場合は、C#を使いこなせると何かと便利です。
C#でツールを使う時に便利なソースコードは、これからも公開していきたいと思います!

EmEditorで巨大ファイルを開く(サクラエディタとの性能比較有り)

テキストエディタとしてはサクラエディタが良く使われると思います。
しかし、サクラエディタで重いファイルを開こうとして時間がかかってしまった、ということもあると思います。

そこで役立つのが、EmEditorです。
EmEditorは、サクラエディタとほぼ同時期(2000年頃)に生まれたWindows用のテキストエディタです。
サクラエディタと比較すると、巨大ファイルを開く時の速さに定評があります。

EmEditorはこちらからダウンロードできます。
有料版もありますが、今回の用途であれば無料版の「EmEditor Free」で十分です。
https://jp.emeditor.com/#download


参考までに、実際にどれほどの差があるのかを計測しましたので、計測結果を公開します。
先に結論を書くと、今回の計測では、EmEditorの方が40倍以上ファイルを早く開けるという結果になりました。

【動作環境】

  • OS:Windows8.1 64bit
  • CPU:Inter(R) Core(TM) i5-4210U CPU @ 1.70GHz 2.40GHz
  • メモリ:8.00GB
  • ディスク:SSD 128GB
  • EmEditorのバージョン:Version 21.6.1
  • サクラエディタのバージョン:Ver. 2.2.0.1

【開閉対象のファイル】

・約170MB(179,148,566バイト)

【計測結果】

・EmEditor(Free版)

サクラエディタ


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

今回はちょっとした作業テクニックの紹介でした。
ファイル編集に関しては、サクラエディタ以外のテキストエディタはあまり使われないと思いますが、今回紹介した通り、他のテキストエディタを併用すると作業を効率化できる場合があります。

このようなちょっとした小ネタも今後取り上げていきたいと思います!