並び順

ブックマーク数

期間指定

  • から
  • まで

121 - 160 件 / 263件

新着順 人気順

プロダクト開発の検索結果121 - 160 件 / 263件

  • データ品質を重視したデータ基盤プロダクト開発

    データ基盤アーキテクチャトレンド 2023 LTとパネルで学ぶ (https://findy.connpass.com/event/278140/) の登壇資料になります。

      データ品質を重視したデータ基盤プロダクト開発
    • プロダクト開発におけるエンジニアリングマネージャー(EM)とテックリード(TL)とPMの役割分担|みね@PRONI

      自社のプロダクト開発をしている、みね@ユニラボ(@mine_take)です。 ※本記事は個人の活動による記事であり、会社の公式見解とは異なる場合があります。 エンジニアリングに関わる内容で記事を書いています。今回はプロダクトの拡大により、エンジニア組織の拡張・拡大を考えた際に重要なポジションの、エンジニアリングマネージャー、テックリードという役割について、そしてプロダクトマネージャーとの関係について書きます。 エンジニアリングマネージャー(EM)とテックリード(TL)とプロダクトマネージャー(PM)の関係性プロダクト開発における重要な役割として、エンジニア組織のマネジメントを手掛ける『エンジニアリングマネージャー(EM)』、高い技術力をもって開発チームを牽引する『テックリード(TL)』、エンジニア組織のマネジメントとは別の役割としてプロダクト開発の責任者を務める『プロダクトマネージャー(P

        プロダクト開発におけるエンジニアリングマネージャー(EM)とテックリード(TL)とPMの役割分担|みね@PRONI
      • 不確実性をぶっ飛ばせ!Fintech事業部における新規プロダクト開発とは - LayerX エンジニアブログ

        この記事は、6月から始まっている #LXベッテク月間 21日目の記事です。 前日の記事はざべすさんの「Fintech事業部の全力のBet Technologyの様子をお見せします」でした。 tech.layerx.co.jp こんにちは、Fintech事業部でサービスの新規立ち上げをしているエンジニアの @takochuu です。 LayerXから三井物産デジタル・アセットマネジメント(以下、MDM)に出向し、エンジニアとして星飛雄馬ばりの全力投球で個人投資家向け新規サービスの立上げをしています。 今回は新規サービスであるプロジェクトZENIOKOSHIが具体的にどんな開発プロセスで開発されていっているのかをご紹介します。 Fintech事業部と今回語る新規プロダクトについてはこちらのPodcastにて紹介していますので、よければお聞きください。 open.spotify.com 開発に対

          不確実性をぶっ飛ばせ!Fintech事業部における新規プロダクト開発とは - LayerX エンジニアブログ
        • スタートアップ創業期にリモート主体で進めてきたプロダクト開発チームの軌跡 - Beatrust techBlog

          はじめに Beatrust VPoEの Ryo(長岡 諒) です。 Beatrust は2020年3月創業で現在3年目となりました。創業当初は3名だったのですが、現在社員は16名で業務委託の方も含めると30名以上の組織体となっており、初期からリモートワーク主体でした。しかし、リモートワーク主体の組織では意志を持って取り組まないとコミュニティのつながりが薄れサイロ化し、セールスとプロダクトなど各チームでのセクションの境界が強まり情報や意思決定の断絶が起こりがちです。我々も最初期は全員で議論していましたが、人数やチーム課題の変化に伴い共有・議論の仕方は進化しており、どんな変遷を経て行き着いたのかその過程から共有することで参考になるものもあるかと思いまとめました。 チーム開発においてどういった会議体・プロセスでプロダクト開発を進めようか試行錯誤している方や、リモートワークが主体となりチームサイズ

            スタートアップ創業期にリモート主体で進めてきたプロダクト開発チームの軌跡 - Beatrust techBlog
          • POSレジの長期プロダクト開発 - STORES Product Blog

            STORES, STORES レジでバックエンドエンジニアをしている @charlie です。 先日 STORES から新しいプロダクト STORES レジ がリリースされました。 プロジェクト発足からリリースまで開発に実は1年9ヶ月かかっています。 全体像は @ide も公開しているので読んでみてください。 https://ideyuta.com/stores_regi ここではバックエンドエンジニア目線で約2年弱のプロジェクトを振り返りたいと思います。 POSレジという未知の世界 レジプロジェクトにアサインされたのは2019年10月頃。 社内にはオフラインやPOSレジの知見はほとんどなかったため、キャッチアップから始まりました。 例えば、複数の店舗やシフトといった概念はオフライン特有のものです。 オフラインでは何が必要なのかを調査し、STORES でどのように実現していくのかを検討して

              POSレジの長期プロダクト開発 - STORES Product Blog
            • Shape Up - Basecampによるプロダクト開発ガイド - tuneの日記

              はじめに Basecamp社が公開しているプロダクト開発ガイド「Shape Up」の存在を知り読んでみました。 Basecamp社はプロジェクト管理SaaS Basecampの開発元で、以前は37 Signalsという社名でした。 Ruby on Railsの作者 David Heinemeier Hansson氏がCTOを務め、最近だと新機軸のメールサービス Hey を立ち上げています。 basecamp.com 特徴 Basecamp曰く「アジャイル開発でもスクラム開発でもない」、Basecamp社で15年近く試行錯誤して改善してきたやり方だそうです。 「6週間の開発サイクル」と「2週間のクールダウン期間」を繰り返して開発を進めます。 サイクルの途中で中断・見直しはせず、期間内にリリースに至らなかった場合でも期間延長はされません。 6週間は「何か意味のあるものを最初から最後まで作り上げ

                Shape Up - Basecampによるプロダクト開発ガイド - tuneの日記
              • プロダクト開発だけでなく、組織のパフォーマンスも上げる概念「イネーブルメント」 名村卓氏が説く、その価値

                株式会社overflowによって開催された、開発組織のあり方について考える1ヶ月「CTOWeek 2023 by Offers」。Week2に登壇したのは、株式会社LayerX 執行役員の名村卓氏。開発スピードを落とさないために必要な、イネーブルメント組織について話しました。全3回。3回目は、視聴者からの質問に答えました。前回はこちら。 ドメインがファットになった時、分割する時のリードもEnabling Teamが行うのか? 大谷旅人氏(以下、大谷):名村さん、ありがとうございました。やはり小さなチームにするためにはドメインフォーカスした状態が必要というところで、私も自分の組織に置き換えながら拝聴していました。 ここからは質疑応答の時間といたします。一番上からいきましょうか。「ドメインがめちゃくちゃファットになった時に分割する時のリードもEnabling Teamが行いますか? もしそうだ

                  プロダクト開発だけでなく、組織のパフォーマンスも上げる概念「イネーブルメント」 名村卓氏が説く、その価値
                • プロダクト開発におけるKPI設定について|GakuBessho

                  こんにちは。別所 (@gb_pdm)です。 2019.12からSNS領域プロダクトのプロダクトマネージャーをしています。 現在KPI(Key Performance Indicator)に基づき機能立案やプロダクト改善ができるチームを作るため挑戦中です。 KPI設定方法については既に多くの方が情報発信されていますが、自分の中での整理の意味も込めて先人の方達の内容をベースに改めてまとめました。 ここで話すこと - KPIは様々なシーンで設定されるかと思いますが、ここではプロダクト開発観点での話になります。 ここで話さないこと - 具体的にどういった指標をKPIに設定すべきかについては触れていません。 - KPI・KGIの達成方法については触れていません。(誰か教えて下さい) 1.KPI設定のメリット [メリット1]道標になる KPIはKGI(Key Goal Indicator)という山を登

                    プロダクト開発におけるKPI設定について|GakuBessho
                  • MNTSQプロダクト開発チームのカンバン運営を紹介します!|ikutani41

                    リーガルテック・カンパニーMNTSQ(モンテスキュー)を創業して1年と9ヶ月が経ちました。 今日はMNTSQ(モンテスキュー)のプロダクト開発チームでは日々どんな流れで仕事が行われているのか、特にカンバン運営に焦点を当てて紹介しようと思います。 MNTSQのプロダクト開発の全体像としては、OCRやアルゴリズム開発やリーガルナレッジの再定義など様々なことをやっていますが、今回は特にユーザが触るソフトウェア面の開発(Rails + Vue.js + Elasticsearch)での運営を紹介します。 開発チーム構成 # こんな感じ ・PM & Designer & フロントエンドエンジニア: 1人(私) ・遊撃隊: 1人 ・バックエンドエンジニア: 2名 ・検索エンジニア: 1名 ・週2~3業務委託エンジニアチーム: 4名見ての通りまだまだ小さいチームです。 特に業務委託チームはフルリモートで

                      MNTSQプロダクト開発チームのカンバン運営を紹介します!|ikutani41
                    • 10XにおけるC向けのプロダクト開発とサービスグロースの考え方をチラ見せします | 株式会社10X

                      こんにちは、10Xのグロースチームです。 みなさんは10Xという会社にどの様なイメージを持っているでしょうか。 10Xはその事業領域から、「小売のDX」といった文脈で捉えられることも多く、もしかしたらB向けにサービスを提供している会社、という認識を持たれている方も多いのかもしれません。 それはそのとおりで、確かにB向けのプロダクト開発もゴリゴリとやっているのですがが、その一方でいわゆる「C向け」のプロダクト開発もバリバリやっていますし、いままさにその分野が社内でもアツくなり始めています。 この記事ではそのあたりの話と、10Xのグロースチームの構造の全体像を紹介させてください。 <このブログの内容> ・10Xのモデルの簡単な説明 ・C向けのプロダクトの改善と根拠となる分析のチラ見せ ・グロース体制の全貌の説明 ・人材募集してます10Xのモデルサービスモデル10Xは小売事業者向けにネットスーパ

                        10XにおけるC向けのプロダクト開発とサービスグロースの考え方をチラ見せします | 株式会社10X
                      • DX事業本部のプロダクト開発プロセス(現在進行系) - Speee DEVELOPER BLOG

                        デジタルトランスフォーメーション事業本部でプロダクトマネージャーをしています、渡邊です。本日はデジタルトランスフォーメーション事業本部(以下、DX事業本部)のプロダクト開発プロセスについてご紹介します。 取り組み中の内容も多く、あくまでも現時点を切り取ったスナップショット的な内容になりますが、2019年の棚卸しの意味も込めて、ログとして残しておきたいと思います。 DX事業本部の取り組み DX事業本部では「リアル産業の情報流通をリ・デザインし、バリューチェーンを再開発する」というミッションを掲げ、歴史のある産業の非効率な情報流通を見つめ直し、オンラインとオフライン両方のネットワークをより良い形で繋ぐ取り組みを行っています。 speee.jp DX事業本部(イエウール)のプロダクト開発チーム DX事業本部の事業のひとつでもある、イエウールは不動産売却・査定サービスにおいて、業界トップのシェアと

                          DX事業本部のプロダクト開発プロセス(現在進行系) - Speee DEVELOPER BLOG
                        • 事業やプロダクト開発を加速させるデータ分析|masa_kazama

                          ここ数年、様々な業界でデータサイエンティストの求人を目にします。一口にデータサイエンティストと言っても内容は様々で、画像解析やレコメンド開発など機械学習エンジニア系のものもあれば、ビジネスの意思決定を支援するようなデータアナリスト系のものもあります。(データサイエンティストの分類についてはTJOさんの記事が参考になります) この記事では、ビジネスの意思決定を支援するデータ分析に絞って、事業やプロダクト開発を加速させるのに必要なことについて、自分の思考の整理を兼ねて書きたいと思います。この記事を書くきっかけは、最近読んだデータ分析についての記事が、面白くて新しい気づきが多く、改めてデータ分析について整理してみたいと思ったからです。(だみ〜さんの記事、タカヤナギ=サンの記事) この記事は、「現場とデータの両面からの分析」と「データ分析がしやすい環境作り」がやはり大切という内容で、日頃データ分析

                            事業やプロダクト開発を加速させるデータ分析|masa_kazama
                          • プロダクト開発におけるリスクを排除するためにモバイルアプリエンジニアができること - inSmartBank

                            こんにちは、スマートバンクでモバイルアプリエンジニアをしているロクネムです。 書籍『INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント』ではプロダクト開発には以下の4つのリスクがあると説明されています: 実現可能性のリスク: エンジニアが、持っている時間とスキルとテクノロジーで必要なものを作れるかどうか 価値のリスク: 顧客が購入するかどうか ユーザビリティーのリスク: ユーザーが使い方をわかるかどうか 事業実現性のリスク: ソリューションが、販売、マーケティング、財務、法律など、ビジネスのさまざまな分野でも問題がないかどうか (順番は入れ替えています 🙏) 同書では、優れた開発チームはこれらのリスクに対して開発の早い段階で取り組むと記されています。 自分はこれらのリスクのうち「実現可能性のリスク」「価値のリスク」「ユーザビリティーのリスク」の3つについてはモバイルアプリエ

                              プロダクト開発におけるリスクを排除するためにモバイルアプリエンジニアができること - inSmartBank
                            • プロダクト開発における結果目標の功罪、そして状態目標へ

                              プロダクト開発における目標設定で陥りがちな罠とそれを回避する目標設定について

                                プロダクト開発における結果目標の功罪、そして状態目標へ
                              • 10XにおけるC向けのプロダクト開発とサービスグロースの考え方をチラ見せします | 株式会社10X

                                こんにちは、10Xのグロースチームです。 みなさんは10Xという会社にどの様なイメージを持っているでしょうか。 10Xはその事業領域から、「小売のDX」といった文脈で捉えられることも多く、もしかしたらB向けにサービスを提供している会社、という認識を持たれている方も多いのかもしれません。 それはそのとおりで、確かにB向けのプロダクト開発もゴリゴリとやっているのですがが、その一方でいわゆる「C向け」のプロダクト開発もバリバリやっていますし、いままさにその分野が社内でもアツくなり始めています。 この記事ではそのあたりの話と、10Xのグロースチームの構造の全体像を紹介させてください。 <このブログの内容> ・10Xのモデルの簡単な説明 ・C向けのプロダクトの改善と根拠となる分析のチラ見せ ・グロース体制の全貌の説明 ・人材募集してます10Xのモデルサービスモデル10Xは小売事業者向けにネットスーパ

                                  10XにおけるC向けのプロダクト開発とサービスグロースの考え方をチラ見せします | 株式会社10X
                                • SRE とプロダクト開発の EM を兼務して半年経った - ツナワタリマイライフ

                                  3ヶ月前の振り返り https://blog.chaspy.me/entry/2022/12/24/120000 いろいろキツかったがなんとか走り切れたかな、というそんな感じ。うまくいかない時期もあったが、周囲にサポートしてもらいながら、少しずつ前に進むことはできたと思う。 SRE ややハードになりそうな状況ではあったが、なんとか乗り越えられたと思う。メンバー1人1人の自立性と技術力のおかげだと思う。 11月に1人、2月に1人入社し、メンバーは7人になったところで採用を止めることができた。これにより採用活動にかけていた時間を使わなくなったのは大きい。 新しく入った2名についても順調に立ち上がっていると判断していて、1on1は細かめにやっているものの、マネージャーというよりはメンターとそれを受け入れるチームが正しく機能していたことが大きいと思う。 後半の Q4はリーダーが他のチームに留学した

                                    SRE とプロダクト開発の EM を兼務して半年経った - ツナワタリマイライフ
                                  • 「絶対売れる!」と思ったのに利用実績はたった1社 プロダクト開発の大失敗から学んだ“視点変換”と“共有と意思決定の細かさ”の重要性

                                    自己紹介と株式会社カミナシについて 後藤健佑氏(以下、後藤):開発、実装の話ではありませんが、今僕がプロダクトマネージャーとしてやっていて、「これは売れる!」と確信して出したものの、機能の利用社数が1社で、膝から崩れ落ちた話をしようかなと思っています。よろしくお願いします。 自己紹介です。今、株式会社カミナシでプロダクトマネージャーをやっている後藤と言います。ふだんはプロダクトの仕様を決めるなどをやっています。もともとはエンジニアからスタートしていて、GolangやTS、AWS周りがけっこう好きです。今はプロダクト周りの仕様や、「どうして作るの?」みたいなところを作っています。 まず「カミナシとは何か?」をお話します。「カミナシは現場の改善プラットフォームを作っている」とよく言いますが、現場のルーチンワークであったり、事務作業のを自動化するアプリを作ったりしています。現場は、手書きの情報や

                                      「絶対売れる!」と思ったのに利用実績はたった1社 プロダクト開発の大失敗から学んだ“視点変換”と“共有と意思決定の細かさ”の重要性
                                    • あなたの新規事業プロダクト開発はこうして失敗する🦆

                                      釣りタイトル容赦。なんてことありません、僕の失敗談です。 失敗談は好きですか?僕は大好きです。 他人の不幸はなんとやら。さぁ行ってみよう! 1. 早すぎる最適化をしてしまう ドナルド・クヌース先生の、「早すぎる最適化は諸悪の根源」という言葉は、ソフトウェア開発に携わっている皆様であればそれなりに日々実感することであり、なんとなくでも直感的に共感できることと思います。 この言葉自体は、ソフトウェア開発の性能チューニングの文脈で語られるものだとは思いますが、僕はこの言葉、結構いろんな場面で使えると思いますし、使っています。 もちろん原義通り、パフォーマンスのための最適化という文脈でも当たり前のように意識したほうが良い言葉ではありますが、例えば抽象概念のモデリングや、コード品質の向上、ライブラリやアーキテクチャの選定といった場面でも使える概念ではないでしょうか。 「ここ」と「そこ」のロジックはな

                                        あなたの新規事業プロダクト開発はこうして失敗する🦆
                                      • PMからSales/BizDevに伝えたい、プロダクト開発における4つの大切な考え方|さとじゅん

                                        メルペイのPMのさとじゅんです。 to B向けプロダクト開発のPMとして働く上で、SalesやBizDevの方(以下Sales)から、「あの会社が◯◯で困っているから✖️✖️という機能が欲しいのだけど検討できないか」という話を貰うことはたくさんあります。 こんな時にPMの人がどんなことを考えているかについてまとめていきたいと思います。 そしてそれによってSalesの方々がPMの思考を理解して、お互いに建設的な議論がたくさんできるようになると良いなぁと思っています。 PMの現状いろんな人から要望を受ける まず大体の場合、PMの人数とSalesの人数はSalesのほうが多いはずです。 この場合1人のPMに対して複数のSalesが要望を上げることになると思います。 いろいろな人からいろんなことを言われるPMからすると、より課題感の深い問題に取り組みたいし、インパクトを算出するためにも数字感など具

                                          PMからSales/BizDevに伝えたい、プロダクト開発における4つの大切な考え方|さとじゅん
                                        • プロダクト開発で陥りがちな“アウトプット指標の甘美な罠” ビルドトラップにはまらないための組織づくり

                                          ビビッドガーデンとベルフェイスのコラボイベント「脱ビルドトラップ toB/toCそれぞれのプロダクトマネジメント」。事例発表とパネルディスカッションを通して、各社が取り組むプロダクトマネジメントの手法と、いわゆるビルドトラップ状態を脱したプロセスなどの実例を話しました。株式会社ビビッドガーデンから登壇したのは、森洋一郎氏。脱ビルドトラップなプロダクトマネジメント組織づくりについて発表しました。 ビビッドガーデンに1人目のプロダクトマネージャーとしてジョイン 森洋一郎氏:私からは「脱ビルドトラップなプロダクトマネジメント組織」というテーマで、今日は話します。 最初に自己紹介させてください。「食べチョク」のプロダクトマネージャーの森と申します。僕は大学卒業後に福岡のSIerでエンジニアをするところからキャリアを始めました。その後オンライン英会話のレアジョブというところで2年ほどエンジニアをやっ

                                            プロダクト開発で陥りがちな“アウトプット指標の甘美な罠” ビルドトラップにはまらないための組織づくり
                                          • エンジニアは「How」、PMは「Why & What」ならばTPMは?メルカリのプロダクト開発における“位置づけ” | mercan (メルカン)

                                            エンジニアは「How」、PMは「Why & What」ならばTPMは?メルカリのプロダクト開発における“位置づけ” 「テクニカルプロダクトマネージャー(以下、TPM)」とは、プロダクトマネジメントにとどまらず、テクニカル面からプロダクトを管理・進行する役割。メルカリグループでも2020年から本格的に導入し、現在も多様なメンバーがTPMとして活躍しています。 しかーし、気になるのはその“位置づけ”です。TPMという言葉から「プロダクトマネージャー(PM)とエンジニアの間に立つ」ようなイメージは持てるものの、具体的にどんな業務を行っているのかはまだわかりにくい印象もあります。 そこで今回は、メルカリへTPMとして入社し、現在はFoundation ProductチームとPlatform Productsチームでそれぞれプロダクト開発に関わる丸山素良(@Sora)とCamy Tsukamoto(

                                              エンジニアは「How」、PMは「Why & What」ならばTPMは?メルカリのプロダクト開発における“位置づけ” | mercan (メルカン)
                                            • プロダクト開発とチームづくりを支えるLeanerの「相棒制度」

                                              この記事で紹介したいこと Leanerでは「相棒制度」と呼ばれる職能間のコミュニケーションを促進する施策をやってます。 何のためにそんなことをやっているのか?を感じていただけると嬉しいです。 Leanerの相棒制度とは セールス、カスタマーサクセス、Devのチーム間で三人一組をつくって相棒となります(人数比が合わないので2人になる組もある)。 それぞれ相棒になった組で、週一で相棒ミーティングを行ってもらいます(頻度は各組にお任せ)。 3ヶ月を区切りとして、組をローテーションして別のメンバーと相棒を組みます。 相棒ミーティングで話すこと 社内向けには以下のように説明していますが、実際にどのような話をするかは各組に完全に任されています。 (社内のNotionを転記) - 基本的にはセールス面、サクセス面で抱えている顧客の課題について話してもらう - それをどう解決するかを組で一緒に考える -

                                                プロダクト開発とチームづくりを支えるLeanerの「相棒制度」
                                              • 日本語対応のノーコードツール5選!!プロダクト開発から業務改善まで対応!!(Click、MagicInstructions、サスケWorks、Kintone、Platio) | メディア | NOCODO(ノコド)

                                                日本語対応のノーコードツール5選!!プロダクト開発から業務改善まで対応!!(Click、MagicInstructions、サスケWorks、Kintone、Platio) これまで、NOCODO(ノコド)では主要なノーコードツールを軸に、アプリを開発することができるノーコードサービスや、業務改善を行うことができるノーコードサービスの紹介を行なってきました。 ノーコードツールは基本的に、非エンジニアでも使えるように提供されているサービスですが、現在ノーコード市場で注目されているサービスの多くは、アメリカなどの外国の企業から提供されているものが多く、英語力が必要になることがあります。 そこで今回は、日本語で提供されている、国産のノーコードツールを、5つ紹介していきます。 「SaaSなどのサービスの導入を考えている方、皆が使いやすいサービスを探している方や、言語の壁でストレスなくアプリ開発を行

                                                  日本語対応のノーコードツール5選!!プロダクト開発から業務改善まで対応!!(Click、MagicInstructions、サスケWorks、Kintone、Platio) | メディア | NOCODO(ノコド)
                                                • 【グロースするプロダクト開発の共通点】Notion開発責任者が語る「Product-Led Growth」な組織に必要なもの - エンジニアtype | 転職type

                                                  転職・求人情報サイトのtype エンジニアtype スキル 【グロースするプロダクト開発の共通点】Notion開発責任者が語る「Product-Led Growth」な組織に必要なもの 2022.01.25 スキル PdM Zoom、Slack、Shopify……近年、瞬く間にメジャーになったサービスに共通するもの。それは、「プロダクト・レッド・グロウス(Product-Led Growth)」を実現していることだ。 「プロダクト・レッド・グロウス」とは、「プロダクトがプロダクトを売る」という概念。かつて企業は営業やマーケティングの力で製品を広めようとしたが、昨今のITサービス、特にシリコンバレーでは「プロダクトの品質こそが売上に直結する」という考えが強くなっている。 しかし、日本ではまだプロダクトの重要性が、充分に認識されていない。そんな問題意識から設立された日本CPO協会の主催で、海外

                                                    【グロースするプロダクト開発の共通点】Notion開発責任者が語る「Product-Led Growth」な組織に必要なもの - エンジニアtype | 転職type
                                                  • ソフトウェアの「アジリティ」と「品質」をトレードオフにしない、プロダクト開発の理想型|Tably及川卓也×Autify 近澤良|ハイクラス転職・求人情報サイト AMBI(アンビ)

                                                    ハイクラス求人TOPIT記事一覧ソフトウェアの「アジリティ」と「品質」をトレードオフにしない、プロダクト開発の理想型|Tably及川卓也×Autify 近澤良 ソフトウェアの「アジリティ」と「品質」をトレードオフにしない、プロダクト開発の理想型|Tably及川卓也×Autify 近澤良 ソフトウェア開発においても重要なキーワードとなっている「アジリティ」。激しい市場変化への対応力、機敏性を意味する言葉だ。あらゆる産業でソフトウェアを主体としたビジネスへとシフトするなか、その「アジリティ」と「クオリティ」をどう両立するか。そのためのプロダクト開発の理想型とは? Tably及川卓也氏 × Autify 近澤良氏の特別対談をお届けする。 アジリティがなければ、もはや勝負にならない。 ミニウォーターフォール化する、アジャイル開発の罠 高まる、E2E (End to End)テストの重要性 組織とし

                                                      ソフトウェアの「アジリティ」と「品質」をトレードオフにしない、プロダクト開発の理想型|Tably及川卓也×Autify 近澤良|ハイクラス転職・求人情報サイト AMBI(アンビ)
                                                    • PyTorchのEmbeddingの挙動についてまとめてみた - DROBEプロダクト開発ブログ

                                                      はじめに CTOの都筑(@tsuzukit2)です この記事では PyTorch の Embedding の挙動について記載します Embedding とは何か 公式の仕様書はこちらになります Embedding - PyTorch 1.9.0 documentation 公式の説明は以下となっており、非常に的を得ていると思います A simple lookup table that stores embeddings of a fixed dictionary and size. 意訳すると、 固定長の辞書埋め込みを保存するシンプルなルックアップテーブル になるんじゃないかなと思います。Embedding は、何だか難しそうにも思えてしまうのですが、ここに記載されている通り非常にシンプルなテーブルでしかないという事です モジュールの解説としては以下のように記載があります This mod

                                                        PyTorchのEmbeddingの挙動についてまとめてみた - DROBEプロダクト開発ブログ
                                                      • 2年半ぶりのプロダクト開発であらためて感じた自動テストの大切さ / realized the importance of automatic testing with product development for the first time in two and a half years

                                                        Android Test Online #1の発表資料です

                                                          2年半ぶりのプロダクト開発であらためて感じた自動テストの大切さ / realized the importance of automatic testing with product development for the first time in two and a half years
                                                        • エンジニアの仕事は、プロダクト開発という名の総合格闘技|大竹雅登/dely

                                                          こんにちは。クラシルを運営するdelyでCTOをしています、大竹です。 兼任で、クラシルの新規事業であるネットスーパー事業の責任者をしています。先日、イオン様との提携を発表しました。 delyは2014年の設立時に堀江さんと共同創業しました。いくつもの事業立ち上げ・撤退を経て、2016年5月にクラシルをローンチしました。当時はエンジニアは自分1人しかいなかったので、(負債も残しつつ)全てゼロから構築しました。 そこから4年半、CTOとして技術選定、メンバー採用、組織マネジメント、さらに新規事業としてEC事業の立ち上げも経験しました。 曲がりなりにも多くの経験をしてきて一つ断言できるのは、エンジニアの仕事はコードを書くことだけではない、ということです。 そもそもやるべきことは、世の中の課題を解決することです。その手段としてプロダクトがあり、そのプロダクトを作るためのソフトウェア開発があります

                                                            エンジニアの仕事は、プロダクト開発という名の総合格闘技|大竹雅登/dely
                                                          • Communeの「プロダクト開発サイクルの今」を公開します! - Commune Engineer Blog

                                                            はじめに こんにちは、コミューンでプロダクトマネージャー(PdM)を担当している東です。 今回は、コミューンにおけるプロダクト開発サイクルについて、概要をまとめて公開してみたいと思います。 コミューンについて少しでも興味を持ってくださっている方や、他社事例を見てみたい方などにご覧いただけると幸いです。 Communeについて 弊社は、「企業とユーザーが融け合う社会を実現する」をビジョンとして掲げ、現在「commmune」と「SuccessHub」の大きく2プロダクトを提供しています。 「commmune」は、オンラインコミュニティプラットフォームをノーコードで作成できる、いわゆるBtoBSaaSです。SaaS形式でツールをご提供しつつ、カスタマーサクセス(CS)がコミュニティの戦略策定・実行支援を丁寧に行い、コミュニティの成功に向けて伴走しています。toB・toC問わず、スタートアップから

                                                              Communeの「プロダクト開発サイクルの今」を公開します! - Commune Engineer Blog
                                                            • whyから始める顧客起点のプロダクト開発 - asoview! Tech Blog

                                                              アソビューAdvent Calendar 2022の16日目の記事です。 アソビューCPOの横峯です。 「生きるに、遊びを。」というミッションをもとに事業を展開する弊社が大切にする考えとして「For You 〜すべては顧客のために」というバリューがあります。 コロナ化でもこのバリューを体現し売上95%減からV字回復できたと考えています。 business.nikkei.com 今日はアソビュー!のPdMの役割も担っている僕が開発現場における顧客起点を実現していくために大切にしていることをお話します。 アソビュー!の開発フロー まずは開発全体のサイクルから。 弊社はプロダクトバックログを軸にしたスクラム開発を2週間のスプリントで実施しています。 アソビューの開発フロー プロダクトバックログの優先順位を僕が決め、それをベースにスプリントプランニングを実施しスプリントバックログを作成。 デイリー

                                                                whyから始める顧客起点のプロダクト開発 - asoview! Tech Blog
                                                              • LayerXのプロダクト開発:チーム・開発プロセス・技術スタック

                                                                こんにちは。LayerXのリードエンジニアの@MasashiSalvadorです。今回のブログではLayerXの事業の概要を説明した後に、実際に事業を進めていく中でどのようにプロダクト開発をしていくかを書いていきます。2020年初頭版、LayerXの開発のざっくりとした全体感という感じになるかと思います。開発の進め方、技術スタックとその選定方法とか、社内のチーム開発の様子などを紹介できればと思います。 利用している技術達LayerXの事業とアジャイルな開発プロセスLayerXはブロックチェーン技術を基軸にソフトウェアを用いることで企業のDX(Digital Transformation) を推進し、共同で新しい事業を作り出そうとしています。今現在、多くのクライアント企業様とお仕事させていただいています。 各プロジェクトは コンサルティング実証検証の前提や要件モノを作ることによる実証検証の実

                                                                  LayerXのプロダクト開発:チーム・開発プロセス・技術スタック
                                                                • 高い事業成長の実現には、健全なカルチャーが必要。年300%成長SaaSを支える、プロダクト開発組織構築への挑戦|Micoworks株式会社|note

                                                                  こんにちは。顧客体験のパーソナライズを実現するマーケティングSaaS「MicoCloud」を提供する、Micoworks株式会社の開発責任者をしております、久森と申します。 Micoworks以前は、メガベンチャーでのSRE的な業務や担当スタートアップの立ち上げ支援、政府関連の業務など、様々なところで技術者として働いていました。この度縁あって、Micoworksのプロダクト開発組織づくりを拝命することになりました。 ▼私自身のキャリアや、Micoworksにジョインした理由についてはこちらのnoteをご覧ください。 「成長軌道に乗った事業の勢いをより加速させるために、プロダクト開発組織をどのように組成していくべきなのか」は、全てのスタートアップの持つ関心事だと思います。 今回の記事では「年300%成長するプロダクトを支える組織のカルチャー形成」をテーマに、今まさにスタートさせたカルチャー形

                                                                    高い事業成長の実現には、健全なカルチャーが必要。年300%成長SaaSを支える、プロダクト開発組織構築への挑戦|Micoworks株式会社|note
                                                                  • AIと一緒にプロダクト開発推進!初心者がChatGPTと一緒にユーザーストーリーマッピングをやってみた - asoview! Tech Blog

                                                                    バックエンドエンジニアの川又です。 入社2ヶ月レポートを投稿してからもう半年が経ちました。時間の経過が早すぎてびっくりです。 最近は今月末取得予定の夏休みをどう過ごそうか考えるのが楽しい毎日です。 tech.asoview.co.jp さて、今回はユーザーストーリーマッピング初心者メンバーがChatGPTを活用しながらストーリーを洗い出してみた事例についてご紹介します。 はじめに 背景 どうしてChatGPTに助けを求めたか 前提 ChatGPTと一緒にユーザーストーリーマッピングしてみた ユーザーストーリーマッピングとは何かを説明してもらう ペルソナを考えてもらう 行動を洗い出してもらう ストーリーを洗い出してもらう Let's ユーザーストーリーマッピング 事前インプット 行動の見直し ストーリーの見直し ChatGPTを活用してよかったこと・感じたこと 時間が短縮できた 事前インプッ

                                                                      AIと一緒にプロダクト開発推進!初心者がChatGPTと一緒にユーザーストーリーマッピングをやってみた - asoview! Tech Blog
                                                                    • Basecamp社のプロダクト開発メソッド「Shape Up」を6ヶ月実践した振り返り - Grooves開発ブログ

                                                                      こんにちは。grooves エンジニアの福井(@bary822)です。 突然ですがみなさんはスクラム以外でソフトウェア開発を行ったことはありますか? 私はありませんでした。 私が社会人としてお金を頂きながらコードを書き始めた2014年頃、スクラムは当時としては画期的な概念をソフトウェア開発に持ち込んだ革新的な存在であり、それを採用しているのはいわゆる「イケてる開発チーム」でありました。そして私は幸運にもこのイケてるチームでソフトウェアエンジニアとしてのキャリアをスタートした一人だったのです。 それから7年という、この業界では長いとされる年月が過ぎてスクラムは大衆化しました。私の感覚ではWeb界隈の自社開発企業ではデファクトスタンダードになっていると思います。 実際、Forkwell Jobsで「スクラム」と検索すると300件以上の求人がヒットします。組織の実情や置かれている環境によってその

                                                                        Basecamp社のプロダクト開発メソッド「Shape Up」を6ヶ月実践した振り返り - Grooves開発ブログ
                                                                      • エンジニアだった頃に知っておきたかったプロダクトマネジメント【連載:小城久美子のエンジニアのためのプロダクト開発】 - エンジニアtype | 転職type

                                                                        本連載では、プロダクト開発に携わるエンジニア読者向けに「成功につながるプロダクト開発」を実現するためのプロダクトマネジメントの基本の考え方や応用テクニックを、国内外の企業の優れたプロダクト開発の取組みを事例にとり、小城久美子さんがエンジニア向けに紹介・解説。明日からすぐに使える「いいプロダクト開発」をかなえるヒントを提供します。 小城久美子(@ozyozyo) ソフトウェアエンジニア出身のプロダクトマネジャー。ミクシィ、LINEでソフトウェアエンジニア、スクラムマスターとして従事したのち、『LINE CLOVA』や『LUUP』などにプロダクトマネージャーとして携わる。そこでの学びを活かし、Tably社にてプロダクトマネジメント研修の講師、登壇などを実施。書籍『プロダクトマネジメントのすべて』(翔泳社)共著者 はじめまして、小城久美子です。 私はエンジニア出身のプロダクトマネージャーで、『プ

                                                                          エンジニアだった頃に知っておきたかったプロダクトマネジメント【連載:小城久美子のエンジニアのためのプロダクト開発】 - エンジニアtype | 転職type
                                                                        • 【日本のプロダクト開発、おかしな常識】コンサルの3つの限界/GAFAはコンサルと無縁/米国の株主は日本の100倍厳しい/保守運用に偏る予算/シリコンバレー流プロダクト開発【LinkedIn曽根原春樹】

                                                                          ▼続きはこちらから https://bit.ly/3LUFXAx ▼アプリでは広告なし、バックグラウンド再生が可能 https://app.adjust.com/1era46rf <目次> 00:00 ダイジェスト 01:07 日本のプロダクト開発、おかしな常識 10:08 人に投資することの重要性 16:50 コンサルへの依存が及ぼす影響 22:37 シリコンバレー流のプロダクト開発 34:39 次回予告 <ゲスト> 曽根原春樹(X:@Haruki_Sonehara)|LinkedIn米国本社 シニアプロダクトマネージャー シリコンバレーのビック・テックやスタートアップ企業でBtoB・BtoC双方のプロダクトマネジメントを計10年以上経験。Udemyでの講座の受講者は3万人を超える。共著に『プロダクトマネジメントのすべて』など。 ※発言は個人のものであり、所属企業を代表するものでは

                                                                            【日本のプロダクト開発、おかしな常識】コンサルの3つの限界/GAFAはコンサルと無縁/米国の株主は日本の100倍厳しい/保守運用に偏る予算/シリコンバレー流プロダクト開発【LinkedIn曽根原春樹】
                                                                          • プロダクト開発における“難しさ”をモデル化してみよう 「意思決定」と「可観測性」の視点から考える、UGC特有の課題

                                                                            登壇者の自己紹介 rokuroku氏:それでは「UGCプラットフォームの難しさをモデル化する」ということで、私、rokurokuが発表いたします。 最初に自己紹介をしたいのですが、私はrokurokuといいまして、今はpixiv事業本部の小説マンガ百科部という、長い名前のところでテックリードをやっています。 もともとは、アプリ開発やバックエンド設計、あとはデータ分析みたいなことをやっていたのですが、最近はプロダクトマネジメント周りの仕事をしていて、今日はそうした話をできればなと思います。 プロダクト全体のことを考えようと思うと途端に雲をつかむような話になってくる 突然ですが、みなさん、プロダクト開発って難しくないですか? プロダクトの特定の一部の話だったらまだわかりますが、プロダクト全体のことを考えようと思うと、途端に漠然としてきて雲をつかむような話になってくると思います。今日は、そういう

                                                                              プロダクト開発における“難しさ”をモデル化してみよう 「意思決定」と「可観測性」の視点から考える、UGC特有の課題
                                                                            • SaaSスタートアップのプロダクト開発(シード〜シリーズA編)|河内 佑介 |カミナシ

                                                                              カミナシでCOOをしている河内です。 カミナシでは、現場で働くノンデスクワーカー向けにSaaSプロダクトを提供しています。 2020年6月にリリースしたプロダクトの導入社数は右肩上がりで伸び続けており、毎日数十万件のデータが紙の代わりにモバイルで提出されるまでに成長しました。 カミナシ上で提出されたデータ数推移SaaSスタートアップの成長ステージを 1. Product-Market-Fit期(プロダクト価値の検証) 2. Go-To-Market-Fit期(ビジネス戦略の検証) 3. Growth & Moat期(事業スケールと参入障壁の構築) の3つに分類すると、カミナシは「3」のステージに入りつつあります。 今回は、SaaSスタートアップであるカミナシのプロダクト開発をテーマに ・3つの成長ステージに応じて、どのように体制が変遷したか ・いま具体的にどんなことに取り組んでいるか を書

                                                                                SaaSスタートアップのプロダクト開発(シード〜シリーズA編)|河内 佑介 |カミナシ
                                                                              • UXデザインを取り入れたプロダクト開発を教科書通りにやってみた - ROBOT PAYMENT TECH-BLOG

                                                                                私は組織のプロダクトマネージャーとして、日々新しいプロダクトや機能の開発に携わっています。最近、私たちの組織ではプロダクト開発にUXデザインプロセスを取り入れることにしました。私たちが取り組んでいる具体的なプロセスについて、皆さんにお伝えしたいと思います。 まず、UXデザインプロセスとは、ユーザーエクスペリエンス(User Experience)を向上させることを目的としたデザインプロセスです。これにより、プロダクトがユーザーにとって使いやすく、魅力的であり、効果的なものになることが期待されます。私たちはこのプロセスを取り入れることで、プロダクトの競争力を高め、ユーザーからの満足度を向上させることを目指しています。 それでは、新しい機能を作る際に私たちが実際に行ったプロセスを紹介します。 1.ユーザーインタビューを行い課題を把握 新しい機能開発の第一歩として、まずはユーザーインタビューを行

                                                                                  UXデザインを取り入れたプロダクト開発を教科書通りにやってみた - ROBOT PAYMENT TECH-BLOG
                                                                                • 機械学習のプロダクト開発におけるデプロイパターン - Qiita

                                                                                  はじめに この記事はCourseraのコース「Introduction to Machine Learning in Production」を受講し、要点をまとめたものです。そのため、人に読んでもらうということよりは、自分で後で見返したときに思い出すことを目的とした記事なので、誤りや見づらい点がございましたらどうぞ遠慮なくご指摘頂ければ幸いです。 本記事では、機械学習システムをデプロイする際のユースケースやケースに応じたデプロイパターンについて解説します。 ここでは3種類のデプロイパターンについて紹介されています。 シャドーモード カナリアデプロイ ブルーグリーンデプロイ それぞれについて詳しく見ていきます。 シャドーモード 下図は教材動画から転載したものです。教材ではスマートフォン製造過程における検査業務のシステム化を例にしてます。 このデプロイ方法では、初期段階では機械学習モデルの出力

                                                                                    機械学習のプロダクト開発におけるデプロイパターン - Qiita