Pages

2015年10月13日火曜日

帳票運用ノウハウ ~アタマの体操~

こんにちは。阿部です。

今日は、算数の問題です。A4サイズの帳票を三つ折りにして、長形3号の封筒に封入します。そのときの、折り目の位置を算出します。














【前提条件】
・封筒は窓あき封筒で、封筒の窓から、帳票に印字した送付先情報(郵便番号、宛先住所、
 宛名)が見えなければなりません。
・封筒の中で封入物(帳票)が上下にずれても送付先情報が窓から見えなければなりませ
 ん。
・封筒の窓から、帳票の本文が見えてはいけません。封筒内で封入物(帳票)が上下にずれ
 ても、本文が見えてはいけません。


帳票上部から送付先情報上部までの長さaは、封筒上部から窓の上部までの長さAよりも大きいので、封筒内で帳票が上にずれても、送付先情報が窓枠からはみ出ることはありません。

(a A)

ところが、帳票上部からの本文上部までの長さcは、封筒上部から窓の下部までの長さBより短いので、中身が上にずれると、本文の上部が封筒の窓から見えてしまいます。

(c B)

さて、皆さんならどうしますか?(印字位置は固定です)




















-------------------------------------------
a : 帳票上部から送付先情報上部までの長さ
b : 帳票上部から送付先情報下部までの長さ
c : 帳票上部からの本文上部までの長さ
A : 封筒上部から窓の上部までの長さ
B : 封筒上部から窓の下部までの長さ
C : 窓の下部から封筒下部までの長さ
D : 封筒の長さ
-------------------------------------------

封筒の中身が上下に動くのは、封筒の縦幅よりも、三つ折りにしたときの用紙の上下の幅のほうが狭いからなので、三つ折りにしたときの用紙の幅が封筒の縦幅ぎりぎりになるように調整します。

縦幅ぎりぎりに折るためには、本文が窓からはみ出る問題があるため①面で調整はできないので、②面を封筒の縦幅ぎりぎりになるようにします。

(y D)

※③面でもいいですが、今回は②面で考えることにします)











②面の長さyを①面の長さxより大きくし、その分xを小さくすれば、三つ折にしたときの上部からの封筒内の本文の位置が下に配置されるので、窓枠からはみ出ないようにできます。このとき、①面の長さxは、どのような範囲であれば条件を満たせるでしょうか。

まず、送付先情報の上部が窓枠上部からはみ出ることはないので

(a A)

送付先情報の下部が窓枠の下部にはみ出ないようにするための条件を考えます。
そのためには、三つ折りにしたときの帳票上部から送付先情報の下部までの長さ

(y - x) + b

が、封筒の上部から窓枠の下部までの長さ(B)よりも小さい必要があります。

(y - x) + b B

すなわち

x y + b - B y Dなので

x D + b - B D - B Cなので

x C + b

次は、帳票の本文が窓枠から見えないようにするための条件を考えます。
そのためには、三つ折にしたときの帳票上部から本文までの長さ

(y - x) + c

が、封筒の上部から窓枠の下部までの長さ(B)よりも大きい必要があります。

y - x + c B

同様に数式を処理すると

x C + c

というわけで、①面の長さx

C + b x C + c

という範囲であれば、送付先情報は封筒の窓から表示でき、本文は窓からは見えないようにできます。

ちなみに注意事項ですが、

y D

としていますが、

y D

だと封筒に入らないし、帳票を複数枚重ねて封入すること
もあるので、yDよりも数ミリ小さめにしておきましょう。

さて、私は先日実際にこのような調整をしたわけですが、そもそも帳票の印字位置を決めるときに、封筒に入れることまで考慮すればよかったのです。経緯はさておき、このような調整をするのはレアケースなのだとは思いますが、皆様のご参考になればと思います。

頭の体操、くらいにはなりましたでしょうか。


阿部氏の過去投稿

帳票開発ノウハウ! ~ソート処理での出来事


2015年9月8日火曜日

帳票運用ノウハウ ~これからはじめる始まるマイナンバー~

こんにちは、深水です。

前回は、帳票システムのクラウド利用について投稿しました。今回はガラッと変わり、これから始まるマイナンバーについてです。

