mochikoAsTechのdig日記

当方好きなコマンドはdigです！お友達から！！よろしくお願いします！！！

2拠点目として温泉の出る激安マンションを買った話

窓の外で鳥の鳴く声がする。時折、遠くで貨物列車の走る音が聞こえる。海沿いを散歩して、その帰りに魚屋で買ってきた海鮮丼を食べる。お腹がいっぱいになったら部屋で温泉をためて入る。とろりとした疲れを感じながら少し昼寝をして、目が覚めたらぼーっと海と山を眺める。

標高が高いので、風呂上がりにガラス戸を開けるとひんやりとした山の風が吹き抜けていってとても気持ちがいい。虫もいないのでそのまま開けっぱなしでも問題ない。最高か。

実はちょっと前に面白い買い物をしたのです。バブル期に人気のあったエリアで、ヴィンテージのリゾートマンションを1部屋買ってみました。いま東京で家を買おうとすると、平気で2LDKが7千万とか、3LDKが1億超えとかするらしいけど、なんと私が買った部屋は90平米で400万円ぽっきり。だだっ広くて部屋で温泉が出る。別にいま住んでいる東京の家を手放すつもりはなくて、個人的な仕事をするための2拠点目として面白いのでえいやっと購入しました。

ゴールデンウィーク明けからリフォームをして、第2のおうちオフィスとして快適な拠点に育てていく予定なので、とりあえずぶっ壊す前の部屋で1日だけゆるゆると過ごしてみたけど、これがめちゃくちゃよい。

海を見ながらさわやかな風を浴びて「買ってよかった－！」としみじみしている。

人気のなくなった激安リゾートマンションって、住人が少ないから管理費が足りなくてメンテナンスができずに云々とか、実は災害のリスクが高い場所で云々とか、安いだけに何かしらの落とし穴があることをきっと心配いただいたかと思うのですが、なんと先に高殿円さんが全国各地に赴いてありとあらゆる実地調査をして地雷という地雷をすべて踏み抜き、最終的に「ここだ！」と決めたマンションを見せてもらって、「わー、確かに！ここいいですね！」となって購入したのでその辺りはご安心ください。

他店が入念な立地マーケティング調査をし、万難を排して出店した店舗の隣に店を出す、みたいなことをしました。やっほい。ちなみに高殿さんによる知の高速道路はここで買えます。

※この文章はそんな温泉マンションでポメラのキーボードをたたいて書きました。ポメラめっちゃいいな。

ついにポメラを買ってポメラニアンになった

ポメラを買った！ポメラを買ったぞ！長らく気になってはいたものの、折角なら限定色のWHITEかCristalが欲しかった（だがどちらももうとうに完売していて手に入らない）という気持ちもあり、なんとなく買うに至っていなかったポメラを！ついに！買ったぞ！！

なぜこのタイミングで買ったかというと、2024年5月に開催される技術書典16で出す新刊（テクニカルライティング本）の原稿があまりに進まなくてつらかったからです。新しい文房具買うとわくわくしてしばらく真面目に日記書いたりするじゃないですか。あの感覚でポメラ買ったらもうちょっとするするっと書けたりしないだろうか、と思って買いました。

私の初ポメラはDM250という最新機種のダークグレー。最新機種と言っても2022年7月に出たものなので、発売からすでに2年弱が経過しており、値段も結構下がっていた。ヨドバシでポイントが13%付いて、実質39,000円。発売当初の定価だと税込み6万円超えだったので、その値段はちょっと考えちゃうけど、3万円台ならえいやっと買えた。

購入してすぐにいろいろセットアップ。キーボードの割り当てを好みのものに変えて、SDカード（別売り）を差し込んでフォーマット。新規ファイル作成時のデフォルト保存先をSDカードにして、ファイルの命名規則も日付ベースのものにした。

パソコンでVS Codeを開いて書いているときの方が調べ物をしたり、過去書いたものを参照してコピペしてきたりという作業は確かにやりやすいんだけど、正直気づいたらTwitter（X）を開いているし、Slack見ちゃうし、気が散って全然書き進められない。

