「私考える人、あなた作業する人」を越えて、プロダクトマネジメントがあたりまえになるチームを明日から実現していく方法/product management rsgt2023
4プロダクトを成功させようと悪戦苦闘しているものの、プロダクトの行く末についてプロダクトオーナーやプロダクトマネージャといった一部の人の意思決定に依存しすぎてしまっていると悩んでいるチームが、彼らと共にプロダクトマネジメントを実行できるようにするセッションです。「プロダクトオーナーがボトルネック」という状況から、おさらばしましょう。 概要 https://confengine.com/conferences/regional-scrum-gathering-tokyo-2023/proposal/17655 発表者 https://twitter.com/_N_A_ https://note.com/mryy
ビジネス・アーキテクチャとシステム・アーキテクチャ - Runner in the High
うちのコンサルが「システムアーキテクチャを決めるためには、ビジネスアーキテクチャを先に固めることが必要」と言ったら、お客様が「事業構造の変化が激しすぎてビジネスアーキテクチャを固めることが難しい」と仰った。 そうだよなぁ。システムの寿命よりビジネスの寿命のほうが短くなってるのかも— ボム / SIer (@bombombomb2017) 2021年8月29日 これにめちゃくちゃ共感した。 よくあるアーキテクチャ設計では、ドメイン層と応用層を分離することで応用層におけるコントロール不能な変化をドメイン層に及ばないようにさせたりする。しかし、現実のプロダクト開発ではDBやフレームワークなどの応用層で起きる変化よりもドメイン層の変化のほうが圧倒的に多い。システムにおけるすべての中心にあり、あらゆるところから依存されているドメインが頻繁に変化するとなると非常にツライ。 とはいえ、ビジネス・アーキテ
早くしっかりユーザに価値を届けるためのチケットの書き方 - SmartHR Tech Blog
こんにちは。PM（プロダクトマネージャー）のhiroki_Mです。 年末調整を担当しています。趣味はお絵描きと虚無になることです。 2年前に私が公開した記事「スクラムをうまく回すために受け入れ基準をきちんと書く」が、現在も思ったより多くの方にご覧いただいていることがわかりました。 スクラムやアジャイルについては様々な記事が出ているものの、現場目線での実体験に基づく情報を得たい人は多いのかも、と思い、前回書いたものをアップデートした記事を書くことにしました。 この記事では、「早くしっかりユーザに価値を届けるための、チケットの書き方のポイント」をテーマに、スクラムをうまく回す※ために気をつけるべきチケットの書き方のポイントについて書こうと思います。 やりたいことと開発者をつなぐのがチケットです。開発プロセスをカイゼンしても、チケットがきちんとしていないと、その効果は表れづらいです。逆に、やりた
Godot Engine - Free and open source 2D and 3D game engine
Godot Rendering Priorities: January 2024 4.2 brought a lot of improvements to Godot's renderer and ongoing work is paving the way for new features Dev snapshot: Godot 4.3 dev 2 After a well-deserved holiday break, the team is back on Godot 4.3 development at full speed, with o... Dev snapshot: Godot 4.3 dev 1 We're ending the year with an early sneak peak at the upcoming Godot 4.3 release with its
開発のスピードを上げたいならすべてのスコープを小さくしよう
ピナクルズの CTO をしている渋谷です。「現場向け動画 DX」を実現するための SaaS『tebiki』を開発しています。 今回は、「プロダクトの開発スピードを落とさずに、かつユーザーの芯を食ったソリューションを提供するためには、すべてのスコープをいかに小さくできるかが重要」だということについて書いてみたいと思います。 ちなみに弊社はこれを実践することで開発がものすごくスムーズになり、リリース頻度が体感で 50% くらい向上しました！ スピードは失われていく前提として、プロダクトの開発スピードは意識的に改善し続けなければ、機能の追加とともに失われていきます。 提供する機能の増加に伴い、仕様の辻褄合わせだとか実装の順番だとかの複雑に関連するパラメータも同時に増えてしまうので、結果として人や時間といった必要なリソースが指数的に増えていくという話ですね。 （技術的な負債もこのパラメータに含まれ
複雑な開発要件を整理する際の考え方〜RDRAを参考に〜 - LayerX エンジニアブログ
はじめまして！LayerXのカレー担当のN_Taisho（西井）です。 私は、もともと霞ヶ関の役人として、６年ほど地方財政支援、大規模災害の被災地の復旧・復興支援、国際協定交渉等に関わってきました。現在はLayerXに所属しながら、三井物産デジタル・アセットマネジメント株式会社（以下、MDM）にてProduct Managerとしてプロダクト開発に主に携わりつつ、会社立ち上げに係る様々な業務に従事させてもらっています。 このMDMは、「眠れる「銭」を、Activateせよ。」をミッションに、「Operation × Techでどうアセマネ業務をリデザインするか」に取り組んでおりますが、その概要については以前、同じくLayerXに所属しながらMDMにコミットしている丸野が執筆した以下の記事が詳しいところなのでそちらをご一読いただければと思います。 tech.layerx.co.jp 今回は、
内製化をすすめる知人へのアドバイス - Kengo's blog
ソフトウェアエンジニアとしての働き方を探求してきた経験と、駐在員として文化の狭間でうろちょろしてきた経験、OSSエンジニアとして多数の多様な人材と交流してきた経験をもとに、果敢にも内製化に挑戦する知人へのアドバイスを気持ちまとめます。 前提 主な利用技術にはJava（Spring Framework）やTypeScriptを想定 FaaSを始めとしたManaged Serviceは（いまのところ）積極採用しない構え Digital Transformationを推し進める一環としての内製化に、エンジニアリングの観点から挑む方を読み手として想定 内製化のターゲットは決まっているか心当たりがある状態 既存の開発チームはほぼ無い想定 1. チームビルディング 1.1. スーツとギークの対立を避ける 我々が若かった頃は"スーツ"と"ギーク"の対立を煽る風潮にありました。Rockstar Engin
開発者体験をさらに向上させる
事業と研究との連携
開発者体験をさらに向上させる 事業と研究との連携 2021/04/10 さくらインターネット株式会社 さくらインターネット研究所 上級研究員 松本亮介 / まつもとりー / @matsumotory
技術的負債とステークホルダと説明責任と / The Debt
Talked at CloudNative Days Spring 2021 Online #CNDO2021. https://event.cloudnativedays.jp/cndo2021/talks/801
TechCrunch
Haun Ventures has made 48 investments, including some of its token positions, across its early-stage $500 million and $1 billion later-stage acceleration funds. At the 2024 IAB NewFronts event on Wednesday, Snapchat announced a series of new augmented reality (AR) and machine learning (ML) tools designed to help brands and advertisers reach users on the socia
レガシーコードからの脱却
2019年10月4日のAWS DevDay / 2019年10月31日のEOF2019 / 2020年2月14日のDevelopers Summitで登壇した際のスライドです。 1. レガシーコードからの脱却 2020/2/14 株式会社アトラクタ 吉羽龍太郎 (@ryuzee) ✤ ✤ ✤ 初版: 2019/10/03 AWS DevDay 改訂: 2019/10/31 EOF2019 改訂: 2020/02/14 Developers Summit 2020 2. 株式会社アトラクタについて ✤ 社名：株式会社アトラクタ 英文表記：Attractor Inc. / https://www.attractor.co.jp ✤ 設立：2016年12月 ✤ 所在：東京都港区 ✤ 開発プロセスに関するコンサルティングやトレーニングを提供 ✤ アジャイル開発 / DevOps / チーム育成 /
新しすぎるものは避けてアーリーマジョリティくらいを目指そう 息の長いサービスを少しずつ改善していく営み
株式会社ラクスが開催するエンジニア向けのイベント「RAKUS Meetup」。今回は「Vue.js、React、TypeScript、E2Eテスト」をテーマに、「楽楽明細」の機能開発を担当する三田英一氏が登壇し、「息の長いサービスのフロントエンドを少しずつ改善していく営み」という内容で話をしました。関連資料はこちら。 フロントエンドとバックエンドのどちらも担当 三田英一氏（以下、三田）：「息の長いサービスのフロントエンドを少しずつ改善していく営み」というテーマで発表したいと思います。よろしくお願いいたします。 まず自己紹介です。三田英一と申します。TwitterとかGitHubはこのアカウントでやっています。ラクスには、中途入社で2014年に入りました。以来、フロントエンドとバックエンドのどちらもやっています。 あと、今日の話とはあんまり関係ないのですが、アジャイル開発も好きなので、認定ス
Windowsで開発
Windowsで開発環境を整えた。 背景 開発環境を改善しようと思い、PCデスクの見直しなどをやっていたら、Windowsでも開発できるようにしようと思い至った。新しい環境を試してみたい気持ちが1割と、新しいゲーミングPCを組みたい気持ちが9割だ。 エディション Windows 10 Homeエディションを利用している。 Windows 10 ProにはHyper-Vという仮想化機能を直接利用できる利点があるが、WSL2で同じようなことをより便利に実現できるようになったおかげで、この点においてPro版の必要性は薄れてきている。今のところ自分のやりたいことはWindows 10 Homeですべて実現できている。 Windows Update WSL2を使うために、Windowsをバージョン2004・ビルド19041に更新した。 日々の自動更新ではバージョン1903で止まっていて、まだ自動では
サルでもわかるNASA式システム開発 第0話 「NASA Systems Engineering Handbook」 - 株式会社レヴィ ブログ
この記事では、「サルでもわかるNASA式システム開発」ガイドブックのポイントを抜粋して紹介しています。全文をお読みになりたいかたはこちらから無料ダウンロードしていただけます。 levii.co.jp 1995年に発行された“NASA Systems Engineering Handbook” という本があります。 このハンドブックは、NASAが宇宙開発のプロジェクトを進める上で、重要だと考えていることが記述された、システムデザインに携わるエンジニアにとってはバイブルのような本です。 最近（2020年1月）2回目の改訂版が発行され、とても閲覧しやすくなりました。 www.nasa.gov 宇宙開発に限らず、システムデザインに役立つノウハウが満載なのですが、日本では、ほとんど読まれていないと思います。 とても勿体無いことなので、それをできる限り簡単にして、誰にとっても読みやすいように１話完結の
専門職と視座
こんにちは。ミクシィでスポーツやライブエンタメ関連の技術部長を担当している石井です。社内向けに書いている記事を少しづつ外部公開していきます。 大規模なサービス開発組織で働いていると、技術職スタッフにおいても、視座の高さを求められることが増えます。「視座の高さ」という単語は、曖昧で、入社していきなり「視座！視座！」と言われても、「えらい人がなんか言うとる」「わいには、まだ早い」くらいで、腹落ちしないと思います。しかし、給与体系にも紐づいていたりするので、給与が上がってくると、「視座をもうちょっとあげてもらわないとね…」と上長から言われれて「えー」となるかもしれません。私の考える「視座の高さ」と、なぜ専門職にも必要になるのかを説明しつつ、サービス開発と組織の関係について考えてもらう機会になればと思います。 私は、エンジニアリングを、単にプログラミングを書いたりすることで技術課題解決するというこ
【翻訳】技術的負債という概念の生みの親 Ward Cunningham 自身による説明 - t-wadaのブログ
システム開発の世界において「技術的負債（Technical Debt）」は繰り返し話題になり、しばしば炎上しています。 技術的負債という概念の生みの親は Ward Cunningham （ウォード・カニンガム）です。彼は 1992 年にオブジェクト指向プログラミングの国際カンファレンス OOPSLA '92 の Experience Report でコードの初回リリースを負債に例えました（"Shipping first time code is like going into debt"）。 Ward Cunningham はソフトウェアの世界に多くの貢献を果たしてきました。Wiki の発明者であり、XP と TDD の父 Kent Beck の師匠のような存在であり、建築の世界の「パタン・ランゲージ」を Kent Beck と共にソフトウェアに輸入した人であり、「アジャイルソフトウェア開
SpaceXのロケットが安い理由は再使用ではない、という話｜ina111 / 稲川貴大
結論：安いロケットエンジンを持っているからである。 SpaceXのFalcon1（退役済み）やFalcon9に使われているMerlinエンジンはRP-1（灯油に似た燃料）と液体酸素（LOX）を推進剤にしたロケットエンジン。A~Dとバージョンがあり、推力は34〜62トン重と2倍近くも差があるエンジンであるが、価格はおよそ1億円だと噂されている。極めて安い。 エンジンだけではなく全体で低コストの方法が取られているが、2002年創業のSpaceXはNASA等の技術をうまく活用している。 この記事ではMerlinに通じるエンジンのうち、日本語での情報が少ないNASAのFastracエンジンの紹介。 SpaceXのMerlinエンジンはSpaceXのCTO of PropulsionでもあったTom Muellerさんが設計していた彼のSpaceXの前職場であるTRW社のTR-106やTR-107が
新規Webサービスを独りで開発・運用する際に立ちはだかった壁とそれを乗り越えた方法まとめ【個人開発】 - Qiita
その1. そもそもアイデアが思い浮かばない 遭遇確率 ：★★★★☆ どんな壁？：いざWebサービスを作ろうとしても何もアイデアが思い浮かばない 解決策：身近な課題をひたすら探す サービスを作る上では何かを解決する系のアイデアであり、かつ自分が当事者であるとモチベーションも続きやすいです。 自分が普段ネットを使っていて不便だと思うこと、今使っているサービスの不満点、などなんでも良いのでとりあえず書き出してみましょう。 大体この中に自分の技術力でも解決できるような課題が存在します。 もし自分の中での課題が見つからないという場合は、日々Twitterのタイムラインで流れてくる身近な人が抱えている課題をピックアップしてアイデア化するのもありです。 回避策：しょぼいアイデアでも日々書き残していく いざサービスを作るというときにアイデアも出ないし身近な課題すら見つからない場合は、普段からアイデアを無理
メルカリ・メルペイCTOとエンジニアが明かす「今だからこそ面白い」課題と挑戦 ＃BoldChallenge | mercan (メルカン)
プロダクトの開発や改善に伴い数値や成果に追われるなか、どうすれば納得感や達成意欲を感じながら働いてもらえるのだろうか。現場のエンパワメントやマネジメント、経営と現場のシームレスなコミュニケーションは、多くの組織にとって課題となり続けてきました。それは紛れもなく、メルカリグループも同様です。 9月24日に開催されたイベント「Mercari Bold Challenge ~CTOとエンジニアが赤裸々に語る 変化と挑戦~」。メルカリ、メルペイそれぞれのCTOや、現場のエンジニアを統括するEM（エンジニアリングマネージャー）が登壇。メルカリグループがエンジニアマネジメントにおいて考えていること、苦労していることや試していることなどを「赤裸々」に話しました。メルカンでは、3時間にも及んだイベントの様子をダイジェストでお届けします。 メルペイは、単なる「サービスの普及」を目指していない 第一部では、メ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
心が折れずにゲーム開発を続ける方法
