忙しい人向けのまとめ ドメイン知識ってどうやったら早く身につくの？ ドメイン知識習得までの実践例 インプットにおいて意識したこと 各知識のインプットの進め方：実践例 業界のエコシステム 業界のトレンド 担当プロダクトのミッション 3C分析・ユーザージャーニー・アウトカムが出るまでの変数 さいごに enechainでブローカー向けプロダクトとクリアリングプロダクトのPdMをしている加藤です。 さて、会社選びの観点で、ドメイン知識がない領域に飛び込むのが怖いと思っている方は多いのではないかと想像しています。一方で、業務理解が難しいドメインに身を置く会社の中の人も、そうした方が活躍するにどんなオンボーディングプログラムや体制を用意すれば良いのか困っているのではないかとも思います。 そんな方の悩みに少しでも寄り添えればと思い、領域未経験・ドメイン知識がない状態で飛び込み約4ヶ月が経った身から、オン

はじめに enechainデザインシステムについて デジタル庁デザインシステム 特徴 Figmaファイル Webサイト GitHub Primer 特徴 Figmaファイル Webサイト Ameba Spindle 特徴 Figmaファイル Webサイト 各デザインシステムの構成まとめ enechainへの反映 Notionでのガイドライン まとめ はじめに こんにちは、デザイナーの渡邉と申します。私はenechainの業務委託メンバーとして、enechainの複数プロダクトを支えるデザインシステムの改善に携わっています。 この記事では、利用しやすいデザインシステムへと改善していく上でデザインチームが取り組んでいたことをまとめます。 enechainデザインシステムについて enechainでは10個以上のマルチプロダクトを開発・運用しており、デザイナーは各プロダクトでUIデザインを担当し

はじめに 背景と課題 システム概要 ワークフローの詳細 動画文字起こし (Gemini, GPT-4o) 文字起こしの議題単位の分割 (Claude 3.5 Sonnet) 議題単位での要約作成 (Claude 3.5 Sonnet, GPT-4o) 出力 実装上の工夫と課題 結果と今後の展望 おわりに はじめに こんにちは。enechainで統計・機械学習モデルの構築やLLM（大規模言語モデル）の活用推進を担当している@udon_tempuraです。 近年、GoogleのGeminiなど生成AIの発展が目覚ましく、多くの企業がこれらの技術を業務に取り入れようとしています。 私たちenechainも例外ではなく、積極的にLLMの活用を進めています。 今回はその活用例の1つとして、複数のLLMを使い分けて構築した「会議動画の要約作成ワークフロー」についてご紹介します。 このワークフローでは会

はじめに 背景 やりたいこと Why MSW？ 導入手順 詰まったこと defaultのtimeout設定時間が短い CIで落ちた時の検証方法がわからない 認証後のストレージの状態が入ってこない 今後の展望 おわりに はじめに enechainでフロントエンドエンジニアをしている@Shunya078です！ 自分の所属するGXデスクでは『日本気候取引所 - Japan Climate Exchange』(以下JCEX)のサービス開発を行っており、その中でReactを使用したフロントエンドの開発を担当しています。 リグレッションテストは運用を考えると、設計から導入した後、どう管理していくかまで検討する点が多く存在します。 JCEXは去年の年末にリリースされたばかりのサービスで、まだブラウザまで含めたリグレッション相当になるテストレイヤーが導入できておらず、存在しませんでした。 今回は新たに自チ

はじめに こんにちは。enechainのPlatform EngineeringチームSoftware Engineerの soma00333 です。 enechainは電力の卸取引や環境価値の取引の機会を提供するマーケットプレイスを運営する会社で、インフラ基盤としてGKEを採用しています。信頼性が非常に大切なドメインで、SREの力が欠かせないビジネスを展開しています。 この度、enechainはSREチームのさらなる強化を目指し、SRE as a Serviceを提供する 株式会社Topotal様 にご支援いただいて新たに2名のエンジニアを迎えました。 SREチームを強化するにあたり、「採用を頑張る」「内部で育てる」など手段は様々です。 本記事では、「外部会社（Topotal様）との協力」という手段がSREチーム・開発チーム全体にどのような効果をもたらしているかを紹介します。 SREチー

はじめに 旧BigQuery構成と課題点 新GCP Project/BigQuery構成 承認済みビューの設定 結果 終わりに はじめに enechainのデータプラットフォームデスクで2年目エンジニアをしている菱沼です。 本記事では、社内ユーザに対する閲覧権限をBigQueryの承認済みビューを用いて改善した例をご紹介します。 事業規模の拡大に伴い、各種データへのアクセス権限整備の重要性が増し、BigQuery上のデータも厳密な権限管理が求められるようになりました。 今回は、我々が抱えていたBigQueryアーキテクチャの権限管理上の課題と、その課題に対する取り組みについて具体的にご紹介します。 ぜひ最後までお付き合いください！ 旧BigQuery構成と課題点 データプラットフォームデスクで構築しているデータ基盤の1つに、 外部データソースから取得したデータを収集・蓄積するためのETLパ

