はてなブックマーク

はじめに 対象読者 課題 解決案 実践：コンテキスト作成のフロー 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アプリを開発しているエンジニア フロントエンドとバックエンドの担当が分かれている開

はじめに enechain データプラットフォームデスク エンジニアの鳥山です。 enechainでは電力取引に必要な情報（例えば電力需給や燃料価格）を外部から収集し、社内外に公開しています。 このデータ収集はAPI経由で有償購入しているものもあれば、オープンデータとしてwebサイトに公開されているものもあります。電力自由化以降、電力需給に関する情報の公開が進んでおり色々なデータが参照可能となっていますが、それらは必ずしもマシンフレンドリーなデータばかりであるとは限りません。これは電力に限らず、特定の業界特化のドメインデータにおいてはよくある状態です。 本稿では、このような不確実性の高いデータを収集・活用するにあたってのノウハウの一部をご紹介させて頂きます。 はじめに データ取得における問題 基本的な考え方 問題 対処 リトライとタイムアウトを設定する データを検査する rawデータを永続

はじめに こんにちは、enechainでeScanという電力取引におけるリスク管理システム(ETRM)を開発しているYamatoです。 eScanは、小売電気事業者や発電事業者の電力ポートフォリオが抱えるリスクを診断し、定量的に評価するウェブアプリケーションです。プレスリリースにも出ているように、導入企業様が順調に増えています。 それに伴い、より良いユーザ体験を追求したり、使いやすい機能を追加・強化していくなど、プロダクトの価値を素早く高めていく活動が一層重要となってきました。 その上で、我々開発チームが今現在どの程度それらに応えられるのか、今後どこを目指してチームを成長させていくのか、定量的な指標を得るためFour Keysを計測指標として導入することにしました。 はじめに Four Keys 導入の背景 eScan の特性とチームの課題 Four Keysとは 1. デプロイの頻度（D

enechainでプロダクトデザイナーをしているET(@et_universe)です。 今回は、enechainのデザイナーが本当におすすめしたい、デザイナー向けの書籍をご紹介します。多様なバックグラウンドを持つenechainのデザイナーたちが、日々の仕事やキャリアの中でインスピレーションを受けた書籍の数々✨ デザインの視点を広げたい方、深めたい方にとって、必読のラインナップです。 デザインの世界は広大でありながら、細部に神が宿ると言われるように、常に新しい発見と学びがあります。各メンバーが推薦する本を通じて、デザインの本質や多様なアプローチに触れながら、ものづくりに携わるすべての方にとって刺激となる内容になれば嬉しいです。 それでは、奥深い本の世界へ出発しましょう！📚 デザインってなんだろう？デザインの世界をひろげる本たち デザインの輪郭 融けるデザイン ― ハード×ソフト×ネット時

はじめに enechain HRの酒井です。主にエンジニアやPdM、デザイナーといった、enechainのテクノロジーチームの採用を担当しています (以降、Tech採用と表記します)。 スタートアップでTech採用に携わる方には共感いただけると思いますが、エンジニアをはじめとしてTech人材の売り手市場トレンドが続いており、人材獲得競争はますます激化しています。また、転職意欲の有無にかかわらず候補者との接点を持つことが一般化し、採用プロセスが長期化する傾向にあり、選考以外でのコミュニケーションが以前にも増して重要になっています。 同時に、enechainの事業やプロダクトのフェーズ、組織規模も刻々と変化しています。創業期にはアトラクトの武器となっていた「アーリーステージ特有の面白さ」は、今では伝えづらくなりました。魅力の伝え方や採用の在り方自体が変わっています。 2023年を振り返ると、私

