プロダクトマネジメントのコーチをしています。プロダクト開発の中でもGPT4を使うケースが増え、相談されることが増えてきました。 ChatGPTのGPT4を用いた際の、専門家として信用できる精度で推論させるための工夫の一部を紹介します。精度が必要な専門職かつ中級者向けになると思います。「機密情報の入力をどうさけるか」といった運用の話は今回はしません。 やったことと起きたこと一通り論文を読んで試したり、試行錯誤しました。 その結果、専門家として業務レベルで使える程度のものができるようになってきました。 クライアントのプロンプトを添削する仕事も増えつつあります。副作用として、日本語なのに日本語と感じられない自然言語に目覚めてきました。この片鱗についてお話しします。 分かったこと分かったこととして、精度を業務レベルで用いるためにまずはじめにとりくむことは下記です。 ・接待モードを切る ・指示の質が
年度が代わり新しい環境に行く人も多いですね。新しい環境・プロダクトだといろいろ戸惑うことがあります。自分は数年ごとに転職し、副業も複数のところでしているので初めての環境に関わることが結構あります。そのなかで素早くチームになじんでプロダクトに貢献できるようにやっていることがあるのでそれを紹介したいと思います。 自分がウェブやアプリのエンジニアなのでその文脈で話します。 「プロダクトのあるべき姿と現状を把握する」と「短期的・長期的に貢献できることを探す」ことを意識してやっています。 プロダクトのあるべき姿と現状を把握する 関わるプロダクトがユーザの何を解決しているのか理解することは開発する上で非常に大切です。機能を開発する上でもただ開発するだけでなくその機能自体が必要なのかどうか、必要ならどのような機能にすればユーザが問題を解決しやすいかという何を開発するかに密接にかかわっています。 1. ア
同じTypeScriptという言語を利用する場合においても、トランスパイラによってTypeScript自体の機能制限がかかったり、思わぬトラブルを招く場合があります。それぞれのトランスパイラの特徴を踏まえた上で、それにより生じる問題も見ていきましょう。 1-1. tsc TypeScriptの開発元であるMicrosoft純正のTypeScriptトランスパイラです。TypeScriptを利用する際に typescript パッケージをインストールする必要がありますが、それに同梱されています。 公式ツールなだけあって最も早く最新バージョンのTypeScriptに対応したり、言語すべての機能を利用することができる一方で、バンドラではないためminifyやchunkの設定はできません。また、Path Aliasesの未解決や旧ESへの互換性が不完全であることが欠点として挙げられます。 tsco
はじめにメルカリUK版の立ち上げを終え2018年3月に帰国しました@tsumujikazeです。今は東京でメルペイのProduct Managerをしています。 イギリスではいわゆるモダンなプロダクトチームでのLeanなプロダクト開発を経験しました。得るものが多かったので、なるべく多くの人に知ってもらいたいと思いこのポストを書きました。 PMF →リーンプロダクトのプロセス →モダンなプロダクトチーム（組織論）という流れになっています。 はじめに 本編 ・何のためにプロダクトを作るのか ・プロダクトマーケットフィット ・PMFピラミッド ・要件定義フェーズのリーン化 ・モダンなプロダクトチームでのリーン開発とは おまけ ・Problem Space vs. Solution Space ・Problem Solution Fitとは ・エンジニア組織とPM組織の特性について ・バリュープロ
Agile Manifestoには以下のように書いてあります。 動作するソフトウエアは包括的なドキュメントにまさる ともするとドキュメント軽視と取られかねない宣言です。この宣言を誤って解釈してドキュメントはいらないとなる場合もあるかもしれませんが筆者はそれは間違いだと思っています。この宣言では包括的なドキュメントよ
差し込みの多いプロダクト開発のスケジュールの精度を上げるためにはバーンアップチャートがおすすめです - スタディサプリ Product Team Blog
こんにちは。 今回は差し込みの多いプロダクト開発におけるスケジュール精度の上げ方として、バーンアップチャートの利用をおすすめしたいと思います。 どんな人に読んでほしいか Product GrowthやEnhancementに携わっているけど、やることが多くて思ったように進捗が管理できない人 ↑のようなProduct Manager(PdM)やProject Manager(PjM)とのコミュニケーションが多いけど、期待に対してうまく動いてくれないことをもどかしく思ってる方 TL;DR 3ヶ月や6ヶ月程度でタイムボックスを切りましょう タイムボックスの中でやりたいことを全部リストアップして見積もりをしましょう 終わったタスクのcloseと新規タスクのリストアップを繰り返すと、自然と「やりたいことが全部できるのかどうか」が見える化します バーンアップチャートとは 下記のようなものです。 図中の
小さいプロダクト開発におけるGCP利用の勘どころ - 個人的なプロダクトを三日でローンチした話 - Lean Baseball
私個人の話なのですが. 最近は仕事でAWSやGCPのサーバレスアーキテクチャにふれる機会が増えた*1と同時に, 自分が気になる世の中のニュース（グルメとかいろいろ）だけをいい感じに集めてまとめて読みたい その中でも特に⚾, 速報とかいい感じに通知させたい という怠け者欲ライフハック欲が高まってきたので, GCP（とちょっとしたPythonスクリプト）でSlack Botを作りました. 趣味開発で雑にはじめた結果, 三日程度でできちゃった*2のでその知見をメモ代わりに残します. おしながき おしながき TL;DR 対象読者 作ったもの GCPをフル活用して実質三日でBotをローンチした Bot本体の開発 GCPの何を使うかで試行錯誤 プランA「GCEを使う」 プランB「Cloud Run + Cloud Scheduler」 採用した構成「Cloud Functions + Cloud Sc
Reactを使ってプロダクト開発している開発者だけでなく、マネージャにも読んでほしい「Fluent React」 - ROUTE06 Tech Blog
チームでReactを使って開発していると、コードレビューをする際に、「この書き方はしない方がいいが、それを説明するには800文字くらい必要。図も描きたい。でもそれらを準備する時間はない。」ということが度々ありました。 また、フレームワークやライブラリの技術選定をする際、マネージャに「どうして技術選定が必要なのか」を説明する必要がありました。ROUTE06のマネージャはエンジニアリングへの造詣が深い方が多いので、対立構造になることはありませんが、説明するためには1000文字くらい必要で、やはり図も描きたい。時間はない。と同じ気持ちになることがありました。 参考情報として紹介できる情報がないか探してみると、「とりあえずこうすればOK」というベストプラクティスについては検索エンジンやSNSですぐに見つかります。ただ、どうしてその方法がベストプラクティスなのか、仕組みや原理を説明している情報は少な
この記事は "What We’ve Learned From A Year of Building with LLMs" という記事を著者の一人である Eugene Yan さんから許可を得て翻訳したものです。 https://applied-llms.org/ Thank you for giving me a permission to translate this wonderful article! 著者の方々 Eugene Yan Bryan Bischof Charles Frye Hamel Husain Jason Liu Shreya Shankar 原文の公開日 2024/６/8 今は大規模言語モデル（LLM）を使った開発がとってもエキサイティングな時期です。この1年間で、LLMは実世界のアプリケーションに対して「十分に良い」ものになりました。そして、年々良くなり、安く
![[翻訳]LLMで1年間開発して学んだこと〜LLMプロダクト開発を成功に導くための実践的ガイド〜](https://cdn-ak-scissors.b.st-hatena.com/image/square/3636c7c8e7c838018a6e006d55b3f4b8d18f34cc/height=288;version=1;width=512/https%3A%2F%2Fres.cloudinary.com%2Fzenn%2Fimage%2Fupload%2Fs--7VM-vHg9--%2Fc_fit%252Cg_north_west%252Cl_text%3Anotosansjp-medium.otf_55%3A%25255B%2525E7%2525BF%2525BB%2525E8%2525A8%2525B3%25255DLLM%2525E3%252581%2525A71%2525E5%2525B9%2525B4%2525E9%252596%252593%2525E9%252596%25258B%2525E7%252599%2525BA%2525E3%252581%252597%2525E3%252581%2525A6%2525E5%2525AD%2525A6%2525E3%252582%252593%2525E3%252581%2525A0%2525E3%252581%252593%2525E3%252581%2525A8%2525E3%252580%25259CLLM%2525E3%252583%252597%2525E3%252583%2525AD%2525E3%252583%252580%2525E3%252582%2525AF%2525E3%252583%252588%2525E9%252596%25258B%2525E7%252599%2525BA%2525E3%252582%252592%2525E6%252588%252590%2525E5%25258A%25259F%2525E3%252581%2525AB%2525E5%2525B0%25258E%2525E3%252581%25258F%2525E3%252581%25259F%2525E3%252582%252581%2525E3%252581%2525AE%2525E5%2525AE%25259F%2525E8%2525B7%2525B5%2525E7%25259A%252584%2525E3%252582%2525AC%2525E3%252582%2525A4%2525E3%252583%252589%2525E3%252580%25259C%252Cw_1010%252Cx_90%252Cy_100%2Fg_south_west%252Cl_text%3Anotosansjp-medium.otf_37%3Aseya%252Cx_203%252Cy_121%2Fg_south_west%252Ch_90%252Cl_fetch%3AaHR0cHM6Ly9zdG9yYWdlLmdvb2dsZWFwaXMuY29tL3plbm4tdXNlci11cGxvYWQvYXZhdGFyL2QzODg4YjM0MzEuanBlZw%3D%3D%252Cr_max%252Cw_90%252Cx_87%252Cy_95%2Fv1627283836%2Fdefault%2Fog-base-w1200-v2.png)
チームのキャパシティを超える要求を抱えたプロジェクトが、なんの問題もなく完了するはずがありません。なんとか作り上げられた機能は、表面上は要求通りでも、どこかぎこちなさを感じます。ユーザー体験が悪く、それがユーザー価値を押し下げ、ビジネス価値を削り取ります。触るたびに新しい欠陥も見つかるかもしれません。内部品質も最低です。それが今後の追加開発の足を引っ張ることにもなるでしょう。そして、ただ消費するような働き方によって、チームは成長も達成感も感じられず、疲弊します。 詰め込み型のプロジェクトは、誰にとっても利点がなく、そのうえ持続不可能なやり方なのです。 「詰め込んでもなんとかなる」という楽観主義詰め込み型のアプローチは、組織内でプラクティス化しやすいプロジェクト計画手法です。この手法で完了したプロジェクトは、一見すると、上手くいったように見えます。多少の遅延があったとしても、概ね一通りの機能
セキュアにGoを書くための「ガードレール」を置こう - 安全なGoプロダクト開発に向けた持続可能なアプローチ - Flatt Security Blog
The Go gopher was designed by Renee French. (http://reneefrench.blogspot.com/) The design is licensed under the Creative Commons 3.0 Attributions license. 種々の linter が様々なプロダクトの品質を高めてきた、というのは疑う余地のない事実です。実装の初歩的な問題をエディタ内や CI/CD パイプライン中で機械的に検出できる環境を作れば、開発者はコーディングやコードレビューの邪魔になる些末な問題を早期に頭から追い出し、本質的な問題に集中できます。 また、そのような環境づくり（e.g. linter のルールセットの定義、組織独自のルールの作成、…）は、まさに開発組織のベースラインを定義する作業として捉えることができます。一度誰かが定義
依頼、調整、合意、承認、etc. こういったコミュニケーションがチーム境界を越えて頻発すると、ソフトウェアプロダクト開発のフローは遅々として進まなくなります。いずれも、機能追加や機能改善を進める上でのクリティカルパスを引き伸ばす要因を生み出すからです。 機能追加や機能改善といったひとつひとつの開発は、アイデアを生み出し、それを価値に変えるまでのフローです。フローが進む過程で、組織内の様々な人の手で、様々なタスクが実行されます。その全てを1つのチームで完結することは、プロダクトの規模が大きくなるほど困難になり、より多くの人々が関わるようになります。そこに、チーム境界を越えた「依頼、調整、合意、承認」といったコミュニケーションが発生するのです。 開発フローのクリティカルパスを悪化させるこのようなコミュニケーションの頻度をどれだけ減らせるか。組織設計、チーム設計で最も注視すべき観点の1つは、そこ
もしあなたがLLMを使ったプロダクトを何かしら開発している、もしくは興味があるのなら、メモリを大量に積んだMac Studioの購入を検討すべきです。 対象読者NVIDIAが絶対にいいという人はこの記事の対象読者ではありません。また、用途によって、ローカルマシンによるローカルLLMが向いてる・向いてないは明確にあるので、向いてない用途にしか使わない人も対象読者ではありません。あしからず。 また、この記事は別にNVIDIAをdisる意図はありません。みんな違っていい。NVIDIAもいい選択肢ですが、Mac Studioも悪くないですよ、と言いたい。 結論LLMプロダクト開発において、今年はもはやローカルLLMを無視できない、してはいけない状況です。 LLMプロダクト開発をする会社の視点でいえば、是非とも80GB以上の十分なGPUメモリを積んだマシンを用意できるようなアジリティを持つのが望まし
プロダクト開発のユーザーを絞って考えることの重要性とsuper-specific whoの考え方 ｜PM Club
プロダクト開発において、ユーザーを絞って考えることの重要性と"super-specific who"という考え方や決め方について解説しています。
IPAによる海外でのアジャイル開発についての報告書「非ウォーターフォール型開発の普及要因と適用領域の拡大に関する調査報告書 （非ウォーターフォール型開発の海外における普及要因編）」を紹介した昨日の記事「海外でなぜアジャイル開発が普及しているのか？ IPAが分析と提言」は、とても多くの読者に読んでいただき、ツイッターやブックマークなどでもコメントが多数寄せられました。 そうした反響の中で、この調査報告の作成に関わったアジャイル開発の第一人者である平鍋健児氏から「資料の付録にある海外でのインタビューが興味深いので注目してほしい」というメールをいただきました。 インタビューの中で「日本国内に限らず、海外でもアジャイル型開発の普及が進みにくい領域がある」という点を指摘部分は、アジャイル開発がどう位置づけられているのかをあらためて浮き彫りにしているように思います。主に、「リーンソフトウェア開発」シリ
個人開発者 catnose ソフトウェア開発者・デザイナー。 個人開発者として、Webデザイナー向けメディア「サルワカ」、ポートフォリオ作成サービス「RESUME」、技術情報共有サービス「Zenn」、簡単にAIサービスがつくれる「だれでもAIメーカー」など、数々のプロダクトを世に送り出す。家族は妻、娘、犬、猫。 個人開発者として、ポートフォリオ作成サービス「RESUME（レジュメ）」や技術情報共有サービス「Zenn（ゼン）」、入力欄や選択ボックスを組み合わせるだけで簡単にAIサービスがつくれる「だれでもAIメーカー」など、数々のプロダクトをヒットさせてきたcatnose（キャットノーズ）さん。現在も複数の開発案件に関わりながら、新たなプロダクトを開発中だといいます。 今回はそんなcatnoseさんのこれまでの作品を振り返りながら、個人開発者として培った開発哲学や、30代になるとともに起きた
2017.07.15 HANATANI Takuma a.k.a. potato4d #phpkansai
ざんねんなプロダクト開発事典
2022/11/02のPMConf2022で登壇した内容になります。 登壇セッションのYoutubeはコチラ。 https://www.youtube.com/watch?v=jNRb5CppCIQ
こんにちは~！プロダクトマネージャー(PM)を10年以上してしている@megです。私が若手の頃はPMについての情報がほとんどなくて困ったので、若手PMのちょっとでも役にたてばいいなぁとまとめていこうと思います。 メルカリや副業でのスタートアップでの新規プロジェクトの立ち上げをよくしていたので、その時のプロダクトマネージャーをしていた視点から企画フローをまとめてみました！あくまでも、会社としてではなく、私個人が自分のチームやコンサル先で使っているフローです。 10年以上前はSIerで100人規模のウォターフォールでの開発をしていて、ここ数年のスタートアップはアジャイルぽいものが多く、その中間のメルカリだと事業計画や予算もある中、ウォーターフォールっぽく一定フェーズをを決めつつ、アジャイルのいいところを取りいれるような開発していました。実際は、そのようなどっちとも言えない開発が多いのでそのパタ
強くてニューゲームなプロダクト開発 / Product development in new game plus
エンジニア組織30人の壁を超えるための 評価システムとマネジメントのスケール / Scaling evaluation system and management
Shin Sasaki on Twitter: "Figmaの歴史はプロダクト開発者にとって学びの宝庫だった📝 1. 初期コンセプト「ブラウザ上のフォトショップ」は不発 2. 当時の常識は「1人かつオフライン」 3. 機能を絞りUIデザインに特化し成功 4. 他ツールからシェア… https://t.co/F9dyeR8Gbv"
Figmaの歴史はプロダクト開発者にとって学びの宝庫だった📝 1. 初期コンセプト「ブラウザ上のフォトショップ」は不発 2. 当時の常識は「1人かつオフライン」 3. 機能を絞りUIデザインに特化し成功 4. 他ツールからシェア… https://t.co/F9dyeR8Gbv
みなさん、こんにちは！プロダクト開発部の吉川（@yoshiyu0922）です。 現在、JMDCが保有している医療ビッグデータを活用して生活者や医療に新しい価値を提供する新規プロダクト開発チームのバックエンドを担当しております。 以前に新規プロダクト開発で採用している技術や設計についてこちらの記事で紹介しましたが、Go x GraphQL x DDDでプロダクト開発をしています。今回はプロダクトの開発が一区切りしてこれからリリースするということで、開発してみて良かったことやこうすれば良かったことを振り返りをしました。振り返りの内容は主にDDDに関することです。 DDDとは DDDとは「Domain-Driven Design」の略語でドメイン駆動設計と呼ばれるソフトウェア開発手法の一つです。問題を解決しようとする領域（ドメイン）をモデリングによってソフトウェアの設計や実装に反映させることで、
GPT-3.5-turbo を Fine-tuning して GPT-4 相当の性能を獲得する - DROBEプロダクト開発ブログ
はじめに 結論 背景 課題 Fine-tuning とは？ Data の準備 Fine-tuning を実施 結果 おわりに 参考 はじめに こんにちは、DROBE の都筑です。 みなさん LLM 使っていますか。今回は GPT-3.5-turbo の Fine-tuning の事例を紹介します。 結論 GPT-4 を利用して得られたデータを使って GPT-3.5-turbo を Fine-tuning する事で、特定のタスクに関しては GPT-4 相当の性能が出る事が確認できた GPT-4 利用時点で使っていたプロンプトをそのまま使った場合の性能が一番高く、token 節約のためにプロンプトの省略をすると性能が劣化した 背景 LLM を利用したサービスの開発において、OpenAI を利用する場合にはモデルの選択肢がいくつかあります。2023年9月現在では、GPT-4 と GPT-3.5-
プロダクト開発組織のチームビジョンを作ったらすごいパワーが生まれた話 - Uzabase for Engineers
こんにちは。NewsPicks プロダクトチームの文字です。今日はプロダクト開発組織のチームビジョンを作ったら、すごいパワーが生まれた話をさせて頂きます。 「経済を、技術でもっとおもしろく。」 今年の春、NewsPicks のプロダクトチームでは、こんなチームビジョンを作りました。実は NewsPicks のタグラインは「経済を、もっとおもしろく。」なので、会社の掲げるタグラインをほぼ踏襲しているように見えます。しかし一見凡庸なこのビジョンが、実はとても大きなパワーを秘めていたのです。 1/ なぜビジョンをつくったのか 増大し続ける技術的負債と運用負荷 組織の急拡大 2/ みんなでビジョンをつくる 合宿の開催 腹落ちできるビジョンが完成 3/ ビジョンをつくったら、どうなったのか？ ビジョンはパワー 4/ これからのプロダクトチーム 1/ なぜビジョンをつくったのか そもそも、何故こんなチ
デブサミ2017でパネルディスカッション形式で登壇させていただいた。 event.shoeisha.jp エンジニアからプロダクトマネージャーへのキャリアがテーマで、私自身どうやってなったのか振り返るキッカケになった。また別の機会でもエンジニアのキャリアについて考えることが多く、改めてエンジニアからプロダクトマネージャーへのキャリアについてまとめてみた。 プロダクトマネージャーの仕事と必要なスキル まず、プロダクトマネージャーの仕事とスキルについて言語化を試みた。プロダクトマネージャーの教科書であるINSPIREDにもあるように、プロダクトマネージャーの任務は2つ、「製品の市場性を評価する」ことと「製品を定義する」こと。少しわかりにくいので、下記の3つのプロセスを定義した。 市場の分析 STP（セグメンテーション/ターゲティング/ポジショニング・コンセプト） 製品要求の定義 Webの製品開
技術とビジネスのハブになる！ プロダクト開発のためにエンジニアとガチで議論するリクルートコミュニケーションズのITプランナーの役割とは - はてなニュース
3年ぶり、4回目のリクルートコミュニケーションズ（以下、RCO）×はてな座談会をお届けします。これまでの座談会ではRCOが優秀なエンジニアが活躍できる風土作りのために、継続的に注力してきた様子をお伝えしてきました。今回、焦点を当てるのはエンジニアではなく同社の「ITプランナー」です。 エンジニアリングとビジネスの両方を視野に入れ、価値を創出する役割がITプランナーだとRCOは定義します。同社には、エンジニア出身のITプランナーも多数在籍しており、時にはアーキテクトとガチの議論をすることもあるそうです。RCOがITプランナーという人材に注目する理由は何か？ 自身もエンジニア出身であり、エンジニアリングとビジネスの両面に深く関わるはてな大西（id:onishi）が話を聞きました。構成はITジャーナリスト星暁雄です。 座談会出席者（上写真下段右より）リクルートコミュニケーションズ村上大輔さん、金
概要 背景・目的 関連研究 提案手法 実験 アルゴリズムの説明 順位相関の確認 定量評価 定量評価の内訳 定性評価 おわりに 参考文献 DROBEで機械学習エンジニアをしております、藤崎です。 概要 ファッションアイテムを特徴づけるための情報として、画像とテキストがある。これらは異なる情報を含んでいると考えられる。 類似のファッションアイテムを検索する場面で、画像とテキストの情報を両方活用することで、検索の精度を向上させることができると推測される。 類似のファッションアイテムを検索するタスクで、両方の情報を活用した提案手法の性能を評価し、片方の情報だけを活用するよりも、大幅に性能が改善することを確認した。 背景・目的 この記事は以下の記事の続編です。 tech.drobe.co.jp 以前の記事で、私たちはプロのスタイリストが作成した評価データセットを用いて、複数のアルゴリズムを類似商品検
クックパッドの海外展開プロダクト開発ノウハウとは（前編）～検索結果に言語や宗教が影響する。Cookpad TechConf 2017
クックパッドの海外展開プロダクト開発ノウハウとは（前編）～検索結果に言語や宗教が影響する。Cookpad TechConf 2017 アプリケーションを海外で展開するには、アプリケーションの内容それぞれの現地の言葉に翻訳すればできる。そう思われがちです。しかし、実際には言語、宗教、地域ごとのライフスタイルなどの違いによって一筋縄ではいきません。 海外展開するプロダクトの開発にはどんな困難が降りかかるのか。1月21日に都内で行われたイベント「Cookpad TechConf 2017」から、クックパッドの海外事業部でプロダクトの開発を行う滝口健太郎氏のセッション「Go Global」の内容をまとめました。 Go Global 海外事業部でエンジニアをしている滝口と申します。 いまは海外事業のヘッドクオーターがあるイギリスに住んでいて、今日はこのカンファレンスのために日本に来ました。 クックパ
生産性高くプロダクト開発に関与するためにトドケールで採用している Notion と GitHub の運用法について
弊社では、プロダクトの成長を生み出すエンジニアやデザイナーのメンバーを積極採用中です。採用情報をご確認 【技術スタック】 Figma, TypeScript, Next.js, Python, FastAPI, AWS, Terraform 【採用情報】 https://todoker.notion.site/efc2eea5eb054b6e8757fa3553af58d1
プロダクト開発体制を一挙公開〜メルカリ・エンジニア組織の大解剖〜 (2021/11/11 19:00〜)
お知らせ 2024年9月1日より、connpassではスクレイピングを禁止し、利用規約に明記しました。以降の情報取得にはconnpass APIをご利用ください。APIご利用についてはヘルプページをご確認ください。 新機能 「QRコード読み取りによる出席機能」をリリースしました。事前に入場受付が必要な場合や、受付時に参加枠などによって個別の誘導が必要な場合にご利用ください。詳しくは こちら をご覧ください。 新機能 connpass APIに新しく、ユーザーのプロフィールを取得できるユーザーAPIを追加しました。APIリファレンスは こちら を、またAPI利用希望の方は こちら をご覧ください。
Protocol Buffers によるプロダクト開発のススメ - API 開発の今昔 - | Wantedly Engineer Blog
こんにちは、Wantedly People アプリの開発をしている竹野（Altech）です。今回は、Protocol Buffers についての記事になります。 Wantedly People では、2018年に Protocol Buffers （以下、Protobuf と呼ぶ）がとあるマイクロサービスに入って以降、何度か大規模に Protobuf を使った開発をしてきました。またその経験を通じて、Protobuf には単に「型がついて嬉しい」というだけではないパラダイム的な変化があることが分かってきました。 その知見を全社に展開するため、去年「Protobuf によるプロダクト開発速習会」という会を行いました。この記事の内容は、そこで話したことの前半「Protobuf を使うと開発がどう変わるのか？」になります。 なお、Protobuf にはバイナリフォーマットとしての役割とインターフ
僕と共同創業者のSuinは2013年に起業してShouldBeeというプロダクトをPHPで作りはじめた。 起業する前にプロトタイプをPHPで1〜2週間程で開発し簡単なセールスを行ない1件の受注を獲得した。これはよい感触だと感じSuin氏を誘い起業に乗り出した。 その後もプロダクト開発はPHPで行っていたが当時はPHPに不満を感じていた。そのころの僕達は顧客数が伸び悩む原因をプロダクトの機能不足や開発速度が遅いからだと考えてしまった。後にこれはまったく検討違いな判断だったと気がつく。 本格的に顧客がつき、たくさんの利用がはじまるとPHPで作られたこのプロトタイプではフィードバックにすばやく対応できないことや、自分達のモチベーションのためにならないと考えScalaでの全面的なフルスクラッチを実施することを決定してしまった。バックエンドはScalaで記述し、フロントエンドはReact+Redux
デザイナーの帽子をかぶったわたしが、プロダクト開発するうえでスクラムチームに提供したいこと / what I want to provide to Scrum teams when developing products
Scrum Fest Fukuoka 2024の登壇資料です。 プロポーザル：https://confengine.com/conferences/scrum-fest-fukuoka-2024/proposal/19575
Introduction Webエンジニアであれば、「自分達の手で0から作ったプロダクトで世の中を変えられたらな、それで食べてけたらなー」と夢見ることがあるのではないでしょうか。 私たちは、夫婦2人で、プライベートの時間でアプリ開発と運営をしています。その過程でぶつかった壁がとてもたくさんありました。 全てのプロダクトで当てはまることではなく、あくまでも特定のケースなのでなかなか一般的な手法として展開しずらい事例が多いですが、これらの困った体験が何かのお役に立てればと思い書きました。 実際に起こったこともあれば、起こってはないが、経験から推測するとこのケースはこう対処すればいいのかもしれないと思ったこと、の両者を記載しています。本やブログなどで得た知識をそのまま紹介するというよりは、実体験に基づいた内容になっています。 人が集まるまで 作る時間が無い 困った たくさん機能開発したいが、普段
by Tobias van Schneider first appeared on my private email list. 私が「割れ窓理論」に出会ったのは、数年前、当時働いていたSpotifyの同僚が勧めてくれたのがきっかけでした。 「割れ窓理論」とは、地下鉄の落書きを消したりすることで都市の環境をきちんと整備すると、破壊行為や路上飲酒といった小さな犯罪の発生率が下がり、街に秩序を好む雰囲気が生まれるというものです。そして、それがより深刻な犯罪の発生を減少させるというのが最大のポイントです。 比較的最近のニューヨークの例を紹介しましょう。1990年代にニューヨークの犯罪発生率は劇的に下がりました。重大犯罪がこの期間アメリカ全土で28%減少したのに対し、ニューヨークは56%以上も減少しました。どうして短い間にニューヨークの犯罪発生率はこれ程大きく落ち込んだのでしょう？ 一般的に、こう
Kaizen Platform でやっている Kaizen Week というイベントについて / kaize week tokyurubykaigi 10
今回は、「クラウド会計ソフト freee」のリリースにおける学びについてまとめてみた。今後、新規にプロダクト開発を行う人や、ソフトウエアをコアとするスタートアップの人にとって参考になると嬉しい。周囲からのフィードバックをうまく活用できず、本来すべきだった仮説検証をしきれないケースというのはとても多いのではないかと思う。僕達の失敗もや苦悩などを含め、より多くのよいアイデアが力強く世の中に出ていく一助になれると嬉しい。 freee のリリースまでの間、評判は決してよくなかった freee は 2013年3月19日にリリースされた。リリースまでの間、いろいろな方に見ていただいたり、触っていただいたが、実はリリース前の freee は決して評判がよいわけではなかった。「今までの会計ソフトで十分」、「この業界は30年間変わっていない。今さら変わる訳ない」、「自動で帳簿がつくのは気持ち悪い」など、いろ
「機械学習」という技術で価値を創出する技術 〜プロダクト開発に機械学習を応用する際に考えること〜.pdf / techniques-to-create-values-with-ml-layerx-at-wi2
2023年10月21日、ARG Webインテリジェンスとインタラクション研究会（ウィッツ研究会）のセミナーにおける講演資料です。 様々なコンテンツやクラウドサービスの充実により、機械学習という技術を利用するハードルは低くなりました。一方で、機械学習を用いて価値を生み出すことは容易ではありません。プロダクト開発において「機械学習」という技術で価値を創出する技術について、バクラク請求書の実例とともにお話ししました。 https://www.sigwi2.org/cfanos3.html
プロダクト開発のモニタリングにおいて大事な4つの段階とベストプラクティス - KAKEHASHI Tech Blog
カケハシで Musubi Insight のバックエンドエンジニアをしている末松です。今回はプロダクトのモニタリングをどう進めていくべきかについて、4つの大事な段階とそのベストプラクティスを紹介したいと思います。 この記事は秋の技術特集 2024の 10 記事目です。 想定読者 モニタリングの悩みあるある モニタリングを始めるためには モニタリングにおいて大事な4つの段階 1. 【可視化】プロダクトの状況がさまざまな断面で可視化されている 【可視化】 のベストプラクティス 2. 【共有】プロダクトの状況が定期的にチームに共有・認識されている 【共有】 のベストプラクティス 3. 【検知】プロダクトが異常な状態であることにチームが気付くことができる 【検知】 のベストプラクティス 4. 【集中】チームが優先すべき指標が定まっている 【集中】 のベストプラクティス まとめ 想定読者 プロダクト
5年前に「Webだけやっていてもおもしろいものがつくれない」と思っていた僕がIoTプロダクト開発を選択したことは正しかったのかを振り返る｜kazuph
5年前に「Webだけやっていてもおもしろいものがつくれない」と思っていた僕がIoTプロダクト開発を選択したことは正しかったのかを振り返る 会社辞めました（5年ぶり2回目）。 この文章はWebだけやっていたときに「あれ、もしかしてWebだけやってても、この先おもしろくない？？」って思ってしまった僕が、IoT製品（スマートロック）を開発するために起業し、その後5年の月日を経て様々なことを経験し、そして現在退職してみて改めて客観的に振り返ったときに何を思ったかを綴ったものです。 念の為言っておくと、今だとWebだけって部分がどんどん進化していて、SPAフレームワークが成熟してきたし、クラウドベンダーもガンガンおもしろい基盤サービスつくっているし、コンテナネイティブ/サーバーレスなアーキテクチャが流行ったり、AI/MLの波が来たり、AR/VRにもはみ出し始めたりで、全然Web領域だけやっていてもお
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ChatGPTでstep by stepもロールプレイもやめたらプロダクト開発で使える精度になったよ｜MRYY
新しくプロダクト開発に入ったときにやっていること | wapa5pow blog
TypeScriptをプロダクト開発に使う上でのベストプラクティスと心得 - Qiita
なぜモダンなプロダクトチームによるリーンなプロダクト開発が必要なのか｜川嶋一矢@メルペイPM
プロダクト開発でドキュメントを書かないとどうなるか
[翻訳]LLMで1年間開発して学んだこと〜LLMプロダクト開発を成功に導くための実践的ガイド〜
詰め込み型のソフトウェアプロダクト開発は誰も得しない｜mtx2s
チーム・組織デザインの良し悪しはプロダクト開発フローの効率を左右する｜mtx2s
LLMプロダクト開発者がMac Studioを買ってローカルLLMを触るべき理由｜erukiti
プロジェクトという形態は下火になり、プロダクト開発が台頭している。IPAの調査から
【catnose】Zennを生んだ個人開発者に聞く、プロダクト開発の美学
現代におけるプロダクト開発とPHPを選定するワケ #phpkansai
メルカリなどメガベンチャーにありがちなプロダクト開発の企画フローと成果物｜田辺めぐみ
DDDでプロダクト開発をしたので振り返ってみた - JMDC TECH BLOG
プロダクトマネージャーの仕事/スキルとエンジニアとのスキルギャプ - 情熱プロダクト開発
（続）ファッションにおける類似商品検索アルゴリズムの性能評価 - DROBEプロダクト開発ブログ
スタートアップでのプロダクト開発はRailsで必要十分
個人プロダクト開発で、困った時にどうするか - Qiita
デザインとプロダクト開発における「割れ窓理論」
正しく失敗しながら進むプロダクト開発/railsdm2018
周囲に振り回されないプロダクト開発法 – freee のリリースからの学び