はてなブックマーク

新規プロダクトの立ち上げ期には、成果の裏で、「誰も見ていないが、誰かが必ずやらねばならない仕事」が数多くあります。 今回紹介する DevTool は、新規プロダクト立ち上げの裏で有志メンバーにより実装された、数値計算結果の可視化・検証を支える社内向けフロントエンドツールです。 当初は開発効率を上げるための副次的な取り組みでしたが、いまではQAチームやステークホルダーを含めた、“数値を扱うチーム全員の共通基盤” に成長しました。 このブログでは、その0→1の過程と、チームがどのようにそれを活かしたかを紹介します。 ※ツール開発が必要になった新プロダクト「eClear」についての詳細は、以下の記事をご覧ください。 techblog.enechain.com 背景：数値検証がボトルネックになっていた きっかけ：開発の合間に生まれた小さなツール 広がり：チームにとっての共通ツールになった 試行錯誤

この記事はenechain Advent Calendar 2025の19日目の記事です。 オフサイトの失敗あるある オフサイトは成功すれば事業の起爆剤になる そもそも「しらけのイメトレ」とは何か？ オフサイト版「しらけのイメトレ」とは 「だれに」「どんな気持ちになってほしいか」「それはなぜか」の事前準備が大事 企画が先行している場合は逆算して目的を出してみる 課題がふわっとしてしまう場合はN=1に立ち返る イメトレ開始！参加者の思考回路をなぞる 議論を盛り上げるバランス調整 企画チームでロールプレイング 一人企画なら、AIも使える 良き組織の追求は終わらない enechainPdMの加藤(@mk_mitarashi)です。 サイバーエージェントでマッチングアプリ開発に5年ほど関わり、HRSaaSのシードスタートアップを経て、enechainでPdMをしています。 振り返ると事業と組織にず

この記事はenechain Advent Calendar 2025の18日目の記事です。 はじめに 計測 もっさり感の正体を特定する もっさり感を示す指標 INPの計測 Datadog Real User Monitoring (RUM) Chrome DevToolsのパフォーマンスパネル 改善 原因の仮説 修正 表示するDOMの数を減らす 不要な再レンダリングを減らす 改善結果 モニタリング 操作ごとのINPの計測 ダッシュボードの作成 ダッシュボードの運用 まとめ はじめに enechainでソフトウェアエンジニアをしている @nakker1218 です。 私たちのチームでは、電力取引仲介を行う同僚（ブローカー）たちが使う、注文管理システム「eNgine」を開発しています。 ブローカーは、顧客から注文を預かり、eNgineに入力してチームで共有し、画面を見ながら顧客と交渉して成約を

はじめに Process Managerパターン導入以前のアーキテクチャ CQRS+Event Sourcing の採用 イベントをトリガーとした業務プロセスの自動化 直面した課題: 単純なイベントハンドラの限界 Process Managerパターンによる解決 Process Managerパターンとは 実装例: 複数市場への注文掲載 要件 ProcessManagerインターフェース 状態遷移の設計 Executeメソッドの実装 イベントハンドラの実装 まとめ はじめに こんにちは、enechainでエンジニアをしている青戸です。 イベント駆動のシステムで、処理の流れが複雑化して「ピタゴラスイッチ」状態になってしまったことはありませんか？ あるイベントが発生して、それをトリガーに別の処理が動いて、さらにその結果を受けて次の処理が......と連鎖していくうちに、全体のフローを把握するの

この記事はenechain Advent Calendar 2025の16日目の記事です。 はじめに 序：UIは“気分”に寄り添う時代へ ダークモード：色反転から“情緒デザイン”へ 最新のダークモードは“情景”を作っている UIに宿る“空気感”：Expressive Design と Liquid Glass の登場 Material You：ユーザーの気分を UI に取り込む Material 3 Expressive：ムードを持つ UI Liquid Glass：空気感が“静”から“動”へ Emotion Layer：UIは感情を扱えるのか？ UIが誘導できる“心理状態” Emotion Layer = 感情をつくるUIパラメータの組み合わせ 感情はユーザー自身が言語化できない 実例：感情を扱うUI 実装と運用のイメージ：感情は測れなくても、影響は測れる 測定可能な指標例 デザインシス

