CDツールを使わない場合のデプロイ手順のイメージ

現在の開発現場・運用現場では、CD(Continuous Delivery)ツールを使用したデプロイ(サーバーへの資材配置)が一般的になっています。
CDツールの設定を行うのは一部の技術者のみであることもあり、CDツールを使用しない場合の原始的な手順でのデプロイ手順は、経験の浅い技術者にはイメージしにくいものであると感じています。

そこで、この記事では、CDツールを使用しない場合のデプロイ手順のイメージを書いていきます。
デプロイ手順を知ることで、CDツールを使う理由やそのありがたさを理解しやすくなると思います。


開発した機能を本番サービスに反映させるためには、開発環境で開発を行った資材(プログラムの実行モジュールやスクリプト、設定ファイル等)を商用環境に配置する必要があります。
配置を行うためには、最低限下記の作業が必要になります。
(コマンドのイメージも併記します)

1.商用環境のサーバーへのログイン

2.ファイル共有サーバーからの資材取得

3.資材(圧縮ファイル)の解凍

4.解凍後の資材の配置

上記の作業を行うだけでも、コマンドの誤り・漏れによる作業ミスの可能性がありますし、入るサーバーを間違えてしまうことすらあります。
作業を引き継ぐことにも困難さを伴い、作業手順書のようなものが必要になります。

加えて、下記のような作業を伴うことも多く、実際の手順はより複雑になります。

  • デプロイ時のサービス停止や機能制限、それに伴う設定変更(サーバー毎に設定が異なることも多い)
  • デプロイ前のバックアップ取得
  • デプロイ後の定型的な確認作業

作業ミスを防いだり引継ぎを容易にしたりする上で、CDツールの利用が有効になります。
CDツールでは、コマンドや設定を登録し、複数のサーバーに対して画面からGUIベースで作業することができるようになります。

イメージとしては以下のようなものになります。
(以下は、CircleCIのチュートリアルの一部です)

Hello World – CircleCI


今回の記事は、社内の勉強会で私の方から補足説明したことを記事に残したものとなります。
「CI/CD」という言葉の説明や、CI/CDツールの具体的な使用方法に関する記事は多く見つかりますが、ツールが使われるようになった経緯(過去の作業手順)に触れた記事は少ないと感じましたので執筆しました。

何かの参考になれば幸いです。

C#:ファイルのデータを置換する簡易ツールの作成

文字列置換はサクラエディタを使用すると楽ですが、サクラエディタを使用した場合は大量データの処理ができないという問題があります。

そこで、C#をプログラムにより置換を行うというのが有効になります。
プログラムでのファイルのストリーム読み込みであれば、高速に処理することができ、大量データにも対応することができます。
また、C#のコンパイラはWindowsOSに標準で搭載されているので、環境設定が不要なのも便利な点です。

サンプルコードは以下です。
サンプルコードでは文字列の”hoge”を”fuga”に変換しているだけですが、バイナリファイルとして読み書きしている上に変換する文字は16進コードで指定しているため、ASCII文字以外の置換にも対応可能です。
また、ロジックを書き変えれば、より複雑な条件での置換も可能になります。

また、この記事に限りませんが、ソースコードをコピペする場合は、「[」を「[」、「]」を「]」、「<」を「<」、「&」を「&」に変換するようにお願いします。

【フォルダ構成】

【ソースコード】

・execute.bat

・replace.cs

【入力ファイル】

・input.txt

【出力ファイル】

・output.txt


今回も小ネタの紹介でした。
C#のプログラムはサクラエディタのマクロよりも複雑なことができる上、Windiows OSであれば環境構築不要ですぐに使用でき、文法もJavaプログラマーであればとっつきやすいものです。
ちょっとした作業自動化で用いると便利だと思います。

C#:自ユーザーのダウンロードフォルダーのパスの取得方法

C#(正確に書くと.Net)では、以下のように、WindowsOSで定められる特殊なフォルダのパスがEnumで定義されています。
https://learn.microsoft.com/ja-jp/dotnet/api/system.environment.specialfolder?view=net-8.0&viewFallbackFrom=windowsdesktop-8.0

