estie[B!]新着記事・評価 - はてなブックマーク (original) (raw)

7 users
www.estie.jp
estieでSRE, Platform Engineeringを推進している徳原です。 estieでは、組織横断でSREプラクティスやPlatform Engineeringを推進するPlatformチームが発足しました。この記事では、その取り組みの一つであるPreview環境実装について紹介させていたします。 Preview環境の導入 Preview環境とは、プルリクエストで提案された変更内容をもとに、自動的にコンテナイメージをビルドし、専用のURLを発行してその動作を確認できる環境のことです。この仕組みにより、コードレビュー時にコードだけではなく、実際の画面での動作も確認できるという大きなメリットがあります。一般的に、Preview環境の利点としては「コードだけでなく、UIや挙動も視覚的に確認できる」といった点がよく挙げられますが、estieではさらに次のような背景を考慮し、導入を決定

17 users
www.estie.jp
こんにちは！スタッフエンジニアの @kenkoooo です！Rust から Go で書かれたコードを呼び出す方法を紹介します。 日々ソフトウェアを開発するにあたって、我々開発者は多種多様なツールを利用しています。それらのツールはそれぞれ様々なプログラミング言語で作られていて、その中には Go 言語で書かれたものも多くあります。例えば、自分の AWS アカウントに紐づく権限情報を使って、ローカルからクラウド上で動いているリソースにアクセスすることができるツールとして session-manager-plugin があります。plugin の名の通り、単体で使うことは想定されておらず、AWS CLI で Systems Manager の機能を利用可能にするものです。AWS CLI は内部的にこのコマンドを呼び出して使っています。estie でも内部的に session-manager-plu

40 users
www.estie.jp
デザインエンジニアの表(@HirokiOmote)です。 Next.jsでApp Routerがリリースされて、1年が過ぎました。 弊社では、@hiroppyさんを技術顧問に迎え、Frontendを中心とした長期的な技術選定にご協力いただきました。 本日は、そこで得た学びをご紹介したいと思います。 App Routerについて 2023年5月にNext.js 13.4がstableとしてリリースされ、App Routerが登場しました。 ツリー構造でのファイル配置が基本となりました。 ディレクトリ構成とルーティング page単位・feature(機能)ごとに切り分けたディレクトリ構成が可能になったため、より直感的で再利用性の高い構造が実現しました。 // App Router . ├── dashboard │ ├── components │ │ ├── button.tsx │ │ └

3 users
www.estie.jp
こんにちは。estieでPdMをしている三橋です。 最近、estieでPdMよもやまをしていると、「プロダクトの力ってすごいよね」「プロダクトの力をもっと信じたいよね」という声をよく聞きます（「よもやま」ってなに？という方はこちらをどうぞ）。 この発言の意図を、私は「プロダクトドリブンでもっと事業の成長スピードを上げられるよね」、要は「プロダクトにもっと魂を込めた方が良いよね（超自分勝手な解釈）」ということだと理解したのですが、改めて考えてみると深い言葉だなーと思ったので、今日はそれに関して自分の想いを好きに述べようと思います。あくまでも個人の考えなので異論は大いに認めます。 この記事で伝えたいこと PdMは顧客から言われたものをそのまま作ってはいけないし、顧客が求めていないものも作ってはいけない。この2つの矛盾するアプローチを同時に満たす必要があるからこそ、PdMの仕事は面白く、難しく、

6 users
www.estie.jp
こんにちは！ VPoEの青木啓剛です。 現在、QA領域のマネジメントを兼務しておりまして、半年ほど前に コンパウンドスタートアップにおける理想のQAについて考えた という記事を執筆したものです。このときに思い描いた理想のQAへ少しずつ近づくために色々なトライをしているのですが、そのひとつとしてAPIシナリオテストツール「runn」を試してみた中で感じた利点などについて紹介したいと思います。 runnとは？ runn（ランエヌ）はオープンソースのシナリオテストツールです。YAMLのフォーマットで宣言的にテストシナリオを記述することができ、定型的なテストの実行に大変便利です。APIのシナリオテストを実行するのに便利な機能もいろいろと組み込まれており、そういった周辺機能も含めてコードでテストを定義することで再利用性の高いテスト整備が可能となります。 github.com 技術検証の背景 検証をは

