architecture

The Essential System Layers（本質的システム階層）

混沌とするシステム技術の世界における羅針盤

AIの台頭、ローコード/ノーコード（LCNC）の急速な普及、そして絶え間なく進化するフレームワークやインフラ技術。現代のソフトウェア開発を取り巻く環境は、まさに「混沌」と表現するのが相応しいでしょう。新しい技術が次々と登場し、あっという間に古くなる、そんな変化の波に乗り遅れまいと、多くのエンジニアが表面的なトレンドに目を奪われがちです。

長年のキャリアの中で、私は「技術は常に変化する」という現実を肌で感じてきました。しかし、だからこそ、目先の技術に囚われず、「本質」を見極め、変化の激しい時代を生き抜くための確固たる思考の軸が必要だと強く感じています。

このエントリでは、私自身の経験と試行錯誤の中でたどり着いた、システム構築における「The Essential System Layers（本質的システム階層）」をご紹介します。これは、技術を単なるツールの羅列としてではなく、それぞれの層が論理的に連携し、システム全体を構成する「必須」の要素として捉えるための、私なりのメタ認知フレームワークです。

「The Essential System Layers」が示す、システム構築の7層構造

私の提唱する本質的システム階層は、システムの根源にある「なぜ作るのか」という問いから、ユーザーが実際に触れる「最終的な成果」に至るまでを、段階的かつ相互依存的な7つのレイヤーとして表現します。各層は「選択」と「行使」のプロセスを内包し、全体として一貫したシステム構築の流れを示します。

第0層: 根源層（Root Layer）: 仕様 & ビジネスドメイン

この層は、システムが作られる以前から存在する、システム構築の「前提」となるものです。7つのレイヤーに含めることで、技術的な選択が常にビジネスの目的と要件に基づいて行われるべきであることを強調しています。

  • 役割: システムの存在意義と目的を定義する、すべての出発点。「何を（What）解決すべきか」「なぜ（Why）それを作るのか」を明確にします。技術的な制約から独立した、純粋なビジネス上の要件、顧客の課題、市場のニーズ、そして最終的なビジネス価値がここに集約されます。

第1層: 論理設計層（Logical Design Layer）: ドメインモデリング & アーキテクチャ設計

  • 役割: 第0層のビジネス要件を受け、それを技術的に実現可能な「論理的な形」に落とし込む層です。ビジネスルール、データ構造、システム全体の振る舞い、主要コンポーネント間の関係などを、具体的な技術実装に依存しない形で設計・定義します。システム全体の骨子を決定する、最初の「選択」が行われる場です。

第2層: 実装手段選択層（Implementation Means Selection Layer）: 開発パラダイム & 技術スタック選定

  • 役割: 第1層の論理設計を実現するための、具体的な開発手法や主要な技術スタックを決定する層です。開発速度、コスト、複雑性、保守性などを考慮し、最適なアプローチを選定します。

    • AI（コード生成、自動化エージェント）やローコード/ノーコード（LCNC）ツールは、特定のビジネスロジックや定型処理を迅速に実装する際の強力な選択肢です。ただし、この層における安易な選択は、後に不必要なコストや非効率を招くこともあります。
    • 各種プログラミング言語（Python, TypeScript, Goなど）は、より複雑なカスタムロジックや、性能が要求される部分に選択され、きめ細やかな制御を可能にします。

    AIの位置づけについて: 近年注目を集めるAIは、このレイヤーにおいては、あくまで「実装手段の選択肢の一つ」として捉えられます。AIは、特定のタスクを自動化したり、コードを生成したりする強力なツールですが、システムの根本的な設計やドメインモデリングに直接的な影響を与えるものではありません。

第3層: コード・ロジック層（Code & Logic Layer）: ソースコード & 個別ミドルウェア実装

  • 役割: 第2層で選択された手段を実際に「行使」し、第1層で定義された論理設計を具体的なコードや設定として表現する層です。

    • プログラミング言語で記述されたアプリケーションコードや、その開発を効率化するフレームワーク（React, Spring Bootなど）がここで活用されます。
    • LCNCツール上での設定や、AIの挙動を制御するプロンプト/モデルの定義、さらにはデータベースのスキーマ定義など、各ミドルウェアがアプリケーションロジックと連携するために必要な具体的な実装や設定もこの層で行われます。ここが、「実装」の主戦場です。

第4層: 実行環境層（Execution Environment Layer）: 実行エンジン & コンテナ技術

  • 役割: 第3層で作成されたコードや設定が実際に「動く」ための、抽象化された実行環境を提供する層です。

    • Java Virtual Machine (JVM) や Node.js (V8) といった言語ランタイム、そしてDockerやKubernetesなどのコンテナ技術が、アプリケーションの動作環境を標準化し、隔離します。ここも、「実行環境の選択と設定」が行われる場です。

第5層: インフラ基盤層（Infrastructure Foundation Layer）: クラウドインフラ & 仮想化

  • 役割: 第4層の実行環境を稼働させるための、仮想化された、あるいは物理的な基盤を提供する層です。

    • AWS, Azure, GCPなどのIaaSが、サーバー、ネットワーク、ストレージといったITリソースを抽象化して提供します。物理サーバーや仮想化技術もここに属します。

第6層: 物理・制御層（Physical & Control Layer）: ハードウェア & オペレーティングシステム (OS)

  • 役割: すべてのデジタルシステムが最終的に依存する、最も低レベルな物理的・論理的基盤です。

    • CPU、メモリ、ストレージなどのハードウェアと、Windows、Linux、macOSなどのオペレーティングシステム（OS）が、上位層のソフトウェアを支える最終的な土台となります。

第7層: 出力・ユーザー体験層（Output & User Experience Layer）: 具体的な機能・ユーザー体験

  • 役割: システムが最終的にユーザーに提供する価値、インターフェース、そしてそれによって生まれる体験の層です。

    • 第0層のビジネスドメインが、すべての層を経て具体化され、ユーザーが直接触れ、認識し、利用する最終的な機能やインターフェースがここに現れます。

「The Essential System Layers」がエンジニアにもたらす価値

この本質的システム階層は、単なる技術の分類に留まりません。複雑なシステム構築において、エンジニアが確かな視点を持つための強力なツールとなります。

  1. 適切なツール選択の指針:
    各層の役割と特性を理解することで、表面的なトレンドに流されることなく、目の前の課題にとって本当に最適な技術やアプローチを選択できるようになります。AIやLCNCを過大評価することなく、また従来のプログラミング言語の重要性を見失うことなく、バランスの取れた判断が可能になります。

  2. 問題の特定と解決能力の向上:
    システムで問題が発生した際、それが「仕様理解の不足（第0層）」に起因するのか、「設計の誤り（第1層）」なのか、「手段選択のミス（第2層）」なのか、「コードの実装バグ（第3層）」なのか、あるいは「実行環境やインフラの問題（第4層～第6層）」なのかを、この階層構造に当てはめて素早く特定し、効率的に解決に導くことができます。

  3. キャリアパスの明確化と「本質」を見抜く力:
    自身のスキルがこの構造のどの層に位置し、今後どこを深めるべきか、あるいは広げるべきかを戦略的に考えるための羅針盤となります。技術の表面的な変化に惑わされず、各層の「本質」的な役割を理解することで、エンジニアとして長期的に価値を生み出し続ける力を養うことができます。

  4. 新しい技術の本質とその影響を素早く把握する力:
    昨今のAIやLCNCのように、新しく登場した技術がどの層に位置するのかを見極め、それによりどんなことを解決してくれるのかをスムーズに理解するための一助となります。また、新しい技術が自身のフォーカスする層にどのような影響があるのかを理解し、どのくらいの速度で変化していくのかを見定めるためのツールとなります。

