10/2更新: 1日しない間に、大変たくさんの方々にご応募いただけました。ありがとうございます。募集は終了とさせていただき、結果は選考の上お返事させていただきます
2025年初めに刊行を予定している書籍について、翻訳原稿のレビュアーを若干名募集します。翻訳は @snoozer05 が行っています。
書籍は技術執行役員（あるいはCTOやVPoE、技術統括など）としてエンジニアリング組織をリードする立場になった後に遭遇する課題やそれを乗り越えるためのアプローチ、考え方、スキルについて学ぶ内容となっています。次のような方々を対象とした書籍です:
具体的な書名は募集時点では規約により明かせないため、レビューに参加頂いた方のみにお知らせいたします。悪しからずご理解くださいませ。
募集期間は最大で1週間程度(~10/8)とし、応募状況によってはそれよりも手前で締め切らせていただきます。
興味がある方がいらっしゃいましたら、以下のURLよりぜひご応募をお願いします。
翻訳を担当した書籍『スタッフエンジニアの道ー優れた技術専門職になるためのガイド』（オライリー・ジャパン）が来週（2024年8月26日）発売となります（電子書籍はオライリー・ジャパンのサイトでの販売となります）。本書は、2022年にO'Reilly Mediaより刊行されたTanya Reilly著『The Staff Engineer's Path: A Guide for Individual Contributors Navigating Growth and Change』の全訳となります。
本書は、技術専門職としてのキャリア成長に必要な考え方やスキルを、20年を超えるキャリアを持ち、現在も現役で上級技術専門職を務めている著者が、自身の経験をもとに整理・解説した書籍です。
具体的な目次は次のようになっています。
第I部 大局的な思考
1章 では、具体的に君はここで何を？
1.1 スタッフエンジニアとは一体何なのか？
1.2 ご高説ごもっとも。で、私の仕事は何？
1.3 役割を理解する
1.4 スコープ、形状、重点事項を一致させる
1.5 まとめ
2章 3つの地図
2.1 あれ、誰か地図は持ってきた？
2.2 ロケーターマップ：観点を手にいれる
2.3 トポグラフィックマップ：地形を学ぶ
2.4 トレジャーマップ：向かう先は？
2.5 あなた自身の旅
2.6 まとめ
3章 全体像を描く
3.1 シナリオ：SockMatcherには計画が必要です
3.2 ビジョンとは何か？ 戦略とは？
3.3 働きかけ
3.4 作成
3.5 ローンチ
3.6 ケーススタディ：SockMatcher
3.7 まとめ
第II部 実行
4章 限りある時間
4.1 全部やる
4.2 時間
4.3 リソース制約
4.4 プロジェクトを選ぶ
4.5 まとめ
5章 大規模プロジェクトをリードする
5.1 プロジェクトのライフサイクル
5.2 プロジェクトの始まり
5.3 プロジェクトの推進
5.4 まとめ
6章 なぜ止まってしまったか？
6.1 プロジェクトが動いていない。動かすべき？
6.2 あなたは迷子
6.3 たどり着いた……どこに？
6.4 まとめ
第III部 レベルアップ
7章 今はあなたがロールモデル（お気の毒さまながら）
7.1 良い仕事をするとはどういう意味？
7.2 有能であること
7.3 責任ある行動を取ること
7.4 目的を忘れないこと
7.5 先を見据えること
7.6 まとめ
8章 良い影響力を広げる
8.1 良い影響力
8.2 アドバイス
8.3 教育
8.4 ガードレール
8.5 機会
8.6 まとめ
9章 この先は？
9.1 あなたのキャリア
9.2 現在の役割
9.3 ここからの道のり
9.4 リセットする準備
9.5 選択が重要
9.6 まとめ
スタッフエンジニアの「スタッフ（staff）」は、軍事用語における「参謀（staff）」を指します。
参謀（さんぼう、独: Stab、英: staff、仏: État-Major）とは、作戦・用兵などに関して計画・指導にあたる将校 ...（略）... 軍隊において部隊の指揮系統は単一であるために、あらゆる決心は指揮官が単独で行う。しかしながら高級指揮官は軍事作戦を指揮統制するために処理すべき情報や作業が膨大なものとなる。これを組織的に解決するために参謀組織が情報収集、情報処理などの面で高級指揮官を補佐することとなる。そのために指揮官に対する発言権は認められていたとしても、部隊の指揮権は持たない。
こうした役割を求められるスタッフエンジニアという具体的な職も存在する一方、シニアよりも上位の技術専門職（インディビジュアルコントリビューター, IC）には、一定こうした役割が期待されます。そのため、職位としてのスタッフエンジニアと区別して、こうした働きが求められるシニア以上の技術専門職をまとめた総称として「スタッフ+（スタッフプラス）」という呼称も出てきています。
本書は、ソフトウェアエンジニアリングの専門家として、組織やビジネスを現場から独立した形で支えることが期待される、そうした上級技術専門職に求められる考え方やスキルを解説した書籍です。
スタッフエンジニア、スタッフプラスの役割を解説した書籍としては、もう一冊、Will Larsonの『Staff Engineer: Leadership beyond the management track』（邦訳『スタッフエンジニア：マネジメントを超えるリーダーシップ』）が存在します（本書の著者であるTanya Reillyが序文を書いています）。
ソフトウェアエンジニアが、マネジャーやCTOといったマネジメント職に進むのではなく、技術力を武器にテクニカルリーダーシップを発揮して、エンジニアリング職のキャリアパスを登っていくための「指針」と「あり方」を示します。
Will Larson自身はスタッフエンジニアではなくマネージャーであり、Will Larsonの方の書籍は、実際のスタッフエンジニアへのインタビューなども含め、スタッフエンジニアの仕事を外側から整理した書籍となっています。
一方、本書『スタッフエンジニアの道』の著者であるTanya Reillyは長いキャリアを持つ現役のスタッフエンジニアであり、本書はスタッフエンジニアの仕事を内側から整理した書籍となっています。
両方の書籍に目を通すことで、スタッフエンジニアという役割がより立体的に理解できると考えます。
本書の序文は『エンジニアのためのマネジメントキャリアパス』（オライリージャパン）のCamille Fournierが執筆しています。
本書は、技術系マネージャーとそれを目指すエンジニアに向けて、IT業界の管理職に求められるスキルを解説する書籍です。テックリードからCTOになった経験を持つ著者が、管理職についたエンジニアが歩むキャリアパスについて段階をおって紹介します。インターンのメンターから始まり、テックリード、チームをまとめるエンジニアリングリード、複数のチームを管理する技術部長、経営にかかわるCTOやVPと立場が変わることによって求められる役割について、それぞれの職務を定義しながらくわしく説明します。
経緯は序文に詳しいですが、『エンジニアのためのマネジメントキャリアパス』の原書のタイトルは『The Manager's Path』、本書のタイトルは『The Staff Engineer's Path』となっており、両者は姉妹本の関係にあります。
エンジニアリングのトラックに進むのか、マネジメントのトラックに進むのか。それぞれの書籍は、自身の今後のキャリアを考えるヒントになってくれます。今後のキャリアについて考えている/ 考えたいという方は両方に目を通してみると、良いキャリアパスのヒントが得られると考えます。
多くの研究や文献が存在するマネジメント職と異なり、技術専門職のキャリアを進める際に参照できる情報はまだまだ多くありません。
日本国内でも、昨年（2023年）にWillの書籍の訳書が出版され、スタッフエンジニアという役割についての理解が少しずつ広まりつつあります。そこに本書も加わることで、国内でも上級技術専門職の仕事や役割への理解、そしてエンジニアリングリーダーシップについての議論がますます深まっていくことと思います。
本書が、エンジニアリングリーダーシップの道を進んでいく方々にとって有益なガイドになることを願っています。
「エブリン……何してる？」
「あなたの戦い方を学んでいる」
映画『Everything Everywhere All at Once』より
翻訳を担当した電子書籍『Ruby on Rails パフォーマンスアポクリファ』が発売となりました。 書籍は以下から購入できます。
本書は、2020年に出版されたNate Berkopec著『The Ruby on Rails Performance Apocrypha』の全訳です。原書は訳書と同様、著者の販売サイトで自主出版の電子書籍として出版され、現在はKindleストアでも販売されています。
The Ruby on Rails Performance Apocrypha
本書は、Nateがニュースレター「Speedshop Ruby Performance Newsletter」に公開してきた記事を編集してまとめたものです。Nateが注力し続けている Ruby on Rails アプリケーションのパフォーマンスやスケーリングの話題、ソフトウェアパフォーマンスの一般原則、RubyについてのNateの考えなどがまとめられてます。具体的な目次は次のようになっています。
第1章 原則
1.1 私が大切にしていること
1.2 パフォーマンスの科学
1.3 なぜパフォーマンスか?
1.4 あなたはコンパイラではない
1.5 10%の高速化が本当に意味すること
1.6 Rails アプリケーション向けのベンチマーク
1.7 自分用のAPMを作る
1.8 フレームグラフを読む
1.9 DRM(データベース、Ruby、メモリ)
1.10 デザイン空間におけるパフォーマンス
1.11 マイクロサービスとトレンド
1.12 Minitestについて
1.13 Rubyに対する企業のサポート
1.14 なぜRubyは遅いのか?
1.15 人気
1.16 臭い依存関係
1.17 なぜキャッシュするのか?
1.18 スタートアップにおけるソフトウェア品質
第2章 フロントエンド
2.1 簡単なフロントエンドの設定変更
2.2 常にCDNを使用する
2.3 ページ容量とフロントエンドの読み込み時間
2.4 遅延読み込みを簡単に
2.5 リソース優先順位付けとは何か
2.6 HTML ON THE WIRE
第3章 Ruby
3.1 例外:静かでもタダではない
3.2 スレッドセーフについて
3.3 GVLとは
3.4 GVLを時分割する
3.5 GVLとC
3.6 肥大化
3.7 最低限必要なRails
3.8 誰も使わなかった奇妙な設定
3.9 オブジェクト割り当て
3.10 常に本番用プロファイラを使用する
3.11 ローカル環境で問題を再現する
3.12 ワーカーキラー
3.13 クエリーキャッシュとは?
3.14 NewRelicのRubyVMタブを読む
3.15 テストセットアップ
第4章 スケール
4.1 消費時間とは
4.2 リクエストキュー時間
4.3 アムダールの法則
4.4 スレッド数
4.5 CPU律速かIO律速か?
4.6 スワップとは何か
4.7 データベースプール
4.8 シングルスレッド性能
4.9 リードレプリカ
4.10 なぜLambdaなのか?
4.11 Performance-Mは決して使わない
4.12 日次での再起動
本書はニュースレターに書かれてきた記事が元になっているため、Railsのパフォーマンスに関して体系的にまとめた書籍というよりも、パフォーマンスをテーマとした技術エッセイ集的側面の強い一冊に仕上がっています。しかしながら、そうした技術エッセイ集的な読み心地には、なんとも言えない「良さ」を感じます。
かつては、『ハッカーと画家 コンピュータ時代の創造者たち』（オーム社）や『BEST SOFTWARE WRITING』（翔泳社）、『プログラマが知るべき97のこと』（オライリージャパン）をはじめとする『〜が知るべき97のこと』シリーズなど、ソフトウェア技術者によるエッセイ集が多く出版されていた時期があり、技術書としても人気を博していました。
Rubyに関わりが深い著者による同系統の書籍として、『達人プログラマー ―熟達に向けたあなたの旅― 第2版』（オーム社）や『情熱プログラマー ソフトウェア開発者の幸せな生き方』（オーム社）などを思い浮かべる方も多いのではないでしょうか。こういったエッセイ集から私たちが学んでいたのは、単なる新しい技術や知識というよりも、ソフトウェア技術者としての哲学や心構え、考え方でした。
しかし、ブログブームの終焉や出版業界の状況なども相まってか、昨今はこうした書籍を商業出版で見かける機会は減ってしまいました。
そういった状況の中で本書を読み、訳者が久々に感じたのは、上記のような書籍を読んでいたときに感じていた「良さ」に似た味わいでした。
本書は、Web（特にRailsによるWebアプリケーションによるWebアプリケーション）のパフォーマンスについての書籍ですが、それと同時に、Nateというソフトウェア技術者の考え方や哲学に触れることで、私たち自身のソフトウェア技術者としての考え方を深めたり、普段の開発への取り組み方を見つめ直したりするきっかけになる書籍でもあります。
本書を通じ、一人でも多くの方に、訳者が感じた原書の味わいが届けられればと願っています。
Nateは、現在は日本に暮らしており、日本語での情報発信も積極的に行なっています。 本書を気に入られた方、気になった方は、ぜひ彼の活動に触れてみてください。
7/11更新: 1日しない間に、大変たくさんの方々にご応募いただけました。ありがとうございます。募集は終了とさせていただき、結果は選考の上お返事させていただきます
2024年冬頃に刊行を予定している書籍について、翻訳原稿のレビュアーを若干名募集します。翻訳は @snoozer05 が行っています。
翻訳している書籍は『Software Architecture and Decision Making: Leveraging Leadership, Technology, and Product Management to Build Great Products』になります。
書籍紹介より
リーダーシップの知識を活用し、より良いソフトウェアアーキテクチャの決定を下そう。深く考えた上で、ゆっくりと実装しよう。
ソフトウェアシステム（ソフトウェアアーキテクチャ）を構築する私たちのゴールは、品質基準を満たし、長期間または定められた期間、最高の投資収益率（ROI）をもたらすシステムを構築することだ。
優れたプロダクトは、テクノロジー、リーダーシップ、プロダクトマネジメント（UXを含む）の組み合わせから生まれる。リーダーシップとは、不確実性を管理し、適切な決定を下すことを指す。優れたプロダクトを作るには、リーダーシップ、プロダクトマネジメントの知識を組み合わせて、適切な決定を下していく必要がある。技術的なミスの多くは、これら3つに関する知識と判断力のギャップから生じる。
本書は、ソフトウェアアーキテクトが深く理解しなければならない原則と概念を解説するものだ。そして不確実性を管理するために、それらの原則を活用する方法についても説明する。本書で取り上げられる質問と原則は、ソフトウェアアーキテクチャを構築する際の不確実性を管理し、意思決定していくためのフレームワークを提供する。本書は、構築するシステムに関して総合的な判断を下すソフトウェア業界のすべての技術リーダー、そしてそうした技術を学ぶ将来のリーダーのための書籍だ。
募集期間は最大で1週間程度(~7/17)としますが、応募状況によっては早めに締め切らせていただきますので何卒ご了承ください。
興味を持っていただける方がいらっしゃいましたら、以下のURLよりぜひ応募をいただけますと幸いです。
2024年6月29日(土)にHOKKAIDO x Station01をお借りしてえにしテック15周年記念カンファレンスを開催しました。
当日はたくさんの方々にお越しいただき、おかげさまで、とても特別な15周年を迎えることができました。参加いただいた皆さま、あたたかいメッセージをいただいた皆さま、登壇いただいた高橋さん、角谷さん、大場さん、平鍋さん、美味しいコーヒーを出していただいた猫廼舎さん、運営をつつがなく取り仕切ってくれたメンバーのみんなに感謝します。ありがとうございました。
正直、まだあの場がなんだったのかをきちんと飲み込みきれておらず、きちんとした総括はできない感じなのですが、何かを書いておかないと先に進めない気がしているので、一旦カンファレンスのことを書き残しておこうと思います。
15周年の節目、何をしたいかと考えて出てきたのは、一番に初心に返って勉強会がしたいなという気持ちでした。
なぜ会社の初心で勉強会かというと、株式会社えにしテックの出自は、Ruby札幌 というコミュニティにあるからです。
Ruby札幌は、2006年に島田が発起人となって始まったコミュニティです。Ruby札幌では、運営チーム（@darashi、@tmaeda、@noplans、@mrkn）やそこに集まってきてくれた人たちと一緒に色んなことにチャレンジしてきましたが、その始まりは島田がRubyを勉強したくて始めた Ruby勉強会＠札幌という勉強会でした。
その初心に立ち返って、今島田が話を聞きたい方々を呼んで、島田が一番前でその人たちの話を聞き、そこから何かを受け取るという場・時間を、今の会社のみんなと一緒に経験したい。それが最初に立てたこの会のコンセプトでした。
そして、講演は島田やえにしテックにとって繋がりのとても深い高橋さん・角谷さん・大場さん・平鍋さんの4名にお願いしました。
それから猫廼舎さんも。日本Ruby会議2007からの付き合いであるogijunさんも、ぼくらにとってはカンファレンスに欠かせない特別な存在で。猫廼舎さんにコーヒーを提供してもらうカンファレンスをする（しかも札幌で！）ということも、この会の大事なコンセプトの1つでした。
会期中のことは、まだまだ全然冷静に振り返れないので、感情の断片を残しておきます。
前方で角谷さんが「わかってしまったなー‼︎」って言いながらスライドの準備してて、後方で猫廼舎さんが試しドリップして試飲を提供してるカンファレンス会場、前日の光景として控えめに言って最高だったなあ #enishitech
— Koji Shimada / 島田浩二 (@snoozer05) 2024年6月28日
この時点で、何だか特別な感じがしていたんだなあ。
札幌でお会いできるのを楽しみにしています！
— 🌲juneboku🌲 (@juneboku) 2024年6月27日
イベントのハッシュタグって指定のものはありますかね…？今日から移動している人たちもいるし、ワイワイできたらうれしいな〜と思えてきました🙌
このメンションをもらった途端、何だかX（ソーシャルメディア）がTwitter（ソーシャルネットワーク）に戻ったような印象を覚えました。このままこの流れの中でみんなで決めるのが「正しい」と感じて、そのように振る舞いました。ここでハッシュタグが定まったのもとても良かったし、このやりとり自体もイベントのテイストに作用するとても大事な場面だったと感じています。
ここから先考えるべき問いをもらうキーノート。The One Person Framework、概念圧縮、消極的自由と積極的自由。
主催したカンファレンスで角谷さんがこんなに生き生きと講演してくださったことがまず何よりも嬉しく、師匠の高座を横で学ばせてもらっていました。そしてちりとてちん...
bsky.appあらためて、ちりとてちんのオープニングから始まったカンファレンスのハイライトが、コミュニティへの「ふるさと(概念) 」の伝搬というのは、なんだかとてもすごいことが起きたんじゃないか……という気がしている。夢……だったのかもしれない #enishitech
— Koji Shimada (@snoozer05.bsky.social) 2024-07-04T08:55:23.283Z
えにしテック15周年カンファレンスの準備をしていて、大場さん @nay3 の『Rubyの教えてくれたこと』を改めて見ている。同じ方向に向けて似た旅路を歩んでいる先輩が突然目の前に現れた衝撃があって、すごく励まされた感じがあったんだなあ https://t.co/9kdn9FUIZc
— Koji Shimada / 島田浩二 (@snoozer05) 2024年6月27日
大場さん。前日に思い返していたのと同じで、今回もまた、大場さんの背中にはとても励まされたし、新しい人たちも同じように励まされていて、やっぱり大場さんはかっこいいなあと感じていました。
平鍋さんとしまださん#enishitech pic.twitter.com/55OwPGRhjU
— いづ (@izumii19) 2024年6月29日
全体をライブで総括していく平鍋さんは、やっぱりすごくて、かっこいい。これもまた師匠の高座を学ばせてもらっている感覚が強くありました。もっと時間をゆっくりとって、平鍋さんの話もじっくりと聴きたかったけれど、それはまたこの先のどこかで。
ぼく側の視点から見た平鍋さんとの歴史:
お寄せいただいたメッセージ、心に染みました。ありがとうございました。 #enishitech
— Yoji Shidara (@darashi) 2024年6月29日
これまでご縁のあった方々のメッセージ、当日かけてくださった言葉、感想。どれも大切な宝物になっています。本当にありがとうございます。
そして、今回は新しい人たちも覗きに来てくれていて、それもとても嬉しい出来事でした。そうした新しい人たちは、ぼくからはとても素敵に映っていて。あの空間を一緒に過ごしてもらえて良かったなあと感じています。
お祝いをしにいったら、お祝いしてもらっちゃった気分。人間関係のエクササイズだからね。ありがとうございました。今後益々のご発展を！お互いに。どう発展するといいんでしょうねえ、発展てなんですかねえ、みたいなの、今後も相談させてくださいませ！ #enishitech
— MOROHASHI Kyosuke (@moro) 2024年6月30日
「会社」がこんなふうに祝われるというのは何だろう...というのがうまく解釈できないでいたのですが、「えにしテックとはRubyコミュニティという土地に生えてきた芽であり、その芽を祝うというのはRubyコミュニティ（土地）そのものを祝うことであり、Rubyコミュニティとはそこに集う人たち自身であるなら、それは自分たち自身を祝う場であった...みんなでみんなを祝福する場だったのかもしれない」とみなさんの感想を読んでいて感じるようになってきています。
本当に特別な1日となりました。改めて、カンファレンスにご参加いただいた方、そして、これまでえにしテックに関わりのあったすべての方々に感謝します。ありがとうございました。
野辺へ出てまいりますと、春先のことで、空にはヒバリがピーチクパーチクピーチクパーチクさえずって、下にはレンゲたんぽぽの花盛り。かげろうがこう萌え立ちまして、遠山にはふあ〜っと霞の帯をひいたよう。麦が青々と伸びて菜種の花が彩っていようかという本陽気、やかましゅう言うてやってまいります、その道中の陽気なこと！ 〜「ちりとてちん」より
技術顧問先で、一生懸命コードに向き合っているプログラマーになりたての方から、次のような質問をもらいました。
最初に面談した時、1年後にいいコードが書ける、上手に書けることを目標にしましたが、 先日スクール時代の同期（それぞれRubyの会社で働いている）と話したところ、会社ごとにレビューの仕方やコードに関する基準がさまざまなようで、良いコードとはなんなのか疑問に感じました。「いいコード」とは、みたいな部分で島田さんの考え方をお聞きできたら嬉しいです。
この質問にぼくは次のような回答をしたのですが、「この質問が来たら他の人はどんな回答するんだろうな」に興味があるので、ここにしたためておきます。もしよかったら「若者にこれを聞かれたら自分ならこう答える」をコメントなどで残していってもらえたら嬉しいです。
とても大事な疑問を見つけられたんだなあと思います。
「良さとは何か」ということに向き合う必要のある質問だと思って考えています。 ものの良さ=質というものには、大きく
の2つが存在しますよね。 たとえば、映画（音楽でもアニメでも小説でも、なんでも自分のイメージしやすいものに置き換えてもらって大丈夫です）を例にとると、次のような感じです。
ここで、難しいのは、この「主観としての良さ」と「客観としての良さ」というのは、常に一致するわけではないというところにあります。
「自分は良いと思っても、世間では評価されていない」「世間ではとても評判だけど、自分にはイマイチ良さがわからない」
そして、世間の中でも、あるところでは絶賛されているけど、あるところでは問題視されている、なんていう風に評価がぶれていることも多々あります。
こうしたギャップが生じるの起きるのは、「良さ」は、その良さを測るシチュエーション（何を評価する場面なのか）と誰が評価するのか変わってきてしまうからだと考えます。
さらに、自分自身の評価も、対象に関する知識が増えたり経験によって変わっていったりします（例：映画をたくさん見ることで、映画の見方がわかってくる）。
今回、Sさんが感じた「よくわかんなくなった」は、この辺りがこんがらがってしまったんじゃないかなと想像します。
スクール時代の同期の話や今の仕事で書いているときに求められるコードの質は「客観としての良さ」についてのことで、「1年後にいいコードが書ける、上手に書ける」というのは「主観としての良さ」についてのことに当てはまると思ったからです。
そうだとして、どうしたらいいの？という話なんですが、客観の良さについてはシチュエーションや相手によって変わるのは仕方なく、良さを評価される立場にいる場合には、そのシチュエーションで求められる品質を満たすコードを書いていくしかない、ということになるかなと思います。
求められているのが自分がクリアするのが厳しい品質である場合には、主観の良さを鍛える良い機会になるでしょうし、逆に主観の良さを超えないものであった場合には、その仕事の制約の中で自分が満足できるコードにどれだけ到達できるかがポイントになってくると考えます（仕事でコードを書く場合には、期限という大きな制約があるので、完全に自分として納得のいかないコードの場合でも、要求される品質は少なくとも満たす、というところで先に進む必要が出てくるという感じです）。
いずれにしても、Sさんが立てた「1年後にいいコードが書ける、上手に書けること」に進むためのアプローチとしては、許された制約の中で、自分として精一杯のコードを書き続ける、そしてその結果がどんなコードだったか（満足いくものになっているか、何かたどり着けなかった部分があるか、制約がなかったらどうやれるか）をちゃんとふりかえっておく、ということになるんじゃないかなと思います。可能であれば、コードや設計についての勉強も続けられるとより良いです。
上記を継続していく過程で、間違いなく、少しずつ「こういったコードが良いコードだ」というのが自分の中に積み重なっていくはずです。
更新: 無事に在庫全てにご応募いただけたため、募集締め切らせていただきます。ご応募ありがとうございました!!
翻訳した書籍の在庫が増刷などで手元に増えてきたので、お読みいただける方にそれぞれお譲りしようと思います。
以下のフォームから応募いただいた方に先着でお送りいたします。特に応募に条件などはありません。
https://forms.gle/kGkQJ7qVGJDdXiYG9
全部の本が捌け次第フォームは閉じます。また、レターパックで送ることになるので、届くのは連休明けなるかと思います。
もし読んでくださる方がいらっしゃいましたら、ご応募お願いします。
