仕事のメモ・共有版

ひと昔前は、帳票をデザインする方法に、あまりたくさんの選択肢がなかったように記憶しています。なので、帳票専用に作られたミドルウェアを採用して、使い慣れないデザインツールと格闘する、なんてことがままありました。実際にプリントされる帳票もまあまあきれいな感じだし、ボタン一発で印刷の操作ができてシステムとうまく統合されている感じも出るし、決して悪くはありません。一般的に、開発や保守のコストは高めになると思います。 その後、HTMLの形で帳票を作っても別にいいのでは、という発想で、もうちょっと簡易に帳票を作るようなものも時々見るようになりました。情報システムのほうは、最終的にプリンタに出力するところはユーザーに任せてしまうことにして、そのかわり、HTMLをファイルとして出力して、これを適当なウェブブラウザーで開くくらいのことまでをお世話します。ユーザーはこの結果が気に入ったら印刷するなり何なりすればよいわけです。この方法だと、帳票専用に作られたツールに比べて、ちょっとキレイさでは劣るものが出力されますが、別にそんなことを気にしないような用途だってありますし、もしそうなら、最低限、内容さえちゃんと確認できればいいですよね。作る側としても、とても安価に提供できます。 Excelがコンピュータにインストールされているなら、これを帳票ツールとして使ってしまうというのもよくある発想です。この場合、ユーザー側で思う存分レイアウトを調整して（Excelですからやれますよね）、その上で、開発者のほうでは、決まったセルの上に値をプログラム的に書き込む、という方式で、最終的に印刷に耐えるような文書ができあがります。 Excelだと、明細行がいっぱいあって１ページに収まらないときにはどうするの、という疑問をもつ方がいるかもしれません。そういうときも、うまくプログラムを作って、明細部分にあたる行を内部的に増殖させて対応できますから、こういう点で限界を感じる必要もありません。 印刷するべきフォーマットがとても綿密に決められている場合があります。国や役所のルールで様式がすっかり定められている場合など。こういうときは、PDFを直接生成するようなやりかたで帳票を作るという作戦が採用できます。PDFが普及する前はこういう精密なフォーマットの印刷はいろいろ面倒でしたが、今なら、PDFはほとんどどこでも使えます

ウェブページへの誘導をさせるために、印刷物やポスターにQRコードを印刷してあるのを見ることがとても多いです。ほとんどのスマホではこれの読み込みができる手段が準備されていますから、とても便利であるのは間違いありません。 QRコードの複雑さには種類が設けられていて、レベル1という最も単純なものから、レベル40という滅多に見ないような巨大なものまであるようです。中に入れられる情報の量がこれによって変わりますから、誘導したいウェブページのURLが長い場合は、それに応じてQRコードも複雑なものを使わなくてはいけなくなります。大きなQRは、限られたスペースに押し込めれば点の並びも細かくなり、印刷の品質によっては、読み取りを不安定にしてしまう要因のひとつになります。 だからURLは短くシンプルであることが一般的に望ましいのですが、URLをどうシンプルな形に保つかというのはそれなりの知識がいることです。現在ブラウザのアドレス欄に表示されているURLを工夫せずにそのまま使うと、余計なパラメータ情報などが紛れ込んでいる場合もあり、長さの無駄が生じてしまいます。結果、細かいQRコードが発生します。 QRの細かさに影響を与えるもうひとつの要因は、「誤り訂正レベル」をどう設定するかです。QRはとても賢く作られており、部分的に汚れたり欠けたりしていても、ある程度、自動的に情報が復元できるように設計されているのです。筆者の個人的な意見ですが、ほとんどの使い道において、誤り訂正レベルはよほど低くしても問題はないと思っています。実際に汚れたり破れたりしたQRコードなんてほとんど見たことはないでしょうし、それで困ったなんていう例も聞きません。QRに誤り訂正機能があるのは、工場などの汚れやすい環境で使っても業務が滞らないように、ということが理由だと聞いたことがあります。それ以外の利用シーンなら、たぶん完全に汚れのないQRばかりでしょう。QRをシンプルにするためにも、誤り訂正レベルは無駄に高くしないようにしましょう。 （QRコードの中央あたりに、自由なマークを貼り付けたものをよく見ます。あれは実は、QRコード的には「汚れ」に相当します。あんな邪魔なマークが混入しても、QRは残った情報からなんとか元の完全な情報を復元している、ということが、実際は読み込み時に起こっています。一見してオシャレなものに見えますが

