サイゼントの技術ブログ

unix/linuxの便利コマンドの紹介です。

---

テストや補正作業を行う際、決められた時刻に決められたコマンドを実行したい場合があります。
unix/linuxでは、atコマンドを使用することで、決められた時刻に決められたコマンドを自動的に実行するように登録することができます。

しかし、atコマンドを通常の使い方をする場合、対話式にコマンドを入力したりコマンドを記載したファイルを別途用意したりする必要があり、オペレータに作業を依頼したりシェルスクリプトに組み込んだりする場合に都合が悪い場合があります。
そこで、下記のようにプロセス置換（コマンドをファイルに見立てる記法）を用いることで、対話式のコマンド入力やファイルの用意をする必要がなくなります。

・20:00に/home/hoge/test.txt（空ファイル）を作成するように登録する例

#> at 20:00 -f <(touch /home/hoge/test.txt)

---

OSのバージョンやatコマンドの設定によっては、atコマンドを使用できない場合もあります。
その場合は、下記のようにループ処理とバックグラウンドを併用することで、atコマンドと同じようなことを実現できます。

・20:00に/home/hoge/test.txt（空ファイル）を作成するように登録する例

#> (TIME=date "+%H%M"; while[${TIME} -lt 2000]; do sleep 60; TIME=date “+%H%M”; done; touch /home/hoge/test.txt) &

---

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

unix/linuxのコマンドを使いこなせるようになると、できる作業の幅が広がります。
今回紹介したコマンドも、使う機会が少なくないのではと思います。

これからも、便利コマンドを紹介していきたいと思います！

日本でシステム開発を行う場合、多くの場合は「ウォーターフォールモデル」と呼ばれるプロセスに従って開発を進めます。
ウォーターフォールモデルを知ることで、各々の工程を何のために行うのかを考えることができるようになります。
システム開発作業に参画する際は、ウォーターフォールモデルについて知っていることが望ましいです。

ウォーターフォールモデルでは、実際にプログラムを作るまでは「要件定義（基本計画）」→「外部設計（基本設計）」→「内部設計・プログラム設計（詳細設計）」→「プログラミング（製造）」といった工程を踏みます。
ユーザの要求からスタートし、段階的に詳細化しシステム化の方針を決めるといった形で、トップダウンで開発を行います。
プログラムを作り終えてからは、「単体テスト(UT)」→「結合テスト(IT)」→「システムテスト(総合テスト、ST)」→「運用テスト(UAT)」といった工程を踏みます。
バグ頻発でテスト進行が妨げられることを防ぐために、細かい箇所からテストを行い徐々に統合するという形で、ボトムアップで開発を行います。

開発工程とテスト工程は、以下のように連関しています。

プログラミングの内容は単体テスト、内部設計・プログラム設計の内容は結合テスト、外部設計の内容はシステムテスト、要件定義の内容は運用テストで検証します。
これをＶ字モデルと呼びます。

誤りを修正する場合、後の工程になるほど手戻り工数が増え、修正コストが増大します。
最悪なのは、リリース後に誤りが発見され、修正の必要が生じた場合です。
そのため、手戻りは原則として行わず、各々の工程を順番にこなしていくことが理想です。
（水が流れるように順番に工程をこなすことから、「ウォーター（水が）フォール（流れ落ちる）」と呼ばれるようになりました）

手戻りを防ぐためには、レビューを強化する等し、ある工程で埋め込んだ誤りはその工程の中でできる限り解消することが重要になります。
仮に後の工程で誤りが発見された場合は、その誤りについてなるべく早い段階で例外的に前工程に戻り、その誤りの修正に関わる要件・設計・実装を見直すことが重要になります。
大規模かつミッションクリティカルなシステム開発では特にこの原則を守ることが重要となります。
以下は東証のシステム更改の例で、前工程への手戻りを正式にプロセスに組み込むことで手戻り工数を削減する「フィードバック型Ｖ字モデル」が採用されました。
http://ac.nikkeibp.co.jp/cn/xdev10/pdf/10907-xdev-A-1.pdf