6 users
www.estie.jp
こんにちは、estie (エスティ) で副業をしている新田 (しんでん) です。エンジニアは様々な働き方が広がり副業の人でも会社のブログを書くことも増えてきたように感じますが、副業の人が会社の募集要項を書くことは珍しいと思うので、ブログを書くことになりました！ この記事では2つのことをお伝えしたいと思います。 外部の人が募集要項を書くことで分かった発見 募集要項のCTOやEMの職の定義を深堀りした中での独自の解釈 仕事の依頼 私はキャリアブレイク中です。現在は未就業で、次の仕事で何をしたいかを検討する期間を取っています。とは言え収入が0なのも心配ですし、副業を通して良い会社を知る切っ掛けになるかもしれないと考え、短時間の副業案件を募集していました。そのタイミングで estie CTOのNariさんが毎月開催している会があり、CTOやEMなどのエンジニアが集まって、事前トピックはなしでその場

102 users
www.estie.jp
【プロフィール】田村 祐樹（たむら ゆうき） 1979年生まれ。ネバーランドカンパニーにてゲーム開発に従事。gumiにて技術担当執行役員CTOに就任し、ソーシャルゲーム開発を牽引する。 その後、ディライトワークスにてFGOをはじめとしたスマートフォンゲーム開発を担当。直近ではSmartNewsにてEMを務め、その後、不動産テックのCTOに着任。 2023年9月よりestieに参画。2024年2月に事業部CTOに就任。 エンジニアリングマネージャーの仕事といえば一言で言えば何でしょうか？ マネジメント？ 1on1？ ミーティングにでること？ 違いますね。 そう、マネージャーの仕事は「マネージャーのアウトプット＝チームのアウトプット+影響を与えた他のチームのアウトプット」ですからこのアウトプットを最大化することです。 （かの有名なアンディ・グローブの定義を持ってきました） このアウトプットの影

267 users
www.estie.jp
こんにちは！estieでビジネス部門の責任者をしている束原です。 2024年になりましたね。estieは決算月が12月なのですが、毎年期初に「今年こそが勝負の年だ」と言っている気がしており、それに対して「ガハハ」と笑い合えるメンバーで仕事ができているのが最高に楽しいなと日々痛感しております。 さて、こちらは事業の立ち上げ（事業開発）に関する記事です。 この記事に書いてあること estieでは「仮説検証」をやめようと思っている話 事業開発の成分の8割は営業だという話 かなり極論が並んでいますが(笑)、事業開発を進める上でとても重要だと考えているので、ご興味のある方は少しお付き合いください。 to Bスタートアップは仮説検証をやめようという話 「仮説検証って言葉が嫌いなんすよねー」と、確か弊社の事業責任者の齋藤だったか代表の平井だったかが以前社内で言ってました。 1年前くらいまで私は、その発言

3 users
www.estie.jp
EMをしている松本(@matsu7874)です。estieでスタッフエンジニアという職位を導入した際に書籍『スタッフエンジニア』を使って社内勉強会を開催していました。書籍では5章に様々な会社のスタッフエンジニアのインタビューが掲載されているのですが、estieにも前職でスタッフエンジニアを努めていた Ryosuke Lin Yamamoto がいらっしゃるので、より深く理解を深めるためインタビューをさせてもらいました。 前職の職位の構造 Q. 前職でエンジニアの職位はどう設計されていた？ 前職のジョブタイトルはこのような形でした。 ソフトウェアエンジニア ソフトウェアエンジニアII シニアエンジニア スタッフエンジニア プリンシパルエンジニア 全社で100人~200人のエンジニアがいて、プリンシパルが3人、スタッフが10人くらいでした。 スタッフエンジニアの実務 Q. スタッフエンジニアと

5 users
www.estie.jp
こんにちは！スタッフエンジニアの @kenkoooo です！僕が estie でやっているスタッフエンジニアというのがかなり面白いので、紹介させていただきます！ ミッション estie のスタッフエンジニアは、全社横断の技術課題の解決をミッションとして負っています。 estie は、複数のプロダクトを同時並行で開発・提供し、顧客の複雑な課題を総合的に解決するコンパウンドスタートアップです。小さなチームが自律的に動くことで高速なリリースを可能にしています。 一方で、チーム間にまたがるような大きな課題や、まだ顕在化していない課題、1チームで解決しても小さなインパクトだが全チームで解決すると大きなインパクトになる課題は、各チームで取り組むよりも全社横断で取り組むのが良いでしょう。こうした課題にスタッフエンジニアが取り組みます。 初期には CTO が担っていた役割の一部を引き受けるというのが僕の理

