青竹雑記帖(6代目)

雑記帖がまた新しくなりました。

西鉄電車データベース・運用関係資料出力システム実装中

ご無沙汰しております。7月後半に発生した多忙状態を無事倒し、そこから1週間かけて状態異常を回復しました。

状態異常回復期間中に、西鉄電車の時刻表データベースシステムの製作を大いに進めました。これは、私が作成する西鉄電車の車両運用関係諸資料(車両運用表・車両運用図表【箱ダイヤ】・列車編成両数表)および全列車一覧形式の時刻表を一括生成することを企図して構築したものです。これは次の機能を持ちます。現在、昨年の試作システムからの移植、および新規実装部分の構築を進めています。

  • 車両運用表の出力(昨年の試作システムから移植実施予定)
  • 列車編成両数表の出力(出力実装完了、LaTeXソースコード生成部移植実施予定)
  • 車両運用図表用グラフの出力(昨年の試作システムから移植実施予定)
  • 全列車一覧形式の時刻表出力(LaTeXソースコード生成に成功)
  • 車両運用情報入りの駅別時刻表生成(実装完了)

私が西鉄電車の車両運用を本格的に追い始めて早十年、各種運用資料を作るようになってから八年が経ちました。当初は運用調査成果をもとにすべて手作業で打ち込んでいましたが、列車が1日数百本走る路線の全列車を入力するのは非常に大変で、作成後の自分の手での校正により数十箇所の誤植を訂正しつつもさらに誤植が残るありさまでした。悪い時には総誤植数が百箇所近くに達していたこともあり、これではもし後世に残ったとして混乱が生じるもとになります。そこで、私は資料生成の自動化を始めました。

自動化として、車両系統(出庫から入庫まで、どの列車に流れるかの情報)と車両形式・編成両数の情報を一体化しました。この情報をもとに、各列車の列車番号から車両系統を求め、一覧表に同じことを何回も入力する手間を省くようにしました。また逆に、車両系統から各列車を求め、運用表にその情報を並べるようにしました。この手法の利点は「ミス発生箇所の集中化による発見可能性の向上」です。たとえば、車両系統に対する車両形式の入力を間違えたとします。その情報は、列車編成両数表において複数行の誤りとして表示されるため検出しやすくなります。また、検出された車両系統の情報を修正し、資料を再生成すればすべての誤りが修正できます。また、どれかひとつで誤りを発見した場合、必ず同じ列車・車両系統において別の資料も誤りがあることになるため、誤りの検出効率が上がります。各資料てんでばらばらの場所に誤りがあるより、同じ列車・車両系統に関係ある部分すべてに出現してくれた方が、逆説的ではありますが一気に誤りを直せて、資料の品質が向上します。

この自動化システムは、昨年夏に試作して実際に動かし、2021年3月13日ダイヤ改正における資料生成に多大なる貢献を果たしました。誤り箇所の発生を大きく減らし、かつ迅速に情報をまとめることができました。また、今まで構想しながらも煩雑さのため見送っていた車両運用図表(箱ダイヤ)の生成も実現しました。

ただ、試作システムには少々問題がありました。それはデータ入力に一手間かかっていたことです。公式発売のダイヤグラムから列車を1本ずつ取り出して自作システム規定の形式でデータベースシステムに打ち込んでいましたが、最初の設計で無駄に細かくしすぎたため、この情報をテーブルAに入力し、そのIDに関連する情報をテーブルBとテーブルCに入力……といったように、手続きが面倒で間違いやすいものになっていました。実際、前回より誤りが大きく減ったとはいえ、近所の有識者の方による校閲でまだ10~20箇所の誤りが検出されました。

また、これは個人的な話ですが、データを可能な限りテキストデータとして保持したいという思いがありました。試作システムのデータベースは世に広く定着しているSQLite3を用いていました。このデータベースはSQLにより情報を自在に集約して取り出せること、外部キー制約などを利用してデータの関連性の規則を保つことができること、最適化された保存形式により高速にデータ集約が可能なことという利点があります。しかし、遠い将来情報が取り出せなくなる可能性がテキストデータよりも高くなります。広く使われているオープンソースソフトウェアは比較的開発保守が継続されやすいのですが、将来の行方がどうなるかは誰にも分かりません。

テキストデータであればファイルの形式に起因する読み取り不能状態を避けやすくなります。テキストデータからの集約演算はUNIXコマンド群や各種スクリプト言語によるプログラミングにより達成できますし、大変であればいつでもその時流行っているデータベースシステムに取り込んで、SQLを用いて集約ができます。最近ではテキストデータに対してSQLを発行できる面白いツールが公開されていますので、これを使うことも有力な選択肢です。

github.com

これらを踏まえ、私はシステムVer.2.0を製作しました。