ブログもしばらく書いていなかったし、日々のランニングをサボっていた結果、長距離を走るやり方も忘れ気味という感じなので、しばらくポメラで「他人のあれこれを気にせず、書くことだけに集中する」をやってみようかなと思う。ただ手元にスマホがあると結局そっちを見ちゃうので、ポメラで書くときはスマホを遠くに置かないとだめそう。

ポメラは「現時点の文字数」が常時出ているのもよい。自分がどれくらい書いたか、数字が目に見えて増えていくので楽しい。

スマホアプリと接続するときは、わざわざポメラ側でWi-Fiを立ててそこにスマホをつないだり、ポメラ側でQRコードを表示させてスマホアプリのカメラで読み込む必要があるので若干面倒だけど……あとQRコードを読み込んだとき、「1/2」みたいなのが出るだけで画面をタップしても何も起きないし、一向に保存もされないからなんだよー！と思ったら、どうやらデータ量が多いのでQRコードが複数個あり、ポメラ側で「→」を押してQRコードを切り替え、立て続けに読み込ませることでファイルが保存されるらしい。QRコードにはこういう「続きがあるよ」っていうのを示す規格があるのか、面白いね。

※この文章はすべてポメラで書きました

「次世代 Web カンファレンス 2023」のTechnical Writing セッションで登壇してきました

「次世代 Web カンファレンス 2023」のTechnical Writingセッションで登壇してきました。

次世代 Web カンファレンス 2023ってなに？

12のテーマに沿ってそれぞれ選ばれた4人が、そのテーマについて今どうなっていて、これからどうなっていくのかを90分間ひたすら議論するカンファレンス。

nextwebconf.connpass.com

2023年は以下12のテーマでセッションが行われました。

Performance、CSS、Web3、Testing、A11y、Passkey、Design Technology、Privacy、Tooling、Frontend Architecture、Edge Computing、Technical Writing

議論するってどういうこと？

次世代 Web カンファレンスでは、登壇者側は「聞き手のレベルを意識せず、話したいレベルで話してください」と言われています。実際、自分の担当するセッションが始まる前に、他のセッションを見に行ってみたら何を求められているのかよく分かりました。

なるほど！聞き手に合わせてブレーキをかけずに、登壇者同士で遠慮なくアクセルをべた踏みして議論すればいいんだな！

ただテクニカルライターは普段、「相手の理解度を見ながら分かりやすく説明する」ことを生業としている人たちなので、この「聞き手を意識しない」「分かりやすく話そうとしない」がむしろ難しいんですよね。逆の意味でうまくできるかどきどきしていました。

Technical Writingのセッションを終えて

当日のセッションについては、Togetterを見ると雰囲気が味わえると思います。

togetter.com

今回、議論をするメンバーはテクニカルライター、UXライターの中でも「開発者向けのドキュメントを書いている/エンドユーザー向けのマニュアルを書いている」「日本語で書いている/多言語で書いている」「エンジニア出身/ライター出身」「印刷も経験している/Webのみを経験している」など、属性ができるだけばらけることを意識してお声がけしました。

90分のセッションと、終わった後の30分の延長戦、どちらも各々の経験に基づく考えを存分にぶつけあって、いい議論になったかなと思います。後日、動画も公開されるようです。

こちらは最前列ど真ん中で自作のうちわを振るトップヲタです。

カンファレンスでTechnical Writingがテーマになるということ

次世代 Web カンファレンスは、おおよそ4年に1回のペースで開催されています。

Technical Writingがテーマになったのは今回（2023年）が初めてでした。

もともと私は2021年3月からTechnical Writing Meetup というイベントを継続して開催しているのですが、それが「ライティングの話を誰に頼もうかな…」と思っていたJxckさんの目に留まって今回お声がけいただいたようです。

www.youtube.com

わーい、月1ペースの開催は正直しんどいときもあったけど「テクニカルライティングの認知が高まって、みんなの役に立つといいなぁ」と思いながら続けていてよかったー！

