ヘッダレコード・データレコード・トレーラレコードとは

企業間でやりとりするファイルで見かけることがあるフォーマットとして、レコードが「ヘッダレコード」「データレコード」「トレーラレコード」に分かれているフォーマットがあります。
ファイルの中間部分にあたる「データレコード」に取り扱うデータを格納し、ファイルの冒頭と終了にあたる「ヘッダーレコード」「トレーラレコード」で日付や件数といった付加情報を与える、というのが特徴です。

以下で、「ヘッダレコード」「データレコード」「トレーラレコード」の簡単な説明と使用例を記載します。

【それぞれのレコードの説明】

・ヘッダレコード

ファイルの1レコード目のレコード。
一般的には、そのファイルが何日のデータなのかが記載される。

・データレコード

ファイルの中間レコード。
実際にやりとりするデータの中身が記載される。

・トレーラレコード

ファイルの最終レコード。
一般的には、そのファイルのデータレコード件数が記載される。

【フォーマット例】

取扱商品ファイルを想定した例を記載します。
可変長のCSVファイルを想定します。
(固定長の場合も多いです。固定長の場合は、カンマ区切りではなくバイト数で区切ることになります。)

・ヘッダレコード

1項目目:ファイル区分(1がセットされる)
2項目目:ファイル作成日付(YYYYMMDD)

・データレコード

1項目目:ファイル区分(2がセットされる)
 ※5がセットされることも多いです
2項目目:商品コード(7桁の数値)
3項目目:商品名(全角文字)
4項目目:値段(数値)

・トレーラレコード

1項目目:ファイル区分(9がセットされる)
2項目目:データレコードの件数(数値)

【ファイルのレコード例】

【ファイル受信時の処理例】

ヘッダレコードやトレーラレコードは、受信側のチェック処理に利用できます。
以下、ファイルを1レコード目から順番に読む場合の処理例について記載します。

・ファイル区分が1の時

1レコード目がファイル区分1でなければ異常終了。
(送信側が中間ファイル等誤ったファイルを送信することを想定)
バッチ日付と比較し一致しなければ異常終了。
(送信側が誤って過去ファイルを送信することを想定)

・ファイル区分が2の時

業務上必要な処理を実行。

・ファイル区分が9の時

最終レコードのファイル区分が9でなければ異常終了。
(ファイルを全件受信できていないことを想定)
件数がファイル区分2のレコード数と一致しなければ異常終了。
(ファイルを全件受信できていないことを想定)


ここからは応用です。

拡張性を確保するために、データレコードの種類を増やすという手段が有効になることがあります。
種類が異なるデータレコードをファイルに含める場合、データレコードのフォーマットを変えてしまうと、フォーマットが複雑になることで書き込み・読み込み処理が複雑になったり、フォーマット変更時の影響が全種類のデータレコードに出てしまったりします。
しかし、種類毎にデータレコードを用意することで、1つ1つのフォーマットが複雑になることを防いだり、フォーマット変更の影響が当該種類内のデータレコードに限定させることができます。

フォーマットと処理の例としては以下の通りです。
商品の種類毎にデータレコードの種類を変えることで、データ体系の違いを吸収している所がポイントです。
(1つのデータレコードにしてしまうと、1つのデータレコードに「食品商品コード」と「玩具商品コード」が含まれることになり、どちらを書き込むか・読みこむかの判断が必要になってしまいます。また、食品若しくは玩具にだけ新たな項目を追加する時に、追加が必要無い方の種類の商品の考慮も必要になってしまいます。)

【フォーマット例】

・ヘッダレコード

1項目目:ファイル区分(1がセットされる)
2項目目:ファイル作成日付(YYYYMMDD)

・食品データレコード

1項目目:ファイル区分(2がセットされる)
2項目目:食品商品コード(7桁の数値)
3項目目:商品名(全角文字)
4項目目:値段(数値)

・玩具データレコード

1項目目:ファイル区分(2がセットされる)
2項目目:玩具商品コード(6桁の数値)
3項目目:商品名(全角文字)
4項目目:値段(数値)

・トレーラレコード

1項目目:ファイル区分(9がセットされる)
2項目目:データレコードの件数(数値)

【ファイルのレコード例】

