仕事のメモ・共有版

離れた場所にいるかたに電話でトラブルシュートを頼まれるときは大変です。相手の画面は見えませんが、なんとかして、その現場で何が起こっているのかを理解しないといけません。直前に行った操作は何かを思い出してもらい、今の時点で読める場所を読んでもらい、どんなボタンが押せそうか、どんな枠になら入力ができそうか、という手がかりも聞きながら、状況を頭の中で再現していくという離れ業が必要になる場面です。必ずしも的確な言葉で説明してもらえるとは限りませんから、そんなときはスクリーンショットを取得して、それを共有してもらうのがよいです。 電子メールでも、ビジネスチャットでも、スクリーンショットとしてクリップボードにコピーされた絵を、そのまま貼り付けボタンなどで貼り込むことができる場面が増えました。かつては、スクリーンショットをExcelシートなどに貼り付けて保存、これをメールなんかに添付する、というのが最もありふれたスクショ共有の操作でしたが、今はこの手順が大幅に短縮された形です。 また、画面の一部をスクショすることも簡単になりました。[PrintScreen]ボタンを押したときに、ちょっと昔は、画面全体のスクショができあがってしまうだけでした。これとは別に、ウィンドウ単位のスクショっていうのもありましたが、そんなによく使われるわけでもなく、また、結局Excelに貼り付け直すという手間は同じです。 最近だと、スクショのショートカットキーを押すと、画面のどこからどこまで、という、四角い枠が選択できますね。[Win]+[Ctrl]+[S] キーの組み合わせで。これで、無理なく見せたい範囲だけを選ぶことができます。これを、メール作成画面や、チャットの発言欄にペーストすれば、電話なんかであれこれ聞くよりも手っ取り早い、正確な状況報告の完成です。OS側の改良と、アプリケーション側の改良がそろったおかげで、こういう芸当が一瞬でできるようになりました。よほど多くの人々がこれを待望していたという証拠ですね。 それを見て、どんなトラブルだったのかがいよいよ分かったぞ、となれば、次は、問題を解決するために、ここを操作してこんな状態にしてください、ということを教えてあげる番です。これも、便利になったスクショの機能を活用すべきところです。特に、こちらからスクショを共有するときは、赤線なんかでココですよという点

ある業務を、自力でなんとか自動化してみるということはよくあります。別に職場全体に波及してほしくてやるわけでない、自分を楽にすることがもっぱらの動機であるような、個人発の手作り自動化です。Excelシートにちょっとした関数やVBAを仕込んでみるところからはじまって、それがうまくやれるようになって楽しくなると、pythonとかrubyとかそういった処理系をインストールしてデータ処理をプログラムしてみたり、今までは何に使うのかさえ知らなかったAccessでクエリーを組んでみたり。今だとRPAのツールなんかも持ち出して、マウス操作やキーボード入力をシミュレートするような面白いワザを使ってみるなんてこともあるかもしれません。 それらは素晴らしい工夫ですし、そんな感じに草の根から成長してきたIT者（モノ）がたくさん世に出て活躍してほしいとも心から思いますが、時々起こる問題として「うまく引き継げない」というトラブルがある点には注意が必要です。 その人がいつまでもそこのポジションで同じ業務をするわけではありませんから、きっといつか、今までやっていたことを誰かに任せないといけなくなります。そのときに、作り上げた仕組みが「ブラックボックス」になってしまっていると、色々と困った事態を巻き起こしがちです。おそらく試行錯誤しながら完成に近づいていったのでしょう、作り込まれたものの設計情報はそもそも存在しなくて、書かれたロジックは各所の連関が不明確、必要なときは何を直してよいのか、何を直してはいけないのか、そういうことが分からなくなっているのです。結果として、そこの仕事には変化を加えることができなくなり、ちょっとでもインプットされる情報のルールが変わると、予想できないエラーを起こしてしまう、といった不自由な状態になってしまうかもしれません。 プログラムを試行錯誤しながら作れるようになる、という段階から、メンテナンスに困らないようなドキュメントが整備できる、という段階に至るまでは、意識的な修練が必要です。そのため、前者の段階でいろいろ自動化を作り込んでしまえば、ブラックボックス化の問題を起こす見込みが高くなってしまうわけです。職場の全員が等しくテクノロジーに強くなる、という理想的な話でもあればよいのでしょうが、さすがに現実的ではありません。どうするのがよいでしょう。 筆者がかつて意識したのは、「

ハッシュ（一方向ハッシュ）って何、と聞かれたら、まずは「チェックサムのすごいやつですよ」 と答えることにしています。もちろん、それでピンと来ないようならもうすこし改まった説明を始めますが、「ああ、チェックサムね」と拾ってくれるようなら話がすこし早くなるな、という気持ちからです。 チェックサムとかチェックデジットと呼ばれるものは、一定の長さの数字とか記号の集まり（文字列）が誤って入力されないよう、記号全体のうち1桁とか2桁を、他の記号の「足し算」の結果にしておくという仕掛けです。ただし、単純な足し算ではなくて、どの桁は7をかけてから足す、とか、どの桁は13をかけてから足す、とか、ちょっと工夫されたルールになっていることが多いです。また、数字でなくて文字の場合は適当なルールで数に換算する、とか、チェックサムの桁があふれたときにどうするか、とか、まあ色々あるでしょう。ともかく、クレジットカード番号など、入力されたなんらかの文字列があったときに、それがそもそも存在しうる番号なのかどうかを簡易に判定して、あらかじめ誤入力とかイタズラ入力を防ぐことができるというわけです。（16進ダンプをモニタで入力するときの誤入力も防ぐことができる…　なんて思い出もありますが、これは特に説明を加えません。分かる人にだけ通じればよいです） ハッシュというのは、もっと、入力ミスがあったときに厳密にそれを見つけたい、というときに使われる技法です。チェックサムならせいぜい2桁の数とかですが、ハッシュは、すこし古めのMD5という計算法でさえ、10進数で39桁くらいの巨大な「チェックサム」をつくり出します。2桁のチェックサムなら、たまたま誤った入力が「正解」のチェックサムを偶然出して、有効判定をもらってしまうことが可能ですが、39桁の巨大な数なら、まず「かぶった」チェックサムになる誤入力はありえないだろう、と容易に予想できますね。 ハッシュを計算する対象は、クレジットカード番号みたいな10数桁のデータだけでなく、大きなファイル全体、という場合もよくあります。数ギガバイトみたいな巨大なファイルでも、本質的には一つながりの長い数字と変わらないのですから、全体のチェックサム（ここではハッシュ）を計算できるのです。大きなファイルのハッシュは、ダウンロードが正常にできたかどうかの判定なんかに便利です。 ハッシュの計

