Migaro.
TechnicalReport

セレクション 4
第9回 最優秀賞受賞

日本調理機が取り組む
システム改修方法の改善
IBM i資産の見える化と影響範囲の特定を容易にするアジャイル・ツールを自社開発『Migaro.Technical Report No.9』（2016 年秋）
で最優秀賞を受賞した日本調理機の吉岡延泰氏の論文「IBM iの見える化で実現するアジャイル開発」は、システム改修の効率化・スピード化を実現する自社開発ツールのポイントを解説したもの。山積する改修案件に悩むIBM iユーザーにとって示唆に富む論文だ。今回は「特別編」として、吉岡氏に、ツール開発の背景とそのポイントをうかがった。

システムが肥大化・複雑化しスムーズな改修が困難に
戦後まもない 1947 年に設立された
日本調理機は、 半世紀以上にわたっ供してきた総合メーカーである。現在に会計システムを PC サーバーへ移行

は、 機器類だけでなく厨房施設の設したほかは、ほぼすべてのシステムが計・ 施工なども手がけ、 特注の大型IBM i 上での運用である。

設備・施設の開発に強みをもつことで知られる。

は、現在利用されているものだけで約て、 学校の給食施設や企業の社員食基幹システムは、1993 年に AS/400

1 万 4000 件。 最近、 プログラムの棚堂、病院・老後施設の食堂、ホテル・を導入して以来、IBM ミッドレンジ卸を行い不要なオブジェクトを廃棄しレストランなどに業務用厨房機器を提機上で構築・ 運用してきた。2012 年

たが、それでもこれだけの数がある。

図表 1

アジャイル開発のステップと仕組み
Power 720（IBM i 7.1）
稼働中のライブラリ群（オブジェクト＆ソース）①

収集
ソース内検索、構成情報を収集②

オブジェクト情報出力・一覧

クローラー
プログラム

分析

オブジェクト構成ツリー
Delphi/400 で開発した見える化ツール（構成の展開・検索・抽出）

56

基幹システム上のオブジェクト数③

再構成

一括コンパイルプログラム

アジャイル開発のステップ

①

収集

②

分析

③

再構成

① 処理対象のライブラリからオブジェク
ト情報を収集し、各オブジェクトの親子関係を「クローラー」によりツリーファイル化② Delphi/400 で 開 発 し た「見 え る 化ツール」で、ツリーファイルを展開表示。検索・抽出により影響調査を行う↓
プログラムの修正（フィールドの追加・拡張など）③ IBM i にアップロードし、ファイルごと連続リコンパイルし、ライブラリに反映させる

2017 Spring

056-059_17imagSPRING_migaro_FIX.indd 56

2017/03/03 13:52

Migaro.Technical Report セレクション 4システムの開発・運用・保守は「自のプログラムのリコンパイルに時間が社開発・自社運用」を方針としてきた。

かかるので、同じキーフィールドをも経営・ 業務ニーズに即した開発・ 改

つ物理ファイルをもう 1 つ別に作成す修をスピーディに柔軟に行えるのと、るようなことも起きていた。
「結果的ユーザーの声を反映させた細かい作りにデータベースの正規化を正しく行え

吉岡 延泰氏込みができるのが、 その理由である。

ず、システムがより複雑になるという業務ロジックの開発には、 主として悪循環を招いていました 」 と、 情報

日本調理機株式会社
情報システム部主任

RPG Ⅲと RPG Ⅳを使用してきた。

システム部主任の吉岡延泰氏は振りしかしながら、長年の度重なる改修返る。

COMPANY PROFILE

によってシステムが肥大化し、さらに

本

社：東京都大田区

プログラムの構造化を進めてきた結設

立：1947（昭和22）年

果、システムが複雑になり、改修が年々困難になるという事態が生じていた。
これに加えて最近は、 経営層から戦IBM i 資産を見える化し資 本 金：5億9760万円

一括コンパイルまで

売 上 高：165億3766万円

カバーするツール