データの処理には大きく分けて入口と出口がありますが、出口のひとつとして割とひんぱんに要望されるものが、電子メールの自動送信だったりします。 とても単純な用途ではありますが、たくさんの宛先に間違いなくメールを届けるというニーズは、今のところ尽きることはなさそうです。同一のメールをたくさんの送信先に送ろうとして、送り先とかCCの欄に宛先のメールアドレスをみんな書いてしまった、なんていう失敗談も同じくらい尽きませんが… 通常、プログラム的にメールを自動送信するときは、一通ごとに個別に送信先のアドレスを設定しますから、複数のメールアドレスがみんなにばれてしまう、ということはありません。また、1000通だろうと2000通だろうと、メッセージのコピペをミスすることもありませんから、いったん起動したあとはしばらく放っておくだけでよく、人間の労力をとても節約することができます。 （もっともっと大量のメールを送ろうとすると、場合によってはスパム業者のようなものとみなされて、インターネット側から「出禁」相当の制限を受けてしまうことがありますので、限度を見極めておく必要はありますけどね） プログラム的なメールの自動送信でさらに便利なところは、メールの文章の中身を、送る人にあわせて少しずつカスタマイズできる、というのも大きいでしょう。メールの冒頭に「○○さまへ」という前文がついているだけでも、ちゃんとその人に向けた特別なメッセージに見えるものですし、本文中にも、その人ごとに、現在のポイント数とか、その人向けの星占いとか、いろいろ混ぜ込むことができたりします。その人向けの添付ファイルをくっつけて送る、なんていうこともできるでしょう。 メールソフトによっては、もともとこんな機能を備えているものもあるようです。または、初期状態ではできなくても、追加機能としてこんな機能を付け足せる、なんて仕組みをもつメールソフトもあります。どの場合も、たぶん「メールマージ（Mail Merge）」という名前がついているのではないかと思うので、ネットでこういった機能のことを調べるときにはこの用語を覚えておくとよいです。 メールの一括自動送信の機能を提供するときに筆者が意識するようにしているのは、「カラ撃ち」モードが選択できるように、という点です。つまり、実際にメールの送信までは行わないのだけど、どういう宛先にどうい

 MS Accessはとても便利なアプリケーションで、クエリーという機能がその便利さのけっこう大きな部分を占めます。 「テーブル」と呼ばれる表にデータを蓄積させておいて、それを、あらかじめ決めたルールでフィルタし、ソートし、グループ化して値を合計し、他のテーブルと結合し…　という感じに自由に加工して表示させるという機能がクエリーです。この加工ルールをレシピとして保存しておき、それを必要なときに呼び出すと、表示したときの見た目はテーブルとほとんど変わらないのに、テーブルに入っている実際のデータをいつでも反映したものが得られます。すこし使い慣れてみると、これだけでもきわめて便利なものだと分かります。 （クエリーには追加クエリーや削除クエリーという別機能のものもありますが、今は省略。） ちょっとだけ加工のルールを変化させたクエリーが欲しいときは、一般的には、いったんクエリー定義のコピーをつくって、それに調整を加えて新しい名前をつける、とするのをよく見ます。クエリーの定義を増やさずにうまくやる方法もあるのですが、そういうのはすこしコツがいるので、ついついたくさんのクエリーを作りすぎるというのは、Accessにおける「あるある」でしょう。 「テーブルとの結合」というデータ加工の方法をさきに挙げましたが、これは、Excelでいう「VLOOKUP」をご存じならすぐ分かるものです。例で言えば、あるテーブルには商品コードが入っていて、別のテーブルには商品コードと商品名が入っているとします。このときに、もとのテーブルの内容に、対応する商品名を付け加えて表示させたいときに力を発揮するものです。この場合、ひとつのクエリーが、複数のテーブルに依存したものになります。 クエリーの表示結果はテーブルと変わりない見た目だ、と言いましたが、そのおかげで、あるクエリーの結果を使って他のクエリーを作る、ということさえ可能です。このために、クエリーを材料にした別のクエリー、というものも増殖しがちになります。 クエリーをもとにして別のクエリーをつくり、それはまた別のクエリーの材料になり… かくして、最終的にできあがるかもしれないクエリーは、とてもたくさんのテーブルがクモの巣のように絡みついた、恐るべき複雑さを持ったクエリーになる、というのが、意外と冗談でなく、起こることがあるのです。プロジェクトの中にリスト