8 users
www.estie.jp
はじめまして、mayocornです。 12月からestieでソフトウェアエンジニアとして働くことになりました。 自己紹介 20代後半 （元）主婦 プログラミング歴 SES企業でJavaを少し（業務はExcelでテスト結果をまとめたりスクショ貼り付けたりがほとんど） 42TokyoでC言語やUNIXについて学ぶ AtCoder 青（mayocorn - AtCoder） WEB開発は未経験 経歴 高校中退 → バイト生活（一人暮らし） → 主婦 アルバイター時代 学歴なし、技術力なし、コミュ力・リーダーシップなしの自分にもできる仕事を見つけるのは大変だったので、マイペースに働いていました。 貧乏性が板についていて、都内に住んでも月10万（家賃込み）で収まるくらい省エネ人間だったので、このスタイルでなるべく周囲に迷惑をかけずに生きていけたらいいなと思っていました。 過去の仕事について振り返ると

5 users
www.estie.jp
お久しぶりです。riano_ です。estieに入社して 1 年と少し経ちました。 入社時にこのような記事を書かせていただきましたが、Web 開発をしたことのなかった競技プログラマーが、実際この 1 年でどのようなことを経験し、何を感じたのかを書いてみようと思います。 さて、あらためて簡単に自己紹介させていただきます。僕は大学院で修士まで理論物理の研究をした後、新卒でハウスメーカーの営業職に就き、2年ほど勤務しました。その最後の 4 ヶ月くらいで競技プログラミングを始め、それをきっかけに機械学習系のスタートアップへ、そして現職へと至りました。この時点で「なぜ？」という点がいろいろありそうですが、一旦置いておいて、要するにプログラミングについていえば 26歳で始めた 競技プログラミングと、多少の機械学習しか経験がない という状態でのスタートでした。 結論から言いましょう。estie での仕事

10 users
www.estie.jp
estie データマネジメントグループのソフトウェアエンジニアの和田です。私については → 入社エントリ この記事の内容 さーて、今回の estie inside blog は estie、データドリブンになりたいってよ データの活用先を考えるブレスト会をやったらアイデアが沢山出たよ データ活用を実現していく仲間を募集中だよ という内容になっております！それでは本編どうぞ！ estie、Snowflake を導入しましたよ（再） 少し前にこのブログでも紹介したのですが、estie の新しいデータ基盤として Snowflake を導入しました。 estie、Snowflake を導入しましたよ - estie inside blog 上記の記事では、データマネジメントグループが管理しているデータパイプラインの課題をメインに紹介したのですが、Snowflake に対しては分析利用への期待も高ま

12 users
www.estie.jp
CTO辞めてきた こんにちは、8カ月間、とあるスタートアップでCTOをしていましたが、この度estieに入社しました田村です。えっ、8か月でCTOを辞めてしまうなんてとんでもない奴だなとお思いかもしれませんが、大義を為すには時に思い切った決断も必要と感じての入社です。 【プロフィール】田村 祐樹（たむら ゆうき） 1979年生まれ。ネバーランドカンパニーにてゲーム開発に従事。gumiにて技術担当執行役員CTOに就任し、ソーシャルゲーム開発を牽引する。 その後、ディライトワークスにてFGOをはじめとしたスマートフォンゲーム開発を担当。直近ではSmartNewsにてEMを務め、その後、不動産テックのCTOに着任。 2023年9月よりestieに参画。 CTOになるまで 20代はゲーム開発にあけくれ、NintendoDSやWiiなどで動くゲームをテックリードとして開発しながら机の下に寝袋を引いて