事業内容：厨房用機器、食品加工用機器などの製作・従業員数：509名
販売・輸出入、厨房施設の設計・施工・略的な改修の要請が増え、 事態がまそこで開発したのが、プログラム資すます逼迫する状況になっていた。

産を簡単に見える化し、 その改修範監理など
http://www.nitcho.co.jp/

従来の影響調査は、 対象となるプ囲の特定を容易にするシステムである。

ログラムを FNDSTRPDM コマンドを「その発想自体はかなり前からもって使って検索し、リスト化された一覧かいましたが、RPG と CL と 5250 画面

システムは、オブジェクトの収集から関係のないプログラムを除外して、だけで見える化のためのシステムを開ら影響調査、修正後の一括コンパイル

関係あるものについては 1 つずつソー

発するのは制約が大きすぎると考え、までを行う一連のツール類と、プログスを呼び出して影響範囲を確認すると断念した経緯があります。2011 年に

ラムの検索と結果のダウンロード、従いう方法を取っていた。そのためシス

Delphi/400 を導入し、グラフィカルな属論理ファイルの調査、ソースとオブテム全体の把握と影響範囲の特定にインターフェースを簡単に作れるようジェクトの整合性チェックなどの機能時間がかかり、 改修の要請にタイムになったので取り組んだのが、IBM iをもつ補助ツール類で構成されている。

リーに応えられなくなっていた。

資産の見える化とともに、 アジャイ

改修作業はこれらのツールを使い、ル開発も可能な今回のシステムです」「収集」→「分析」→「再構成」の 3 つ（吉岡氏）のステップで進められる（図表 1）。

さらに、物理ファイルにフィールドを追加する場合、影響を受けるすべて

図表 2

トップ画面（総合メニュー）。ここから作業を開始する

図表 3

オブジェクト一覧の書き出しを行う画面

http://www.imagazine.co.jp/056-059_17imagSPRING_migaro_FIX.indd 57

57

2017/03/03 13:52

最初に、処理対象のライブラリからすメニュ ーリストから選択したり、 ツ氏は、「それと同様の仕組みを構造化べてのオブジェクトをテーブルファイ

リー表示中の項目の選択で表示できされた情報の展開に適用したのが、見ルへ抽出する（オブジェクト情報の収る。

える化ツールです」と語る。
プログラムの影響調査では、ファイ集）。次に、収集した各オブジェクトの親子関係を、「クローラー」と呼ぶ
RPG と CL で開発したツールを使ってツリー構造のファイルに書き出す（以上、「収集」（図表 2・図表 3））。そしDelphi/400 のコンポーネントを使い、短期にツール開発

ルを使用している親プログラムや、子プログラムと連携する親プログラムを調べることが多い。 そのようなとき、見える化ツールの検索機能によって関て、そのツリーファイルを Delphi/400

見 え る 化 ツ ー ル の 開 発 で は、連ファイルやプログラムをすぐにリスで開発した「見える化ツール」で表示・Delphi/400 が備える Query コンポー

ト化しダウンロードもできる。プログ

展開して、抽出を行うのが「分析」でネントと TreeView コンポーネントをラムの修正は、この影響調査の結果をある（図表 4）。

主に使用した。コンポーネントはソフもとにスピーディに行うことが可能だ。

そして最後の「再構成」は、分析結トウェアの部品で、Delphi/400 の開システムの開発は 2014 年にスター

果から得られたデータを CSV 形式に発画面上にコンポーネントを貼り付けトし、 約 3 カ月半で終了した。
「シス変換して IBM i にアップロードし、「一て属性を設定するだけで GUI 画面をテム部員が利用するだけなので見た目括コンパイルプログラム」を使って連作成できる。

やわかりやすさにはこだわらず、短期続リコンパイルする工程である（図表Query コンポーネントはデータベー開発だけを考えて作業しました 」（吉5）。その結果を稼働中のライブラリにスや複数のテーブルに SQL 文でアク岡氏）。実際、プログラムの実装に要リリースして作業は終了する（物理セ ス す る と き の コ ン ポ ー ネ ン ト、したのは 1 カ月たらずで、 残りの 2 カファイルの設計の見直しは、従来どお

