1. パネルディスカッション
帳票開発の肝
小井土 亨
13-C-5 特定非営利活動法人 アイネタジャパン
日本XPユーザ会
鋤柄 吾朗
TIS株式会社

2. 自己紹介
名前 鋤柄吾朗 すきがら ごろう
uid GARAPON
所属 TIS株式会社 金融・カード事業統括本部
カード第2事業部 カードソリューション事業開発部
アーキテクチャ設計グループ
仕事 金融のお客様を中心にシステム開発に携わる。
JavaでWeb（クラサバ⇒Web、リッチクライアント）
方式設計、開発リーダー
好き 自働化、マクロ
必要 デュアルディスプレー
言葉 「出来ない理由じゃなく、どうしたら出来るかを考えろ」
趣味 ダーツ

3. 今まで出会った帳票
ずれて窓枠が合わない帳票
プリンターごとにずれる・・・
作成に5時間かかる帳票
1000万件＊2000万件＊・・・・・
アクセスコントロールがやたら複雑
登録部門と出力部門が別で、出力前なら
内容の編集が可能。管理者は再発行指示
ができて・・・・・

4. 帳票は何かと難しい？？
相対するIFが多い
人的IF：エンドユーザー、社員、関連会社、提携先
システムIF：プリンタ、FAX、センタ出力、PDF、プレビュー
扱うデータ量が多い
統計データ帳票、月間サマリーデータ、売上請求入金
複数の情報が載っている（ユーザー情報+売上情報）
即時と時点データの混在
ある時点の切り出しとしての帳票
しかしボタンを押した瞬間のデータを出したい。
出力日、出力者、端末名を表示したい。
画像と文字
グラフの作成、画像の埋め込み
フォント種類、プロポーショナルフォント、OCR、バーコード、
顧客のこだわり
顧客要望とミスマッチが発生しやすい

5. 教訓
紙は神
早めに実際の仕組みで印刷する
印刷したものを顧客に見せる
何に使われるのか、誰が使うのかをしっかり
把握する
作成タイミングと印刷タイミングのずれを意
識する
ニーズにあった方式設計
早めの性能設計

6. 自己紹介
名前 小井土 亨
仕事 ソフトウェアのパッケージベンダーで、
業務パッケージの開発
得意分野 Microsoft関連技術
最近興味 テスト及び作業の自働化
アワード 2009 Microsoft® MVP アワードSolutions Architect
参加コミュニティ
XPJUG
VSUG

7. 結論 帳票に銀の弾などない
すべての帳票システムに対応できる、
万能解決策やツールは存在しない
個別のシステムの特徴や制約を前提に、
最適な解決策を構築する必要がある
私の提案
帳票部分のアーキテクチャ設計を行う
アーキテクチャへの要求
非機能要求（システム品質特性 ） 処理速度、コスト
変化しない機能要求 出力帳票の品質、出力内容

8. 帳票システムとは
業務システムでは
全体の６割を占める場合もある
二つの側面
ビジネス側面でのインターフェイス
請求書、送り状、バーコード、OCR
システム側面でのインターフェイス
大量のデータ処理（集計処理など）
プリンタ,FAX,PDF,XML Paper Specification (XPS)

9. 帳票システムの難しさ
ビジネス側面
多くのステークホルダ（利害関係）
システム利用者の顧客や取引先
出力物（紙）の制約
システム側面
処理速度
データベース処理の速度、出力加工処理
外部システムへの依存
プリンタへの出力速度、印字品質
テストの難しさ
多彩な出力、多様なパラメータ（膨大な組合せ）

10. 帳票部分のアーキテクチャ策定
大前提
システムアーキテクチャが制約
非機能要求（品質特性）の明確化
パフォーマンス（性能・速度）、セキュリティなど
長期的な機能要求の明確化
出力パターン、出力品質
作業手順
論理的な側面から階層構造を決定
論理的な階層構造を物理構造に対応付ける