普段、ウェブサイトを巡っていて、何の気なしにHTMLソースコードを眺めてしまうことがあります。（参考までに、Edgeでのショートカットキーは [Ctrl+U]） ここで表示されるのは、普通の人にとっては意味の分からない記述の羅列ですが、ウェブブラウザにとってはこちらのほうが本質的な情報で、ここで指示された内容をもとに、表示内容の整え（レンダリング）が行われているのです。また、JavaScriptというプログラム言語で内部的な動作が記述されている場合もありますが、そういうものもすべてHTMLに混じって表示されます。 通常の仕事で簡単なHTMLを書く場合は、そこらへんの商業サイトのような複雑さのものはまず必要とされませんが、それにしても、時々は面白い記述や参考にしたくなる部分も見つかりますし、特段のコストもかからない操作ですので、つい指が動いてソースコードを眺めます。缶ビールを飲んだりお菓子を食べたりしているとき、なんとなくラベルの細かい部分とか原材料表示をまじまじ眺めてしまうのに心理は近いかも知れません。 最近はウェブブラウザも先進的になったおかげで、HTMLを眺めるだけでなく、もっと見やすい形で整えられた情報にもアクセスできます。[Ctrl+Shift+I] などのショートカットキーで、開発者コンソールという情報パネルを表示できる場合があります。ここで、単に「生の」ソースコードではなく、これが実際に表示に整えられるまでの中間形式みたいなもの（DOMと呼ぶときがあります）を眺めることができます。相当に複雑な表示がされるツールなので、一般の方々には親しみようがないものですが、これも、分かる人にとっては、ウェブページの内容を見ているのと同じくらい楽しいときがあり、ちょっとした勉強もかねて、こういうところを探検したりするものです。傍からは、まるで、何かのツールで悪いことでもしているかのように見えてしまいがちですが、まったく違法性はない行動ですよ。ウェブサーバーから公開された情報を「見る角度」がちょっと違うだけのことなので。 同じように、届いた電子メールを読むときも、時々、なんとなくエンベロープ情報（メールの細かい処理記録みたいなものです）を眺めてしまいます。知らないヘッダー項目なんかを見つけたときに、ふーん、これは何だろうなー（調べないけど）、くらいに軽い気持ちで見るだけで

今は、ウェブ上に入力用画面を表示して、不特定の回答者から色々なデータを書き入れてもらって集める、ということがとても楽になりました。いわゆる「ウェブフォーム」というサービスを活用することによってです。MicroSoftも、Googleも、簡易なフォーム作成サービスを提供してくれており、また、もうちょっと高機能なものを安価に提供してくれるような専用のサービスもあります。やりたいことにあわせてサービスを選んで、必要な項目をセットするだけで、即、入力用フォームのできあがりです。 「今は」と言ったのですこし昔の記憶も挙げておくのですが、かつては、ウェブサイト作成用サービスで、「動的コンテンツ」を手作りする機能が入っているようなものがありますから、それを借り、そこに手作りのプログラムをアップロードして、望む動作をさせていました。「CGIスクリプト」と呼ばれていた種類のプログラムです。「phpスクリプト」のときもあるかもしれませんが、なにしろ本質はそれほど変わりません。完全に手作りをする腕前があればそうやってスクリプトを作り、そうでもない場合には、やりたいことにあわせたスクリプトを配布してくれているサイトが当時はよくありましたから、そこから借りてきて、試行錯誤でカスタマイズしながら、最終的に臨む機能に近づけていました。 （もちろん今でもウェブホスティングサービスでCGIやphpが動くものがたくさんありますが、昔はそれくらいしか選択肢がなかった、という話です） 手作りでこしらえたり、あてずっぽうでカスタマイズしたスクリプトは、たくさんの弱点を残しがちです。悪意の加工を加えて入力された内容におかしな反応をして、他人の入力内容が流出してしまったり、もっと悪い場合には、サーバーの機能を乗っ取られてしまうようなことも起こりえました。個人の趣味でやるような場合はともかく、ビジネスのためにこういうスクリプトを利用する場合は、やろうとしていることを完全に理解して、注意のうえにも注意を重ねるくらいの姿勢が必要です。 さきに「楽になった」と言ったのは、全体的な労力が減るということもありますが、それに加えて、思わぬバグでトラブルを起こさないだろうか、という心配をする必要がとても少ないという意味での「楽」でもあります。専用のサービスを使って作成したウェブフォームは、すでに何千、何万という顧客に対して安全