また、実現性が疑わしい箇所について開発開始前にプロトタイプを作成し、実現性をあらかじめ検証するという手法も使われます。
プロトタイプを作ることで、開発開始時に実現性の問題が出て手戻りが発生することを防ぐことができます。
（このような事前検証は「POC」と呼ばれることもあります）

ざっくりまとめると、先が見える場合は１つ１つの作業を確実にこなす、先が見えない場合は先回りして視界を良好にする、という姿勢がプロジェクトを円滑に進める上で重要になります。

---

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

私も１～２年目だった頃は、手戻りのリスクを考えずに猪突猛進に作業を進めて、結局手戻りして先輩に迷惑をかけたことがあります。
若手なら先輩に迷惑をかける程度で済みますが、リーダーや管理者の立場で同じことをすればプロジェクト全体の進捗に影響してしまいます。

ウォーターフォールモデルはシステム開発のプロセスとしては基本的なものですが、基本だからこそないがしろにしてはいけないと思っています。
単純に各工程の名前と作業内容を覚えるだけでなく、その背景にある理念も含めて理解する必要があると思っています。

それではまた次回！

【背景】

金融系SIerでは「コピー新規」という言葉を聞くことがあります。
（「修正新規」と呼ばれることもあります）
特定の現場だけではなく複数の現場で聞いたことがあるので、一種の業界用語だと思います。
しかし、コピー新規という言葉でWeb検索をかけてもヒットしないので、この記事を書くこととしました。

【言葉の説明】

「コピー新規」とは、「既存のソースファイル（プログラム）を丸ごとコピーし、コピーしたソースファイルに対して必要な個所だけ改修することで、新たなソースファイルを作成すること」を指します。

【コピー新規を行う理由】

コピー新規は、金融系の巨大なレガシーシステム（数百万～数億STEP）を改修する際に、高品質と工数圧縮を両立する現実的な最適解として行われます。
具体的には、以下の２つの理由で行われます。

理由１：システムの既存部分への影響を防ぐ

既存のソースファイルを修正して複数の要件に対応できるようにする場合、システムの既存部分への影響が懸念されます。
しかし、コピーして新たなソースファイルを作成すれば、システムの既存部分への影響を防ぐことができます。

理由２：既存部分を流用することでテスト工数を削減する

本番運用で動いている既存のソースファイルは、品質が保証されたものです。
そのソースファイルの中から使える部分は流用することで、その部分に対するテスト工数を削減することができます。

【コピー新規の欠点】

コピー新規を行うことで、以下の２つの欠点があります。

欠点１：改修した箇所が流用した箇所に影響を与えてバグになるリスクがある

コピーしたソースファイルについて、改修した箇所と流用した箇所は適切にスコープ分割やクラス分割されているわけではないので、改修した箇所が流用した箇所に影響を与える可能性があります。
流用した箇所はテストを省略している（理由２より）ので、影響を与えていてもそれに早い段階で気付くことが難しく、リリース直前やリリース後にバグとして顕在化する可能性が高まります。

欠点２：将来の改修が困難になる

ソースファイルの流用箇所については丸ごとコピーされるため、将来その流用箇所に修正が発生した場合、流用箇所を全て洗い出した上で同じ修正を複数のソースファイルに対して行う必要があります。
このことにより、将来の改修コストが増大します。

【欠点への対策】

コピー新規の欠点に対して、以下のような対策が行われることが多いです。
（これらの対策はコピー新規に限った話ではないですが）

対策１：コーディング規約をガチガチに固める

人によって癖があるソースコードの記述方法について、コーディング規約がガチガチに固められていることが多いです。
例えば、「それぞれのメソッドに番号を割り振り、メソッド内でのみ使われる変数名の先頭にその番号をつける」という規約を設ければ、当該の変数が当該のメソッド外に影響を与えることを防ぐことができます。
また、「『商品』は全て『Shohin』と記述する」というルールを設ければ、『Syohin』『Shouhinn』『Commodity』といった似たような単語を使われるのを防ぐことができ、影響分析が容易になります（単語検索漏れを防ぎやすくなります）。

対策２：影響調査ツールを導入する

