ユニケージ開発手法の試行結果の評価
今回実施した「ユニケージ開発手法」の試行では、前述した試行適用の3つの“ねらい”である3点について評価が行われた。
【第1のねらい】高速な稼働統計(ログ集計)処理の実現
この稼働統計機能は、2012年9月末に本番の運用を開始(本店のみ)したが、次のように、バッチ処理性能を劇的に改善できた。
- ①日次処理の場合:現行方式では約120分(7,200秒)、ユニケージ方式では約10秒と720倍の高速化を実現。
- ②月次処理の場合:現行方式では約240分(14,400秒)、ユニケージ方式では約40秒と360倍の高速化を実現。
今回の集計処理は、ユニケージ開発手法のオリジナルコマンドを組み合わせて実現したが、その中で注目すべきは、コマンドそれぞれの処理性能が非常に高速なことである。
【第2のねらい】保守性や開発生産性を高める柔軟な対応の実現
稼働統計処理については、その業務特性から顧客の要件の変化に伴って、将来的に機能追加や仕様変更が発生する可能性が高い。そのため、保守性や開発の生産性を高めるため次のような考慮が行われた。
- (1)EDP注11設計時点でのバッチ処理フローの図式化
ユニケージ開発手法では、“パイプ”を用いて中間ファイルを各コマンド間で引き渡すことになる。それを理解しやすくするため、設計書にコマンド処理内容と中間ファイルを図式化した。 - (2)ユニケージ開発手法のオリジナルコマンドによる開発量の削減
今回の稼働統計処理において、集計ロジック(集計方法)部分だけを見ると日次処理で29ステップ、月次集計処理で25ステップ(ともにコメント含む)で実現することができた。ただし、処理全体としてはファイルの存在チェックやログ出力処理、異常処理なども含める必要があるが、Java言語などによる実装と比較すると圧倒的に少ないステップ数で開発することができた。 - (3)ソースコード中のコメント記述の詳細化
シェルスクリプトに、設計書のパラメータ仕様について詳細にコメントを記述することで可読性を高め保守性の向上を図った。 - また、ユニケージ開発手法ならではの少ないステップ数と、シェルスクリプトの優位性を活かし、簡易な修正であればソースコード注12を読みながらトライ&エラーでの改修やソースコードの流用が容易に可能である。
以上のことから、開発時の工夫によって、保守性や開発生産性の向上が図れることが確認された。
【第3のねらい】バッチ処理の高速化技法の習得
今回の試行適用を通してユニケージ開発手法がバッチ処理の高速化手法として、高い処理性能をもつことが確認された。しかし、ここで誤解しないでほしいのは「Java:×(低速)、ユニケージ:○(高速)」ではないということである。技術標準であるJava言語の優位性も、多数存在するからである。
<Java言語の優位性>
- ①事実上の業界標準であり、技術者が多数存在している言語である。
- ②稼働サーバのプラットフォームに依存しない。
- ③オンライン処理とのロジック共有など、プロジェクト内でリソースの共通化が図れる。
- ④開発支援ツールも世の中に多数存在しており、実装が容易である。
- ⑤オブジェクト指向の優位性を活かし、さまざまなライブラリ群が存在する。
重要なことは、プロジェクトの規模や性能要件を考慮して適用技術を選択することである。(後編につづく)
▼ 注11
Electronic Data Processing、電子データ処理システム。
▼ 注12
ソースコード:プログラミング言語で書かれたソフトウェア(プログラム)の元データ。