並び順

ブックマーク数

期間指定

  • から
  • まで

241 - 280 件 / 2194件

新着順 人気順

プロダクトの検索結果241 - 280 件 / 2194件

  • LLMプロダクト開発とはどういうものなのか?|erukiti

    LLMプロダクト開発者がMac Studioを買ってローカルLLMを触るべき理由という記事を書きました。 mutaguchiさんのツイートを見て、LLMプロダクトの開発とはどういうものなのかを知らない人も多いのかなと気づいたので、そこらへんを記事として書いてみます。 https://t.co/4WvjuuoGnC 「LLMプロダクト開発者がMac Studioを買ってローカルLLMを触るべき理由」の記事のはてブコメント見てたんだけど、ほとんど理解されてなかったのが興味深い。 ・プロプライエタリなLLMでは、ランニングコストが嵩み、これを利用したサービスは成立しづらい… — mutaguchi (@mutaguchi) April 24, 2024 商用LLM APIとローカルLLMって使い方が全然違う気がしてる。 商用LLM APIって、機微情報を送らないこと、規約違反テキストを送らないこ

      LLMプロダクト開発とはどういうものなのか?|erukiti
    • これからお前がプロダクトデザイナーとして SmartHR でヘヴィメタルする前に伝えておきたいことがある|oujimiyahara

      俺だ。SmartHR VP of ProductDesign の @ouji だ。 俺は長年 SmartHR でプロダクトデザイナーをやってきた。 長年といっても数年や十数年なんてちゃちな時間じゃねえ。お前がまだ培養液シリンダーの中を漂うボウフラだった頃から俺はイカれたエンジニアや狂った PdM(プロダクトマネージャー) と火花を散らしてきた。文字通りお互いのヘヴィメタルをぶつけて死合ってきたんだ。 あの頃の SmartHR は今ほどお行儀の良い開発体制なんてなかった。 六本木のインプラントショップで PdM と万が一にも鉢会おうものなら一触即発だった。どちらかのヘヴィメタルが使い物にならなくなるまで殴り合うはめになった。 だから俺はプロダクトデザイナーとして身を守る術を身につける必要があったんだ。 これからプロダクトデザイナーとして SmartHR でヘヴィメタルするお前に、俺が生き抜く

        これからお前がプロダクトデザイナーとして SmartHR でヘヴィメタルする前に伝えておきたいことがある|oujimiyahara
      • プロダクト開発のコミュニケーションをなめらかにする10の概念 - ドクターズプライム Official Blog

        こんにちは、ドクターズプライムの高橋(id:kyosu-ke)です。ドクターズプライムでプロダクト部門と管理部門の担当役員をやっています。 インターネットではTwitterを中心に@kyosu_keというアカウントでやっています。ユーザーIDにアンダースコアを使えるサービスが好きです。 普段は About Productという個人ブログで割と硬めで気取った文章をポストしています。ゆるいテンションで書こうと思ったのですが、途中から個人ブログ向けに書いてると錯覚してしまい、割と重い文章に仕上がりました。 これはなにか 今回はドクターズプライムで取り入れている、「プロダクト開発のコミュニケーションをなめらかにする10の概念」を紹介するポストです。 プロダクト開発に携わる職種の方はもちろん、プロダクト開発職種と関わる非開発系職種の方にも読んでいただけると、プロダクト開発系職種のメンバーとのコミュニ

          プロダクト開発のコミュニケーションをなめらかにする10の概念 - ドクターズプライム Official Blog
        • ElasticsearchとKibela APIを使ってSlackでのCSお問い合わせ対応業務を改善した話 - BASEプロダクトチームブログ

          この記事はBASE Advent Calendar 2020の11日目の記事です。 devblog.thebase.in BASE株式会社 Data Strategy チームの@tawamuraです。 BASEではオーナーの皆様や購入者様のお問い合わせに対して、Customer Supportチームが主となって対応をしています。その中でもいくつかの技術的なお問い合わせに対しては、以下のようにSlackの専用チャンネルを通して開発エンジニアに質問を投げて回答を作成することになっています。 CSチームから調査を依頼されるお問い合わせの例 これらのCS問い合わせ対応は日々いくつも発生しており、CSお問い合わせ対応を当番制にして運用してみた話 でもあるように週ごとに持ち回り制で各部門のエンジニアが対応しているのですが、どうしても調査や対応に時間が取られてしまうという問題が発生していました。 dev

            ElasticsearchとKibela APIを使ってSlackでのCSお問い合わせ対応業務を改善した話 - BASEプロダクトチームブログ
          • エンジニアのリモートワーク in BASE - BASEプロダクトチームブログ

            この記事について コロナウイルスによる社会不安の影響でこの半年でリモートワークの機運が特に都心部を中心に大きく高まってきました。 つい先日ヤフー株式会社が全社テレワークへの移行を正式発表したことは記憶に新しいです。 BASEでもコロナウイルスの感染拡大に伴っていち早くリモートワークの制度を構築し(2020年2月には全社的にリモートワークを開始)、 その制度は現在でもまだ運用されています。 また、世の中の動向やニーズの高まりもあり、リモートワークへの関心の高まりは採用の場面でも感じられるようになってきています。 我々も各種求職者の紹介サービスを利用していますが、そういったサービスではリモートワーク可・不可という選択肢しか選べない場合が多く、 結局面接に来ていただいた方に、BASEでどのようなリモートワーク制度が取られているか、今後どうなっていく予定か、 そういった内容を毎回口頭でお伝えする形

              エンジニアのリモートワーク in BASE - BASEプロダクトチームブログ
            • アジャイル開発における要件定義 〜DXプロダクト開発における要件定義の理解を深める〜 | TC3株式会社|GIG INNOVATED.

              1. はじめに 前回の「アジャイル開発プロセスの本質」(前編・後編)では、ソフトウェア・エンジニアリングの基本に従いアジャイル開発プロセスを設計していくことにより、アジャイル開発プロセスの進め方、実施する活動、作成する成果物についてなぜそうなっているのかを知り、アジャイル開発プロセスへの理解を深めました。 本記事ではその続編として、DX(デジタルトランスフォーメーション)の文脈におけるプロダクトをアジャイルに開発していくにあたり、特に要求プロセス部分に絞ってソフトウェア・エンジニアリングの基本とアジャイル開発プロセスでの対応をより詳細に解説することで、DXプロダクト開発における要件定義の理解を深めるということを目的としています。 本記事のタイトルにある「要件定義」という言葉はフェーズではなく、要求を決めるまでの活動の分類=要求プロセスという意味で使っています。この使い方の違いについては、前

                アジャイル開発における要件定義 〜DXプロダクト開発における要件定義の理解を深める〜 | TC3株式会社|GIG INNOVATED.
              • Yogibo ヒットの歩みはマーケティングの名著『確率思考の戦略論』からも理にかなった戦略だった【みる兄さんが話題のプロダクトを考察する連載・第5回】 | Marketing Native(マーケティング ネイティブ)

                事業会社のマーケティング部門に所属する匿名マーケター・みる兄さんが話題のプロダクトを考察する連載の第5回は、ビーズソファやクッションなどのリラックスアイテムで知られるYogiboを考察します。アメリカで誕生したYogiboが日本国内で着実に認知を拡大し、売上を伸ばしていったのはなぜなのか、「認知」「配荷」「プレファレンス」の観点で解説していきます。 今回のテーマは、Yogiboの日本国内の取り組みを森岡毅氏の著書『確率思考の戦略論』を参考図書として用い、そのマーケティング戦略とブランディングをひもといていきたいと思います。 2022年1月に入り、Yogiboと国内代理店契約を結ぶウェブシャークが米国Yogiboを買収してニュースになりました。SNSでも話題になっていたのでご存じの方も多いと思います。日本の販売代理店がブランド本体を買収する事例は、事業会社でサービス開発やマーケティングを担っ

                  Yogibo ヒットの歩みはマーケティングの名著『確率思考の戦略論』からも理にかなった戦略だった【みる兄さんが話題のプロダクトを考察する連載・第5回】 | Marketing Native(マーケティング ネイティブ)
                • ハッカソン的に作ったプロダクトを改善し、Firebaseを「ちゃんと」 使っていく話 / Migrate to Firebase friendly architecture

                  2019年8月2日に #serverlessosaka で発表したスライドです。

                    ハッカソン的に作ったプロダクトを改善し、Firebaseを「ちゃんと」 使っていく話 / Migrate to Firebase friendly architecture
                  • 「『撤退はしないくせに投資もしない』はインパール作戦みたいなもの」 “撤退”か“追加投資”しかない中で、プロダクトマネージャーが持つべき心構え

                    「撤退はしないくせに投資もしない」はインパール作戦みたいなもの 吉羽龍太郎氏(以下、吉羽):さてさて、あと5分ぐらいなので、最後の「プロダクトや機能を終了する」という話をして、終わりにしたいと思います。これ、僕らは散々言いますよね。もう口酸っぱく言いまくるという感じかな。 「プロダクトをやめられない」とよく聞きます。だから人が分散しちゃって勝負にならなくなっちゃうというのが、すごくありますよね。薄い人数のチームがいっぱいあって、どれも塩漬け、プラス、運用対応をちょっとだけしてみたいな。 それで、「メンバーのモチベーションが上がらないんですけど、どうしたらいいですか?」、いや、そりゃ、そんな塩漬けを運用させていてメンバーのモチベーションが上がるんだったらやり方を教えてくださいよという感じだと思います。これはもう(プロダクトを)捨てろという話だと思うんですが、それ以上の話はなにかあります? 及

                      「『撤退はしないくせに投資もしない』はインパール作戦みたいなもの」 “撤退”か“追加投資”しかない中で、プロダクトマネージャーが持つべき心構え
                    • 「プロダクトマネジャー」として成功できる人、できない人の違い

                      早稲田大学理工学部を卒業後、日本DECに就職。営業サポート、ソフトウェア開発、研究開発に従事し、1997年からはMicrosoftでWindows製品の開発に携わる。2006年以降は、GoogleにてWeb検索のプロダクトマネジメントやChromeのエンジニアリングマネジメントなどを行う。2015年11月、技術情報共有サービス『Qiita』などを運営するIncrementsに転職。17年6月より独立し、プロダクト戦略やエンジニアリングマネジメントなどの領域で企業の支援を行う。17年9月、ヘッドハンティング・人材紹介を展開するクライス&カンパニーの顧問に就任。2019年1月、テクノロジーにより企業や社会の変革を支援するTably株式会社を設立。「プロダクトマネージャーのキャリア戦略」 及川卓也のプロダクト視点 アマゾン、アップルといった米国企業や中国企業からの遅れが目立ち始めた日本企業。かつ

                        「プロダクトマネジャー」として成功できる人、できない人の違い
                      • 開発チームとプロダクトのデリバリープロセスを効率化&成果を最大化する業務を担当しているチームを紹介します

                        LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog LINEの開発組織のそれぞれの部門やプロジェクトについて、その役割や体制、技術スタック、今後の課題やロードマップなどを具体的に紹介している「Team & Project」シリーズ。今回は、LINEの様々な開発組織やプロジェクトやプロダクトのデリバリープロセスをより効果的にするプロフェッショナルが集うEffective Team & Delivery室(ETD室)を紹介します。それぞれETD室に属するDelivery Managementチームの谷川と、Lean & Agileチームの貫名に話を聞きました。 ――まず、自己紹介をお願いします。 谷川: 2018年にLINEに入社し、Delivery Management1,2チー

                          開発チームとプロダクトのデリバリープロセスを効率化&成果を最大化する業務を担当しているチームを紹介します
                        • 2022年版 みてねを支えるプロダクト開発体制

                          この記事では、以前に別記事で「みてねを支えるプロダクト開発体制」という記事の中で説明した「みてねのプロダクト開発体制」を最近になってアップデートをしたので、その詳細をお伝えします。 プロダクト開発体制については、数多くカジュアル面談や面接を行なっている中でも多くのエンジニアの皆様にご質問をいただく部分で、特に「エンジニアがどの段階から施策に入り込んで開発できるのか?」であったり「エンジニアと他職種のメンバーとの関わり方は?」など、確かに自分自身もソフトウェアエンジニアとして事業に関わるときに気になることではあるので、ここで再度整理したいと思います。 みてね開発体制のこれまでみてねの開発チームは、これまで組織規模や事業課題に合わせて複数回の大きな体制変更を行なってきました。どのような変遷を辿ってきたかを整理してみます。詳しい時期はあまり覚えていないので、年の記載はおおよそです。 2014年~

                            2022年版 みてねを支えるプロダクト開発体制
                          • 「覚悟を決めたPMは経営者感覚を持っている」 “ROI”と“機会コスト”の両面から考える、プロダクトの利益

                            自分が価値があると思うなにかをリリースしただけで満足していませんか? 曽根原春樹氏:次が4点目の経営者感覚です。すみません、全部は聞けていないのですが、先ほど及川さん(及川卓也氏)と吉羽さん(吉羽龍太郎氏)の話の中で、途中お金の話が出てきていたみたいで、やはり、キレッキレなPMたちを見ていると経営者感覚がすごいんですよね。 そういう人たちがやがて、スタートアップのCEOになったり、VCになったり、今度は他の企業のファイナンスを助ける感じで育っていったりと、人材が巡るエコシステムができている感覚が、シリコンバレーだとあるんですね。 もう少し話をしていきます。1個目ですが、自分の会社が何で収益をあげているのか、なぜ収益をあげることができるのか、みなさんはきちんと説明できますか? 当たり前じゃんと思う人もいるかもしれません。いいんです。当たり前だったら、たぶんその方はきちんと理解されていると思う

                              「覚悟を決めたPMは経営者感覚を持っている」 “ROI”と“機会コスト”の両面から考える、プロダクトの利益
                            • プロダクト開発はなぜ直観に反するのか - 弁護士ドットコム株式会社 Creators’ blog

                              この記事は、弁護士ドットコム Advent Calendar 2023の25日目の記事です。 前日は tsuchiya さんの「ログや例外についてレビューや実装時に意識していること」でした。 はじめに: 人と成りては童子のことを棄てたり インターネットの海には、不幸な開発プロジェクトの話が溢れています。例えば「とにかく言われた通りに作ればいいんだ」「スケジュールにコミットしろ」「遅れは徹夜で取り戻せ」「障害を起こしたら減給だ」など*1。 プロダクト開発に携わる人であれば、こうしたやり方が無意味どころか逆効果であることはご存知でしょうか。では、なぜこうしたやり方が提唱されてしまうのでしょうか。 それは、旧来のビジネスの常識*2に照らせば、ある意味でまっとうなやり方だからです。問題は、プロダクト開発においてはビジネスの常識が通じないことにあります。 (加えて、にも関わらず旧来の常識が押し通され

                                プロダクト開発はなぜ直観に反するのか - 弁護士ドットコム株式会社 Creators’ blog
                              • ReactプロダクトにおけるButtonコンポーネント実装の最適解を探し続けた結果

                                2023/12/13 aria-disabledの付け方を改良 2023/12/11 タイポ修正 2023/12/08 next/linkのhrefにundefinedを渡すとエラーがでるため、disabledにする方法を修正 <Button asChild ref={}>とrefを指定できてしまっていたのを修正 セミコロンをつけないように 2023/12/07 タイポ修正(priamry -> primary) import { cloneElement, forwardRef, isValidElement } from "react" import styles from "./style.module.css" import clsx from "clsx" export type ButtonProps = { variant?: "primary" | "secondary"

                                  ReactプロダクトにおけるButtonコンポーネント実装の最適解を探し続けた結果
                                • なぜプロダクト開発のツールとしてNotionとGitHubでは不十分なのか | wapa5pow blog

                                  ここ数年、NotionとGitHubという組み合わせでプロダクト開発をしています。 ただ、両者が提供している機能をあわせても効率的に開発する上で足りていないなという点がでてきているので何が足りないかを明らかにし改善策を提案したいと思います。 Notion + GitHubだと何が足りないのか 前提として、アジャイル開発(Scrum開発)をしており各ツールは以下のように使用しています。 タスクがNotionとGitHubのIssueにわかれて入れられておりScrum開発で言うすべての開発アイテムがプロダクトバックログに入っている状態ではないです。 ロードマップやスケジュールはNotionで管理されていますが、Notionがデータベースのアイテムを階層化することができないのでタイムライン(ガントチャートのようなもの)でみたときにタスクとサブタスクがどのように紐付いているかわからず、スケジュール

                                    なぜプロダクト開発のツールとしてNotionとGitHubでは不十分なのか | wapa5pow blog
                                  • 設計を議論する会を作ったらプロダクトの設計品質は上がりチーム全体の設計力が上がりました

                                    こんにちは。Magic Momentの髙橋です。 現在Magic Momentではチーム全体でプロダクト品質の向上と設計力の向上に積極的に取り組んでいます。 もちろんMagic Momentのエンジニアは技術力向上に貪欲で、自分たちで勉強会をしたり新しい技術の使い所について議論をすることが本当に大好きだと思います。しかし個人の日々の勉強ではなかなか得られない経験というのが「顧客向けに作るサービスの設計」だと思います。 いくら自社サービスを作っているMagic Momentであっても、すべてのエンジニアが等しくすべての設計の経験ができるとは限りません。そこで少しでも設計の経験を積んでもらい、それがプロダクトの品質向上にも貢献するような取組をはじめました。 それが「Product Development会」という設計を議論する会議体を作ったことです! ここからは「Product Develop

                                      設計を議論する会を作ったらプロダクトの設計品質は上がりチーム全体の設計力が上がりました
                                    • SQLとMarkdownで洗練されたデータプロダクトを構築できるBiツールOSS・「Evidence」

                                      EvidenceはSQLとMarkdownで洗練されたデータプロダクトを構築できるBiツールOSSです。MITライセンスの元でソースコードが公開されています。 従来のD&DによるBiツールではなくコードベースとなっており、データアナリストが信頼性が高く価値のあるレポートを提供できる事を想定したものとなっているそうです。 コードベースにする事で、アナリストがダッシュボードにチャートやフィルタをD&Dで作業するよりも、より活用度の高いワークフローをアナリストに提供できるようになるのだそう。 そのため、利用にはSQLとMarkdownの知識が前提条件となっています。D&D仕様のBiツールに使いにくさを感じている方はご覧になってみては如何でしょうか。 Evidence

                                        SQLとMarkdownで洗練されたデータプロダクトを構築できるBiツールOSS・「Evidence」
                                      • プロダクトに眠る時限爆弾「UX負債」との向き合い方

                                        デザインにもある『負債』 作ってから指標を考えるのではなく、何を計測すべきか事前に決めたほうがデザインがしやすくなります。作る目的がハッキリしますし、目的に沿った デザインフィードバックができるのもメリットです。 プロダクト / サービスの成長のためには、適切な指標をもつことが必須です。しかし、すべての施策が計測できるわけではないのが悩ましいところです。例えば「ボタンの一貫性を整える」といった施策に取り組んだところで、クリック率は上がらないですし、ユーザーテストをしても判断が難しい場合があります。 だったらすぐにユーザーインパクトのある施策をしたほうが良いということになって後回しになりがち。こうした『しっかり考えて作ったほうが良いけど、優先順位が落とされてしまう施策』はたくさん眠っています。他にも大事なことがあるのは間違いありませんが、放置しておくとだんだんプロダクトの『負債』が溜まってい

                                          プロダクトに眠る時限爆弾「UX負債」との向き合い方
                                        • なぜプロダクトマネージャーが打ちのめされて、辞めていくのか “プロダクトマネージャー万能説”の裏にある誇大広告

                                          日本では、常にエンジニアが不足していると言われます。特にエンジニアの知識を持ちながらマネージメントもする人が足りてないと言われます。そこで、『エンジニアリング組織論への招待』著者の広木大地氏に、日本の企業におけるプロダクトマネージャーの重要性、そして今の日本のエンジニア組織に必要なものについてうかがいました。最後はプロダクトマネージャーのキャリアについて。前回の記事はこちら。 問題を解決したいと思ったら何を使うか 藤井創氏(以下、藤井):時間が迫っているのでこれが最後になります。キャリアとしてのマネジメントについてうかがいたいと思います。マネジメントのところで、プロダクトマネジメントなどいろいろな言葉がありました。もしそれを自分が任された時に、どのようなことに気をつければいいのか、どのようなことを考えればいいのか、教えてください。本を読めばわかるのですが(笑)。 (一同笑) 広木大地氏(以

                                            なぜプロダクトマネージャーが打ちのめされて、辞めていくのか “プロダクトマネージャー万能説”の裏にある誇大広告
                                          • Amazon Elasticsearch ServiceによるECSアプリケーションのログ解析基盤の構築 - BASEプロダクトチームブログ

                                            こんにちは、BASE BANK 株式会社 Dev Division でエンジニアとしてインターンをしている前川です。 今回、Amazon Elasticsearch Service(以下、Amazon ES)による、ECS/Fargate で稼働するアプリケーションのログデータの解析基盤を新規で構築することになったので、構築するにあたって調査した内容や関連する内容、実際におこなった構築方法についていくつか紹介します。 今回の構築の簡単な全体構成図は次のようになります。 今回は、 ECS/Fargate のログを S3 にルーティングする Amazon ES にログをルーティングする VPC アクセスの Amazon ES を構築し、Kibana を外部からアクセスできるようにする の3つの手順にわけて、構築方法や関連する内容について紹介していきたいと思います。 なお、この記事で取り扱ってい

                                              Amazon Elasticsearch ServiceによるECSアプリケーションのログ解析基盤の構築 - BASEプロダクトチームブログ
                                            • S3 + API gateway + Lambda (+ Aurora) による Serverless 申請フォームの構築 - BASEプロダクトチームブログ

                                              はじめに はじめまして、CSE (Corporate Solution Engineering1)の上野です。 今回は BASE Partners という事業で使用していた Google フォームを S3 + API gateway + Lambda (+ Aurora) を使用した Serverless 構成のフォームに移行するというプロジェクトについてお話します。 変更前の構成図と構築した構成図としては以下のようになります。 変更前 変更後 BASE Partners について BASE では新規のショップオーナー様を紹介・支援いただくオフィシャルパートナーを募集するパートナープログラムを運営しています。 それらの申請には初期的には Move fast に行うため、Google フォームと Google スプレッドシートが使用されていましたが、ありがたいことにパートナー様やご紹介いただ

                                                S3 + API gateway + Lambda (+ Aurora) による Serverless 申請フォームの構築 - BASEプロダクトチームブログ
                                              • プロダクトの理想と現実はなぜ乖離してしまうのか? 開発者、営業、リリースそれぞれの問題とPMが取れる対処法

                                                政府や自治体を巻き込むプロジェクト、金融や証券など法務が複雑なプロダクトなど、個人開発とは違った視点が必要になる大規模なPM事例をシェアする「コロナワクチン予約システム開発秘話~国や自治体のプロジェクトを語ろう~【開発PM勉強会vol.11】」。ここで株式会社Timersのすずけん氏が登壇。プロダクトの理想と現実の乖離が起きてしまう理由と、その対策法を紹介します。 すずけん氏(以下、すずけん):簡単に自己紹介します。鈴木健太郎といいます。Twitterは「すずけん」という名前でやっています。39歳です。新卒はWebディレクターからスタートして、今はTimersという会社でLead Product Managerを務めています。(スライドを示して)このあたりが会社の遍歴です。 私の担当している運営サービスを簡単に紹介します。Timersでは「Famm」という子育て家族向けのサービスを運営して

                                                  プロダクトの理想と現実はなぜ乖離してしまうのか? 開発者、営業、リリースそれぞれの問題とPMが取れる対処法
                                                • BASEの長期間プロジェクトでのチーム開発について - BASEプロダクトチームブログ

                                                  ServiceDev所属、サーバサイドエンジニアの栗田です。 現在私は、ServiceDevのチームに所属し、ネットショップ作成サービス「BASE」及びショッピングアプリ「BASE」の機能開発を担当しています。 BASEでは主にQ毎にプロジェクトチームを編成し、チームで主体となって機能開発を行っていきます。 チームメンバー構成はプロジェクトの特性や規模により様々ですが、多くの場合、同じグループから1〜2名がプロジェクトにアサインされます。 今回はとある長期間プロジェクトで感じた事や・実際にこのように進めたよというところをサーバサイドエンジニアの視点から紹介したいと思います。 どんなプロジェクトだったか 今回紹介するプロジェクトは「BASE」の拡張機能である「BASE Apps」の1つである「商品オプション App」を開発するプロジェクトでした。 「商品オプション App」は商品にギフトラッ

                                                    BASEの長期間プロジェクトでのチーム開発について - BASEプロダクトチームブログ
                                                  • 進撃のプロダクトマネジメント|坪田 朋

                                                    僕がサービス開発で意識している心得や考え方をざっと書いてみたので、プロダクトマネジメントの参考になると嬉しいです。 プロダクトマネージャ(PdM)として意識していること先ず実行し、同時に深く考えていく 新規サービス・新機能立ち上げ期は、色んなアイディアが出てくるので、ブレがちだけど、自分のスタイルはとにかく早く作って、自分達で触って感覚掴んで、顧客に使ってもらった感想を聞くことを大事にしてる。 — 坪田 朋 / クラシル (@tsubotax) October 23, 2021 新しい取り組みの時は、先ず形にして行動しながら考えを深めるを強く意識します。 例えば、新しい機能を検討する時は、先ずデザインを起こし、ユーザーニーズを把握する時はそのデザインを見せながら意見を聞き、手触り感を重視する機能ならモックアップを作って触りながら考えを深めてく事にしている。 長い期間計画してもプロトタイプを

                                                      進撃のプロダクトマネジメント|坪田 朋
                                                    • 開発チームが会社のプロダクトビジョンと足並みをそろえる4つのルール【テッククランチ】

                                                      寄稿者 Sanjoy Singh(サンジョイ・シン) インド企業Talentica Softwareのエンジニア担当副社長。アーリーステージ、グロースステージのスタートアップ50社超のスケーラブルプラットフォーム構築をサポート。 ソーシャルニュースサイトを運営する米Diggの共同創業者で、ベンチャーキャピタリストでもあるKevin Rose(ケビン・ローズ)氏はかつて、「A team aligned behind a vision will move mountains. (ビジョンに沿っているチームは山を動かす。)」と言った。これは真理だ。成功するプロダクトを生み出すにはあらゆる不確実性を乗り越えなければならない。そのためには明確なプロダクトビジョンが必要だ。 開発チームがプロダクトビジョンに沿っていれば、意思疎通が容易になり、チームメンバーに意思決定権を委ねられる。すると、主要関係者へ

                                                      • エンジニアが推進するプロダクトマネジメント | Qiita Conference 2023|小城久美子 / ozyozyo

                                                        Qiita Conference 2023で登壇の機会をいただきましたので、登壇内容を一部noteにもしておきます。登壇資料は最後に貼ってあります。 前提プロダクトマネジメントはUX、Tech、Businessの交差領域であり、各々の専門性が重なるというのが基本概念のはずです。(左)しかし、プロダクトマネージャーという職種が増えてきた結果、分業したままなんとかプロダクトマネージャーがその糊となって繋げている組織をみることがあります。(右) プロダクトマネージャーではなく、プロダクトマネジメントは各領域の専門家が集まるチームでやっていきましょう。プロダクトマネージャーはその旗を降る人であって一人でプロダクトマネジメントをするわけではありません。 エンジニアがプロダクトづくりを推進するためには、Tech x UXやTech x Businessの領域に積極的に手をだして重なりをつくっていきまし

                                                          エンジニアが推進するプロダクトマネジメント | Qiita Conference 2023|小城久美子 / ozyozyo
                                                        • 「Honoはあくまでオープンソースプロダクト」開発者でコントリビューターの私が会社員になった理由 - Findy Engineer Lab

                                                          ▲ YAPC::Asia Tokyo 2013でベストトーク賞1位を獲得し表彰される和田裕介さん(写真提供:Japan Perl Association) エッジコンピューティング環境に適したWebフレームワークとして注目を集める「Hono」の開発者として知られる和田裕介(@yusukebe)さん。大学院卒業後に就職の道を選ばず起業し、その後は17年にわたりフリーランスのエンジニアとして活躍してきましたが、2023年4月に初めて就職しました。 世界最大級のCDN(Contents Delivery Network)プラットフォームを提供するCloudflareが「Hono」に注目し、和田さんをスカウトしたことがきっかけです。Cloudflareに入社した和田さんはサーバレス環境「Cloudflare Workers」上での開発者体験(Developer Experience)の向上を職務と

                                                            「Honoはあくまでオープンソースプロダクト」開発者でコントリビューターの私が会社員になった理由 - Findy Engineer Lab
                                                          • 君のプロダクトはビタミン剤か?鎮痛剤か?それとも治療薬か? デザイン会社 ビートラックス: ブログ

                                                            プロダクトやサービスのアイディアを考える際に最も重要とされているのが「ユーザーの課題解決に繋がるか」という点。これは、どう考えても正しい考え方な気がする。だって、そもそも課題を解決してくれないサービスなんていらないし、お金も払う気にもならない。 と、思いがち。でも現実は大きく異なる。 意外と課題を解決していないヒットサービスが多い現在大ヒットしているプロダクトのその多くが、実は元々あった課題の解決をしていないのだ。まさかと思うが、下記のようなサービスは、ユーザーのどんな課題を解決したのだろうか? FacebookYouTubeTikTokそう。どうしても解決してほしい課題があったわけではない。でも、使い始めたらなぜか使い続けてしまう。これらのサービスは、課題を解決していないのに、新たな習慣を通じ、ユーザーに大きな価値を生み出した。 これこそがプロダクトやサービスを考える際の大きな盲点。 特

                                                              君のプロダクトはビタミン剤か?鎮痛剤か?それとも治療薬か? デザイン会社 ビートラックス: ブログ
                                                            • RailsプロダクトへのWebAuthn導入に向けての取り組み - 虎の穴開発室ブログ

                                                              皆さんこんにちは、とらのあなラボのY.Fです。 先日、弊社エンジニアが開発で関わっているCreatiaで、以下のお知らせが投稿されました。 【新機能のご案内】#クリエイティア にて、『パスワードレスログイン』機能をリリースいたしました。 パスワードの代わりに指紋や顔認証、PINコードを使って、スムーズかつ安全にクリエイティアにログインできるようになりました! ▶詳細は下記記事をご参照くださいhttps://t.co/FzsVIAl7Sp— クリエイティア[Creatia]@ファンクラブ開設費無料! (@creatia_cc) 2023年6月8日 弊社のサービスは、とらのあな通販やサークルポータル除いて、ほぼRuby on Railsを利用しています。 speakerdeck.com 今回の記事では、Ruby on Rails + WebAuthnについて、調べたことなどをまとめてみたいと思

                                                                RailsプロダクトへのWebAuthn導入に向けての取り組み - 虎の穴開発室ブログ
                                                              • 「入門 監視」社内輪読会から1年経過して 〜参加メンバーの意識の変化と今後〜 - BASEプロダクトチームブログ

                                                                はじめまして。 BASE株式会社 SRE Groupに所属している富塚(@tomy103rider)です。 先日、弊社CTOが 「もうさばき切れない」アクセスが激増したECプラットフォームにおける負荷対策 https://devblog.thebase.in/entry/bsucon という記事を公開しました。 社内ではこのアクセス激増をきっかけに「サービスの監視をどうしていくか」「サービス/システムのアラートに対してのアクションはどうあるべきか」といったような監視に関する話題も改めて盛り上がっています。 そんな中でふと1年くらい前にBASE BANK 株式会社の東口 (@hgsgtk)が社内で主催した「入門 監視」輪読会に参加したことを思い出し、その輪読会がどういう会だったかなど、改めて輪読会を振り返ってみようと思います。 「入門 監視」輪読会の目的は何だった? この輪読会を開催するにあ

                                                                  「入門 監視」社内輪読会から1年経過して 〜参加メンバーの意識の変化と今後〜 - BASEプロダクトチームブログ
                                                                • Docker Desktop有料化対応をするときに知りたかったこと - BASEプロダクトチームブログ

                                                                  はじめに こんにちは。Product Dev Division でエンジニアリングマネージャーをしている@tac_tandenです。 Docker Desktop 有料化の移行期間が終わって約 3 ヶ月が経ちましたが、皆さまいかがお過ごしでしょうか? 旬の時期は過ぎている気もしますが、BASE 社内で行った Docker Desktop の有料化移行をする中で得た知識や知見を改めてまとめたので、テックブログで公開させていただくことになりました。 有料アカウント購入の運用フローや社内の予算案の作成を担当した当時の自分が、最初から知っていればあんなに苦労しなかったのに!というのを主にまとめています。 なので、想定される読者の方としては以下の通りです。 Docker Desktop の有料プランを購入予定だが、どういう基準で選んでよいのかわからない 近い将来、有料プランの購入条件に該当しそうなの

                                                                    Docker Desktop有料化対応をするときに知りたかったこと - BASEプロダクトチームブログ
                                                                  • Vue.jsでWebの多様なユーザー/利用シーンに対応していくための公開素振り - BASEプロダクトチームブログ

                                                                    この記事はBASE Advent Calendar 2019の15日目の記事です。 こんにちは。フロントエンドグループの加藤です。 私達は、「Payment to the People,Power to the People.」というミッションを掲げ、日々サービスづくりを頑張っています。 Peopleとは誰か このミッションにある、Peopleとは誰のことを指すのでしょうか? 自分の周りの環境を想像しても、実に多様な人がいることがわかります。 また、日々ショップオーナーさんや購入者さんからいただく様々なお問い合わせの内容を見ていると、ほんとに様々な背景を持った方々に使っていただいているんだなと思います。 Webフロントエンド開発者としては、自分の力で出来ることがあれば、出来る限り多様な使われ方に対応できるプロダクトにしていきたいという思いがあります。 何を指針とするか では、まず何をどうす

                                                                      Vue.jsでWebの多様なユーザー/利用シーンに対応していくための公開素振り - BASEプロダクトチームブログ
                                                                    • GPT-3.5に画像分類タスクを解かせる - DROBEプロダクト開発ブログ

                                                                      概要 背景・目的 関連研究 提案手法 実験 終わりに 参考文献 DROBEで機械学習エンジニアをしております、藤崎です。 概要 ファッションの分野ではトレンドの変化とそれに伴う属性情報の変動に対応するため、画像分類AIモデルを頻繁にアップデートする必要性がある。 しかし、既存の画像分類AIモデルのアップデートには、労力と時間が掛かる。 様々なタスクの遂行能力が高いGPT-3.5に画像処理能力を付与し、画像分類タスクに挑戦した。 既存の研究(ex. HuggingGPT)と違って、GPT-3.5自体が画像分類の推論を行う点がユニークである。 実験からは有望な結果が得られた。 今後の性能向上はプロンプトを工夫するなど、比較的簡単な方法で達成できる可能性がある。 背景・目的 ファッションの業界は、トレンドの変化が早く、新しいスタイルが次々と提案されます。それに伴い、スタイルに付随する属性情報も常

                                                                        GPT-3.5に画像分類タスクを解かせる - DROBEプロダクト開発ブログ
                                                                      • プロダクトを分割してマネジメントする|小城久美子 / ozyozyo

                                                                        ロードマップやプロダクト指標(NSM)を設計するとどの単位でこれらを検討すればよいのか?という悩みを持つことがあります。今日は私の考えるプロダクトの分割についてです。 ※ 「プロダクト」の分割について記載しており、「チーム」の分割については触れません 機能でプロダクトを分割しないプロダクトが大きくなるにつれて検討事項が増えるので人を増やしてプロダクトを分割することを検討します。このときのアンチパターンは「機能」でプロダクトを分割してしまうことです。 機能でプロダクトを分割した末路: 蛇足のダソくんこの絵は極端な例となりますが、とても優秀な「ヒレ」機能の担当者がいると、「ヒレ」機能だけが華美になり結果としてプロダクトの全体価値を損ないます。 価値でプロダクトを分割するプロダクトを価値で分解するプロダクトは提案する「価値」で分割しましょう。ただ、分割するときに、それが大きな価値なのか、その大き

                                                                          プロダクトを分割してマネジメントする|小城久美子 / ozyozyo
                                                                        • QAという言葉を正しく理解して使っていますか - BASEプロダクトチームブログ

                                                                          こんにちは! Process Engineeringグループのセキネです。 入社してからQAという言葉が社内で頻繁に使われることが多いのですが、どうも違和感を感じて今回の内容を社内で共有したところ結構反響があったので紹介したいと思います。 そもそもQAって言葉どういう意味で使っていますか? 実は結構前から社内では人によってQAという言葉の認識が異なっているように思います。 QAという便利な言葉によって認識の齟齬が起きているような話をちょくちょく聞くようになりました。 誤った認識や、認識の齟齬が起こらないようにしていく必要があります! QA(Quality Assurance) 日本語訳的には品質保証 QA ≠ テストです!!!(テストも含んではいますが、イコールではないです) もし、 QA=テストとして使っている人がいるのであれば少し認識を改めていただいた方がよいかもしれません。 品質保証

                                                                            QAという言葉を正しく理解して使っていますか - BASEプロダクトチームブログ
                                                                          • イケてるプロダクトマネージャーは何を大切にしているのか? | ユニコーン転職日記

                                                                            僕が愛する職種である「プロダクトマネージャー」って、日本国内では未だに役割の定義が曖昧なところがあって、こういうツイートをしたんです。 自分が今20代ならオススメの職業はやはりソフトウェアエンジニアがおすすめ。メルカリ時代に新卒の面接で「PMかエンジニアどちらからキャリアをスタートすべきか」と何度か聞かれたけど、世界基準ではプロダクトマネージャーはコンピューターサイエンスの学位やエンジニアの経験が必須の職種。 — たいろー / メルカリ→スマニュー🦄 ユニコーン転職日記 (@tairo) May 13, 2020 これ要するに プロダクトマネージャーは技術への理解がかなり求められるよしたがって、新卒でいきなりPMは相当無理があるよPMかエンジニアかで迷うならエンジニアから始めようね ということなのですが。 でも、じゃあ「イケてるプロダクトマネージャー」って一体、何をしているのでしょうか?

                                                                              イケてるプロダクトマネージャーは何を大切にしているのか? | ユニコーン転職日記
                                                                            • CTOがプロダクトマネジメントに本気で取り組んで見えてきたエンジニアリング組織のセオリー|kotamat

                                                                              CTOとしてプロダクトマネジメントに軸足を置いてから半年ほど経過し、エンジニアリングマネジメントの観点で新しい気付きがうまれてきたので、記事にしてみる。 この記事で述べることこの記事では、back checkでプロダクトマネジメントをする上で試行錯誤してきた内容を踏まえ、プロダクトマネジメントを遂行する上で必要な人のアサインとキャリアについて言及していこうと思う。 まずは「back checkがプロダクトマネジメントの観点でどういう課題に直面したか」を述べた上で、「組成した新規チームのミッションとアサイン」を述べ、そこから学んだことを述べる。 その上で、一個抽象化し、「プロダクト運営上発生する不確実性」を述べた上で、「適性をもとにしたエンジニアリングマネジメントのセオリー」を考えていく。 プロダクトマネジメントでやってきたこと自分がback checkのPMとしてジョインしはじめたのは20

                                                                                CTOがプロダクトマネジメントに本気で取り組んで見えてきたエンジニアリング組織のセオリー|kotamat
                                                                              • 『金属製の名刺入れは失礼』ネットで調べたら謎マナーが書かれていたが金属加工業に失礼では?「想いのこもったプロダクトが愛されるようになることが一番」

                                                                                ドクター・べじぱみゅ @dr_vegepamyu ネット調べたら「金属製の名刺入れは失礼」とかいう謎マナーを説いたページがあった。「相手はちゃんと革製使ってるのにこっちが金属だとチープな印象」だと。相手の名刺入れなんか凝視しないし、さらに金属材料にちょっと携わる者として「金属はチープ」とは何事か。お前のページが金属屋に失礼だ。 2020-07-27 07:24:39 ドクター・べじぱみゅ @dr_vegepamyu 金属屋が日々どんな思いで小さな欠陥やワレの兆候を調べて、それを取り除いてお客様に快適に使ってもらうにはどうすればいいか昼夜悩んでいるかを知っているのか。それを「チープ」とかいう一言で片付けることについて意図の説明を求めたい。じゃお前今日から電線も筐体も、金属一切使うなよ。 2020-07-27 07:28:13 ドクター・べじぱみゅ @dr_vegepamyu 大阪のハイパーパ

                                                                                  『金属製の名刺入れは失礼』ネットで調べたら謎マナーが書かれていたが金属加工業に失礼では?「想いのこもったプロダクトが愛されるようになることが一番」
                                                                                • ドメイン知識をフル活用した「あと払い(Pay ID)」の新規開発 - BASEプロダクトチームブログ

                                                                                  導入 BASEでは、2023年3月頃に「あと払い(Pay ID)」というBNPL(Buy Now Pay Later)のサービス提供を開始しました。BNPLとは、いわゆる後払い決済のことで、今回、BNPLのシステムを一部内製化した上で、世の中にリリースしました。BASEとしては「決済手段を内製化する」ための第一歩であり、ありがたいことに国内の決済業界で、少しばかり話題になりました。 リンク先:2023/4/11 日本経済新聞 今回は、BNPLという決済システムの開発において、どのような困難があり、どう克服していったのかについて、開発に携わったPay IDチームのエンジニアの視点で書きます。※ なお、このテックブログの読み手として2つのセグメントを想定しています。 ドメイン知識が複雑なアプリケーションを開発をする人 決済システムの仕事に携わる業界の方々 先に結論を書くと、伝えたいことは「ドメ

                                                                                    ドメイン知識をフル活用した「あと払い(Pay ID)」の新規開発 - BASEプロダクトチームブログ