今回初めて個人サークルとして技術書典に本を出すことにしました。以下のURLから500円で購入できます。 techbookfest.org 同人誌を出すに至る経緯 初めての同人誌の執筆で大変だったこと、面白かったことなど 目次 同人誌を出すに至る経緯 私は元々ブログに自分の考えをアウトプットしたり、勉強会で発表することをある程度得意としてきましたが、一から同人誌を作るという経験がありませんでした。技術書典については前職はてなにいた頃に、Hatena Tech Bookへ寄稿するという経験はありましたが、一冊丸々書くことなんてできるのだろうか？という思いからチャレンジしてみました。 テーマとしては、直近自分が書いたブログや考えてたことで組織周りのこと（特にエンジニアのキャリアについて）が書きやすいかなと思い、その辺りの内容を改めて整理し直すことにしました。 blog.stenyan.jp bl

情報のインプットについてたまに悩んでいて、しばらくRSSリーダーとして Inoreader を使ってみていましたが、最近「個人SlackにRSSフィードを流す方式」に戻しました。日々仕事も趣味もSlackやDiscordを眺めているので、そのままの体験でニュースを追うことができるのは個人的に便利です。 個人SlackにRSSを流すためのTips 基本的にはRSSフィードのURLを /feed subscribe URL で登録するだけですが、他にもいくつかTipsがあるので紹介します。 まず特定のGitHubリポジトリのリリース通知を受け取りたいケース。 GitHub Slackアプリの /github subscribe コマンドで releases に購読する方法はありますが、たまに自分が管理していないリポジトリだと権限が足りずに購読できないことがあります。その場合はリポジトリの /r

株式会社カケハシに入社しました - stefafafan の fa は3つです から、最初の1週間が終わった。ほとんどオリエンテーションなどで実際の開発はあまりしていないけど、チームには配属され開発環境のセットアップをしたり日々の会議には参加している。 前職と似ているところもあれば違うところも沢山ある。ドメインが違うし、前職には存在しない職種の人もいる。そのため、全く同じ調子でテキストコミュニケーションをした場合にどういう印象を与えるのか現時点ではまだわからない、みたいなところがある。会話の進め方に限らず、他所から参加したばかりのメンバーに何かを指摘された際は人によっては若干の拒否反応を示してしまう可能性もある。 そういったことを考えながら丁寧なコミュニケーションをとることを意識していたのが今週。チームに入って開発プロセス周りで改善案が既に若干思いついていたりするけど、そもそも過去の経緯や

2017年に以下の記事を書いていました。最近も時々この記事が引用されたりX (Twitter) でもいまだにシェアされたりしているのを観測しています。 blog.stenyan.jp なおこれはもはや7年前の記事で、ベースの考えは大きくは変わっていないものの、普通に自分用のチャンネルをいまは作っています。 運用次第で良し悪しある まず結論としては、チャンネルを作ったほうが良いとか作ってはいけないということよりも、使われ方（運用）方法次第で上手く回らない可能性があるよねという話だと思っている。なので、Xなどでtimes不要論が流れてきても「結局どう運用しているか次第だな〜」とニュートラルよりな気持ちで静観している。 例えば以下のような運用の場合はひょっとすると見直した方が良いかもしれない。 チームのチャンネルでは基本的に何も書かずに、自分の分報に仕事に関する考えや思いを書き続けている→チーム

From: 株式会社はてな (2015/07/01 - 2024/03/31) To: 株式会社カケハシ (2024/04/01 - ) 初めての転職、引き続きソフトウェアエンジニアとしてやっていきます。 株式会社カケハシについて 株式会社カケハシは前職と違って医療ドメインの企業です。ただ、実は私も会社のことを元々あまり知りませんでした。 私がカケハシを初めてちゃんと認知したのは、 id:bufferings さんのエントリでした。彼の記事をいくつか読んでソフトウェアエンジニアとしてとても信頼できそうだったので、そんな彼が入社する会社はどういうところなんだろう、とこの時思いました。 bufferings.hatenablog.com その後、はてなブックマークをウォッチしているとカケハシのテックブログが何度かホットエントリ入りしているのを見ていて、Regional Scrum Gather