MS Accessを使って何かの情報システムを作ろうとしたときに、変に「仕上げたい」という欲望？を感じさせることがあるようです。 Accessは、WordやExcelなどと同様、色々な機能がメニューバーやサイドバー、またフォームのフッター部などに配置されており、必要なときにそれらの機能を便利に呼び出しながらデータ操作などを行えるようにできています。 ですが、これらを一切表示させたくない、という要望を述べられることが、経験では意外と珍しくありませんでした。 あるAccessプロジェクトを起動すると、特定フォーム以外の操作が一切できないような（モーダルって言います）状態の初期画面が自動的に現れ、そこで必要な機能を実行するためのボタンを押す。すると、その次に出てきた画面もモーダル設定になっており、そこで許された操作以外を行わせない。そんな作りに、あえてしたいというのです。 しばしば、帳票の印刷ボタンがそういったフォーム上に配置されており、サイドメニューから帳票を選んで起動するだけで本来足りるのに、専用のコードが書かれたそのボタンを押して帳票を印刷するという操作しかさせてもらえない。なんなら帳票はプレビュー表示を飛ばしていきなりプリンタに送られてしまうよう「自動化」されており、いったん画面上で確認するということが許されない。そんな例もあります。 データ入力フォームも、本来ついている入力内容反映ボタンや編集キャンセルボタンをあえて隠して、専用に配置したボタンを押すことでしかそれが実現されないか、あるいはそういった操作自体が許されなくしてほしい、とも。TABキーで入力枠のフォーカスが移ることさえ禁止させてほしい、なんてこともありました。 まるで、Accessのいくつかの機能を禁止して、同じような機能、しかも劣化版を別途に作り直しているかのようです。 意図しない操作をユーザーが行うことで、本来設計したデータ操作のフローを乱してほしくない、というのが、たぶんこういう作りにしたいときの動機なのでしょう。想定した操作だけをしてほしいし、それ以外のことをやってエラーを起こしたあげく、開発者のせいにされたくない、ということですね。 使う側のユーザーにとっても、なにやら「よく仕上がった」仕組みが実現したように思えて、なんなら最初は満足感を感じることもあるようです。 筆者は、できるだけAcce