今回のようにテクニカルライターやUXライターが集まって議論するセッションもまたやれたらと思っていますので、興味のある方はぜひご参加ください。

tw-meetup.connpass.com

初参加してみた感想

次世代 Web カンファレンスへの参加は今回が初めてでしたが、A11yやDesign Technologyといった別ジャンルのセッションでも「あー、分かる」「これ、私のやってることに関係あるな」という話がちょこちょこあって、1日で色んなジャンルの濃い話をたくさんつまみ食いできるのすごくいいな！となりました。

主催や運営のみなさま、ありがとうございました。とっても楽しかったです！

新卒でいきなり開発者向けのドキュメントを書くテクニカルライターになれますか？

これは「mhidakaが建立した Advent Calendar 2023」の9日目の記事です。

まじでゆるふわでいい、ということなので、雑で特に結論もない話を書きます。わいわい。

---

tech.smarthr.jp

先日、この「教えて先輩！ DevRelの立ち上げ方（前編）活動の成果と計測、体制、予算 - SmartHR Tech Blog」という記事を読んでいて「めっちゃわかるー」となったところがあった。以下、引用。

941：そうですね。うちに大学生のアルバイトの子が一人いたんですけど、卒業するから新卒でDevRelに入りたいって言ってきて。いや、ファーストキャリアは絶対にここじゃないよって（笑）。

玉田：ああー、わかる。

941：新卒カードは絶対違うとこで使ったほうがよいです。なので、セカンドキャリアっていうか、他に何かやってから……。

杉田：ですね。ベースで何か自分の強みが一つあって、それプラスアルファのDevRelかなという気がします。

これ、テクニカルライターにもよく似てるなーと思ったのです。

以下は、私がときどき大学にお呼ばれして、自分のキャリアについて話すときの発表原稿から抜粋したもの。

これってドラクエの転職システムに似ているなーと思っていて、テクニカルライターって決して最初から目指す職業じゃなかったりするんですね。

レベル1の戦士になって、レベル50まで行って、転職してまたレベル1から魔法使いをやって、またレベル50まで行って、その2つを経てようやく上級職の魔法戦士に転職できたりする。

大学卒業した直後、いちばん最初から魔法戦士、つまりテクニカルライターを目指したらなれていたかっていうと、恐らくそういうじゃないな、という。

私はプログラマーをやってたときも、広報をやってたときも、インフラエンジニアをやっていたときも、別にテクニカルライターを目指して踏み台としてそこをやってた訳じゃないんだけど、その辺で育ててきたスキルがうまい具合に噛み合って、ゆくゆくいい感じの職業に辿り着くことがあるよ、という。

最初から「なりたいもの」がはっきりしていなくても、置かれた場所で精一杯がんばっていると、それがスキルになって、後々の選択肢を広げることがあるよ、という話ですね。

一度も料理したことないし、なんなら「台所」という概念も知らない人間に、分かりやすいレシピが書けるかというとやっぱりかなり難しいので、エンジニアリングもライティングもどちらも経験せずにいきなり初手で目指すようなポジションではない気がしている。

ちなみに私がここで言っている「テクニカルライター」は、こういうお仕事のことを指しているけど、エンドユーザー向けに電化製品のマニュアル（取扱説明書）を書くタイプのテクニカルライターであれば、マニュアル制作会社で新卒採用はしているし、そこからIT系のテクニカルライターやUXライターにジョブチェンジしてきました、という話もよく聞く。

参考：テクニカルライター - 職業詳細 | job tag（職業情報提供サイト（日本版O-NET））

せっかくサイボウズ、SmartHR、ソラコム、ヌーラボなどIT系の各社でテクニカルライター採用枠もまた増えてきたし、「こういうルートを進むとIT系のテクニカルライターになれる」という舗装された道が整備されて人口が増えていくといいんだけど、まだなんか再現性がない「いろいろあって、気付いたらここにいました」みたいな獣道パターンが多いなと思っている。