【ファイル受信時の処理例】

・ファイル区分が1の時

1レコード目がファイル区分1でなければ異常終了。
(送信側が中間ファイル等誤ったファイルを送信することを想定)
バッチ日付と比較し一致しなければ異常終了。
(送信側が誤って過去ファイルを送信することを想定)

・ファイル区分が2の時

業務上必要な食品向けの処理を実行。

・ファイル区分が3の時

業務上必要な玩具向けの処理を実行。

・ファイル区分が9の時

最終レコードのファイル区分が9でなければ異常終了。
(ファイルを全件受信できていないことを想定)
件数がファイル区分2~3のレコード数と一致しなければ異常終了。
(ファイルを全件受信できていないことを想定)


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

モダンなシステムではあまり使われることが少ないファイルフォーマットかもしれませんが、レガシーなシステムでは使われることが多いフォーマットです。
レガシーなシステムとの連携では頻出なので、このファイルフォーマットの特徴を覚えておくと会話や理解がスムーズになるでしょう。

アジャイル開発の概要

プロセスモデルの一つとして、「アジャイル開発」というものがあります。
ウォーターフォールモデルと比較すると新しいモデルです。

アジャイル開発はその名の通り迅速に開発を行うもので、短い期間(数週間~1ヶ月程度)毎にユーザにとって重要な機能から順番にリリースを行います。
一つの期間はイテレーションと呼ばれ、計画・設計・実装・テストがこの期間の間に行われます。
このように開発を行うことで、ユーザは少ない期間・コストで重要な機能を使用することができるようになります。ユーザの要求の変更にもいち早く対応することができます。
また、システムを実際に使うと新たな要望が浮かぶものなのですが、システムを早い段階で手に取ることができるので新たな要望を早く出すことができます。仮に、せっかくリリースした機能がユーザに響くものでなかったとしても、その問題に少ない期間・コストで気付き、軌道修正することができます。
これらの利点により、重厚長大なウォーターフォールモデルを採用した場合に比べて、ビジネス上で優位に立つことができるようになります。
(特にスタートアップ企業にとってはこれらの利点が重要)

しかし、アジャイル開発はユーザの要望が頻繁に変わる小規模システムの開発には向くものの、要望が固定されているミッションクリティカルな大規模システムの開発には向かないとされています。
アジャイル開発ではシステムを小出しで開発するので、システム全体の整合性や最終製品の品質を上手く管理しないと、システムの品質が低下する問題やシステムのスケーラビリティが損なわれる問題が発生してしまいます。
そのため、教科書的には、要望が固定されているミッションクリティカルな大規模システムの開発はウォーターフォールモデルの方が向いているとされています。

ユーザーの要件を満たすプロダクトを迅速に開発するためには、それを実現するための手法や考え方が必要です。
アジャイル開発を実現するための手法、またアジャイル開発と親和性の高い考え方としては、以下のようなものがあります。

・アジャイルソフトウェア開発宣言

アジャイル開発の価値観を端的に言い表した宣言である。
原文はこちら。

・エクストリームプログラミング(XP)

迅速にプログラミングを行うための手法。
リファクタリング(保守性を高めるためのコード見直し)、ペアプログラミング(一人がコーディング、もう一人がリアルタイムにコーディングを見ることで、即座にレビュー・知識共有を行う)、テスト駆動開発(テストケース・テストコードを先に設定してからプログラミングを行う手法で、テスト自動化が伴う場合が多い)、等により実現する。

・プロトタイピング

ユーザからのフィードバックを早期に得るために試作品を作成して提供する。
試作品はコーディングして作成するとは限らず、紙芝居のような形でコンセプトを伝えるペーパープロトタイピングと呼ばれる手法もある。

・スクラム

チーム一体となってプロジェクトを遂行して行くことに重点を置くプロセスモデル。
デイリースクラム(始業時に今日の予定と問題点を共有する)、プロダクトバックログ(システムの要求一覧)、スプリントバックログ(イテレーション内で対応する要求一覧)、イテレーション、スプリントレビュー(イテレーション内で開発した機能のユーザとのレビュー)、ふりかえり(イテレーション終了時の改善点の共有)等により実現する。