プログラムを書いてなにかを自動化しようとするとききは、正常な動作だけでなく、異常があったときに何が起こるかもあらかじめ想定します。何の異常も起こりえないほど理想的な制作ができるのが理想ですが、必ずしもそうはいきません。何より、このプログラムに何を入力されるか、どんなデータが与えられるか、といった条件は完全にはコントロールできませんので、どんな場合においても、なんらかのエラーが発生する想定は欠かせません。 数字であるべき場所に数以外の文字が入ってきた、というのが例えば予想されるエラーですが、こういうときにどう振る舞って欲しいかは、そのプログラムで自動化した仕事がどういう性質のものかによります。たぶん、許されないデータを検出した時点で、「このデータにエラーがあるので、前の段階からやりなおしてください」といったエラーメッセージを表示して、実行が中断されてしまうべき、というあたりが最もありそうなところです。データの中でもそれほど重要でない部分なら、代わりにゼロが入ってきたものとみなして処理を続行する、なんて対処も、候補に入るかもしれません。 他にも、結果を出力しようとした場所がすでに容量オーバーだとか、作業中にメモリがいっぱいになってしまうとか、通信すべき相手が返事を返してくれないとか、あらかじめ何もかも想定しておくには困難なくらいに、色々な種類の異常が起こりえます。また、実行した人がこれを無理矢理「閉じるボタン」で終了させてしまう、というのもありえます。ともかく、こういった状況が起これば、プログラムはやむを得ず終了するのですが、そのときにも、あとで回復するときに困らないように設計しておくよう努めています。 異常な終了をしたせいで、すでに正常に作られたデータが巻き添えで消失してしまった、とか、データベースが中途半端に更新されて不整合な状態になってしまった、とか、最悪のパターンではデータベースが壊れてしまった、とか、そういうのが起こることを避けないといけません。「倒れるかもしれないけど、最悪ではない方向に倒れるようにしておく」ということです。そういうことを実現するための実装上のテクニックが色々と存在するのですが、こうすれば万全、みたいな公式があるわけではないので、何が起こりうるか、何が起こったら困るか、というのをよく想像しながら設計することが必要となります。 ちっとも関係ない

ショートカットキーを使いこなす人は案外少ないんだな、と思ったことがあります。それがいいとか悪いということではなくて、マウス操作でメニューをクリックする、という操作が直感的で充分に便利なので、一度それに慣れたら、特にそれ以上の操作性を求める必要がないのかもしれません。 とはいえ、一般的に最も使われる、コピー（Ctrl+C）と貼り付け（Ctrl+V）は、定番中の定番とも呼ぶべきショートカットなので、ぜひ一度は使ってみてください、とオススメすることがあります。どんな種類の作業をしようと、幾度となく使うことになるはずですので、時短効果がとても高くて、習得するコスパは最大級でしょう。 しかし、そのほかのショートカットキーは、別に無理に覚えなくてもよいと考えています。筆者自身は色々なアプリでショートカットキーを時々使いますし、それが作業の時間を実際に短くもしていると思っていますが、それでもなお、無理に使うほどのものだとは思わないです。正確には、わざわざあらかじめ暗記するまでもない、と言い換えたほうが正しいでしょうか。 でも、改めて調べてみると、アプリケーションひとつについて、相当にたくさんの機能が、ショートカットキーで使えるようになっているものです。これはメニューバー（アプリの上部に並ぶ、階層状に並んだ機能一覧）がもともとそういう機能をサポートするように設計されているからで、アプリを作る方としては、ひとつひとつの機能に簡単にショートカットキーを割り当てることができるからです。 たとえばよくある例としては、適当なアプリで、「ファイル」のメニューから「ドキュメントを開く」みたいなサブメニューがあるか、探してみてください。もしあれば、そのメニューの表示の端に、「Ctrl+O」みたいな表示も並記されていませんか。余裕があればそれを覚えてしまってもいいですが、さしあたって忘れてもよいです。いつでもこんな感じに調べられるのだな、という実感を得ておくことがむしろ大事です。今後、すごくたくさんドキュメントを開いたり閉じたりしなくてはいけないような機会が来たら、そのときに「いちいちマウス操作はだるい、ショートカットキーで楽したい」という具体的なニーズを感じるでしょう。ここではじめて、「Ctrl+O」を改めて調べて、これを活用して楽すればよいのです。ここでは例を挙げませんが、きっとドキュメントを閉

プログラムを書くという作業は、小さな命令の部品を並べて組み立てていく作業です。ひとつひとつの命令でできることは、ほとんどの場合とても単純ですから、それらが全体として何か人間に役にたつような動作をしてくれるようになるまでは、たくさんの記述が必要です。 ただし、普通は、命令のひとまとまりに「名前」をつけることができるもので、こうすると、ここはもとの命令をいちいち全部書き直さなくても呼び出せる部分になります。 三角形の面積を出すために、底辺の数値に高さの数値をかけて2で割る、という処理をあらかじめ命令の組み合わせで作って、それに「三角形の面積を出す」という名前をつけておけば、次からは、三角形の面積を出すためにいちいち同じ計算式を書く必要はありません。底辺と高さはいつも違う数値でしょうからそれはパラメータとして与えることにして、あとは、その「できあいのやつ」を呼び出せば、いつでも三角形の面積がだせるという具合です。 つぎに、三角錐の体積を何回も計算する必要が出てきたとします。すでに三角形の面積を出すのは「できあいのやつ」を活用してやれることが分かっていますから、それは再利用することにして、あとは錐の高さをかけてから3で割れば、三角錐の体積のできあがりです。この計算過程にも名前をつけておけば、今度から、三角錐の面積を計算することも楽になるでしょう。 この例はきわめて単純なものですが、もっと仕事レベルの複雑なものでも、本質は変わりません。すでに準備されている「名前のついた」処理のカタマリがあって、それを順番に実行することで要望を実現していったり、ときにはその順番通りに行う処理のカタマリそれ自体にも「名前」をつけて、同じような仕事をさせる必要があるときにもっと楽ができるようにしたり、と、そういう工夫を繰り返していくのです。楽さが積み上がっていきます。 どこかのアニメで、主人公の少年が、手元のコントローラーに向かって「戦え、鉄人！」みたいなことを叫んで、それに反応して大きなロボットが敵を殴る、みたいな場面があったとします。昔はああいうシーンを見て「そんなあいまいな命令で都合よくやれるもんか」と笑ったりしたものですが、今になって考え直してみれば、あれは「音声による命令を認識する」という小さいプログラムと、「周囲の文脈から、もっと細かい指示を推測する」という小さいプログラムと、「視覚情

