投稿

スクショの扱いは楽になった

離れた場所にいるかたに電話でトラブルシュートを頼まれるときは大変です。相手の画面は見えませんが、なんとかして、その現場で何が起こっているのかを理解しないといけません。直前に行った操作は何かを思い出してもらい、今の時点で読める場所を読んでもらい、どんなボタンが押せそうか、どんな枠になら入力ができそうか、という手がかりも聞きながら、状況を頭の中で再現していくという離れ業が必要になる場面です。必ずしも的確な言葉で説明してもらえるとは限りませんから、そんなときはスクリーンショットを取得して、それを共有してもらうのがよいです。 電子メールでも、ビジネスチャットでも、スクリーンショットとしてクリップボードにコピーされた絵を、そのまま貼り付けボタンなどで貼り込むことができる場面が増えました。かつては、スクリーンショットを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ソースを眺めるクセ、メールエンベロープを眺めるクセ

普段、ウェブサイトを巡っていて、何の気なしに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」を改めて調べて、これを活用して楽すればよいのです。ここでは例を挙げませんが、きっとドキュメントを閉