サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
TGS2024
nekogata.hatenablog.com
社内で書いた内容から、一般化できる話だけを抜き出して書いた記事です。 TL;DR 意思決定者は、 仕様が複雑になればなるだけ、指数関数的かつ継続的にコストがかかることを理解する必要がある。 ユーザーの要求や利便性について優先順位をつける必要がある。 それらを揃えた上で「いっちゃんいいバランスで顧客要望に応える」必要がある。 コストについて サービスあるいは機能の一生 サービスあるいは機能は以下のライフサイクルを辿る 初回リリース以前 初回リリース以後、クローズ以前 クローズ 実は一番コストがかかるのが「初回リリース以後、クローズ以前」の部分。なぜならサービスの一生のうちほとんどの時期がここなので……。 初回リリース以前にかかるコスト いわゆる「初期開発」が行われる。 当然、この時に仕様がシンプルであればあるだけ初期開発にかかるコストは低くなるし、仕様が複雑であればあるだけ初期開発にかかるコ
uzullaさん主催の「みんなで作るテックカンファレンス」のya8に参加してきました。 わたしはアンカンファレンススペース担当として、二日間アンカンファレンススペースの切り盛りをさせていただきました。アンカンファレンスのキモは「一方通行ではなくて参加者みんなで議論する」だと思っているのですが、実際二日間においてほとんどずっと活発な議論が行われていて、参加して発言してくださったみなさんに大変感謝しています。しかも、「いつメン」の同窓会ではなく、いろんな方が発言してくださっていて、ほんとうにいいアンカンファレンスになったなと思っています。 議論の内容については余裕ができたら改めてまとめるかもしれません。 さて、実は私は、約5年ぶりくらいのカンファレンス参加でした。長い間カンファレンスに出席していなかったのには実は理由があります。詳しい理由は控えるのですが、ひとことで言うと、以前「自分とテックコ
組織やチームはそれぞれルールや文化、仕組みを持っている。この仕組みやルール、文化はときに外部から見ると「アンチパターン」に陥っているようなこともある。そのとき、「アンチパターンを抜け出してベストプラクティスを」と言うのは簡単だけど、実際にそこから抜け出すのは「言う」のと比べるととても大変なことだ。なぜなら、多くの仕組みやルールは複雑かつ有機的に絡まり合って現在の「仕事のフロー」を形成しているからだ。自分の職能の範囲だけで改善しようと思っても、仕事は自分の職能の範囲では完結せず、「他の職能のやり方がこうだからベストプラクティスは採用できない」となってしまいがちだ。こういう「変えるのが大変」という状況をぼくは「チームの慣性力が働きすぎている状態」と呼んでいる。 では、この慣性力に負けないためにはどうすればいいのだろうか。ぼくは心構えとしては以下のようなことを考えている。 文化や仕組みを変えるの
よく、「仕事の属人性を排除して、仕組みやルールで標準化すべき」ということが言われる。これは決して間違えていないと思うけど、一方で片手落ちだと思う。たしかに、労働集約型の事業においては、「人数を増やせば増やすほど利益につながる仕組みやルール」を作ることが大事になるだろう。一方、知識集約型の事業においては、これは必ずしも真ではないと思う。 言ってみればあたりまえのことだけれど、ルールや仕組みは、増えれば増えるほど労働は平準化されていく。労働集約型の事業においては、「ローパフォーマーを減らすこと」のほうが、「ハイパフォーマーにさらに高いパフォーマンスを発揮してもらうこと」よりも重要だ。だって数がたくさん必要なんだもん。そのため、ハイパフォーマーにとっては「枷」になってしまうようなルールや仕組みであっても、その仕組みを課すことでローパフォーマーでも一定のアウトプットが出ることが重要となる。つまり、
「顧客中心主義」という言葉を振りかざすひとは胡散臭く感じてしまうが、一方で重要な考え方であるとも思うアンビバレントがある 労働についての話。 労働をしていると、「どうしてうちの組織はこうなってないんだ」とイライラすることはだれにでもあると思う。というか、そういうイライラを失ってしまったとしたらそれはもう理想を失っているということで、改善の機会を失っている。理想と現実の間のままならなさにイライラしながらも顧客（その顧客は社内の別の部署かもしれないが、それが最終的にエンドユーザーに届くロジックは強固にたてついていないといけない）に対してなんらかの価値を提供して対価を得るのが労働だとさえ思う。 ところで、この理想を実現するためにはどうしたらいいのだろうか。理想を知ること、理想の状態を想像することは簡単だけど、このままならない現実を理想に近づけるためになにかを変えるというのはすごく大変だ。このギャ
2023年度を迎え、所属するバンドも新しい音源の制作としてレコーディングを開始しました。わたしの所属するバンドは、2度ほどいわゆる「エンジニア付きレコーディングスタジオ」でレコーディングをしたのですが、そのあとの音源制作は、基本的に私がエンジニアをしてDIYレコーディングを行っています。わたしがバンドでDIYレコーディングを始めたときは、まだ音楽のお仕事でお金をもらい始める前のできごとなので、まごうことなき「アマチュアによるDIYレコーディング」です（でした）。 さて、ところで、エンジニアさん付きのレコーディングプランの価格を調べてみたことがありますか？ 調べるとみなさんびっくりされると思います。たとえばスタジオノアのレコーディングプランでは、スタジオ代に追加で ￥24,200- 支払えば、きちんとしたエンジニアさんが6時間もレコーディングを行ってくれます。高い？ いえいえ、サウンドエンジ
編曲やレコーディングを真剣にやり始めて、他人様に提供するようになってから随分と経つ。その中で、自分にとってはエレキギターの録音が最も難しい課題のひとつとしてずっと立ちはだかっていた。もうずっといろんな手段を試してみたけど、最近ようやく満足に片足突っ込んだ音を録ることができるようになってきたので、それについて書く。なお、スタンスとして「高い機材買いまくればそりゃいい音で取れるけど、そうじゃなくて創意工夫で現実的な範囲で最高の音を録りたいんじゃ」というスタンスです。 最初に結論 及第点出すならstrymon IRIDIUM買っとけば間違いない マイク録りするなら覚悟が必要。そこは底無し沼だ、気をつけろ。自宅でやるなら以下の戦略を取ろう 音量が小さくてもいい音が出せるセッティングを突き詰める マイキングがかんたんなセッティングを突き詰める 「手軽に安価でシミュレーターよりいい音」を出せるリグは以
自分のバンドで使いたいから作った。 ニーズ ライブをやるときに、セットリストが足元にあると便利。 BPMも同時にわかると便利 便利なんだけど、ふつうBPM:88ですって言われてもそれがどれくらいの速さなのかはパッとわからない 楽譜アプリとかで、視覚的にBPMがわかる（丸が点滅してくれる）やつもあるんだけど、ライブしてる途中にスマートフォンとかタブレットとかいじってるところあんま見られたくない できればペダルボードの横とかに放置しておくだけで全曲のBPMを視覚的に教えてほしい。 機能 ライブでやる曲のリストをformタブから入力できる prompterタブではそのリストが表示され、「signal」というカラムでその曲のbpmに合わせて「●」が点滅してくれる share linkをコピーすると、アプリをインストールせずにバンドメンバーに展開可能 その際入力しておいたセットリストとbpmはURL
組織やチームにおいて、合意は非常に重要だと思う。そもそもなんらかの合意が存在しないチームや組織はそれはもはや組織やチームではなく、バラバラな個人の集まりとなる。 一方、合意はとても高コストだ。全ての行動に合意が必要となる場合は、動きはとても遅く、目的を達成するためのコストは跳ね上がる。なにをするにしても「根回し」と「合意」をとらなければならなくてとにかく仕事が進まない、というのはよく聞く嘆きではないだろうか。合意は重要だが、一方でハイコストなので、合意を取る必要のないものについては合意なしで済ませることも重要となる。 合意は非常に重要だが、ハイコストである。このジレンマに対しては、「合意を取るべきものはなにか」「何ならば合意を取らずに進めていいのか」の合意、いわば合意に関するメタ合意とでも呼ぶべき合意が重要になると考えることができると思う。メタ合意さえあれば、本当に合意を取るべき（と合意が
今日は掲題のような文章について。 世の中には「すでにわかっているひとにはよくわかるしとてもわかりやすいんだけど、わかってないひとにとってはなんのこっちゃかわからん」みたいなタイプの文章が存在すると思う。 たとえばソフトウェア開発の文脈で言うと、基本情報技術者試験の勉強の際に読むようなやつを想像してみてほしい。ぼくは基本情報技術者試験って結構役に立つよなあって思っている側の人間で、ある程度ソフトウェア開発の経験を積んだひとからもけっこう「内容はいいよね」っていう言葉は聞くと思う。で、この「内容はいいよね」ってところが結構ポイントだと思っていて、実際にソフトウェア開発の経験をある程度積んで、暗黙知や経験知がある程度溜まった状態、つまり「わかっている」状態であれらを読むと「わかるわかる」となるが、一方でそういう暗黙知や経験知がない状態で基本情報技術者試験に合格しても結構「とりあえず暗記したけどこ
ソフトウェアの内部品質への投資を怠ったが故に、その内部品質がビジネスの足枷になってしまった、という失敗はよく聞かれる例だと思う。 そういう場合、「なのでソフトウェアの内部品質を直しましょう！」と言う発想になりがちだし、当然そのための投資を始めることは必要なのだけれど、それ以上に注目しなければならない問題がある、と最近は思うようになった。 「内部品質が落ちたので内部品質を直しましょう」というのは、単なる対症療法である上に「いつんなったら直って内部品質への投資やめられるの」という誤った問いを誘発してしまう。よくある話として、一定の内部品質を達成するために「リプレースプロジェクトです！」と言って書き換えを進めて、それが終わったらまた内部品質は鑑みられなくなるような話があるし、内部品質だけではなく「EOL対応」とかでもそういうケースはまま聞く。 じつは直面すべき課題は「内部品質の低さ」や「依存ライ
いろんなところで主張してきたことの繰り返しになりますが、ソフトウェアの設計とは、「解きたい問題に対して適切な構造を与えること」だとわたしは考えています。 「解きたい問題に対して適切な構造を与えること」という以上、「解きたい問題」が変われば「適切な構造」も変化する、ということが言えるはずです。これは「まず問題を適切に捉えること」の重要性を示していると言えると思っています。しかし、そのことと同等に問題とされるべきは、「適切な構造は何によって構成されるか」であるとも思います。 わたしは、ソフトウェアの「適切な構造」を構成する二大要素は「関心の分割点」と「分割点によって分割された要素同士の依存関係」だと思っています。 つまり、ソフトウェア設計とは、「まず解きたい問題を理解し、その問題に応じて、適切な関心の分割点を見出し、見出された関心の分割点で分割された各要素に対して最も適切な依存関係を設定するこ
軽く振り返りたい。 去年の10月からVPoTになって、ずっと手探りでやってきていつのまにか1年以上経ってた。 正直言って、始めてから半年くらいは「何を期待されていて、自分ができることが何で、それをどう進めるべきか」が全然わからなくて、自分が何をすべきかということを探る期間だったし、ちゃんと機能できていなかったと思う。具体的に何をやっていたか、と言われてちゃんと応えられる成果がない。まあ、半年くらいそんな感じで右往左往しながら、今までと違う立場で社内を観察していたのはまるっきり無駄とは言えず、今の仕事につながってはいるかな、とは思う。けど正直機能できてなくてすまんかった、とも思っている。 では今何をやっているかと言うと、課題を抱えた現場に対してアドバイザリーとして入っていって改善おじさんをやったり、そういう現場レベルのことよりもでかい粒度で「全社レベルでの仕事の構造を変える」ことに注力してい
この10月から、VPoTという肩書がついた。公式な経緯などは会社のブログのほうに書いたのでそちらを読んでいただきたいのだけれど、こちらは個人の日記なので個人の日記レベルのことを書く。 VPoTになるまでは、テックリードという肩書で、社内を見渡して「あ、ここちょっと自分が入っていった方が物事がうまく進みそうだな」というところに入っていっては手を動かすというようなムーブをしていたのだけれど、冒頭に貼った記事のような経緯で、今は手を動かすことよりも、仕組みづくり、組織構造に起因する問題に対する解決となる構造を作ることなどが主な仕事になった。 じつは、ぼくは今の会社に入るときに明確に「CTOやそれに準ずる仕事はしたくない」と伝えた上で採用してもらっている。なのになぜ心変わりをして、いままたCTO業の一部のようなことをやっているか、ということを今日は書きたい。 そもそも、ぼくがなぜCTOやそれに準ず
コミュニケーションが成立するためには、双方の発信器官、受信器官（ここで言う器官というのは身体的な器官のことではなく、「メカニズム」くらいの意味だ）が健全に稼働していることが必要条件となることは言うまでもないことだとおもう。片方の受信器官が壊れていたら、とうぜんもう片方がいくら発信したところでその信号はだれにも届かないまま消えていく。これは逆もまたおなじことが言えて、片方の発信器官が壊れていたら、とうぜんもう片方がいくらがんばって受信したところでそれは理解不能なものになるし、そもそも発信されてないものを受信することはできない。いくら耳をすましていても。 いま、双方の発信器官受信器官が健全に稼働していることをコミュニケーション成立の「必要条件」と言ったけれど、ではこれらの条件はコミュニケーション成立の「十分条件」だろうか？ ということを考えてみたいと思う。換言すれば、「双方の発信器官も受信器官
gemとかが標準エラー出力に対して「deprecatedなメソッド呼んでるよ〜」みたいなwarningを吐いてくれることがあると思うんですが、自分のプロダクトコード側でそのメソッドを呼んでいるわけではなくて依存してる別のgemの気がする、犯人は誰だ！みたいなときの話です。 だいたい./vendor/bundle以下を検索すればまあ犯人見つかるというのはあるんですが、メソッド名を動的に作ってるやつとかがいると引っかかってこなかったり、あとは同じ文字列がたまたま関係ないところで出現してるみたいなときもあるにはあり、「このwarningを出してるところのスタックトレースがほしいよお！」ってなることがある。そのようなときには、 class CustomStdErr < IO def write(*args) p caller STDERR.write(*args) end end $stderr
builderscon2019に参加してきました。以下技術的ではない部分の振り返りです。技術的な部分の振り返りはまたあとで書きます。 今年はすごく自分のメンタルが乱高下する、とてもヘヴィなbuildersconとなった。というのも、まさに前回の記事に書いたことが起こったのがbuildersconの前夜祭だったからだ。前回の記事は自分もまだ混乱のさなかにあるときに書いたものなので、だいぶ落ち着いた今、再度そのあたりの話をするところからはじめたい。 前回の記事にも書いたけれど、「マッチングアプリのいいね自動化」という内容そのものが悪である、という立場にぼくは立たない。マッチングアプリというのは、そもそも男女ともに「性的に選別」しあうものである。そうである以上、「マッチングアプリ上での性的な選別の自動化」は問題ないはずだ、という立場ではある。「どんな文脈であれ人間を性的に選別するような発表はそも
エンジニアの集まるカンファレンス（参加者の多くはソフトウェア・エンジニアだが、ものづくりするひとすべてを対象としたカンファレンスなので、暫定的に「エンジニア」という括りで話します）において、マッチングアプリ上で女性の外見を判別して自動でいいねを押すという発表がなされている現場に居合わせた。このエントリの目的は特定の発表自体の是非を判断することではないので、リンクしない。「リンクしなければそもそもその発表の是非の判断ができないじゃないか」という向きもあると思うけれど、少し調べればわかることだし、その発表自体の是非を議論したいなら、調べるくらいのコストをかけて別のところでやってくれたら嬉しいと思っている。 さて。少なくとも今回参加しているカンファレンスのジェンダーバランスは、めちゃめちゃ偏っている。おそらく、多くの技術系のカンファレンスにおいても、そうなのではないかと思う。これ自体がいびつであ
労働の現場においては、gemにオレオレパッチを当てたい、ということがまれにあります（あ、いい忘れてましたがこれからRubyの話をします）。もちろん、オレオレパッチは基本的には避けるべきものですが、そうも言っていられない深遠なる事情というのが、労働においてはある……。労働にはいろいろあります……。 さて、オレオレパッチの是非については一旦おいておいて、gemにオレオレパッチを当てたいとき、オープンクラスを利用してモンキーパッチを当てることが一般的には多いのではないでしょうか（繰り返しになりますがここではオレオレパッチの是非は問いません）。Railsを利用している場合、config/initializers以下にモンキーパッチのためのファイルを入れて、Rails起動時にgemの挙動を拡張、あるいは変更する、というような手段が多くの場合取られるのではないかと思います。 しかし、Railsを利用し
twitterに書いたやつ再掲+加筆。 Webフロントエンド、というかSPAの設計で、単なるwebAPIラッパーに対して「Repository」と名付けるケースが散見されるけど、ぼくはあれあまり好きではないです。というのも、Repositoryという名前がついてると、集約的なもの、それが言い過ぎならいわゆるEntity、それも言い過ぎならひとかたまりのデータを保存、取得するだけの責務のように思えるからです。けど、実際の「Repository」を見てみると、取得されるのは画面の仕様にベッタリなJSONだったり、更新系としてもなんちゃらidとパラメータを渡すようなIFになってることが多いですよね。画面の仕様にベッタリなJSONが返ってくるようになってたり、idとパラメータ渡すだけだったりするのは、多くの場合考えることが少なくて済むし通信量も減る良いプラクティスだと思うので、それ自体は問題ではな
最近、高校の先生が「知識問題」「思考問題」という言葉を使ってらっしゃるのを聞いて、「なるほど、面白い分類だな」と思った。それ以来「知識問題と思考問題」という視点で物事を眺めるのが自分の中でブームとなっている。 もちろん、知識問題と思考問題というのはきれいにスパッとわかれるものではなく、グラデーション状になっていると思う。この問題はやや思考問題よりだね、とか、かなり知識問題に振れてるね、とか、かなり思考問題寄りだね、とか。 ソフトウェアの設計について考えてみると、じつは、ソフトウェアをどのようなレイヤーに分割するか、というような話はかなり知識問題寄りに見える。この問題には先人の知恵がたくさんあって、それらが「傾向と対策」として未知の問題にも流用しやすい。 一方で、レイヤーの内部をどのような責務でどのようクラス、コンポーネントに分割していくのかというのは、かなり思考問題よりに見える。このとき、
誤解を産んでいそうだったので追記します。ここでいうApplicationServiceというのは、いわゆるレイヤードアーキテクチャのアプリケーション層のApplicationServiceレイヤの話です。別の言葉だと、「Usecase層」とか言う言葉で呼ばれたりするアレのことです。追記おしまい。 Railsにおいては、ApplicationService相当のロジックをコントローラーに書いても良いものとする— 猫でもわかるしんぺい入門 (@shinpei0213) June 4, 2019 これについてです。 結論から先にいうと、ぼくは「正しい」と思っています（ただ、自分ではあまりやらず、ApplicationServiceに切り出しちゃいますが、これは好みの問題だと思っています）。 なぜ正しいと思うのか。それを考える際に、まずは「一般的に、なぜControllerとApplication
前回の記事の続きです。 前回は、「時代が変わるとサーバーアプリケーションの役割も変わるよね。そうすると必要な要素技術も変わっていくよね」という話でした。今回は、じゃあ「サーバーアプリケーションがJSON喋るマンになって、クライアントアプリケーションとの協働でユーザー体験が実現されるようになってきた今、"ビジネスロジック"はだれが持つべきなの？」って話をしたいと思います。 基本的にはサーバーでもってあげたほうが楽 さて、サーバーサイドでなんでもやる牧歌的な時代は過ぎ去り、クライアントサイドとサーバーサイドがコラボレーションしてひとつの体験を提供するようになった昨今、「そのアプリケーションの体験を成り立たせるための"ロジック"をどっちに書くのか」という問題が立ち上がってきます。わたしの私見ですが、これはなるべくならサーバーサイドで請け負ってあげるのがよいのではないでしょうか。その理由は、クライ
最近、2019年のwebAPIの設計まわりの問題について考えていて、問題とその周辺技術の整理を自分の頭の中でしています。 で、その内容をたぶん何回かに分けて書きますが、初回の今日はちょっと導入として浅めの部分を整理してみようと思います。 昨今、サーバーサイドの仕事はもっぱらJSONなどをしゃべることに終始して、エンドユーザーが触る画面をサーバーがレンダリングする事例は減ってきているのではないでしょうか。これはぼくが考えるに不可逆な事態で、今後もユーザーが使うインターネットにつながるデバイスは多様化していくし、それぞれがそれぞれにネイティブな環境を持ち、それらがHTTPSを喋ってインターネットとつながる、という世界はしばらく変わらないでしょう。言葉を変えれば、サーバーサイドでHTTPをしゃべるお客さんが、エンドユーザーからクライアントアプリケーションというプログラムに移行してきている、という
やんざむ先生のこのツイートを見て考えたことをまとめます。 UseCase がわからない... FizzBuzz で 「3の倍数のときは fizz が返る」 「5の倍数のときは buzz が返る」 「3の倍数かつ5の倍数のときは fizzbuzz が返る」 「3の倍数でも5の倍数でもないときはそのままの数字が返る」 これは— Yuki Anzai (@yanzm) February 15, 2019 結論を先に書くと、「これはそもそも問い自体が不適切である」（しかし強いて言えばEntity）という立場をわたしは取ります。以下、まじめにFizzBuzzを設計しながら考えてみます。 ひとまず、出発点は上にあるツイートの疑問から出発するとしましょう。 まず前提として、ユースケースってどういう役割か まず前提として、ぼくはユースケースを「ドメインモデル（このツイートで言うところのEntity）やイン
アジリティ高くすることが重要なわけで、UI変更のアジリティ高くするためにPDSを意識したり、モデルに関してもドメイン層とインフラ層を分離したりするわけで、「その分離によってどういう変更に対するアジリティを高めたいのか」を説明できないならやるな— しんぺい a.k.a. 猫型蓄音機 (@shinpei0213) December 13, 2018 この発言でもうすべてを語っているんだけど、たとえばDDDの流行（？）によりレイヤー化アーキテクチャ、そこにDIPによる依存関係の整理を加えたオニオンアーキテクチャやヘキサゴナルアーキテクチャ、それらを統括した概念としてのクリーンアーキテクチャなどへの関心はますます高まっているような気がする（要出典）。それ自体は喜ばしいことだとぼくは考えているのだけれど、一方で、初学者などがいきなり「ふんふん、これが"正解"か」と思って、その「構造だけ」を真似してみ
暇。いい響きだと思う。声に出してみる。ヒマ。とても良い。「ヒ」の音でちょっと勢いづいた感じがするも、マ行の発音をするためには一度唇を閉じなければいけないこの感じが、いかにも暇という言葉の甘美な後ろめたさを表しているように思う。 これがもしも「ヒマ」ではなくて「ヒカ」とかだったら、あまりに印象がシャープにすぎる。暇にかまけてよしなし事をそこはかとなく書きつくるようなことは許されないような、そんな感じがする。逆に「ニマ」くらいまでいってしまうと、今度はほげほげとしすぎていて、なんとなく忙しい世間から取り残されるような後ろめたさが感じとれないではないか。 この、シャープなわけでもなければ、ほげほげとし過ぎているわけではない、そんな捉えどころのない「暇」というものについて、少し考えてみたい。 ぼくが「暇」について考えるときにいつも頭に浮かぶのは、スチャダラパーの「暇の過ごし方」という曲だ。これは
11/8日に株式会社アトラエ様に会場をお借りして、設計Nightを開催します！！ connpass.com 先日builderscon tokyo 2018で私が行った発表「開発現場で役立たせるための設計原則とパターン」は、いままで暗黙知になりがちであった「現場でどうやって設計原則やデザインパターンを役に立たせるのか」に光を当てたという点で、一定の成果と意味があったのではないかと自負しております。一方で、これで「設計について語るべきことはなくなった」というわけではなく（あたりまえである）、設計についてはこの発表ではカバーしきれない様々な論点があるかと思います。その中から、今回はみっつの論点について、今回は豪華ゲストに語っていただきます！ パフォーマンスについて 問題をいかに捉えるのか MicroServicesという視点 これらの論点は私自身が大きな関心を寄せるものでもあり、当日ゲストの方
世界とのチューニングを合わせることに苦労する、という感覚は、多かれ少なかれどんなひとでも持ってるのではないか、と思っている。 それはたとえば、飲み会でうまく立ち回るみたいな具体的なことから、なんとなくうまく世界に馴染めないみたいな曖昧なこともあるだろう。それは時には「どう働けばいいのかわからない」という形をとって現れたりもするだろう。そうすると大変だよね。 ぼくの知り合いで、めちゃめちゃ仕事ができるのに、「切手の値段がどう決まるかわからない」と言って封筒を出せずに毎回レターパックを使っているというひとがいる（というかさっきそういう話をツイッターでしてるのを見かけた）。「ググればいいじゃん」と思うことなかれ。おそらく彼にとって「郵便システム」という世界の一部とチューニングを合わせることは、ほかのひとには感じることの難しい困難さを伴うことなのだろうと思う。しかし彼は仕事ができる。それは、彼がほ
次のページ
このページを最初にブックマークしてみませんか？
『猫型の蓄音機は 1 分間に 45 回にゃあと鳴く』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