#技術書典 15で「#届ける工夫 ～欲しい誰かに見つけてもらえる60の方法～」という新刊を出します

技術書典15で「届ける工夫 ～欲しい誰かに見つけてもらえる60の方法～」という新刊を出します！

techbookfest.org

「届ける工夫」ってどんな本なの？

もしあなたが「もっとたくさんの人に手に取ってもらって、○○の良さを知って欲しい」と思っているなら、たとえばこんなことをするといいですよ、という工夫を紹介する本です。

この本には、欲しい人に存在を知ってもらい、手に取ってもらうための実践的な工夫が詰め込まれています。「せっかく書いた良い技術書が、存在自体を知ってもらえていないせいで売れていない。この本を必要としてる人はたくさん居るはずなのになんで届かないんだ……」という悔しい思いをしたことがある著者の方にとって、きっと役に立つヒントが得られるはずです。

それぞれの工夫は、どれも私が技術書典で本を出すとき、実際にやっていることが元になっています。題材は技術書典ですが、それぞれの工夫は汎用的なものなので、たとえば同人誌即売会で自作の小説を売っている人や、ハンドメイドのアクセサリーをマルシェで売っている人など、自分の作ったものを自分で販売している人にはきっと共通して参考になる内容だと信じています。

本の目次

この本はいつどこで買えるの？

技術書典15というイベントで買えます。技術書典はオンラインマーケットとオフライン会場で同時に開催するので、紙の本がネットでも現地でも買えます。紙の本を買うと、電子版も付いてきます。

オフライン会場では「い02」という、入口からほど近い場所にいます。

オンラインマーケットで買った紙の本は、会期終了後にまとめておうちに届くので、「紙の本がいますぐ欲しい！」という方は11月12日(日) のオフライン会場にお越しください。その場で紙の本を買って持ち帰れます。

オフライン会場に入るには、無料の入場券が必要なので、必ず事前に取得してお越しください！当日でも枠が残っていれば取得できるので、もし急に行く気になったら電車の中でスマホからシュッと入場券取って会場に来てください。

記念すべき10冊目！

2018年に技術書典4で「DNSをはじめよう」を出して以来、さまざまな技術書を書いてきました。今回の「届ける工夫 ～欲しい誰かに見つけてもらえる60の方法～」は、記念すべき10冊目の本です！

会場には既刊もいくつか持ち込む予定です。新刊と一緒に、気になる本があったらぜひお手にとってご覧ください。

techbookfest.org

techbookfest.org

#技術書典 14で「LINE Botをつくってみよう ～APIを試して学んでしっかりわかる～」という本を出します

技術書典14で「LINE Botをつくってみよう ～APIを試して学んでしっかりわかる～」という新刊を出します！みなさま、買いに来てくださいまし～！電子版は無料ですわ～～！

techbookfest.org

「LINE Botをつくってみよう」ってどんな本なの？

実際にLINE公式アカウントからメッセージを送ったり、オウム返しするLINE BotやAIチャットボットを作ったりする、「手を動かして学べる」本です。

  • 実際に手を動かしながら「APIをたたく」を実践的に学べる
  • あなたにもLINEで動くAIチャットボットが作れる
  • OpenAI API（ChatGPTのAPI）を使ったLINE Bot開発を解説

第1章「LINE 公式アカウントをつくってみよう」でLINE 公式アカウントについて解説し、第2章「Messaging APIでLINE Botをつくってみよう」で実際にLINE Botをつくって動かし、最後に第3章「Messaging APIの色んな機能を試してみよう」でLINE Botを育てていく色んな方向性を紹介する、という三部構成になっています。

詳しい目次は、このブログの下の方に載せておきます。

この本の値段はいくら？

180ページ / B5サイズと結構な厚みのある本なんですが、今回なんと電子版は0円で出します！無料ですわ～！そして紙版は500円です！ワンコインでお買い得なんですわ～！！

技術書典のオフライン会場で「新刊、電子版でください！」と元気よく言うと電子版が無料で読めるURL入りポストカード（数量限定）を差し上げます。また会場に来られなくても、オンラインマーケットで無料でダウンロードできます。 

