Posts

この記事は10X 創業 6 周年アドベントカレンダーの 14 日目の記事になります。 昨日は BizDev の寺崎さんが、「100 社以上の小売企業と面談して知った 5 つの発見」という記事を公開していますのでぜひ読んでみてくださいね。 はじめに 2023 年 2 月に 10X に入社した jojo です。 入社してエントリ書くぞと思っていたのですが時が経つのは早く、気づけば早 4 ヶ月が経ってしまいました（この企画がなければ、なかなか筆を取ることができなかったかもしれません笑）。 この記事は、かなり個人的な備忘録ですが興味を持ってくれた人に少しでもためになれば嬉しいです。今回は、私が 10X へ転職を決意した経緯と、この 4 ヶ月間で感じたことについて話していきます。 前職でやっていたことは？ 新卒で入社した前職では、メガベンチャーで BtoB マーケティング領域の新規事業部のエンジニアをしていました。 チームが小さく、一人ひとりが多くの役割を担う環境だったため、落ちているボールは全て拾うぞーという勢いで私は 4 年間でサーバーサイド（Golang）の開発に関わりつつ、フロントエンド（React・TypeScript）も触りながら iOS アプリのリニューアルなどを行ったり広くプロダクト開発に携わる機会がありました。（新卒 1 年目のぺーぺーにも機会を惜しみなくくれた環境に本当に感謝です。） また、PdM（プロダクトマネージャー）としての役割も任され、複数のステークホルダーと連携しながらプロダクトの仮説検証や施策推進を行いました。私が加入した当初は十数人規模だった事業部も、私が在籍している間に 50 人近くの組織に拡大して、事業は独立し、最終的には分社化するまで見届けました。 なぜ転職を？ 心理的安全が高く裁量もやりがいもある環境から移ることを考えたのは、結婚等を通して自分の人生を見つめ直して二十代最後の時間をどう使うかと考えたときにもう一段階ギアを上げることが求められるよりチャレンジングな環境に身を置くことが今の自分にとっては必要なんじゃないかと感じるようになっていったためです。 転職活動は初めてだったのでせっかくなら色んな人・業界の話を聞いてみたいと思い 30 社以上とカジュアル面談実施して広く話を聞きに行ってました。 各企業と話していて言語化された自分の価値観を Notion にまとめていきました。（一部抜粋） そんな中で固まった転職軸は以下の 3 つです。 世の中のシリアスでインパクトの大きな課題解決に取り組んでいること エンジニアが事業づくりにおける越境をすることが肯定される組織であること ユーザー志向で素早く開発プロセス・プロダクト改善のサイクルを回していること 新卒で勤めていた会社を選んだ最大の理由も、「テクノロジーで世の中のシリアスで大きな課題の解決に取り組んでいる」という観点でした。私はエンジニアとして技術そのものがもちろん好きですが、それ以上にその技術をどのように活用して課題解決に取り組むのか、どのような仮説を立てるのかに強い関心を持っています。 その上で、自分が作ったプロダクトがユーザーにとって真に価値あるものであると自信を持てるよう、絶えず改善を重ねられる組織に所属したいという思いが、多くの人々との対話を通じて明確になりました。（当時まとめていた Notion ページ抜粋） なぜ 10X に？ 10X への道のりは、たまたま遠方のサウナ（みんな大好き The Sauna）に行く道中で前職の先輩と「エンジニアもビズも関係なくイシューにこだわってプロダクト作ってる会社ありますかねー？」という何気ない会話をしたことがきっかけでした。 その先輩の紹介により 10X の suumin さんとのカジュアル面談の機会を得ることができ、「プロダクト開発への真摯な姿勢めっちゃいい！社会のインフラになり得るプロダクトにわくわくする！」と一瞬で 10X の魅力に強く引きつけられました。...