はじめに こんにちは、enechainのApplication Platform Deskでエンジニアをしているmaverickです。 我々のチームでは、バックエンドアプリケーションをGoで構築しています。 データベースアクセスが発生するテストはgo-sqlmockを使っていましたが、テスト用のDBを使って、実際のアプリケーションの動作環境に近いテスト環境へ切り替えました。 今回は、その際に行ったtestcontainersの導入とテストの並列実行へのアプローチについてご紹介します。 はじめに sqlmockの課題 testcontainersの導入 導入手順 testcontainersの起動 コンテナ起動のコスト テストデータのコンフリクト 並列化へのアプローチ 残課題 最後に sqlmockの課題 弊チームでは、可能な限りJOINは行わずにシンプルなクエリでデータベース処理を行うこと

はじめに GitHub Script概要 セットアップ context の中身 eSquare Liveでの活用事例 発生した問題 タグの打ち間違い releaseブランチが複数存在する場合のデプロイ先選択の複雑化 解決策としてのGitHub Scriptの活用 機能1 vX.Y.Zのタグがmainブランチのコミットハッシュと一致することを確認する 機能2 releaseブランチは最新バージョンのみ自動で検証環境にデプロイする 完成版スクリプト まとめ はじめに こんにちは、enechainでeSquare Liveを開発しているエンジニアの古瀬(@tsuperis3112)です！ 今回は、マニュアル依存になりがちなデプロイフローの問題を actions/github-script で解消した方法についてお話します。 eSquare Liveの開発では、効率的かつ信頼性の高い開発フローを維

仕事の納まった皆様も、これから納める皆様も、ひとまず一年間お疲れ様でした。 enechain CTOの須藤（@sutochin26）です。 年末と言えばラーメン二郎納めですね。 私も良い感じに納めてきたので、美しい写真をシェアさせてください。 さて、今年も本当に色々な出来事がありました。 去年のアドベントカレンダーではカルチャーに全振りの記事を書いていて、振り返ってみると組織づくりに投資していた1年でした。 techblog.enechain.com 転じて、今年はenechainの事業・プロダクトが大きな転換期を迎えた1年でした。私自身も、事業やサービスへの向き合いがかなり強まったように思います。 CTOとして、「こうしておけば良かった」という反省も山程ありますし、「これが出来て良かった」というポジティブな振り返りもあります。 この記事では、思いつくままにそんな振り返りを書いていこうと思

前置き バレルファイル自体の賛否については今回は触れないこととします。 はじめに こんにちは。enechainで働いている takurinton です。 enechainのデザインシステムではコンポーネントをindex.tsという名前のバレルファイルに集約し、それをエントリポイントとしてビルドして公開しています。つまり、新しくコンポーネントを追加しても、そのコンポーネントを公開するためにはindex.tsにexportを追加する必要があります。 // index.tsの中身 import Button from './Button'; import Input from './Input'; export { Button }; export { Input }; しかし、この運用では新しくコンポーネントを追加した際にそのコンポーネントをindex.tsに追加することを忘れたままリリースし

この記事はenechain Advent Calendar 2024の25日目の記事です。 はじめに eScanチームの課題 導入期 導入期から成長期にかけて 導入期に感じていた課題 取り組んだこと チーム目標の設定 ステップ1. チームの理想の状態を決める ステップ2. 現状と理想のギャップを見つけ出し、ギャップを生み出している課題を抽出し解決策を考える OKRの目標にチーム目標の内容を反映する チーム目標の振り返りの振り返り 1回目: 8月下旬 2回目: 9月下旬 3回目: 10月下旬 4回目: 12月中旬 変化 チームの変化 個人の変化 終わりに はじめに こんにちは、ソフトウェアエンジニアの小沢です。 私が所属しているチームではeScanというプロダクトを開発しております。プロダクトをリリースしてから様々な機能開発を行い、ご利用いただくユーザーも増えてきました。 そういった状況変化