・バーンダウンチャート

縦軸に「残作業量」、横軸に「時間」を割り当て、残作業量を折れ線グラフにより記述したチャート。
ガントチャート等と比べて、プロジェクトの進捗状況をいち早く把握することができる。
誰もが見える場所に張り出すと効果が高い。

・リーン生産方式

トヨタ生産方式を元に編み出された方式。
開発工程におけるムダを排除することを目的として、製品および開発工程の全体にわたって、トータルコストを系統的に減らそうとするのが狙い。「ムダをなくせ(顧客に価値を与えない作業を無くす)」「学習を強化せよ(反復型開発)」「決断を遅らせよ(状況の変化に合わせた決断)」「できる限り早く出荷せよ(機会損失防止)」「チームに権限を(チームの手で最良のプロセスを採用)」「摺り合わせて作り込め(ユーザとのトライ&エラーの繰り返し)」「全体を見よ(全体最適化)」という7つの原則によって成り立っている。

・チケット駆動開発

スプリントバックログを約2~3時間のタスクである「チケット」に分割し、チケットを管理することで、メンバーの作業把握と成果物の更新理由の把握を容易にする。
チケットによる管理を行う場合は、チケットの完了(Done)の定義を明確にし、完了基準を満たすまでは完了とみなさないようにすることも重要である。

・ストーリーポイント

案件の規模や複雑性を「ストーリーポイント」と呼ばれる直感的・相対的な基準で測ることにより、俯瞰的な視点で直感的に迅速に見積もりを行う。


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

日本ではアジャイル開発はあまり普及しておらず、アジャイル開発を採用しているプロジェクトには巡り合えないかもしれませんが、それでも顧客の要望に沿ったシステム開発を行う必要があることには変わりありません。
そのため、ウォーターフォールの開発だとしても、アジャイル開発の手法や考え方は部分的にでも取り入れることは有効ですし、実際に部分的に取り入れているプロジェクトも少なくありません。
開発者としても、アジャイル開発の手法について知っておくことに越したことは無いでしょう。

ハッシュ化(暗号化)におけるソルトとは

この記事では、ハッシュ化で使われる「ソルト」について、説明していきます。
どちらかと言うと初心者向けです。


【ハッシュ化とは】

ハッシュ化とは、与えられた文字列を特定の方式(アルゴリズム)に従って変換することです。
変換後の文字列から変換前の文字列に戻すことは困難であるため、変換前の文字列を知られたくない場合に用いられます。
具体的には、パスワードを使用した認証処理(ログイン処理)で使われることが多いです。

例えば、「SHA-512」と呼ばれる方式では、「password」という文字列は以下のように変換されます。

【認証処理におけるハッシュ化の使い方】

認証処理においては、パスワードを管理するファイルやデータベースに、ハッシュ化された形でパスワードが保持されます。
認証を行う際には、ユーザーから入力されたパスワードをハッシュ化し、ファイルやデータベースに保持されているハッシュ化された文字列と一致することを確認することで妥当性を確認します。

なお、システムの管理者もパスワードの平文を知ることができないので、ユーザーがパスワードを忘れてしまった場合はパスワードを再作成する運用を行います。

【レインボーテーブルによる攻撃】

不正ログインを試みる攻撃者は、何らかの方法でハッシュ化されたパスワードの一覧を入手した後、レインボーテーブルによる攻撃を試みることがあります。
レインボーテーブルとは、平文とハッシュ化後文字列の対応表のことを指し、この対応表を用いることでハッシュ化後文字列から平文を推測することができます。
例えば、以下のような対応表がレインボーテーブルです。全ての平文について対応表を作ることは困難ですが、良く使われる平文はこれで突破されてしまいます。

【ソルトによる対策】

ここでソルトの登場です。
ソルトとは、平文からハッシュ化を行う前に、平文に付加される文字列のことを指します。
ソルトは、平文の前に付加されても後に付加されても構いません。
ソルトを付加することにより、レインボーテーブルによる攻撃で平文のパスワードを推測されることを防ぎやすくなります。

以下は、「password」という平文の後ろに「LdCTFPMk」という平文を追加する例です。
ハッシュ化後文字列が全く違うものになり、レインボーテーブルで逆引きすることが困難になります。

