[レポート]みんなの考えた最強のデータアーキテクチャ #datatechjp | DevelopersIO
さがらです。 11月8日20時～22時に、datatech-jp(データエンジニアリング関係のコミュニティ)主催でみんなの考えた最強のデータアーキテクチャというイベントが開催されました。 本記事はこのイベントのレポートブログとなります。 イベント概要 ※connpassより引用 datatech-jpで集ったデータエンジニアが、それぞれみんなの考えた最強のデータアーキテクチャを紹介し合うという夢のような企画が実現しました！ たくさんの新しいプロダクトが群雄割拠する現在、モダンデータスタックなどという言葉も登場しています。 今こそ、どんなプロダクトを選び、どのようなデータ基盤を作れば、効率的にやりたいことが実現できるのか。 5人の猛者からおすすめの構成をご紹介いただきながら、参加者のみなさんとも一緒に考えていく時間としたいと思います。 おまけ：当イベントの応募者数 このイベントですが、なんと
![[レポート]みんなの考えた最強のデータアーキテクチャ #datatechjp | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/9f9486832be1a42a11ac2d244e8c51de11a34ab7/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2022%2F11%2F2022-11-08_19h35_04.jpg)
作者冥利に尽きる - ゆーすけべー日記
会社の朝会で話す番が回ってくる。 メンバーが入れ違いで自己紹介をするんだけど、 それに加えて「自分なりのこだわり」みたいなことを話す流れになっている。 自分の場合、つくってきたもの紹介とそれから学んだこと、みたいなのはどうだろうか。 結局こういうキーワードが出た。 作者冥利に尽きる。 今まで原動力になっていたのは、 プロダクトを使ってもらって嬉しい反応をもらうことだ。 なので「もしよろしければ、みなさんも（一緒に、じゃなくてもいいけど）作者冥利に尽きる体験をしましょう」 という流れにしようかと。上からだけど、まぁありでしょう。 で、作者冥利に尽きるにはどうすればいいか。メモを残す。 つくってきたもの いわゆる「個人開発」というものをやってきた。 特にWebサービスをたくさんつくってきた。数えたらエロ含めて70個、除いて48個だった。 以下のスライドで全部網羅してある。 僕がつくった 70個
月5ドルの自作サービスで最初の500人を集めるまでにやったこと
顧客はいったん継続課金を開始すると、特に大きな問題に遭遇しない限り概ね何ヶ月も継続して利用する傾向があります。最近のチャーンレート(解約率)は2~3%で、驚くほど低いものでした。ターゲット層である開発者はこだわりが強いため、彼らは熱心に他のMarkdownエディタを何年もかけていろいろ試しています。そして僕のアプリを最終的に選択しました。だからそう簡単に他に移ったり辞めないのでしょう。ちょうど彼のように： Your application is a life changer. I’ve tried numerous markdown based applications over the years and I’m so pleased to finally find a keeper! Awesome work! — James Lilliott しかし彼らは常によりよいツールを探し求め
コードレビューのときに見ているところ - 詩と創作・思索のひろば
あるときコードレビューするときにどういうところ見てるんですか？ と訊かれてたしかに自分でもあまり言語化したことはなかったな、と気づいたので簡単に書いておく。 変更意図が要求に沿っているか そもそも実現しようとしていることが、ユーザやプロダクトオーナーの要求に沿っているか。モデリングや実装のコンテキストを自分でも把握しておく。 関連する別の変更やイシューなど、自分が知っていて相手が知らない有意義な情報があったらコメントする。 モデリングが妥当か モデルによって意図が表現できているか。仕事が適切な粒度で明確に切り分けられているか。意図のない共通化がなされていないか。 わかりやすい名前がつけられているか。ここが混乱していると何かがよくないサイン。既存のコードがすでに……ということもある。そういう場合は改善できそうな道筋について議論できるとベター。 仕事にあったインタフェースになっているか。テスト
日本のソフトウェア企業でよく見るエンジニア組織の構造と、近年推奨されるエンジニア組織の構造について
はじめに 恥ずかしながらスクラム開発の開発チームへの導入を何度も経験しているのだけれど、どうしてもチームの成熟レベルが高い位置までもっていくことができませんでした なぜうまくいかないのか？ これを深掘りする過程で教科書どおりに実行するには組織の構造がスクラムガイドで書いてある構造と根本的に異なっているのではないか？と考えるようになりました。 よくあるエンジニア組織の構造 大きめのWebソフトウェア企業の内製型エンジニア組織の構造はだいたいどこもこのような感じになっています この組織構造の問題点 スクラムを導入する場合、リーダー自身かあるいはメンバーの一人がスクラムマスターとなります リーダー自身がスクラムマスターになる場合でもアンチパターンと言われる開発者との兼任になります。 スクラムマスターの最も重要な職務である「観察」が行えなくなります。 スクラムマスター自身が観察を行わない場合、各メ
勘を減らしてテクノロジーの力でエンジニア組織を応援したい｜Findyに入社しました👍 - Blog::kobaken
こんにちは。こばけんです。 8月末に約11年半勤めたモバファクを退職して、9月からFindyで働きはじめました。 モバファクでは、エンジニアとして新卒で入社し、プロダクトマネージャー、エンジニア組織開発責任者など任せていただき、たくさんの方にお世話になりました。ここ数年のモバファクでの仕事はエンジニア組織全体を改善する仕事でしたが、こちらをこじらせ、まだやるべきことはありつつも退職をさせていただました。応援の言葉をかけていただいた同僚に感謝してます。ありがとうございます。ありがとう。 Findyは、五反田の会社のよしみで繋がってはいましたが、正直入社することは想像していませんでした。が、今はもっと早く知っていれば良かったと思ってます。技術コミュニティに育てられた恩があるので、技術に関わる人や組織に向けたプロダクトを作りたいと思っていました。また、エンジニア採用も組織も問題を抱えてない会社は
Pull Requestの質を向上させるために行った戦略/戦術の話 - JMDC TECH BLOG
株式会社JMDCでモバイルアプリエンジニアをやっている @mrtry です。入社した当初、モバイルアプリチームのエンジニアは私一人だったのですが、現在では4人になりました。最近はPull Requestのレビュー数も爆増しており、とても疲弊しがちです(嬉しい悲鳴)。たいへんポイントを減らすために、最近Pull Requestまわりの運用を整えたので、今日はその話をしたいと思います。 Pull Requestのレビューがたいへん 現在、モバイルアプリチームでは、3つのプロダクトの開発をしています。各プロダクトに1名ずつassignされており、リードエンジニアとして私が一通りレビューをしている状況です。そんなこともあり「Pull Requestのレビューがたいへん」というのが最近の悩みでした。 Pull Requestのレビューをするとき、私は以下のような観点でレビューしています。 機能仕様レ
フロントエンドのコードからの情報漏洩を防ぐための工夫 - BASEプロダクトチームブログ
基盤チームの右京です。 昨今はフロントエンドのアプリケーションもリッチになり、ブラウザ上で実行されるコードが行うことの範囲も増えてきました。一方で多くのことを実装できてしまうのはリスクでもあり、BASE でも問題となることがあります。 その中でも「開発環境の URL」や「デバッグ機能の存在」ような環境毎に異なる情報は、特に意図せずに漏れやすいものだと考えています。これらはコードを記述する際に、実装方法を知識として知っていればその多くが回避可能です。この記事ではその実装例を解説しています。 コードから漏れる情報 例えば、次のようなコードがあるとします。 function debug() { // 開発環境の host であればデバッグ機能を有効にする return location.host === 'dev.example.com'; } なんの変哲もないようなコードに見えますが、ブラウザ
チームの目標が「とにかくたくさん開発する」はいけない “アウトプット”ではなく“アウトカム”を重視する体制作り
プロダクト開発チームが40人規模の組織となっていく過程で、どんな課題に直面し、どのような取り組みをしてきたのかをLT形式で届ける「食べチョク Tech Talk #1 『ユーザーに早く価値を届ける』組織と技術それぞれの取り組み」。ここで執行役員CTOの西尾氏が登壇。株式会社ビビッドガーデンが重視している「アウトカム」についてと、その思考に合わせた開発体制作りについて話します。 生産者の課題と、株式会社ビビッドガーテンの取り組み 西尾慎祐氏：「アウトカム思考なプロダクト開発を実現する組織作り」というテーマで、私たちの組織や開発チームがどういう体制でやっているかという話ができればと思っています。私は、株式会社ビビッドガーデンでCTOをしている西尾です。よろしくお願いします。 まずはその前に、私たちの会社がやっていることを紹介します。ビビッドガーテンは「食べチョク」というサービスを運用しています
10歳の minne から、これから長く続くプロダクトを作るすべての人へ
【iCARE Dev Meetup #34】10年続くRailsアプリ開発のために大事なこと での発表資料です。
はじめに - NestJSの強化書 βversion
本書の目標は、本読者がNestJSをすぐに実務で利用できる(具体的に言えばNestJSで簡単なプロダクトを開発できる)ように、最短ルートに読者を導く一冊になることです。本書は、NestJSの網羅的なドキュメントではありません。取り扱う内容は頻出する機能に絞って、「実務でNestJSを扱うなら、最低限ここだけは理解しておこう」「これさえ押さえておけば実務でも安心できる」という観点で執筆しています。 本書はNestJSを中心に取り扱いますが、実務上、必要になる知識としてJavaScriptやTypeScriptの仕様やフロントエンドフレームワークのReactやVueについても扱います。
プロダクトマネジメントを学ぶための推しの書籍
プロダクトマネジメントを学びたい人、プロダクトマネージャーにおすすめの書籍です。 以下、記載した書籍のリストです ## Product Management ### プロダクトマネジメントを広く理解する 「プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける」オライリージャパン (2020/10/26) https://www.amazon.co.jp/dp/4873119251/ 「プロダクトマネジメントのすべて 事業戦略・IT開発・UXデザイン・マーケティングからチーム・組織運営まで」翔泳社 (2021/3/3) https://www.amazon.co.jp/dp/4798166391/ 「INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント」日本能率協会マネジメントセンター (2019/11/1) https://www.amazon.co.jp/dp/4
1億円を投資した、プロダクトリニューアルが失敗に終わった理由｜山田修 | Osamu Yamada
こんにちは。Micoworks代表の山田と申します。 私はこれまでに10年ほど会社を経営させていただいておりますが、多くの失敗をしてきています。 その中でも投資額として最も大きかった失敗が「採用管理システムのリニューアルプロダクトを潰してしまったこと」でした。 2,3年ほど前の話になりますが、リリースまでに1億円程度を投下しておりお金の損失はもちろんですが、BizやCSメンバーも多大なリソースを費やし、会社の成長を失速させてしまいました。 当時は「この時間を丸々MicoCloudに投下していれば、もっと成長していたのに、、、」と自分の未熟さを何度も悔いていました。 この話の真因は「非エンジニアの経営者が、プロダクト開発の工数や進め方を理解できていないままプロジェクトを進めてしまったこと」だったと感じています。 そこで備忘録を兼ねて、noteのテーマとして取り上げてみたいと思います。 ※テッ
進出して分かった日本とアメリカのSaaSプロダクトニーズの違い
はじめにこれは何？ 数カ月間マーケット調査、商談をして見えてきた日本とグローバルでSaaSプロダクトに求められることの違いを紹介する 誰向けの記事？ グローバルで利用されるプロダクト開発に興味のあるPdM, エンジニアの方 まとめると？ 競合がエグい。日本はプロ野球で、グローバルはメジャーリーグみたいなイメージ。プロダクトは広く浅く→狭く深くに要件が変わる。 エコシステム、SaaS市場の成熟度の違いから、インテグレーションファーストになる 時差や人件費の違いがプロダクトに影響を与え、セルフサービス前提の設計になる 伝えたいこと グローバルで使われるSaaSプロダクトづくり（＝メジャーで野球する）、そしてそこで勝つためのプロダクト・開発組織づくりに経営者として本気で取り組みます。 メジャーで勝利するために、優秀なメンバーが集まり、切磋琢磨し、成長できる環境。勝ち筋も見えています。他ではできな
プロダクトの目的・目標・指標をチームで考えていくために可視化した話 - SmartHR Tech Blog
こんにちは、プロダクトマネージャー（以下PM）の adachi です。（ToDo: ここになにか面白い文章を入れる） 先日、プロダクトの目的・目標・指標をまとめた図をTwitterに投稿したところ、わりと反響があったのでこちらで解説したいと思います。 開発メンバーから「会社の戦略とプロダクトの目標がどう紐付いてるかわからない」という声をもらって作った図。 改めて整理する中で自分のなかでも気付きがあり、もっと早くやっておけばよかったなと思いました。 pic.twitter.com/tuedZhaZG2— Takashi Adachi (@asanebo_) 2022年6月1日 この記事でお伝えしたいこと 会社のミッションや戦略とプロダクトの目的・目標・指標は、構造的に整合していることが重要である PMにとって自明に思えることでも、アウトプットしなければチームで共有できない 目的・目標・指標の
プロダクトマネージャーの必須スキルである「言語化」を活かす 最強の言語化ツール・Notionを活用した情報の一元管理法
Notionを使ったプロダクト開発管理のノウハウを紹介する「実践！プロダクトづくりとNotion活用事例」。ここで株式会社TechBowlの大木氏が登壇。PM目線から見た、Notionのメリットと活用法を紹介します。 自己紹介 佐々木真氏（以下、佐々真）：じゃあやっていきたいと思いますので、よろしくお願いします。タイトルが「Notion×プロダクト作り最強活用法」というところですが、今日は15分しか時間がないので、できるだけエッセンスをお伝えできればなと思っています。 あらためて自己紹介です。私はTwitterにはこのアイコンでいます。佐々木真と申します。プロダクトマネージャーで、PM Clubの主催者をしています。過去に事業売却したり、起業したり、現在はIT企業で顧問をしたり。あとは、シンガポールの法人で取締役をやっていたりもするので、「何やってんだかよくわかんねぇ」みたいなこともありま
Notion API を使った機能開発 〜最小の実装で作る要望回収システム〜 - Timee Product Team Blog
はじめに こんにちは、フロントエンドエンジニアの樫福 @cashfooooou です。 タイミーでは toB 向け管理画面を作成しています。 半年ほど前、タイミーでは顧客からのサービスへの要望を集め、管理するシステム（以下、要望回収システム）を作りました。 顧客の課題から新しい機能について考え、顧客により価値のあるものを届けるための施策です。 システムの実装には Notion という SaaS を活用しました。 最小限の実装で良い機能・良い運用が作れたと思っています。 この記事では、要望回収システムの実装に取り組んだ経緯から、実際の運用の例まで紹介します。 同じように顧客の要望回収を行いたい方はもちろん、SaaS を使ったミニマルな機能開発の参考になれば幸いです。 はじめに Notion 従来の回収システム 課題 解決したい課題 Notion API を用いた課題解決 制約 データベースの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
最近の日本の中高生はWebブラウザーやOSを開発しちゃうのね／オープンソースで様々なプロダクトを生み出すコミュニティ「Ablaze」がすごい！【やじうまの杜】
電子情報学特論：Chromiumのアーキテクチャを解き明かす