Microsoft Office製品の中で、WordやExcel、あとPowerPointの使い方なんかは割と分かっても、Access（アクセス）を何に使うの、ということをズバリ答えられるひとはそんなに多くありません。 データベースを扱うアプリケーションなんだよ、と説明されても、それだけではやっぱり分からないかもしれません。マス目にデータを入れる仕組みであることはなんとか分かるし、Excelと似たようなものかなあ、くらいの感想なら出てきそうですが。 Accessをうまく使いこなすと、ちょっとした情報システムならこれだけで作ってしまうことができます。ほどほど器用にデータ入力の画面をこれで作ることができますし、ほどほど高性能なデータベースの機能（数百万件のデータなら余裕）も持っていますし、ほどほど表現力のある帳票出力機能もあります。Windowsのファイル共有を併用すれば、データ入力や編集を複数のコンピュータから行うことが可能なので、何人かで協力してデータを整備していく、という仕組みも作れるようになっています。 それに加え、データベースの中身をどのようにフィルターして並べ替えたいか、またはどういうデータをグループにして数字の合計を見るか、というレシピをあらかじめ作っておき（クエリーっていいます）、これを呼び出すことで、いろいろな側面からデータを確認したり、集計表をすぐに作ったりできます。 こういった機能をうまく設計して組み合わせれば、業務で使いたいデータ管理にはこれだけでも充分だ、となることも結構あるのです。 Accessには、その内部で自作のプログラムを動作させるという機能もあります。VBAという言語でこれを書くのですが、これが、入力フォームに入力された値に反応して動作したり、ボタンが押されたタイミングで動作したりします。このプログラム部分には、業務固有のデータ操作ルールを書いたりすることになるでしょう。データ全体の締め処理みたいなものも、VBAで書いてしまうことができます。ここまでやれれば、いよいよ広い範囲の業務をカバーすることができますね。 WordやExcelの親戚程度のものかな、と思いきや、Accessは、フル機能に近い情報システム開発ができるアプリケーションだったのです。 Accessは長い期間をかけて機能を成熟させてきていますので、安心して使えるソフトウェ

 情報システムをつくる際、利用者からの要望を聞きとっていると、ともかく色々なデータ出力形式に対応できるようにしてくれ、という話になりがちだったなあと筆者は記憶します。 出力形式、と固めに表現してみましたが、もっと具体的に言い直せば、帳票やラベル印字の形式とか、どこか他のシステムに投入するためのデータフォーマットのことです。とくに帳票なんかは、公機関で定められたようなフォーマットがたくさんあるために、ユーザー側の選択次第でどのフォーマットにも正しくデータが転記できる、という仕組みを作ることを求められます。 それらの出力形式のうちいくつかはとても頻繁に使われ、いくつかは年に数回の出力頻度だったりします。また、ちょっとしたルール改変でフォーマットに微妙な変更があると、そのつど、それに対応するためのカスタマイズが発生します。 大きな基幹システムのイチ機能、としてこれらの出力機能を捉えるなら、これらはみんな、そのシステムの改修あるいはカスタマイズということになり、たぶん大きなコストを払わされることになります。開発業者の側としても、もとの大きなシステムと同じようなサポートをこの改修部分に対しても行わないといけませんから、当然、それなりの費用を請求せざるをえないのです。 もしも、利用者側のほうで、基幹システムからはそれなりに再利用できるデータだけを得られればいいよ、といえるのなら、今挙げたような悩みはかなり軽いものになります。基幹システムとは別に、データの利用方法のひとつとしてユーザー側で勝手に工夫するから大丈夫、と考えることができるなら、そうなるでしょう。ちょっとした印刷位置の修正や文言部分の修正とか、年号が変わったのでそこらへんの対応をするとか、そういった微調整の自由を得ることができるわけです。 「いいや、ユーザー側でそんな器用なことはできないよ」という意見がすぐに聞こえてきそうです。もちろんこれもその通りで、できないからこそ、実装業者にこれを作ってもらっているわけですもんね。 ユーザー側で帳票作成くらいの作業ならできるかも、という幸運なことも、時にはあるかもしれません。実際のところ、ちょっとしたプログラミングができるなら、データを帳票や別形式のデータに変換するようなことは、多少のセンスがあればやれる程度の仕事だと筆者は考えます。ただし、その器用な人物がいなくなったあとで、誰

 コンピュータによる情報処理を自動化したいというニーズは業務のあらゆるシーンにおいて発生するものですが、それをシステム屋さんに伝えるときには、どのくらいの自動化をしたいかを意識するとよいと思います。 よくある傾向として、「人間が何もしなくても勝手にいろいろいい感じに処理されていてほしい」という要望になりがちですが、これには危険も伴います。 自動化を達成するためには多分なんらかのプログラムを作ることになるでしょうが、それの作りが完璧とは限らない、というのが、残念ながら、前提とすべき事実です。たいていの場合は期待通りに動くかもしれませんが、時々、なにか特別な条件では期待と外れた動作をしてしまう、というのも決して珍しくはありません。プログラムを書く際は、色々な例外的パターンを予想しながら、どんな条件でも適切に対処して動くように努めないといけないわけですが、それにしても、起こりうるあらゆるケースをすべて想定し、あらかじめ全て対応しておく、というのは現実的でないコストがかかりますから、とりあえず、確率は低くても、なんらかのエラーが発生するかも、という覚悟はしておくのが普通です。 何もかも人手を介さない自動化、というのは、途中でなんらかの予想外が起こってしまったときに、「そのまま、プログラムにしたがって行程が進んでしまう」という危険につながります。プログラムが異常を検知して終了してくれるならまだいいのですが、単に先に進んでしまう、ということだってあるのです。 たとえばAさんに最終的に10,000円の入金を行うような自動化プロセスがあったとして、その途中、今までに予想もしなかったような原因で、Aさんに入金されるべき金額は10,000,000円である、という計算結果になってしまったとします。それを、人間があらかじめ目を通して「あれ、これはなんだか異常だぞ」と気づけば、少なくとも本当の入金が起こってしまう前に修正を行うことができそうです。入金額を計算するという自動化と、実際に銀行と通信して本当に入金を行うという自動化が完全にひとつながりになっていた場合は、人間がこれに気づくチャンスを減らしてしまいます。コンピュータに「一千万なんて入金、常識で考えれば変だと分かるだろう！」とあとで詰め寄っても仕方がありません。 コンピュータが、ある段階で「これからこういうことを行うつもりだが、人間よ、