変化の時代を生き抜くエンジニアとして

テクノロジーの進化が加速する現代において、エンジニアはますます複雑な課題に直面します。しかし、このように体系化されたメタ認知を持つことで、私たちは単なる「技術の利用者」から、その「技術を真に理解し、使いこなす設計者」へと進化できるはずです。

例えば、AI技術の進歩と普及は一見何もかもを覆してしまったように見えるかもしれません。しかし、このメタ認知に当てはめて考えるならば、AIは主に第2層（実装手段の選択）に関わる技術であり、システムの根本的な設計やドメインモデリングに直接的な影響を与えるものではない、と冷静に判断することができます。

この本質的システム階層というフレームワークが、あなたのシステム開発における意思決定、問題解決、そしてキャリア形成の一助となれば幸いです。

event

[Event]NT函館2025で出展した話

NT函館ってなんだ？

NT函館 というイベントをご存じない方のためにかんたんに説明すると、だいたい以下のような感じです。

  • NT = Nanka（なんか）Tsukuttemita（つくってみた）の略とのこと。要するに、ものづくりに関する展示イベントになります。
  • 趣味でつくってみたものや自分の好きに作ってみたものが一斉に集まり展示され、さまざまな技巧・趣向が凝らされた作品がおよそ55点展示されました。
  • ソフトウェア・ハードウェア、やたらデカいロボットや座禅訓練マシーン、公道走行可能なミニカーなど、良い意味でイカれてる作品ばかり。

NT函館のほかにもNT東京、NT札幌、NT金沢などがあるようです。

すごい展示たち

ひとまずこいつらを見てくれ！すごい！すごすぎる！

自動演奏する鉄琴。下にコイルと鉄くぎで作った「ハンマーユニット」がずらりと並んでおり、あらかじめ設定された楽曲を奏でる。

レーザー電子ハープ。レーザーを手などで阻害すると（手は焼かれずに）音がなる。テクノっぽい。

座禅訓練マシーン。座面に感圧センサーが数か所設置されており、姿勢が揺らぐと「雑念がある」とみなして喝を入れられる。

他にもたくさんありました。

私の展示

私は「ハコダテ縦断ウルティメイトクイズ」というものを展示しました。なんとHSP3で作った雑なコードでありますが、とりあえずエンタメに振り切ったものとしました。

ただ開発期間が短く、バグ取りまではしきれなかったですね。

ちなみに、ある程度クイズを勝ち上がった方には「ニューヨク行きチケット」をお配りしました。良い湯だな～ってなってくれたら幸いです♨

感想

月並みかもしれませんが、まぁめっちゃ楽しかった～！時期にもよるけど、次はもっとものづくりに振った展示を出したいな～！と思った次第でした。

event

[Event]きのこカンファレンス2025に参加した話

きのこカンファレンスこと「エンジニアがこの先生きのこるためのカンファレンス2025」に参加してまいりましたので、そのレポートです。

前夜祭

前夜祭では「Perlの生きのこり ～ペアプロ解説～」と題しまして、kobakenさん(@kfly8)との共同登壇をさせていただきました。

事前に企画に関するエントリをnoteでも公開してあったのですが、一部の方々からの期待値が結構高まっていたようでして、盛り上げ役としては絶対に面白くしてやるぞ、という覚悟をもって登壇に臨んだ次第です。

詳しい発表内容についてはkobakenさんのエントリに委ねるとして。

楽しかったに決まってますよ、最高でした！＞@kfly8

そしてこのような機会をいただけて、本当にありがたいことです。とにかくPerlの歴史を楽しく伝えつつ、今のPerlの様子を見てもらいたい、という狙いは達成できたかな、と思います。欲を言うならば、今度はこれを2時間くらい使ってもう一度やりたいですね！

とにかく前夜祭は大盛況でした。雰囲気を伝えるべく、Xをペタペタと貼っていきます！（引用させていただいたツイ主の皆さま、NGでしたら わいとんに遠慮なくお申し付けください。「許可を求めるな謝罪せよ」のスタンスでやらせていただいております！）

YAPC::Fukuoka 2025 の宣伝

マジでみんな来てくれ！！！！

みんなPerlやってるかい！？

だって「やってる！」って返事が帰ってこなかったもんだから・・・

CGI、Lambdaに似てないっすか？

いやLambdaっていうかFaaSがCGIっぽいんですよ？

令和のPerl

若干ほかの言語に見えなくもない

Claudeはラクダの夢を見るか

AIとPerlは親和性高いって私は思っていますよ

酒カスムーブ

最後に残ったわずかな獺祭の処分に運営さんがちょっと困っていたのでつい・・・

当日

当日は午前中に野暮用を済ませる必要があり、午後からの参加となりました。

前日夜にスマホを充電し忘れたまま寝てしまい、バッテリー残量の都合上、あまり積極的にツイートできなかったのですが、まず感想を率直に表すと、めっちゃ楽しかったです！

印象深かったトーク

  • 「働きママエンジニア」、看板もそろそろ畳みます！ 無冠のわたし、これからどう先生きのこれる？ - たかのあきこ
    • まずスライドが全部手書き、しかも筆ペンか毛筆のどちらかで書かれていて、見ていてとってもほっこりするデザインでした。
    • 「働きママエンジニア」としての状況の変化と、それに合わせてキャリアのチャレンジの枠をどんどん広げていく様子、そして最後に「はたらくマダムエンジニア」としてのあゆみを進める、というストーリーラインがとても素敵なものでした。
  • フルリモートでも生き残る。たとえ日本中からフルリモ案件がなくなったとしても。 - 株式会社Sanukite（サヌカイト）　代表取締役　水尾峻輔
    • フルリモートのお仕事そのものがコロナ禍のころと比較して激減した、というものの、コロナ禍以前はもっと状況は悪かったし、そういう意味では今は低空飛行で今後も層だろう、との見通しは、だいぶ似たようなことをやっている経営者として、共感を通り越して一種のシンパシーを感じました。
    • リーダー経験、顧客折衝あたりができるとリモートでは強い、というのも「その通り！」と思いながら聞いていました。共感できる点が大変たくさんあったトークでした。
  • AIが台頭する時代のエンジニア進化論：価値探索とAI-Human Interfaceのスペシャリストへ - おだかとしゆき
    • AIが生み出す価値と張り合うのは人間には無理で、AIではできない部分、つまり最終的な判断、とくに野性に基づく判断ができるのは人間にしか為しえないというのはなかなか面白い考え方だなと思いました。困難な状況に対応し生き抜くための力としての野性は、確かに人間じゃないと出来なさそうですよね。
    • ある種、ハードシングス的な考え方がAIとは違った人間ならではの本領なのかもしれませんね。
  • 変わりゆくもの、変わらないもの。 - 米久保 剛
    • ゲームチェンジャーとしていくつかのIT技術は、これまでおおむね10年おきに登場してきましたが、そのたびに変容をもとめられるのがエンジニア。でも、そんな中でも変容しないものが厳然として存在しますよね、というお話でした。
    • とくに具体→抽象→高度な抽象→別の具体、というような、具体と抽象の間を意識的に行ったり来たりするというのをすることが「変わらないもの」を体得する上で重要である、というのは印象深かったです。

スマホのバッテリー10%前後で写真撮ったりしてた

天気がよいときの台場は本当に景色がいいんですよね。

ここでもしっかりとYAPC::Fukuoka 2025を宣伝。

みんなの歴史年表を見て思ったこと