この記事はenechain Advent Calendar 2025の15日目の記事です。 データプラットフォームデスクの山田です。普段は分析目的のためのデータパイプラインの構築や運用をしています。 今年からデータパイプラインにDatastreamを導入し、半年ほど運用してきました。簡単に導入でき、今のところ障害といった障害もなく安定して運用できており、とても助かっています。とはいえ、考慮しなければならないことや、困っていることもいくつかでてきました。 本記事では、Datastreamを導入した経緯と、半年運用してみて遭遇した困っている点を紹介します。 現在のDBのデータを取り込む仕組みとその課題 Datastreamの採用 Datastreamを含めたデータパイプライン構成 データパイプラインのアーキテクチャ テーブル構成 Datastream導入時の注意点と運用を開始して困っていること

はじめに 全体像：どんなレイヤーに分けているか Baggageとコンテキストで「グローバルな値」を伝播する なぜ Baggage を使うのか Baggage に値を積む：WithTraceInfo Baggage から値を取り出す：SharedLogHandler slogctx.Handler：コンテキスト上の「ロガーバケット」から値を取り出す コンテキストに値を積む：WithLoggerValues slog Handler 側でバケットから値を取り出す logjson と json-iterator/go によるマスキングとバイナリハッシュ WrapMutable：遅延エンコード + キャッシュ jsonExtension：構造体フィールド単位の制御 1. バイナリハッシュ化（DecorateEncoder） 2. Drop / Secret / Masking（UpdateStru

この記事はenechain Advent Calendar 2025の14日目の記事です。 こんにちは！ET(@et_universe)です。普段は電力取引プロダクトのデザインをしています。 弊社では、お客様はもちろん、社内の仲間も国際化が進んでおり、過去のTech Blog記事にもあった通り英語の活用を推進しています。今回はそのような環境で、「英語のUIテキスト」について改めて考え、気づいた大切なことをまとめます。 まずはじめに伝えたいです。私は英語が得意ではありません！ しかし、デザイナーとして、英語利用者のお客様にも、私たちのプロダクトの体験が快適であってほしいという思いが強くあります。 そんな英語が苦手の私が英語UIに向き合った結果、強く実感したのは、 英語UIテキストは直訳ではなく、設計である というシンプルだけれど根源的な視点です。 この記事では、UIテキストライティングの実践

こんにちは！enechainのシニアデザイナーのみそん(@misunkang5)です！ この記事はenechain Advent Calendar 2025の22日目の記事です。 いい年して、まだ伸びたい。プロダクトデザイナー13年目、"経験ゼロ"の電力の世界へ。 いい年してまだ伸びたい。 気づけばプロダクトデザイナーとして13年目。 安心できる領域を抜け出し、私は電力という未知の世界に飛び込みました。 そこで感じた「通じるもの」と「通じないもの」。 私の挑戦の記録を残します。 プロダクトUIUXデザイナーとして12年間、私はずっと日本大手のBtoB SaaSの世界にいました。 ユーザーの状況と課題を理解し、ソリューションを考え、UIUXとして落とし込んだものを提案する。そんな仕事が「呼吸するように」できるようになっていました。 それがある日、私は”経験もナレッジも０”のエネルギー業界に転

この記事はenechain Advent Calendar 2025の11日目の記事です。 はじめに 背景 1. 他チーム管理ロジックへの依存 2. 開発サイクルの相違 アーキテクチャパターンの検討 1. ライブラリ共有パターン (Shared Library) 2. テンプレート参照パターン (WorkflowTemplate Reference) 3. コンテナインターフェースパターン (Container Interface) 4. イベント駆動パターン (Event-Driven) 実装 ワークフロー実装 1. データサイエンスチームのimageを参照するWorkflow Template 2. DAGでの依存関係定義 3. Kustomizationリソースでのイメージバージョン管理 権限設定 KSAの作成 Terraformによる権限管理 運用 デプロイ運用 アラート運用 今後

この記事はenechain Advent Calendar 2025の10日目の記事です。 本日はenechainのGXデスク バックエンドエンジニアの @eji が担当します。 1. はじめに GXデスクで開発している環境価値取引所JCEXのバックエンドサーバーはGoで書いており、DBと結合させた状態でAPIテストを書いています。 テストのフィクスチャはBunのFixtureを利用しており、APIテストのテストケースごとにフィクスチャをDBにロードしてテストしています。 今回はフィクスチャ管理で私たちが感じた課題と、その課題に対してどのようなアプローチで解決に取り組んだか、そしてその結果どうなったかについて紹介したいと思います。 2. 対象読者 GoでDBを使ったテストを書いている方 テストフィクスチャのメンテナンスを改善したいと考えている方 YAMLでのフィクスチャ管理に限界を感じてい