なお、ソルトに用いる文字列は、複雑で長い文字列(例えばランダムで生成された文字列)、かつユーザー毎で使い分ける(ログイン時に入力されたユーザーから対応するソルトを取得する処理を別途作成する)ことが望ましいです。


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

ソルトは良く出てくる技術ですが、その意味はあまり知られていないように思うので、今回の記事が参考になれば幸いです。

リーダーシップ状況論の理論と実践

今回の記事では、リーダーシップの理論と、IT業界における実践について述べていきます。
情報処理技術者試験対策としては理論を知っていれば良いですが、実際に現場で活かす上で役に立つ情報(経験則)も書いていきます。


【理論】

組織とリーダシップの関係は下記図のようになるとされています。
組織が成熟するにつれて、有効なリーダーシップの取り方がa→b→c→dに移行するとされています。

aは組織の発足時の段階です。
構成員のスキルも自主性も不足しているため、仕事関係本位でリーダー自ら先頭に立ってチームを引っ張る必要があります。
スポーツに例えると「選手をきちんと管理することが勝つための条件だ。」という状態です。

bはaから成熟度が進み、構成員がスキルを身に付け始めた頃です。
構成員を引っ張るだけでなく、リーダーが1から10まで指示しなくてもチームがパフォーマンスを発揮できるようにするために、構成員の自主性を育て大切にすることも考える必要が出てきます。言い換えると、仕事関係本位のリーダーシップだけでなく人間関係本位のリーダーシップも強めていくことが有効になります。
スポーツに例えると、「うるさく言うのも半分くらいで勝てるようになってきた。」という状態です。

cは更に成熟度が進み、構成員が自主性を身に付けはじめ、自分の仕事を自ら見つけ、必要なスキルを自ら身に付けるようになり始める段階です。
この段階になると、仕事本位のリーダーシップを取る必要性が薄くなり、構成員の自主性を維持するための人間関係本位のリーダーシップを前面に押し出すことが有効になります。
スポーツに例えると、「勝つためには選手と十分に話し合って戦略を作ることだ。」という状態です。

dは成熟度が最も進んだ段階です。
各々の構成員が自らリーダーシップを取るようになるので、リーダーは人間関係本位のリーダーシップも弱め、構成員に任せて見守るというリーダーシップの取り方が有効になります。
スポーツに例えると、「勝つためには選手に戦術の立案と実行を任せることだ。」という状態です。


【実践】

IT業界の開発の現場では、具体的に以下のことが言えます。

最も成熟度が低いaの状態というのは、構成員のスキルも自主性も不足している状態のことです。もう少し具体的に言うと、成果を出すために何をすれば良いのかわからない状態や、そもそも成果を出すための意欲が低い状態のことを指します。
現場としては、全くの新規プロジェクトの現場や、前任者が離脱して残された構成員が右往左往している現場、組織再編や短納期化等でこれまで頼っていた社内プロセスを見直さざるを得なくなった現場等が、これに該当するでしょう。
この状態の組織では、十分な能力や経験を持つ者がリーダーとなり、リーダー主導で作業計画や品質強化を行う必要がありますし、リーダー自ら設計や開発に関わる必要もあります。炎上プロジェクトの火消し役、というのもここに含まれます。
リーダーのワンマンプレイのようになるので人間関係に軋轢が生じることもありますが、この段階では副作用としてある程度受け入れざるを得ません

成熟度が少し高くなり、bの状態になると、構成員にスキルが身に付き始めます。この状態になると、末端の細かい判断や作業は構成員自らできるようになります。
現場で言うと、混沌とした時期を乗り越え、プロセスが正常に回り始めた現場と言うことができると思います。
この状態になると、構成員がプロセスに沿って自ら仕事ができるようになります。リーダーは、構成員がプロセスに沿って仕事ができるようにサポートするのが主な仕事になります。
まだまだリーダー自ら動かなければならない場面も多いですが、このあたりからは構成員に任せる仕事の範囲を徐々に広げ、構成員と良い人間関係を築くことも考える必要が出てきます。あまり長い間リーダーが前面に出ていると、構成員の自主性が育つのを阻害し、次の成熟度へ進むのが難しくなります。