59 users
www.estie.jp
こんにちは！estieでQAエンジニアをしているかすや（https://twitter.com/ma_cho29）です。 今回ブログを書くにあたり、前回書いたのはいつだったかなー？と見返すと1年が経過していたことに気がつきました。 歳を重ねると体感時間が短くなると聞いたことがありますがそれでしょうか・・・ 入社3年目になる今年もやり残しがないように過ごしたいところです。 さて、今回はQA未経験だった私が1人目のQAエンジニアとしてestieに入社し現在までおこなってきたE2Eテスト自動化の変遷について語っていきたいと思います。 私がメインで関わっているプロダクト「estie マーケット調査」は約2年間でテストフレームワーク移行を2度おこないました。 当時の意思決定やその際に個人的に感じたフレームワークごとのメリット・デメリットなど含めて話したいと思います。 （あくまで僕の所属する開発チーム

3 users
www.estie.jp
こんにちは、estie でソフトウェアエンジニアをしている riano_ です。 この記事は estie 真夏のアドベントカレンダー 7日目の記事です。 estie に入社して、ちょうど 1 年が経ちました。という趣旨のちゃんとしたブログは、もう少ししたら公開したいと思って書き始めているのですが、今日は普段の仕事の中で漠然と考えていることを書き連ねてみます。軽い読み物のつもりでぜひお楽しみください。 「あなたが落としたのは、金の斧ですか？それとも銀の斧ですか？」 この質問に対する正解が、金の斧でも銀の斧でもないことは、多くの方がご存知であることと思います。しかし、仕事の中で、あるいは日常生活の中で、「A を取るか、B を取るか」という質問が与えられたとき、それ以外の選択肢を自然に考えることが出来る人は多くはないでしょう（僕も意識しないと出来ません）。 世の中には、二者択一に見える選択が溢れ

15 users
www.estie.jp
こんにちは。ひらやまです。 今回は、これまでフロントエンド環境を作ったり、運用したり、設計のアドバイスをしたりしてきた私がひとまずたどり着いた、このくらいの塩梅の設計が良いのではないかと考えている一つの案をみなさんに共有しようと思います。 フロントエンド設計の必要性 フロントエンドは JSON 色づけ係と言われることもありますが、ただ JSON をきれいにしてユーザに見せる以上の難しさを感じることもあるのではないでしょうか。 実装を完遂するために必要となるスキルが広いため、様々なバックグラウンドを持つ人がコードを書くことになりやすいです。フロントエンドエンジニアと呼ばれる人も、私みたいにマークアップエンジニアからフロントエンド領域に手を伸ばした人もいれば、デザイナーやバックエンドエンジニアなどの領域からこの環境に挑戦される方もいらっしゃいます。 このような様々な背景を持つ人たちが一つのコー

6 users
www.estie.jp
こんにちは、デザインエンジニアのomoteです！ estieでは、一人目のデザインエンジニアのhikaruに加え、先日、きょんしー が入社しました！私、omoteを含め、総勢3人になりました。 Reactとかコンポーネント設計についてデザインエンジニアsに100個質問してみた HTML, CSS, TypeScript, React で良く指摘するところ・気にしているところをベースにしながら幅広く話すことをテーマに勉強会を開催しました。その名も… 「デザインエンジニアしか知らない世界」 （勉強会のタイトルと討論のテーマはパロディです。） 本記事では前後編に分けて、最近のCSS事情や、Reactコンポーネントの設計の気になることについて話していきたいと思います。 若者のmargin離れが進んでいる件 皆さんは、ul内のli間のスペースをどうしてますか？ CSSは、様々な解法があるから、どれが

4 users
www.estie.jp
VP of Designの荒井（@rakenarai）です。 本日、estieは新たなブランドに生まれ変わりました。これに伴い、会社のロゴも以下のように一新しました。 新たなロゴは「estieが真価を拓いていく、“場”の象徴」です。 3つの青いオブジェクトは、「フロア」と「データ」の重なりを意味します。 唯一無二の土地にフロアを重ね、その真価が最大限発揮される「場」が創られていく様を表現しています。また、その原動力となるデータの層も表しています。 estieがあらゆる産業の根幹である商業用不動産の真価をテクノロジーの力で拓き、産業全体の真価をも拓いていく。そんな願いが込められています。 振り返ってみると、このリブランディングには1年を要しました。今は長きにわたって検討したものをリリースできてホッとする気持ちと、新たなブランドに込めた壮大な思いを絵空事では終えられない使命感を抱いております。