eClear Deskの@hase1031です。 enechainの子会社である株式会社eClearは2025年5月に現物・先物市場を効率的につなぐソリューションを提供することを目的に株式会社三菱UFJ銀行と資本提携を発表しました。 eClearは2022年9月から提供しているサービスですが、今回新たに提供するソリューションは、既存のものとは設計思想から求められる機能まで大きく異なり、コードベースの大部分を再構築する必要がありました。 本記事では、eClearが果たす役割と、先物取引への対応に向けたシステム開発の裏側、そしてそこから得た学びを紹介します。 今後はeClearに関する技術記事をさらに公開していく予定のため、本稿では詳細な技術仕様には踏み込みすぎず、全体像にフォーカスしています。 これから公開される記事をぜひ楽しみにしていてください。 eClearの存在意義 eClearによる

この記事はenechain Advent Calendar 2025の8日目の記事です。 言語の壁が組織の摩擦を生んでる？ CTOから届いたメッセージ 第一歩：漫画制作開始 人の話をよく聞くようになった、見るようになった 隙間を埋める役割へ 言語の壁が組織の摩擦を生んでる？ こんにちは、enechainのPdMのokpです。アドベントカレンダーの時期が来ると1年が終わるなとウルウルし、今年はどんなことしたっけ？と振り返るのも、3回目です。3年目に入った今年は、自分の趣味と仕事を掛け合わせてvalueが発揮できたし、楽しかった年でした。TechとBizの言語ギャップを埋めるために、漫画を描いてみた話を紹介します。 enechainは、日本の電力に特化したプロダクトを作る会社です。日本の電力業界の知識は専門的で、日常では触れない領域ばかり。私も入社直後の頃は、Bizの会話が日本語として理解でき

はじめに 本記事の要点 背景と課題 デザインシステムの現状 デザインシステム利用者の多様化 アップデートにおける具体的な課題 解決アプローチ eclair-analyzerとは 主な機能 1. Usage Analysis：プロジェクトでのコンポーネント利用状況分析 2. History Analysis：バージョン間の変更分析 提供しているTools プロジェクト分析（Usage Analysis） マイグレーション分析（History Analysis） 活用例と効果 実施概要 アップデート実施の流れ 効果と改善点 技術実装 技術スタック 実装のポイント まとめ この記事は enechain Advent Calendar 2025 の7日目の記事です。 はじめに enechainに業務委託として参画しているエンジニアの@konatsu_pです。主にデザインシステムの開発・運用を担当し

はじめに 対象読者 課題 解決案 実践：コンテキスト作成のフロー Step 1: Notion AIによる「叩き台」作成 Step 2: チームディスカッションと録画、Gemini処理 Step 3: GitHubでのチームレビューと品質担保 Step 4: AIエージェントでの活用 Geminiでの動画処理の工夫 Geminiプロンプトの設計 メイン処理定義 出力フォーマット定義 実行方法 コストと効率性 今後の展望：ドキュメントの自動更新 まとめ はじめに この記事はenechain Advent Calendar 2025の4日目の記事です。 こんにちは、enechainで統計・機械学習モデルの構築やLLM（大規模言語モデル）の活用推進を担当している@udon_tempuraです。 昨今、Claude Sonnet 4.5やGPT-5.1、Gemini 3.0 Proなど強力なAIモ

この記事はenechain Advent Calendar 2025の3日目の記事です。 はじめに 【変えたこと①】「自分が決める」から「決めるための『道』を整える」へ 現場の解像度と経営のアテンションの非対称性 「コストの高そうなコミュニケーション」を先払いする 【変えたこと②】「個人の出力」から「チームの出力」へのコミット 「任せる」を公言し、退路を断つ 「答えを持っている」という過信を捨てる 【変えなかったこと①】最後の砦としての「意思決定スタンス」 【変えなかったこと②】現場への解像度と、非連続な未来への仕込み 「Fly High」な施策を温め、実現する おわりに はじめに enechain Advent Calendar 2025の3日目を担当します、執行役員 eSquare事業本部長 兼 Technology本部 プロダクト企画部長の大橋（社内では「はっしー」と呼ばれています）

