ソフトウェアエンジニアリングと一見関わりはなさそうで、しかしチームで成果を出す過程においてとても重要だと筆者が考えているコンセプト、 "Working Out Loud" について書いてみます。 日本語の記事がほとんど見当たらないのであまり知られている言葉ではないかもしれません。 対象読者 以下に興味や関心を持つ方を対象読者として想定しています。 チーム開発におけるコラボレーション手法 チーム開発者としての振る舞い方 テックリードやスペシャリストの育成 が、本心ではチーム開発する全ての方に届いてほしいです。 まえがき ある夜に同僚の@ujihisaと近場ないし遠方のEngineering ManagerやVPofEの皆さんと話す機会があり、その折にふと筆者がこぼしたのが 「開発などの日常の業務において自分がやっている以下の思考様式が大変便利なので、この考え方を最近入社したメンバーにもインス

世はまさに大サブスクリプション時代。この潮流の中で弊社スマートバンクもまた、去る2023年7月12日にB/43プラスというサブスクリプションサービスをリリースしました。 サブスクリプションといえばユーザーに提供されるコンテンツや機能といった直接的な価値に焦点が当たりがちですが、その土台にはサブスクリプションビジネスを成立させるための課金システムがあります。本記事では筆者が行った課金関連の開発を振り返ってみて重要だったポイントや工夫点を伝えてみたいと思います。 すでに世に多くのサブスクリプションサービスがある中で、課金システムの実装はコモディティ化した単純な作業に思えるかもしれません。しかしながら自社サービスにてゼロから実現するとなると、想像よりも多くの思考と意思決定が必要とされる、エンジニアリング観点ではとても奥深い題材といえます。いち開発プロジェクトのケーススタディ、あるいはいちプログラ

LFAを書いたときの話にあるKernel#loadの第2引数で名前空間的なものを作れるんだけど、loadした先のファイルでrequireされてたらダメなんだよね、という話の続き。ダメなんだよねー、で終わってたんだけどRubyKaigi2023で@shioyamaさんのMultiverse Rubyを聞いて、ここに仲間がいた!!! ってなって、さらにそのあとバーで飲みながらやろうやろうって盛り上がったので、なんか色々考えている。 RubyKaigiの話は別途書くとして、いまはとりあえずこっち。 後半に、こんなものが欲しい、という話、および読んだ人の意見が欲しいということが書いてあるので、このあたりに何か思うところがある人はぜひ読んでみてください。どっちかというと、自分以外のRubyユーザがどう考えているのかを、bugsに出す前にまず知りたいなと思っています。 動機 Rubyにはみなさんご存知

私たちソフトウェアエンジニアは、コード品質についてしばしば論ずるけれども、ではコード品質の良し悪しがどれほどビジネスに影響するのかと問われると、回答に窮する。只々、「コード品質が悪いと変更により多くの時間がかかります」だとか、「欠陥の修正に追われて開発時間が奪われます」だとか、個人の経験やエンジニア的一般論に頼った定性的な説明に終始するしかない。ソフトウェアを繰り返し変更する頻度が高いほど、コード品質が開発時間に影響を与えるのは確かにそのとおりだと思えるが、はたしてそれは、どれほどのインパクトなのだろうか。 2022年の研究論文 "Code Red: The Business Impact of Code Quality – A Quantitative Study of 39 Proprietary Production Codebases" では、コード品質がビジネスに与えるインパクト

卒業していく君へ。 卒業おめでとう。本当は面と向かって言ったほうが良いのだけど先生という立場だと私の発言が思った以上に重くなってしまうので直接君にはいえない。でも、君への言葉を一度形にしておかないと私の頭に一生こびりつきそうなのでここに書かせてもらうよ。 今年、君は卒論に苦しんだね。君が卒論に苦しんだ理由は自分でも分かっていると思うけど、常に外部に正解を求めたことにあるんだ。私が「どうして、それが正しいと思うの？その理由を教えて。」と聞くと、いつも君は表情を凍らせて黙ってしまったね。何度も何度も「研究には正解とか不正解とかない。誰も答えを知らないから研究になっているんだ。だから、自分の主張をとりあえず述べて、相手の反論が正しいと思えてから自分は間違っていたと考えれば良いんだよ。」と伝えたのだけど、最期最後まで君は自分の主張の正しさを自分の言葉で言えず、常に私の保証を求めたね。はっきり言って