システムとしてはプログラムディレクトリが43.78KB(シェルスクリプト14個・AWKスクリプト1個・Rubyスクリプト4個・テキスト形式メタデータファイル5個)、データディレクトリが1.7MB(2021年3月13日改正全ダイヤ分)となりました。このサイズは小規模であると言って良いと思います。スクリプトファイル数は少々多いかもしれません。

現在、このシステムを2021年3月13日ダイヤ改正データに対して適用し、出力状態の確認を進めています。完成した後、来たる2022年8月28日ダイヤ改正データを収集・打ち込みをして適用し、各種運用資料の迅速生成を目指します。

質問を考える時間をくれ、できれば3日(この時間を短くしたい)

私の困り事のひとつに「話に対する質問をただちに返せない」というものがあります。しかも、質疑応答が重要とされている場面において特に発現するため、大変困っています。

研究発表会、イベントでの交流、雑談など、いわゆる相手がいるような場面で交流を深めるには、何からの形で質問をすることが重要です。たとえば「元気?」などはわりと使いやすい質問、声かけです。もっと深めていくには、相手の話を受けてつないでいくような感じで質問ができればいいんですが、それができない悩みがあります。また、よりかしこまった場で「質問をどうぞ!」と言われると「あー、えーっと、ちょっと待ってな……」と詰まってしまいます。そして、そのような場で無制限の待ち時間が与えられることはなく、だいたい数分間で終わってしまいます。発表や交流だと、他の人から受けた質問に答えること以上に、質問をすることの方が重視されます。でも思いつかないんですよね。困った。

思いつかないとはいっても、話を聞いてから未来永劫質問が思いつかないわけではなく、おおむね n 日(nは小さめの自然数)経ったときにふと思いついたりします。とくに最近は n = 3 のことが多いです。決してボケっと何も考えずに聞き流しているわけではないんです、信じて。しかし3日もあれば研究発表会もイベントも終わってしまいますし、メッセージを別途送ろうと思うとちょっと尻込みしてしまうという状況になって、結局その質問は宙に浮いてしまいます。外から見たら「話は聞いていそうだけど、理解してくれているのかわからない」という存在に見えますね。研究発表者としての私の苦手な存在です。

例外は親しい人との会話で、たとえば家族との会話だとわりとするする質問をして話を展開させることができますし、友人との雑談もそこそこできています。そのときの状況をうまく応用して、初対面の人とよく話ができるようになれないかと考え、ひとつの仮説を立てました。相手の話の背景をよく理解しているかどうかで、質問を思いつく時間が変わってくるのではないかと。もしこの仮説が真なら、事前によく理解することが鍵なのでは。……え、そんなの当たり前だって? そっかー……ワシ今気がついたわ。でも、講演を聴講してぶっつけ本番でもさらりと質問ができるすごい人がいっぱいいますよね。彼らみたいになれたらいいな、と思って今日もアーウーいいながら、質問が出てくるまでの時間を1秒でも稼ごうとしています。

あるいは、自分は物事の観察力と思考の言語化能力が低いのかもしれません。世の多くの研究考察や作品考察を見て、「みんなよくここまできちんと見て解釈を提示できるな、すごいわ」と思うことが多々あります。自分は「おもしろかった!」「こりゃすげえ!」で止まってしまいます。この問題を解決したいのですが、まず観察力の方はどうしましょう。私の裸眼視力は0.03で、矯正視力が0.7くらいです。メガネをかけるとよく見えるようになるのであれば、物事を観察する心か脳か、どちらかにメガネをかければ良いのではないか。でもそれは色眼鏡かもしれません。言語化能力はどうでしょう。私の自慢は日本語の語彙力です。でも感想や考察にその語彙がちっとも活かされていないので、自分にはあまり関係がなさそうです。さまざまな伏線や背景となる表現、各種のメッセージを込めて作品を作ってくれている作者の皆々様が甲斐がないとお嘆きになるかもしれませんが、私はそれらを全てスルーして読んでいます。逆に、私の物語作品には伏線も背景もメッセージも特にありません。全てはフィーリングです。もし何らかのメッセージを受け取られたとしたら、そのメッセージはあなただけのものです。大切になすってください。

今日の話はこんなところです。質問がある方は挙手ください。3日待ちます。

くっつけるのは簡単だが、分けるのは難しい(パソコンのデータの話です)

パソコン、プログラミングの題材ばかりでブログ記事が進んでいますが、ここは「雑記帖」ですので、他の題材も当然出る予定です。そろそろ鉄道ネタでいくつか書くつもりです。

さて、タイトル「くっつけるのは簡単だが、分けるのは難しい」ですが、私が研究活動や趣味でデータを扱ってきて何となく感じていたことをようやく言語化したものになります。データ処理をしている人なら一定程度この言明に納得していただけると思います。