この記事はenechain Advent Calendar 2025の2日目の記事です。 はじめに dbt Fusionとは dbt PlatformでのFusion対応状況 Local環境でFusionを試す 良かった点 気になった点 Fusionへの移行準備 やるべきこと 互換性についての注意点 まとめ はじめに enechainのデータプラットフォームデスクでエンジニアをしているakizhouです。 弊社では今年からdbt Platform（旧dbt Cloud）を導入しました。今回は、dbt Labsから今年リリースされた次世代エンジン「dbt Fusion」について、実際に触ってみた所感を共有します。dbt Platform導入の経緯や実運用についてはまた別の機会に書ければと思います。 dbt Fusionとは dbt Fusionは、より快適な開発体験とコスト効率を実現する次世

この記事はenechain Advent Calendar 2025の1日目の記事です。 はじめに プロジェクト管理の型を使い分けよう 失敗談 学びと実践 分類軸: 期間 ~ 短期(数週間) vs 中長期(数ヶ月~半年) 分類軸: 依存関係 ~ 自チーム完結 vs 複数チーム依存 分類軸: 要件の確実性 ~ 未確定要素が少ない vs 未確定要素が多い 分類軸: 期限 ~ 期限無し vs 期限有り 徹底的に違和感を拾おう 失敗談 学びと実践 チームが直面している違和感を検知する仕組みを作る 違和感の根本原因を探る 失敗を恐れずに改善を続ける 本は課題ベースで読もう 失敗談 学びと実践 目の前の課題をリストアップする ただの知識ではなく実践に落とし込もう おわりに はじめに こんにちは！enechainでエンジニアリングマネージャー(以下、EM)をしているtaniyarnです。 今年もこの季節

はじめに 開催までの準備 お題の選定 AIツールの選定 参加者募集と反応 ハッカソンの形式 評価方法 開催！ お題発表 デザイン制作プロセス 各チームの発表 AIデザイン王の決定 人間AIデザイン王 AIAIデザイン王 AIによる評価の精度 まとめ ネクストステップ はじめに enechainプロダクトデザインデスクのマネージャーの近藤（@add_kk）です。 enechainのテクノロジー本部では、今年8月に、AIを使ったデザインハッカソンを企画・実施しました。テーマはずばり「プロンプトのみでどこまでデザインやプロトタイプが作れるかみんなで試してみる」。 AIでのUIデザインやプロトタイピングの領域は今年に入り一気に進化。新しいツールも次々に登場しています。enechainでは日頃からAI活用を積極的に進めていますが、その一環として、デザイン領域での現在地を確認するための企画です。デザイ

こんにちは。Platform Engineering Deskの吉田（@ryysud）です。enechainはこの度、9/18に開催されたPlatform Engineering Kaigi 2025にシルバースポンサーとして協賛しました。こちらの記事では、当日のスポンサーブースでの展示物とブースへお越し頂いた方に実施したアンケート結果を共有します。 Platform Engineering Kaigi 2025 について www.cnia.io Platform Engineering Kaigi 2025は、プラットフォームエンジニアリングに関する知識と経験を共有するための専門カンファレンスです。各社でプラットフォームエンジニアリングを実践しているエンジニアが一堂に会して、最新の知見や事例を共有する貴重な機会となっています。 弊社のPlatform Engineering Deskも、

こんにちは。Platform Engineering Deskの大隈（@kumashun88）です。7/12、13に開催されたSRE NEXT 2025で、enechainはシルバースポンサーとしてブース出展させていただきました。スポンサーブースでの展示内容と、ブースで実施したアンケート結果を共有します。 SRE NEXT 2025について SRE NEXTは、SREのコミュニティ「SRE Lounge」のメンバーを中心に開催される、信頼性に関心の高いエンジニアのためのカンファレンスです。今年のSRE NEXT 2025で、5回目の開催となっています。https://sre-next.dev/2025/ 弊社のSRE Deskも、社会インフラを目指すエネルギーマーケットプレイスの信頼性向上をミッションとしているため、スポンサー募集にエントリーしました。 スポンサーブースについて ブースのテ

はじめに 背景 エラー情報の管理方法 案1: gRPCメソッドのresponseにエラー用のフィールドを追加する Pros Cons 案2: metadataにエラーを追加する Pros Cons 案3: protoにコメント形式でエラー情報を追加 Pros Cons 選定された方法 チェックツールについて まとめ はじめに こんにちは、ソフトウェアエンジニアの大山です。 enechainでは、複数プロダクトから共通で利用される機能はマイクロサービスとして独立させており、それぞれがgRPC APIを提供しています。 Protocol Buffersの一元管理 ではそれらAPIの定義を一元管理する仕組みについて紹介しました。 共通系のサービスが自由なフォーマットで実装されていくとクライアント側の認知負荷が高まるため、正常系の処理だけでなく異常系の処理に関しても詳細なフォーマットが定められてい