目標設定むずかしいよね。正直嫌いとか意味がわからんと言う人も多いと思う。自分は適切な目標設定は必要なものだという腹落ちはしてるんだけど、なぜむずかしいかとかはうまく説明できなかった。 そんな時に EM.FM Re8. 本当に意味のある目標設定 でMBOの歴史から色々と話していてさすがだなー面白いなーと思ったので、自分もそもそも目標管理とは何なのかﾁｮｯﾄ調べてみることにした。 学術的にきちんと学べたわけではないので少しこわい部分もあるけれど、こういうのは誰かのためになるかもしれないし書いてみる。もし間違いや補足があれば教えてもらえると嬉しい。 目標管理の起源 目標管理の起源は欧米の研究者の中ではよく論じられているテーマらしい 諸説あるが、アリストテレスが 「成功するには目的意識を持て」 と言ったのが最初という説もある この起源とは関係ないが、Googleでは「効果的なチームを可能とする条件

この間はじめて「R地形」と呼ばれるところをゆるく滑ってきた。 R地形、よくわかっていないけどスケボーのランプのような、ハーフパイプのもっと緩い壁のような、そんなような感じの地形。 わたしは何年か前にスケボーを体験したことがあるんだけど、 ランプに入るのは補助があってようやく、という感じだった。 で、そんな体験はあるけどスノボはほぼ初めて。 R地形、沢に入ると体にかかる重力がぐわっと変わる。 雪があるしビンディングで足と板が固定されてるとはいえ、とにかく気を遣う。 体を小さくする、谷側に飛び込むようにする、上半身をきちんと使う。 スノーボードをやっているときは考えることが多すぎて、世の中全ての嫌なことを忘れている。 それが気持ちいいなあと思う。 ランニングだと、走る距離が短いからか、あまりテクニカルなことを意識しないからか、全くそこに辿り着けない。 スケボーもプッシュとチックタックしかできて

Better Code Reviews, Less Hassle, All in SlackAxolo takes your team's code review practices to the next level, integrating seamlessly with Slack to deliver real-time notifications and natural discussions. Enhance developer experienceFoster real-time, in-context discussions improving team collaboration and increasing developer satisfaction. Axolo creates a more enjoyable code review workflow. See o

Elon Musk’s reach on Twitter is dropping — he just fired a top engineer over it The chaos continues inside Twitter 2.0 as employees worry about what will break, what will get them fired, and what will get them busted by the FTC.

ちょっとTwitterに書いたら食い付いてくる人が多かったので、ではアピールしとこうと思った。 象印の加湿器、とにかく手入れが簡単でこれ以外の加湿器はもう二度と買う気がないというくらい最高— tagomoris (@tagomoris) 2023年1月7日 TL;DR 衛生面などを考えると加熱式加湿器*1を使いたい 加熱式加湿器は加熱部に残留物が結晶化して固まるので手入れがめちゃ面倒 象印のやつは電熱ポットと同じなので、たまにクエン酸ぶちこむだけで超ラク、最高です 加湿器運用の手間を減らしたい人にとにかくお勧めです 自分が使ってるのはこれ。今年大きいのを買い足した。旧モデルの小さい方とあわせて2台とも使ってます。 EE-DC35・50 | 加湿器 | 生活家電 ｜ 商品情報 ｜ 象印マホービン 加湿器を加熱式のに替えるとき、某社従来型*2と象印の(2020年モデル)と2台買ったんだけど、手

観測しようとすると、その観測が影響を与えてしまう感じで、おもしろい 自分の頭の中 この機能をチームで開発するのに、だいたい2ヶ月くらいかなぁと自分が頭の中で思っているとする。もし僕らの知ってる範囲ですべてが収まれば1ヶ月くらいで終わるかもなぁと思いつつ、まぁ、知らない範囲のことがあるだろうし2ヶ月くらいに思っておくのがいっか という感じ。6割ぐらいの自信 チームの中 チームメイトに「この機能いつ出せるかな？」って聞かれることはあんまりないと思うけど、もし聞かれたら「んー、2ヶ月くらいじゃない？もしかしたら、もうちょっと早くできるかもだけどね」ってそのまま頭の中を伝えると思う 聞かれることがあんまりないというのは、そもそも、チームでラフに見積もるから。Tシャツサイズとかストーリーポイントとかを使って「Mサイズだから2ヶ月くらいだね」って話をするだけで済む。「2ヶ月くらいだね」って言ったものは

なんか芸能人に影響されたって言うの格好悪いと思っててあんまり大っぴらに話したことなかったんだけど、id:kkawaとか id:ninjinkun とかに「メッチャ良い話だから書くべき」って言われて「そうだな、何を変な意地張ってたんだろう」と気が付いたので書こうと思う。 僕はコミュニケーションを頑張っている。 それはネットで見た星野源の言葉に影響されたからだ。正確に言うとその言葉で興味を持って原典の本を読んで「もっともだな」ど思ったので頑張っている。 「それまで、相手に好かれたい、嫌われたくないという想いが強すぎて、コミュニケーションを取ることを放棄していた。コミュニケーションに失敗し、そこで人間関係を学び、成長する努力を怠っていた。 　それを相手に「人見知りで」とさも被害者のように言うのは、「自分はコミュニケーションを取る努力をしない人間なので、そちらで気を使ってください」と恐ろしく恥ずか