懇親会、アンカンファレンス、その他

  • カンファレンスの食事は本当に大変。何が大変って量のコントロールが大変。
  • カンファレンスのゴミ処理問題、それを解決するだけのビジネスを立ち上げたら需要はあるのではなかろうか？儲からなさそうだけど。
  • レアなキャリアを突き詰めていくと、職業名が自分の名前（もしくは自分のハンドル名）になる未来しか想像できない。
  • 人は、好きなことで生きていきたいから起業するけど、好きなことにはやりたくないことも一緒についてくる。特盛カツカレーに例えると、好きなことは福神漬け程度の量で、残りの特盛カツカレーくらいの量のやりたくないことがついてくるものだ。
  • やりたくないことを淡々とこなせるのがプロ
  • エンジニアが経営をすると、数字からは目をそむけたくなる。プログラムは書くのに数字はダメなんですねーって言われがち。
  • すごい数の豪華日本酒が持ち込まれた。が、私は前夜祭でやたら飲みまくったので、懇親会ではアルコールレスアーキテクチャを貫徹しました。

さいごに

スポンサー各社のみなさん、スタッフのみなさん、そしてスピーカーのみなさん、一般参加のみなさん、本当にお疲れさまでした。そしてありがとうございます。

きのこカンファレンス、最高の体験でした！ちょっと見た目には毒気がありつつ、でもふんわり甘い香りでおいしくて、食べると気持ちよくなっちゃうきのこ、という感じで（めっちゃ褒めてます）大変良かったです！

生きのこりについて思いを馳せながらこのエントリを書きました！本当にありがとうございました！

perl

[Perl]他の言語にあるアレをもって来ようぜって話

このエントリはPerl Advent Calendar 2024の22日目のエントリとなります。

他の言語にあるアレとは

皆さん、Perl触ってますか？Perlを触っている方もそうでない方も、ご自身がよく使う言語にあるメジャーなライブラリや大変有用な基礎機能というものがあると思います。私が思いつくところですと、例えば以下のようなものでしょうか。

  • C#におけるLINQ
  • F#におけるパイプライン演算子
  • Goにおけるgoroutine
  • RubyにおけるMix-in
  • ElixirにおけるLiveView
  • PHP/LaravelにおけるLivewire
  • などなど・・・

とにかく、いくつかの言語で実装されている便利なやつ、ということを言いたいのです。

で、最近私はTypescriptという言語を触る機会が多いのですが、この言語では大変有用なライブラリがたくさん作られ、提供されています。一部をご紹介します。

  • Prisma ORM : Typescript向けに作られたORM。スキーマ変更に対するケアが素晴らしい。
  • Zod : データバリデーター。非常に複雑なデータ構造に対するスキーマをシンプルに記述できる。
  • Biome : ソースコードのフォーマッティングと構文解析を行うツール。品質の高いコードには必須。

Perlにも便利なものを持ってきてもいいじゃないか

近ごろは、Perlにとって明るい話題というのをなかなか聞かなくなってきたなぁと思うようになりました。個人的にはPerlは好きな言語ですし、私がまともにITエンジニアとして食っていけるようになるきっかけとなった言語ですので、末永く便利に使いたいものだと思っています。

そんなことを考えていたある日、先ほどご紹介したZodというバリデーターの存在を知り、業務でも利用するようになりました。このZodの便利なところは、とにかくスキーマを細やかに指定できるというところであり、そのスキーマ自体が変数として取り扱うことが出来る点です。

例えばご当地バーガーショップのレシートデータを構造化しようと考えた場合、そのデータスキーマを設計する必要があります。注文された商品とその点数、テーブル番号、値段などがデータスキーマに含まれる必要があることでしょう。

Zodで表現するならば、だいたい以下のようになるかと思います。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
import { z } from 'zod'

// 商品単品のスキーマ
const itemSchema = z.object({
  // 商品名。便宜上30文字までとしてある
  name: z.string().max(30), 
  // 商品価格。便宜上10万円までとしてある
  price: z.number().min(0).max(100000), 
})

// 注文のスキーマ
const orderSchema = z.object({
  // 商品オブジェクト。どの商品を注文するのかを表す
  item: itemSchema, 
  // 注文数。一度に同じ商品を20個まで注文できる
  amounts: z.number().min(1).max(20), 
})

// 担当者のスキーマ
const staffSchema = z.object({
  // 担当者ID
  id: z.number().min(1), 
  // 担当者名。便宜上30文字までとしてある
  name: z.string().max(30), 
})

// レシートのスキーマ
const receiptSchema = z.object({
  // テーブル番号。1～45まである店舗ということにする
  tableNumber: z.number().min(1).max(45), 
  // 注文の一覧
  orders: z.array(orderSchema),
  // 注文された日時の記録。デフォルトで現在時刻が記録される
  orderedAt: z.date().default(new Date()), 
  // 注文受付担当者
  staff: staffSchema,
})

こういう感じのスキーマ定義を、型がとても緩いPerlでも使えるようにしたら便利では？と思い、移植してみました。それが拙作のCPANライブラリであるPozです。

https://metacpan.org/pod/Poz

Pozのつかいかた

Pozをインストールする場合は cpanm などのPerlモジュール管理ツールをお使いいただくのが最も簡単です。

1
$ cpanm Poz

では、先ほどZodで表現してみたご当地バーガーショップのレシートデータ構造化スキーマを、Pozでもやってみます。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
use strict;
use utf8;
use Poz qw/z/;
use Time::Piece ();

# new Date() の代わりを作っておく
my $new_date = sub {
  Time::Piece::localtime->strftime('%Y-%m-%dT%H:%M:%SZ');
};

# 商品単品のスキーマ
my $item_schema = z->object({
  # 商品名。便宜上30文字までとしてある
  name => z->string->max(30), 
  # 商品価格。便宜上10万円までとしてある
  price => z->number->min(0)->max(100000), 
})->as('BurgerShop::Item');

# 注文のスキーマ
my $order_schema = z->object({
  # 商品オブジェクト。どの商品を注文するのかを表す
  item => $item_schema, 
  # 注文数。一度に同じ商品を20個まで注文できる
  amounts => z->number->min(1)->max(20), 
})->as('BurgerShop::Order');

# 担当者のスキーマ
my $staff_schema = z->object({
  # 担当者ID
  id => z->number->min(1), 
  # 担当者名。便宜上30文字までとしてある
  name => z->string->max(30), 
})->as('BurgerShop::Staff');

# レシートのスキーマ
my $receipt_schema = z->object({
  # テーブル番号。1～45まである店舗ということにする
  table_number => z->number->min(1)->max(45), 
  # 注文の一覧
  orders => z->array($order_schema),
  # 注文された日時の記録。デフォルトで現在時刻が記録される
  ordered_at => z->datetime->default(sub { $new_date->() }), 
  # 注文受付担当者
  staff => $staff_schema,
})->as('BurgerShop::Receipt');

なるべくインターフェースをZodに寄せてありますので、ほぼZodの使い方と一緒です。

違うとことがあるとすれば、 ->as('BurgerShop::Receipt') のあたりでしょうか。これは本家Zodにはない指定でして、Zodの場合は構造体の型を z.infer で生成することができるのですが、Perlの場合はHashRefに型を紐づけたい場合、blessするほかありません。

そのような言語の特性を吸収するべく、バリデーションが通ったHashRefについては as(...) で指定したクラスのオブジェクトとしてblessしてしまおう、という対応をとっています。

なお、実際にバリデーションを行うときには以下のようにします。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
my $data = {
  table_number => 10,
  orders => [
    {
      item => {
        name => 'チーズバーガー',
        price => 250,
      },
      amounts => 2,
    },
    {
      item => {
        name => 'ポテト',
        price => 150,
      },
      amounts => 1,
    },
  ],
  staff => {
    id => 1,
    name => '山田太郎',
  },
};