データを入力させる画面で、どのくらい入力内容の形式を強制できるかは、それに対応したプログラムを書くことで調整できます。 ごく当たり前な例では、データを必ず入力させる、という強制。名前とか、メールアドレスとか、そういう部分に内容を書き入れずに提出ボタンを押しても、ここが足りませんよというメッセージを出して再入力をさせる、なんていうのを、日常的にとてもよく見ます。 また、内容を書き入れるにしても、数字であるべきところにアルファベットが入っているようなとき、あとで処理エラーを起こすのを防ぐため「弾かれる（入力を拒否される）」ようになっていることがあります。年齢を聞いているのに、AとかBなんて文字が入っていては困りますもんね。これの発展で、たとえ数字でも、常識的な値を入れてくれないとだめ、という制限もあり得ます。年齢が150歳を超えていたら、普通そんなはずがないでしょう、という感じにエラーを起こして受け付けないようにもできます。 生年月日を入力させるときに、あらかじめ準備された選択肢からしか入力させませんよ、という強制方法もありますね。マウスで触るとドロップダウンするようになっていて、1900年から2024年現在までから選ぶしかない、という具合です。同様に、月も1から12まで、日も1から31までしかそもそも選択肢が準備されていないでしょう。ただし、ここまでやっても、存在しない「11月31日」みたいな入力ができちゃうことがあるかもしれません。小の月のときは30までしか選択できない、とか、うるう年以外のときは2月28日まで、そうでなければ2月29日まで…　などと、ここらへんを凝り始めるとキリがなくなってきますが、でも、ここが正確であることが業務上重要なことだったら、ちゃんと完全に対応すべきですね。 数字であるべきところに「全角文字の数字」が入力されていたらどうするの、というのは、システムによって対応方針はまちまちです。「全角」と呼ばれる種類の、普通より幅広な英数字の文字があるんですが、これは内部的には普通の数字ではないのです。「全角はだめですよ」というエラーメッセージを出して入力させ直すのもいいですが、全角から半角への変換はルールに従ってやれますから、わざわざエラーで突き返さず、自動的に半角の数字に直して扱ってあげる、ということも可能です。こういう気遣い機能のためには、ちょっぴ

自動化で楽しよう、というのは、データ処理みたいなものにしか使えないワザではないです。キーボードで打ち込んで実行するようなコマンドライン、あれの生成を補助するなんていうのもアリです。 コンピュータの操作って、マウス操作でやるようなことばかりではないですよね。黒い画面に白い文字で命令文をなんだかポチポチ打ち込んで、Enterキーを押して実行、みたいなパターンもあります。急に手慣れた玄人っぽく見えるあれです。白い文字じゃなくて、緑の文字だったりすると、もはやちょっとしたハッカーみたいな気分でしょうか。まあ、そこまでいうのは大げさですが。 ともかく、システムを管理する際に、必要に応じてこういうコマンドライン入力が必要になるような場面は、時に避けがたいものです。そして、そこでのコマンド実行、特に、システム上に強力な変更を加えるようなコマンドの実行は、たいへんに緊張するのが普通です。打ち込んだコマンドラインにちょっとでもミスがあれば、運が良くて単に動作しないだけ、運が悪ければ、なにか想定外の動作をしてしまって、システムを壊したりする原因まで作ってしまいかねません。 こういうのを少し楽にする方法として、打ち込むべきコマンドラインを自動で作ってもらい、それを入力欄にコピー＆ペーストする、というのもあります。そのつど変わる部分（パラメータっていう時があります）はどこかフォーム上にでも打ち込んで、必要なコマンドラインをそこから導き出してもらうわけです。こういうのを「自動化」の一例と呼んでも、一応いいんじゃないかと思いますがどうでしょう。 そんな間接的な方法じゃなくて、ボタンをマウスクリックしたら、その場でそのコマンドラインを実行させちゃうのではダメなのかな、という意見も出ることでしょう。もちろんそういうのもアリに決まっていますし、コピペの手間もはぶいて、手数が減らせますね。それはそうなのですが、コピペ用のコマンドラインのサンプルが表示されるだけの部分をあえて自動化する、というアイデアが役にたつような場面も、場合によっては出てきます。 打ち込むべきコマンドがとても強力なもので、万にひとつも間違えたくない場合、というのがひとつ。自動生成で確実に正しいコマンドを作りたいけど、その自動生成が完璧な動作をするかどうかを無条件に信用するにはまだ実績も少なく、念には念を入れて人間が途中で目視して確か