Automerge is a library which provides fast implementations of several different CRDTs, a compact compression format for these CRDTs, and a sync protocol for efficiently transmitting those changes over the network. The objective of the project is to support local-first applications in the same way that relational databases support server applications - by providing mechanisms for persistence which

子供が産まれて一年半近く経つが、時間が全然取れない。 ここ最近は新しい技術を何か積極的に勉強するということが特になく、20代の頃に得た知識でなんとか飯を食っている感覚がある。転職してから1年は業務でFlutterを始めていて、それだけ聞くと新しい技術を得ているように見えるが、自分の中では今までの延長線上にいるだけのような感覚がある。 20代の頃は必死になって技術書読んだり記事読んだり実際に手を動かしたりもしたけど、ここ最近は業務で必要な知識を業務時間内に得るだけで、業務では触らないような知識は全然身についていない。 モバイルアプリエンジニアはこの先オワコンになると思っており、上辺だけのエンジニアリングの知識では飯を食っていけなくなりそうな気がする。そのためバックエンドをもっと強くやっていくとか、ウェブフロントエンドなど手を広げたいが全然時間が取れない。業務でやるのが一番いいが、モバイルアプ

Actions Ecosystem Actions Ecosystem is a community-driven project that maintains many simple, independent GitHub Actions. The GitHub Actions are designed to be easily integrated with others, even ones developed by another project or your own. Getting Started To get started with this project, it's recommended to go through the recipes. Users The GitHub Actions maintained in this project are used an

Negative Capabilityという概念を最近知った。詩人ジョン・キーツが提唱したとされている用語で「事実や理由を性急に求めず、不確実さや不思議さ、懐疑の中にいられる能力」を意味する。対義語はPositive Capabilityで、所謂課題解決能力の事。 我が身に翻ってみると思い当たる事が多く、特にマネージャーをやっているとこの能力の有用性を感じずにはいられない。例えばよく目にするのは以下の様な事象だ。 新しく入ってきたマネージャーが成果を出そうと張り切って色々提案するが、芯を外していたり合意を得られてなかったりで現場でハレーションが起きる ある問題を解決する為に新しいツールを導入するが、新しいツールが更なる問題を引き起こし以前より状況が悪化する 組織内で色々改善活動を試みるが、すぐには効果が出ず反応も芳しくないので心が折れてしまう これらはpositive capability

1 on 1 (ワンオンワン) とは1対1のミーティングの事。ここでは毎週もしくは隔週で行われるマネージャとその部下(direct reports)であるソフトウェアエンジニアの 1 on 1 に焦点をあてる。よく 1 on 1 で何を話したらよいか分からない。話題がない。と相談されるので僕の思うところをまとめてみる。 僕はマネージャもソフトウェアエンジニアのどちらも経験があるので両側からの視点を提供できると思う。 マネージャ編 マネージャは 1 on 1 を部下のために開催しなければならない。自分のための時間ではないことを肝に銘じよう。部下には話したいことを何でも話してもらう。事前に「1 on 1 は君のための時間だよ」と説明しておこう。 1 on 1 が始まったら「何か話したいこと、気になることある？」と問いかけよう。焦ってはいけない。じっくりと待ってみよう。 たとえマネージャとしてプ

僕はチーム join 時に、Docker は初手で剥がすし、GitHub Actions でやっているワークフローの全体像を把握するのを次に行う、というのを基本的にはやっている。これはシステム構成やデプロイ周りの全貌を把握するのが好きなのと、何かが起きたときにコレをやっているのといないのとで問題切り分けの精度に圧倒的な差があるからなんだけど、join 直後にやるのが最適解とは限らない場面もある。 チームの人員構成として、テックリード業を既に担っている人が居る場合、追加人員にはテックリード未満の「プラスの工数として数えられる戦力」となって欲しい。この戦力というのは、「目の前に積み上がった問題を一緒に解いて欲しい」という期待。問題と言うよりも、既にタスクになっているものを消化したい、という期待の方が大きいと思う。 そういう期待があるときには、ちんたら Docker を剥がしている場合ではなく、

こんにちは。SRE Team の @chaspy です。次の10月で Engineering Manager をつとめて1年になります。 本記事ではもしかするとメンバーからわかりづらい Engineering Manager のしごとについて、昨年10月からの約1年間を振り返りながら説明しようと思います。 ところで「エンジニアリングマネージャのしごと」もうすぐ発売ですね。筆者もとても楽しみにしています。検索のノイズになるのは本意ではないので記事のタイトルはカタカナではなく英語表記にしました。 www.oreilly.co.jp なお、リクルートでは人事制度上 "Engineering Manager" というロールはなく、GM (Group Manager) が正式なロールです。EM と GM は重複する部分、そうでない部分ありますが本記事では割愛します。 基本情報 会社組織編 SRE T