2023年度リクルート エンジニアコース新人研修の講義資料です
Qiita Conferenceは、ソフトウェア開発者が集まり、最新の技術や最先端の挑戦・ソフトウェアの未来についての考えや知見を共有し、つながる場を創出する、「Qiita」が開催するオンライン技術カンファレンスです。ここで小城氏が登壇。まずは、小城氏がエンジニア時代に感じていたモヤモヤと、「プロダクトマネージャー」が出てきたがゆえに起きている“良くない分業”について話します。 小城氏の自己紹介小城久美子氏：よろしくお願いします。ミノ駆動さんの発表おもしろかったですね。そのあとはやりづらいなという気持ちもありつつ、がんばっていければと思っています。よろしくお願いします。 私の発表のタイトルは「エンジニアが推進するプロダクトマネジメント」というところで、話をしていければと思っています。どうぞよろしくお願いします。 はじめに簡単に自己紹介をしたいと思います。（スライドを示して）私はいわゆるエン
本稿は Gergely Orosz 氏によって書かれた次の記事の日本語翻訳です。著者に翻訳の許可を得て公開しています。 blog.pragmaticengineer.com また本稿は DeepL Pro を使って下訳したものに手を加えています。日本語翻訳の不具合または誤訳については Gergely Orosz 氏ではなく、本稿のコメント欄にお願いします。 著者も機械翻訳を下地にしたやり方に関心をもたれたようです。 The article translated to Japanese: https://t.co/4uynyyhm4E The author was transparent and noted that the article is a modification of an ML-translated article. This person managed to transl
今回のツイッターの件でいろいろな記事や書き込みやコメントを見てて、未だに世間的にはプログラマーといえばスーパーハッカーな超人くんか、無個性な組立工やコーディング職人の集団、というような2極化した個人のイメージが主流なのかなと感じた。 イーロン・マスクを支持してる陣営は、優秀だが有害な前者に鉄槌を食らわした、あるいは無能な後者を大量に撃滅したみたいな喝采をおくっている。逆の陣営は、スーパープログラマーや属人化した知識を持ったエンジニアが解雇されたことを残念がっている（後者はまた雇えるだろうくらいに思ってそうだけど）。 でも実際のところ、エンジニア個人の去就より、ツイッター内のいろいろな開発チームが壊れてしまったこと。もっというとイーロン・マスクが自らの手で「チームを壊した」としか言いようのない行動を取っていることのほうが今後への影響は大きいんじゃないかと思う。スポーツと同じで、たとえエースが
ここから、DevとOpsが協力すればより効率的になる＝DevOps、という言葉が生まれました。 当時は大企業においてはDevとOpsが分かれていることが当たり前だったのです。そして、大企業における当たり前が、当たり前ではないことに気付き始め、DevOpsを実現するためのツールができ始めたころでもあります。 ではなぜ、大企業ではDevとOpsが分かれているのが当たり前だったのでしょうか？ ハードウェアの時代その昔、産業の主役はハードウェアでした。 そのため、多くの企業はハードウェアを作ることに対して最適化が行われました。 ハードウェアには研究開発、製造、運用サポートといった大きな区分けが存在します。そして、それぞれの仕事において要求する人材レベルは異なります。 加えて、大量生産された製品の運用サポート（設置作業員、サポートセンタ）には、大量の人員が必要になってきます。 したがって、組織を研究
PMBOKとはPMBOKは「Project Management Body of Knowledge」の略語で、日本語に訳すと「プロジェクトマネジメントの知識体系」です。読み方は「ピンボック」です。米国のプロジェクトマネジメント協会（PMI）が1986年にPMBOKのガイドブックの初版を刊行してから、ほぼ4年ごとに改訂され今では「プロジェクトマネジメントの世界標準」とされています。 本来「PMBOK」は体系そのものを指しますが、PMBOKのガイドブック「PMBOK GUIDE」を指す言葉としても用いられています。 【参考】PMI日本支部 2017年に発刊されたPMBOKの第6版はA4判750ページの大冊でしたが、第7版は250ページと1/3のボリュームになりました。目次の構成もガラリと変わっています。この大改訂にショックを受けたのが、プロジェクトマネジメント協会が主催するPMP試験（プロジ
はじめに 以前Scrum@Scaleについて@tyantya41717651さん、@zakky_devさんとディスカッションしましたが、先日お二人と、大規模アジャイルフレームワークであるSpotifyモデルと先日公開された失敗記事(「Spotifyは "Spotifyモデル "を使っていない(Spotify's Failed #SquadGoals)」)についてディスカッションしたのでブログにまとめました。*1 はじめに Spotifyモデルと取り上げた理由 モデルの失敗ではなく、ヒトの失敗 扱える以上の自由や権限を与えた悲劇 1. チームへの過剰な権限付与による、サイロ化の加速 2. 分隊のプロセスの自由さや能力不足による、分隊間協力の困難化 3. 全員での意思決定を追求したことによる、意思決定コストの増大 まとめ Spotifyモデルと取り上げた理由 今回Spotifyモデルの詳しい解
ゲーム開発 プロジェクトマネジメント講座 ２０１１年１０月８日 株式会社スクウェア・エニックス CTO 橋本 善久 1 ©SQUARE-ENIX 2011 SQUARE ENIX OPEN CONFERENCE なぜプロジェクトは 失敗するのか？ 2 ©SQUARE-ENIX 2011 プロジェクトの失敗ポイント • 見込みより売上が少ない • 計画よりもコストがかかっている • 発売時期が遅れた • 発売に間に合わせるため内容が削られた • ユーザーの評判が悪い • 不具合が発生 • スタッフの満足度が低い、故障者が出た、辞め てしまった • など・・・ 3 ©SQUARE-ENIX 2011 プロジェクトの失敗ポイントの分類 • スコープ（コンテンツの範囲）の問題 • 品質の問題 • コストの問題 • 時間の問題 • リソース（人員・環境）の問題 • ビジネスの問題 4 ©SQUARE
先日、現場の人から質問を受けました。 「スクラムで進めているプロダクトに、大きめの問題(バグっぽい挙動)が見つかった。POは最優先で対応したいと思っているが、まず状況把握や原因調査だけでも時間がかかりそうで、ましてや対応までどのくらいかかるかわからず、1スプリントに収まる気がしない。どう対応していくのがいいか」 バグ対応とスプリントについては、いろいろな人が言っています。自分の中ではそういう話と自分の経験がまぜこぜになってしまっていますが、それを思いつくままに書き出して回答を送りました。なんとなく、自分にとっても整理された感があったので、こちらにも置いておきます。 問題を特別扱いしない。問題も、機能追加も、どちらも「理想と現実のギャップ」であり別々に扱う必要はない。どちらも同じように、調査や準備をし、見積もり、プロダクトバックログに入れ、優先順位を検討し、スプリントで開発する。 POが優先
はじめに ： Who I amこんにちは、建設×ITのスタートアップ「シェルフィー株式会社」でプロダクトマネージャーをしているShoko（@shokosuzuki1991）です。本日noteデビューしました！👏 先日参加した『建設職人甲子園』というイベントで、東京タワー建設時のエピソードが紹介されてたのきっかけに、『東京タワーができるまで』を調べれば調べるほど、すごすぎる！ヤバすぎる！となったので、今回はそのあたりをPM的な切り口でまとめてみました。 （※なるべく事実に忠実に書いてますが、一部わかりやすくする表現を優先しているところもあります。予めご容赦ください🙏） 1.構想の大胆さがヤバい 東京タワーが完成したのは1958年です。当時は爆発的なテレビの普及が予想される中で「このまま各局独自の電波塔が増えると、東京中が電波塔だらけになって景観が悪化する」という問題を抱えていました。 そ
“あなた” の開発を支援する AI エージェント Bedrock Engineer / introducing-bedrock-engineer
鳥のさえずり声を聞いて、私は悪態を吐いた。今日の早朝に予定されていたミーティングのことをすっかり忘れていたのだ。 まったく、最悪の朝だ。着替えている間に、電話も鳴った。「高い金を払ってコンサルタントを雇った極めて重要なミーティングだ」と念を押されていたというのに。 それもこれも昨日のバグのせいだ。睡眠時間も、開発スキルも、人員も、私の現場には何もかもが足りていない。 それにも関らず、理解の足りない上司は「テスト工程を削ってでも早く納品しろ」とプレッシャーを与えてくる。 あの馬鹿どもめ。一体何を考えているんだ？ スーツに着替え終わった私は、冷蔵庫の缶コーヒーで空腹を誤魔化すと、バイクに跨った。通勤時間が5分なのが、せめてもの救いだ。 「遅れてすまない」 そう言って会議室に入ると、奇妙なことに気がついた。教室のように整然と並んでいたはずの机が、即席の半円形に並べ替えられていた。 何より、ホワイ
3年前にこんな話を書いたわけですが、皆さんご記憶でしょうか。 この当時は「平均への回帰」という言葉にその不毛さを託したわけですが、前回の記事に着想を得てもう少し今時っぽく論じることが出来るんじゃないかと思ったので、ちょっと書いてみようかと思います。 なお、言うまでもありませんが以下に示す例は完全に単なるシミュレーションであり、特定の事例を意味するものではありません*1。過去にデータ分析業界の内部で見聞された数々の事例の最大公約数的な部分をベンチマークとしてまとめたものとご理解下されば幸いです。またシミュレーション自体も特に数理的な厳密さを期したものではありませんので、そこもご了承あれ*2。 ビジネスの現場でよくある光景 一般に「PDCAサイクルをとにかく速く回す」のがビジネスを成功させる近道だと言われるわけです。そこで、こんなケースを考えてみます。設定としては、何かしらのeCommerce
朝っぱらからこんな動画みてました。 機関車トーマス：じこはおこるさ 【ニコニコ動画】【クラッシュ】きかんしゃトーマス「じこはおこるさ」【連発】 色々とすごいです。この歌。 まずサビで「事故は起こるものさ」と連呼するこのセンス。 しかもバックでは延々と機関車たちの事故映像。結構ホンキで痛々しいですよ。 明るい曲調、深刻な事故。しかも連発。いや、怖いです。 何よりヤバイのはこの歌、このPVが公式のものであること。 何考えてんですかスタッフ。顔のある、喋る機関車たちの番組でこんなもの作って見せるなんて。 こんなもの子供に見せられたら、最悪トラウマですよ。 とか、ひとしきり考えながら(爆笑がほとんどですが)見てると、YouTubeでこんなコメントを見つけました。 戦艦のダメージコントロールとか、OSのセキュリティーパッチな-んかも米英人的な発想ですね。 日本では言霊信仰とというか、ケガ-レの意識と
知らないうちにどんどん人が増えていく会社gumiに入って一ヶ月か二ヶ月が過ぎたころ、チームに所属して様子を見てみると、gumiには一ヶ月の間にかなりの多くの人（5人とか10人とか）が入ってくるのに気がつかされた。 幾つかのチームが組成され、それぞれがゲームを開発、運用しており、解析班などと呼ばれるようなチームもあった。 （そして、それは機能していなかった。売れてないのだから、解析する内容などあるはずもない） そして、入ってきたプログラマは時折適当にプロジェクトにアサインされたりした。 私のチームにも新しいプログラマがやってきたわけだが、そのことを切っ掛けに、うやらプログラムがまともに組めない（仕事を任せられない）人が入ってきていることに気がつかされることになる。 困ったので当時のCTOにどういう基準で人を採っているのか訊いてみた。 特に基準はない、みんな頑張ればできる、とのことだったので、
こんにちは、らくからちゃです。 システム業界に身を置いておりますと、色んなお客様とお仕事をさせて貰う機会があります。システム構築はお客様との二人三脚。お客様の作業効率が弊社の作業効率に直結することも多いものの、横から『こうしたほうがええんとちゃうの？』とも言い出せず、悶々としてしまうときがあります。 そこで直接は言いづらい『ここらへん考えてみてほしいなー』という点について、だらだら適当に書いてみます。ありきたりのことしか書きませんが、どこかのプロジェクトの燃焼速度が多少なりとも遅くなれば幸いです。 例題 例えば、上司からこんな風に指示されたものとします マーケの部長が、修理案内の通知を封筒に詰めて送る作業をやってくれるひと探してるんだけど、お願いしてもいい？ 宛先と対象商品と諸々が書かれたA4用紙が1000人分くらい来るからさ、宛先が東日本なら茶色、西日本なら白色の窓付き封筒に入れて糊付け
6. 6 Business Sales/Marketing Engineering ・Product Backlog ・Sprint & Release planning ・Acceptance Criteria ・Personas ・UX ・User stories ・Customer Success ・Marketing ・Market Research ・Competitive analysis ・Customer relationship ・Pricing ・Vision ・Product Positioning ・Roadmap ・Alliance ・Budget Management Productにおける様々な役割 ・Human Resources ・Recruitment ・Coordinate ・KPI Management 7. 7 Business Sales/Mar
None of the Agile, Lean, or Scrum principles have a formal definition of responsibilities for a Software Architect. Some companies take it to the extreme and not hire a architect at all. Others that do hire one are not clear on architect’s role within the agile context. Do You Need an Architect?Well, at a very fundamental level, whether to have an architect or not depends on: The size and complexi
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