データ構造をどうするかというのはシステムを設計する上で一番難しいところで、ここさえ決まればあとはアルゴリズムも決まると言われています。Rob Pike氏のプログラミングの5つの規則 (http://users.ece.utexas.edu/~adnan/pike.html) のうち、ここに述べた規則5を以下に引用し、日本語訳を示します(夜眠くて頭が働かないので機械翻訳で😛)

Rule 5. Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming. (訳: 規則5、データが支配する。適切なデータ構造を選択し、物事をうまく整理していれば、アルゴリズムはほとんど常に自明である。アルゴリズムではなくデータ構造がプログラミングの中心である。)

良いデータ構造であるとさまざまな仕事が捗ります。良くないデータ構造ですと、データから有用な情報を引き出す処理に多くの時間を要し、作業効率が低下してしまいます。その一例として、住所録システムのデータを考えてみたいと思います。住所録に最低限必要なフィールドには名前、住所、電話番号、電子メールアドレスがあります。漢字で書かれた名前であれば読み仮名もあれば便利そうです。住所にはついでに郵便番号も入れてしまいましょう。このとき、データをどう保存するかで、次のような方法が考えられます。

  • 名前
    • 姓・名(さらに広く対応するならミドルネームも)に分ける。
    • 一つのフィールドにする。
  • 住所
    • 郵便番号・都道府県・市区町村・町名・丁目・番地に分ける。
    • 上の項目のいくつかをまとめる。
    • 全部一つのフィールドにする。
  • 電話番号
    • (NTT加入電話の場合)市外局番・市内局番・電話番号に分ける。
    • (携帯電話番号の場合)3桁・4桁・4桁に分ける。
    • 一つのフィールドにして、ハイフン等で区切る。
    • 一つのフィールドに番号10~11桁をそのまま入れる。

実社会で運用されているシステム、たとえば通信販売の住所登録方式はこの中の複数の組み合わせで構築されています。何が最適かはかなり難しく、利用者に入力してもらう際の煩雑さにも関わってきますが、私は「迷ったときは細かく切っておく」という作戦を提唱したいと思います。もちろん区切りは意味のあるまとまりで設定するのが良く、たとえば名前を一文字ずつ切って格納するのは一般的にナンセンスです。(プログラム処理上の内部の取り扱いで一文字ずつに切らざるを得ないのはC言語で見られますが、プログラムの事情をデータ格納のところまで引っ張り出してしまうことにはあまり意味がありません。)

区切ったデータをくっつけるのは簡単です。たとえば ExcelLibreOffice Calc などの表計算ソフトであれば、いくつかのセルに入ったデータや文字列をくっつけてひとつの値にする CONCAT 関数があります。プログラミングの際も、文字列結合の関数や演算子で全部くっつけてしまえます。一方、ひとつにまとまったデータを分けることは難しいです。意味がある単位で区切りが入っていれば、それを頼りに分割できます。多くのプログラミング言語では文字列分割関数(一般には split 関数やメソッド)でサクッと切れますが、ExcelLibreOffice Calc では一筋縄ではいきません。これらには文字列分割関数がありません。文字列検索関数・文字列切り出し関数を駆使して非常に面倒な式を書かねばなりません。ちなみに、Google スプレッドシートでは SPLIT 関数が使えますので楽です。表計算ソフトでも速く実装してくれたまへ。区切りが入っていなければもはや地獄です。住所や電話番号は規則性がある(都道府県は47通りしかない、市区町村は最後に必ず「市・区・町・村」が来る、電話番号は付番規則が定まっている)ため、正規表現を用いるなどしてパターンマッチングにより切り出すことが可能です。でも町名はどうしましょう。番地もスタイルがバラバラですね。お手上げです。正規表現で頑張りすぎると後から保守・改修が難しくなります。この際諦めましょう。

フィールドへのデータ格納法以外にも、たとえばリレーショナルデータベースには「関係の正規化」という手段で関係を適切に定めて、データを分割するような形でいくつかのテーブルに分けて格納し、データを効率的に取り扱うための設計方法論があります。正規化されていくつかのテーブルに分かれたデータはSQLを記述して結合してデータを取り出せます。しかし、ひとつのバカみたいに大きいテーブルに何もかもが詰め込まれてしまうと、データを取り出す方法が非常に限られてしまう恐れがあります。また、もしテーブルを分割することになったとき、そこからデータを欠落・破壊しないように分割することは困難を極めます。不便かもしれませんが、諦めてそのまま運用しましょう。困ったときは必要なデータをSQLで引っ張りだしてCSVでダンプして Excel でコネコネしようか……

困ったときは分けましょう。よいデータ処理ライフを!

自立したソフトウェア

昨日の記事「JavaScriptフレームワーク(泣)」からの関連で少し続けます。

aotake91.hatenablog.com

当記事中で紹介した「Windows/Mac/UNIX すべてで20年動くプログラムはどう書くべきか」(松浦智之著・USP研究所監修)の序章において、松浦氏はこのように述べています。

20年間本当に動き続ける保証のあるソフトウェアを手に入れるにはどうすればいいのか。答えは、他人に頼らず自分で保守できる知恵を身に付けること、だ。

数年前の私はこの言葉に大変感銘を受けました。同書では他人が作ったものに過度に依存し、高度化した技術の内部にまで目を配る余裕がなくなっているソフトウェア開発現場の現状を指摘しています。これについて、昨日の記事を踏まえて自分から拙い例を挙げますと、たとえばJavaScriptフレームワーク「Vue.js」は、GitHubリポジトリ (https://github.com/vuejs/core) を置いて、今では300人を超える人が何らかの形で開発に携わっています。私を含む多くの人はこの Vue.js の成果をありがたく享受し、ウェブアプリケーション開発に勤しんでいます。GitHubを見てもらうとわかりますが、このソフトウェアは「MIT License」により提供されています。このライセンスは、Vue.js の開発者の著作権表示と、MIT Licenseが定める利用許諾表示をすることを条件に、ソフトウェアを誰でも無制限に自由に取り扱うことを許しています。また、「作者または著作権者は、ソフトウェアに関してなんら責任を負わない」ことを定めています。つまり、何らかの事情があれば自分で保守できなければならないということも含意しています。しかし幸いなことにソフトウェアの作者およびコミュニティの偉大なる技術力と継続的開発のおかげで数多くの問題が発見修正され、我々はバグレポートを上げつつ、その成果物の恩恵に浴することができます。

それでは我々は、この Vue.js の中身を理解できているでしょうか。Vue.js の根幹はTypeScriptで記述されており、TypeScriptのコンパイラにより最終的にはJavaScriptに変換されます。TypeScriptやJavaScriptの知識があれば読み解けるわけですが、私はまだ理解するに至っていません。理解が及んでいないながらも、潤沢なドキュメントや書物のおかげで、なんとかその機能を利用して開発をしています。ただ、自分の知識水準を考えると、Vue.js という技術を適切に自分の手で使いこなせているとは言いがたい面があります。もし何らかの事情があって自ら保守しなければならなくなったらお手上げです。過度であるかどうかは措くとして、少なくとも依存していることは確かです。*1

他人が作ったものに過度に依存しないとして、ではどこまで自立すると良いかですが、松浦氏の書にある事項を基準として一言で表しますと「コンピュータを使う多くの人が確実に入手整備できる環境さえあれば、動くようにする」となります。その解のひとつが UNIX 環境で、しかも「POSIX標準」です。目安はそのプログラムを動かすにあたって、追加の言語処理系や標準外のライブラリ・コマンドをできるだけシステムに追加せずに済む(Debian系のLinuxであれば、sudo apt installを打たずに済むか、打つにしても標準リポジトリで済む範囲にする)ところでしょうか。より補足すると、ひとつの表現は「UNIXが動くレンタルサーバにおいてはどこに持っていっても常に動く」となります。過度に依存しない姿勢をウェブに向けて拡張すると「POSIX中心主義(POSIX標準 + ウェブアクセス用コマンド・ライブラリ + W3C標準)」です。先の例であれば、JavaScriptのうち標準化されている範囲だけで自ら記述すればこの姿勢を満たすことができます。

もちろん、大規模なプロダクトに関わるチームの下っ端のひとりであれば、この姿勢を貫いて開発を実施することはまず無理でしょう。もしかしたら、そうした現場のプログラマの中には、不幸にして自分が携わるソフトウェアがどのような技術に依存しているかを理解していない人がいて、話が通じない可能性があります。でも、この記事をわざわざ読みに来るような、技術について深い理解を得ている人は、ぜひこのような姿勢があることを知り、少しでも実践していきましょう。あるいは、自分が設計・構築を自ら差配できる立場であるならば、思いきって導入するのも手かもしれません。

この自立の姿勢を持ち続け、良いプロダクトの開発につなげていきましょう。

*1:ちなみに、ソフトウェアの作者にとっては、「ソフトウェアの実装詳細が分からなくてもきちんと使え、本質的な開発に集中できる」状態を実現できているのは作者冥利に尽きます。しかし、我々プログラマは同業の達人の謦咳に接するという意味でも、やはりソフトウェアの中身を知ることは大切だと思います。中身を知っていれば、移植の必要性が生じてもそれを円滑に実施する助けになるはずです。

JavaScriptフレームワーク(泣)

はじめに:敗北

私の本業は情報系の大学院生(博士課程)です。また、アルバイトとしてとある通販会社の内製システム改修業務を担当しています。本業ではテキストデータを刻んで機械学習や統計処理にかけているため、CLI一辺倒でガチャガチャやっていますが、アルバイトではウェブシステムを取り扱っているため、フロントエンドの知識も必要になってきます。

アルバイト先のシステムはそこそこ年季が入っていて、改修が重ねられた結果、現在はバックエンドとフロントエンドが一定程度分離された状態となっています。分離された部分のフロントエンドには Vue.js と Vuex が用いられています。すでにバックエンドとフロントエンドをともに扱う機能追加改修をひとつ成し遂げており、これで Vue を完全に理解したぞワハハハハ(←フラグ)として次のフロントエンド部分機能改修タスクに取り掛かり、昨日盛大に挫折しました。なんなんだ、 Vue というか Vuex が全くわからんぞ……

Vuex わからん

developer.mozilla.org

世の中にはJavaScriptフレームワークが複数あります。その中でも、現在広く使われていて、活発なコミュニティ活動と優れたドキュメントがある代表的なフレームワークが MDN Web Docs で紹介されています。 Vue はその中のひとつにあたり、学習コストが非常に低く、それでいて多様なアプリケーションの開発が容易になることが特徴です。確かに、使いやすいなと思ってちまちまと遊び、アルバイト先の小規模システム構築にも利用しました。その経験を踏まえて内製システムの改修に臨み、1勝1敗となっています。その原因が Vuex です。

Vuex とは、「Vue.js アプリケーションのための 状態管理パターン + ライブラリ*1」です。まず私はフロントエンドにおける「状態管理」の意義と実際について理解が不足しているため、その部分の理解を深める必要があります。とはいえ「理解するまで1か月時間を寄越せ」と言える立場ではない(正確には堂々と宣言できなくもありませんが、あまり期限を遅らせるようでは良心がない)ので、ひとまず重要な部分を理解して、他の実装済のコードを参照しつつコードを実装するわけですが、全く動きません。トホホ。システム班のチーフと議論した結果、本質的な問題はこのシステムにドキュメントが存在せず、何を思ってこのような実装にしているのかという「設計哲学」がまったく分からないことが、コード理解を困難にしているという結論に至りました。こんなもん改修できるかと投げてもいいですし、実はすでに新システムの開発も進んでいるのでなおさら投げてもいいわけですが、それでは良心がない(2回目)ので、やります。

JavaScriptフレームワークなんかきらいだーーーーーーーーーーーーっ!(←ドップラー効果で遠ざかる声)

私は JavaScript 自体を粉砕したくてたまりませんが、これ無くして現代のリッチなウェブ体験が存在し得ないことを理解しています。実際、自分でも扱えないと現代を生きるのは難しいので、いわゆる「生の」 JavaScript を学び、扱えるようになっています。ではそこからフレームワークの学習に進んでみよう! ……となっていないのが現状です。 Vue.js は扱えますけど、正直、それを頼みに積極的に開発案件を受けようとは思いません。いっちょん好かん(ぎこちない共通語訳:全く好きではない)。

フレームワーク抜きで戦うには

好きでなければフレームワーク抜きで戦う必要がありますが、自分だけの小規模プロダクトであれば生のJavaScriptで戦うことは余裕です。でも、チーム開発や大規模プロダクトになると、フレームワーク抜きだと間違いなく破綻します。どら焼き1個賭けてもいいです。お仕事をするみなさんと未来の私頑張ってください。

でも、フレームワークがすべて爆発四散した荒涼たる未来インターネットの世界でも生き残りたいあなたには、生のJavaScriptだけでいろいろやってみる訓練をするのも良い経験だと思います。Ajaxも書きやすくなりましたし。第一歩はみんなだいすき MDN Web Docs から!

developer.mozilla.org

フレームワーク抜きで戦う思想の根源

私がフレームワーク抜きでもなんとか戦おうと思うようになったきっかけとなる思想書は、「Windows/Mac/UNIX すべてで20年動くプログラムはどう書くべきか」(松浦智之著、USP研究所監修)です。これ自身はシェルスクリプトを用いた兵法書ですが、その中にフレームワークに頼らないインターネットとの付き合い方(プログラム作成法)の例として「生のJavaScript機能でも戦えるぞ」というコード例があって、大いに感銘を受けた次第です。この当時は XMLHttpRequest を用いて Ajax を実装していましたが、今であれば Fetch API を利用しても問題ないでしょう。

この書にある「POSIX原理主義」「POSIX中心主義(POSIX原理主義 + W3C原理主義)」の思想は賛否両論ありますが、それを採用するにせよ採用しないにせよ、触れておくと技術を扱う上で得られるものが多いと確信しています。少々お高めの一品ですがぜひご一読ください。フレームワーク無しでもかなり戦えることを知り、また、フレームワークがあると便利になる部分を理解する助けになります。

「そこそこ」の選択肢

物事を「全部やる」か「全くやらない」かを考えたくなったとき、判断対象をもう少し細分化して判断し、総体として「そこそこやる」という選択肢を今一度ご検討ください。

昨日私がふとツイートしたものですが、少々言い換えると「おはようの挨拶はタダなので、遠慮なく積極的に挨拶をしておけ。常日頃おはようと挨拶をしていただけで記憶されて、一大事において物事が通じることもある」という感じのことを言いました。ひとくちに挨拶と言ってもいろいろあり、このような軽い一声のこともあれば、ちょっとした立ち話のこともあるでしょうし、重要な挨拶ともなれば、正装をして手土産を持参し、丁寧に言葉を述べることになります。この「そこそこやる」というのを再認識したのは、先日(といいますか完全復旧宣言は今日でしたが)のKDDI通信障害の件についてのSNSでの反応でした。

KDDI通信障害の件で、「作業にあたっている人に感謝すべきだ」「いや、契約上の義務を果たしているだけだからその必要はない」「会社を甘やかすな」など、SNSでは言葉の応酬が繰り広げられています。もともと何を対象として見ているか、何に対して論評しているかという点のすり合わせができていないのが最大の問題ですが、それに加えて考えると良いのが、判断対象をもっと細分化して考えるということです。たとえば私は、次のように考えています。

  • 会社組織としては、当然通信障害を積極的に引き起こしたくて作業をしたわけではないが、結果に対しては責任を負い、体制に改善すべき点がないか批判的に検証する必要がある。
  • 組織内各担当者は、おのおのの作業フローを再点検して改善可能な点を明らかにする必要がある。
  • それはそれとして、足かけ3日に渡り必死に作業した方々に「や、お疲れさん」と労いの言葉をかける。

これらは互いに矛盾なく成立する姿勢だと思っています。

ちなみに「批判」という言葉も最近では否定的文脈で使われ、とりわけネット上ではしばしば相手をとにかくボコるみたいなことをしがちですが、本来の意味は「物事に検討を加えて、判定・評価すること。」(『デジタル大辞泉』より)ですから、物事をよく検討し、それについて良かった点は良かったとし、改善すべき点は改善すべき点として示すことが重要です。これらも合わせると、全肯定か全否定に限ることなく、さまざまな選択肢が広がります。

全肯定か全否定かという状態を指すときに「0か1か」や、「0か100か」という表現をすることがあります。私は情報系の人間なので、これを2進法的にたとえています。全肯定か全否定かで物事を判断するのは2通りですから、これは2進法では1ビットで表せます。問題を細分化して、これは良い、これは悪いと判断していくと、その細分化した数に応じて桁数が増えていきます。2つの部分ごとに判断すれば4通り、3つに分けて判断すれば8通り、次いで16通り、32通り、64通りと増えていきます。全肯定か全否定か以外の判断をしていくと、真ん中あたりに「そこそこ」という範囲が生まれてきます。この「そこそこ」という部分を自分は大事にしたいと考えています。どのくらい細分化すると良いかは経験則によるところが大きいですが、4つくらいの判断水準で最終的に16通りくらいの結果にするのが上出来かもしれません。

ちなみに最近のコンピュータは64ビットアーキテクチャですから、最大64ビット幅で各種データを処理できます。ちなみに64の判断水準で物事を細分化して考えますと、18,446,744,073,709,551,616(1844京6744兆737億955万1616)通りの結果が得られます。全肯定・全否定以外に1844京6744兆737億955万1614通りありますから、じっくり考えて判断する必要があります。この数は、昨今のTwitterで大変大きな数を意味するときにしばしば使われる「5000兆」よりはるかに多いです。……今の日本円の価値のまま2の64乗円くらい銀行口座に入金されませんかね。

コホン、判断水準が多いとその分頭が痛くなりますが、頭が錆びつかない程度に判断して選択していきましょう。

困ったときの通信確保指南(公衆電話の説明がクソナガイ)

週末の KDDI (au) の通信障害においては、各方面実に大変だったことと存じます。我が家は全員 docomo でしたが、親戚の多くが au 利用だったので大変だっただろうなと思います。 とても気合の入ったタイトルから始めましたが、大したことは言いません。ネット上にあふれるアドバイスよりも、少しばかりは大多数の人のあり方に近い感じにします。できるかな?

ちなみに通信障害の概要は次の通りです。

  1. 障害継続時間 7月2日午前1時35分 ~ 継続中(5日午前2時現在ほぼ回復したものの、本格再開との発表はなされていない)
  2. 影響利用者数 全国3915万回線

要約

  • 人生諦めが肝心。茶を飲んで飯食って寝るしかねえ。
  • とはいえ命や暮らしが懸かるとそうも言っていられない。なんとかするならば……
    • Wi-Fiスポットを見つけて世話になる。
    • 公衆電話を探しておく(ただし受信はできない(正確にはできるけど公衆電話の電話番号は非公開))。
    • 安いスマートフォンを買い足して安いプランを契約しておく(もちろん追加費用がかかる)。
  • ネット上のアドバイスの問題点
    • 「デュアルSIMって、何?」という人の持つスマートフォンのほとんどは、SIMを1枚しか挿せないし、eSIMへの対応が困難。
    • 安いとはいえ回線を増やせば金はかかる。

人生諦めが肝心

各種インフラは日々多くの人やシステムの不断の努力によって維持されています。とりわけ日本ではめったに障害を起こしません。 少し古い情報になりますが、総務省の電気通信事故検証会議がまとめた「平成30年度電気通信事故に関する検証報告」では、 今回のKDDIの件のように継続時間24時間以上、および影響利用者数100万以上の事故は0件であったと報告されています。

なかなか起きない事態に対処するときの方針としては「自分の命に危険がないなら、諦めて、寝る」が良かろうと思います。怒ると寿命が縮みます。

とはいえ命や暮らしが懸かるとそうも言っていられない

いかんせん命が懸かると諦めるわけにはいきません。山奥や海で病気やケガなどをすると、数時間の差で命が失われる危険があります。 今回も海の事故で、事故発生から通報が届くまでに5時間を要してしまった事例が報告されています。 あるいは、この暑さで倒れてしまったら、スマートフォンが唯一の生命線になることだってあり得ます。 自分がそうなるだけでなく、相手がそうなってこちら側に助けを求めてくることもあるわけで、その際にこちら側で受信ができなければ一巻の終わりです。 ある程度は自分達の側でも対応策を考えておく必要があります。

Wi-Fiスポットを見つけて世話になる

通信を確保する有力な策は近所の公衆無線LAN (Wi-Fi) スポットです。主要な駅や大型ショッピングモールだと整備してくれているところも多かろうと思います。 コンビニにもスポットが整備されています。ただ、セブンイレブンは昨年度末頃までにほとんどの店舗でWi-Fiサービス(7SPOTや各携帯電話会社のキャリアWi-Fi)を廃止してしまいました。 こうした公衆無線LANではセキュリティ面が心配な面もありますので、クレジットカード決済など、盗まれると危ない情報のやり取りが発生する処理は避けた方が無難です。

公衆電話を探しておく(ただし受信はできない(正確にはできるけど公衆電話の電話番号は非公開))

参考ウェブサイト : NTT西日本の公衆電話に関する案内

www.ntt-west.co.jp

最近は携帯電話番号や電子メールアドレス情報を交換しないので、LINEのようなメッセージングアプリや、その他のSNSしか連絡を取る手段が無い相手も多いかと思います。 とはいえ、家族の携帯電話番号や家の固定電話番号(最近は設置しない家も多いですかね?)などは携帯電話の連絡先アプリに登録しているはずですので、公衆電話から掛ければつながります。 うちのあたりだと中高生を中心に公衆電話を使う姿が今も見られます。都会の人には信じがたいかもしれませんが、携帯電話等持ち込み禁止の学校がまだあるのかもしれません。

一応使用方法をご紹介します。

  1. 受話器を取ります。
  2. テレホンカードまたは硬貨(10円または100円)を入れます。10円玉の場合、電話代より投入額が多かったら余りは返ってきます。100円玉だとお釣りは出ません。
  3. 受話口(耳につける方)から発信音(ツー、という音)が鳴ることを確認します。
  4. 電話番号を入力します。プッシュボタン式であれば数字をそのまま打ち込んでください。ダイヤル式(最近はほとんどありませんが、ごくまれに設置されています)の場合は、数字に対応する穴のところに指先を入れ、指がストッパーに当たるところまで右に回し、指を離してください。ダイヤルが元の位置に戻ることで番号が1ケタ送信されます。これを電話番号のケタ数分繰り返します。
  5. 相手が出たら話します。電話料金が不足すると警告音が聞こえますので、硬貨やテレホンカードを追加投入してください。追加投入しなかった場合は通話可能時間終了とともに電話が切れます。
  6. 通話が終了したら、受話器を元の位置に戻してください。テレホンカードや電話代に使われなかった硬貨が返ってきます。

公衆電話は削減傾向が続いており、総務省が設置義務の基準を緩和したことから、最低設置基準を満たしつつもさらに削減されることになっています。設置箇所は2012年からウェブサイトで検索できるようになりました。NTT西日本管内(九州・沖縄・中国・四国・近畿・東海・北陸)とNTT東日本管内(甲信越・関東・東北・北海道)でページが分かれています。いずれも屋外・屋内の別、終日利用可能か利用不可能時間帯があるか、車椅子での利用が可能かを基準に地図上にアイコンで表示されます。それ以上の設置箇所説明はありませんので、たとえば設置箇所がどの建物の前か、あるいは中かという情報は地図を見て判別するしかありません。……これってテキスト読み上げによるアクセシビリティはどうなっているんでしょう。

www.ntt-west.co.jp

publictelephone.ntt-east.co.jp

駅名やランドマーク名でも検索できますが、これは単に地図上でその駅やランドマークの位置に飛ぶというだけで、検索で出てきた駅やランドマークに公衆電話が設置されているとは限らないという罠があります。たとえば秘境駅として名高いJR日豊本線宗太郎駅大分県佐伯市)は、検索結果に現れてその駅の位置まで飛べますが、ここには公衆電話はありません。また、わが地元小郡市で、終日利用可能とされている屋外設置の公衆電話のうち、ひとつは陸上自衛隊小郡駐屯地のど真ん中に点が打たれています。申し出れば入れてくれるとは思いますが、公衆電話を使う人が少ない昨今、どうみても怪しい奴にしか見えません。

あと当然ですが、公衆電話から電話を掛けることはできますが、特殊簡易公衆電話(通称ピンク電話。でも新しい機種は白い)の一部を除いて、相手方からかけることはできません。公衆電話にも電話番号はありますが、非公開とされています。

安いスマートフォンを買い足して安いプランを契約しておく(もちろん追加費用がかかる)

そしてこれです。予備回線の確保するのも有力な策です。もし普段使わないなら思いきり割り切って、格安中の格安なスマホを選んで用意するのもいいかもしれません。スマートフォン本体は中古調達し、格安SIM (MVNO) は超絶安いものを選択して契約するというものです。この時重要なのが、メイン回線で持っている会社とは違う系統の会社の回線を使うことです。初めての人は混乱すると思いますが、格安SIMの会社は自前の回線を持たず、回線を持っている会社 (MNO)(NTTドコモKDDIソフトバンク楽天)から借り受けて通信サービスを提供しています。(ちなみに楽天モバイルは自社以外に回線を提供していません。ちなみに自社回線エリアを増やしてきていますが、まだKDDI回線へローミングするエリアも多いです)格安SIMの会社で「プランA」(KDDI)、「プランD」(NTTドコモ)、「プランS」(ソフトバンク)と分かれていたり、「docomo回線」や「Softbank回線」などと書かれている場合は、それぞれ書かれた会社の回線を利用して実際の通信を行います。ですから、メイン回線としてKDDI系統の回線を使っている場合は、予備回線にはNTTドコモ系統やソフトバンク系統を選択すべきです。

ただ、この方法は後述するように、多少は金がかかりますし、それ以前に条件により契約自体ができない場合があります。

ネット上のアドバイスの問題点

今回の件を受け、Twitter等では「予備回線を確保しておけ、デュアルSIMだ」という声が多く聞かれましたが、彼らは大変な問題を見落としています。

「デュアルSIMって、何?」という人の持つスマートフォンの多くは、SIMを1枚しか挿せないし、eSIMへの対応が困難

通信関係に詳しい人は、SIMフリーのデュアルSIMに対応するスマートフォンを調達して、実際に2社の回線を契約して運用していると思います。そうした人達が見落とすのは、「世の多くの人は各携帯電話のキャリアショップや家電量販店の店頭で携帯電話を購入契約し、しかも長期間利用する」という点です。日本でシェアが高いiPhoneがデュアルSIMに対応したのは2018年発売の「iPhone XS」「iPhone XR」からです。それ以前のiPhoneや、Android系端末のうち各キャリアが出すモデルは、そもそもシングルSIMか、あるいはグローバルモデルでもデュアルSIM機能を削除してあるか、どちらかです。また、iPhoneのデュアルSIM対応は、2つのうち1つはeSIMでなければなりません。MVNOがよく分からない人が、eSIM対応の会社やプランを探し出して利用するのは難しかろうと思われます。

安いとはいえ回線を増やせば金はかかる

私の友人知人が話していましたが、「格安スマホを使っている人は、その格安な回線1本を維持するだけで大変なのではないか」という懸念です。確かに探せば維持費が年間660円(povo2.0で回線維持に必要な最低限のトッピングを購入した場合)であったり、donedone (ドネドネ) エントリープランという年間0円で維持可能な回線プランがあったりします。しかし、これらはどちらもKDDI系統の回線ですので、もしメイン回線がKDDIならこれらを予備にする意味がありません。ちなみにNTTドコモ系統やソフトバンク系統の回線プランですと、最安で年間約2400円 (HISモバイルのdocomo回線プラン・Softbank回線プラン 段階型料金のうち0.1GBまで)です。年額2400円くらい大丈夫だとする向きは多いでしょうが、困窮とまでは行かないまでも低賃金ですと、正直アップアップな状態になる人もいるかもしれません(信じがたいでしょうが)。最大の問題として、MVNOのほとんどは料金支払手段としてクレジットカード決済しか認めていません*1ので、そもそもクレジットカードを持たない人はお呼びでないということになります。

まとめ

めったにない事象なので腹をくくって諦め、公衆電話などを探しておくか、公衆無線LAN (Wi-Fiスポット) に頼るか、金があれば予備回線を持っておくか、お選びください。

良いスマートフォンライフを!

*1:QTmobileは、QTnet光回線BBIQ」を契約して口座引き落としにしている場合に限り、同じ口座からの引き落としで契約可能