はじめに eScanチームの平田です。 eScanは日本の電力事業に特化したリスク管理サービス(ETRMシステム)です。2022年から開発を始め、お陰様で今では徐々に導入いただける社数も増えてきています。まだまだ不足している機能はありますが、すべてのお客様が確実に必要とするであろうETRMの必須機能の実装は概ね終わっており、新規機能追加中心フェーズは終わりつつあります。これからは、よりお客様にとって価値のあるサービスになるような機能強化や改善を中心にする必要があると考えています。 今回は、eScanチームでの事業フェーズの変化に伴う開発プロセスの試行錯誤と、高速な仮説検証の補助として導入を進めているHasuraについてお話します。 フェーズの変化と仮説検証の必要性 「はじめに」に記載したとおり、徐々に新規機能追加中心のフェーズからより顧客への提供価値の最大化を目指すフェーズに差し掛かってい

こんにちは。enechainで働いている takurinton です。 enechainではプロダクト開発において多言語化を行っています。 今回は、enechainデザインシステムでのi18n対応と運用について紹介します。 i18n対応の前提 プロダクトでi18nをする際、一般的にはjsonで言語の定数を記述し、それにライブラリを使って型をつけてhooks経由で呼び出して使うことがほとんどかなと思います。 全てのテキストを抜け漏れなく定義し、それぞれの言語で表現するのであればそれは妥当な方法であると自分は考えています。 UIコンポーネントライブラリではそこが少し異なります。今回話す部分はReactで作られたUIコンポーネントライブラリなので、基本的にprops経由でテキストが差し込まれます。差し込む場合、そのテキストに関してはプロダクト側で管理・保持してほしいです。 ではどのようなときにデ

はじめに eSquare Live構想のはじまり eSquare Liveを実際に立ち上げ開始！次々出現する強敵 第一の敵！「いつまでもフワフワ」登場。 第二の敵！「覆りまくる意思決定」登場。 第三の敵！「知らず知らずに複雑化」登場。 さいごに はじめに こんにちは、enechainプロダクト企画部部長の大橋です。プロダクト企画部は、デザインやプロダクトマネジメント、PoCをツールで推進する部署といった、プロダクト開発における企画よりのチームで構成されており、私自身もProduct Managerとしてプロダクトを担当しています。 今回の記事では、2024年10月9日にリリースされた電力卸取引のオンラインマーケットプレイス「eSquare Live」プロジェクトについて、立ち上げ時からPdMとしてリードしてきて、学んだこと、他のプロダクトの立ち上げ時でも活かせるようなエッセンスを抽出すべく

この記事はenechain Advent Calendar 2024の21日目の記事です🎄 はじめに こんにちは。enechainでソフトウェアエンジニアをしている@nakker1218です。 私たちのチームでは、電力の取引仲介を行う同僚(ブローカー)たちが使う、注文の統合管理システムeNgineの開発しています。 ブローカーは日々1分1秒を争いながら収益を上げているため、システムが停止したり機能に不具合が生じると、事業に非常に大きな影響を与えてしまいます。 一方、電力業界はドメインが複雑で、要件や機能も多いため、バグが発生するリスクが高いです。 実際にこれまで以下のような問題が発生したことがありました。 Validな注文なのに、バリデーションが通らなくなった 特定の選択肢が選択されているときに表示されるはずのフォームが表示されない ショートカットキーを使ったインタラクションが一部正しく

この記事はenechain Advent Calendar 2024の20日目の記事です。 はじめに 背景 proto定義の一元管理 ディレクトリ構成 パッケージ公開のワークフロー 利用推進のための工夫 開発用ワークフローの整備 初期セットアップの自動化 コードメンテナンスの役割分担 おわりに はじめに こんにちは、エンジニアの青戸です。 enechainでは複数のプロダクトが利用する機能をマイクロサービスとして共通化する取り組みを進めており、APIの定義にはProtocol Buffersを利用しています。本記事では、proto定義の管理や公開を効率化するための取り組みについて紹介します。 背景 enechainではエネルギー取引にまつわる様々な課題を多方面から解決するために次々と新たなプロダクトが立ち上がっています。プロダクト数が増えるにつれて、認証認可や外部サービスとの連携等、複数の