「ファイルを圧縮する」という言葉を割と誰でも使っているように思います。なんとなく視覚的にイメージしやすい言葉なのかもしれないですね。食パンみたいな物体があって、それが、「圧縮」という操作によって、カチカチに固められた小さなカタマリになってしまう感じでしょうか。（圧縮したファイルをもとの形に戻すことは一般に「展開」と呼ぶんですが、不思議と、「解凍」という呼び方をされることが多いですね。これも、実生活に即したイメージからそう理解したくなるんでしょう…） ZIP（ジップ）という形式で圧縮するのが最近は圧倒的に主流で、他の形式を知っておく必要はあまりありません。LHAとかRARとか、実際には意外とたくさんあるんですけどね。 圧縮という操作によって、ファイルは、一般的に、より小さなサイズの別のファイルになります。これがなぜなのかを説明するのは簡単でありませんが、とりあえずは、そういう不思議なことが起こるんだなと思っておいてもよいです。または、なんとなく、「中身の無駄な部分をうまく省略しているらしい」くらいに考えても案外間違いではありません。 圧縮したファイルをさらに圧縮したらどうなるのだろう、という好奇心を感じるかも知れませんが、この場合、ファイルはそれ以上小さなサイズにはなりません。そうじゃなければ、無限に小さな圧縮ファイルが作れることになって、明らかに不自然ですもんね。 ほかにも、圧縮しても小さなサイズになりにくい種類のものが色々あります。大部分の画像ファイル、音声ファイル、動画ファイル、PDFファイル、また、WordやExcelのファイルなどなど。実は最近、圧縮して小さくできないファイルはけっこう主流だったりします。こういうファイルは、実は、内部的にすでに圧縮された形でデータを格納しているからなのです。中身の無駄がはじめから少ないってワケですね。 ファイル圧縮の操作によって、複数のファイルをひとつの圧縮ファイルにまとめてしまうことができます。内部的なフォルダ構造も保たれます。サイズが減ることよりも、この特徴のほうが利用価値が高いかもしれません。たったひとつのファイルを配布するだけで、たくさんのファイルを、ちゃんと内部的な配置もそのままに渡すことができるわけですから。電子メールにファイルを何個も添付して送ったら煩雑な感じになりますが、圧縮ファイルをひとつ添付するだけならス

ファイルの大きさについてそれほど意識したことがないという方は、もちろんたくさんいます。それほど気にしなくても、コンピュータ上でやるような文書作成や表作成には支障がありませんので。でも、扱う情報によっては、思いがけず大きなサイズのファイルが発生して、格納する場所がなくなってしまうとか、メールで送ろうとしたら失敗するとか、そういう事態に遭遇することも出てくるでしょう。 パワーポイントのファイルを編集していると、コンピュータの動作がやたらと遅くなって使いにくくなってしまうんだ、と相談を受けて、様子を見せてもらいに行くと、とても巨大な写真を複数貼り付けて使っていたせいだった、ということが割とあります。パワポ資料そのものは10ページそこそこなのに、そのファイルが100MB（メガバイト）とかそれ以上とかになっているようなら、これは何かおかしいな、という手がかりになるでしょう。 そんなとき、「いや、大きな写真なんて使ってないよ」と言われることもありますが、試しに、ワンポイントカットのつもりで配置されているらしい風景写真を、めいっぱい拡大してみると、いくら拡大しても、木の葉の一枚一枚がなおクッキリ判別できるほどの高精細な写真のままだった…　とてもよくある、オフィスでの一シーンです。パワポには写真の解像度を下げながらサイズを縮小して使う機能がありますから、そういうのをお教えすると、ファイルサイズが劇的に小さくなって、それでもなお、資料の見た目には変化がほとんどありません。PCの動作も軽く保てますし、いいことばかりです。 コンピュータの性能が上がって、大きなファイルの写真・音声・動画の資料が比較的に楽に扱えるようになりましたので、普段それらの実際のサイズに気づかなくても済んでしまうのです。でも、あまり無頓着でいると、必要以上にたくさんのハードディスク容量を消費することになってしまいますし、複数人で共有して使うような格納場所があるようなときも、より大きなサイズのストレージ装置でないと足りなくなり、余計な予算がかかってしまう、といったことも現実に起こりえます。 時々、扱っているファイルのサイズを見て、「こういう種類のファイルは大体こんな大きさになるのが普通なんだな」と思っておくクセをつけると、コンピュータを扱うセンスが向上する…　と思います。あんまり神経質になって何もかも確認する必要なない

伝票番号や、その他の番号などをつくるときは、前もっていろいろなルールを検討するものです。 たとえば、桁数（文字数）をそろえるべきか、そうでもないか。何かの注文を受けたときに発行する伝票番号みたいなものは、あとで決まったフォーマットに印字するであろうことを考えて、桁数を一定にしておくことが多いです。また、その番号の一部分には年月日のような情報を混ぜておくことで、あとから、どの時期の伝票だったかが見当つきやすいようにしておくと便利なことがあります。伝票データの一覧を伝票番号で並び替えたときに、意味のある順序に並ぶようにしておくためにも、年月日が決まった位置（先頭なことが多い）に入っているというのは悪くありません。 桁数が一定でないような番号をつけることはそれほどないですが、シンプルな数字を一時的な管理番号として使う場合なんかは、桁数の統一にそんなにこだわることはないでしょう。たとえば順番待ちの番号札を発行することがあるとして、それが100人以上になっても対応できるようにするには、必ず3桁に固定した番号を発行しないといけないかといえば、そうでもないです。番号札に「099」とあえて書かれているまでもなく、「99」だったとしても別になんの問題もありません。 年月日や発行順のようなものに頼らない、もっとランダムな感じの番号（記号）を作ったほうがよいという場面もあります。 お客さんに伝えて、あとでお客さん自身が情報を照会するときにもその番号を使うようなものがあるとします。ウェブサービスとかに記号を入力する用途になるかもしれません。ホテルの予約番号なんかはこういう感じですね。こういうときは、番号になにか法則を持たせてしまうと、「別の番号も試して、別の誰かのデータも照会してみちゃおう」というイタズラが可能になってしまいます。これだと他人のプライバシーを危機にさらすことになっていまいかねません。こういうケースが想定されるような使い道なら、発行する番号は、推測が不可能なものにすべきでしょう。または、伝票番号と照会番号を別々につけておく、というのも手ですね。伝票番号は年月日がくっついた予測可能なもので、照会番号は予測不可能に。 ホテル予約だけでなく、コンビニプリントに予約記号を打ち込むようなものも、この例です。あてずっぽうで何か入力しても、別のデータにたどり着ける可能性はごくごくわずかです