すてにゃん Advent Calendar 2023 というのを一人で開催していたが、2023年には終わりきらなかったどころか、その後こっそり記事を登録していって、3月にやっと終わった形になってしまった。ここでは原因と今後の対応について考えたい。 状況 12/9 頃までは、基本的に1日遅れくらいの状態で記事を投稿していた 個人ブログの記事をGitHubで管理するようにした - stefafafan の fa は3つです 12/10 の記事はさらに遅れて 12/19 に投稿された Fukuoka.go #19 Reboot に参加した #fukuokago - stefafafan の fa は3つです 12/13 の記事でさらに遅れが広がって 12/29 に投稿された エンジニアリングマネージャーの4領域はEM以外のメンバーでも濃淡はあれど意識する必要がある - stefafafan の

2024年1月31日を最終出社日として、新卒から8年半ほど勤めていた株式会社はてなを退職します。次の会社は決まっていますが、そちらについては入社エントリでお話しします。 はてなでの思い出 サーバー管理・監視サービス「Mackerel」 出版社向けWebマンガビューワ「GigaViewer for Web」 マンガ家向けWebサービス「マンガノ」「ジャンプルーキー！」 ソフトウェアエンジニアとしての発信 退職を決意した理由 今後が楽しみ はてなでの思い出 社内でいくつかのプロダクトに関わらせていただきました。「Webアプリケーションエンジニア」という職種でサーバサイドやフロントエンドのコードを書いたり、TerraformやAWS CDKのコードを書いたり、時にはスクラムマスターやテックリードなどもしてきました。「はてなブログ」のような社名を冠したサービスには結局携わらないまま転職することにな

以前会社で「Team Topologies読書会」に参加した際に、認知負荷には3つの種類があることを知りました。それ以降新しいメンバーのキャッチアップについて考える際に毎回この3つの種類について思いを馳せるようになっています。 チームトポロジー　価値あるソフトウェアをすばやく届ける適応型組織設計 作者:マシュー・スケルトン,マニュエル・パイス日本能率協会マネジメントセンターAmazon 心理学者ジョン・スウェラーが提示する三つの種類とは「課題内在性負荷」「課題外在性負荷」「学習関連負荷」です。Team Topologiesにも書いてあったようなことを元に軽く紹介します。 課題内在性負荷とはタスクに直接関連する負荷であり、プログラミング言語そのものの知識などを含むそうです。 課題外在性負荷とはそのタスクというよりは周りの環境に関連する負荷であり、覚えにくいコマンドの羅列だったりするそうです。

Go Conference mini 2023 Winter IN KYOTO というイベントに参加して、表題のGoサブ会について発表しました。 speakerdeck.com Goサブ会設立までの経緯について大体資料に書いてありますが、そもそも自分がGo言語への関心が高まっている背景も少し書いておこうと思います。 自分は2015年にはてなに入社して、最初はMackerelチームに所属していたため当時からGoを書いていました。またこのあたりではてな東京オフィスをGoのリリースパーティ会場として活用したりしていたので、Goに対する「やっていき」がありました。 チーム異動して今度はPerlを書くようになり、Goは一旦触る機会が減りました。Perlは古い言語ではありますが色々と便利ではあるし、YAPCなどのコミュニティも温かくてとても好きです。仕事で書かなくなったGoからは一時的に離れちゃいまし

同僚が1on1の際に他の人がどういう話をしているのか気にされていたので、便乗してブログに書きます。 ということで人が1on1の時間に何を考えてどう使っているのか気になっている1on1で何を話すか考えてる - tomato3713’s blog 前提 株式会社はてなは新卒から所属しており、今年で9年目 現在チームでテックリードをしている。Webアプリケーションエンジニアとしてコードも日々書いている とはいえ自分もメンティーは持っていなくて、1on1してもらう側の1人 最近1on1に向けて考えていること 前提に書いてある通り、自分はこの会社では古参で普段の仕事の仕方だったり同僚とのやりとりやカルチャーについての大きな悩みや不安はないです。その代わり、テックリードや30歳になったエンジニアとしての悩みや考えはあります。ということで以下のようなことを考えています。 テックリード どのような振る舞い

