設計のしかたを教えるのは難しい
いきなり勉強会で話すことになって、前々からやりたかった「設計のきほん」というテーマで話したが、いまいち反応が薄くて反省しているという話。
なんか巷でのバズワードや流行りの手法に振り回されずに、そもそも設計ってなんで必要なんだっけ？大切な原則、忘れちゃいけないよ？みたいな話をしたかったわけだが、聞いてくれる人がそもそもそんなにバズワードや流行りの手法に振り回されてなかった（！）のでいまいち響かなかった、ということかと解釈している。どうせわたしが「意識が高すぎる」んでしょうよ。えーん（かわいくない）。
まあ、それは私の準備というか伝え方が悪かったという話で終わりなのだが、そもそもふだん、みなさん現場で設計とかどのように教えておられるんですかね？ソースコードを書いた時にはコードレビューがあって、そこでまかなえる範囲なら指摘できるかもしれないし、設計書をちゃんと作るような開発体制の場合だと、そこで設計レビューが入るかもしれない。でもどちらにしても、一般論として教えるのってどうも疎かになったりしていないですかね？会社ごとや個別事例に対してのアドバイスはできるんだろうけど、それを一般的な原則にまで落として説明してあげてる現場がどれぐらいあるのかは本当にわからない。
あと、それ以前の話として、そもそも設計の一般論など不要で、会社で昔からきまったフォーマットの設計書があって、それを適度に慣例に従って書けばだいたいうまくいっているし、残りは臨機応変に反応すればいいんじゃない？みたいな現場の方が多いのではないかと勝手に想像している。そしてそれは大変現実的で素晴らしい、バランスの取れた現場だとも思う。
ただなあ、やっぱり、もっとうまくいく方法があるのに、同じ手間をかけるならいいソフトウェアを作りたいと思わない？楽して追加変更できるようになった方がみんなハッピーになると思わない？という心の中の声が黙ってくれない。でもまあ、その考え方自体がビジネスと相性が合うとは限らないし、「意識高い」と言われちまうんだよな〜という自虐になってしまう。特に、新規開発ならばともかく、すでに動作しているソフトウェアのリファクタリングなどが対象の場合は、余計に「動いているものは直すな」理論が勝ってしまうのよ。アーメン。
話が逸れた。たとえ現場がよりよい設計を求めていたとしても、そもそも他人に設計の方法を教えるのは難しいという話だったはず。一般的な原則については良い書籍もたくさんあるが、それをReal Worldに適用するための基準や練習方法が不足しているように感じる。わたしが知らないだけですかね。というか根本的に難しいということの証左なんですかね。これから新しい職場でぜひそういうワークショップみたいなことをしていきたいとは思いつつ、ちょうどいい見本を探している、というそれなりのキャリアを積んでしまったソフトウェアエンジニアの世迷言でした。
IT技術書ってなくなるの
緊急事態になりましたね。
それはいったん置いておいて、iPadに入っている技術書を眺めていたら、技術自体はまだあるし、内容もよかったのに、書籍の情報が古くなってしまっている本もたくさんあるなあ、と突然思った。ちなみに（厳密には数学書とかもあるが）iPadには300冊以上入っていて、それとは別に一部のプログラミング書籍とか数学、その他デザイン系の書籍が家で私に読まれるのを待っている（積読の少しオサレな言い方）。
具体的に挙げていこう。まず、Node.js。これはずいぶん長い間よいと思える書籍がなかったんだけど、つい最近オライリーから出ましたね。いろいろごたごたもあったししょうがないのかもしれなかったけど、JavaScriptなのにこれだけ書籍が長い間更新されなかったのも珍しい。あと、（個人的には）Clojure。とくにもったいないのが「おいしいClojure入門」。面白い本なのに。プログラミングClojureももう古いイメージ（specの話とかないもんね）。シェア的にしょうがないよ！という気持ちもありつつ、Elixirはこの前第2版が出たもんなあ（でもオーム社が電子書籍やめちゃったのと内容自体はそこまで変わっていなかったっぽいので今回購入はしていない）。
逆に「こんなに必要？」と思うものもあって、もちろん筆頭はPython。自分も今はPython書いているので偉そうなことは言えないしブームなんだから仕方ないけど、Fluent Pythonとかあとは実務寄りだと黒い表紙の2冊（それぞれ違う出版社）、それは良かったんだけど他は無象無象感がすごい。そしてHTML/CSS。なんだか内容的には自分にはグッとくるものは少ない。いや、読者層としてそもそもターゲットではない自覚はあるんだけど。
変化が早すぎると、ただでさえコスパが悪い（らしい）技術書はますます出版されなくなっていく。自分はもともとスマホアプリの人だったので、10年近く前、始めたてのころは本当にたくさんのiOS/Androidの書籍を買って読み漁った。ただ、これらは基本的に毎年OSの機能が追加されたり変化したりして、情報がすぐに陳腐化するので、どんどん書籍の数は減っていった。今はむしろAndroidの方が残ってる感じ？（よくしらない）ですが、やたらSwift UIの書籍が面出しされているのは老兵には不思議でしょうがない。Auto Layoutの本は1冊しかなかったのに！
あと、Kindleをありがたがってる人もいらっしゃるんですけど、自分はPDFで買えない場合に、物理本よりはマシという理由で買う感じ。残念なのは、流し込みのレイアウトが性に合わない。ページをいったりきたりすると同じ内容がレイアウト上の違う位置に移動していたりして、あれすごいストレスたまります。あと、そもそもだが、ページめくりが遅い。なんであれあんなに重いの、そして改善されないの？となって、むしろ本当に大事にしたい場合は物理で買うな、よく考えると。出版社によってはKindleとPDF両方用意しているところもあって、間違えてKindle買ってしまって買い直したい本も結構あるんよなあ…
あかん、これやり出したらキリがないな。微妙に褒めているとも限らないので、上記の書籍のリンクは貼りませーん。
配色を検索したい
記事の内容とは直接関係ないんだけど、以下の記事の中でのsyntax highlightの配色がとてもいいなと思うんですよ。完全に好みの問題だけど。
で、普段VS Codeを使っているのでそこで同じ配色のテーマを見つけたいなと思ったんですけど、これってどうやって探したらいいんですかね。簡単に探した感じだと以下のサイトがあったので眺めてるんですけど、これ、めちゃくちゃ楽しい。ずっと眺めていられる。
ただしかし、一方ではもう少し簡単に検索とかできんもんかいの、と思うところもある。そのためのUIを考えるのって結構UIを考える問題としてはおもしろいと思う。今回のケースで言うと、他のサイトとかで見た配色をきっかけにほしいとおもったわけなので、そこから汎用的にテーマの名前やそれぞれの色コードが取得できるとかにすればいいんですかね。でもまあ、実際に見たソースコードの配色だけではもちろんテーマ全体が一意に特定できるとは限らないので、そこで出ている色を含むテーマが検索できて結果が出れば最高ですよね。言うだけならば誰でもできる。言い出しっぺが作らされる法則は、仕事の中だけで十分ですよ…
そもそも配色とか、けっこう敏感な方なんですよね…このブログも「色」って入ってるでしょう？色って、分析哲学や認知科学でもそうだけど、頻繁に話題になりがちな、みんな知ってるけどちょっと不思議な存在というイメージなんですよね。色はコンピュータ上では複数のパラメータで表されるタプルにすぎなかったりするけれど、わたしたち人間の側の認識がそれを捉える時に周囲の環境や個人差に左右されすぎて、統一した見え方にならないという、ちょっとふわったした感じが好きなんです（伝わってるのかこの言い回し）。
それはともかく、さっきの気に入った配色とか、ブログの筆者に聞くのが一番早いよね…テクノロジーが簡単なコミュニケーションに勝てないケース、ほんとうに多いよね…。テーマ一覧眺めて、もうちょっと楽しもう。
正月に書いたコード
正月には久しぶりにWebAssemblyの仕様書を読み直して、それをもとに少しだけコードを書いていた。去年の夏休み以来だ。WebAssembly1.0になってから結構経つが、まだあまり変わった感じはない。確か、1.0になったときに関数が複数の値を返せるようになったんだっけ。うろ覚えです。複数の値を扱えるようになるメリットがどこかに記事で上がっていたな、と思って探したらあった。
あとは、早く複数のテーブル（関数テーブル）やメモリが扱えるようになるといいな。テーブルに関しても関数以外も置けるようになれば、ポインタ置き場として使い道はたくさんありそう。でもやっぱり、セキュリティ上、そんなに簡単に用途を広げられないんかな。
前回は（全然公開していないが）WebAssemblyのインタプリタを書いた。ただしText Formatにだけ対応していて、また動く命令も一部だけだ。また機会があれば追加していきたいなと思っていたら転職であっというまに時間が過ぎてしまった。今回はBinary Formatで書き始めている。よく考えたらバイナリのパースを手で書いたことはないな。なんとなくバイナリのパースと聞くとErlangが浮かぶが、別に書きやすくはなさそうな気もする。そのなかにLEB128という形式が出てきて、WebAssemblyで使う整数値はその方式でバイナリ化する決まりになっている。これもプログラミング始めたての方の練習に良さそう（ビット演算とか仕事だとなかなかしないし）。
ちなみに少し前に買った以下の内容が役に立ちました。ここではRubyで実装されている。技術書典で買ったもの。技術書典、またリアルで遊びに行けるようになるといいね。
「お子さま」の覚悟
去年からほぼイベントらしいこともなく、新年が始まった。とはいえ、ここ5年ほどは毎年こんな感じだ。テレビもないしそもそも行事めいたことに労力を割く習慣がないので、少しずつ、年末年始はただの冬休みへと、粘性が高めのまま、変化し続けている。それでも微かに残る習慣が節目を作ろうと、こんな風に文章を書き始める。
去年はコロナがなくとも、なかなか激変の一年だった。転職したからだ。一年前はまだ転職活動中で、内定が出たのが3月。まだぎりぎり、国内出張が許されていた（そのくせマスクの着用は義務だった）。いろいろあってまったく休みなく職場が変わり、私は新しい会社での「完全リモート正社員第一号」の称号を与えられた。その頃のことはこのブログに書いているが、コミュ障がコミュニケーションの大切さを再び思い知らされるといういい機会になった。
秋口からは巡り合わせもあり、対外的に期限が設けられている、地味で大きなプロジェクトのリーダーをやることになった。会社に慣れている身だったら引き受けないように忍足で逃げていたところだが、Zoomで数人としか話せない数ヶ月を過ごしていた自分に上司が「社内のたくさんの部署の人間と関わることができるいい機会だ」と言われ、それもそうだと喜んで引き受けた。珍しいことだが、それぐらい会話に飢えていたとも言える。
元々キャリア的にも少しずつマネージメントは行なっていたので、その点で戸惑うことはないものの、やはりそれなりに規模の大きい会社なので単純に物量が違う。それまでと打って変わってIDEを開けることもDockerで遊ぶこともなくなり、ExcelというかGoogle Spreadsheetを眺めたりスライドを作ってばっかりの日々がまだ続いている。
この立場になって感じるのは、というか薄々わかっていたことではあるが、自分は「エンジニア」気質ではないな、ということ。プログラミングは大好きだが、どんな題材でも楽しい、というわけではない。大学の時に数学基礎論や分析哲学をかじるような人間だし、正直、現時点でも興味の対象は当時からほとんど変化がないと言っていい。課題に対して情熱的にパッチを当てながら穴を少しずつ塞いでいく、という現実的な対処の仕方はこれだけ経験を積んでもまだ好きになれない。一見複雑な現象を切り分け、もしくは抽象化して、少ない「ことばかず」でクリアしていきたいのであって、力任せにたくさんソースコードを書きたいのではない。
さて、困ったのは、現在の会社はその意味で、私の気質とは正反対の経過を経ていて、しかも劇的な成長を続けている、という事実だ。「きれいなものをつくる」と「ビジネス的にうまくいく」が両立することはないとわかってはいても、いざ眼前に、自分の解くべき課題として立ちはだかると今までの「お子さま思想」が揺らいでしまう。でもだからこそ、今回の転職はうまくいったな、と感じる。まだやったことのないおもしろそうな課題であることも、間違いないからだ。自分がどこまで現在のスタンスを貫けるのか、現実というやつと戦ってみようと思う。
Algebraic Property Graph
近況
転職後１ヶ月半、初の連休でゆっくりできた。在宅勤務が続く中で一つ気づいたのは、一日誰とも会話せずに仕事するとメンタルを病む、ということ。事務的な報告ではダメで、仕事の内容でも全く問題ないがとにかく話すべき。そういう意味では、単なる作業者ほどキツそうだな、と思う。数少ない出社日も、今後の情勢次第では完全在宅になる可能性も残っている感じ。
Algebraic Property Graph
連休中に、以前から調べている、Algebraic Property Graphという概念について改めて考えていた。今回はざっくりこのAlgebraic Property Graphを紹介してみようと思う。以下のリンクを読んでください、が一番簡単な説明なのだが、私自身の関心も絡めて、もう少しだけ説明してみることにする。 arxiv.org 元々、私はAlgebraic Databaseというものに強く興味を持って以下の論文を読んでいたのだが、このAlgebraic Property Graphはその延長線上にあるものである。
arxiv.org Algebraic Databaseの大まかな概念そのものはそこまで難しいわけではないと思うのだが、この論文は圏論の高度な概念がたくさん出てきて、とてもじゃないが一読して理解できるようなものではなく、おかげで圏論を勉強しまくるハメになった。あくまで私見だが、Algebraic Databaseは、関係論理を基盤にするRDBを発展させうる可能性を持っていると考えている。例えば「スキーマ変形」はトピックの一つで、Algebraic Databaseではスキーマ変形や、異なるスキーマを持つデータのマージなどを形式的に扱えることをアピールしていたりする。一方RDBの場合だと、データ「マイグレーション」はその仕組みの外側で、他のツールや仕組みを使って管理する必要がある。他には、プログラミング言語とRDBの間のいわゆる「インピーダンスミスマッチ」を埋めようとしている点も注目すべきだと思う。
さて、Algebraic Property Graphは、Algebraic Databaseに比べれば遥かに理解がしやすい概念である。圏論は出てくるものの、上記の論文は読みやすい。Uberで使われているっぽいのだが、RDFやRDB、JSONなど、異なる構造のデータを統一的に扱い、相互に変換するための道具であるように読める。Algebraic Databaseには存在する、例えばクエリ（CQL）のような概念は出現しない。そういう意味では、Algebraic Databaseから便利で実用的な側面を切り出してきたようにも見える。
ただ、Algebraic Property GraphはAlgebraic Databaseの単純なサブセットというわけでもなく、むしろ扱える構造は広がっているように思える。Algebraic Databaseで出現する例では、あくまでもRDBのレコードを「スキーマ」と「インスタンス」に置き換えることが主眼となっていたのだが、Algebraic Property Graphではハイパーグラフも表現の射程に入っている。もちろんAlgebraic Databaseのポテンシャルとしてそれらを表現することは可能だと思うので、単純に適用範囲が広がっているとみなすべきなのかもしれない。
実装したい
実は元々、Algebraic DatabaseはJavaでの実装が存在し、Algebraic Property Graphもその拡張として実装されている現状がある。詳細は以下から辿れると思う（GitHubでソースコードも公開されており、説明もある）。 conexus.com ただ、個人的にはやっぱり自分で作ってみたいので、少し前からRustでの実装を開始してみている。まずはAlgebraic Property Graphであるが、何をどうやって作るのかを考えながら、少しずつ進めている現状である。
気が向けば、また詳細も書いていこうと思う。
転職しました
6月から新しい環境で働いている。先月も休まず働いていたので、急に切り替わった感触が強い。
規模の差
前職と現職の差は大きい。まず、人数。前職の全社員数は、今の自部署のたぶん1/3ぐらいしかいない。要するにめちゃ増えた。見渡す限り、ソフトウェアエンジニアがたくさんオフィスにいる光景はずいぶん久しぶり（初めてではない）。前職だと、例えば職場環境を改善しようとする試みがあったとしてもあまりペイしないのだが、現職は当然ながら仕組みの宝庫である。その分覚えることも多いが、幸い不条理はあまり感じていない。
フェーズの差
前職は新規事業プロダクトで、顧客を探すフェーズだったわけだが、現職は長期間運用している、全国規模のWebサービスである。プロダクトの方向性やビジネス面でどうするかといった内容を考える必要はなく、たくさんの人間の中で自分の役割を果たすことに集中できる状態。とにかく、色々と規模がでかいが、その割には身動きがそこまで取りづらいというわけでもない。
安心感の差
現職の現場はみんな忙しそうで、やることはなんぼでもあるという印象。前職とは流れる時間の感覚が違う。にもかかわらず、「やるべきタスクがはっきりしている」「それを自分が制御する必要がない」という状況のおかげでストレスはさほど感じない。人間、放置されたり日々の作業に対するリアクションがないとメンタルがやられていくもので、それはプロダクト開発の初期には多かれ少なかれ発生するものだと思うが、会社に来て作業内容が管理されているのがこんなに楽だとは、という印象。まあ、当たり前か。あと、これは風土だと思うが、みな一様に、穏やかな印象。元々の性格というより、明らかに企業全体の安定感によるものかと。ここに関しては前職に限らず、サバイバル感溢れる真逆の世界で生きてきたので、まだ少し慣れない。
技術スタックの差
転職先候補の中では、現職は最も前職との技術スタックの差が少ない（特にバックエンド）。それよりも、20年選手のWebサービスなので、レガシーな部分が存在する事実の方が、差異としては大きい。ソースコードすら見始めたばかりでまだ把握できていないものの、Python 2系も残っていてフロントはjQuery。ただ、モダナイズも複数の粒度で進んでいるし、現実的な路線で日々新陳代謝している印象。クラウドの規模も桁違いだが、そもそもインフラは担当ではないのでまだよくわからない。
社会的責任の差
現職は上場企業のため、コンプライアンス含め、しっかりしている。またそもそもソフトウェアエンジニア以外の従業員の方がはるかに多い（正社員以外も含めるとソフトウェアエンジニアは全体の2〜3割？）ので、より一般的なスキルレベルに会社全体が設定されているように見える。というわけで小さな所帯だった前職と比べると、圧倒的に「社会性」を感じる。オフィスにたくさん人がいて、全く異なる仕事内容の人がたくさんいて、全国規模のWebサービスを安定稼働させるために技術者が日々奮闘している。社会的責任の差は本当に大きい。社内手続きなどは多少煩雑だが、SIer案件などで感じていた理不尽さはなるべく緩和されているし、もしかするとそこが一番安心しているポイントかもしれない。理不尽がとても苦手なので。
男女比の差
IT企業としては女性比率は高い方だと思う。またサポート業務の部署はほとんどが女性なので、オフィスを移動していて見かける男女比は半々ぐらい、だろうか。また、私個人にしか当てはまらないが、所属チームはなんと女性の方が多い。全員、私と同じWebエンジニア担当である。元々、仕事上では同僚の性別によって態度を変えることは少ない性格のはずだが、それはたぶんバイアスがかかっている。実は一番気を使っているのは、今のところこの点かもしれない……。
COVID-19関連
さて、この点に関しては、前職でも現職でも共通である。5月まではフルリモート、6月からは出社が可能になったが新しい勤務形態を模索していく、という点でも同様。というわけで初日からみんな私たち新入社員（そういえば、新入社員が同日に複数入ること自体が久々で新鮮だった）の相手をするよりは、席替えや飛沫防止シートの設置（ソーシャルディスタンスのため）、在宅勤務に関する事項が多かった。部署全体ミーティングもZOOMで行われたし、私もあたふたしながらカメラに向かって自己紹介することとなった。これからは週2で出社していくとのことだが、こればっかりは大都市圏は特に共通の状況だろう。
まだ3日なのでたかが知れているし、どんどん忙しくなっていくに違いないけど、ひとまずはご報告でした。5月にも色々勉強したしその話もしたいけど、改めて。