# データを検証
my ($result, $error) = $receipt_schema->safe_parse($data);

上記の例では safe_parse を使っていますが、本家Zodと同じように parse も使えます。ここら辺のインターフェースもZodによせてありますので、Zodに慣れている方であれば違和感なくご利用いただけるのではないでしょうか。

なお、この時以下のテストが通ります（実はこのエントリを書いていてバグに気が付いたので、急いで直して、v0.03をリリースしました・・・！！）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
# エラーは無し
is($error, undef, 'expected no error');

# テーブル番号は10番
is($result->{table_number}, 10, 'table_number is 10');

# オーダー一覧はBurgerShop::Orderインスタンスの配列になっている
is_deeply($result->{orders}, [
  bless({
    item => {
      name => 'チーズバーガー',
      price => 250,
    },
    amounts => 2,
  }, 'BurgerShop::Order'),
  bless({
    item => {
      name => 'ポテト',
      price => 150,
    },
    amounts => 1,
  }, 'BurgerShop::Order'),
], 'orders is correct');

# スタッフもBurgerShop::Staffのインスタンスになっている
is_deeply($result->{staff}, bless({
  id => 1,
  name => '山田太郎',
}, 'BurgerShop::Staff'), 'staff is correct');

# 注文日時がデフォルト値（現在時刻）となっている
like($result->{ordered_at}, qr/^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}Z$/, 'ordered_at is correct');

まあまあ複雑なデータ構造もいい感じに検証されており、無事に検証を通過したデータは適切にblessされているのがわかります。ちょっと頑張りましたね！

kuraとの連携

Perlの型ライブラリに kura というものがございまして、これはMetaCPANにある様々な型ライブラリのうち、 Data::Checks, Type::Tiny, Moose::Meta::TypeConstraint, Mouse::Meta::TypeConstraint, Specio などを横断的に使えるようにしてしまおうという、大変意欲的なものとなっています。

なんと、ありがたいことに、kuraの作者である こばけんさん からPozにコントリビュートをいただいており、 既にkuraとの連携 ができるように調整いただいております。本当にありがたいことです。

1
2
use Poz qw(z);
use kura Name  => z->string->min(1)->max(255);

というか、Pozをリリースしてから2日以内くらい？でこれが出来るようになっていたんです。すごくないですか・・・？

まとめ

ZodをPerlに移植したようなバリデーター「Poz」を作った話をさせていただきました。

別の言語で使える便利そうなやつをPerlに持ってくるというのは、かなり楽しいです。

今のご時世、AIによるサポートを得ながらライブラリの開発ができますが、今回作ったPozもGitHub Copilotを存分に活用して開発しました。なかなか簡単に作れたので、ちょっとPerlに元気を与えたいと思った方にはぜひともチャレンジしてもらいたいなと思います。

elixir

[Elixir]Ash Frameworkに入門しようとしたら準備がちょっと大変だったので、devcontainerを整備して簡単に始められるようにした

このエントリはElixir Advent Calendar 2024 シリーズ3の15日目のエントリとなります。

Ash Framework とは？

Ash Frameworkは、Elixir製のWeb Frameworkです。

Zach Daniel氏(@ZachSDaniel1)が開発しており、ResourceとActionという概念を包含したDomainが特徴で、コーディング量が少なめながらも実用的なアプリケーションの開発ができるように作られているようです。

試したかったものの、手元ですぐに確認できる環境がない・・・！

実はAsh Frameworkについてはdaimon.exというイベントにて知りました。是非試したい！…と思ったのですが、ここしばらくはElixirと遠い生活を送っていたので、手元にElixirな環境もなく、なかなか試す機会を作れずにいました。

しかし、せめてこのエントリを書くためには多少触っておきたい。どうすれば…

よろしい、ならばdevcontainerだ。

そこで、今回はdevcontainer環境の準備をして、Get Startedの冒頭だけでもできるところまで持っていくぞ！ということにしました。

作ったのが https://github.com/ytnobody/ash-devcontainer となります。

実際にAsh Frameworkを試した様子をREADME.mdに記載してありますので、同じ手順でGet Startedの冒頭を試すことができます。

使い方

VSCodeをお使いの場合、Dockerがインストールされていることが条件ですが、devcontainerというVSCode拡張がありますので、これを使って起動できます。

devcontainer起動直後、すぐに iex および mix igniter.new を利用することができます。

あるいはgithub codespaceを使うのもいいでしょう（私はこちら側でした）。

Ash Frameworkの感想

まだそこまでしっかり触れていないのですが、Domain配下にResourcesとActionsがまとまっているのは一貫性を感じます。

Elixirという言語特性上、副作用について切り分けるというところをどこまでやるかは使い手に委ねられそうな気はしましたが、そもそもコード記述量がやたら少なくて済みそうな雰囲気は感じており、小さめのアプリケーションをAshで作って動かし始めてみるのがまずは良さそうかなと思いました。

さいごに

どうにかAsh Framework入門をちょっとだけすることができました。少しでもAsh Frameworkを触ってみようっていう人に届けば幸いです。

Event

YAPC::Hakodate 2024をやるぞ！と言い、YAPC函館市電LTもやった

※このエントリは、私わいとん 個人 の飾らぬ思いであります。

YAPC::Hakodate 2024の実行委員長という大役を仰せつかってからおよそ7か月、2024-10-04に前夜祭、2024-10-05に本編、2024-10-06にアフターイベントをそれぞれ開催し、無事に閉幕までやり遂げることができました。

たくさんの方々・企業のみなさんに貴重なお時間とお力を割いていただいた結果できたことです。ありがとうございます。私自身も大変楽しませていただきました。

写真コーナー

なかなか当日は忙しいこともあって写真を撮る余力があまりなかったのですが、その中でも撮影したものを載せておきます。雰囲気が伝わるといいのですが。

YAPC::Hakodate 2024はアートである（と私は勝手に思っている）

※ここから先は小難しい話が続きます。面倒な方はここで読み終わりとしてください。

YAPCをはじめとしたイベントはMICE(マイスと読む。Meeting, Incentive travel, Convention, Exhibition の頭文字をとった略語)と呼ばれるものに相当するでしょう。学びを共有するためだったり、コネクションの開拓を促す目的などで開催されることがほとんどではないでしょうか。YAPC::Hakodate 2024(以下、YAPC函館)についてもそのような側面は持ち合わせていますので、これは間違いなくMICEに分類されるイベントであると考えてよいはずです。