4 users
www.estie.jp
こんにちは。kenkoooo です。estie で余生を開始してから1年経ちました。かなり楽しめているので、その様子を共有します。 入社目的と進捗 estie をメチャクチャ給料を出す会社にしたいと思って入社しました。何か崇高な目的があるわけではなく、単にそういった会社が作れるのかどうか試してみたいためです。これが思ったより面白く、開始から1年ほど経ちましたが、未だに熱中してます。いったん5年くらいは集中してやり込みたいと思っているので、もうしばらくは続けていくつもりです。 クリア条件を達成するためには、少ない人数でメチャクチャ売上を上げていくことが必要になりますが、自分には営業などの才能はなく、売上を直接作っていくことはできません。一方で、ソフトウェア開発は他人より少し経験があるので、これを活かして次の方針でプレイしています。 自分ができることとしては4点、「メチャクチャ開発」「メチャク

32 users
www.estie.jp
こんにちは。ひらやま（@rhirayamaaan）です。 先日とあるツイートを見かけ、つい反応してしまいました。 これはReactコンポーネントを作る時に最低限必要なTypeScriptの知識をまとめた記事を書く気運高まってますか…！！？ https://t.co/rb9iwfNqDG— ひらやま (@rhirayamaaan) 2023年3月1日 3, 4年くらい前（2023年4月現在）は、フロントエンドを好むエンジニアやプログラムを書くマークアップエンジニアが目を輝かせながら React に飛びついていたように私は感じていました。しかし最近では React を使ったサービスが運用される機会も増え、デザイン修正を行うためにデザイナーが React のコードを触るケースも徐々に増えてきている印象があります。 ここ最近ではデザインエンジニアや UX エンジニアという形で表記ゆれを許しながら新

7 users
www.estie.jp
こんにちは、 @kenkoooo です。2月に開催されたDevelopers Summit (デベロッパーズサミット, デブサミ) のセッション「満を持して始める Rust」で発表した内容をブログでお届けします。セッションの内容を再現しているので、色んな話題を詰め込んだ忙しい内容になってしまいましたがご容赦ください。 Rust とは Rust とは、Mozilla が初期から公式プロジェクトとして開発を進めてきたプログラミング言語で、コンパイラがメモリ安全性を保証するという特徴があります。バージョン 1.0 のリリースから8年ほど経ち、広く使われるようになってきました。 Shipping Rust in Firefox - Mozilla Hacks - the Web developer blog Rewriting the heart of our sync engine - Drop

3 users
www.estie.jp
keigo（左）shin（右） こんにちは、年末年始は子供とずっと一緒に過ごし、子供の語彙力が爆発的に伸びていくことに驚きつつ、負けてられないなと思っているCTOの岩成（tiwanari）です。 今回は、タイトルの通り、新しく青木啓剛さんにVP of Engineering（VPoE）に就任していただき、今まで一人でVPoEを務めていた青木信さん（kirin_shi）と共に、二人の青木さんによるVPoE二人体制（おそらくVPoEの二人が同じ姓なのは日本初 [当社調べ]）へ移行したので、その思いについてお伝えできればと思っています。 体制変更に至った背景 Whole Product構想へ取り組む開発部門 estieの開発部門は3つのセクションで構成されています。 セクション メンバー Engineering Software Engineer/Data Scientist/QA Engine

270 users
www.estie.jp
みなさん、監視作ってますか？ システムを作ったら、そのシステムを監視していく必要がありますよね。どうやったら「いい監視」が作れるのでしょうか。「いい監視」とそうでない監視との違いとは、いったいなんでしょうか。 今の時代、「監視」ではなくて「可観測性」、 Observability (o11y) の時代になっていて、良いプラクティスや考え方が色々とあります。 この記事は、監視や o11y についての考え方を社内に共有するため書いたものを、社外共有用に調整し直したものです。新しい Observability の時代を、一緒に生きていきましょう。 監視を作ろう あなたはシステムを作りました。そのシステムに「監視」をつけようと思ったとき、最初にすることはなんでしょうか？ まずは、システムを何らかのツールで監視するところから始めましょう。やらなきゃはじまらない。 Nagios, Cacti, Mun

