ウォーターフォールモデルとV字モデル

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

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

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

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

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

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

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

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


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

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

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

それではまた次回!

「コピー新規(修正新規)」とは

【背景】

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

【言葉の説明】

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

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

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

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

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

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

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

【コピー新規の欠点】

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

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

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

欠点2:将来の改修が困難になる

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

【欠点への対策】

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

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

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

対策2:影響調査ツールを導入する

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

対策3:人海戦術に頼る

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

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

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

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

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

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


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

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

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

Excel:VLOOKUP関数と代替関数の使い方のまとめ

表題の通り、VLOOKUP関数とその代替関数の使い方をまとめました。

Excelであるキーに対応する値を取って来たい場合、多くの場合はVLOOKUP関数(第四引数FALSE)を使うと思います。
記述量も少なく関数の内容もわかりやすいので、VLOOKUP関数は広まっていますし、とりあえず検索したい時はVLOOKUP関数(第四引数FALSE)で事足ります。

しかし、高速化する必要がある場合や左側の項目を取得する場合、行と列の両方にキーが存在する場合は、他の方法で検索する必要があります。
一番汎用性が高いのはINDEX関数とMATCH関数の合わせ技です。
MATCH関数は第二引数で指定された範囲から第一引数が存在する位置を返すというもので、INDEX関数は第一引数の範囲から第二引数が示す位置を返すというものです。INDEX関数の第二引数にMATCH関数の結果を用いることでVLOOKUP関数と同じようなことができます。左側の項目を取得したい場合にも対応できます。
また、MATCH関数の第三引数(通常は0)を1にすることで、文字コードの昇順に並んでいる範囲を二分検索で高速で検索することもできます。
更に、INDEX関数は第二引数で行の位置、第三引数で列の位置を指定することもでき、この二つの引数を用いることで行と列の両方にキーが存在するケースにも対応できるようになります。
いざという時に使えるようにしておくと便利でしょう。


使い方をまとめた画像は以下になります。

以下、コピペ用にテキストでも記載します。
セル指定は適宜変更して下さい。

・キー項目が昇順・降順ではない場合の検索

VLOOKUP(B12,$B$3:$D$7,3,FALSE)
INDEX($D$3:$D$7,MATCH(B17,$B$3:$B$7,0))

・キー項目が昇順の場合の高速検索

IF(VLOOKUP(B21,$C$3:$C$7,1,TRUE)=B21,VLOOKUP(B21,$C$3:$D$7,2,TRUE),NA())
IF(LOOKUP(B25,$C$3:$C$7)=B25,LOOKUP(B25,$C$3:$C$7,$D$3:$D$7),NA())
INDEX($D$3:$D$7,MATCH(B28,$C$3:$C$7,1))

・キー項目が右側に存在する場合の検索

IF(LOOKUP(B35,$C$3:$C$7)=B35,LOOKUP(B35,$C$3:$C$7,$B$3:$B$7),NA())
INDEX($B$3:$B$7,MATCH(B38,$C$3:$C$7,1))

・列検索と行検索を同時に行う場合の検索

INDEX($B$2:$D$7,MATCH(C46,$B$2:$B$7,0),MATCH(B46,$B$2:$D$2,0))


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

キーに対応する値を取って来るだけでも、意外と奥深いことが分かったと思います。
VLOOKUP関数(第四引数FALSE)で大抵の場合は事足りるとは言え、遅い、左側の項目を取得できない、行と列を同時に検索できない、という不満はいずれ持つと思います。
そのような時に、INDEX関数とMATCH関数の合わせ技でサクっと対応できることがあるので、覚えておくと便利だと思います。

次回も、役に立つ情報を提供していきたいと思います!