Sansanは黎明期：入社時の会社のフェーズを自分が変える。｜nishiba
私はSansanに入社してちょうど3年になった。私の社員番号は1,000番代の前半。今、入社すると2,000番代になる。つまり、この3年で1,000人以上の人が入社し、2倍くらいの人数になった。 カジュアル面談や選考に進んでくれた人たちに「Sansanはどのようなフェーズだと思いますか？」と質問している。そうすると「BtoBのSaaSで日本最大級であり、大きな会社だと思います。」という返事が多い。 Sansan以外に未上場のスタートアップの選考にも進んでいることが多く、この「大きな会社」というのはスタートアップとの比較になる。そのため「大きい＝組織やビジネスがある程度完成している」と見なされているように思う。 しかし、実際は全然違う。そこで次のような話をする。 「例えば、Microsoftに社員番号2,000番代で入社した人はどんな人だろう？ その人たちはWindows 96以前に入社して
イベント”JTCのリアルトーク！KODANSHAtechとAEON”をFindyさんオフィスで開催しました！
こんにちは。イオンスマートテクノロジー株式会社（AST）でSREチームの林 aka もりはやです。 2024年7月18日にイベント「JTCのリアルトーク！KODANSHAtechとAEON」を開催したのでレポートします。 発端 最初に感謝を申し上げたいのがFindyさんです。 本イベントの開催にいたる発端は2024年5月9日に行われたFindyさんの新オフィスお披露目イベントでした。 このイベントはパブリックなものでなく、Findyさんと縁がある（？）方に声が掛かっていたようで参加されている方々は私が経験したことがないほど多様で幅広いものでした。 初対面の方でもSNSのアイコンさえ見れば「あの人だ！」となる方ばかりで、刺激的な会話をするなかで出会ったのがKODANSHAtechのもっとさんでした。 ”もっとさん”とはその場で意気投合し、互いにJTCに所属する身であることと、JTCの中でも面
「爆走できますか?」という問い - 私が歌川です
「困っていますか?」と質問するよりは「順調ですか?」と聞いたほうがいい、という話はけっこう聞くと思うけど、それを更に推し進めることで「爆走できますか?」「爆走できていますか?」というところまで持っていけると思う。 何も困っていること・障害がなく、真に爆走できている状態なら自信を持ってイエスと答えられるだろうけど、実際には何かしらつまずきポイントがあることのほうが多い。そういうときに、どこで詰まるか・詰まりうるか考えたり、みんなで議論したりするのを促進するため、「爆走できる」という状態を最初から理想として持っておいて問いかける。本当に爆走できるならそれに越したことはないだろう。 「爆走」というと全てを無視して最高速で走りつづけるというニュアンスがあるかもしれないけど、本当に全てを無視しているのではなく、取り組みたいことの障害となることが全て解決されている理想形のことを指して「爆走できる」と呼
技術コミュニティの活動を通して人生に整合性がとれた ─ 未経験30代がRubyのコア実装に挑むようになるまで - Findy Engineer Lab
高校を卒業した後、コールセンターでの派遣業務や非正規の事務職といった経歴から、33歳でまったく異なるソフトウェア開発の世界に飛び込んだ塩井美咲（@coe401_）さん。短期間でプログラミングのスキルを学び職業プログラマーへの転身を果たしただけではなく、プログラミング言語Ruby自体の開発をテーマとする国際カンファレンスRubyKaigiでも4年続けて発表するほどになっています。 キャリアチェンジの経緯やプログラマーとしての歩みについて塩井さんに伺うと、むしろ技術コミュニティとの出会いと積極的な参加があったからこそ、エンジニアとして多くの成長があったことが分かります。その熱意のベースには、何のためにソフトウェア開発者を志すかという思いがありました。 ▲ 松本市で開催されたRubyKaigi 2023に登壇する塩井美咲さん ソケットライブラリの改善にRubyの開発助成で取り組む 世の中をよくす
1on1 やるときの話 (2)｜Sotaro Karasawa
5年以上前に↑こういう記事を書いていてとても良い記事だったので、マネージャーになる人や支援先等には基本読むように勧めてるんですが、 そろそろ時間がなくなったのでw、そして長くなってきたので、 ・どのような頻度でやるのか、 ・こういう話が出たときはどうするのか、 ・マネージャーとして1on1に挑むときのメンタリティ などについて次回書きます。 と書いておいて、その次回が一生書かれていなかったので、書いていこうと思います。(書いて、と言われた… はい😇) 今回は、頻度と時間、の話。 どのような頻度でやるか目的が明らかになったので、どういう頻度でやったらよいかを書いていきます。 最初に結論ですが、「頻度や時間は、内容による」です! というと、全くしょうもないコメントだと思うので、一旦以下に自分がやったことがあってよかったな、と思う目安をパターンごとに書いていきたいと思います。 隔週1時間 迷子
キャディ、製造業AIデータプラットフォームとしての、第二章。｜加藤/キャディCEO
こんにちは。キャディの代表の加藤です。 今回は、創業から7年間で最も大きな事業アップデートがありましたので、それについて書いています。最初に言いますが、ウルトラ長いですｗ 0: 製造業って面白い品質検査結果は、3点とも全て不良。 キャディが2017年11月9日の創業よりちょっと前に受注した記念すべき1号目の製品は、電車に使われる板金製品でした。一番最初は品質が怖いからと、念には念をで20社以上回った加工会社さんの中から、東大阪市を中心にトップ3の会社さんに全く同じ製品を発注。それにも関わらず、届いたものを私と創業メンバーの幸松の2人で検査したところ、結果は全て品質不良でした。今でも忘れない、3つの不良の内容は、穴のサイズ違い、塗装のムラ、寸法違い。既に時間は夕方で、翌朝自分でお客さんのところまで持って運んで行かないといけない。そんなわけで、最も自分たちで直せそうな「穴のサイズ違い」だった部
Ruby の CSV が nil を返さないようにする - tmtms のメモ
Ruby の CSV ライブラリはとても便利なんだけど、ひとつだけ問題があって、CSV をパースしたときに nil を返すことがある。 つぎのような CSV をパースすると2番目のカラムが nil になる。4番目のカラムは空文字になるのに！ hoge,,fuga,"",piyo require 'csv' CSV.parse_line('hoge,,fuga,"",piyo') #=> ["hoge", nil, "fuga", "", "piyo"] なので CSV のパース結果は全部文字列だと思って使ってるとエラーになってびっくりする。 CSV.parse_line('hoge,,fuga').map(&:upcase) #=> undefined method 'upcase' for nil (NoMethodError) CSV を生成するときも nil と空文字で変わる: pu
散歩が好き。 - ダンの日常2
僕の好きなことランキングトップ3に入るのが散歩です。 他に好きなことは、サイクリングや温泉。楽器を弾くのも好きだったんですけど、これより上達するには途方もない時間を費やさないといけないと気づいてからはあまり練習をしなくなってしまった。でも好きは好きです。 散歩が好きになったのは、大学を卒業して、22年間住んだ北海道を出て東京で一人暮らしを始めたくらいだったと思います。北海道にいたときも、もともと歩くのは嫌いではありませんでした。バスが来るまで時間があるとき、歩いて次のバス停まで辿り着けそうなときはそうしてましたし、読みが外れてバスに追い抜かれたこともあります。 22歳で知らない土地で一人暮らしを始めて、歩くたびにいろんな発見があるのが楽しかったんでしょうか。今の夢は全ての道を歩くことです。 京都に引っ越してからは、さらに散歩が捗るようになりました。京都はとても歩きやすいんですよね。碁盤の目
再現性の無い多様なキャリアの前例があることに価値がある | おそらくはそれさえも平凡な日々
大吉祥寺.pmの前夜祭「生存者バイアスナイト」で話してきた。 https://junkyard.song.mu/slides/survivor-bias-night/#0 同年代の優秀なエンジニアの方から「自分のキャリアは再現性が無いから他人の参考にならない」という話をよく聞く。果たしてそうだろうか。私はそういう人たちにもっと自分の経験の話をしてもらいたいと常々思っていた。 彼らは「思い込みの結果として上手く行った」「単に運が良かった」「だから普遍的なノウハウにならない」そんなふうに自覚している。だから、そんな普遍的ではないノウハウを偉そうに声高に話したがらないし、ましてや、それを押し付けるような老害的振る舞いになることを恐れているようにも見える。そういう謙虚なスタンスは好ましくも思う。 でも実際は一つ一つの経験には大きな意味がある。普遍的ではないかも知れないが、それでも話してみると、自分
大吉祥寺.pmで僕とワインと鍋のことを話してきた｜suthio
メインは下記の発表をしに行きました。 割ともっと話せるかと思ったけどうまく話せない部分もあって難しかった。 本当は他の人の発表をもっとちゃんと聞きたかったのですが、自分の発表があり、ドキドキしていたので集中できなかったのは反省です。 どこかで飲食店経営の話ができたらいいなと思っていたのですがこんな機会をいただき、magnoliak さんありがとうございました！ 会場では非公開情報をたくさん話したのですが、公開する資料には情報を抜いてから公開しています。（本当は全部公開したいんだけど色々なステークホルダーがいたりするのでごめんなさい） 伝えたかったこと「ソフトウェアエンジニアリングやプロダクト開発で学んでいる内容って他の分野での応用可能性はかなりあるのでは？」と昔から思っていて、みなさんにも同じように思ってもらえたら他の業種でもソフトウェアエンジニアリングの知識が広がっていって世の中良くなっ
大吉祥寺.pmに参加し、登壇し、DJをやった #kichijojipm - 私が歌川です
大吉祥寺.pmに参加しました。この記事の公開をもって吉祥寺からの帰還といたします。 登壇した speakerdeck.com タイトルは「君たちはどう生きるか」をモジりました。 コードレビューの目的は「コードの品質を保つこと」「知見を共有すること」である、という観点を踏まえ、自分がどのようにしてコードレビューに向き合っているか・向き合うべきと考えているか を話しました。発表後や懇親会などでポジティブな感想をいただいたり、コードレビューの難しさや向き合い方の話をしたりできて、自分が当初思い描いたよりもいい発表ができたんだろうな、と思っています。 実は、発表のテーマ自体はすぐ思いついたのですが、何をどう話すか・正解をどこに置くべきか など非常に悩みながら発表資料を作りました。弊社の人は知っているかもしれませんが、発表資料を一度レビューしてもらったあと、ほぼ全てのスライドを書き直して再構成してい
真にチラつかないダークモードをついに実現したぞ。実現方法と気付きを書く | stin's Blog
真にチラつかないダークモードをついに実現したぞ。実現方法と気付きを書く2024/07/14 14:36 nextjsreact このサイトはダークモードに対応しています。なぜならダークモードは基本的人権だからです(要出典)。 しばらく、サイトに訪問した直後ライトモードとダークモードが切り替わってチラつく現象が発生していました。これを改善したので、実装方法と気付いたことを残しておきます。 ダークモードの実装方法一般に、ダークモードの実装方法は3タイプあります。 OSによるモード設定を反映する メディアクエリー@media (prefers-color-scheme: dark)を使うと、OS側でダークモードを指定している時だけ有効になるスタイルを書くことが出来ます。 JavaScriptでも判定が必要な場合はmatchMedia("(prefers-color-scheme: dark)")
エンジニアリングマネージャとして入社した最初の取り組みとして、エンジニア全員(およそ100人)と1on1をしました - だいくしー(@daiksy)のはてなブログ
はてなにエンジニアリングマネージャとして入社して2ヶ月と少し経ちました。 マネージャとしての「最初の100日」もいよいよ終盤です。 note.com 入社して最初の取り組みとして、およそ100人のエンジニア全員との1on1を実施しました。 なぜ全員とやろうと思ったか イギリスの人類学者であるロビン・ダンバーによって提唱された「ダンバー数」というものがあります。 これは、人間が安定的な社会関係を維持することができる人数の認知的な上限について提案された数字です。大雑把に説明すると、人間が相互に認識しあって社会関係を築ける人数はおよそ150人程度、というものです。 要するに1つの組織でお互いに顔見知りの状態で活動ができる集団の人数上限が150人前後であるということです。 このエントリを書いている時点で、はてなのエンジニアはおよそ100人ほどいます。つまり、はてなのエンジニア組織は、まだダンバー数
「開発生産性の教科書」という本を執筆しました - Findy Tech Blog
こんにちは！ファインディ CTOの佐藤(@ma3tk)です。 表題の通り、約1年半ほどの期間をかけて「エンジニア組織を強くする 開発生産性の教科書 ～事例から学ぶ、生産性向上への取り組み方～」(以降、開発生産性の教科書)という本を執筆しました。 本日(2024年7月11日)発売となりましたので、改めて「開発生産性」に対する思いをお伝えしたり、本の内容の一部をご紹介したいと思います。 「開発生産性の教科書」のご紹介 エンジニア組織を強くする 開発生産性の教科書 本の概要は次のとおりです。 項目 詳細 タイトル エンジニア組織を強くする 開発生産性の教科書 ～事例から学ぶ、生産性向上への取り組み方～ 著者 佐藤 将高、Findy Inc. 発行 技術評論社 定価 2,860円（税込） 発売日 2024年7月11日 ISBN 978-4297142490 購入 Amazon / 楽天ブックス 全
Capybaraとreg-cliを使ってお手軽にビジュアルリグレッションテストを行える環境を整備しました📸 - メドピア開発者ブログ
こんにちは、MedPeerの開発を担当している森田です。 今回は私が開発に参画しているMedPeerに元々E2Eテストで利用していたCapybaraと、reg-cliを利用してビジュアルリグレッションテスト(以下VRT)を行える環境を整備したので、それについてご紹介させていただきます。 なぜ、VRTを導入するのか？ VRTの要件と技術選定 実際に構築したVRT基盤の概要 VRT基盤の具体的な話 System Spec内でスクリーンショットを取得する reg-cliでスクリーンショットの差分をチェックする 分かりやすいコマンドでVRTを実行できるようにする CIで差分をチェックする OS間での利用フォントによる違いを吸収する おわりに 参考にさせて頂いた資料 なぜ、VRTを導入するのか？ MedPeerでは元々System Specを活用したE2Eテストを利用してフロントエンドを含めて品質を
NISAは「ニーサ」なのか「ナイサ」なのか - 詩と創作・思索のひろば
[B! togetter] アメリカのVTuberさんが『日本人はカスコー(Costco)のことをコストコって言うんやで 発音かわゆす』みたいなお話をなさっていた「tを読まないんか」 このブコメに「NISAも英語読みならniceのようにナイサと呼ぶべき」というものがあり、それは違うんじゃね？ と直感的には思ったものの、そんなに説明できる感覚でもないなと思ったので調べてみた。 結論としては「ニーサ」で問題はないだろうと思う。 英単語を構成する文字のうち子音をC、母音をVで表すことにする（一般的な表記のようです）。ここでは「CiCeという形で表される英単語のiにおける発音のルールが、CiCaという形式にも適用されるのか？」という疑問に否定的な回答をしたい。 そのために、 まずCiCaの形（NISA）をとる既知の英単語における "i" の発音がどのようであるか、 その後、CiCeの形（nice）
良いコードとは良い感じのコードである - ennui's blog
こんにちは、imazです。10年ちょっとRailsエンジニアをしています。 インフラは苦手、CSSやJavaScriptも得意ではない、アーキテクチャとか設計も得意ではない… SQLとかデバッグが好きです。答えがあることが好き！ 作業中めちゃくちゃ独り言が出るのでオフィスで働けないタイプです。 Re: 良いコードってどんなコードですか？という質問を受けたら何と答えるか snoozer05.hatenablog.jp 今日はしまださんの記事を読んで、私ならどう答えるかなぁ、自分の場合はこうだなぁ、と思ったことを書いておきます。 良いコードを書くために 私がコードを書くときに心がけているのは「コードがなぜそうあるのか説明できるようにすること」です。 コードの一行一行に対して、どういう選択肢があってなぜそのコードを選んだのかというのが理解できているのが良い状態だと思っています。 簡単な例 たとえ
ベースマキナのエンジニアブログを始めます - ベースマキナ エンジニアブログ
こんにちは、syumaiです！ このたびベースマキナのエンジニアブログを始めることになりました！ 本記事では、エンジニアブログを始めることになった経緯や、これからどういった内容について書いていくのかなどについて簡単に紹介します！ ベースマキナとは 今回は、一本目の記事ということで、簡単にサービスの紹介もさせてください！ ベースマキナは、一言で言うと管理画面のSaaSです。特に社内向けの管理画面をメインの用途としたプロダクトです。 社内向けの管理画面は専任のチームが存在しないことも多く、 ライブラリの更新、新機能追加のメンテナンスが滞る 権限管理の実装を十分に行えない といった課題を抱えている場合があります。 ベースマキナでは、任意のデータベースやAPI (REST API / gRPCなど） への接続を行ったうえで、 処理実行用のフォームの生成 入力値へのバリデーション 権限管理、承認フロ
PdM/EMが気づくべき「技術負債」の異変
技術負債が溜まっている勘所について。現場のエンジニアは実際のシステムを触っているので変更や追加をする過程で当事者になるのでおおよそ異変に気づく。 一方、実際にそのシステムに対となるプロダクトに関わっているのはエンジニアだけではない。PdMやEM、事業責任者がいる中でこのメンバーにどう常に変化し続けるシステムアーキテクチャの異変に気づいてもらうのか、自ら気づかせるのかは至難の業である。 とはいえ、つばり一番わかり易いのは工数の予測精度の幅がある。 以下の3つのフェーズがあったときにそれぞれのズレが大きい場合は負債が溜まっていることが多い。（特に、1.と3.） 一般的な視点と現場システムへの理解度のズレ詳細から開発手前での予測のズレ予測工数と実績工数のズレここでいう工数予測がズレるのはエンジニアリングスキルの問題ではなく、システムに関する理解度の認知問題によってズレるケースが該当する 1.一般
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
君たちはどうコードをレビューする (される) か / 大吉祥寺.pm