私はいま会社でテックリードをしていますが、いちエンジニアとして技術的改善をチームに提案するスキルに関してまだ課題感を持っています。その際同じくチームに所属しているエンジニアリングマネージャー（EM）の方にヘルプしていただき、実際に提案資料をペアライティングした中で湧いたイメージがあるのでブログとしてまとめて自分の考えを整理してみようと思います。 効果的なストーリーテリングのための既存のフレームワーク 技術的な提案をするには効果的なストーリーテリングをするスキルが必要だと考えています。私はストーリーテリングに関して詳しくありませんが、仕事を通じて以下の二つのフレームワークを知りましたので軽く紹介します。世の中には他にもいろいろあると思いますが、基本的な考え方は近いのかなと想像しています。 空・雨・傘 STARフレームワーク 空・雨・傘 EMの方と会話する中で「空・雨・傘」というフレーズを何度

最近少しずつ技術系のイベントでの発表機会を増やそうとしています。その中で、大きめなイベントだとまずCall for Proposals (CfP) という、プロポーザルを出したらそれによって選考が行われ実際に発表できるかどうかが決まる制度があります。ここで出したプロポーザルは必ずしも通るわけではないですが、出さない限り発表はできません。 プロポーザルを出すためにネタがないといけませんが、最近自分は「完璧な資料やアウトラインはないけども、当日までにまとめることはできそうだな」という感じのものをプロポーザルとして出したりしています。 具体的には、 Go Conference mini 2023 Winter IN KYOTO では、自分が社内でチーム横断の「Goサブ会」という職能グループのオーナーをやっているのでその話についてのプロポーザルを出しました YAPC::Hiroshima 2024

まだ荷解きの最中ですが福岡に引越しました。会社は変わらず株式会社はてなです。以下の制度を活用した形となります。 hatena.co.jp 福岡(学生時代)→東京(新卒時)→神奈川(コロナ禍入ってすぐ)→福岡、みたいな感じで子供の頃住んでた場所に戻ってきました。 福岡に戻ってきた狙い いくつかありますが簡単にまとめると、 住みやすさの向上 (都会・自然のバランスの良さなど) ご飯のおいしさ オフラインイベント参加のしやすさ (神奈川から東京のイベントに参加するよりかは、福岡市に住んで天神や博多のイベントにいくほうが楽) 会社の制度を積極的に利用して、他社員も全国に散らばってほしいという思い よろしくお願いします 直近はPHPカンファレンス福岡2023に参加します。CloudNative Days Fukuoka 2023 も参加するかも？ 福岡周辺のエンジニア各位と交流したいです、よろしくお

この記事ははてなエンジニア Advent Calendar 2022の29日目の記事です。*1 昨日は id:koudenpa による 破棄し忘れたクラウドリソースに半年間金を払い続ける方法 - koudenpaのブログ でした。 今回は私のはてなエンジニアとして個人的に意識していることを一部紹介します。*2 ソフトウェアエンジニアとしての働き方 新しい概念を発明するのではなく社内外にあるものをもとに検討する 業務で利用しているOSSについて自分が気になった箇所・ハマった箇所は他者も気になっているはずなので issue を探したり、なければ自分で立てたりPull Requestを出す 自分がハマった箇所や解決した方法については社内外に公開する リモートワーク時の振る舞い 何事もテキストとして残す オンライン上の存在感を高める 終わりに ソフトウェアエンジニアとしての働き方 新しい概念を発明

つみたてNISAといえば年40万円までの非課税枠があるが、12ヶ月では割り切れないので設定するときに工夫が必要ということが知られている。自分はSBI証券を利用しているがこの設定をミスって4円余らせたことがあるので一応ブログに書いておきます。 ボーナス月を指定しているのに4円余らせる設定 (うまくいかない) 毎月33333円積み立てて、ボーナス月に100円、NISA枠ぎりぎり注文を有効にする。（ボーナス月は最低100円からとなってるのでこうしている）。 うまくいかない設定ボーナス月とNISA枠ぎりぎり注文を使うのはFAQにも書いてあるし、上記の設定では12月のみ33337円積み立てられてほしい。が、実際には失敗します。 faq.sbisec.co.jp おそらく原因としては、12月時点でのNISA投資可能枠が残り4円になっているともう発注ができないということになるため。これはさらに別のFAQ