はじめに zenn の記事の転載です。 これはGo Advent Calendar 2021の 6 日目の記事です。 DDD についてはエリック・エヴァンス先生や先人の鬼ほどわかりやすい書籍があるので、 こちらを読むことをおすすめします。（笑） ドメイン駆動設計 モデリング/実装ガイド ドメイン駆動設計 サンプルコード&FAQ ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本 なのでここでは、DDD を詳しく解説などはせずに、 Golang を使ってモデルでドメイン知識をどのようにソフトウェアに落とし込むのか、 簡単な具体例をあげて説明していきます。 ドメイン駆動設計(DDD)とは？ とはいっても、ドメイン駆動設計とはなんぞやをカンタンに説明しておきますね。 DDD Referenceでの定義を以下に記します。 Domain-Driven Design is an approach to the development of complex software in which we: Focus on the core domain. Explore models in a creative collaboration of domain practitioners and software practitioners. Speak a ubiquitous language within an explicitly bounded context. This three-point summary of DDD depends on the definition of the terms, which are defined in this booklet....

まず結論から zenn の記事の転載です。 Redux を理解する上では、この図解(引用元：Redux Application Data Flow)を理解できれば 90%は OK。 ユーザーの入力から、(ActionCreator が)Action(アクション)を作成する Store(状態を管理するところ)へ Action を Dispatch（送信）する Dispatch された Action を Reducer（状態を変更するところ）へ渡す Reducer が作成した新しい State を Store が保存する Store からデータを参照して View（画面）に描画する 「ここが間違ってる！」や「もっとこんな仕組みが使われてるよ！」等のツッコミがあれば、どしどし貰えると助かります！(そのために書いてるみたいなところも多いので！) Redux とは Reduxは、React が扱う UI の state(状態)を管理をするためのフレームワークです。 React では state の管理するデータフローにFluxを提案していますが、Redux は Flux の概念を拡張してより扱いやすく設計されています。 React 以外にも AngularJS や jQuery などと併用して使用することもできますが、React と使用するのがベターです。 Redux - GitHub Redux の 3 原則（Three Principles） Redux の基本設計は以下の 3 つの原則に基づいて設計されています。 順を追って見ていきましょう。 Single source of truth(ソースは１つだけ) この原則は以下のような要約できます。...

現状と課題 ビカクシダがおうちに 6 つほどいるのですが、 彼らは比較的育てやすい子たちなんですが、 本来は冬の無いような暖かい場所に生息しているので、 できれば 15-20 度くらいをなんとかキープしたい。 最近は、比較的暖かくなってきたが、私は郊外に住んでいるので下手すると 10 度切るくらいに寒いときもぼちぼちあるので、 なんとか彼らが住みやすいような環境を作りたい。 作ったもの とりあえず、部屋の温度をスマートハブで監視して、 15 度を切ったら自動的に暖房が ON になるようにして、22 度以上で暖房を OFF になるようにした。 （ぶっちゃけこれ、既存アプリのシーン設定だけでできんじゃね？） データを残すこと大事なんで！とりあえず可視化したかったので、やってみた。 ざっくり、ビカクシダが育ちやすそうな温度になっていることがわかる。 よかった。よかった。

今回つくるもの 今回作るのは静的な Web サイトです。 まさにこのサイトのようなブログのような複数のユーザーから動的な更新を想定しないサイトの場合は、静的なページで実装することで高速に読み込むことができるサイトを開発することができます。 ここでは、Firebase と Hugo をつかってさくっと実装していきます。 Hugo とは？ HUGO とは、一体何でしょうか。 HUGO の公式によると、 Hugo is one of the most popular open-source static site generators. With its amazing speed and flexibility, Hugo makes building websites fun again. つまり、HUGO とは静的な html を生成する事ができる静的サイトを生成するフレームワークです。 HUGO のメリット 静的なページなので高速 セキュリティ面でのリスクを減らすことができる Markdown 形式で記事を書くことができる 既存のテーマを使えばサイトの実装がかんたん 静的なページにすることでサイトの表示速度は高速になり、サーバサイドの処理が無い分セキュリティ的にもリスクを減らすことができます。 なんといってもこのフレームワークの魅力は Markdown 形式で書いた記事がそのまま公開できるという点です。 これは全エンジニアにとってはとてもありがたい利点ではないでしょうか！？ 逆に Markdown 記法になれていない方にとっては WordPress のような GUI 的にマークダウンできるフレームワークのほうが便利かもしれませんね。 HUGO のデメリット 記述が独特で学習コストがかかるところがある 既存のテーマを使用するとカスタマイズが面倒 動的に title タグや description を組み立てるのが面倒 基本的には、標準機能が充実しているのでプラグインを追加してなにかするといったことはほとんどありません。...