自ユーザーのダウンロードフォルダの直接のパスはEnumに登録されていないようです。
しかし、ユーザーのプロファイルフォルダ(C:\Users\(自ユーザー名))のパスは登録されていますので、そのパスを起点にダウンロードフォルダのパスを定義することができます。

試しに、ダウンロードフォルダ上のファイルのパスを定義し、そのファイルを読み込んで出力するサンプルコードを書きました。
具体的な使用例は以下のコードを参照してください。
(ソースコードをコピペする場合は、「[」を「[」、「]」を「]」に変換するようにお願いします。)

【サンプルコード】

・Program.cs

【用意するファイル】

・C:\Users\(自ユーザー名)\Downloads\test.txt

【実行結果】


今回はちょっとした小ネタの紹介でした。
ダウンロードしたファイルに対して加工を行うツールを作る際に便利だと思います。

要件定義・設計・製造工程の作業管理の概論

試験工程の作業の管理については、以前に記事を公開していました
以前の記事は要望に応じて執筆したものでしたが、試験工程の管理手法しか書いていなかったので、今回は要件定義・設計・製造工程の作業の管理について執筆しました。

今回の記事もウォーターフォールを前提とします。
それぞれの工程の概要については、ウォーターフォールモデルとV字モデルを参照してください。

また、今回の記事では、見積もり手法やWBSといった計画段階の手法は対象外とし、実作業が行われるようになった後の管理手法についてのみ書きます。

(1)各工程のトレーサビリティの確認

開発工程は、クライアントと合意を取った要件を元に、徐々に設計や製造に落とし込んで行くという形で進められます。
品質を確保する上で欠かせない観点の一つは、要件から設計、製造への落とし込みの過程で、落とし込みがなされなかった要件や設計が存在しないか、という観点です。

落とし込みの過程で漏れがないかどうかを確認する上では、それぞれの要件や設計の項目について、それが後続の工程で設計・製造行為に対象になっているかをトレースして確認することが重要になります。
視覚的なイメージとしては、以下の図の通りです。

ウォーターフォールの案件を進めていくにあたっては、工程を推進する者が上記のような観点を持つ必要があります。
場合によっては、上記のような確認を、Excelやスプレッドシートのような形式でドキュメントに残した方が良いです。

(2)課題・指摘事項の管理

会議の場で、もしくは各関係者が作業を進める中で疑問や気付きを得たタイミングで、関係者間で検討・対応が必要な課題が発見されることがあります。
また、会議や机上でのレビューを行う中で、確認や対処が必要な指摘事項が見つかることもあります。
品質を担保する上では、これらの課題や指摘を挙げるだけでは不十分であり、それらが計画的に抜け漏れなく対応されるかどうかを見る必要があります。

以下では、課題や指摘を管理する上で、どのような形式でドキュメントを残す必要があるのか、その目的も合わせて書いていきます。

【ドキュメントの形式】

ドキュメントの形式は大きく分けて「議事録」と「管理表」に2つに分けられます。

・議事録

 後に「言った言わない」問題のような認識齟齬が発生することを防ぐために、会議中での意思決定の流れを記録に残すために作成するものである。
 社外のクライアントや社内の意思決定者(経営層)との会議後に作成するような正式なものであれば、WordやExcelで決まった書式で書く必要がある。
 開発者間の会議で個人的・チーム間で用いるようなものであれば、メモ帳やExcelでフリーフォーマットで書いて構わない。

・管理表

 前述の通り、工程を進めていく中で課題や指摘が挙がることがある。
 その課題や指摘を抜け漏れなく管理するため、Excelやスプレッドシートのような形式で表を作ることもあれば、BacklogやJiraのようなチケット管理ツールを用いることもある。
 チケット管理ツールのイメージとしては以下(リンクはBacklogの公式ページ)。
 https://backlog.com/ja/lp/

【議事録に必要な情報】

議事録には、会議を特定する情報と、会議での発言内容を記録する必要があります。
具体的には、以下のような情報が必要になります。

・会議のタイトル

 必要に応じて目的を併記。

・開催の日時と場所

・主催者と参加者の一覧

