なんでも作れる時代に、何を作るか — アラン・ケイとAI時代のプロダクトデザイン - enechain Tech Blog
アラン・ケイとは何者か 今のコンピュータ体験の多くはここから始まっている Dynabook — 「個人のためのメディア」という構想 GUI — コンピュータを「触れる」ものにした Smalltalk — コンピュータの見方そのものを変えた Appleのプロダクトとケイの思想 未来を当てたのではなく、前提を変えた 「メディアはメッセージである」 コンピュータは「思考のためのメディア」である 「使う」だけでなく「作れる」メディア AI時代の違和感 「何を作るか」から「何を変えるか」へ おわりに 参考 enechainプロダクトデザインデスクの近藤（@add_kk）です。電力や環境価値の取引、トレーディングに関するデザインを主に担当しています。 先日、社内のLT会でアラン・ケイについて紹介したとき、こんな反応がありました。 「未来人すぎる」 「タイムトラベラーでは？」 「その時代にタッチ操作を考
Auth0から内製認証基盤へ移行を決めた背景と移行方法 - enechain Tech Blog
はじめに なぜ内製化を選んだのか プラットフォーマーとしての説明責任 制約の解消とコスト削減 認証基盤を内製で持つリスク 移行の設計 並行稼働による段階的移行 使用するデータソースの統一（SSoT） 認証基盤の内製化、並行稼働をしてみて 認証基盤全体がコントローラブルになった 内製化で得られた価値 並行稼働について 発生した課題 まとめ はじめに こんにちは、ソフトウェアエンジニアの大山です。 enechainではこれまでユーザー認証基盤としてAuth0を利用してきましたが、事業の成長に伴い自社開発の認証基盤（eAuth）へ移行しました。 本記事では、Auth0から内製へ移行する意思決定の背景、移行の設計について紹介します。 なぜ内製化を選んだのか enechainでは元々Auth0を認証基盤として採用していました。 少人数のチームでサービスを立ち上げるフェーズでは認証認可の開発運用コスト
スタートアップにおけるサクセッションプランニング~育成、採用、権限委譲~ - enechain Tech Blog
こんにちは。enechain CTOの須藤 (@sutochin26) です。 今更ながらグランメゾン東京にハマっています。キムタクも相変わらずカッコいいですが、丹後シェフが良いキャラしてますね！映画を観るのが楽しみです。 さて、グランメゾン東京も組織作りについて考えさせられる作品でしたが、本記事でも組織作り、特にサクセッションプランニングをテーマに書いていこうと思います。 我々のようなテックスタートアップの特徴の1つは、組織が急速に拡大することです。我々enechainも、私が入社してからの3年余りで、組織が30人規模から200人規模へと大きく拡大しました。 このような急成長の中では、計画的な後継者育成・採用が極めて重要になってきます。 うまく権限を委譲していかなければ、自身が意思決定のボトルネックになるだけでなく、SPOF(単一障害点)となり、事業上のリスクにもなってしまいます。 本記
外部データ取得と利用のテクニック - enechain Tech Blog
はじめに enechain データプラットフォームデスク エンジニアの鳥山です。 enechainでは電力取引に必要な情報（例えば電力需給や燃料価格）を外部から収集し、社内外に公開しています。 このデータ収集はAPI経由で有償購入しているものもあれば、オープンデータとしてwebサイトに公開されているものもあります。電力自由化以降、電力需給に関する情報の公開が進んでおり色々なデータが参照可能となっていますが、それらは必ずしもマシンフレンドリーなデータばかりであるとは限りません。これは電力に限らず、特定の業界特化のドメインデータにおいてはよくある状態です。 本稿では、このような不確実性の高いデータを収集・活用するにあたってのノウハウの一部をご紹介させて頂きます。 はじめに データ取得における問題 基本的な考え方 問題 対処 リトライとタイムアウトを設定する データを検査する rawデータを永続
SREチーム強化の新たな手段 ~協業で実現する信頼性向上~ - enechain Tech Blog
はじめに こんにちは。enechainのPlatform EngineeringチームSoftware Engineerの soma00333 です。 enechainは電力の卸取引や環境価値の取引の機会を提供するマーケットプレイスを運営する会社で、インフラ基盤としてGKEを採用しています。信頼性が非常に大切なドメインで、SREの力が欠かせないビジネスを展開しています。 この度、enechainはSREチームのさらなる強化を目指し、SRE as a Serviceを提供する 株式会社Topotal様 にご支援いただいて新たに2名のエンジニアを迎えました。 SREチームを強化するにあたり、「採用を頑張る」「内部で育てる」など手段は様々です。 本記事では、「外部会社（Topotal様）との協力」という手段がSREチーム・開発チーム全体にどのような効果をもたらしているかを紹介します。 SREチー
チームトポロジーの観点で見直すプラットフォーム開発組織 - enechain Tech Blog
はじめに チームトポロジーとは プラットフォーム開発組織に存在した課題 SRE何でも屋問題 中長期課題に取り組めない問題 チームトポロジーを元にした組織見直し SRE Deskを3つのDeskに分割 SRE DeskとPlatform Engineering Deskの違いを明文化 見直しの効果 見直しを通じての所感 最後に はじめに こんにちは。enechainでCTOを務めている@sutochin26です。 enechainでは、組織拡大に伴いSRE/Platform関連業務を行うチームの体制見直しを行ないました。 その際に、チームトポロジーの考え方を参考にする事で方針の言語化がしやすくなり、認識合わせの助けになりました。 SREとPlatform Engineeringをチームトポロジー視点で定義すること自体は新しくはないですが、本記事では実際に現場で生じていた課題と共にお話します。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