コンピュータを使うために必ずプログラミングが必要になるということはありませんが、同じような作業を何度もマウス操作＋キーボード操作で行うのは、うっかりした間違いを起こすことが多いでしょう。間違えずに同じような操作を確実に行いたいなら、プログラミングによる自動化がうってつけの分野です。 まったく同じ操作を繰り返すばかりでなく、扱うデータの特徴にあわせて、少しづつ異なる操作をする、というときも同じです。そこに法則やルールさえ存在すれば、それにあわせて操作を自由に変えられる、というのはプログラミングのいいところです。 最近は、プログラミングのための道具がとても充実しており、覚えるべきことは最小限にして、すぐに高度な自動化を達成することができます。すこし調べるだけでたくさんの作例を見つけられますし、AIが記述を手伝ってくれる、なんてことさえ期待できるようになりました。もちろん、本当にうまくこの仕事をこなすにはそれなりの経験や熟練が必要になるのですが、ともかく思い立った時にすぐ試してみることができるというのは、たいへんよいことです。 さて、「プログラミング」とさきほどから連呼していますが、本格的なプログラム言語は、実はほとんどの場合必要にはなりません。 ここで「本格的」と呼ぶのは、コンピュータの根幹にまで分け入って動作を制御できるようなもので、これを使えばある意味「なんでもやれる」プログラミングが達成できます。C言語なんかがその代表格で、一般に、記述すべきプログラムは複雑で大量なものになりがちです。それだけ、プログラム作成に意図しない誤りを混入させやすい、という特徴にもつながりますし、「なんでもできる」プログラム言語は、別にいいことばかりでなく、長所も短所もあると知っておきましょう。 また、基幹系の大きなシステムにおいても、「本格的」プログラム言語が使われている可能性があります。高速な動作を期待されることが多いですから、こういう場合も「本格的」の出番だったりするわけです。 本格的なものに対して、もっと簡易的なプログラム言語が存在します。 「簡易的」だと、作るのが簡単で短い一方、やれることは限られているし、動作も、極めて高速とは行きません。一般にこういうプログラムは「スクリプト」とも呼ばれがちです。でも、冒頭に書いた「似たような操作を何回も繰り返す」というくらいの用事なら、きわめ

長年、さまざまな情報システムについて、色々な側面から関わってきました。開発業者として要件ヒアリングから設計・実装、運用サポートまでのすべてを経験しましたし、また、システムを利用する側としても、どんな業務をシステム化したいのかという話を聞くところから始まり、それを具体的な要件にまとめ、実装業者を呼び、予算や時間のことを考慮しながらシステム化の範囲を調整し、実装内容をチェックして検収し、操作担当者に使い方を教えてサポートする、という、かなり多くのシーンを経験してきたと考えています。 端的には、システムを作るほうと、システムを作らせるほうの両方を見てきた、とも言えます。 そういう経験の中には、システムを作って納品まで完了した（された）のに、結局まともに運用ができずに終わってしまった、という例もあります。システム全部が使われない、なんてのはやや極端ですが、システムの一部として作りこんだところが、あとでよく聞いてみると実はちっとも使われていない、というくらいのことなら、案外珍しくありません。 また、そういう「使われなかったシステム、使われなかった機能」に限って、ずいぶんと時間をかけてたくさんの人間が検討に加わりながら仕様を作っていたり、どたん場になってから、やっぱりこういう動作をするよう直してくれ、という注文に応えたりしながら作られている、ということがありがちでした。 システムが使われなかったという例とはすこし異なりますが、システムの利用が担当者にとって苦痛であるという例にも遭遇したことがあります。誤入力ですぐに内部的な故障が発生する、間違ったボタンを押したことでデータ破損が起こる、または単純にデータ入力のための操作が煩雑すぎる、などなど。人間がコンピュータを使いこなしているようには到底見えず、その逆が起こっているかのようです。 こんな不幸を、少なくとも自分の手の届く範囲では起こしたくないものだなあ、といつも考えていました。 個人的な規模の取り組みでは、いわゆる基幹系と呼ばれるような巨大な情報システムをコントロールすることは簡単にはできません。ただし、そこへ入力するデータを整えることや、そこから出力されるデータを要領よく活用する、という形でなら、日々の苦痛を軽減することもできるし、時には、今まで簡単でないと思い込んでいた仕事を思いがけずうまくやれたりもします。 そんなわけで、