成熟度が更に高くなり、cの状態になると、構成員に自主性が育ち、自ら考えられるようになります。
この段階になると、重厚長大なプロセスに頼らずとも、各々の構成員が適切な判断をするようになります。不測の事態が発生した時にも対応が楽になりますし、そもそも不測の事態が発生しないように各々の構成員が手を打つようになります。
この状態になると、これまでリーダーが行っていたような判断を構成員自ら行うようになりますし、その上で足りないスキルがあれば構成員自ら努力して身に付けるようになります。
この段階になれば、リーダー自ら動く必要はなくなります。構成員が気持ちよく仕事ができるように(このリーダーの下で働きたいと思ってもらえるように)、人間関係のメンテナンスに注力するのが有効になります。

成熟度が最高に高まり、dの状態になると、構成員自らリーダーシップを取るようになります。
各々の構成員が適切な判断をするようになるだけでなく、リーダーのように組織作りといったことも考えるようになります。
この段階に到達すると、リーダーは人間関係のメンテナンスをする必要もなくなります。
リーダーの仕事は、構成員に任せて見守るというものになります。この状態であれば、リーダーが更に上の立場に昇進したとしても、現場に問題は発生しないでしょう。


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

今回は、リーダーシップ状況論について、情報処理技術者試験で問われることだけでなく、より実践的なことを経験則から補記しました。
実践的なことも知っていると、記憶が定着しやすくなりますし、知識も活かしやすくなると思います。

ソースコード修正の競合と統合

複数の案件が同時に動いており、1つのソースコードを複数の案件で修正する場合、ソースコード修正の競合(コンフリクト)の統合(マージ、差分取り込み)が必要になります。
統合には、全体のロジックの整合性や案件のリリース時期の違いを考慮する必要があり、機械的に判断できない場合もあるので、最終的には人の手で判断し統合する必要があります。


例えば、商品の販売価格を計算する以下のソースコードがあるとします。
(今回はjavaのソースコードであると仮定します)

・修正前ソース

このソースコードについて、下記3案件で修正するものとします。
案件1.消費税増税対応(3ヶ月後リリース)
案件2.店舗毎セール対応(3ヶ月後リリース)
案件3.タイムセール対応(6ヶ月後リリース)

3案件の修正後ソースはそれぞれ以下の通りとします。

・案件1

・案件2

・案件3

リリースすることを考えると、以下の2段階に分けてソースコードの修正を統合する必要があります。

・3ヶ月後を想定

 案件1と案件2を統合

・6ヶ月後を想定

 3ヶ月後のソースと案件3を統合


案件1と案件2の統合は容易です。
以下のように機械的に統合することができます。

・3ヶ月後のソース

対して、3ヶ月後のソースと案件3を統合は機械的に行うことができません。
修正ポイント2-5と修正ポイント3-4は同じ個所を修正しているので、両方の修正が反映されるようにソースを書き変えなければなりません。
そもそも、修正ポイント2-3でコンストラクタが追加になっているため、新たに追加したコンストラクタに対しても案件3の内容を反映しなければなりません。
よって、6ヶ月後のソースは以下のようになります。

・6ヶ月後のソース


なお、バージョン管理システムのGitのブランチやマージの機能を使えば、これらの統合の作業が楽になります。
機械的に統合できる箇所は自動で統合できますし、機械的に統合できないブランチについても以下のような方法を用いて比較的容易に統合することができます。
(具体的な操作方法は省略します。操作方法はWebで調べられるので、必要に応じて調べると良いでしょう。)

  • Gitが出力した差分を見てエディタで編集
  • 競合の原因となったコミットを取り消しコミットし直し
  • マスター管理しているブランチを元に新たにブランチを作り直し、作り直したブランチに対して同じ修正を行う

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

「ソースコード修正の競合と統合」と言うと、Gitのテクニックが求められるように思われるかもしれません。
しかし、Gitの操作が多少不得手でも、何をしなければならないのかが理解できていれば、多少手間取ったり非効率になったりすることはあっても、最終的には問題無く修正作業を行うことができます。
まずは、何をしなければならないのかを理解することに努めましょう。
(それを理解する上で、今回の記事が参考になれば幸いです)