20161月からスタートする社会保障・税番号(マイナンバー)制度、それに先立って201510月から個人に割り当てられる番号の通知が始まります。

「社会保障・税番号(マイナンバー)制度」とは、住民票コードを元にして、個人個人に生涯変わらぬ十二桁の番号を振ることにより、複数の行政機関等にまたがって存在する個人の情報を効率よく集約することができる「社会インフラ」です。

当面は、税、社会保障、災害での利用に制限され、個人の番号をキーとした情報連携システムを構築することにより効率的な社会保障の提供を主な目的とされています。
マイナンバーの本格利用は2017年からという記事も目にしますが、企業では主に「給与・報酬の支払い」や「個人情報の管理」の面で業務上の影響がありそうです。帳票の観点では、「給与明細」や「源泉徴収票」などへマイナンバーの記載が義務付けられます。

これらの帳票にITシステムでマイナンバーを記載するためには、まず個人の番号を収集する必要があります。この収集作業だけでも苦慮している声を耳にします。特に社内の番号収集対象者の多い小売りや外食業界では、アルバイトが多く数万、数十万件という膨大な数の収集が必要となります。また、情報漏えいの罰則が厳しい点も頭を悩ませているようです。アルバイトが多い場合、従業員の流動性が高く、番号収集のみならず破棄の頻度も高くなります。そのため、番号管理には厳重な対応が必要になりそうです。