はじめに なぜprotobufに認可設定を組み込もうと思ったのか？ 前提知識 protobufのプラグインの仕組み protocコマンドのインターフェース 実装 今回のお題 プラグインの開発 拡張プラグインの実行 生成したmapを使った認可処理 最後に はじめに こんにちは、enechainのApplication Platform Deskでエンジニアをしているendoです。 Application Platform Deskは、全プロダクトが横断で抱える課題を解決するチームです。 ※「開発者体験の向上を目指す」という意味ではPlatform Engineeringチームと近い位置づけですが、もう少しアプリケーション開発寄りの領域を担当しています。 私達のチームでは、protobufで自動生成したGolangコードを使ってAPI Endpoint毎にロール単位の認可処理ができる仕組みを構

はじめに 技術スタック eScanチームにおけるGraphQLの使い方 開発フローの工夫 N+1問題の対応と注意点 エラーハンドリングの工夫 モニタリングの工夫 ドキュメンテーションを必須化するための工夫 その他の取り組み 振り返り 良かった点 難しかった点 今後の展望 最後に はじめに こんにちは、enechainでソフトウェアエンジニアをしている小沢です。 私が所属しているチーム(以降、eScanチーム)では、eScanという電力会社向けのリスクマネジメントシステムを開発・運用しており、その中でGraphQLを採用しています。すでにGraphQLを採用するメリット・デメリットについて様々なところで語られていますが、eScanチームでもオーバーフェッチが解消できる点、1リクエストで必要なデータをフェッチできる点などのメリットを享受するために採用しています。 今回は実際にGraphQLを採

はじめに なぜ民主化か 目安箱の設置と対応件数 デザインシステム株主総会の開催 第一回：前期の事業報告と今期の事業計画について 第二回：プロダクトAで先行して実装した新・共通UIと今取り組むべきアクセシビリティ 第三回：プロダクトBで取り組んでいたカレンダーコンポーネントのFIXまでのプロセス振り返りとユーザー像をどうイメージするか デザインシステム名称の全社募集 まとめ はじめに enechainプロダクトデザインデスクのマネージャーの近藤（@add_kk）です。 1つ前のtakurintonの記事『デザインシステムの開発者体験向上の試み』に続いて、弊社のデザインシステムでの取り組みについて紹介させていただきます。 enechainでは会社全体のOKR *1 に基づき、4ヶ月サイクルで各組織がOKRを立てています。デザインシステムチームは専任メンバーがいない有志のチームであるため、OKR

はじめに 今回書く開発者体験について 具体的な試み eslint pluginによるコーディング規約の明文化 Notionへのリソース集約 デザイントークンと型定義 おわりに はじめに こんにちは。enechainで働いている takurinton です。 enechainではさまざまな開発者体験向上の取り組みが試行されていますが、今回は自分が主に見ているデザインシステムにフォーカスして記事を書こうと思います。 弊社のデザインシステムに関しては、 @Shunya078 の なぜ我々はデザインシステムを創るのか？ を読んでいただくと背景がご理解いただけると思います。 今回書く開発者体験について 開発者体験の定義についてはさまざまな解釈があると思いますが、今回は以下の3つのトピックに絞って紹介します。 eslint pluginによるコーディング規約の明文化 Notionへのリソース集約 デザ

はじめに こんにちは。enechainのPlatform Engineering Deskで働いているsoma00333です。 enechainではproductのdeploy先としてGKEを採用しており、Platform Engineering DeskではKubernetes Clusterの運用業務を行っています。 enechainは「エネルギーの取引所を作る」というmissionを持っており、productも増えてきています。 Platform Engineering Deskも今後ますますsecurityに力を入れていく予定です。 前回は、Platform Engineering Deskのsecurityに関する取り組みの一例として、Pod Security Admissionを紹介しました。 ※ Pod Security Admissionの紹介 今回は、引き続きsecuri

はじめに JCEXで実践しているAPIテストについて 単体テスト 負荷テスト なぜAPIの単体テストを行っているのか API単体テストで使用するパッケージ 実例によるAPI単体テストの環境構築 前提 ステップ１: テストしたいAPIの定義 ステップ２: テストの作成 ステップ３: APIの実装 ステップ４: DBを使ったテスト ステップ５: ヘルパー関数化 ステップ６: テーブル駆動テストに変える ステップ７: フィクスチャを使ったテスト まとめ おわりに はじめに こんにちは、enechainのGXデスクでエンジニアをしている@ejiです。 GXデスクは、『日本気候取引所 - Japan Climate Exchange』 (以下 JCEX) のサービス開発を担当しており、 私は主にBFFとバックエンドのAPIをGoで開発しています。バックエンドのAPIは gRPC を使用しています。