プログラムを書くにあたって、リファレンス（参考資料）はとても重要なものですが、それに劣らず、理由の分かりにくい不具合の原因を調べるために、適切な情報源をネット上から見つけることが重要です。 どうということのないコツではあるのですが、知っているといないのでは効率がまったく違うことがあります。出てきたエラーメッセージを、ダブルクォーテーション（”という記号）で囲んでネット検索する、これだけです。これで、個人ブログやQAサイトみたいなところが見つかり、そこで「こういうプログラムを書いた、こういうエラーメッセージが出た、こういう原因だった」という記事が見つけられる見込みがとても高いです。 エラーメッセージはほとんどの場合英語ですので、英語圏のサイトからも情報源が見つかることがあります。これらにも怯まないのが第二のコツです。筆者も英語がそれほど得意なわけではないですが、自分のなじんだジャンルの話題なら、案外書かれていることの雰囲気が分かるものですし、最近は翻訳サービスに文章の一部をコピペして、内容をそれなりに把握することも難しくはありません。ウェブブラウザの機能として、ページをまるごと翻訳させることもできるかもしれません。もしその見つけた記事に、問題を解決したあとのコードも記されていれば、その部分だけは、日本語だろうと英語だろうと読み解くことができますね。英語でさえない、中国語なんかの情報源が見つかったときも、それでも多分、要所は分かります。 プログラム言語に限らず、コンピュータを操作していれば起こるであろうさまざまな種類の動作不良についても同じです。エラーが出たら、そのエラー表示の主な部分（エラーコードが出ているようならその番号）をコピーして、クォーテーションで囲って検索。この世で自分だけが出会ったような珍しい不具合なんてめったにないのですから、ほとんど必ず、誰かの体験談にぶつかることができます。 人に相談を受けて、筆者のほうでは単にエラーメッセージを「ググって」解決策を調べてあげた、ということがとてもよくあります。そのたびに、このコツを伝えて、今後は独力でも調べられるはずですよ、と言ってあげるのですが、それでも別の日にはまた別の、ググれば答えの出ているような相談を持っていらっしゃったりします。もしかしてこれって特殊なスキルなのかもしれないな、と考えることも最近はあります。

情報システムや自動化処理を設計するにあたり、誰がどんな操作をしてこれを動作させるのか、というのを考えます。 大体の場合、Word、Excel、電子メール送受信くらいの基本的な操作ができる人に無理なく覚えてもらえるのはどのくらいか、というあたりを目安にしていますが、状況によってはもうちょっと想定レベルを上げ下げすることもあります。その現場の感覚をなんとなく把握して、できれば、そういう人たちに話をしたりしてみて考えます。「こういう操作くらいならやれると思います？」なんて直接尋ねてみることもあります。 そんなことをしなくても、考えられる限り簡単な操作にする、と初めから決めれば簡単じゃないかと思われそうですが、それがいつでもベストとは限りません。かつて「かんたんケータイ」なんてものが存在しました。あらかじめ電話番号を数個登録しておいて、そこへの発信と着信、それに加えて最低限のメール送受信くらいができる、といった割り切り機能が提供されていました。そのぶん使い始めの取っ付きはよくて、操作にも迷う余地がないので、人によってはとても向いているでしょう。でも、慣れてきたら、もうちょっと細かい点にこだわった使い方をしたくなってくるかもしれませんし、もともとこの種の機械に慣れている人なら、はじめから複雑な機能をみんな使えるようにしておいてほしいはずです。習熟度によって、「簡単であること」と「いろいろやれること」のトレードオフが発生する、とも言えます。 いろいろやれること、にこだわっていくなら、何かの機能を実行するときにいろいろなパラメータを受け入れるようにして、利用者はより様々なパターンの業務をこなしやすいように作れるでしょう。その分、操作の間違いを起こしてしまう可能性も高くなっていきますが。 逆に、簡単であることに重点を置くほど、起こることは変化の余地がなく、利用者はすぐに使い慣れることができるでしょう。そのかわり、ちょっと変わったことをするべき事態が生じたときには、システム側で融通をきかせにくいせいで、かえって複雑な後始末が別途必要になる、というのが起こりやすくなります。 どちらのパターンにおいても、作るコストは案外変わりません。このトレードオフに、いつでも通用するような決定的な答えは特にありませんので、どんな仕組みが必要ですか、誰に役にたてばいいですか、というヒアリングが重要になっ

情報システムや自動化の仕組みを作るにあたって、目新しいものを採用することを極力避けるようにしています。なぜかというなら、単純に、存在感が安定しているかどうかの問題です。 プログラムを書くのがすこし得意になってくると、例えばExcelやAccessの上で動くVBA（Visual Basic for Applications）なんかが妙に不便に感じられてくることがあります。記述量を少なくできるようなうまい書き方が他のプログラム言語にはあるのに、こっちには準備されていない、といったことがままあり、仕方なく、少々長ったらしい書き方をする羽目になる、と感じるのです。長くなったプログラムは記述ミスを起こす可能性も大きくなるため、余分な注意が必要です。「ああ、ここに、もっと先進的な○○言語を書くのが許されていればいいのにな」という気分を感じることも時々はあるでしょう。何なら、そういう○○言語で、同様にExcelなどのドキュメントを自動編集するような仕組みも世の中の有志によって色々と作られていることがあり、実際にそれを使って、ちょっと「洗練された風」のプログラムを作成することができるかもしれません。 こういう選択肢があったときには、筆者としては、「現在、この世に、このやり方で理解している人が一番多いという方法はどれだろう」という点を考慮します。また、「数年後、できるなら10年後になっても廃（すた）れていない方法はどれだろう」とも考えます。相対的に目新しい方法のほうだと、流行が終わったあとに定番として定着しておらず、その結果、理解できる人がとても減っているかもしれません。もっと悪いのは、内部的に不具合が見つかったときに、それを簡単には直せない、という状況になってしまうことです。 プログラムを書くために外部ライブラリを援用するときも同じです。ライブラリというのは、誰かが書いた便利なプログラムを部分的に再利用するためのものです。これを活用することで、自分が余分な努力をするまでもなく、他人の成果を借りてやりたいことができる（しかも、多分自力でやるよりずっとうまくやれる）ようになる、というのが最大の利点なのですが、作者がいつまでもそのライブラリを保守し続けてくれる保証は普通は全くなく、もしそうなら、あとでバグが見つかったときや、プログラム言語自体がバージョンアップして、それに対応した調整が必