TreeView コンポーネントは、階層化

月半は事前調査に費やしたという。

り手作業で行う必要がある）。

されたデータを視覚的に表示するため「分析」ステップの見える化ツールをのコンポーネントである。

事前調査に時間を要した理由について吉岡氏は、「ツールを使ってソー使うと、オブジェクトの親子関係を「親同社では、この見える化ツールの開スの構造を解析し良好な結果を得る→子」や「子→親」などの表示形式で発以前に、これらのコンポーネントをには、システムがルールに則って構成展開でき、 全ノードの展開・ 格納も使って、 製品と組立品および部品とされていることが必須です。当社ではボタン 1 つで行える。精査したいプロの関係を表示する「部品構成図」プロ

従来から、“論理ファイルは物理ファグラムは、クローラーの処理リストやグラムを開発した経緯がある。 吉岡

イルと同じライブラリに作成する ”“ソースとオブジェクトは同じライブラリに配置する”などの運用ルールを設

図表 4

Delphi/400 で開発した見える化ツールを使い、RPGソースをツール展開表示

けてきましたが、長年の度重なる改修で例外も数多く発生していました。その例外の修正や、 影響調査の範囲を絞るための現行データと過去データとの区分けに、 予想外に時間がかかりました」と説明する。

改修をアジャイル方式で行えるようにする
今回のシステムによって、同社では改修のやり方が大きく変わった。
大規模な改修の場合、 それまでは計画と影響調査に長時間をかけ、 設計、開発、テストへと移るウォーター58

2017 Spring

056-059_17imagSPRING_migaro_FIX.indd 58

2017/03/03 13:52

Migaro.Technical Report セレクション 4

フォール型で行っていたが、導入した

図表 5システムでは影響調査が短時間で済新規開発した一括コンパイルツールを使い、ファイルごとに連続コンパイルを実行

み、修正、リコンパイル、リリースもスピーディに進められるので、小さな単位の改修が可能になった。つまり、「修正→リリース」を小刻みに繰り返すアジャイルな改修が可能になったのである（図表 6）。
その変化の 1 つとして、たとえば仕様書がある。 従来、 大規模な改修では設計前に時間をかけて仕様書を作成してきたが、現在は、改修のポイントを記したメモとラフな画面イメージをメンバー間で共有するだけで作業を進める。
「仕様書の作成・管理は廃止してしまいました」と、吉岡氏は言う。
また、修正したプログラムはすみやかにリリースするので、最新のソースの影響調査でほかのメンバーの進捗状す 」 と言い、 今回のシステムの意義に、変化に強いシステム基盤への第一況が確認できるようになった。

を次のように総括する。

歩だと考えています」

吉岡氏は、「当社のような開発要員「企業は、新しいイノベーションを創見える化ツールについては今後、各が少人数で、それぞれのスキルマップ出し、 その改善の繰り返しで成長しツールの機能の充実化（重複排除ながわかっているような体制では、 アていきますが、それを支えるシステムど）や、スケジュール機能による収集・ジャイル型の開発・改修は非常に合っは、開発・改修をスピーディに行える

メンテナンスの自動化、Delphi のソーていると感じています。小さな単位で要件を備えていることが重要です。今スファイルへの対応などをを予定して開発・ 改修作業を割り当てられ、 修回のシステムは、 開発・ 改修の効率いるという。

正を終えたところからリリースできま化を目指したものですが、それと同時

図表 6

見える化ツールを使ったアジャイル手法による改修の効果● 従来の大規模改修の場合
影響調査

設計

実装

テスト

実装

テスト

● アジャイル手法による改修
影響調査● 導入効果時間の短縮

設計

手戻りによる時間ロスの減少
よりよい実装とテスト

システム停止時間が短い計画を立てやすい

リリースのタイミングが早い
仕様書はユーザー目線のイメージ資料のみ

http://www.imagazine.co.jp/056-059_17imagSPRING_migaro_FIX.indd 59

59

2017/03/03 13:52