ソフトウェアエンジニアにおすすめしたい本を100冊選んでみた | gennei's blog
Adobe Firefly で生成PdMむけの記事でこのような記事がある。 「プロダクトマネージャーこそ、戦略的に読書せよ！」── 最短で成果を出すための読書地図 (1/6)|ProductZine（プロダクトジン） これのエンジニア向けの記事がないかなと思っていたがなさそうだったので作ろうと思った。しかし客観的な視点でこれがおすすめというのは難しいので自分が参考になったと思った本を家の本棚を見ながらまずは100冊リストアップしてみた。 紹介する本は10年読まれていたり、近年発売のものであれば10年後にも読まれているだろうというものを選ぶようにしている。個別のプログラミング言語やフレームワークなどの本はバージョンアップに追随ができないことが多いので選んでいない。 入門本プリンシプル オブ プログラミングリーダブルコード定番中の定番。おそらくこの2冊はあちらこちらで紹介されている。とりあえず
見積・提案書に書いておくと不幸を減らせる前提条件
はじめに ちょっとつぶやいたら思いのほか需要がありそうだったので、簡単にまとめておきます。 おことわり これを書いておけば、すべての不幸を避けられるというものではありません 提出先との関係性次第では、書かないほうがいいこともあるかも 私自身が普段提案している内容が、すべて記載されているわけでもありません（うろ覚えで書いてたり、大人の事情） これを流用しておこったすべての事項について、何らかの責任をとることはできません 本稿では請負による開発を想定しています でも共有することで、この業界の不幸が減ればいいなということでつらつら書いてみます。 他にもあるようなら、Twitterなりコメントなりで提案してもらえると嬉しいです。 前提条件を書く目的 見積・提案書通りに、実施するために必要な条件を明確にする 条件を逸脱したときに、どうなるのかハッキリさせる 上記は概ねつぎのとおり 実現が不可能になる
1on1 事前面談シートの振り返り - ユニファ開発者ブログ
この記事はユニファ開発者ブログ Advent Calendar 2021 の 7 日目の記事となります。 adventar.org こんにちは、プロダクトエンジニアリング部の田中です。 今回は、1on1 で約 2 年半使用している事前面談シートの振り返りをしてみます。 私が所属しているプロダクトエンジニアリング部では定期的に 1on1 が実施されています。 頻度と時間は各々で調整可能で、私は 2 週間に 1 回、30 分の間隔で上司にお願いしています。 元々は 1on1 を受けるにあたり特に用意も何もせず手ぶらで臨んでいたのですが、終了後に時折「あっこれ言い忘れた」ということがあり、良くないなと感じていました。 そんな折、以下のブログ記事を拝見し、それ以来こちらの事前面談シートを使わせていただきまして（ありがとうございます）、シートに記載し、上司に共有した上で 1on1 の時間を迎えるよう
プロダクトマネジメント入門: 失敗しないプロダクトの作り方を学ぼう
Founder Customer Fitこのセクションについて解決したい課題を見つけよう顧客を決めようリーンキャンバスを書こうミッションを決めようCustomer Problem Fitこのセクションについてペルソナを立てよう共感マップをつくろうカスタマージャーニーマップをつくろう課題仮説を整理しようプロブレムインタビューをしようProblem Solution FitこのセクションについてPEST分析をしようフックモデルを定義しようプロトタイプをつくろう解決策仮説を整理しようソリューションインタビューをしようSolution Product Fitこのセクションについて名前をつけようユーザーストーリーマップをつくろうMVPを構築しようMVP仮説を整理しようMVPインタビューをしようProduct Market Fitこのセクションについてグロースサイクルを定義しよう利用規約をつくろうプロ
プロダクトマネージャーのスキルは「W型」で磨いていく――連載「PMの基本」執筆陣と学ぶPMのキャリア
昨今日本での認知が高まっている職種「プロダクトマネージャー」。その背景にあるのが、市場やテクノロジーの変化の速さだ。プロダクトやサービス開発において、市場や顧客の状況を見極めながらスピーディーに「何をどのように作るのか」を、責任を持って進めて行くには、「プロダクトマネジメント」という専門の知見やスキルが不可欠とも言える。プロダクトマネージャーにはどんな知識が必要で、どこまでそれらの知識を深く知る必要があるのか。連載「プロダクトマネジメントの基本を学ぼう」の執筆陣、及川卓也氏、曽根原春樹氏、小城久美子氏がオンラインイベントに登壇し解説した。「調整役にならないためには？」「PM/POの違いは？」など現場のリアルな課題が寄せられたQ&Aコーナーの模様も併せて、当日の模様をお届けする。 当日のスライド：プロダクトマネジメントを学ぶ夏 @翔泳社Product Zine夏のイベント 「プロダクトマネー
【資料公開】アジャイル開発プロジェクトの始め方
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 これからアジャイル開発を始めるときには、気をつけておいた方がよいことや、実際にスクラムでスプリントを回す前にやっておいた方がよいことが色々あります。 それについて使っている資料がありますので参考までに公開しておきます。 これもやった方がいい、こういう時にはどうするの？などありましたら是非[Twitter](https://twitter.com/ryuzee)などでお知らせいただければと思います。それでは。 SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発著者／訳者：西村 直人、 永瀬 美穂、 吉羽 龍太郎出版社：翔泳社発売日：2
「技術的負債だらけのチームで技術マネージメントしてみた」資料が素晴らしい - プログラマの思索
「技術的負債だらけのチームで技術マネージメントしてみた」の公開資料が素晴らしいのでリンクしておく。 【参考】 akipiiさんのツイート: "すごく良い資料。RT @yassan168: #kichijojipm 発表資料upしました。誰かの役にたてば良いのだけど。connpassにもUPしています。＞技術的負債だらけのチームで技術マネージメントしてみた https://t.co/3R25aUnI4S" 前任の仕事を引き継ぎしたら、下記の問題があったらしい。 技術的負債込みで引き継いでしまった、という例は、本当によくある。 (引用開始) １年前の状態 ・すべてがメールベース ・ドキュメントはほぼ無い ・最強の属人化。個人のパワーで乗り切る ・技術に関心が無く誰も行動しない ・暫定スクリプトが今も元気に本番稼働中 ・ソースには、ほぼコメント無し ・hoge.pl.(日付) 形式のソース管理
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
エンジニアが納期を守れていないとしたら、そこにはいったい何があるのだろう？（あるいはいったい何がないのだろう？）