国税庁のホームページ(http://www.nta.go.jp/mynumberinfo/index.htm)にはは、申告所得税関係における申請書、届出書において、個人番号の記載が必要となる書類が掲載されています。まだ、様式案としての掲載となっており確定ではないことも注意が必要です。各企業では、これらの書類について現在の作成方法を確認することから開始しています。様式が確定する時期があいまいなため、決定から実行までの期間が気になるところです。ただし、現状の作成方法を認識しておくことで、ある程度の対応工数を想定できるのではないでしょうか。

対象となる書類もこのホームページに掲載されているため、それらの書類に必要なデータをITシステム全体から影響するシステムの特定も事前に行っておくことも必要です。書類に必要なデータの所在を把握しておき、複数のシステムやDBに分散されているのではあれば、それらのデータを収集し、必要なデータを整えた(クレンジング)結果を帳票作成ツールを活用して、帳票のレイアウトに反映します。

 マイナンバー制度では、対象となる帳票に単に番号を付与するだけでなく、その番号の取り扱い方法、運用ルールの定義が必要です。人事、給与、会計システム等分散したITシステムでの番号の管理、運用、破棄を確実に行わなければなりません。皆さんは、マイナンバーに対してどのような取り組みをされていますでしょうか。マイナンバーに関する、ITシステム運用の課題に対してこれまで同様、ご提案してまいります。

深水さんの過去の投稿

2015年8月20日木曜日

帳票開発ノウハウ ~ガイドラインのすすめ~

こんにちは、ユニリタの尾田です。
ご無沙汰しておりました、ひさびさの投稿です。

最近気づいたのですが、帳票の業務に関わる方でも、帳票やプリンタの事って意外と知らない人が多いようで、私が常識と思っていた

 ・UNIXにはWindowsの様なプリンタドライバが無い
 ・プリンタメーカ毎にプリンタ言語(PDLがある
 ・プリンタ本体の操作で印刷の履歴やステータス情報が印字できる

の様な事項や用語を知らない人が多いようです。

仕事上、帳票の話をする際には、まずはお客様がどの程度帳票の事をご存知なのかを把握して、お客様に合わせた説明が必要ある事をあらためて気づきました。これは帳票の話に限る訳ではありませんが、今まで以上にお客様に判り易く説明する事を心がけたいと考えた次第です。

さて、以前の投稿では「帳票マイグレーション」のお話をしましたが、今回も帳票の作成や移行の時に注意する点を書きたいと思います。帳票って、実は毎年少しずつ変わっていきます。変更の多いお客様では、1年で全体の半分以上の帳票が変更される事があります。税制の変更、法律の変更など外的要因での変更も多いですが、エンドユーザ様からのリクエストによる変更も結構多いです。

従ってシステム構築の際には、カットオーバ後に毎年発生する帳票改定のコストも加味して帳票を設計した方が良いです。特に複雑なロジックや、凝ったレイアウトを作れば作るほど、改定の際の工数も大きくなってしまいます。

現場の担当者の方は、常に凝ったレイアウトを要望されると思います。システム部門がどこまでレイアウトの調整役を出来るかで、後々のメンテナンスコストが大きく変わると言っても良いでしょう。
この問題については決定的な解決方法はありませんが、一つの提案として「帳票設計ガイドライン」を作成する事をお勧めします。ガイドラインに沿って帳票を作成する事で、個人や部門の趣向に偏った帳票の作成をある程度抑制する事が出来ると思います。

帳票設計ガイドラインには
 
 ・用紙サイズ
 ・使用するフォントの種類とポイント数
 ・罫線の種類や太さ
 ・網掛けの%
 ・上下左右の余白

などの基本的な取り決めに加え、帳票を作る段取り(印字調整の仕方)、ロゴの取り扱い、レイアウトの命名規則なども記載しておくと良いです。

【設計ガイドラインの例1】
【設計ガイドラインの例2】

     
また、様々な要因で帳票設計ガイドライン自体も陳腐化しますので、定期的な更新も定義して帳票設計ガイドラインの改定時期も決めておくと良いでしょう。毎々の帳票作成やレイアウト改定のコストで悩んでいる方は、帳票設計ガイドラインの作成に取り組んでみて下さい。

尾田さんの過去の投稿
http://reportsytems.blogspot.jp/2014_07_01_archive.html

2015年7月22日水曜日

帳票運用ノウハウ ~職場ではペーパーレス化は進んでいますか?~

こんにちは。ユニリタの小柳です。

しばらく、社名変更やら、部署の異動やらで、掲載が休止状態にありました本ブログですが、ようやく再開することができました。月2回ぐらいの公開をしていきたいと思いますので、引き続き今後ともよろしくお願いします。

さて、6月から公開していますすWEBセミナー「ウェビナーユニリタ」でご紹介中のペーパーレスの現状について今回はお話ししたいと思います。

皆様の職場ではペーパーレス化は行われていますか?
環境配慮やコストダウンも目的に、企業ではペーパーレス化が推進されて久しいと思います。
企業によっては、結構な年数でペーパーレス活動を行ってきているので、成果が出ているのではないかと思いますが、実態はどうなのでしょうか?

IDC Japanが調査、発表している
全世界における2011年のデジタルハードコピーデバイスからの印刷ページ数
によると先進国の印刷量は前年比 5%減との調査結果が出ています。直近調査結果ではありませんが、現在もこれに近い状況にあるのではないでしょうか。

これに対し、同じくIDC Japanによる
国内のデジタルプリンター/MFPにおける2013年の印刷ページ数
によると、日本国内の印刷量は前年比2.1%増という驚きの調査結果が出ています。ペーパーレス化って今では常識的に言われていますが、印刷量は増えていると矛盾した結果が出ています。

内訳は、インクジェットプリンタの印刷量が前年比 6.9%増なのです、IDC Japanによると、ビジネスインクジェット機の普及によるものではないかと推測しています。確かに、インクジェット機に強いメーカーの企業向けのCMを、テレビや雑誌広告でよく見かけます。ビジネスインクジェット機が企業に浸透してきているのは間違いないのでしょう。では、これまでのオフィスプリンターの主流であるレーザープリンタに着目、むむむ、調査データでは、カラーレーザープリンタの印刷量も前年比  6.3%増増加してきているとの事!!

ビジネスインクジェットプリンタもカラーレーザープリンタも、オフィスで使う事が多いプリンタです、
先進国である日本が、世界の流れに逆行して印刷量が増えている答えはここにありそうです。

ペーパーレス化の動きから、情報システム部や業務運用部門による大型プリンタでの帳票大量印刷は大きく減少してきました。また、部署ごとの紙帳票は電子帳票にとって代わり、一見、紙は減少しているかに見えます。しかし、オフィスの印刷量は増えている傾向にあります。

皆さんの中には、パソコンの画面で閲覧はするものの、なかなか頭に情報が入らず、紙印刷をして確認している方はいらっしゃいませんか?かく言う私もその一人です。

個人が出す紙の印刷量は、なかなか会社全体でコントロールしにくく、印刷する用紙サイズを間違えたり、一度は印刷・破棄した帳票を、もう一度見る機会があり、また印刷するケースなども少なくないと思います。

ここでもう一度、ペーパーレス化を再定義して、環境貢献やコストダウンの見直しを行ってはいかがでしょうか。ウェビナーでは、その答えの1つを定義していますので、ぜひ参考にしていただければと思います。

電子化・ペーパレス化に潜む罠
※登録などは一切不要ですので、お気軽に視聴ください。

帳票って何気なく普段使用していますが、まだまだ印刷しないといけない重要な情報源なんです。
これから、月に2回ほどではありますが、このブログを通じて、帳票について考える時間を作っていきたいと思います。

2015年3月31日火曜日

帳票開発ノウハウ ~幹業務システムをクラウドで利用する~

こんにちは、深水です。

突然ですが、皆様の企業ではクラウドサービスを利用していますかスケジュール管理やeラーニング、勤怠管理などはクラウドサービスが既に浸透しているのでないかと思います。我々も利用しています。

基幹業務システムについては、どうでしょうか?基幹業務システムをクラウドで利用するにはまだハードルが高いとお考えの方もいらっしゃると思います。今回はこのブログのキーワード「帳票」についてのクラウド利用についてご紹介します。

基幹業務システムで生成される帳票、しかも、機密性の高い帳票(たとえば、請求書とか)をアウトソーシングすることはこれまでも多々事例があります。月締めにより印刷のピークがある場合には、自社で処理するのではなく、専門企業に依頼します。これによりコスト面だけでなく、本業にリソースを集中させることができ、効果をあげている企業がたくさんあります。

このような企業で次に取り組もうとしていることのひとつが、帳票開発環境のクラウド利用です。

本番環境はアウトソーシング、開発環境は自社で保有するのではなく、クラウド環境を利用します。アウトソーシング先はもちろんセキュアであり、本番環境に対してアクセスすることはできません。しかし、帳票に関しては、レイアウト変更やタイトル変更を自由に行いたいという要望は多々あります。


帳票のレイアウト変更やタイトル変更だけであれば、帳票ツールが自社PCにあればできるのでは、と思われたかもしません。それだけでは足りないのです。変更をするということは、検証が必要です。検証にはできるだけ同じ環境を準備する必要があります。ただ、本番環境と同じ構成を自社で用意することに様々な面でIT部門の方は苦慮されています。

これらの課題を解決する1つとしてクラウドの活用です。AWSで帳票プロダクトをご利用頂けるサービスを検討されては如何でしょう。クラウドサービスのため、サーバやプロダクトを購入するのではなく、サービスとして利用いただきます。短期間での利用開始、初期費用の抑止、継続的な利用、運用面でのメリットに魅力を感じて頂いています。

自社でサーバを保持する案もありましたが、運用管理をアウトソーシングしたが開発機を保持すると、それが必要になることに疑問符が。。。

それを解決したのが、帳票システムのクラウド利用でした。開発環境がほしい、必要、でも準備できない。そんなお声にお応えします。いかがでしょうか?


深水さんの過去の投稿
http://reportsytems.blogspot.jp/2014/10/blog-post_30.html

2015年2月2日月曜日

帳票移植ノウハウ ~OracleLinux移植について~

こんにちは。今週は初投稿となります宮本が担当させて頂きます。

今回の本題は帳票と違う話になってしまいますが、今年私が、弊社製品のOS移植を行った際の事についてお話させて頂きます。

皆様は、「Oracle Exadata Database Machine」(以降Exadata)をご存じでしょうか?Oracle社が提供しているデータウェアハウス向けのプラットフォームの名称です。このExadataからの帳票出力に弊社製品を使いたいとの要望を頂き、移植を行う事になりました。Exadataでは、OSに「OracleLinux」というLinuxOSを採用しています。OracleLinuxは「RedHat Enterprise Linux」(以降RHEL)をベースにカスタマイズが加えられOSなっています。つまるところ、Exadataへの移植とは、OracleLinuxへの移植となります。

OracleLinuxの大きな特徴の一つとして上げられるのがOracle製品に最適化されたプラットフォームである(つまり「処理が速い」)ことと、システム起動時に以下の2つから起動カーネルを選択することが出来ることです。


①「Red Hat Compatible Kernel
その名の通りRHELとの互換性を保ったカーネルで、RHEL動いていたプログラムが、そのままOracleLinuxで動く事を謳っています。
②「Unbreakable Enterprise Kernel
OracleLinux用に最適化されたカーネルで、RHELの互換性は保証されておりません。このカーネルであれば、OracleLinuxのパフォーマンスを100%発揮できます。


でも、わざわざOracleLinuxを使って①にする人がいるのかなとも思います。 よくわかっていませんが、①を選択しても他のOSと比べればOracle製品が速く動くとか。あるいは、単にExadataを使いたい人とかでしょうか。さて、折角のOracleLinuxへの移植なのですから、パフォーマンスを十二分に発揮できるカーネルでやるべきだと考え「Unbreakable Enterprise Kernel」での移植を実施することにしました。弊社製品はRHEL版があるので、それをOracleLinuxへ移植します。移植自体は、非常に簡単で特に大きな問題も無く行えました。OracleLinuxRHELがベースとなっている訳ですから難しくないことは想定内ですが、それでも移植しやすいよう考えられているのだと思います。

移植作業が終わりましたのでテストを行うのですが、やはり気になるのはパフォーマンスです。Oracle社のHP等で、製品紹介内容に以下のような文句があります。「高度なスケーラビリティと信頼性をエンタープライズ・アプリケーションおよびシステムに適用するOracle Linuxは、卓越したパフォーマンスを実現し、すべてのx86ベースのOracle Engineered Systemsで使用されます。」・・・つまり、RHELよりも良いパフォーマンスを発揮することが出来ると謳ってる訳ですが、しかし、Oacle製品に限ると言うことだと理解できます。なお、実は移植した弊社製品はOracle DataBase等のOracle製品を使用しておりません。果たして、パフォーマンスに差が出るのか出ないのか、実際はどうなのでしょうか。

OracleLinuxUnbreakable Enterprise Kernel)」とそのベースとなった「RHEL」で、どの程度パフォーマンスに違いが出るか、両OSでの比較テストは次の通りです。テストではマシン環境による違いが出ないよう、

勿論、同スペックマシン
・弊社製品のモジュールは、RHEL版でもOracleLinuxでもほとんど同じ
・弊社製品の機能である帳票の仕分けと帳票に出力を、同じ手順で3回計測し、平均値を取得という形で実施、計測しました。

果たして結果は・・・?


上記の通り(横軸が帳票数で縦軸が処理時間です)、RHELと大きな差がありませんでした。というか、ほぼありません。他にもいくつかテストを実施したのですが、やっぱり、ほぼ違いがありません。それにしても、Oracle以外のDatabaseでは全くといっていいほど性能が変わらないというのもある意味すごいかもしれません。もしかしたらわざと他のDatabaseは早くならないような、そういうKernel実装をしているのではと勘ぐってしまいました。

まとめると、「RHEL版からOracleLinuxの移植は簡単だった」、「OracleLinuxOracle以外のDatabaseを使うとパフォーマンスはRHELとまったく同じだと分かった」と言うことになります。

今回は帳票とは大分違う方向性の内容となりましたが、如何でしたでしょうか?
次回をお楽しみに!

OracleExadata
http://www.oracle.com/jp/engineered-systems/exadata/overview/index.html
OracleLinux
http://www.oracle.com/jp/technologies/linux/overview/index.html

2015年1月19日月曜日

帳票開発ノウハウ! ~手戻りが恐い!帳票移行の原本合わせの注意点~

こんにちは。吉谷です。

今回は、「帳票移行」における「原本合わせ」の注意点についてご紹介したいと思います。

皆さまの会社には、業務アプリケーションがあり、その業務アプリケーションから必ず帳票を作成していると思います。業務アプリケーションの機能不足やエンドオブサービス等の理由により、別の業務アプリケーションへ移行する場合があります。特にここ数年はOSの入れ替えを契機に、業務アプリケーションの移行が目立っていると思います。

この業務アプリケーションの移行のタイミングで、帳票パッケージ(ここでは帳票フォームを設計して帳票ファイルを作るためのパッケージ)も合わせて入れ替えることもあります。そして、それまで使用していた帳票パッケージで作成した帳票を元に、入れ替えた新しい帳票パッケージで帳票フォームを作り直すことを「帳票移行」と言っています。この時、それまで使用していた帳票に合わせて、新しい帳票フォームの文言や罫線の位置や大きさの調整をする作業を「原本合わせ」と言っています。

私が今までに携わってきた帳票フォームの原本合わせの経験からみて、簡単なフォームを1つ作成するのに2時間、複雑なフォームになると5時間以上の時間が必要となります。原本合わせは、許容誤差が1ミリ以内の世界であり、作成した帳票フォームとデータを組み合わせて帳票を作成し、実際に印刷したうえで、印字位置、フォントサイズ等の違いがないかを確認する必要があります。また、原本合わせの調整結果を最終的に確認してOKを出すのがその帳票を使っている現場の方だったりするので、帳票開発の作業場所と地理的に離れていたりして、やりとりに時間がかかります。

今まで使用していた帳票と全く同じものを作成するには、それだけの手間がかかります。100フォーム以上の原本合わせが必要となると、手戻りが発生した時の工数が馬鹿にできません。
ここでは、私の原本合わせ失敗経験に基づいた、私が心がけている注意点を3つご紹介させて頂きます。

①フォーム修正におけるルールの共有

お客様が使用している帳票フォームには、いくつかの共通点があります。
・会社のロゴ画像は、特定の座標に表示されている
・会社の住所・電話番号の記述は、特定の座標に記述されている

帳票フォームの移行作業は複数人でやることが多いため、メンバー内での情報共有を必要となります。以前に携わった帳票の移行作業では、バーコードの印字位置ルールを共有が漏れてしまい、大きな手戻りになったことがありました。また、共有するルールをメンテナンスすることも大切です。当たり前ですね。原本合わせは、現場の方に確認してもらうと、どんどん指摘がでてきます。現場の方はやはり開発者と観点が違います。その指摘の共通化できるものをルールに追加していかなければ、いつまでたっても原本合わせが終わりません。

②原本に潜む問題について

①では、帳票フォームの共通点についてお話ししました。しかし原本自体が共通化されていない、あるいは共通化にムラがある場合があります。類似する帳票原本を比較すると、一見共通の様に見えて、座標が若干異なるということがあります。
これは、原本では意図して小さくしている場合もありますし、帳票を作成した当時に共通化が漏れてしまった場合もあります。判断が必要になり、判断を誤ると手戻りになります。
無理に原本に合わせた結果、後で他の帳票との統一性を持たせてほしいと要望を頂いたことがあります。
原本合わせはとても曖昧な作業なのです。

③移行元の帳票フォームの印刷

3つめ、最後になりますが、これは最近やってしまったことです。とてもケアレスですが・・・。


帳票移行では、お客様から帳票の原本を頂き、頂いた原本を元に新しい帳票フォームを作成します。
この原本をPDFファイルで貰う場合に、このPDFを紙で印刷する時に注意が必要になります。
PDFを印刷する時に、AdobeReaderでは、下記の4りの印刷方法があります。

・合わせる
・実際のサイズ
・特大ページの縮小
・カスタム倍率

デフォルトは「合わせる」だと思います。普段意識しないと思いますので大抵の場合はみなさん「合わせる」で印刷していると思います。これは印刷する用紙サイズに合わせてPDFのページを拡大縮小して印刷するものですが、実は用紙サイズと実際のページサイズが例えばどちらもA4であっても、実際のサイズよりも倍率が縮小されて印刷される可能性があります。

これの何が問題かと言うと、気付かずに、この縮小された原本のサイズで新しい帳票フォームを作成したり、原本合わせしたりしてしまうと、後でその全てがやり直しになるということです。他にも帳票フォームの移行作業における注意点は多々ありますが、大きな手戻りとなった3つだけの紹介とさせて頂きます。

今回の記事で、帳票フォームの移行作業がどれ程大変なものかを感じて頂けたのであれば幸いです。