コンピュータを使った情報整理はもちろん役に立つものですし、そこにまとめた情報をあとで再利用する際にも便利です。キーボードの扱いがほどほどうまくなれば、結構なスピードで文字を入力することもできますから、たくさんの情報を短い時間で記録する目的にも合っています。 それでもなお、筆者は紙にボールペンとか鉛筆を使って情報の整理をすることが多いですし、これに代わる方法で同じことができるとも思っていません。これだけ言うと、まるでデジタル化にすっかり取り残されたオジサンといった様相ですが、別に、作図ソフトやワープロが苦手なわけではないですよ。必要があれば何でも使います。 紙のメモは、とりとめなく浮かんでくる考えや、目の前で繰り広げられる込み入った議論や、自由にアイデアを出し合うような場面で、最も素早く、ビジュアルな印象込みで情報を整理することができます。別に難しいことを言っているわけではなく、大事な言葉をマルで囲ったり、因果関係などでつながるものを矢印でつなげたり、二つに分けて考えるべきものを分岐させたり、ごく簡単なイラストを記して、登場するのが建物なのか、人間なのか、文書なのか、データベースなのか、といった違いを一目で表したり、まだ不確かな状態だと思うものにハテナマークを書いたり、そういう程度の話です。 紙の中央部分には議論の中心的な要素を書き、それから連想されて出てきた話題は周辺に書く、ということで、議論のそもそもの中心を見失わないようにという工夫も簡単です。あとで余分に思いついたことがあれば、似たような要素の近くに適当な空白を見つけて、そこにチョイチョイと書き足して、サラッと線でつなげばよいです。PC上でやるときみたいに、マウスでドラッグしてスキマを空ける、なんてまどろっこしいことをする時間はいりません。 さらに色鉛筆なんかも使いこなせれば最強で、似た要素と思われたものには同じ色のアンダーラインを引いていくだけで、あとから特定の要素のことだけ抜き出して考えたいときに、視覚的に一瞬で情報をフィルタすることができます。 どんな情報システムが欲しいのですか、どんな問題を解決するためにそれが必要なのですか、というヒアリングをするときには、複数人数で、同じ紙をにらみながら議論を展開していくことがあります。そんなときは、思い切って大きな紙を使うことも多いです。A4だとちょっと小さすぎで、

コンピュータでやりたい自動化の仕事を、いろいろな要素を組み立てて、最終的になんとかやれるようになったとします。プログラムとか、Accessプロジェクトとか、なにか専用の動作をさせるための機械とかの組み合わせです。こういうのをみんなあわせて、ひとつのシステムと呼んだりします。 そのときには、当然ながら、やったこと全体を説明するドキュメントが必要です。操作マニュアルも重要なドキュメントのひとつではありますが、それだけでなく、どうしてこのシステムが存在するのかを全て説明するドキュメントです。 もっと具体的には、どういう問題を解決するために、どういう根拠でそれぞれのシステム構成要素やプログラム言語・ライブラリが選ばれたか、それらはどういう条件で正常に動作してどういう条件で動作しなくなるか、何を見ることで動作が正常と知ることができるか、などです。 書いたプログラムやスクリプトも、ひとつひとつをすっかり説明すべきです。１本のプログラムごとに、丁寧に整形され、変数名、関数名、パラメータ名が合理的で、細部にわたって、書かれた根拠が明確に説明されていないといけません。のちに動作内容を調整したくなると予想される箇所があれば、それを作り込みやすいようあらかじめ工夫し、その意図を明記しておかなくてはいけません。ExcelやAccessのように、プログラムコードに相当するものが数カ所に分散してしまうタイプのものは、それらがどこに配置されているかも含め、あいまいな点がひとつも残らないよう工夫されていないといけません。 結果として、システムの構築について勉強している人がもしもいたときに、ほとんど教材のように使える程度の品質をもったドキュメントが求められると考えています。 こうして整備されたドキュメントは、実は、それを納品した自分自身のために最も役に立ちます。けっこうな時間が経ってしまったあとで、システムの一部を修正したり、動作内容を変更したり、または動作の不具合と思われる点を調査する必要が生じるということは必ずあるのですが、その際、手がかりなしに当時の記憶をすっかり取り戻せるとは期待できません。そのときの記憶をできるだけ生々しく脳内に「ロード」するために、完璧なドキュメントがその役割を果たします。 自分自身のためであるという一方、このドキュメントは、のちにシステムを他人に託すためにも必要なもので

