エンジニアバブルの終焉についてお話したものが2023年5月28日。あれから半年が経ち明確に転職時の給与についても影響が現れ始めました。スカウト媒体や人材紹介の状況を踏まえつつお話していきます。企業、候補者、そしてその間にある人材事業の事情と思惑を整理していきます。 有料設定していますが、最後まで無料でお読みいただけます。もしよければ投げ銭感覚で応援をお願い致します。 伸び悩む給与提示2022年以前であれば積極採用企業が複数集まることで競りのような現象が起き、現年収に対し1.25倍以上の提示が見られました。これは「社内で出世するより転職した方が年収が上がる」という言説に繋がって行きました。 現在では現年収据え置き、もしくは+50万円程度が相場になっています。給与が大きく上がる場合は現職の待遇が相場より悪く、そのまま入社すると自社の給与水準より低くなる場合や、新卒より低くなるためといった背景が
みなさんこんにちは。@ryuzeeです。 スクラムにおいて、スクラムチーム全体のパフォーマンスをどのようにして上げていくかは難しいテーマですが、プロダクトオーナーの視点でこれを捉えた「10 things you must do to build high-performing Scrum Teams as a Product Owner」という記事が良い記事だったので、翻訳したものをご紹介します。 翻訳に際しては、著者のMaarten Dalmijnさんに快諾いただきました。 なお、著者のMaartenさんはほかにもプロダクトオーナーに関する有用な記事を書いているので、参考にするとよいかと思います。 プロダクトオーナーの開発チームへの関わり方は、開発チームのパフォーマンスにおいてとても重要です。ダメなプロダクトオーナーだと、ハイパフォーマンスチームを簡単に潰してしまう可能性があります。 私
ChatGPTに共有するインタビュー内容について インタビューは1年前、社内のPM、PdM、エンジニアの方など計10名程にお話を伺いました。インタビューの経緯や詳細を知りたい方はこちらのブログをご覧ください。 インタビューのテーマはクラメソのデザイナー像（現状や理想）についてです。事前に質問を準備しましたが、半構造化インタビューの形式を取っていたことやインタビュアーと書記はチームの各メンバーがランダムに行っていたことがあり、人によって質問や解答の項目が異なります。ChatGPTが認識しやすくなるように項目を揃えることも考えましたが、あえて多少バラつきのある項目でも対応できるのか興味があったので、項目も文体もそのままで共有します。ただし具体的な案件名やメンバーの氏名、クラスメソッドという弊社名に至る固有名詞まで全てイニシャルに置き換えておきます。 また、今回はニールセン博士の理論に基づき、5
【資料公開】プロダクトマネージャーのしごと
みなさんこんにちは。@ryuzeeです。 2023年10月17日に行われたオンラインイベント「プロダクトマネージャーのしごと - Forkwell Library #33」の登壇資料を公開します。 内容は、新刊書籍『プロダクトマネージャーのしごと』に関するものなのですが、30分という時間で全部を網羅的に紹介するのは無理ですし、ぜひ本書を読んでいただきたいので、僕が気に入っているところと、本書全体を通して中心にある考え方を紹介しました。 ちなみに書籍は16章から構成されていて、そのなかで特に自分が好きなのは「7章 「ベストプラクティス」のワーストなところ」です。 職業柄、日頃から「プロダクトマネジメントではどんなフレームワークを使うといいですか？」「プロダクトマネジメントの日本での成功事例を教えてください」「プロダクトマネジメントのベストプラクティスを教えてください」のような質問をたびたびい
AWSでログ集約システムを構築する
トラストバンクのパブリテック事業でPdM兼エンジニアとして自治体向けSaaS企画開発運用。JAWS初心者支部とLWTTの運営。AWS Samurai2019。興味:AWS/Python/kintone/SaaS/Cloudflare/
要件定義失敗と改善の歴史 ~ その時、要求・ユーザーストーリーをどうまとめ、どう改善してきたか ~ - 株式会社ヘンリー エンジニアブログ
こんにちは。ヘンリーCEOの逆瀬川です。 開発する上で、難しい部分の一つである要件定義。 最近、社内では「要求仕様」と呼ばれるようになり、要求仕様化のプロセスとフォーマットの改善に取り組んでいます。しかし、3年間にわたって苦労し、失敗と改善を繰り返してきた歴史があります。 本ブログでは、主にプロセスとフォーマットの失敗について触れますので、詳細は割愛します。「ココもっと深く知りたい！」という方は、ぜひカジュアルにお話しましょう。その場で深堀りいただいた内容を元に、更にブログで考察していきたいと思います。 では、過去私たちが体験した5つの時代と今後訪れるだろう要求開発黄金時代についてお話しましょう。 ユースケースで仕様漏れた時代 要求導入混沌時代 要求を全員で書くぞ時代 プロダクト要求と仕様を分けて書き始めた時代 CSと連携して速度が上がり始めた夜明け前 将来訪れるだろう要求開発黄金時代へ
昨日「動いたけどチームメンバーを説得するのが面倒で、秘蔵のブランチになってしまう」って言ったけど、この気持ちはどこから出てくるのか。 分かりやすい Cons があると、反発が予想できて、その反発を解決するところまで労力を割くほどの気持ちが無いので困る。「直ちに問題になるわけじゃないが、どちらかというとやった方がいい、でもリスクもある」という選択肢を選べずにズルズルと現状維持に向かう圧力は、ある。チームの同質性が高いうちはほとんど困らないんだが、人数が増えたり、別の職種が増えたりするごとに「面倒」さはどうしても増していく。 我々の信念として以下を持ってはいるが、現状維持に向かう圧力がある中で変化を加えるのはそこそこ労力が要り、閾値を超えると変化が発生しなくなってしまう。 業務・開発フローは「変えることは無条件に正しい」くらいに思って良いと思っています。 素早く変えてもし仮にダメだったら素早く
「日本のエンジニアは不足しているというけれど本当？ その原因は？」 「わが社でもエンジニアが不足していて困っている、何かよい解決法はないか？」 いまこの記事を読んでいる方は、そのような疑問や悩みを持っているのではないでしょうか？ 「エンジニア不足というのはウソだ」と主張する向きもありますが、実際にデータを見ると確実にエンジニアは不足しています。 2018年時点の調査で22万人、このままいけば最悪の場合は2030年時点で79万人が不足すると予想されているのです。 原因として考えられるのは以下のようなことです。 ・IT市場が急成長している ・技術革新のスピードが速い ・エンジニアの高齢化が進んでいる ・IT業界の労働環境がよくない そして、この解決のために企業がとれる対策としては、以下が挙げられます。 ・エンジニアの待遇を改善する ・社内で人材を育成する ・海外人材を活用する そこでこの記事で
「なぜ？」を使わずに、理由を深掘るコミュニケーション
株式会社オープンエイト、PMグループの辻です。 ここでは、プロダクトマネージャーとして働いています。ということで・・・ プロダクトマネージャーのしごと 少し前に話題になった本、皆さんも読みましたか？ この本は、これまでのプロダクトマネジメント関連の書籍と比べて、リアルな現場の目線に近いカタチで書かれており、参考になった以上に、とても勇気をもらえる１冊でした。 これまでのプロダクトマネジメント関連の本 どちらかと言うと教科書的なものが多い 参考にはなるが、自社や自分の置かれた環境で上手く実践まで持っていくのが難しい そんな印象を抱かれている方も多いのではないでしょうか？ これまでのプロダクトマネジメント関連の本。たとえば、コレ。 これはこれで、オススメです。 この本の特徴・効能 一方で「プロダクトマネージャーのしごと」を読むと、 世界的に著名なプロダクトマネージャーであっても、自分と同じよう
「プロダクトマネージャーがプロダクトマネジメントを失敗させる!?」大企業病の罠を乗り越え若々しいチームを実現する/Traps of Optimization in Product Management 2024
「プロダクトマネージャーがプロダクトマネジメントを失敗させる!?」カオスなプロダクト開発を効率化したら硬くて息苦しい官僚組織になっちゃった! 大企業病の罠を乗り越え若々しいチームを実現するぞ 効率化を進めていったら息苦しい組織になってきたと悩む方に向けたセッションです。 概要 https://confengine.com/conferences/regional-scrum-gathering-tokyo-2024/proposal/19268 発表者 https://twitter.com/_N_A_ https://note.com/mryy 関連スライド 「私考える人、あなた作業する人」を越えて、プロダクトマネジメントがあたりまえになるチームを明日から実現していく方法 https://speakerdeck.com/moriyuya/product-management-rsgt20
はじめに 昨今「開発生産性」についての話題をよく目にします。 生産性が向上することで悪いことは無いので、様々な組織の事例が公開されて業界全体に知見が共有されていくことはとても素晴らしいことだと感じています。 話題のこちらの本 「世界一流エンジニアの思考法」にもとても大切なことが書かれておりますし こちらの記事も参考になりました。 それらを踏まえて個人的に生産性向上のベースになる大切なことだと思っている 「即レスの大切さ」 について書きたいと思います。 これまでやってきたお仕事 ツールアプリの新規事業責任者（3年ほど） 全体3名の少人数チームでスタート 私（責任者+PdMの役割）、エンジニア1名、デザイナー1名 最終的には30人前後の組織の事業部長 ゲームアプリのマーケティングマネージャー（5年ほど） 組織全体としてはビジネスサイド20名、エンジニア5名、デザイナー5名ほど 会社経営（4年ほ
UIUX デザイナーと仕事をする際にプロダクトマネージャーとして持っておきたい 8 つのマインドセット｜Fritz | Lead Product Manager @ Mercari
2020 年に入り、メルカリ US ではプロジェクトの担当 PDM を検討する際に「UIUX に大きな変更が入るならこの人」「関係者マネジメントが重要ならあの人」「テクニカルな知識が要求されるならこの人」といった具合に、プロダクトマネージャーそれぞれの特性・得意分野を考慮したうえで決定する傾向が以前にも増して強くなりました。 その結果、自分（フリッツ と申します、こんにちは）の場合は UIUX 改善を中心としたプロジェクトが相当に増え、並行して 3-4 名の UIUX デザイナーとそれぞれのプロジェクトについて議論することが毎日の風景となりました（めっちゃくちゃ楽しい）。 こうした状況下にあって、あらためて デザイナーと UIUX について議論・もしくはフィードバックをする際に気をつけている・気をつけたいことについて前後編にわけて振り返りをしたので共有してみたいと思います： ・前編（この記
プロダクトマネジメントプロセス概要
より価値を届けていくためにどのようにプロダクトマネジメントをすればよいのか？をまとめてみました。
エンジニアが仕様案を手戻りさせるアンチパターンはもう終わりにしよう - yigarashiのブログ
プロダクト開発のアンチパターン プロダクトオーナー（PO）が仕様案を持ってリファインメントや計画に臨み、エンジニアが実現可能性や曖昧さの観点からダメ出しをして手戻りが起こる……スクラムやデュアルトラックアジャイルを志向する組織においては、一度は目にする光景だろうと思います。しかしこれは、以下のふたつの理由からひどいアンチパターンであると言えます。 ひとつには、仕様案を持って臨むPO側の精神的な負担があまりにも大きいやり方だからです。ちゃんとした仕事をしているPOならば、そもそも仕様案なんていう細かいところにたどり着くまでに、とてつもない量の不確実性を捌いてボロボロになっているのです。プロダクトのミッション、戦略、プロダクトゴール、ユーザーの課題、仮説検証の設計、MVPの特定、そういった大上段からのヘビーな分解を繰り返して、ようやくたどり着くのが具体的な仕様案なわけで、それを実装が難しいとか
みなさん、監視作ってますか？ システムを作ったら、そのシステムを監視していく必要がありますよね。どうやったら「いい監視」が作れるのでしょうか。「いい監視」とそうでない監視との違いとは、いったいなんでしょうか。 今の時代、「監視」ではなくて「可観測性」、 Observability (o11y) の時代になっていて、良いプラクティスや考え方が色々とあります。 この記事は、監視や o11y についての考え方を社内に共有するため書いたものを、社外共有用に調整し直したものです。新しい Observability の時代を、一緒に生きていきましょう。 監視を作ろう あなたはシステムを作りました。そのシステムに「監視」をつけようと思ったとき、最初にすることはなんでしょうか？ まずは、システムを何らかのツールで監視するところから始めましょう。やらなきゃはじまらない。 Nagios, Cacti, Mun
「デジタルマーケティング」とは具体的にどのようなものかを学ぶ初級講座です。「認知を得る」「認知を広める」「効果を改善する」の3つの視点からデジタルマーケティングの基本を学びます。いますぐ施策を実行するための無料のツールや導入事例もご紹介します。 「デジタルマーケティング」とは具体的にどのようなものかを学ぶ【初級】【入門編】の講座。 ビジネスにデジタルを活かすための「はじめの一歩」を学ぶ。 デジタルを活用する目的、ゴール設定、分析方法を学ぶ。 「認知を得る」「認知を広める」「効果を改善する」の3つの視点からデジタルマーケティングの基本を学ぶ。 いますぐ施策を実行するための無料のツールや導入事例もご紹介。
中島氏、イヌ氏の自己紹介 椿原ばっきー氏（以下、椿原）：まず1人ずつ紹介します。まず中島さんです。よろしくお願いします。中島さん、自己紹介をお願いしてもよろしいでしょうか？ 中島悠輔氏（以下、中島）：はい。はじめまして。中島悠輔と申します。株式会社SEVENRICH Accountingというところで、今はクリニック向けのシステムのプロダクトマネージャーを本業（として）やっています。ご縁があってLboseさんの副業PMの求人を拝見した時に「ぜひお話をうかがってみたいです」というところから、このようにしてお仕事を頂戴するところに今はなっています。 椿原：ありがとうございます。具体的な案件の話はあとであらためてちょっとしようかなと思うので。 中島：よろしくお願いします。 椿原：続きまして、（お名前が）斬新ですね（笑）。イヌさん。 イヌ氏（以下、イヌ）：はじめまして。イヌと申します。すみません、
以前は、DDDでどう実装したらいいかなぁって考えてたんだけど、最近は、そういうことへの興味があまりなくなっている。エンティティや値オブジェクト、集約やリポジトリなど、そのあたりにあまり興味がない。ヘキサゴナルアーキテクチャなども、そんなに考えなくなった。 TypeScriptを使うことが多いので、型でしっかり守るとかカプセル化するとか、そのあたりがどっちでもいっかという気持ちになっていることが影響してるとは思う。TypeScriptでクラスを使おうとはあまり思わないし。BrandedTypeみたいなのを使ってまで型で守ろうとは思わない。 じゃあ何に興味があるんだっけ？って考えてみると、トランザクション境界とユビキタス言語かな。 トランザクション境界 トランザクションの境界を作って、DB（RDBMS）を小さく保ちたいと思っている。DBが大きくなると、すぐに複雑になっていく感じがする。 だから
エムスリー執行役員VPoE兼PdMの山崎が、エンジニア、QA、デザイナー、プロダクトマネージャーにお薦めする良書7選 - エムスリーテックブログ
こんにちは。最近、お掃除職人きよきよ*1というYouTuberにハマってしまい掃除に明け暮れ、近所のドラッグストアでドメストとパイプフィッシュの原材料が同じことなどを知って、ふむふむと楽しんでいるエムスリー執行役員兼VPoE兼PdMの山崎です。薬剤を活用した掃除はDr. STONE*2気分で面白いですね。 本ブログはエムスリー Advent Calendar 2021の25日目の記事です。 エムスリー Advent Calendar 2021の締めとして、今年も「VPoEとしてこの◯年間を振り返って」シリーズで2021年を締めくくろうかとも思ったのですが、先日fukabori.fmの第59回と第60回でしっかり語ったのと、流石に3年連続でやっていて4年目も同じネタだと皆さん飽き飽きするかなとも思ったので、本日は新企画として「エムスリー執行役員VPoE兼PdMの山崎が、エンジニア、QA、デザ
こんにちは！estieでビジネス部門の責任者をしている束原です。 2024年になりましたね。estieは決算月が12月なのですが、毎年期初に「今年こそが勝負の年だ」と言っている気がしており、それに対して「ガハハ」と笑い合えるメンバーで仕事ができているのが最高に楽しいなと日々痛感しております。 さて、こちらは事業の立ち上げ（事業開発）に関する記事です。 この記事に書いてあること estieでは「仮説検証」をやめようと思っている話 事業開発の成分の8割は営業だという話 かなり極論が並んでいますが(笑)、事業開発を進める上でとても重要だと考えているので、ご興味のある方は少しお付き合いください。 to Bスタートアップは仮説検証をやめようという話 「仮説検証って言葉が嫌いなんすよねー」と、確か弊社の事業責任者の齋藤だったか代表の平井だったかが以前社内で言ってました。 1年前くらいまで私は、その発言
実は相性が悪い「開発生産性」と「アジャイル」。うまくいかない開発を好転させるためにPMがやるべきこととは【ryuzee|吉羽龍太郎】
TOPインタビュー実は相性が悪い「開発生産性」と「アジャイル」。うまくいかない開発を好転させるためにPMがやるべきこととは【ryuzee|吉羽龍太郎】 実は相性が悪い「開発生産性」と「アジャイル」。うまくいかない開発を好転させるためにPMがやるべきこととは【ryuzee|吉羽龍太郎】 2024年3月26日 株式会社アトラクタ Founder兼CTO／アジャイルコーチ 吉羽 龍太郎 1973年生まれ。野村総合研究所、Amazon Web Servicesなどを経て、2016年1月から現職。アジャイル開発、DevOps、クラウドコンピューティング、組織開発を中心としたコンサルティングやトレーニングを専門とする。著書に『SCRUM BOOT CAMP THE BOOK』（翔泳社）、訳書に『チームトポロジー』（日本能率協会マネジメントセンター）、『プロダクトマネージャーのしごと』『エンジニアリング
はじめに この度は個人でmeta翻訳という翻訳サービスを開発しました。 現在Google翻訳を筆頭に、機械翻訳サービスは乱立していて、業界としてレッドオーシャンだと思いますが、meta翻訳は複数ある翻訳サービスの中でも日本語⇄英語の翻訳では最高精度だと自負しております。 なので、個人でも頑張ればレッドオーシャンに突っ込めるくらいの機械学習サービスを開発できるというお話しをしたいと思います。 ※個人開発とは思えないくらい高精度なので是非一度使ってみてください。 meta翻訳の精度 まず初めにmeta翻訳の精度を簡潔に紹介したいと思います。 専門的な文章を翻訳する場合 「storm surge」など、専門的な単語にきちんと対応できています。 また、「power」が「電力」と訳されているように、専門的な文脈も識別して翻訳します。 口語的な文章を翻訳する場合 実は専門的な文章よりも口語的な文章の方
何が問題視されているのかことの発端の一部は、Twitter日本法人のレイオフにからみ「話題を検索」タブの “ニュース” でのモーメントの掲載で、媒体側からTwitter側へのホットラインがあったという話です。 竹下郁子 @i_tkst確かにTwitterのニュースフィードは更新されてない気がする。私たちメディアは自社記事のモーメントを作成→Twitterキュレーションチームに連絡→審査の上ピックされたりされなかったり、という手順を踏んできたのだけど、この作業はしばらくは意味を成さないのかな？ 星 暁雄 (ITと人権) @AkioHoshiキュレーションチームは全員解雇。 同チームはモーメントタブをキュレーションし、トレンドトピックのセクションをプログラムし、それらのトピックに関するコンテキストを提供し、ライブイベントも扱っていた。またプラットフォーム上の誤情報との戦いにも取り組んでいた。
はじめに こんにちは、CARTA HOLDINGSでエンジニアをしているこんちゃん(@konchanSS)です。 この記事は筆者が新しく発足したプロジェクトのシステムを外部委託で作った経験をチームで振り返った際に得た学びを『システムを作らせる技術』によって補強したものです。 この記事を読んでくれた方は是非『システムを作らせる技術』を一読して欲しいです。 システムを知らないあなたにこそ読んでほしい この記事はビジネスサイドや、PdMだったりマネージャーといったいわゆるシステムの開発を依頼する側の人たちに向けて書いています。 意図した通りのシステムを作ってもらうための術を知ることはあなたにとって以下のメリットがあります。 意図した通りにシステムが動くことで業務の効率的になる 貴方がやろうとしているビジネスを促進させる システムを作ってもらうための術を知ることがなぜそのようなメリットを享受できる
0→1フェーズで最も重要なサービスコンセプトのつくり方 | 実プロジェクトの事例付き｜梶谷健人 / 新著「生成AI時代を勝ち抜く事業・組織のつくり方」
サービスを0→1でつくる上でまず必要になるのが、サービスのコンセプトづくりです。 いままで自社事業や様々な企業との共同プロジェクトを通じてサービスづくりに取り組む中で、サービスのコンセプトづくり、すなわちコンセプトメイキングのプロセスにもある種の型があることに気付きました。 このnoteでは社内ドキュメントである「サービスコンセプトのつくり方」の内容を一部NDAでシェアできない資料を除いて全公開します。 ＜コンセプトメイキングの大前提＞🧐 STEP１：コンセプトとは何かを知ろうコンセプトが何かを知る上で、コンセプトの立ち位置と役割を知ろうコンセプトそれ自体は様々な形があり、非常に漠然としている。 なので、コンセプトがそれ以外の要素とどういった関係にあるのか、どういった役割を果たすのかという観点からコンセプトとは何かを理解しよう。 まずサービスアイデアは下図のような構造を持っている。 ある
架空プロジェクトを通してシステム開発とドキュメント作成を体験してみる（2022 Late） - Qiita
このコンテンツ作成の背景 プログラミングを体験できるコンテンツは沢山存在していますが、開発プロジェクト全体を通した流れを体験したり、実務では不可欠となるドキュメント作成を体験（学習）できるコンテンツは少ないので作ってみました。 とはいえドキュメント作成についてはテンプレート見ながら「こんなもんです」と解説する感じになります。。。 免責事項（いいわけ） 元々は社内の非技術系な人向けに研修用資料として作っていたものを、どうせなら公開するかな。という感じで再編したものなので、足りない部分やオレオレな部分、ゆらぎ、不整合、誤字脱字とかも多いと思います。「間違い」や「こうしたほうがいいよ」というのがあれば、コメント等で"優しく"教えていただけると助かります。少しずつ修正していこうと思ってます。 オレオレな情報だけでは申し訳ないので、一般社会ではプロジェクト関連のドキュメントはどう書くのか？については
こんにちは、こんばんは。年末年始は12/24〜1/9まで17連休を取ってみた執行役員CTO兼VPoPの山崎です。この連休に向けてスノーピークのIGTを買おうと思ったのですが、3ユニットのノーマルと4ユニットのロングどちらを買うべきか、悩みに悩んで、結果ノーマルを2つ買えば6ユニット！ということに気がついて平穏を取り戻しました。もちろんリビングシェルロングProも調達しました。あとは年越しキャンプの予約を取るだけです（さっさと取らないと）。 本ブログはエムスリー Advent Calendar 2022とプロダクトマネージャー Advent Calendar 2022の25日目の記事です。 双方の読者に届くようにダブルエントリーしてみました*1。 昨年は以下のとおり、エンジニア、QA、デザイナー、プロダクトマネージャーのためになりそうな良書を7冊選んでみました。未読の方がいれば是非読んでみて
このブログは、 IVRy 紅白Advent Calendar 2023の白組・17日目の記事です。 白組16日目は PdM佐瀬さん「IVRyなら上流からUX/UIデザイン業務が実践できます！」でした。明日はIVRyのVPoE近藤さんの「IVRyにおける開発生産性へのアプローチ～SPACEフレームワークの視点から～」についての記事が出ます。乞うご期待。 この記事について タイトル通り、2023年に提案されて改善した事を発表するのですが、裏返すと「そんなこともできてなかったのか」と見える内容もあるかもしれません。ネガティブに受け取られる可能性もあるかもしれませんが、IVRyのオープンな社風や、常に改善と変革に前向きな姿勢をアピールするためにも、この記事を執筆することにしました。 なお、課題を発見・解決しながら会社を大きくしていきたいエンジニアの皆さんは、ぜひブログ一番下のIVRyの採用情報から
プロダクト作りにはさまざまな「罠」がある。機能の開発とリリースに集中してしまい、顧客の本当の課題、プロダクトの本当の価値がおざなりになってしまう状況のことを「ビルドトラップ」と言い、プロダクトを開発する組織において陥りやすい「罠」の一つだ。なぜこの問題が起こるのか。どうすれば、本質的なプロダクト作りに立ち戻れるのか。『プロダクトマネジメント――ビルドトラップを避け顧客に価値を届ける』の訳者であり、アジャイル開発や組織改革のトレーニングなどを行う専門家、吉羽龍太郎氏が語った。 大事なのはアウトプットではなく、アウトカムとインパクト 吉羽氏はアジャイル開発やDevOps、クラウドコンピューティング、インフラ構築自動化、組織改革を中心にオンサイトでのコンサルティングやトレーニングを提供する専門家。吉羽氏がCTOを務めるアトラクタも同様のサービスを提供している。また吉羽氏は青山大学では非常勤講師と
Pythonのパッケージ・プロジェクト管理ツールはまだ乱立状態にあって、どれを使えばいいのかわからないから慣れたpyenv+pipを使おうという判断をする人がいるかもしれない。その判断自体は別に否定しないけれども、初心者に教える時にpyenvを教えるのはもうそろそろやめてほしい。 Pythonをソースからビルドするので、コンパイラや依存ライブラリを事前に揃えないといけない。依存ライブラリが足りないと中途半端なPython環境もできうる。 デフォルトで最適化オプション(PGO+LTO)が付いてないので、最適化ビルドしたPythonより~5%程度遅い Windowsで使えない Rye, pdm, Hatch などは python-build-standalone と呼ばれるビルド済みPythonをインストールする機能があるので、これらの欠点が存在しない。 Pythonをインストールするところま
ProductZine Day＆オンラインセミナーは、プロダクト開発にフォーカスし、最新情報をお届けしているWebメディア「ProductZine（プロダクトジン）」が主催する読者向けイベントです。現場の最前線で活躍されているゲストの方をお招きし、日々のプロダクト開発のヒントとなるような内容を、講演とディスカッションを通してお伝えしていきます。
生成AI時代におけるUXデザイン | 生成AIをフル活用したUX設計手法＆生成AI時代のユーザー体験の変化について
ChatGPTやStable Diffusionなどの生成AIが急速に発展し、社会全体が大きく変化しようとしている。 UXデザインのプロセスや、UX自体のあり方も当然革新されていく。 今回はそうした生成AIによってUXがどう変化していくかを、具体的なメソッドや未来洞察といった具体・抽象を行き来しながら話していく。 1. 生成AIを活用したUXデザインプロセス どのようにGenerative AIを活用すれば、UXデザインのプロセスをよりなめらかに、効率的にすることができるのか？ 2. 生成AIでUX自体がどう変化するか Generative AIの発展によって、プロダクトにおけるユーザー体験のあり方はどのように変化していくのか？ 3. AI時代のデザイナー/PdM生存戦略 AI時代に、デザイナーやプロダクトマネージャーなどの個人はどのように強みを磨いていけばいいのか？ ▼ スピーカーTwi
この記事は、以下サイトの機械翻訳です。 何を作るか（あるいは次に何を作るか）を決めることは、プロダクトマネージャーの仕事の中で最も重要な部分の一つです。インパクトを与えるチャンスは何度もありません。だからこそ、賢く選択して、チャンスを最大限に生かすことが重要なのです。 プロダクトの優先順位を決めるには、さまざまな要素を考慮する必要があります。しかし、何よりもまず、お客様の真の問題を解決することを優先しなければなりません。多くの企業では、このプロダクト開発の基本方針が守られていません。おそらく、価値よりも革新性を優先しているからでしょう。私たちは皆、自分たちが最先端の先駆者であると他人に思われたいと思っていますが、市場が求めているのは必ずしもそうではありません。 市場が求めているのは、すでに機能しているものを適度に改良することだったりします。究極のゲームチェンジャーを追い求めるのではなく、フ
はじめに こんにちは、ゆずたそ（@yuzutas0）です。この連載では、ソフトウェア開発者からプロダクトマネージャーに転向した筆者が、多くの失敗を経て重要性を痛感した「プロダクトマネージャーのマインドセット」を解説します。 主な対象読者としては、同じようにソフトウェア開発を出自とした方で、「同じような失敗経験のある方」「これから失敗を経験するであろう方」を想定しています。連載の前提条件の詳細、免責事項などについては、第1回の冒頭を併せて参照ください。 トレードオフが生じる場面 今回は意思決定について扱います。たとえステークホルダーの協力を引き出し、どれだけ試行錯誤しても、どこかでトレードオフが生じることになります。関係者全員が問題と向き合い、議論を整理した上で、それでも一つの結論にならないという場面が訪れます。そこではプロダクトマネージャーとして意思決定を求められます。 画面に表示するテキ
https://2022.pmconf.jp/session/BCrdkstd
こんにちは。Findy Freelanceの開発チームでエンジニアをしている2boです。 この記事では私が開発生産性を上げるために開発をする前に考えていることについて書きます。 ここで「開発をする前」というのは次のようなタイミングを指します。 PdMなどから新規施策の仕様について相談を受けたとき 起票された開発Issueを最初に確認するとき 自分がIssueを作成するとき なぜこのタイミングで考えるかというと、開発を進める上での方向性を間違える可能性を減らし後から軌道修正をしやすくするためです。 なおこの記事においては、開発生産性を「開発成果物の提供価値を投入リソースで割ったもの」とします。 いくら頑張って開発をしても、そもそもやるべきことの方向性を大きく間違えると提供価値が0に近づくため開発生産性が低下します。 特に開発が高速なチームで方向性を誤ると高速に間違った方向へ進んでしまうことに
「Product Roadmaps Relaunched」（オライリー未邦訳）がプロダクトマネージャーにとって非常に良書 - SaaSベンチャーで働くエンタープライズ部長のブログ
プロダクトロードマップに関する書籍を探していたら、「Product Roadmaps Relaunched」に辿り着きました。未邦訳なので英語で読んでいったのですが、非常に良い本です。 Product Roadmaps Relaunched: How to Set Direction while Embracing Uncertainty (English Edition) 作者:Lombardo, C. Todd,McCarthy, Bruce,Ryan, Evan,Connors, MichaelO'Reilly MediaAmazon アウトカムベースのロードマップ(Outcome Based Roadmap) プロダクトマネジメントでは「アウトプット」と「アウトカム」がよく比較されます。アウトプットは出てきた機能に対して、アウトカムは提供価値であり、プロダクトマネージャーはアウトカ
FastAPI入門 - モダンなPythonフレームワークの特性をチュートリアルで手軽に学ぶ｜ハイクラス転職・求人情報サイト AMBI（アンビ）
FastAPI入門 - モダンなPythonフレームワークの特性をチュートリアルで手軽に学ぶ PythonのWebフレームワークとしていま注目を集めるFastAPIは、シンプルにコードが書けるだけでなく、パフォーマンスが高いWebアプリケーションのバックエンドサーバーが構築可能です。同フレームワークの勘所をPythonスペシャリストの杜世橋さんが、初心者向けのハンズオン、そしてより実践的な画像への自動タグ付けサービス実装をとおして解説します。 FastAPIはいま非常に注目されているPythonのWebフレームワークの1つです。Flaskのようにシンプルに書ける一方でPythonのType Hintの機能をうまく活用し、HTTPのリクエスト/レスポンスをPythonの関数の引数/戻り値とシームレスにマッピングして非常に効率的に開発ができるのが最大の特徴です。非同期処理にも対応していてその名
株式会社ラクスが開催するエンジニア向けのイベント「RAKUS Meetup」。今回は「Vue.js、React、TypeScript、E2Eテスト」をテーマに、「楽楽勤怠」の機能開発を担当する北嶋初音氏が登壇し、「Vue.js + TypeScriptによる新規サービス開発の振り返り」という内容で話をしました。関連資料はこちら。 会社初のフロントエンドエンジニア 北嶋初音氏（以下、北嶋）：では、「Vue.js + TypeScriptによる新規サービス開発の振り返り」と題して、UI開発課の北嶋初音が発表を始めたいと思います。 まず軽く自己紹介します。名前は北嶋初音と言います。経歴ですが、2016年の4月からWeb系のITベンチャーに新卒入社しまして、Webエンジニアとしての経験を積みました。次は自社サービスを作っている会社で働きたいという気持ちがあったので、転職活動を始めて、今年の1月から
プロダクト開発のユーザーを絞って考えることの重要性とsuper-specific whoの考え方 ｜PM Club
プロダクト開発において、ユーザーを絞って考えることの重要性と"super-specific who"という考え方や決め方について解説しています。
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「転職した方が上がる」エンジニア給与バブルの終焉と、雑すぎる一部人材紹介会社｜久松剛／IT百物語の蒐集家
【翻訳】ハイパフォーマンスチームを作るためにプロダクトオーナーがすべき10のこと
ChatGPTにペルソナを作ってもらったら完成度が高かった | DevelopersIO
チームに浸透させるのが近年では難しくなっている - id:onk のはてなブログ
エンジニア不足が加速する日本｜現状と原因、対処法をくわしく解説 - GALK（ガルク）
生産性における即レスの大切さ - Qiita
監視の考え方 〜あるいは可観測性とはなんなのか〜 - estie inside blog
講座情報詳細｜はじめてのデジタルマーケティング （METI/経済産業省）
副業PMが正社員PMと同じ認識を持てるように Notionを活用して自社制作したプロジェクト管理ツール
DDDの実装にはあまり興味がなくなっている - Mitsuyuki.Shiiba
to Bスタートアップは「仮説検証」をやめようという話 - estie inside blog
世界最高の翻訳サービスを個人で開発した話【meta翻訳】 - Qiita
Twitterは特定のメディアを優遇し、さらに「トレンド操作」をしていたのか
失敗から学ぶシステム開発委託 - CARTA TECH BLOG
エムスリーが誇る最強のプロダクトマネージャー育成環境：プロダクトマネージャー定例 - エムスリーテックブログ
2023年・新しく入ったメンバーの提案で開発チームが良くなったこと5選
プロダクトマネジメントの罠「ビルドトラップ」とは？ アジャイルや組織改革の専門家、吉羽龍太郎氏が解説
pyenvを初心者に薦めるのはもうやめよう - methaneのブログ
「プロダクトマネージャーこそ、戦略的に読書せよ！」──最短で成果を出すための読書地図
プロダクトマネジメントの優先順位付けフレームワークの究極ガイド
再現性と質を高める「意思決定のフロー化」 ―― 開発畑のプロダクトマネージャーの失敗から学べ
プロダクトマネジメント組織立ち上げの課題と落とし穴と楽しみ #pmconf2022
開発生産性を上げるために開発をする前に考えていること - Findy Tech Blog
新規機能はどんどんコンポーネント化 Vue.js + TypeScriptで開発してよかったこと・つらかったこと