はじめに Cursor導入の検証と評価 検証と評価方法 新規機能開発を用いた検証 技術検証フェーズ 実装フェーズ ルールファイルの導入 Cursor導入前後の比較 Four Keysの比較分析 チームの変化 さいごに はじめに こんにちは、enechainでソフトウェアエンジニアをしている小沢です。 enechainでは、昨今トレンドとなっているAIエージェントの活用に積極的に取り組んでおり、CursorやCopilot Agentの導入、Devinの検証などを行っています。私たちが所属するeScanチームでも、2025年1月から「Cursor」を活用して開発をしています。 本記事では、Cursor導入の効果と、チームに起こった変化についてご紹介します。 Cursor導入の検証と評価 ここでは、我々が実施したCursorの検証と評価の方法についてご説明します。 検証と評価方法 検証では、新

はじめに enechainのデータプラットフォームデスクでエンジニアをしている菱沼です。 本記事では、Google Groupsを用いて、BigQueryの権限管理を設計した例をご紹介します。 事業の多角化に伴い様々なデータが新しく生まれてきた中で、BigQueryに集約されたデータを適切に権限管理しつつもよりスムーズに権限を付与できる仕組みが求められるようになってきました。 今回は、私たちが直面していたBigQueryの権限管理の課題と、その解決に向けた取り組みをご紹介します。ぜひ最後までご覧ください！ はじめに 背景 今までの権限付与運用の課題点 新運用の概要 変更点1: BigQueryリソースに紐づくGoogle Groupsの作成・Viewer権限の付与 変更点2: 手動でのRole Groupメンバー加入による権限付与 今後の展望 承認後の権限付与自動化 Role Groups

はじめに こんにちは。enechainのQAエンジニアのtaise- です。 enechainのQAチームでは、昨年より各プロダクトのE2Eリグレッションテストの自動化を進めており、ツールとしてMagicPodを活用しています。既に導入・運用を開始しているプロダクトがある一方で、現在導入準備中のプロダクトも存在します。 本稿では、以下の点について、enechain独自の経験を交えながらご紹介します。 自動化ツールの選定 ツール導入から運用開始までの流れ 自動化推進における課題と展望 本稿が、E2Eリグレッションテストの導入を検討されている方、または運用中の方にとって、少しでも参考となれば幸いです。 E2Eリグレッションテスト自動化のモチベーション E2E（End-to-End）リグレッションテストは、機能追加や修正によって既存機能が意図せず壊れていないかを確認するために行われます。 E2E

こんにちは。enechain CTOの須藤 (@sutochin26) です。 今更ながらグランメゾン東京にハマっています。キムタクも相変わらずカッコいいですが、丹後シェフが良いキャラしてますね！映画を観るのが楽しみです。 さて、グランメゾン東京も組織作りについて考えさせられる作品でしたが、本記事でも組織作り、特にサクセッションプランニングをテーマに書いていこうと思います。 我々のようなテックスタートアップの特徴の1つは、組織が急速に拡大することです。我々enechainも、私が入社してからの3年余りで、組織が30人規模から200人規模へと大きく拡大しました。 このような急成長の中では、計画的な後継者育成・採用が極めて重要になってきます。 うまく権限を委譲していかなければ、自身が意思決定のボトルネックになるだけでなく、SPOF(単一障害点)となり、事業上のリスクにもなってしまいます。 本記

1. はじめに 対象読者 前提条件 2. 課題 3. 取り組んだこと ① OpenAPIでAPI仕様書を作成する ② OpenAPI形式の仕様書を元にクライアントとサーバーのコードを自動生成 ③ フェイクサーバーを作成し、フロントエンドの開発を並行化 ④ モックサーバーを作成し、バックエンドの開発とテストを自動化 4. 成果 5. まとめ 1. はじめに enechain eClearデスク兼GXデスクのバックエンドエンジニア @eji です。 サービスを開発する上で、外部APIとの連携は避けて通れない課題です。 eClearデスクでも様々な外部APIと連携する機会がありました。 今回は、外部APIとの連携を効率化するために取り組んだ、コード生成とテスト方法を紹介します。 対象読者 外部APIを利用するWebアプリを開発しているエンジニア フロントエンドとバックエンドの担当が分かれている開