一方、YAPC函館はアートであると私は考えます。アートというのは心を豊かにするモノやコトであるとここでは定義します(美術の範囲に限らない広義の用途を意図しています）。

YAPC函館に参加された方は、多少なりとも感情あるいは知的好奇心を大いに揺さぶられたことではないかと想像します。そして次のYAPCにも参加したい、という思いを持ったことでしょう。

この感情・知的好奇心の高まり・思いが生じたことこそが、YAPC函館がアートであることを示しています。人はアートを通じて知的・心的欲求が高まり、次のアートを求めるのではないでしょうか。

YAPC函館がアートであるならば、そのデザイン手法について説明せねばなりません。そうしないと、YAPCは一点ものアートのままになってしまいます。アートであり、かつ工芸品でもあるものにしないと、作り手に依存したままの存在になってしまいます。

ましてやYAPC函館はイベントなので、必ず緩やかに風化していくのが定めづけられています。次に続くYAPC実行委員長（ビキニキさん）が、より楽しくYAPCの企画を推進できるように、YAPC函館と私の事例について共有します。

やるぞ！と言った理由

YAPC函館開催の顛末については概ね YAPC::Hakodate 2024 非公式予習会を開催しました！ - inSmartBank に書かれている通りとなります。

しかし「私がYAPC函館をやるぞ」と言った理由についてはちゃんと答えていなかったですね。概ね以下の通りとなります。

  • 函館への経済効果を期待した
  • 函館および北海道の情報技術系の学生/学府との交流を活性化したかった
  • 都市圏の企業に函館をより解像度高く知ってもらい、函館にITの仕事を増やすきっかけを作りたかった

なんでお前はそんなに生まれ故郷にこだわるのか

これについては端的に「涼しくて飯が安くてうまい函館、良いべえ？」と思っているからです。

しかしながら、ITの（に限らないが）仕事が少なすぎるという弱点があまりにも強すぎるため、手放しに「良いべえ？」とは言い切れない。現に私自身が工業高校を出て就職をしようとしたとき(1998年)に、地元企業の求人票が全然なかったことを今でもはっきりと覚えていますし、本当は地元を離れたくなかったけど、当時は仕事のために東京の会社に就職するしかなかったんです。

であればどうすればその弱点を克服できるか、という事をまあまあ度々考えてしまうわけですが、そのための「もがき」なのかもしれないですね。

YAPCのイベントとしてのフレームワーク性

個人的な観点となりますが、YAPCでは以下のフォーマットが踏襲されるべき大きなポイントであろうと思います。

  • 前夜祭を行う場合は不採択となったプロポーザルに復活の機会を与える
  • 本編は休日・祝日
  • メイン会場は最低でも300人程度が一斉に集まれる
  • LTがあり、キーノートがある

上記の他にはスポンサーに関するフォーマットなどが考えられますが、ここでは割愛します。少なくともJPAがこの点についてはしっかりとバックアップしてくれたので大変助かりました。また、実行委員長としては熟知するよりすぐ調べられる状態にするのが現実解かと思いました。

もちろん開催にまつわるドキュメンテーションや数字などを事前にまとめておいて、それを脳に焼き付けておくことがベストだと思いますが、私の能力ではそれがうまくできなかったので、次善策で対処したといったところです。

イベントのデザイン手法

では、今回のYAPC函館をやるぞ！といった理由について実現度を高めるために、私がどんなことを考えていたのかを明らかにしていきます。

前夜祭

前夜祭は以下の事を意識して司会という役割を務めさせていただきました。

  • YAPCで紡がれてきたつながりを引き継いでいく場を提供する
  • シニアエンジニアも学べる場にする

そのために、次のようなイベントデザインを心がけました。

同窓会としてのYAPC前夜祭をデザインしたかった

YAPCは過去に国内で複数回開催されています。元々はPerlのカンファレンスだったのですが、近頃は以前のYAPCで知り合った人同士が再会を果たす「同窓会」のような機能も期待されていると感じています。

それであれば、「同窓会」に参加してくれる人がまた来たくなるようなイベントにする必要が出てきます。下記のような話題は経験豊富なエンジニアやマネージャー、YAPCガチ勢に好まれる傾向にあると考えます。

  • 古いシステム/環境などの話
  • Perlの話
  • マネージメントの話

また、同窓会らしさを演出するのであれば、コミュニケーションをとるためのツールも必要になります。つまり、飲食です。ここはその土地の色を出せるところですので、以下のような選択をするのが良いだろうと考えます。

  • 地元のソウルフード
  • 地元のクラフトビール
  • その他、地元色が出せる食べもの・飲みもの

地元色を出すことで、経済面でも地元への貢献度が向上するので、これは絶対におススメしたいです。

30代/40代がさらに上の世代から学び取る場をデザインしたかった

YAPC自体が歴史の長いイベントであるということを考慮すると、同窓会を期待している人は確実に30代オーバーということになります。ええ、もちろん私も例外ではなく、もう少しで44歳になります。

私も含め、30歳オーバーの参加者がさらに先輩の世代の生の体験談から得られる学びは間違いなく貴重な体験だろうと考え、50代付近の登壇者をピックアップして座談会を企画しました。

YAPCというブランドで紡がれてきたつながりを次の世代にも体験してもらいたかった

アンカンファレンスについてはアイスブレイクとしての役割を持たせたつもりだったのですが、テーマを公開する機会を逸した結果、最初のタイミングでは誰も反応しないという状況でした。あとAIにテーマを作ってもらった結果、思った以上に「重い」という感想をいただいており、このへんはちょっとしくじったな、と。

どうにかしてアイスブレイクさせなくては・・・と悩んでいた矢先に、見覚えのある @moznion 氏が何やら楽しそうにビールを飲んでいたので、つい「レガシーシステムの刷新について何か言いたそうですね？」という無茶ぶりをして登壇させたのでした。彼が登壇してすぐに言っていた通り、これは仕込みナシです。コーナーが終わった後に彼が私に軽く文句を言うであろうところまで私の中では織り込み済みでした。

結局私の目論見は見事に当たり、@moznion, ma.la, @dankogai, macopy, @pastakなど（敬称略）による解説と見解、そして若干の漫談のようなものを交えながら、見事に場が盛り上がったのでした(見ての通り、最初の10分くらいはほぼmoznion自身のコンテンツ力のおかげですが)。

このようなやり取りを見て、特にYAPC初参加の方や学生などの若い世代の人々に、YAPCで紡がれてきたつながりを感じ取っていただけたのであれば本望です。

本編当日

本編は前夜祭とは大きく変わり、以下を重要視していました。

  • 技術について語り合う場にする
  • これでこそYAPCだと思わせる
  • 年齢・属性関係なしに楽しく学べる場にする
  • 前評判や偏見を取り除き、Perlの良さを再確認してもらう
  • 次のYAPCにも参加したいと思ってもらえる会にする

そのためにどのようなことをすればよいか、というのを自分なりに考え、以下のような指針でイベントデザインをしたつもりです。

年代に関係なく学びのある場を作りたかった

例えばエンジニア組織のマネジメントに関する話題は、ある程度成熟したエンジニアにとっては学びとなり得るものだと思います。しかし、これからプログラミングを学んでいく若者にとっては、いきなりそのような話題を聞かされたところで、なんのこっちゃ、となってしまうはずです。

ですので、なるたけ技術的な学びが得られそうなプロポーザルを採択する傾向となりました。これは、技術的な学びについては、技術カンファレンスに来ているのだから、ある程度多くの人が興味があるはずだろう、という考えに基づいた判断です。

YAPCじゃないと聞けない知見を集めたかった

いくら技術的な学びがあったとして、「YAPCで話すことが相応しい」プロポーザルでなければ通すことはできません。これは例えば、そのプロポーザルはほかのカンファレンスのほうが受け入れられるであろうという内容であれば、優先度を下げる必要があったということでもあります。

今回はとくに、Perlについて触れているプロポーザルを積極的に採択しました。しかしそれでも「Perl成分は薄めだった」という感想もあったようで、それだけPerlについて話そうとしたプロポーザル自体が少なかった、ということだと思っています。

様々な技術に対するフラットな視点を持ち帰ってほしかった

YAPCはPerlのカンファレンスですので、Perlに関するトークに触れて、少しでもPerlについて興味を持っていただきたかった、という気持ちがありました。

Perlに対する様々な視点をお持ちの方もいらっしゃることは承知していましたが、それでもひとつの技術としてフラットに捉えてほしいですし、それはPerlに限らずほかの技術についても全く同じことを思っています。

好き嫌いで触る技術を選ぶのも結構なことだと思います。しかし、一辺倒な視点から脱却するには、まったく異なるものをまっさらな意識で触れてみること、そしてそのようなことに慣れる必要があると考えました。

とくに若い世代の皆さんには「温故知新」の精神でPerlをはじめとした技術に触れてほしいと思ったのです。

技術に熱中する人々とその情熱を知ってほしかった

今回のゲストは、アカデミックな世界で活躍されている方々や若き技術者を中心にお声がけをさせていただきました。

これは、その分野の技術に情熱を注ぎ続けている人々とその軌跡を間近で見ていただくことで、技術そのものの面白さと可能性、そして技術に熱中するという生き様を知っていただきたかったのです。

市電LT

私が作って経営している会社 Y.pm LLC が主催となって開催したYAPC函館市電LTですが、こちらについては、以下の点を重視しました。

  • 函館と北海道、路面電車が好きな方を少しでも増やす
  • YAPCというイベントに強烈なインパクトを付け加える
  • 面白い技術者との交流を深める場を提供する

函館市電LTに参加するような遊び心のある人を知っておきたかった

完全に私個人の欲求の話となりますが、そもそもYAPC函館市電LTに参加してくれた人はかなり「覚悟が決まった人」だろうと勝手に思っています。そんな「覚悟が決まった人」を私としては「ぜひとも仲良くしたい」と思っています。

要するに、私は一緒に遊びを全力投球でやってくれる人が好きなんです。

自社の宣伝をしたかった

私の会社をひとことで言い表すと「零細システム開発会社」というものになると思います。

そんなシステム開発をやっている会社にとっては、案件こそが命の源泉なのです。そのために冒頭ちょっとだけ自社の宣伝をしました。会社の予算を使ってやっている以上、これはやらないといけないやつです。

その他

個人的な思いといいますか、若き日の原体験から思ってきたことを最後に書いておきます。このあたりはYAPCとは関係ない文脈になりますが、背景情報として参考になればと思います。

生まれ故郷に元気を与えたかった

正直、函館という街は国内でもかなり苦戦を強いられている斜陽都市のひとつです。ここ最近は某アニメ映画やインバウンドのおかげもあって観光業とその周辺はなかなか景気が悪くない様子ですが、付加価値の高い第三次産業が弱いこともあって、ITに関する仕事も例にもれず大変希少な状況です。

そのため、恐ろしい勢いでの人口流出と自然減、高齢化の進行が深刻な問題となっていて、私が生まれた当初(1980年)はおよそ35万人直前程度の人口がいましたが、現在ではとうとう25万人を割ってしまい、今ではおよそ23.7万人程度となっています。2040年には17.5万人程度になると予想されています。

深刻なのが生産年齢人口の減少です。1980年におよそ23万人の生産年齢人口がいましたが、2025年には大体12.5万人にまで減少するとされています。2040年には10万人を下回り、8.8万人程度まで減少するだろうという予想がされています。

一方、生活ガイド.comの全国住みたい街ランキングでは39位となっており、そこそこ健闘しているなあという風に思いました。

こんな感じで、全般的に衰退する未来が予想されている一方、多少住んでみたいとは思われている（けど実際に住む人は少ない。家族の意見もあり、私自身もいまだに函館には戻っていないですし。）という、なんとも難しい状況なのが私のふるさと「函館」です。

良い面もたくさんあります。涼しいし飯がうまいし安い。人が多すぎない。風光明媚な自然が盛りだくさん。ただ、市民に元気を与える話題がちょっと少なすぎやしないかと。

なので、何らかの大き目なイベントを呼ぶことで街の経済活性につながるのであれば、それにはできる範囲で協力しようと思い、YAPC誘致に名乗りを上げた次第です。

函館に住んでいる若者が函館で働くことをあきらめない未来に近づけたかった

そもそもなぜこんなに生産年齢人口が減少しているかというと、端的に街に仕事が少なすぎるのです。地方都市ではよくある話ではありますが・・・。

それでも、特に情報通信業の有効求人者数は令和4年から比較して令和5年では485.7%にもなっているので、少しずつIT化の波が函館にもようやく届き始めているのかもしれないです。

また、未来大や函館高専という情報系学科をもつ学府が函館には存在しますが、ITに関わる求人数はまだまだ彼らの多くに対してリーチするには少なすぎるというのが現状です。その一方で、開発拠点を函館に置き始める企業も出てきているようです。

まとめ

  • YAPC函館は一点もののアートである
  • やると決めた理由は「函館に元気を与えたかった」「未来大などの情報系学科の学生と大企業のつながりをもたらしたかった」

最後に御礼を

ごちゃごちゃと書きましたが、YAPC函館を無事終えることが出来たのは、以下の皆さまがご協力くださったおかげです。

  • 参加者の皆さま
  • 登壇者の皆さま
  • 当日スタッフの皆さま
  • JPAの皆さま
  • スポンサー企業の皆さま
  • 未来大の角先生
  • 未来大企画総務課の吉田さま
  • 未来大生協の本間さま
  • キッチンカー（函館ナントカ食堂, くいだおれ太閤, てつまるケータリング）の皆さま
  • 清掃事業者の皆さま

皆さま、本当にありがとうございました。そして、コアスタッフ(@__papix__, @karupanerura)の二人には特に感謝しています。

絶対自分のせいで面倒なことになった部分もあったのに、きわめて冷静沈着に状況をよくしようと立ち回った@karupaneruraには本当に助けられましたし、@__papix__には気持ちの面やアイデアが出てこなかった時に心強いフォローをいただきました。

私自身も「必ずやり遂げるし、やるからには絶対に成功させるぞ」という気概をもって取り組ませていただきましたが、彼ら二人の情熱はそれを凌ぐものがありました。でも、健康面にはもう少し気を配ってもいいんじゃないかって思います。さすがに睡眠の質がよろしくなさそうな話を聞いた時には割と本気で心配しました。今は良くなっていることを祈ります。

あと、広島の三次会？で生じた風のうわさを教えてくれた @myfinder にも感謝しています。彼はいつも私の尻に火をつけるのがうまく、今回も私に「YAPC函館の機運が来たかもしれませんよ？これはやるしかないんじゃないですか？」と立ち飲み処で教えてくれました。このムーブがなかったら今回はほかの地域での開催となっていたか、開催が見送りとなっていたのかもしれません。

とにかく、開催できてよかったと思っています。本当にありがとうございました。

Book

書評：アーキテクトの教科書 - 価値を生むソフトウェアのアーキテクチャ構築

「設計ナイト」つながりで、@tyonekuboさんから献本いただきました！

大吉祥寺.pm参加録でも書いた通り、本書（通称：オレンジ本）の著者である米久保剛さん(@tyonekubo)から献本いただきました。この場を借りて改めて御礼申し上げます。ありがとうございます！！！

せっかく献本いただいたので、これは読んでブログに書くしかない！ということで、本書の書評を書きます。

本書の概要

アーキテクトの教科書 価値を生むソフトウェアのアーキテクチャ構築 (米久保 剛 | 翔泳社)

本書は、アーキテクトとしてのスキルを身につけるための教科書です。アーキテクトとは、ソフトウェアのアーキテクチャを設計し、開発チームに指針を示す役割を担う人のことを指します。

全6章からなる本書は、以下のような内容になっています（以下目次より引用）。

  1. アーキテクトの仕事
  2. ソフトウェアの設計
  3. アーキテクチャの設計
  4. アーキテクチャの実装
  5. 品質保証とテスト
  6. アーキテクトとしての学習と成長

よくもまあここまで絞り込んだものだと思います。本来はもっと内容を盛り込みたい、という欲があると思うのですが、それを抑えてこの6章にまとめたのは、著者の経験と知見が詰まっているからこそだと思います。

推しポイント

実コードを交えた説明が簡潔

本書は、アーキテクチャの設計や実装に関する説明が大変簡潔でわかりやすいです。特に、実コードを交えた説明が多く、理論だけでなく実際のコードを見ながら学べるのが良いですね。

Javaがコード例として使われていますが、かなりシンプルなコード例ですべて説明しきっているため、他の言語を使っている人でも十分に理解できると思います。

数多くの図表があってイメージしやすい

アーキテクチャの設計や実装に関する説明は図表が多く登場し、イメージしやすいです。アーキテクチャごとの違いや目的、考え方の違いがそのまま視覚的に示されているため、理解が深まります。

これは、アーキテクチャの設計や実装に関する知識が浅い人にとっては、非常にありがたいですね。

実践的なアーキテクチャの設計に関する知識が得られる

ベテランが読んでも役に立つレベルの内容が書かれていると思いますが、初心者が読んでも理解できるように書かれているのが良いですね。

私もそこそこ長いことIT業界でエンジニアとして働いていますけど、名前は聞いたことがあっても触れる機会がなかったアーキテクチャについて、本書を読んで理解が深まりました。

また、過去に自分がやってきた設計についても該当するアーキテクチャがあって、利点について再認識できたのも良かったです。

分厚すぎず、デカすぎない。何度も読める手軽さ

本書は、分厚すぎず、デカすぎないサイズ感が良いです。何度も読み返すことができるボリュームで、繰り返し読むことで理解が深まると思います。

さらに、この手の書籍にしては2,800円という破格で、アーキテクトとしての第一歩を踏み出すための教科書としては、非常にコスパが良いと思います。

本書をこんな人におススメしたい

  • 2年目～5年目くらいの経験を持つエンジニア
  • 設計で迷いに出くわした経験があるエンジニア
  • 設計がぐちゃぐちゃなプロジェクトに携わっているエンジニア
  • 様々なソフトウェア設計について学びたいエンジニア

私個人の意見としては、DDDについて深掘りする前に本書を読め、と言いたいです。実践的なアーキテクチャの設計や実装に関する知識を得ることができ、頭でっかちではない、地に足の着いたアーキテクトになるためのヒントが詰まっているからです。

まとめ

本書はアーキテクトとしてのスキルを身につけるための教科書として、非常に優れた内容になっています。また、アーキテクトのみならず、エンジニアとしてのスキルを高めたい人にもおススメできる内容になっていると思います。

優れた設計ができるエンジニアがいるプロジェクトでは、保全性の高いソフトウェアが生まれることが多いです。そのため、本書を読んで設計のスキルを高めることは、エンジニアとしてのスキルアップにつながると思います。

Event

大吉祥寺.pm 参加録

7/13(土)に開催されたオフラインイベント「大吉祥寺.pm」に参加したので、その記録や感想となります。

前夜祭「生存者バイアスナイト」

7/12(金)の夜、吉祥寺のビアバー「P2B Haus」で前夜祭が開催されました。お料理、ビール、トークともに大満足の内容でした。

ただ、あまり大っぴらにしづらい話題もあり（この会はそういう会でもある）、ほかの方の発表については詳細を伏せさせていただきます。一つ言えることとしては「結構考えさせられる内容だった」ということでしょう。

なお、本来登壇予定だった@studio3104さんが病欠とのことで、急遽代打を務めさせていただきました。私の発表については特におおっぴらにしても何ら困らないものですので、こちらで共有しておきます。

本編

本編は武蔵野公会堂にて開催されました。以下、聞いたセッションの中でも特に印象に残っているものについて、感想を簡単にまとめます。

基調講演 - @yasuhiro_onishi

テーマが「黒歴史」でなかなか不穏なはじまり方でしたが、その後の話を聞いていると、ようはここで言う「黒歴史」というのは「失敗を恐れずに挑戦し続けること」であるということがわかりました。

かなり意外だったのが、某ホビー系ショップの草創期に大西さんが関わっていたというのが驚きです。

むしろ大西さんにも「生存者バイアスナイト」で発表してほしかった。というか、大西さんの発表が「生存者バイアスナイト day 2」だったのかもしれません。

多様性の時代を生き抜くキャリアプラニング - @tyonekubo

「中長期のキャリアがイメージできない」「どうしたら評価があがるのか？」という質問をしたことがある人、あるいはされたことがある人、双方にとって有益な内容だったと思います。

「ゴールデンサークル理論」（Why→How→Whatの順で話すと人心に訴えかけることができるという理論）に基づき、その一番内側にある「Why」を見つけることが重要であるという話が印象的でした。

また、国内と海外におけるキャリアラダーの違いについても話されておりました。私は海外での就労経験はないのですが（かつて出張で北京に行ったくらい）、なかなか言われてみると結構な差があるんだなと感じました。

技術力でビジネスに貢献するための公式（技術力×ソフトスキル＝技術貢献力）というのもなかなか刺さる内容でしたね。

開発部に不満を持っていたCSがエンジニアにジョブチェンしてわかった「勝手に諦めない」ことの大切さ - @saku_rye

Q, なぜエンジニアになったんですか？
A, 開発部に不満があるのに、何もできない自分が悔しかったからです。

冒頭からこの感じで、エンジニアになるきっかけや、エンジニアになってからの経験談が語られていました。エンジニアになるためには「勝手に諦めない」ことが大切であるという話が印象的でした。

また、エンジニアになってからの経験談として、開発部に不満を持っていたCSがエンジニアにジョブチェンしてからの話も興味深かったです。エンジニアになることで、自分の意見を形にできるようになったというのは、なかなか感慨深いものがありますね。

一方でエンジニアとしてある程度視座が広がってきたからこその苦悩もあったようです。エンジニアになる前は「エンジニアになれば解決できる」と思っていた問題が、エンジニアになってみると「エンジニアになったからこそ見える問題」があるというのは、なかなか共感できる話だと思います。

個人的には、「勝手に諦めない。分かり合えるまで根気よく接し続ける。」というのは結構なことだと思う一方、皆が皆それだけの胆力を持ち合わせているわけではないと思うので、個々人の胆力に依存しない方法も模索していく必要があるのかなとも思いました。

組織のスケーリングと持続性 - @tunepolo

事業成長の結果、人手が足りなくなった状況下で、開発チームをスケールアウトする際のオーバーヘッドを仕組みで補うという方法とそれ以外の方法が分水嶺となるという話がありました（エンジニアの開発力を向上させる、アウトソーシングをする、人数を増やさない、の３つ）。

スケールアウトする場合も、職能ごとのチームにするのか、フィーチャーごとのチームにするのかで分けられるという話もありました。

一方、人を増やしても売上が増えない場合の逆回転についても触れられており、これはなかなか苦い経験をされたのだろうなと感じました。

共感できる部分も多かったですが、売り上げが上がっていないチームについては人を増やさない、というのが鉄則じゃないのかと思いました。仮に投資を受けて事業を大きくするタイミングで、しかし売上は伸びていない状況であれば、アウトソースをするか人を増やさずに仕組みで売上を伸ばす方法を模索していくのがいいのではないかと思いました。

その他

大井町放談というランチタイムセッションで、@myfinderさんとともに大井町.pmとして雑談タイムで登壇させていただきました。

技術の話、キャリアの話、お金の話と３つのテーマで話をしましたが、参加した皆さんに新たな気づきを与えることができていたら幸いです。

まとめ

大吉祥寺.pmは、技術者としての視座を広げることができるイベントでした。主催の@magnolia_kさん、スタッフの皆さん、登壇者の皆さん、参加者の皆さん、ありがとうございました。また、このようなイベントを開催していただいたことに感謝いたします。

その他

わいとん「あっ、バレましたか・・・」

「設計ナイト」つながりで、@tyonekuboさんから献本いただきました！

ありがとうございます！！！

@a_suenamiさんに「焼肉」をご馳走になりました！

すえなみチャンス！（概念）

ありがとうございました！

Event

YAPC::Hiroshima 2024 参加録

広島で開催されたYAPC::Hiroshima 2024に「フル参加」してきました。フル参加って言っているのは要するに「前夜祭」「本編」「YAYAPC」の3日間に参加したということです。

なんと今回、本編については何の役割も持たずに気ままに参加したのですが、これは何時ぶりですかね…たぶんYAPC::Hokkaido 2016 SAPPORO以来のことではないでしょうか。

前夜祭

前夜祭ではHono v4に関する発表があるという事で大変集中して聞いていました。いま現在、Honoでご飯を食べている私にとっては大変重要なものですからね・・・

  • v4ではクライアントサイドにも手を伸ばしており、Reactと同一の構文でコンポーネントを書くことができる
  • HonoとViteをベースにしたフルスタックフレームワーク HonoX
  • バックエンド観点でのHonoはその互換性に手を加えることなくそのままv4に移行できる

それからキャッシュバスターズの発表もありました。こちらは晩酌をしながら聞いていたのであまり覚えていませんが、聞いていて「あるあるー」「ですよねー」という感じでした。みな同じような悩みを抱えているんだなあと。

本編

今回はスピーカーでもスタッフでもなく一般参加者として参加しました。スポンサーチケットを使っても良かったのですが、直前に念のため一般参加チケットを自費購入しており、スポンサーチケットは社員におすそ分けとしました。

今回聞いたセッションは以下の通りです。割と廊下でのんびり談話していたり個人的なハックをしていたので、聞いたセッションは少なめです。

2024年冬のPerl

charsbarさんのセッションで、まさかのリモート登壇。久々にご本人にご挨拶できると思っていたのですが、おあずけになってしまいました。

主にPerlエコシステム（とくにミラーとかセキュリティなど）に関する話題と、5.38以降の新機能についての解説がありました。

  • Security Issue(SSL証明書の検証に関する問題)があるため、HTTP::Tinyは最新版（0.083 or later）にアップデートしましょう →CVE-2023-31486
  • SSLがコアに入る未来が来るかも
  • UnicodeとWindows周りでperlにもセキュリティ対応のための更新が入るのでは
  • Strawberry Perlが復活！
  • 5.38以降の新機能 （詳しくはモバイルファクトリー社のテックブログ にも書かれている）
    • 個人的には export_lexically 関数が強すぎるなーと思いました。
    • モジュール末尾に 1; を書く必要がなくなったのは感慨深いです。
  • 今後来そうなやつ
    • 特殊変数の別名 → English モジュール相当のものかな
    • 文字列テンプレート → qt<ほげ{$val}ふが> みたいにかけるっぽい
    • 条件付きアロー演算子 → $obj?->method みたいなやつ
    • メタプログラミング → Class::MOP を現代風にしたやつかな
  • 5.8.1がツールチェーンのサポート下限から脱落
    • 今後は10年以内のものをサポート
    • 今は例外的に5.16を下限とする
    • PlackやIO::Socket::IPなどが既に5.12を下限にしている
  • Rakuについて

大変久々にPerl成分を摂取できたので、大満足でした。

Go to Cloudflare Workers ～ 移行から 0.5 年以上運用する

codehexさんのセッション。Cloudflare Workersに以降してから半年経過したというNOT A HOTELのAIアシスタント周辺の話を聞きました。

  • いくつかのフェーズを経て、Cloudflare Workersに移行した
  • デプロイが速くてまるでオフライン開発みたい
  • wrangler dev だけで環境構築が終わるので簡単
  • エッジノードで処理が行われるので、レイテンシが低い
  • アプリケーションはHono
  • monorepo構成、pnpmで管理
    • .code-workspace で複数アプリをどれもプロジェクトルートとして扱える
  • 運用にはログ・監視・トレースが必要
    • 基本的にはこれらの基盤は自作かカスタマイズか
      • （後で聞いた話だとこのあたりをサポートするサービスがCloudflareにはあるらしい）
    • リクエストの最後にログのキューを作成するHono middlewareを作成
  • pnpm patch で外部ライブラリを改造
  • cloudflare discordにへばりついてバグレポなどをしているらしい。胆力がすごい。

古い技術について—SMTP現代事情つまみ食い—

azumakuniyukiさんのセッション。SMTPについての話でした。というか、もうSMTPと言ったらこの方、この方と言ったらSMTPですよ！

メールに関する技術も最近触らなくなってきていたので、情報のアップデートができてよかったです！

YAYAPC

YAYAPC::Hiroshima。実質上のDay2とか、帰ってきた大人のYAPCとかなんとか。そんな会の司会を仰せつかっており、大人のYAPCと同様に細かいことはシェアできませんが、当日の様子を一つのツイートで表したものがこれです。

欽ちゃんのスコアボードについてはこちらがベースとなっており、私のほうでWebSocket対応をさせた次第です。もっと余力があったら審査員用の物理ボタンを用意するところだったのですが・・・

広島飯＆おみやげ

正直なところ、広島飯って本当にお好み焼きと牡蛎しか知らなかったんですが、実際に行ってみると広島飯はお好み焼きと牡蛎以外にも結構バラエティに富んでいて、3日間ではまだまだ食べきれないくらいのものがありました。

お好み焼き

まぜそば

尾道ラーメン

ぷよまん

「生きとったんかワレェ！！！」

その他

まかまかさんと一緒に「広島ミックスあゆむバー」さんにお邪魔したのですが、入店するや否や女装子なあゆむさんとお客さんがテストコードの話をしていたりと、広島の懐の深さに触れることができました。聞くところによるとCOBOLerが結構いらっしゃるとかなんとか・・・あゆむさんありがとうございました！

それから、銭湯に行ったらこんなことも。銭湯民族、考えることは一緒ですね。

振り返りなど

今回は本編については特に何もせず、ただただ参加していたのですが、大変楽しい3日間でした。

広島という街の素敵さにも触れることができ、また、YAPCというイベントの素晴らしさも改めて感じることができました。

次のYAPCはどこで開催されるのでしょうか。楽しみですね。

そして広島はまたいつか行くぞ！

写真

小ネタ

うつ・ひきこもりの人に向けて、ITエンジニアとして働くことについて話してきた

昨年の12月に、うつ・ひきこもりの人に向けて、ITエンジニアとして働くことについて、オンライン講義という形式で話してきました。

事の発端

昨年の10月ころに、私の地元である函館にある就労支援事業所の「Ponte函館」さんから、講師をお願いしたいという依頼をメールでいただいておりました。

テーマは「うつ・ひきこもりの人に向けて、ITエンジニアとして働くことについて」ということでした。私の生まれ育ちや社会人経験をざっくりまとめたライフヒストリーと、ITエンジニアとして働くうえで必要なスキルや心構えなどについてを話しました。

資料について

スライドを以下に公開します。パワポ芸だったり、キャッチーな言葉を意識的に使っていることもあり、だいぶ情報商材っぽいうさんくさいスライドになってしまった点は反省しております。ただ、思ったことをそのまま書いているので、まあいいかという感じです。

色々ご意見等あろうかと思います。その場合は、Twitterにてどうぞ。但し、生産的ではないと思われる言論には反応しません。ご了承ください。

まとめ

私自身は少なくともひきこもりではないですが、過去にうつの傾向があった時期があります。そのような経験を踏まえて、今回の講義をさせていただきました。

より多くの方がITエンジニアとして働くために、何かしらのヒントになれば幸いです。