「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) プロダクトマネジメントでは「アウトプット」と「アウトカム」がよく比較されます。アウトプットは出てきた機能に対して、アウトカムは提供価値であり、プロダクトマネージャーはアウトカ
使われないものを作るな！出口から作るデータ分析基盤 / Data Platform Development Starting from the User Needs
本資料は Tech Play イベント『データ基盤運用の工数削減に効いた俺的ベストプラクティス データマネジメントの勘所』での登壇資料です。 https://techplay.jp/event/940296 データ基盤を構築する際、多くの人が最初にdbt、BigQuery、troccoといったツール名を思い浮かべるかもしれません。しかし、ビジネス価値を生み出すデータ基盤を開発するためには良いツールを選定するだけでなく、「どの技術をいつのタイミングで導入するか」「関係者をどのように巻き込むか」といった観点も重要です。この発表では、製造業のDXを進めるCADDiが直面したデータの課題と、利用状況に合わせて段階的にデータ基盤を拡充していった過程についてご紹介します。
「共通基盤」を超えよ！ 今、Platform Engineeringに取り組むべき理由
OpenShift.Runで登壇した資料です。
(翻訳) GitLab 社で働くのはどのようなものだったか - forest book
本稿は Yorick Peterse 氏によって書かれた次の記事の日本語翻訳です。著者に翻訳の許可を得て公開しています。 yorickpeterse.com また本稿は DeepL Pro を使って下訳したものに手を加えています。日本語翻訳の不具合または誤訳については Yorick Peterse 氏ではなく、本稿のコメント欄にお願いします。 ここから本文です。 GitLab 社で働くのはどのようなものだったか 私は2015年10月に GitLab 社に入社し、6年あまり働いて2021年12月に退社しました。 前に GitLab 社を辞めて Inko に取り組んでいることは書きましたが、2015年から2021年までの間、GitLab 社で働いていたことがどのようなものであったのかについては触れませんでした。理由は2つあります。 燃え尽き症候群に苦しんでいて、(当時は) 自分の人生の最後の6
プリウス開発に見るアジャイル開発要素と今時の進め方：続編 / The Agile Development Elements and Current Approach as Seen in Prius Development: Sequel
弊社の伝説の開発のひとつ、スクラムの源流でもある、初代プリウスについて、当時の開発者たちが語る熱く、時には洩れる本音のトークを紹介します。また日本を代表するアジャイルコーチの皆さんと、温故知新の心構えでこれらを分析しました。開発者たちのトークに、いくつかの共通ワードが存在し、それがスクラムの源流と繋がっている所まで整理できたので解説します。更に、変化の時代、環境変化に対し、ハードウェア開発をどう進めるべきか？ いまどきの取り組みを現場の開発者たちの声と共にお届けいたします。本内容は、スクフェス三河「初代プリウスにみるアジャイル開発の要素と現代の環境での進め方について」の続編という位置付けになります。 / We will introduce passionate and occasionally candid discussions by the developers of our lege
プロダクトオーナーの考えるべきところ - kawaguti’s diary
プロダクトオーナー(PO)の考えるべきところ、もしくは「はまりがちな罠」について、いくつかのトピックを思いつくまま書き出してみました。悩めるPOさんの手助けになれば幸いです。 序盤戦、中盤戦、終盤戦の戦略 一番美味しいアイデアがでる可能性に備えるために 引き継ぎにはコストがかかるので人を追加すると遅くなる システムは利用者の数に従って情報が増えるので、リリース後が最も大変な時期になる システムはハーモニーなので、継ぎ足して別の人を追加すると繋がらない あ、よければアギレルゴの認定スクラムプロダクトオーナー研修もご検討ください。著名な講師が通訳付きで教えてくれます。 1. 序盤戦、中盤戦、終盤戦の戦略 「序盤で基礎を作って、作るスピードが上がってきたら、重要なところを作り、最後はウリになるものを作りこんでリリースする。」一見、良さそうに見える戦略ですが、これは結構危うい計画になりがちです。ユ
チーム開発における技術選定の進め方 - ROUTE06 Tech Blog
プロダクト開発に利用する技術の選択は、不確実性を伴う決断であることが多いです。 私はROUTE06で働く前は個人事業主でした。仕事の多くは、新規プロダクトのプロトタイプや初期バージョンの作成でした。デザインを含めてプロダクト開発をするのは私一人だったので、おおよその要件とスケジュール、予算が合意できたら、作り方は任せてもらっていました。 当時、私が技術を選択する方法は「開発速度や品質に非線形の変化を与える可能性があると感じたらまずは使ってみる」でした。アルファ版*1でもとりあえず使ってみて、上手くいったらそのまま本番稼働させているプロダクトもあります。 足りてない機能や不具合に直面することもありますが、パッチを書いたり開発元にプルリクエストを送りながらプロダクトの開発も進めていました。この進め方は、開発者が一人であれば成果を出せますが、チームで大きな成果を出すのは難しいでしょう。 現在、私
チーム仲は悪くないのに「何となく一体感がない」時に試してもらいたい３つのこと｜こがねん / 組織開発するマン
こんにちは。こがねんです。ファッションテック企業で「組織開発」をしています。 「組織開発」とは何でしょう。これにはいろいろな定義がありますが、僕は「人の集まりが同じ目的に向かって協働するチームになるためのあれやこれやの働きかけ」くらいに考えています。 会社全体・特定部門・特定チーム・特定個人と、人・組織の課題はあらゆるレベルで起こります。その課題発見や解決を自分や自分のチームがリードして行ったり、他の人が行うのをサポートしたりする仕事。それが「組織開発」です。 そんな仕事をしている関係で、現場マネジャーからもよく人・組織に関する相談を受けます。先日も現場のマネジャーからこんな相談を受けました。 「チームの一体感が低下していて困っています。別に仲が悪いわけではないですが、リモートワークになった頃からメンバー同士の関わり合いが減ったこともあり、横のつながりが薄くなってしまったように思います。業
要件定義を専門でやる技術者(Requirement Engineer)に関する雑感 - 勘と経験と読経
タイムラインに流れていた『もう発注側企業に要件定義能力はないので、要件定義を専門でやる技術者(Requirement Engineer)が世界でも日本でも出てきている』という話に関する極めて個人的な雑感。あるいは記憶のダンプ。 b.hatena.ne.jp 要件定義を専門でやる技術者(Requirement Engineer)の話はいつか来た道 要件定義を専門でやる技術者という話は新しい話ではなく、ゼロ年代後半から議論がされていたものである。 ゼロ年代後半というと、SIerを中心にわりと適切なプロジェクトマネジメント方法論が普及しはじめて、「要求された通りのシステムは開発できるようになってきた」という時代だ。 一方で「システムは開発できるが、要件定義がゴミだと、完成するシステムもゴミ」という問題が残っていて、要件定義の高度化や専門家育成の議論があったのだ。 要求開発~価値ある要求を導き出す
コンウェイの法則と、そこで提示された2つの組織課題 - mtx2s’s blog
ソフトウェアエンジニアリング関連の書籍を読んでいると、「コンウェイの法則（Conway's law）」によく出会う。その引用元は、1968年4月に発表されたメルヴィン・コンウェイ（Melvin E. Conway）の論文 "How do committees invent?" で、例の有名な一文は結論（conclusion）に書かれている。 （前略） organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations. （広義での）システムを設計する組織は、自らのコミュニケーション構造を真似た設計を生み出すという制約
スプリントの振り返り大全 〜 チームに最適な手法を見つける15のレトロスペクティブを振り返る - Agile Journey
はじめまして。株式会社イノベーター・ジャパンでフロントエンドエンジニアをしている、うじた（@besburg）です。弊社ではスクラムによる開発を取り入れており、スプリントの最後には毎回スプリントレトロスペクティブという振り返りを行っています。そこで試した振り返りの手法をこの記事ではまとめてみました。 私たちのプロジェクトではタスクの優先度に入れ替わりが多く、今やっていることを可視化するため、2021年8月からスクラムを開始しました。参加メンバーは各プロジェクトのエンジニア全員で、スプリント期間に合わせて1週間ごとに振り返りを行っています。スクラムによる開発が初めてだったこともあり、当初は自分たちに合った手法を見つけることを目標に振り返りを進めました。 週ごとにメンバーが交代でファシリテーターを担当し、試したい振り返り手法を持ち寄ってレトロスペクティブを行いました。そのため基本的には振り返り手
日本のソフトウェア企業でよく見るエンジニア組織の構造と、近年推奨されるエンジニア組織の構造について
はじめに 恥ずかしながらスクラム開発の開発チームへの導入を何度も経験しているのだけれど、どうしてもチームの成熟レベルが高い位置までもっていくことができませんでした なぜうまくいかないのか？ これを深掘りする過程で教科書どおりに実行するには組織の構造がスクラムガイドで書いてある構造と根本的に異なっているのではないか？と考えるようになりました。 よくあるエンジニア組織の構造 大きめのWebソフトウェア企業の内製型エンジニア組織の構造はだいたいどこもこのような感じになっています この組織構造の問題点 スクラムを導入する場合、リーダー自身かあるいはメンバーの一人がスクラムマスターとなります リーダー自身がスクラムマスターになる場合でもアンチパターンと言われる開発者との兼任になります。 スクラムマスターの最も重要な職務である「観察」が行えなくなります。 スクラムマスター自身が観察を行わない場合、各メ
スクラムを1枚で説明する資料7選（2019年版）
みなさんこんにちは。@ryuzeeです。 スクラムの全体像を表す絵は多数出回っています。コーチングやトレーニングを生業にしている人であればだいたい何度も作ったことがあるのではないかと思います。 今日はスクラムの全体像を表す絵のうち、比較的新しいものをいくつか集めてみたので紹介します。 見出しの行か画像をクリックすると、それぞれオリジナルを公開しているページにアクセスできます。 The Scrum Framework Poster | Scrum.org ケン・シュエイバーが設立したScrum.orgのサイトで公開されているもの極めてシンプルなので汎用性は高い一方で、スクラムマスター、プロダクトオーナー、開発チームの記述がでてこないなど、要素がすべて網羅されているわけではないことに注意が必要Visual AGILExicon Essential Scrumの著者Ken Rubin氏作のもの。
ソフトウェア設計についてtwada技術顧問と話してみた 〜 A Philosophy of Software Design をベースに 〜 - NTT Communications Engineers' Blog
はじめに スタンフォード大学の John Ousterhout 教授が執筆された “A Philosophy of Software Design”(以下 APoSD と略す) という書籍をご存じでしょうか？ 書籍のタイトルを直訳すると、「ソフトウェア設計の哲学」となります。書籍の内容はまさに、ソフトウェア設計について扱っています。 本書籍をベースに、「A Philosophy of Software Design を30分でざっと理解する」というお題で社内ランチ勉強会が開催されました。本記事執筆者である岩瀬(@iwashi86)が発表者であり、勉強会資料は以下のとおりです。 スライド P.4 に記載したとおり、本書籍は John Ousterhout 教授の意見が強く反映されており、ソフトウェアエンジニアであれば、議論を呼ぶ箇所があります。実際、勉強会の実況Slackでは、「これはどうな
Agile and Requirement : アジャイルな要件定義について考える
アジャイルマニフェストとユーザーストーリーマッピングのお話です。
スクラムガイドに新たに追加された「プロダクトゴール」とは？ あるいはプロダクトゴールの設定には何が必要か？（前編） Regional Scrum Gathering Tokyo 2022
スクラムガイドに新たに追加された「プロダクトゴール」とは？ あるいはプロダクトゴールの設定には何が必要か？（前編） Regional Scrum Gathering Tokyo 2022 代表的なソフトウェア開発手法として知られる「スクラム」を開発したケン・シュウェイバー氏とジェフ・サザーランド氏によるスクラムの公式ガイド「スクラムガイド」。2020年11月付けの最新版には新たに「プロダクトゴール」と呼ばれる概念が導入されました。 スクラムガイドによると、プロダクトゴールはプロダクトの将来の状態を表しており、スクラムチームの⻑期的な⽬標である、と説明されています。スクラムチームにとって非常に重要なものだと位置付けられているのです。 この重要なプロダクトゴールをどのように考え、どう設定すべきなのでしょうか。 1月5日から7日までの3日間、都内およびオンラインのハイブリッドで開催されたイベント
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
エンジニアリングマネージャーの理想と現実
要件定義に関わる人は３億回くらい読んでほしい−−−−−−−−−−「IPA 独立行政法人 情報処理推進機構 超上流から攻める IT 化の原理原則 17ヶ条」
チームで盛り上げる ファシリテーション
スクラムと見積り