11. 会場の皆さんの
帳票開発の
疑問・質問
聞かせてください！

12. 性能対策
CPUフル、大量出力による他業務への影
響
⇒帳票出力を別サーバーに
レスポンス
⇒夜間バッチで作成しておく
⇒非同期で実行
大量に出力するときの1枚目のレスポンス
の悪さはどうしようもない。。。

13. ズレ
プリンターメーカーによるずれ
印刷プレビューと印刷物のずれ
デザイナーとPDFのずれ
PDFとTIFFとEMFのずれ
⇒レイアウトを修正しどのプリンターでもずれ
ない範囲にレイアウトを調整
ずれがあることを前提にずれの合格範囲を
顧客と合意。

14. 複雑な帳票出力管理
出力内容を入力する部門と出力する部門は別
その為、出力済みでなければ内容の修正が可能
閲覧参照できる出来る帳票は部門、役割によって異なる
すべての帳票はページ単位で連番管理され、紛失時などはそのIDで1ペ
ージ単位の再出力が可能
印刷時には出力者、出力時刻、出力対象IDが記載された印刷用表紙を
添付する。
複数帳票をまとめて出力することが可能
管理者はいつ誰がどの帳票を出したか調べることが出来る
管理者は帳票ID単位で再出力指示を出すことが出来る。
⇒後から分かると真っ赤に燃える。
事前に顧客要件をしっかり把握しておく。
システム外の紙のフローを押さえる

15. クラサバからWEB
出来なくなる事、変わる事が多くある。
１、帳票出力プロセスの変更
クライアントからサーバーに移る
２、レスポンスの悪化
早くなることももちろんある。
⇒変わる内容と対応策のメリデメを早期に提示

16. リッチクライアントやRuby
Rubyからの出力に対しベンダの実績がなかっ
た
⇒HPには対応って書いてあるのに・・・TT
⇒実績はないけどIFはあったので頑張った。
プレビューやらをやってくれるIEコンポーネント
が出ているがリッチクライアントとの相性がよく
なかったり、、
⇒早めにベンダを巻き込む

17. 帳票システムアーキテクチャ
策定ポイント
アーキテクチャの特性（含み制約）の列挙
非機能要求（品質特性）を列挙する
非機能要求（品質特性）の優先順序付け
各品質特性は、相反する項目がある
トレードオフを考慮し、アーキテクチャを決定する
非機能要求（品質特性）の明確化と数値化
依存するシステムアーキテクチャの制約を明記する
印刷速度や単位時間当たりの最大出力枚数など数値
化できるものは、数値を明記する

18. 帳票システムアーキテクチャ
策定ポイント
複数のビューによる検討
実行ビューや配置ビューが重要
４つのビュー
実行ビュー
実行時のプロセスやタスクやスレッドといった実行時の単位の構造
配置ビュー
システムをどのようなマシン上で動作させ、各プロセスがどのマシン（
CPU)上に配置される等を表した構造
論理ビュー
システムが必要とされている機能を実現する、論理的な構造
開発ビュー
システムが開発時のファイル等を単位とした構造

19. 帳票テストの効率化
テストを自動化する
どのようなテストが自動化できるのか
～と同じを確認するテスト
100%の自動化は、困難
ポイント
PDFなどの出力機能を利用
正常に動作した時のデータを正常値として保存
比較は、ツールで可能（WinMergeなど各種あり）
印刷日付や印刷時間など、そのつど異なるもの
モジュール化して、テスト時に差し替えて、同一化する

20. 膨大な帳票テストの対処
帳票のテストのテストケース爆発の対応
問題
入力条件が膨大で、テストケースが膨大になる
対策
印刷部分のモジュールを切り離し、自動化する
テスト結果はPDFなどで保存し、正常結果と比較
テストケース数の最適化
オールペア法などを利用して、テストケースを最適化する
PICTなどのツールを利用
http://www.pairwise.org/