青竹雑記帖(6代目)

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

頭に入れたら出そう

2か月と1週間ぶりになりました.学会やら博士論文執筆(やばし)やらTwitterで時間を食いつぶし,雑記帖への出力がおろそかになっていました.自分に対しては詫びますが,みなさまに対しては「よう! 待たせたな!」と陽気に行きます.……待っていない? コホン,ひとまず始めましょう.

私は昔からよく本を読んでいました.今はTwitterで時間を食いつぶしているため(さっそく2回目の言明)あまり読めていません.読む本は多様です.大部分は情報技術関係の書ですが,もともと好きなライトノベルや,読書好きがあまり好まないビジネス書や自己啓発書なんかも読んだりします.ビジネス書は本の中身がギラギラしていることが多いです.自己啓発書はスピリチュアルな世界に肩まで浸かっていることが多いのでふわふわしていたりします.もちろん星5つの評価をつけたくなる良い書ばかりではありません.ブックオフなどの新古書店へ10円で売る手間も惜しんで,市の古紙回収でバイバイする本もまれに出ます.本当はお焚き上げでもしたいのですが,他人を弾圧したい人もすなる焚書というものを,自分もしてみむとてするわけがありません.阿呆には夜道に気をつけさせる以外の方法を用い,言論界中で影響力を無効化する必要があります.

良書も悪書(白いポストに入れる奴ではありません)も,自分にとって何らかの糧になることは確かです.その糧が今の自分を作っています.昔々の高校生の頃は「ないんだったら作ればいいのよ!」の一言でSOS団を作ることこそしませんでしたが,20代後半になってからは,その一言がぼちぼち何らかの集まりの主宰をする原動力になっています.同じ頃に図書館で借りて読んでいたビジネス向けメモ術,ノート術の蓄積は,200冊にも及ぶ生活記録ノートの束となっています.大学の講義がきっかけで手にとった仏教関係の書物は,自分の思想を形作る要素のひとつです.また,コンピュータ関係の技術書では,自分が折に触れて引き合いに出す「Windows/Mac/UNIX すべてで20年動くプログラムはどう書くべきか」(松浦智之著・USP研究所監修)の薫陶を受けて,自分のプログラムは初手でシェルスクリプトによる実装が試みられるようになりました.

Windows/Mac/UNIX すべてで20年動くプログラムはどう書くべきか 一度書けばどこでも、ずっと使えるプログラムを待ち望んでいた人々へ贈る[シェルスクリプトレシピ集] | 松浦智之, USP研究所 |本 | 通販 | Amazon

変わり種では,祖母宅の本棚にひそかに存在していた丹波哲郎氏の心霊・霊界の研究の書からスピリチュアルに傾倒していた時期が10代中盤頃にあります.今では変なまじないこそしなくなりましたが,筮竹代わりのコインを振って諸事を占っては外しています.たまには馬券の買い目を教えてください神様.悪書をことさらあげつらうことはしませんが,とりあえず最近書店で面陳されたりAmazonの上位に来たりする新書の群れは中身に触れず,もし家にある場合はどこか高いところに祀って遠ざけた方が良いという肌感覚を身につけるのに役立っています.最近は新書の質も零落してしまったな……

さて,タイトルのそれはビジネス書や自己啓発書に書かれがちな徳目のひとつです.胡散臭いことが多い中でも,上記の「頭に入れたら出す」,横文字を使えば「インプットしたらアウトプットしよう」は頭を使う生活に役立つことだと思います.頭に入れていくばかりでは頭でっかちになるばかりでせっかく学んだことが活きません.学んだことをもとに,実際に外へ出力することが大事です.なんかビジネス書みたいな口調になってきましたが続けます.アウトプットは何でもいいです.誰かに喋るもよし,Twitterでツイートしまくるのもよし,この雑記帖のように長文を書くもよし,同人誌を作って即売会で頒布するもよし,動画を作って投稿するもよし,生活習慣を変えるのもよし.さしあたり,この記事を真っ先に読んでくれそうなTwitterのフォロイー(私をフォローしてくれている人)は,自分の中の何かをツイートすると良いかもしれません.

次回は,ゴミだらけになった情報の世界でゴミ情報をどかす秘技を紹介……できません.むしろ教えてくれ.

機械学習とは人間の成長過程を爆速で再現するものである(あまりにも大雑把な説明)

檄文をぶち上げてから3週間、研究論文を書いていたため記事の追加が遅れました。この論文もまた、現状では機械学習によって執筆することができないものと自負しています。もし機械学習に自分よりもうまい論文が書けてしまったならば、もう自分は研究をやめて別の分野にたびにでます、さがさないでください。

冒頭のタイトルの通りですが、機械学習の本質はまさに「学習」です。比喩的には上記の福岡太朗先生のマンガが的を射ていると思いました。コンピュータがデータを取り入れるというと、一見データを丸パクリして蓄え、何らかの入力(要求)に応じてそのパクッたデータをそのまま示すと思われがちですが、違うと断言していいと考えています。厳密な用語を用いず、さらには定義にも則らない雑な説明をしますと、機械学習とは、入力されたデータを内部に持つ数字の山を用いて計算して出力し、その出力データと「お手本」とを比較して、「お手本」に近付くように内部の数字の山を変化させていくことを表します。学習と「お手本との比較」の際にデータを利用しますが、データ自身が直接機械学習の内部の数字の山(機械学習モデル)に蓄えられることはありません。学習を繰り返し、何らかの未知の入力をしたときに、よい出力ができるようになったら、それが「上達」と言えます。