・会議の中で用いたドキュメント名

・会議中での発言内容

 最低でも決定事項を書く必要がある。
 決定事項に至るまでの議論をどこまで書くかはプロジェクト次第だが、通常は、生産性を考慮して、決定事項に至るまでの議論の流れを、発言者の名前と共に要約して書く。
 全文を文書形式で残す必要があるプロジェクトは少なく、全文を残す必要があるとしても、録音データの添付で代替する場合が多い。

【管理表に必要な情報】

管理表には、最低限、個々の課題や指摘の内容を書く必要があります。
また、レビューに対して作成されるものであれば、レビューの開催情報を記載する必要もあります。

これらの情報は、記録を取って対応されたかどうかを確認するために必要です。
議事録に記載した決定事項も、その決定事項が実際に実施されるかどうかを確認するために、管理表の形式に落とし込んだ方が無難です。

また、レビューに関しては、品質管理に必要な情報も記載する必要があります。

レビューの開催情報について記載する場合は、以下のように、レビューを特定する情報を記載したり、品質管理に必要な情報を記載したりする必要があります。

・会議のタイトル

・開催の日時と時間の長さ

 時間の長さは(3)にて後述する品質管理の役に立つ情報の一つである。

・参加者の一覧と参加人数

 参加人数は(3)にて後述する品質管理の役に立つ情報の一つである。

・レビュー対象の成果物名とページ数

 ページ数は(3)にて後述する品質管理の役に立つ情報の一つである。

・指摘事項件数

 これも(3)にて後述する品質管理の役に立つ情報の一つである。
 指摘の数をカウントすれば良いが、挙げられる指摘の中には指摘扱いするべきではないものも含まれるため、それは除外するべきである。

   

個々の課題や指摘の内容については、以下のような情報を記載します。

・通番やタイトル

 見つかった課題・指摘を一意に特定するための情報。
 報告書上や会議の場で「『課題のNo.3 顧客検索画面での入力補助機能の検討』の対応状況に関しましては…」といった書き方・言い方をするため、通番と簡潔なタイトルがあると便利。

・発見日と発見者

 会議の場を通して書かれたわけではない課題に関しては、発見日・発見者の情報を記載することで、後のヒアリングの助けになる。

・課題や指摘の内容

・課題や指摘の対応方針と対応状況

 課題や指摘がどのように対応されるのか、経過を追うために必要な情報となる。

・ステータス

 課題や指摘ごとに「未着手」「実施中」「対応確認中」「対応完了」のようなステータスを持つことで、課題や指摘の対応状況を管理しやすくなる。
 「未着手」「実施中」のままの課題や指摘が多ければ、品質が低いまま作業が先に進んでいる、手戻りのリスクを抱えた状態である、ということを示唆している可能性があるため、管理の上で注意するべき情報である。

・対象機能

 これも管理の上で注意するべき情報である。
 この項目に着目することで、どの機能で課題・指摘の対応残が多いのか、どの機能で指摘が多いのかを見ることができ、進捗確認や品質強化が必要な対象を絞り込むことができる。

・対応完了予定日と対応完了日

 対応状況を管理する上で役に立つ項目である。
 この項目に着目することで、いつ頃に課題や指摘が対応されるのかを知ることで予定を見通しやすくなる、予定通りに作業が進捗していない状況にいち早く気付くことができる、といった利点を得られる。

・指摘の発生原因

 レビューにおいては、なぜその指摘が上がってきたのか、背景を確認するべきである。
 例えば、「前工程の不良」が多いケースと、「担当者への周知・徹底の不足」が多いケースでは、取るべき対応が全く異なってくる。
 (前者は前工程の品質強化、後者は担当者へのレクチャーが必要になる)
 また、指摘事項の一覧には、対応を伴わない念押しの確認や、担当者の認識誤りに基づく対応不要の指摘が挙げられることがある。
 これらについては、品質管理の対象から除外するよう、「指摘ではない」のような発生原因とする必要がある。

(3)プロジェクト全体を巻き込んだ課題・指摘事項対応