巨大レガシーシステム向けに、影響調査ツールを提供するベンダーが複数存在します。
例えばNTTデータ社の「TERASOLUNA DS」の機能として「トレーサビリティー機能」が提供されていたり、NCS&A社が「REVERSE PLANET」というツールを提供していたりします。
これらのツールを用いることで、最新の資産状況が明らかになり、その最新の資産状況で単語検索や構成図確認を行うことができるようになります。

対策３：人海戦術に頼る

コーディング規約や影響調査ツールだけで改修コストの増大に対応するには限界があるので、最後には人海戦術に頼ることになります。
（金融機関に開発資金があるからこそできる対策です）
単純に協力会社やオフショアから開発者を集めるだけでなく、集めた開発者にシステム開発に参加してもらう仕組みを作ることが肝になります。
新たに参画する開発者は少なくとも個社システム独自のことは知らないですし、開発者のレベルにもバラつきがあります。新たに参画する開発者が品質の低いプログラムを開発して後に問題になることは少なくないですし、多数の開発者から一人の有識者に一気に質問が集中することで有識者の本来の業務に支障をきたすこともあります。オフショアの場合は、言語や文化の違いからコミュニケーションが困難になる場合もあります。
そのため、「開発手順の整備」「コミュニケーションの改善（例：窓口役を設ける、英語教育をする）」「独自フレームワークの構築（どのような開発者でも一定の品質の開発ができるようにする、プログラミングせずにシステム開発できる例も）」といった仕組み作りで対応する必要があります。

【リファクタリングしない理由】

現在のプログラミングの潮流は、「適切にクラス分割して、重複した記述はなるべく排除する」というものです。
記述が重複しそうな場合は、クラス分割をやり直して記述の重複を極力防ぐ（リファクタリングする）のが筋です。
「記述の重複を許容し、その代わりコーディング規約や影響調査ツールや人海戦術で悪影響を防ぐ」というのは、その潮流に逆行しているように見えます。

しかし、金融系のレガシーシステムは、その多くがCOBOLの時代に書かれたものです。
COBOLにはオブジェクトの考え方どころか、メソッドやスコープの概念すらありません。
（言語としての機能の問題だけでなく、COBOLが使われていた当時はオブジェクト指向の概念も広まっていなかったはずです）
当然、テストコードなんてものも存在しません。
仮にjavaでリプレースされていたとしても、そのjavaのソースコードはCOBOLのソースコードを自動変換したもので、中身はCOBOLっぽい構造になっているはずです（1クラスが数千～数万STEPある、変数が全てクラス変数になっている、等）。
その時代に書かれたソースコードが数百万～数億STEPも存在しているので、システム全体をリファクタリングするには非現実的なコストがかかります。

現在ではFintechベンチャーが活躍していますが、ベンチャー企業が手を出しているのは仮想通貨やロボアド等の、金融系から見れば傍流のシステムであり、銀行や証券等の基幹システムに手を出すという話はまだ出ていません。 基幹システムは新規参入の企業が容易に手が出せる規模のシステムではなく、これらのレガシーシステムのソースコードが今風のソースコードに淘汰されるというのも現在では考えにくいことです。 海外ではパッケージソフトで大型リプレースをかけるということも行われているようですが、日本の独自の商取引ルールが詰め込まれた基幹システムをパッケージソフトで代替するというのも困難で、レガシーシステムのソースコードは残り続けると思っています。
（比較的歴史の浅いシステムでは事例がないわけではないです。例えば、大阪証券取引所（現日本取引所）の証券デリバティブ取引システム「J-GATE」をNASDAQ OMX社製のパッケージソフトでリプレースした例はあります。）

そのため、既にリファクタリングが手遅れになってしまったソースコードを受け入れ、そのようなソースコードとの付き合い方を考えることが現実的な解だと思っています。
「コピー新規」は、そのための手段の一つと言えます。

---

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

プログラミングについて学んでいくと、「なぜコピー新規のようなことをするのか」と疑問が沸いてくると思います。
（私も疑問が沸きました）
今回は、単に言葉の説明だけでなく、そのような疑問にも答えられるように意識して記事を執筆しました。

今回の記事のような内容は、実際に業界に携わらないとなかなか実感が湧かないことで、それを文章に起こすことには意味があると思っています。
業界経験を基にした記事は、これからも書いていこうと思っています！