つまり、本質的には機械学習に文章やイラストを入力する行為は、お手本としてそれらを示すという行為だけにとどまります。また、機械学習とは、文章やイラストを丸パクリするものではなく「模写」する行為に概念上も実際のプログラム動作上も近いものです。この機械学習のために各種データを利用する行為自体は著作権法において一定の条件のもと認められています。法的立ち位置については別途記事を立てたいと思います。

人類のイラストレーターと機械学習によって構成されたAIイラストレーターの違いのひとつは、単位時間あたりに積むことができる学習回数の差です。人類のイラストレーターが絵を模写するところから始めて自らの絵柄や色遣いなどを獲得し、さらに上達していくのには数か月、数年、さらにもっと長い年月がかかります。丸一日を絵の修練に費せるとしても、その一日で1枚を仕上げることができれば十分すぎるほどに筆が速いと思います。自分は文章書きで絵描きではないのでそのあたりの詳しい時間見積もりはわかりませんが、一日で十数枚も描き上げられる人はもう神の領域でしょう。一方、機械学習ですと一回の学習行程で多くの文章やイラストを参照し、学習することができます。また、その学習成果を出力する速度も極めて速いものとなっています。そのあまりもの速さからいかにも文章も絵も何もかも丸パクリしてその成果をガメているように感じられがちですが、本質は学習です。その速度が人類に比べて異様なまでに速いという、ある種の絶望的な差も突きつけられますが。

もし一年に一本しか小説を書かない小説家志望の人がいたら、おそらく私は「駄文でも何でもいいからとにかくいっぱい書け、その時は未完にせずにきっちり書ききれ」と言うことでしょう。一年に一回しか絵を描かない画家志望、イラストレーター志望の人がいたら、おそらくその道の人は「もっと描け、いっぱいスケッチをし、人の絵を模写しろ、そうすれば上達する」と言うに違いありません。機械学習によるAI文筆家、AIイラストレーターは、まさにその「もっと書く・描く」を地球上で最も体現した存在かもしれません。

ただ、前回の記事でも述べましたが、「彼ら」はまさに独立したひとつの存在であり、あなたに成り代わる存在ではないということを認識ください。将来、作家の名前を指定すると文章や絵柄を限りなく模倣する存在が必ずや出てきますが、それでも「このシチュエーションの文を書く、絵を描く」という自発的な行いは(現状)人間にしか成しえないことです。この三週間でまた、文章を書いたり絵を描いたりするAIはさらに学習を重ねました。後輩に後れを取ってはいられません。さあ書か(描か)ねば。

我々の創作魂は揺るぎない(序論代わりの檄文)

世の創作者たちよ、我々の創作はAIによって揺らぐものではないはずだ。もっと自信を持て。

初っ端から真っ赤なクソデカ文字で何をぶち上げているかと申しますと、機械学習を用いたイラスト生成に様々な思いを抱くイラストレーター諸賢、さらには各種創作を成したことがある創作者諸賢への叱咤激励です。技術的観点、法的観点など、さまざまに理詰めで論じても、動揺しているうちはそれを理解するだけの余裕は取れないと思いますので、序論代わりにまずは心からのシャウトをぶつけることにしました。私は忘れっぽいので、もしかしたらこの檄文だけを書いて続きがない可能性もあります。その節はご容赦ください。

私は情報科学系の研究者にしてITエンジニア、そして小説書きでもあります。主に「ご注文はうさぎですか?」の二次創作小説を書いているほか、高校生の頃から十数年ほど間欠的に一次創作の小説も書いています。私の創作の腕よりはるか上を行く創作者はこの世に数多くいます。その方々が著した各種の本を読むたびに心打たれ、このような素晴らしい文を書きたいと思い、時には嫉妬し、挫折し、もう書くのを止めようかと思ったことは枚挙に暇がありません。でも重要なのは、私の文章を書けるのは私しかいないことです。私の文章を集中して学習して作り上げたAIが、私の文章を限りなく模倣して書いた小説を生み出したとします。それは私を「先生」としたのであって、私を乗っ取ったわけではありません。私のような文章を書く新たな作家が誕生し、その作家がたまたま人類ではないという話であると思っています。私の文章技法や癖を限りなく学び取ったAIとて、入力していないものは学習して出力することができません。それは何か? すなわち私の文章に直接には現れていない私の人生の蓄積、詩的に言えば「わが心」です。文章を模倣しきったとしても、私が文章を生み出すその心までは盗み取ることはできません。

もちろん、ビジネスの世界では我々の心を含めた存在すべてを要請される場面はそう多くなく、たいていは「キミと同等以上の文章が書ける存在があればそれでええんや」と技術のみを要請され、そうしてAIに仕事を奪われる可能性は遠い将来にはあり得るかもしれません。飯の種が消えると自分も路頭に迷います。しかし現在、あなたはまだAIに取って代わられていないはずです。繰り返しになりますが、AI(機械学習)は入力に基づき学習します。これは人間も同様ですが、たとえば現在のAIでは「私の無数の人生経験、そのときに見聞きしたもの」を入力して「それを背景にした文章」を出力するところまでは行っていません。情報科学系の人間がぶち上げるのも変な話ですが、機械学習はそんなに上等でも万能でもありません。あなたの代わりではありませんし、あなたの代わりにはなりません。

「違う、私が心配している、怒っているのはそこじゃない」という人も多かろうとは思いますが、まずは我々創作者の存在はそう簡単に揺らぐものではないと今一度見直していただき、磐石の自信を持って事にあたっていただきたいと思います。いっときの感情に乗せられるまま突き進むと、その先にあるのは破滅です。この文章を読み終わったら画面を閉じ、自分の書き上げた(描き上げた)創作物を見て、それが誰にも完璧に真似することができない唯一無二の存在であることを再確認してみてください。

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

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