軽微な課題や指摘への対応であれば、担当者が対象ドキュメントを修正しそれを確認することで対応が完了します。
しかし、以下の2つのケースについては、担当者だけでは対処することができず、プロジェクト全体を巻き込む必要があります。

・変更要求

 計画変更に伴う新たな予算を確保する必要がある場合

・品質強化

 次工程に向けた品質を確保するために担当者に追加作業を命じる必要がある場合

   

ここでは、プロジェクト全体を巻き込む必要がある対応について、要点を記載します。

【変更要求】

計画自体を変更する必要があり、その変更に伴う予算を確保する必要がある場合に、変更要求と呼ばれる作業が必要になります。
変更要求は、主に、要件定義完了後に、システムを実運用するために新たな要件の追加が必要であることに気付き、その必要性をクライアントの担当者も理解しているような場合に発生します。

変更要求を行うためには変更要求書を作成する必要があり、変更の内容とその背景、変更を行うことのコストと便益、変更を行わなかった場合の影響、等を記載する必要があります。
その変更要求書を元に、クライアント企業若しくは受注企業で決裁権を持つ経営層が審査し、変更を行うか否かを決定します。

【品質強化】

品質強化は、次工程に影響を及ぼす品質問題を発見した場合に発生する追加作業です。
品質問題は、「担当者からの問題提起」「会議でのやりとりに違和感を覚えた管理者による気付き」「管理表や成果物を見た管理者による気付き」等の定性的な要因により見つかることもあれば、レビューにて計測できる品質を示す数値(メトリクス)のような定量的な要因により見つかることもあります。

定量的に品質を見る場合には、以下のような数値に着目します。

・(レビューの長さ * レビューの参加人数) / レビュー対象の成果物のページ数

 一つ一つの成果物に対して十分な量の時間をかけてレビューしているか、を示している。
 この数値が少ない場合は、レビュー工数を十分にかけられておらず、指摘を挙げきれていない可能性がある。

・指摘事項件数 / レビュー対象の成果物のページ数

 一つ一つの成果物に対して実際にレビューで指摘を挙げられているか、を示している。
 この数値が少ない場合は、レビュー者の技術力不足、レビューの開催方法の問題等により、必要な指摘を挙げきれていない可能性がある。
 また、この数値が多い場合は、成果物の品質が低いことにより指摘が挙がり続けている可能性がある。

   

効率的に品質強化を行う上では、品質問題を引き起こしている箇所を特定することが肝要です。 品質問題を引き起こしている箇所を特定できれば、その箇所に対してのみ品質問題に対応するための人員を投入した上で、集中的に追加レビューや成果物の作り直しを命じることで、最小限の資源で品質問題に対処することができます。

品質問題を引き起こしている箇所を特定するためには、以下の観点で見ることが鍵となります。

・似た内容の機能に着目する

 成果物を作成する際、システム全体としての統一感を持たせるために、似た機能を参考に作成していることが多い。
 そのため、一つの機能に問題が発見された場合、似た機能にも同じような問題が生じている可能性が高い。

・成果物を作成した担当者や協力会社に着目する

 品質問題は、担当者のスキルや協力会社の参画体制によって引き起こされている場合がある。
 スキルや体制の問題が品質問題の根本原因であると考えられる場合は、担当者の再教育や人員交代、協力会社の参画体制の見直し等を行った上で、追加レビューや成果物の作り直しを命じることが有効となる。

・機能の複雑性に着目する

 他システムとの連携が多い、実現しようとしている機能が技術的に高度、実現しようとしている機能の業務ロジックが複雑、等の理由で、品質問題が発生しやすい機能が存在する。
 そのような難易度が高い機能に対しては、業務面や技術面のスペシャリストを必要に応じて投入する必要がある。


大規模なプロジェクトでは、上記のような形で作業の管理を行っています。
足元で上記のような作業管理を行うことで、品質・進捗・費用が計画通りになるようにプロジェクトを進めることや、計画通りにならない場合に適切に対処することが可能になります。

作業者の立場で案件に参画しているとしても、上記のような知識を元に行動することができれば管理者から重宝されるため、大規模プロジェクトに携わっているのであれば知っておいて損はありません。

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)


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

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

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