以前から思っていたことで今日も同僚の分報チャンネルでも一言書いてたけど「年齢」のことを考えてもどうしようもないしむしろ意識したくなくなってきた。 子供の頃は誕生日を迎えるごとにまた一歩大人に近づいたと嬉しかったのだけど、いつの日かそういう嬉しさはなくなり今では「もうX歳だからそろそろ次のライフステージのことを考えるか……」「AさんはY歳で家を建てたらしい、Bさんは子供がもういるらしいが自分は……」「Z歳を超えてきてるしもう昔みたいに元気よく○○ができないな」みたいな感じになってきている。 そもそも10歳、20歳、30歳、40歳みたいな区切りは多くの人間がたまたま10進法に慣れていてちょうど良い区切りだと決めつけているし、何歳超えたらこうあるべきというのは存在しないし、何歳以降の人は元気が少ないとかもないと思う（全て人によるだろう）。 また、少なくとも成人後社会で生活するときや仕事するときに

今週土曜はISUCON予選なので、今日はひとりで private-isu をやっていました。 自分のリポジトリはこれです (INDEX貼ったりとかmy.cnfいじったりとかはサーバ上でやってるのでここに反映されていないですが) github.com 環境 READMEにあるようにx86_64のAMIを使って競技用とベンチマーク用サーバをAWS上で立てて使った インスタンスタイプもREADMEに合わせてc6i.largeとc6i.xlarge 作戦 各種計測ツールだけを信じる、なるべく一番重いボトルネックを順番に倒す 以下のような流れ ベンチ実行中に top -d1 -cを実行して負荷の様子をみつつ、go tool pprof -seconds 60 http://localhost:8080/debug/pprof/profile も実行してプロファイル採取 CPU userが重い時は m

我々も「スクラム」やるぞ！と言われても、イマイチどうしてスクラムでやりたいかが伝わっていないことがあると思います。あまり乗り気でない開発者は以下のようなことを感じているかもしれない。 スクラムを導入したところで嬉しさがわからない スクラム独自の用語が沢山あり、覚えるべき概念が多そうに感じる・学ぶための労力が割にあわないと思っている そもそもチーム改善とかに興味がない 改善に興味がなかったら厳しそうですが、スクラムを導入する嬉しさは簡単にでも紹介できたほうが良いと思うのであらためてちょっと整理してみます。 そもそもどういうことができているチームが優秀なチームかというのを考えると 以下のようなことができていると、優秀なチームなのかなと私は考えています。 改善サイクルが回っている（一定の周期で開発と振り返りと改善を繰り返すことができている） タスクが急遽差し込まれたり、方針が変わったときにスムー

yigarashi.hatenablog.com 上の記事読んだらいいこと書いてあって同感！という感じだった。 最近社内向けにも記事を書いてたのですが、以下の三つを目的として自分のチームにスクラムを導入しました。 ベロシティを計測しつつ、仕事を安定させられるようにする 長期タスクのリリース予測をしやすくする 開発者の幸福度をあげる/高い状態を維持する 現状ではまだうちのチームは仕事を安定させることが優先なのでこうしていますが、全ての仕事が安定的で最高な状態になったら次のゴールはベロシティをあげるのは納得します。 ただし上に書いてあるように、「開発者の幸福度」を維持することも大事な観点の一つなので、幸福度が下がるような形でベロシティをあげることを目標とするのは長続きせずよくない。具体的には、「次スプリントは今スプリントより高いベロシティ、+10pt載せましょう」と根拠なく増やし続けるとか、残

gihyo.jp リファクタリング特集よかった。「将来を予測してコードを書いていても上手くいかないから現在の仕様を反映したコードにしよう」みたいなことが序盤に書いてあって心当たりがあって「ウッ」となった。あと7つの凝集度と7つの結合度の紹介と具体的にどういう風にリファクタすると良いか（もしくはしなくてよいか）というのがGoのコードサンプルで説明されていてわかりやすかった。終盤Reactコンポーネントでも論理的凝集を意識したコンポーネントの切り方みたいな話があって、「確かにそこでも使えるのだな」とちょっと新鮮な気持ちになった。コンポーネント内で無理やり分岐で表現しなくて別々の機能を持ったコンポーネントなら別コンポーネントにすればいいだろうとは思っていたものの、これが論理的凝集であるというのは意識していなかった。 「入社した会社にすばやく適応する」特集も興味深くて良かった。以下の記事に大幅加筆