この本はいつどこで買えるの？

技術書典14というイベントで買えます。技術書典はオンラインマーケットとオフライン会場で同時に開催するので、紙の本がネットでも現地でも買えます。

オフライン会場では「い01」という、入口からほど近い場所にいます。

オンラインマーケットで買った紙の本は、会期終了後にまとめておうちに届くので、「紙の本がいますぐ欲しい！」という方は5月21日(日) のオフライン会場にお越しください。その場で紙の本を買って持ち帰れます。

オフライン会場に入るには、無料の入場券が必要なので、必ず事前に取得してお越しください！当日でも枠が残っていれば取得できるので、もし急に行く気になったら電車の中でスマホからシュッと入場券取って会場に来てくださいませ～～！！

なんで電子版は無料だし、紙版も500円なの？

過去に技術書典で出した本を見ていただくとわかると思うんですが、私は基本的に「中身の情報を売っている」つもりなので、紙版でも電子版でも価格差はつけずに同じ値段にしています。むしろ紙版は「電子版を買うと、なんと紙の本がおまけでついてくる！」みたいな感覚ですね。

今回の新刊「LINE Botをつくってみよう」はB5サイズで180ページあるので、今までだったらおそらく紙版も電子版も1,500円くらいで頒布していたと思います。

じゃあなんで今回電子版は無料だし、紙版も500円というお買い得な価格にしているのかというと、端的に言って「私が書きたいことをいっぱい詰め込んで書きたいように書いたら、結果としてちょっと宣伝っぽさを感じる内容になったから」です。

本の「免責事項」にも次のように書いているのですが、この本の発刊時点で私はLINE株式会社に所属しています。

本書の発刊時点で筆者はLINE株式会社に所属していますが、本書は個人として執筆したものであり、本書に記載されている内容はいずれも所属する組織の公式見解ではありません。また、本書は一般に開示されている情報を元に書かれており、筆者が所属する組織において知り得た情報は含まれていません。LINE APIについて言及するにあたって、所属を隠した宣伝であると誤解されないよう所属組織をここに明記しておきます。

この本は「LINE Bot」をテーマにした本であり、実はLINEに入社してすぐの頃から心ひそかに「いつかこのテーマで本が書けたらいいなー」と思っていました。

入社から3年以上の月日を経て、今回ようやく個人として執筆することが叶い、あくまで個人として一般に開示されている情報だけを元にしてこの本を書き上げました。執筆はすべて業務時間外に行ったものであり、所属会社からもお金は一銭ももらっていません。印刷代もデザイン代もすべて私個人のお財布から出ています。

なのですが、どうしても3年の間に培ったプロダクトに対する愛情や思い入れが言葉の端々からにじみ出てしまい、なんというか…読むとそこはかとなく…通信教育のDMに入っているマンガっぽい…宣伝臭…？みたいなものを人によっては感じるかもしれません。

内容自体は初心者にもフレンドリーで、すごく面白いと思います！もしLINE Botについて色々学ぶ前の私に読ませたら、「すごくわかりやすい！」と喜んでもらえる自信があります。

ただ、今までの「その分野の権威でもなければその会社所属でもないのに、好きが高じて勝手に書いた本」に比べると、プロダクトへの愛情故にどうしても一定の「宣伝っぽさ」が抜けなかったため、「この内容にお金を出してもいい！」と思った人だけがお金を払って紙の本を買えるように、電子版は0円にしました。

もし読んだ後に「なんだよ！いい本じゃん！もっと著者に還元させろよー！」と思ったら、ぜひこの本をどんどん宣伝してください。本当に書きたいことを書きたいように書いたので、いっぱい読んでもらえるのがいちばん嬉しいです。

よろしくお願いします！！

表紙

目次

techbookfest.org

「読みやすいコードのガイドライン―持続可能なソフトウェア開発のために」を読んだ！