データをどこかの外部システムから持ってきて、手元でなんらかの処理を加えるということはとても典型的な情報処理の仕事です。そうして処理した結果のデータを、来たときと同様、次のシステムに渡すことになることもよくあります。入ってくるデータと出て行くデータがある、という当たり前のことを述べているだけなのですが、システム的な考え方をするためにはとても基本的な要素です。 で、データの形式は、その前後のシステムが要求する形に従って、CSV形式だったり、XML形式だったり、JSON形式だったり、もっと他の形式だったりするわけですが、例えば今挙げた３つの共通点は、プレーンテキストとして記述されていることだったりします。WordやExcelみたいな独自形式ではなく、プレーンテキストファイル。（今はWordやExcelも一皮むけばテキスト的なもので記述されているのですが、この話は複雑なので省略） 「ああなるほど、（プレーン）テキストファイルですね、そうですね」と同意してくれるかたに出会うと、「やった、この人となら仕事がはかどる」という気持ちになります。 プレーンテキストって何のことなのか、というのをイザちゃんと説明してみようとすると、思ったより複雑な、というか、コンピュータの根幹みたいなものに触れた話になってしまいがちではないですか。コンピュータがメモリに情報を持ったり、ディスクに情報を格納したりするイメージって、プレーンテキストのイメージにそもそもとても近いですから、無理もないことなんですけど。 今目の前の「メモ帳アプリ」なんかで開いているプレーンテキストのファイルが、コンピュータの内部でどんな雰囲気で扱われているか、というのが、たとえウッスラだとしても分かっているわけです。こういうかたには、プログラム的にデータを扱う勘どころをとても説明しやすいですし、なんならプログラムを書くのを学ぶことがあったとしても、きっとスムーズにやれるだろうとさえ思います。データの中に英数字と日本語の文字が混じっているときには、「文字セット」とか「エンコーディング」といった概念も使っていろいろ処理を間違えないようにしないといけないのですが、こういうあたりの知識も、すぐに吸収してくれるに違いありません。そのくらい、「プレーンテキストがなんだか分かりますよ」とおっしゃってくれる方には、筆者はとても頼もしいという気持

何かの情報システムを作りたいんだ、という相談があると、何はともあれ、それを言い出した方にインタビューに行きます。何か解決したい問題があるんですね、何か仕組みをこしらえることで解決できそうだと考えているんですね、それは面白そうですね、くらいの気軽さで。仕事の意識というよりは、好奇心に駆られて首を突っ込みにいく、くらいの意識のときも割とあります。 そこで、何か決まったパターンの作業を延々と繰り返しているのが不合理な気がする、とか、いろんな情報を参照しながら作業をしなくちゃいけなくて間違えやすいのが悩みだ、とか、そんな感じの具体的な悩みを聞き出すところから始めます。問題があると思うからシステム化したいんだ、というのがそりゃあ普通なわけですし。自分の実感として「ああ、そりゃあ大変ですよねえ」と思えるまで詳しく聞くことにしています。自分自身がその仕事をかわりにやる羽目になったとしたら、さぞかし面倒でかなわないだろうな、と想像したりもします。 この時点で、なにか既存の仕組みを使うだけで問題が解消するかもしれない、と感じることがあります。それってExcelをちょっとうまく使えばできそうだよ、とか、完全にぴったり使い道があてはまる既存のソフトウェアがあるよ、とか。システムをこしらえること自体が目的なわけではないので、こういう提案で話がうまく収まったなら、これはこれで大成功です。 そうでない場合は、いよいよ、なんらかのシステム化によって、やりたい仕事を人間にとって合理的なものにすることを考える段階です。さっきまでの「大変ですねー」的な話によって、どんな登場人物がどんなデータを扱って、最終的にどういう成果物をつくりたいのかが大体見えていますから、それを分かりやすく即興の図に描いて（適当な白紙にエンピツ描きで充分！）、「これが普段やっていることの全体で、この中でもここらへんが面倒な部分ですね」といった具合に、問題点を「見える」ようにしていきます。現場の人も、この時点で「そう、ここが解決したいんだ、その通りだ」と同意できるくらい、話に着いてきてくれていることが必要です。まだ「システム屋さん」としての技術的な用語を持ち出してくる必要はなくて、素朴な言葉で構わないので、「これが解決したいんだ」という共通の意識をこの場のみんなが持てるのが大事な目標地点です。 こういう場で、的確に問題点を汲み取っ

世の中には、あらかじめ一定の大きさにめくれるシール台紙が色々と売っていて、さまざまな用事にとても役立ちます。 たとえば仕事の場面だと、管理上の番号を印刷してコンピュータやバインダーに貼るとか、住所を印刷して郵送用の封筒に貼るとか、いくらでも使い方は思いつきそうです。 ラベル台紙のメーカーは、こういうラベル印刷を効率的に行えるように、用紙だけでなく、専用のラベル印刷用アプリケーションも別途販売・配布していることがあります。ユーザー自身で印刷のひな形をデザインして、別に準備したデータを差し込みながら、ラベル印刷が快適にできるようになっています。 こういうアプリを使うくらいで足りるならよいですが、印刷したい内容がすこし特殊になってきたり（変わったバーコードを印刷するとか、データ内容に従って違ったマークを印刷するとか）、用紙のサイズが一般に出回っているものとすこし違ったりとか、そもそもそういうアプリをのんびり使うヒマもなく大量に印刷したいとか、そういうちょっとしたカスタマイズが必要になったときには、お仕着せのラベル印刷アプリの機能ではうまくやれないことがあります。 こういうときは、専用のプログラムを書いてラベル印刷を行う価値があります。プログラムを書く、といっても大仰なものではなく、PDFを生成するためのライブラリなどを導入して、それを使って白紙のページ上に規則的に文字や線などを配置する程度のことで、それ自体はそれほど複雑ではありません。読み込んだデータを各ラベルのどの位置に、どんな大きさで、またどんな字体で印刷したいのかを決め、その設計に従ってプログラムを書いていくことになるでしょう。 ラベル台紙への印刷は、いったんPDFファイルを生成するのがよくあるパターンです。こうすると、いったんできあがったPDFを適当なビューアで確認してみて、問題がないようなら、ラベル用紙をセットしたプリンタに印刷させるという流れになります。印刷ミスをするとラベル台紙がもったいないので、印刷直前にできばえが確認できるのはいいことです。 ところで、ラベル台紙に内容を印刷するときは、レーザープリンタを使うのか、インクジェットプリンタを使うのか、あらかじめよく考慮しておくのがよいでしょう。１ページで何十枚もラベルが印字できるようなタイプのシートだと、今日は半分だけ使い、別の日には残った部分に印刷して使お