並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 638件

新着順 人気順

PMFの検索結果1 - 40 件 / 638件

  • 仕様書の参考例と、こんな内容を仕様書に最低書くといいというお話|田辺めぐみ

    よく、仕様書を書いていなくて、書いてみたいけど、具体的な仕様書がネット上に落ちてなくってこまってるって相談を受けるので 「仕様書の記載内容のイメージ」を作りました! ※前提として「現在仕様書を書いていない、自社開発のMVP検証前後のフェーズのスタートアップ向け」に書いています。PMが仕様書、エンジニアがDesign Docを書く分担です。 ついでに、システム開発の基礎である「システム開発のV字モデルをベースにした設計書の紹介」も含めてまとめてみましたー! 大規模開発に使われたり、古くからあるフレームワークなので、スタートアップの方だと、システム開発のV字モデルの概念やそれにあわせた成果物を知らない人が多いけど、「要件定義書」と「設計書」を全てドキュメント化するとどうなるかを理解した上で、「仕様書」として情報を削る方が、考慮漏れ防止やエンジニアがやっている設計内容の理解につながるので、全体を

      仕様書の参考例と、こんな内容を仕様書に最低書くといいというお話|田辺めぐみ
    • プロダクトマネジメント入門: 失敗しないプロダクトの作り方を学ぼう

      Founder Customer Fitこのセクションについて解決したい課題を見つけよう顧客を決めようリーンキャンバスを書こうミッションを決めようCustomer Problem Fitこのセクションについてペルソナを立てよう共感マップをつくろうカスタマージャーニーマップをつくろう課題仮説を整理しようプロブレムインタビューをしようProblem Solution FitこのセクションについてPEST分析をしようフックモデルを定義しようプロトタイプをつくろう解決策仮説を整理しようソリューションインタビューをしようSolution Product Fitこのセクションについて名前をつけようユーザーストーリーマップをつくろうMVPを構築しようMVP仮説を整理しようMVPインタビューをしようProduct Market Fitこのセクションについてグロースサイクルを定義しよう利用規約をつくろうプロ

        プロダクトマネジメント入門: 失敗しないプロダクトの作り方を学ぼう
      • 新規事業立ち上げのアンチパターン|福島良典 | LayerX

        新規事業立ち上げのアンチパターンについて考えてみる。 このアンチパターンは、完全な飛地の新規事業だけではなく、複数プロダクトを経営する中での隣接領域の新規プロダクトの立ち上げのときや、あるセグメントにPMFした状態から次のPMFを探すときも同様のアンチパターンが適用されうる。 ここでのアンチパターンは、1つ目の事業立ち上げ・プロダクト立ち上げで起こることはない。2つ目の事業や2つ目のプロダクトを立ち上げる際に留意する点であり、コンパウンドスタートアップを正しく経営するには必ず頭に入れておきたい内容である。 規模からの逆算と顧客インサイトの軽視新規事業における市場選択のアンチパターンである。 例えば、売上の30%成長を続けるための、計画と現実のギャップを埋めるために新規事業を規模から探してしまうみたいなケースで見られる。 大前提として、市場規模の推定は重要である。実際に事業をやっていると、い

          新規事業立ち上げのアンチパターン|福島良典 | LayerX
        • 米国でスタートアップの要職をやってたけどレイオフされてしまった話|井上恭輔(きょろ)

          気づけばもう半年以上前の話になりますが、2024年5月、Interim CTOやSoftware Architectとして頑張って働いていた米国でスマートホームを開発するスタートアップ「HOMMA」からレイオフされ、事業を離れることになりました。入社時の夢いっぱいのブログエントリーはこちらからどうぞ。 ※ この記事は退職エントリーです。興味のある方だけお読みください。 何を作っていたの?最終的にどんなものを作ってたの?と思われると思うので、開発したプロダクトのデモを貼っておきます。ちなみに、この動画を作ったのも自分です。私物のBlackmagick Pocket Cinema Camera 4Kを持ち込んで、ポートランドの寒空の下、1人で撮影&編集しました。 タッチパネルが壁一面にあったり、音声クライアントやアプリで操作するドヤ!っとしたスマートホームではなく、埋め込まれたセンサーが人間の

            米国でスタートアップの要職をやってたけどレイオフされてしまった話|井上恭輔(きょろ)
          • 累計4億円調達したシリーズAのスタートアップやってたけど破産したヨ|Yutaro Higashi

            こんにちは、教育系のスタートアップでCTOをしていたヒガシ(@suica_versa)と申します。 表題の通り、私は約6年前から教育機関向けのシステム開発を行うスタートアップでCTOとして働いていましたが、7/10付けで破産開始決定が申し渡されました。 破産に伴い、取引先をはじめ関係各所には大変なご迷惑をおかけしていることを経営メンバーの一人として、謝罪いたします。 このnoteでは、なぜ破産に至ったのか?破産の手続きってどういう内容?破産するとどうなる?という、スタートアップではなかなか語られない点について同じ轍を踏まないよう共有いたします。 ただし、まだ本件については進行中ですので、ある程度内容は省いている点をご容赦ください。 【免責】 当記事は私が所属していたDoorkel社の正式な文章ではございません。内容については時系列含め不正確なものも多々ございますので、あくまで1社員の視点か

              累計4億円調達したシリーズAのスタートアップやってたけど破産したヨ|Yutaro Higashi
            • 事業開発者・プロダクトマネージャーが知っておくべきフレームワーク7選|Shin

              プロダクトマネージャーという仕事はビジネス・デザイン・エンジニアすべてのスキルが求められる総合格闘技のような仕事です。その分、やることも多く忙しくなりがち。 しかし、再現性の高いプロセスというのは仕事が変わってもそのまま活用できます。その代表例がフレームワークです。 今回は世の中に数あるフレームワークのうち、プロダクトマネージャー・事業開発者が絶対知っておいた方が良いと判断したものを厳選してみました。 プロダクトマネージャー向けフレームワーク4選1. Product Prioritization Frameworkhttps://www.product-frameworks.com/Gusto-Product-Prioritization.htmlこちらはもうプロダクトマネージャーであれば無意識に考えていてほしいくらいシンプル、かつ大事なフレームワークです。 expected:期待値の大き

                事業開発者・プロダクトマネージャーが知っておくべきフレームワーク7選|Shin
              • 事業失敗し26歳で自己破産するまでと、自己破産したらどうなるのか。について|棒線小僧

                初めまして棒線小僧と申します このnoteを読まれている方の多くは、自分で商売・事業を始めている或いは今後起業したい。という方が大半だと想定しておりますので、左記に該当しない方にはあまり刺さらない内容となっておりますが、左記の方々であれば一読の価値は一定担保出来ているのではないかなと思っております 在学中にベンチャー・スタートアップ創業からエクイティ調達・融資、組織瓦解、事業撤退→自己破産→メンタルブレイクみたいな、まあその界隈では正直よくある話ですが インターネット・SNS全体で見ると意外と開示している人は少ない(成功した後に過去の失敗談として語られることはある。ちなみに私は今も全く成功していないです)と思ったので 自己破産に至るまでの経緯と、自己破産した後の影響に関してリアルに書かせて頂きました(今はステルスで仕込んでいる事業に専念しているため、名前だし・顔出ししていないですが、上記の

                  事業失敗し26歳で自己破産するまでと、自己破産したらどうなるのか。について|棒線小僧
                • 個人開発を7年以上続けて分かった技術選択のコツ

                  個人開発を7年以上続けて分かった技術選択のコツInkdropというMarkdownノートアプリを作り続けて7年になる。 お陰さまでその売上でずっと生活できている。 これまで個人開発でどう継続していくかについて「ユーザの退会理由をあれこれ考えない」とか「アプリの売上目標を立てるのをやめました」とか、ビジネス面あるいはメンタル面からいろいろ書いてきた。 今回は、技術面にフォーカスして、どう継続して開発していくかについてシェアしたい。 TL;DR最初はとにかく最速でリリースする事を最優先する迷ったら「ときめく方」を選べ程よいところで切り上げて開発を進める使っているモジュールがdeprecatedされるなんてザラだと覚悟する古いから悪いとは限らないシンプルにしていく老舗から継続の秘訣を学ぶ運ゲー要素は排除しきれない最初はとにかく最速でリリースする事を目標に技術選定する開発計画とビジネス計画は切って

                    個人開発を7年以上続けて分かった技術選択のコツ
                  • Udemyの番人がおすすめする講座 - Qiita

                    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 私はUdmeyに年間50万??ぐらい教材に投資して常に、Udemyに貼り付いて良い講座ができるのを監視しています。その中で、最後まで講座を受講してその講座の感想を書きたいと思います。私は、優良だと思わない講座は即返金処理を行うので、ここに紹介される講座は、とてもわかりやすいものしか基本的に載せてありません。この記事は更新されていきますので、ご興味ある方はいいねとストックをお願いします。(よかったやつ証明書とかコピペしてここに貼るの正直まじでめんどくさいので、更新するモチベーションに繋がります)。下記に書いてあるものは全部、優良のものだが

                      Udemyの番人がおすすめする講座 - Qiita
                    • なぜ鬼は鬼殺隊に負けたのか?悪の組織の敗因を「組織デザイン」から分析してみる──『鬼滅の刃』『ダイの大冒険』『ドラゴンボール』|ミナべトモミ|MIMIGURI

                      今回は少年漫画に登場する「悪の組織」を分析することを通して、組織デザインについて学んでいきたいと思います。以前、CULTIBASE Radioで配信し、noteにもまとめた「少年漫画から学ぶリーダーシップシリーズ」が大変好評だったので、その組織デザイン編も書いてみた次第です。 さて、多くの漫画において、「悪の組織」は最終的に主人公やそのチームの前に敗れ去ることになります。 もちろん、主人公たちが努力の末に大きく成長したことが、悪の組織を倒す原動力になっていることは間違いありません。しかしながら、要因はそれだけではないと思っています。 「悪の組織」敗北の要因として特に大きいのが、「組織デザインの失敗」だと僕は考えています。 そこで、この記事では『鬼滅の刃』『ダイの大冒険』『ドラゴンボール』という3つの名作漫画に登場する「悪の組織」の組織構造を紐解きながら、主人公たちに敗れることになってしまっ

                        なぜ鬼は鬼殺隊に負けたのか?悪の組織の敗因を「組織デザイン」から分析してみる──『鬼滅の刃』『ダイの大冒険』『ドラゴンボール』|ミナべトモミ|MIMIGURI
                      • そのユーザーファースト、本当にユーザーファーストですか?|宇野雄 / note inc. CDO

                        こんにちは。クックパッド デザイン戦略本部長の宇野です。 いきなりですが「ユーザーファースト」って良い言葉ですよね。サービスのあり方の基本であり、モノづくりをしていてそれを無視したいという人はいないはず。 しかし僕はこのユーザーファーストという言葉をあまり使わず、使う際は慎重に取り扱うようにしています。この言葉の概念はとても難しいと考えているからです。 「ユーザー」って誰のこと?目の前にいるユーザーの話をそのまま取り入れれば必ず良いものが作れるの? 答えは明確にNoです。 当然ですが無視するべきという話ではありません。ただ、向き合ってるユーザーがどんな人なのか、その人が本当に欲しているものは何なのかを徹底的に考え抜く必要があります。 お問い合わせをしてきている人はだれ? ユーザーからのご意見やお問い合わせ、アプリストアのレビューはとてもありがたいですよね。そこから新たな改善案をもらったり、

                          そのユーザーファースト、本当にユーザーファーストですか?|宇野雄 / note inc. CDO
                        • なぜ僕が「SPAはコストが高い」と考えているのか

                          どうもみなさんこんばんは ちょっと前に「個人開発者やスタートアップの初期からSPAで開発するのはコスト高いっすよね」みたいな事を書いたらフロントエンドエンジニアの皆様からバチバチに叩かれた僕です 彼らには彼らの考えがあるのでそれはどうでもいいのですが、どういう理由があってその発言をしたのか~と言う部分が気になっている方もいたようなので説明しておこうと思います ちなみに今でも全く意見は変わっておらず、この発言に同意できるかできないかは単純に視点の違い、規模の違い、スキルの違いだと思ってます 追記: もちろんSPAじゃないと実現できないようなサービスを作りたい場合はSPA一択ですし(インタラクティブにHPつくるサービスとか。でも世の中の95%くらいのサービスはそうじゃないと思います)、サイトの利用はログインした人にだけ提供するような業務系ツールなどはまた話が別です 前提の話 こういう記事ではコ

                            なぜ僕が「SPAはコストが高い」と考えているのか
                          • ほんで、MEGA BIGくじにいくら賭ければいいの?|morio

                            この記事では、MEGA BIGくじの最適な賭け額、最適な賭け額の算出方法について説明する。 ※この記事の内容は間違っている可能性があるので注意してください。間違いがあればご指摘いただけると嬉しいです。できれば専門家にレビューしてほしいです。 ※この記事はMEGA BIGの購入を薦めているわけではありません。 MEGA BIG 祭2024/8/30、MEGA BIG祭が突如発生した。 MEGA BIGは通常期待値がマイナスであるが、台風の影響でサッカーの試合が一部中止になり第1476回のMEGA BIGの期待値が1を超える可能性があるという投稿があったのだ。 toto MEGA BIGが熱い。 対象の12試合中4試合が中止(自動的中扱い)なので、8試合分当たれば1等というレイドイベント発生。現在キャリーオーバー61億円。 公営ギャンブルとしてはありえない期待値。 なおtoto BIG/100

                              ほんで、MEGA BIGくじにいくら賭ければいいの?|morio
                            • Webアプリを作って収益化する、僕の個人開発ルーティン

                              独学で個人開発を始めて5年が経ちました。これまでには収益化に成功したサービスもあれば、鳴かず飛ばずでお蔵入りになったサービスも数多くあります。それらの経験から、成功したサービスはなぜ上手くいったのか、マーケティングや収益化において押さえておくべきことは何か、その要点が少しずつ見えるようになりました。 今回は私が開発〜集客〜収益化を行うプロセスと、各工程で気をつけているポイントを順を追って書き出してみます。上手く言語化できているか分かりませんが、暖かい目でお付き合いください。 収益化した3つのサービス 私はこれまでにWebサービスを20個以上開発しており、現在はポモドーロタイマー(月間100万ユーザー)やYouTubeのループ再生ツール(月間10万ユーザー)などを運営し、そこからの収入で生活しています。 基本は海外向けのBtoCで、以下のようなツール系が中心です: 収益化済みサービス: Po

                                Webアプリを作って収益化する、僕の個人開発ルーティン
                              • ハードワークで人は成長するか - SaaSベンチャーで働く社員のブログ

                                「成長するためにはハードワークは不可欠」。こういう言説は常に世に出ています。そして、それを信じた真面目な若者が「成長」するためにハードワークをこなすという流れ。知っているだけでも10年以上同じサイクルがあるように思います。 思いつくだけでも、サイバーエージェント創業者の藤田晋氏が著書「渋谷ではたらく社長の告白」で月に440時間働いていたという話や、テスラ創業者のイーロンマスク氏が世界を変えるためには最低でも週80時間は働くべきだと主張があったり、成功者がハードワークを乗り越えた話があります。 一方で自分自身の経験を振り返ると、必ずしも労働時間の長さが個人の成長につながったとは思えません。この認知の違いはどこからくるのか。自分自身の経験を振り返ってみたいと思います。 自分自身の労働時間経験 ハードワークだが成長しなかった経験 ワークライフバランスを保ち、成長した経験 成長の定義を「今できない

                                  ハードワークで人は成長するか - SaaSベンチャーで働く社員のブログ
                                • カイ二乗検定は何をやっているのか|コグラフ株式会社 データアナリティクス事業部

                                  こんにちは。コグラフ株式会社データアナリティクス事業部の塩見です。 私は「カイ二乗検定」に対して、当初は納得できない部分がありました。やりたいことに対して、必要以上に複雑な手法のように感じたからです。同じような疑問を持つ方も多いのではないでしょうか。この記事では、私が「カイ二乗検定」を理解し納得するまでの過程をお伝えします。 結論から言いますと、一度頻度論を離れてベイズ統計の視点で考えてみたところ、実は非常に単純なことを行っていると気づきました。その後、カイ二乗検定を再び考え直すと、すんなり理解できたというお話です。 カイ二乗検定の手順まず、サイコロを何度も投げ、出た目の回数(実測値)を記録します。偏りのないサイコロでは、全ての目が均等に出るはずです。この理論的な回数を理論値と呼びます。 次に、実測値と理論値の差を計算し、その差を二乗してから理論値で割ります。この計算結果を「ズレ」と呼びま

                                    カイ二乗検定は何をやっているのか|コグラフ株式会社 データアナリティクス事業部
                                  • SaaS系スタートアップのリアルなAWSアーキテクチャ設計

                                    概要 AI革命のインフラを目指すSaaS系スタートアップのFastLabel(最近資金調達しました!記事はこちら)で働いているが、今までGCPで動かしていたインフラを訳あってAWSに基盤を載せ替えることになった。 スタートアップは何よりスピードが求められるが、だからといってセキュリティやモニタリング、可用性を疎かにはできないし、大きなインフラコストに耐えられるほど体力もない。 アプリケーション要件を満たしつつ、以下を実現するアーキテクチャを設計する。 シンプルな構成・構築の容易さ スピーディな開発・適用 可用性の担保 セキュリティの担保 最低限のモニタリング 低コスト(リソース・運用) ここで紹介するアーキテクチャは実際に運用まで行っており、問題なく稼働しているし、先日AWSの方にレビューしてもらったが、「なかなかイケてる」というお言葉をもらい、特に改善点も指摘されなかった。 結論(アーキ

                                      SaaS系スタートアップのリアルなAWSアーキテクチャ設計
                                    • 実は意外と大したことない。スタートアップの現実と数字(カミナシの場合)|諸岡 裕人(カミナシCEO | SaaS)

                                      最初の売上はMRR10万円。それを獲得するまでに1年1ヶ月かかった。MRR100万円を超えるのに2年。問い合わせは毎月5件くらい。投資家とのMTGは辛く、友人の「売上いくら?いつ上場するの?w」には苦笑いで返してた。3年やってMRR280万円までしか伸ばせずにピボット。スタートアップなんてこんなもん! — 諸岡 裕人|カミナシ CEO (@morooka_hiroto) February 9, 2022 そこで2つのことを感じました。 「サクセスストーリーではなく、苦労話や失敗談を聞くことで活力になったりする場面もある」ということ。過去の自分など特にそうですが、上手く行ってない時ほど誰かの苦労した話を聞くと、「自分もがんばろう!」と思えました。なので、このnoteは順調な方よりも、昔の自分のように苦しい状況にいる方に向けたものになっています。 2つ目は、「みんなリアルな数字を知りたがってい

                                        実は意外と大したことない。スタートアップの現実と数字(カミナシの場合)|諸岡 裕人(カミナシCEO | SaaS)
                                      • [翻訳]LLMで1年間開発して学んだこと〜LLMプロダクト開発を成功に導くための実践的ガイド〜

                                        この記事は "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/6/8 今は大規模言語モデル(LLM)を使った開発がとってもエキサイティングな時期です。この1年間で、LLMは実世界のアプリケーションに対して「十分に良い」ものになりました。そして、年々良くなり、安く

                                          [翻訳]LLMで1年間開発して学んだこと〜LLMプロダクト開発を成功に導くための実践的ガイド〜
                                        • 【総集編】15年間のC向けサービスづくりで得た学び|Shota Horii

                                          これまでC向けサービスを作り続けて15年が経過しました。 このnoteは「課題を解決し、事業としてスケールするプロダクトを創る」ために自分が考えてきたことを改めて体系立てて、言語化したいなと思い書き残しています。 同時に以下のように機能することを目指しました。 自身のプロダクト開発の知識を集約させる プロダクトに関わる人にとって教科書的に振り返ることができる スマートバンク社のプロダクトの再現性が伝わる 学びに終わりはないので、このエントリー自体も更新し続けるようにしたいと思います。 1.サービスを作る前の心構え俺が考えた最強のサービスを作らないスタートアップで何よりも回避すべきは、長い労力を掛けて作ったプロダクトを「誰も欲しがらない」こと 作り手の思い込みの「仮説」は現実の誰かの問題を解決するとは限らない 頭の中にある架空のユーザーに対してプロダクトを作った結果、実際に市場では「使われな

                                            【総集編】15年間のC向けサービスづくりで得た学び|Shota Horii
                                          • RESTful API との比較で GraphQL API を作ることの難しさ|qsona

                                            上の資料でも書いてるんですが、要点を言うと以下のようなことを主張している。 API の設計手法として、以下の2つのパターンが考えられる ・Resource-based API ・Usecase-based API Usecase-based というのは要はクライアントの要求にそのまま沿った形で API を作るということだ。しかし、UI やその他クライアントの要求というのは変わりやすいものなので、そのたびにいちいち API を変更しないといけないとか、API に一貫性がなくて使いにくいとか、1つの endpoint で多数の要求に対処する "神API" が作られてパフォーマンスが悪化する、というような問題が起こる。 したがって、注意深く RESTful API を設計すると Resource-based になる。ここで言っている Resource というのはテーブル設計にやや近いが、そのまま

                                              RESTful API との比較で GraphQL API を作ることの難しさ|qsona
                                            • ユニクロの広告を並べてみると『販促』と『ブランディング』の違いがよくわかる「デザインがまるっきり違う」「販促は消耗品、広告は投資」

                                              柳澤大介|新しい売れる仕組みを作る @socialselling84 B2Bの営業&マーケ支援に強い、株式会社マイノリティの代表です。新規事業のPMFはお任せあれ!売れる仕組みで急成長を実現します。スタートアップがユニコーン企業に成長するためのノウハウを毎日発信中。キーエンスやメルカリ・スマニューで新規事業立ち上げ⇨起業。ソーシャルセリング.com 運営。続きは↓の「さらに表示」から! https://t.co/2yVKGmJLKI

                                                ユニクロの広告を並べてみると『販促』と『ブランディング』の違いがよくわかる「デザインがまるっきり違う」「販促は消耗品、広告は投資」
                                              • 評価制度が機能するのは、前提に「腹八分目の年収」があるから 人事評価制度の構築・改良を成功させる6つのポイント

                                                白潟総合研究所株式会社代表で『中小ベンチャー企業を壊す! 人事評価制度 17の大間違い』著者の白潟敏朗氏と、『起業の科学』著者の田所雅之氏による対談の模様をお届けします。テーマは「人事評価の『ワナ』『落とし穴』」。中小ベンチャー企業の経営者に向けて、人事評価に対する悩みを解決するために最も大切なポイントについて語られました。最終回の本記事では、人事評価制度の構築・改良の成功のための6つのポイントが語られました。 固定賞与や給与に関する評価シートは、従業員が増えてから 白潟敏朗氏(以下、白潟):少しまとめさせていただきます。(人事評価シートについて)じゃあ私どもとしてどうしたらいいのかなというのを、一覧表示してみました。まずは業績連動賞与、いわゆるインセンティブに関しては、従業員の人数関係なく、ある意味計算式でやれる世界ができれば、評価が一番楽なのかなというふうに考えます。 社員が20人にな

                                                  評価制度が機能するのは、前提に「腹八分目の年収」があるから 人事評価制度の構築・改良を成功させる6つのポイント
                                                • ピボットを経てグローバル戦略へ、そして1兆円企業に…Treasure Data CEO・太田一樹の「忘れられない30分間」

                                                  データの収集・分析・連携ができるCDP(カスタマーデータプラットフォーム)を手掛けるTreasure Dataは、グローバルでも急成長中の注目SaaS企業。2018年にはArm社へイグジットしましたが、その後、今年になって創業者たちが「出戻り」の形で経営陣につき、さらなる飛躍を目指すというニュースは、業界に驚きをもたらしました。 今でこそCDPとして名高いTreasure Dataも、実はARR 30億円の段階でピボットし、現在の姿へと変わった経緯がありました。その背景にあったストーリー、ピボット後にARR 100億円を突破するため必要だったこと、そしてカムバックの理由まで、共同創業者でCEOを務める太田一樹さんに伺います。 聞き手は、ALL STAR SAAS FUNDマネージング・パートナーの前田ヒロです。 3年でARR10億、しかしテックジャイアントの参戦で…──早速ですが、ARR3

                                                    ピボットを経てグローバル戦略へ、そして1兆円企業に…Treasure Data CEO・太田一樹の「忘れられない30分間」
                                                  • 新規事業の決済機能としてStripeを導入する上で考えたこと全て - Timee Product Team Blog

                                                    こんにちは、タイミーデリバリー開発チームの宮城です。 この記事はJP_Stripes Advent Calendar 2020の10日目の記事です。 タイミーデリバリーはデリバリーを頼みたい人が安い価格で注文でき、飲食店も安い利用料で注文を受けられるデリバリープラットフォームです。 その決済機能として今回はStripeを導入しました。 この記事では、決済基盤の技術選定/Stripeを活用したクレジットカード決済と各事業者への入金までの流れ/Railsでの具体的な実装内容 をそれぞれタイミーデリバリーでの活用事例として紹介します。 導入にあたった背景 決済基盤の技術選定基準 Stripeでできること PCI DSSについて 利用したStripeの機能 Custom Account Stripe SDKを利用したRails/Swiftでの実装内容 PaymentIntent Customer

                                                      新規事業の決済機能としてStripeを導入する上で考えたこと全て - Timee Product Team Blog
                                                    • プラットフォームが初期ユーザーを集めるための8つの戦略と事例紹介|相川真司(かわんじ) #DiQt

                                                      ブログやマッチングサービスのような、価値を生み出す『生産者』と価値を消費する『消費者』の二種類のユーザーがいるサービスを、『プラットフォーム』や『ネットワーク製品』と呼びます。 Twitterやメルカリ、そして今あなたが読んでいるnoteも、「プラットフォーム」と呼ばれるサービスです。 しかし、このプラットフォームの立ち上げには、一つ大きな壁があります。 それは、『立ち上げ初期に機能させるのがとても難しい』という問題です。 プラットフォームでは『生産者』と『消費者』の2種類のユーザーを集めなくてはなりません。 しかし、サービス立ち上げ時には、このユーザーを集めて実際にサービスを機能させるのに大変苦労します。 なぜならプラットフォームでは、『生産者が増えないと消費者が増えない一方で、消費者が増えないと生産者が増えない』というジレンマがあるからです。 たとえばメルカリであれば、出品者が増えない

                                                        プラットフォームが初期ユーザーを集めるための8つの戦略と事例紹介|相川真司(かわんじ) #DiQt
                                                      • 「良いコードとは何か」で消耗するのはもうやめよう - DMM Developers Blog

                                                        これはなに? こんにちは、DMM.comのミノ駆動です。 プラットフォーム開発本部 Developer Productivity Group 横断チームにて、 プラットフォームの設計品質向上に取り組んでいます。 さて、ネット上ではソフトウェア開発における「良いコードとは何か」をめぐって、 いろんな意見が交錯したり、 ときには激論を呼んだりします。 収拾がつかないこともしばしばです。 この記事は、良いコードを考えるうえでの要素を整理し、 建設的な議論を助けることを目的とします。 これはなに? この記事の理解目標 良いコードをめぐる議論 議論1: 何をもって良いコードなのか 議論2: 良いコードはどうやったら書けるのか 議論3: 「綺麗なコード(良いコード) vs 動くコード」問題 議論改善のために提案します 提案1: ソフトウェア品質特性の観点でコードの良し悪しを判断しよう 提案2: 原理原

                                                          「良いコードとは何か」で消耗するのはもうやめよう - DMM Developers Blog
                                                        • 3大クラウド(AWS,Azure,GCP)をそれぞれプロダクションで実運用した感想(その2 Azure固有の優位性について) - Qiita

                                                          Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 3大クラウド(AWS,Azure,GCP)をそれぞれプロダクションで実運用した感想(その2 Azure固有の優位性について) はじめに 前回記事で3大クラウドに関して、各々のクラウドのシェアと将来性に関して感想を記述したところ、トレンド1位になったりと大変大きな反響をいただきました。 長い記事であったにも関わらず、目を通してくださった読者の皆様ありがとうございます! しかしながら、予想外のバズり方をしてしまってだいぶハードルが上がってしまったのと、ちょうど弊社でインパクトの大きい経営施策(シリーズBの資金調達/事業譲渡)が立て続けに執行

                                                            3大クラウド(AWS,Azure,GCP)をそれぞれプロダクションで実運用した感想(その2 Azure固有の優位性について) - Qiita
                                                          • 「ノーコード」だけで7億円のシリーズAまでスピード調達、HQに聞く | Coral Capital

                                                            月間10万人が読んでいるCoral Insightsのニュースレターにご登録いただくと、Coral Capitalメンバーによる国内外のスタートアップ業界の最新動向に関するブログや、特別イベントの情報等について、定期的にお送りさせていただきます。ぜひ、ご登録ください! 創業1年半で約7億円、累計9億円のシリーズA資金調達をする段階までノーコードツールを組み合わせてプロダクトとオペレーションを磨いてきたスタートアップがあります。Coral Capitalが出資するリモートワーク支援プラットフォーム「リモートHQ」を提供するHQです。 HQは2021年3月の創業で、約1年後の2022年4月に初の外部資金として約2億円を調達しています。その後、リモートワークやハイブリッドワークの広がりを背景に、大手企業を含む導入事例と売上をぐんぐんと伸ばし、シード調達からわずか6カ月半後の2022年11月に約7

                                                              「ノーコード」だけで7億円のシリーズAまでスピード調達、HQに聞く | Coral Capital
                                                            • 3大クラウド(AWS,Azure,GCP)をそれぞれプロダクションで実運用した感想(その3 AWS固有の優位性について) - Qiita

                                                              Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 今年のはじめに書いた3大クラウドの比較シリーズに関して長いこと続編を書いてませんでした...。 最近、知人/友人のみならず取引先からも「AWSやGCPに関して続編書かないんですか?」と言われることが増えてきたので、今回はAWSを本番運用していて感じたAWS固有の優位性について感想を述べていきます。 AWS 固有の優位性 周知の事実ではありますが、AWSは長年クラウドベンダーとして世界トップシェアを維持し続けています。 AWSをクラウド基盤として利用しているサービスを一切利用せずに1日を過ごすことは不可能なんじゃないかというレベ

                                                                3大クラウド(AWS,Azure,GCP)をそれぞれプロダクションで実運用した感想(その3 AWS固有の優位性について) - Qiita
                                                              • セキュリティの立ち上げで何をやる?

                                                                最近、セキュリティの立ち上げで何をやったらいいかわからない、という質問を何度か受けるケースがあったので、最初に何をやるか、というのを情シスやセキュリティ担当者としての考えをまとめてみる。 著者のキャリアについて セキュリティの立ち上げについて書く以上、信頼に足る情報源なのか?という疑問がわくと思うので、簡単に著者のキャリアを書いておきます。 2002年にSIerでIT業界に入り、研究所のNetwork Admin、Web penetration test、ISMSコンサルの補佐などやり、その後外資プリセール分野で7年仕事して、最初のSIに戻ってセキュリティソリューションの立ち上げを担当、その後ユーザーサイドにキャリアを変えて、外資石油系企業のセキュリティアナリスト、中国系スタートアップのInfoSec Director&一人情シスをやってきたキャリアです。CISSPは2019年に取得してお

                                                                  セキュリティの立ち上げで何をやる?
                                                                • エンタープライズ向けサービスのMVPはこうして失敗する。|大平 裕介/ CEO at リーナー

                                                                  どうもエンタープライズ企業の調達を刷新したい企業、Leanerの大平です。 エンプラSaaSの雄である会社の創業メンバー兼役員の方と、オンラインランチの機会があり、示唆深かったので許可をいただきメモ公開します。 ※この記事ではエンタープライズ企業は略称としてエンプラと書きます エンプラ向けにサービス開発している方の参考になったら嬉しいです! 拡散していただけると次回のやる気になるのでそれも嬉しいです(重要)! より話してみたい方や、少しリーナーに興味あるかもという方は、下記URLよりカジュアルに話しましょう!! "SMBのMVP"と"エンプラのMVP"一緒にすんな当然だが、SMBとエンプラでは、業務のオペレーションや目標・ミッションなどすべてにおいて、個社性がまったく違う。 比較的、SMBでは、個社性が低く。エンプラでは、個社性が高い。 だからこそ SMBは、MVPが「画一的」で許される。

                                                                    エンタープライズ向けサービスのMVPはこうして失敗する。|大平 裕介/ CEO at リーナー
                                                                  • プロダクトにドメイン駆動設計を適用するためにはじめたこと - ContractS開発者ブログ

                                                                    こんにちは。最近Slackのカスタム絵文字作りにハマっている友野です。Holmesでサーバーサイドエンジニアをしています。 Holmesが提供するホームズクラウドは、今年8月にサービスローンチ3周年を迎えました! これまでの支持に感謝し、これからも長く使ってもらえるようにプロダクト改善に取り組んでいます。そのひとつとして、ドメイン駆動設計(以下、DDDと表記します)適用に関する取り組みについてご紹介します。似たような状況や同じ課題を持つ誰かの一助になれば幸いです。 背景と現状 まずはじめたこと 戦略的モデリング そして、戦術的な設計 採用するパターン2つ ドメインモデルを反映したオブジェクトを置くパッケージの作成 既存テーブル構造に依存しないRepository+Adapterパターン ふりかえり まとめ 最後に 背景と現状 ホームズクラウドはPMF(Product Market Fit:

                                                                      プロダクトにドメイン駆動設計を適用するためにはじめたこと - ContractS開発者ブログ
                                                                    • [確率思考の戦略論] 1.確率理論の導入とプレファレンスの数学的説明

                                                                      import numpy as np import scipy from scipy.stats import binom %matplotlib inline %config InlineBackend.figure_format = 'svg' import matplotlib import matplotlib.pyplot as plt import seaborn as sns print("numpy version :", np.__version__) print("matplotlib version :", matplotlib.__version__) print("sns version :",sns.__version__) numpy version : 1.18.1 matplotlib version : 2.2.2 sns version : 0.8.1

                                                                        [確率思考の戦略論] 1.確率理論の導入とプレファレンスの数学的説明
                                                                      • 監視ツールを迷ったら CloudWatch から始めてみるのもありなのでは - カミナシ エンジニアブログ

                                                                        こんにちは、新規プロダクトの開発をしています、a2 (@A2hiro_tim )です。 昨日、開発してきたプロダクトについて、正式リリースを発表させていただきました 🎉 prtimes.jp employee.kaminashi.jp さて、新規プロダクトの立ち上げは、技術選定や運用ツールの自由度が高く、どの監視ツールを使うか、選択に迷うこともあると思います。 我々のチームでは複数ツールの使用経験はあるものの、特定のツールの導入経験や深い知見があるメンバーはいなかったので、フラットに比較検討し、 Amazon CloudWatch の利用から始めてみよう、と意思決定しました。 主な選定理由は、 AWS エコシステムの中で完結できるため、Terraform Cloud などの既存の設定を流用できて新しく覚えることが少ない、AWS 上でコストを一元管理できる、等のメリットがある。 サービス開

                                                                          監視ツールを迷ったら CloudWatch から始めてみるのもありなのでは - カミナシ エンジニアブログ
                                                                        • 結局のところ、エンジニアリングマネージャーとは何者なのか|dora_e_m

                                                                          はじめにこれはEngineering Manager Advent Calendar 2023 25日目の記事です。 毎日良質な記事がアップされて、完全に俺得な一ヶ月でした。ご参加いただいたみなさんありがとうございます。 最終日の記事では、EM Advent Calendarを俯瞰しながら執筆している私のEMキャリアをふりかえり、結局のところEMとは何なのか、ということを考えてみます。 Advent CalendarにおけるEMの多様性と共通点LLM時代におけるEMという、実に2023年的な切り口から始まったこのAdvent Calendarには、実に多様なコンテンツが集まってきました。 新任EMの方の奮闘の記録、手を動かしてなんぼという考え方、スクラムとの接近、プロジェクトマネジメント的アプローチ、オブザーバビリティのEM業への援用、キャリア論・・・。 共通しているのは「マネジメント対象

                                                                            結局のところ、エンジニアリングマネージャーとは何者なのか|dora_e_m
                                                                          • 目標設定の意味を問え。「OKRそのもの」が大事なわけではない理由|Kazuki Otomo

                                                                            OKRって難しいですよね。 というか、OKR以前にそもそも「目標設定」がムズかしいです。 でも、だから、大事です。 多くのスタートアップではOKR(Objectives and Key Results)という目標設定のフレームワークを導入しているわけですが、OKRについての悩みを社内外からよく聞きます。 今回は、「OKR以前の問題」について、主にマネージャー視点で役立つように書いてみようと思います。(メンバーの方も理解が進むと思います) ポイントはOKRの形式以前にある実際、ダイニーでも過去に何度か目標設定の方法を変更してきました。 フレームワークなし→OKR→PKA※→OKR といった具合の変遷です。 ※PKA:ミラティブさんがあみだした独自の目標管理手法Promises and Key Actionsのこと では、OKRがよかったのか、というと、今のところOKRがよいというだけで、実は

                                                                              目標設定の意味を問え。「OKRそのもの」が大事なわけではない理由|Kazuki Otomo
                                                                            • 組織の中で起業家のように働く、新しい専門職としてのあり方を考える - データ分析職種の場合|樫田光 | Hikaru Kashida

                                                                              ここ数年、曲りなりにデータ分析の専門職種としてやってきたが、常々この仕事には困難さがつきまとうなと感じる。その事について、その理由、そしてその困難さとどう戦っていくかについての考察を記してみたい。 気まぐれな雑記のうえ、だいぶ長くなってしまったが時間がある方はお付き合い願いたい。感想の一つでも貰えれば幸いです。 困難さ仕事をしていて苦労することはよくあるわけだが、とりわけデータ系の仕事をしているとおおよそ以下のような面倒さを背負い込んでいることに気づく。 普通にしているとあまり良い仕事が回ってこない 周囲に任せていると細かい本質的ではない仕事に埋もれてしまう 組織の上層の戦略やリテラシに依存するところが異様に大きい 自分たちの成果がどうにもわかりづらい 短期的な都合に押し負かされて自分たちの仕事の優先度を下げられる などなど。これは自分個人の体験だけにとどまらず、他の会社でもデータ分析チー

                                                                                組織の中で起業家のように働く、新しい専門職としてのあり方を考える - データ分析職種の場合|樫田光 | Hikaru Kashida
                                                                              • Linux 6.1の注目機能「MGLRU」―メモリ管理に取り入れられたエイジングシステム | gihyo.jp

                                                                                Linus Torvaldsは12月11日(米国時間⁠)⁠、前週の告知どおりに「Linux 6.1」の正式リリースをアナウンスした。 Linux 6.1 -Linus Torvalds Linux 6.1はメインライン開発ではじめてRustを採用したことが大きな話題となったが、そのほかにもユーザ空間におけるメモリサニタイザーツールに似た動的エラー検出の「KMSAN」やB-treeベースのデータ構造「Maple Tree⁠」⁠、AMDの新しいPMFドライバのサポートなど多くのアップデートが行われている。Googleの開発者がメインラインへのマージを提案してきた「MGLRU(Multi-generational LRU⁠)⁠」もそのひとつで、古参のカーネル開発者であるAndrew MortonもMGLRUのメインライン化をバックアップしてきた。 Linuxカーネルではメモリ管理に「LRU(Le

                                                                                  Linux 6.1の注目機能「MGLRU」―メモリ管理に取り入れられたエイジングシステム | gihyo.jp
                                                                                • 入社一ヶ月の分報戦記(Ubie) - maru source

                                                                                  僕は仕事で分報をかなり活用しています。今年の3月に入社したUbie(ユビー)というヘルステックベンチャーでもめちゃくちゃ分報に書き込みをしています。どれぐらい書いてるかというと、入社初月で1700投稿(75投稿/平日)し、社内トップでした。 社内の分報チャンネルの投稿数ランキング 分報にはこの一ヶ月で経験した色々な仕事について感想や意見を書いています。まさに僕自身の入社一ヶ月の戦記と言えます。そこでこの分報からコメントをピックアップして入社一ヶ月を振り返ってみようと思います。振り返りは三つの軸で行いました。 🏥 事業ドメイン(医療) 🧠 組織・カルチャー 🧑‍💻 自分の成長(ソフトウェアエンジニア) 🏥 事業ドメイン(医療) サマリー Ubieはヘルステックベンチャーなので事業ドメインとしてはバリバリの医療。それがすごく面白い。何が面白いかって言うと医療自体は自分の身近にあるもの

                                                                                    入社一ヶ月の分報戦記(Ubie) - maru source