18 users
www.estie.jp
エンジニアの松本です。Rust、何もわからない... #5 - connpassを開催いたしました。 今回はUNICORN株式会社のctlyさん、フェアリーデバイセズ株式会社の加藤学さんにご登壇いただき、estieからはSWEのriano_17が登壇しました。 それぞれのスライドが公開されていますので、紹介いたします。 Rustプロダクトのキャッチアップ speakerdeck.com 加藤さんから既にRustをプロダクションで使っているフェアリーデバイセズに転職してからのキャッチアップについてお話しいただきました。 「GitHubで読もうとして、頭がパンクする」「ハイスペックPCが必要になる」という困ったポイントもあれば、「光速で開発環境が整った」「（Clippyが教えてくれるので）天才じゃなくても使えた」など良かったポイントをあげられていて、ものすごく自分の感覚と近いなと感じます。他に

10 users
www.estie.jp
皆さんこんにちは。 estieでプロダクトマネージャーをしております中村と申します。 今回は私が考えた”さいきょうのロードマップかんりツール”をfigmaのコンポーネントを駆使して作ってみました。 早速ですがこちらです。 さいきょうのロードマップかんりツール ▼こちらからコピーしてお使い下さい さいきょうのロードマップ_master 上記見て「お！！」と思った方はぜひこのまま読み続けていただければと思います。 ロードマップに入れ込むべき要素に関する記事については、先輩プロダクトマネージャーの方のブログや記事等で知見の共有がされており、土壌が整いつつあると感じております。 しかしながら、実際のロードマップ自体の作成ノウハウやメンテナンスノウハウ、またロードマップ作成ツールの知見はなかなか見つからずに苦労しておりました。 そこで、私がいろいろなツールで試行錯誤した結果のベストプラクティスを作成

3 users
www.estie.jp
estieでソフトウェアエンジニアをしている安東です。普段の業務で関わっているのはPython製のシステムが中心ですが、過去データを分析するのにちょっとRustを使ってみたりもしています。 こうやって普段からお世話になっているPythonですが、中身がわからないまま使い続けることに対してやや不安を感じることがあります。たしかに書き方だけ知っていれば大抵の場面でなんとかなってしまうのでしょうが、それだけではカバーしきれないところがどんなプロジェクトでも突然やってきます。カバーできる範囲を増やすためにも、突然の出来事の予兆を事前に嗅ぎつけるためにも、プログラムが動いている感覚が地に足ついた形でほしいのです。 ということで、今回はPythonの処理系でおそらく一番メジャーなCPythonのソースコードを読んでみようと思います。ただ、ソースコード全体を読むには時間も記事のスペースも足りないので、今

49 users
www.estie.jp
自己紹介 業務委託でestieに参画している@HirokiOmoteです。 estieでは主にデザインとFrontendを担当しています。 過去には、スタートアップの創業フェーズでプロダクトの立ち上げなども行なっていました。 そこでは、Nuxt + Firebaseを採用し、Webアプリの制作に着手。 しかし、プロダクトが成長するにつれ、コードの安全性や可読性の観点からJavaScript…動的型付け言語の限界を感じていました。 そして、静的型付け言語であるTypeScriptを採用することに。 また、Firebase Cloud Functionsを使った機能開発も行うようになり、次第にBackendもTypeScriptを使って書くようになりました。 それが、TypeScriptとの出会いです。 気づけば、すっかりその魅力に取りつかれていました。TypeScriptは楽しい。 そもそも

155 users
www.estie.jp
estie でソフトウェアエンジニアをしている徳永(@yTo_9)です。 estie では Ruby を書いたりTypeScriptを書いたりしています！ estie 夏のブログ祭りにかこつけて、せっかくなら普段は追わない部分だけど、気になっていたYJITなるものを深掘りしてみようと思い、「YJITがなぜRailsアプリケーションの高速化を実現できたのか」を調べてみたので紹介したいと思います。 「どうせ難しいんでしょ？」と思いながら調べてみたのですが、講演や論文の説明がわかりやすく、意外に概要を把握することは難しくありませんでした。 YJIT の核となっているのは Lazy Basic Block Versioning (LBBV) という手法で、これはRubyだけに限らず動的言語全般に適用可能な強力なアプローチであることがわかりました。 「あるタイプの条件分岐は、ほとんどの場合で片側しか

次のページ