先日、社内で技術書に関するイベントが行われた。執筆経験を持つ社内のエンジニア諸氏から話を聞ける、という面白そうなイベントだったので有難く参加してきたんだけど、そこで質問を投げたところ、著者である石川さんからご厚意でこちらの本を頂戴した。

ばばーん！「読みやすいコードのガイドライン―持続可能なソフトウェア開発のために」です！

gihyo.jp

実はもともとこのツイートを見て気になっていたんだけど、「私には難しすぎるんでは…」とためらって買っていなかった本だったので、とてもうれしい！

サイン入りですわよ！わいわい！ありがとうございます。

お願いしてサインを入れてもらった

「はじめに」によると、これは石川さんが2019年に公開したCode readabilityというスライド（プレゼン資料）を元にして書かれた本なのだそうです。

私、知ってるんだ…何度もプレゼンで使われて、生で色んな質問や反応を受けてきた資料をベースに登壇者が本を書くと、ものすごくいい本になるんだって知ってるんだ…！みんなが「え、どういうこと？」ってつまづいたところがちゃんと補修、補強されているので、独りよがりなところがなくなってて、初版なのに転生10周目みたいな本になるんですよ…！

ちなみに元のプレゼン資料については、そちらも石川さんが解説しているブログがあるので、そちらを見ていただくとよさそう。

engineering.linecorp.com

「読みやすいコードのガイドライン―持続可能なソフトウェア開発のために」は、このCode readabilityというスライドを用いた8時間に及ぶプレゼンを生で聞かなくても、読めば同じ内容を理解できることを目指して書かれた本なのだそうです。すごい。

章立てはこんな感じです。

第1章　可読性の高いコードを書くために
第2章　命名
第3章　コメント
第4章　状態
第5章　関数
第6章　依存関係
第7章　コードレビュー

私がコードを書き始めた最初の頃に、「センスがない」と叱られた命名やコメントについても第2章および第3章をまるまる使ってしっかり解説されていて、あのときおうちで「センスが…ない…」とめそめそ泣いていた私にこれを読ませてあげたい…！という気持ちになりました。

また第7章では、プルリクエストを用いたコードレビューの仕方について解説されています。レビューイ（レビューを依頼する人）とレビューア（レビューを実施する人）、それぞれが注意すべきことが紹介されているのですが、特にレビューアに向けて書かれた「レビュー実施時の基本原則」の部分が、過去に自分が話した「文章の改善点を上手に指摘する方法」と重なる部分もあって「わかりみのかたまり～～」となりました。

ちなみに「読みにくいコード/読みやすいコード」の例として出てくるコードのベースはKotlinなのですが、なんというか具体的なコードを挙げてああしましょうこうしましょうという話だけでなく、その手前の「可読性ってどういうときに重要なんだっけ？」「可読性が低いと誰がどう困るんだろう？」「可読性を持続的に追求するにはどういう環境が必要かな？」といった「コード以前」の話もたくさんあったので、「Kotlin読めないしなー」と思ってこの本を読むか読むまいか悩んでいる方がいたら、読むといいよ！とお伝えしたいです。（現に私はKotlin書いたことないけどとても学びの多い本だった）

全編を通して「これはやめましょう」だけではなく、「こういう理由でこれはやめましょう。代わりにこうするといいですよ」が提示されているので、「なんでだめなの？！じゃあどうすればいいの？！」という心の声を響かせずに済みます。読み手への配慮が…隅々まで行き届いている…！

コード上の形式的なコメントから生成されるドキュメンテーションについても触れられていて、自分の仕事（開発者向けのドキュメントを書くお仕事）との関わりも感じてほっこりしました。

可読性と言われると難しく感じるかもしれませんが、私は初学者にこそ読んでもらいたい本だなと思いました。「命名やコメントにセンスがない」と叱られてめそめそしているそこのあなた、「まだまともにコードも書けないのに、コードの読みやすさへの配慮なんて…上級者向けでちょっと私には難しすぎるんでは…」と思わず、ぜひ読んでみてください。

gihyo.jp