2024/06/12 16:16 結論を追記 2024/06/12 20:29 より記事の内容を分かりやすく理解頂くため、タイトルを「PRDやDesign Docを書かなくなった」から変更 2024/06/13 20:39 結論にフロー情報・ストック情報に関する意見を追記 結論 この記事では、「様々な観点を考慮して網羅的にドキュメントを書いて、それを関係者にレビューしてもらう」のではなく、関係者と同期的に対話しながら、観点や選択肢やそのトレードオフを洗い出すことで、少ない手数でより良い答えが見つけられると主張する。 ただし、対話のために必要なドキュメントは事前に書いておくべきだし、対話した結果はドキュメントに残すことが望ましい。そして、そのドキュメントのフォーマットはPRDやDesign Doc以外でも良い。例えば、ADRはアーキテクチャに関する議論の過程と結果を述べる上で必要十分なフォー
Application Load Balancer (ALB) への謎の大量アクセス攻撃 - Techouse Developers Blog
はじめに こんにちは、Techouse の人材プラットフォーム事業部でサーバーサイドエンジニアを担当している imayayoh と申します。 Techouse では各事業部でエンジニアがインフラの監視として、AWS・外部サービス等のグラフモニタリングを実施しています。モニタリングでは下記に重点を置いており、インフラ構成の見直しや障害対応の場として活用しています。 サービス運用に十分なスペックでインフラが構成されているか 最適なコストでサービスが運用されているか インフラ・外部サービスで重大な問題が発生していないか 本日はモニタリングの実施で即時対応できたトラブルの一例として、Application Load Balancer (ALB) への謎の大量アクセス攻撃を紹介します。 コストモニタリング 弊社のサービスではインフラに AWS を使用しており、モニタリングでは AWS Billing
小城久美子が勧める、事業サイドからプロダクトマネージャーになる人向けのPM本5選 2024年6月12日 プロダクトマネージャー 小城 久美子 プロダクトづくりの知見の体系化を試みるプロダクトマネージャー。書籍『プロダクトマネジメントのすべて』共著者であり、日本最大級のプロダクトづくりコミュニティ「プロダクト筋トレ」の主催者。 経歴は、ソフトウェアエンジニア、スクラムマスターなどの開発職を経験後、プロダクトマネージャーに転身し、現在は現場でのプロダクトマネジメントの傍ら、プロダクト戦略の構築や仮説検証の伴走を実施している。 1. 『アジャイルなチームをつくる ふりかえりガイドブック 始め方・ふりかえりの型・手法・マインドセット』森一樹 著 2. 『アジャイルサムライ ー達人開発者への道』Jonathan Rasmusson 著、近藤修平・角掛拓未 訳、西村直人・角谷信太郎 監訳 3. 『プロ
銀の弾丸はない - 偶有的複雑性と向き合うためのログラスのEnabling & Platform戦略 - loglass_product_teamのブログ
こんにちは。ログラスでVP of Engineeringとしてエンジニアリング組織全体のマネジメントをしております、いとひろ@itohiro73と申します。 前回、「銀の弾丸はない - 経営の本質的課題に向き合い続けるログラスのプロダクト開発」と題して、ログラスのプロダクト開発がいかに本質的課題と向き合ってきたか、そしてこれからどのようなチャレンジが待ち受けているのかを書きました。 今回は、「本質的な課題」を解くために本質的な複雑性に付随して存在する、「偶有的複雑性」について、開発組織としてどのように向かっていこうと考えているのかを記します。 前回の記事で引用した、『人月の神話』（Frederick P. Brooks,Jr. ,丸善出版,2014）という書籍にも収録されている論文（Brooks, Fred P. , "No Silver Bullet -Essence and Accid
Github Actionsによる継続的デリバリーの構築 - SO Technologies 開発者ブログ
CTO室所属の高橋と申します。皆からはニャンさんと呼ばれております。そして私は特に無茶振りはされていません。 さて、developブランチに変更が入ったらdev環境にリリース、mainブランチに変更が入ったら本番環境にリリースを行う仕組み、いわゆる継続的デリバリーを構築しているプロジェクトは多いことと思う。我々のチームではCircle CIで行なっていたが事情があってGithub Actionsに移行することになった。ところがGithub Actionsではdevリリースと本番リリースの手順をどう共通化すればいいのか分からず迷ってしまった。 近年のソフトウェア開発の現場ではCI/CDは当たり前になっているが、もはや当たり前すぎて逆にまとまった情報がネット上にないのかもしれない。であれば得られた知見は共有しておくべきだろう。 結論から言うとジョブの共通化には再利用可能なワークフロー用いるのが
はてなブログ独自の集計による人気記事のランキング。6月9日（日）から6月15日（土）〔2024年6月第3週〕のトップ30です*1。 # タイトル／著者とブックマーク 1 【ChatGPT】英語学習用に素敵な先生を錬成したよ！ - はげあたま.org by id:hageatama- 2 ご奉仕チキンレースで均衡する出世水準 - やしお by id:Yashio 3 エスカレーターの右側に乗ったらおっさんに背中押された - にげにげ日記 by id:nigenige110 4 大公開！バッチアプリケーションの品質を高めるZOZOの『バッチ開発ガイドライン』 - ZOZO TECH BLOG by id:vasilyjp 5 C言語をマスターしたい人はGCCのバージョン14を使いましょう - pyopyopyo - Linuxとかプログラミングの覚え書き - by id:pyopyopyo 6
本連載では、AIを活用した音声解析サービスを提供しているRevComm（レブコム）が、プロダクトマネジメントにおいてNotionを活用することで、成果を上げたポイントを具体的に解説していきます。第3回はPRD（プロダクト要求仕様書）の作成・運用・管理についてです。（編集部） はじめに 株式会社RevComm（レブコム）のプロダクトマネージャーの吉井です。RevCommは音声解析AI電話「MiiTel（ミーテル）」、AI搭載オンライン会議解析ツール「MiiTel Meetings」、オフライン（対面）の商談を可視化する「MiiTel RecPod」を開発・提供しています。 RevCommでは、2023年5月からドキュメント管理ツールとして「Notion」を全社に導入し、プロダクトマネジメントにも活用しています。今回は、全社員がフルリモートで業務を行っているRevCommにおけるPRD（プロダ
銀の弾丸はない - 経営の本質的課題に向き合い続けるログラスのプロダクト開発 - loglass_product_teamのブログ
こんにちは。ログラスでVP of Engineeringとしてエンジニアリング組織全体のマネジメントをしております、いとひろ@itohiro73と申します。 ログラスの開発組織は比較的発信が活発なこともあり、採用で出会うエンジニア候補者の方々には「ログラスの開発組織はすでに色々整っているように感じます。自分が取り組むチャレンジはあるのでしょうか？」と聞かれることが多々あります。 ログラスでは、解決すべき課題や取り組むべきチャレンジは「山ほどあります」。むしろここから先のチャレンジの方が大きいです。この点をうまく伝えきれていないのは問題だと思い、ログラスでの挑戦の魅力を皆さんにお伝えするために、この記事を書くことにしました。 ログラスが取り組む大きな課題領域に対し、「銀の弾丸はない」シリーズとして、複数の記事に渡ってログラスのプロダクト開発の面白さと、多岐にわたるプロダクト開発・エンジニアリ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
網羅的なPRDやDesign Docを書かなくなった - kosui
小城久美子が勧める、事業サイドからプロダクトマネージャーになる人向けのPM本5選
今週のはてなブログランキング〔2024年6月第3週〕 - 週刊はてなブログ
リモート環境における情報共有をスムーズに──Notionを活用したPRD管理