プロダクト開発に必要なもの全部繋げたらCursorが最強のプロダクトマネージャーになった｜田口 信元
Ubie株式会社で病気のQ&Aのプロダクトマネージャー（PdM）を務めている、田口（@guchey）です。 Cursorをプロダクトマネジャーが活用する記事を見て、自分もプロダクトマネジメント業務の中心をCursorにしてみることにしました。 威力すごい。各所にあった知識を集約した結果、自分の認知限界を超える相棒になりました。 現在のスプリント、バックログアイテム、OKR、ユーザーストーリー、主要メトリクスを把握したAIは、プロダクトの現在地から未来の姿まで詳細に把握したAIプロダクトマネージャーだった。 ディレクトリ構成今はこんな構成にしています。 cursor_pdm/ ├── .cursor/ # Cursor AI 用の設定ファイル │ ├── mcp.json # MCP設定ファイル │ └── rules/ # Cursor AIルール │ ├── 000_general.md
完全ペアプロは「やりすぎ」だった。失敗を経て辿り着いた、ペアプロ×開発組織の最適解【Tebiki渋谷】 | レバテックラボ（レバテックLAB）
Tebiki株式会社 取締役CTO 渋谷 和暁 神戸大学法学部卒業後、SIerを経てWebシステムの開発会社に入社。ECなどの受託開発やゲームアプリ開発のリードとして従事した後、コーチ・ユナイテッドに転職。クックパッドによる吸収合併のタイミングでCEO貴山氏とともにTebiki社を起業し、取締役CTOを務める。 GitHub Medium アジャイルなプロダクト開発において、コード品質・学習効率・チームワークの向上に効果があるとされる「ペアプロ」。1人でプログラミングすること（＝ソロプログラミング、以下ソロプロ）が主流の中で、ペアプロをどうやって組織に浸透させるべきか、困っている組織は少なくないのではないでしょうか。 かつてのTebiki社も、同じ悩みを抱えていた組織の一つでした。2018年3月に創業し、小売、製造、サービス、物流などの現場マニュアルのDXを目的としたSaaSを開発する同社
クリティカルチェーン・プロジェクトマネジメント（くりてぃかるちぇーん・ぷろじぇくとまねじめんと）
不確定要素の多いプロジェクト型業務に、TOC（注1）の基本原理を適用したプロジェクト管理手法。クリティカルチェーン（注2）という制約条件の下、プロジェクト各工程の締め切り厳守を積み上げるアプローチではなく、プロジェクト全体の納期を守ること（あるいは短縮すること）を目的に、TOCの提唱者エリヤフ・M・ゴールドラット博士（Dr. Eliyahu M. Goldratt）によって開発されたTOCプロジェクトマネジメント（注3）ともいう。 PERT（注4）に由来する従来のプロジェクトマネジメント手法が大規模プロジェクトにおける複雑なスケジューリング問題の数理的最適化を志向しているのに対して、プロジェクトという不確定度の高い作業を行う場合の人間心理や行動特性、および社会的・組織的問題に配慮して、全体最適なプロジェクト管理（スケジューリング、タスクの実行、進ちょく管理）を行う実践的手法である。 従来の
開発者からのコード改善（リファクタリング）要求を受け入れず、先延ばしにした場合に発生しうるビジネス機会の損失
このブラウザ バージョンのサポートは終了しました。サポートされているブラウザにアップグレードしてください。
JIRA is an antipattern | TechCrunch
Atlassian’s JIRA began life as a bug-tracking tool. Today, though, it has become an agile planning suite, “to plan, track, and release great software.” In many organizations it has become the primary map of software projects, the hub of all development, the infamous “source of truth.” It is a truism that the map is not the territory. Alas, this seems especially true of JIRA. Its genesis as a bug t
テックリードという役割
なぜこの文章を書くか?自身が数ヶ月テックリードの役割で経験した内容を基に、テックリードがどういう役割で、毎日の仕事の中でどのような仕事をするのかについて書いていく。 テックリードはサンフランシスコのWeb系企業では一般的なようだが、日本ではまだそれほど広まっているとはいいづらいと思う。 テックリードに求められるのは一言で言えば”技術でエンジニアチームをリードすること”である。Webエンジニアのキャリアパスでたびたび二元論的に語られる、”技術一本で生きていく”職人的なトラックとも”人やプロジェクトのマネジメントをする”マネジメント系のトラックともニュアンスが異なる。 自身の技術力、そしてリーダーシップをもってエンジニアチームのアウトプットを最大化させていくのがテックリードの役割である。 多くの人にその役割を知ってもらい、エンジニアとしてのキャリア形成の助けになればと思っている。 なお、このポ
技術なきマネジメントの衰退とその対策 - メソッド屋のブログ
今回は、マイクロソフトにいて自分が感じているIT業界の大きなスタイルの変化の兆候とその対策について書いてみた。今回もいつも通り、単に自分の意見をシェアしているだけであって、他の人にどうこうしろと言いたいわけではない。ただ、日本のIT業界が米国に追いつき、追い越すための議論のきっかけになるといいなと思っている。自分も楽しみながらも、もがいていることと、そこで見えた光について書いてみたい。 世界は「技術力」の重視に向かっている 私のキャリアは、某大手SIerを12年勤めた後、ITコンサルティング企業に３年在籍して、主に超上流を実践した。その後独立し、ビジネスモデリングから、アジャイルや、DevOpsの導入支援、マネジメント、開発などを実施していた。 私がマイクロソフトを受けてみようと思ったのは、友人からの推薦の要素が大きかったのだが、その背景では、海外で勤務したいという希望があったのと、「技術
de:codeで澤円さんが伝えたかった「エンジニアに必要なマネジメント」の真意とは？
de:codeで澤円さんが伝えたかった「エンジニアに必要なマネジメント」の真意とは？ 馬場 美由紀（HTML5 Experts.jp編集部） 5月23・24日の二日間に渡って開催された日本マイクロソフトの開発者向けカンファレンス「de:code 2017」。その中でも定員数をはるかにオーバーし、入場規制もかかった澤円さんのセッション「これからのエンジニアに必要な『マネジメント』の考え方」が興味深かったので、レポートしたいと思います。 マネジメントは「管理職」のことだけはない エンジニアの世界では日常茶飯事で交わされている以下のセリフ。皆さんも聞き覚えがありませんか？ 「これさ、なるはやでチャチャっと作ってよ」 「とりあえずいい感じに仕上げといて」 「なんかこれ、あんまり動かないよ」 実はこれ、澤さんいわく「マネジメントが欠けている状態」なのだとか。どんなマネジメントが欠けているのかというと
だんだん開発スピードが遅くなっていくのをどうやってとめたら良かったんだろう？ - Mitsuyuki.Shiiba
先日、モブプロをやってきた。その中で、モブプロとは別で、いくつか感じたことがあって、今日はその中のひとつを思い浮かんだままにメモ。 bufferings.hatenablog.com 要件を満たすプロダクトをより早く出す モブプロでTDDしながら、要件を満たすプロダクトをより早く出すことに集中してみた。例えば、第２ラウンドのお題はTDDBCなどでお馴染みの「自販機」。 「100円を入れてボタンを押すとコーラが1本買えること」 最初に「100円を入れてボタンを押すとコーラが1本買えること」と言われ。 assertThat(get(100), is("コーラ")); みたいなテストを書いて。 String get(int money) { return "コーラ"; } みたいな実装を書いた。爆速！ 「200円を入れてボタンを押すとオレンジジュースが1本買えること」 次に「200円を入れてボタ
SIについて私が思ったこと。そしてSIerにおけるモダン開発について : 小野和俊のブログ
ひとことで言えば、「レビュー文化は良くない」ということになるだろうか。 Slack導入、そして同時期に開始した服装の自由化、バイモーダルという考え方の浸透、AIやブロックチェーンを活用したPOC等の取り組みによって、SIerとしてのセゾン情報システムズは、社内の雰囲気もずいぶんと変わってきた。 しかし、こうした取り組みだけではどうにもならないものも少なからずあった。 そのひとつは、「悪い報告がしづらい」ことだった。 これは他のSIerでも同様のことが多いのではないかと思うが、問題プロジェクトに認定されると、品質管理部のモニタリングが強化されたり、第三者によるプロジェクト監査が始まったり、経営会議での定期的な報告が求められたり、何をやっているのかとレビューでこっぴどく叩かれたり、、、。 そうした責任感から、遅れをキャッチアップできるよう少しでもがんばろう、と励まし合う中で、それなのに四方から
スタートアップに向く人、向かない人（エンジニア編）｜えとみほ
先日、機械学習のエンジニアを募集する広告を出したところ、複数の人から「旦那に頼めばいいじゃん」と言われた（知り合い以外の方のために説明すると、私の夫は工学の博士号を取っているソフトウェアエンジニアである）。 確かにスキルマッチング的にはドンピシャではあるのだけど、夫とは実際に半年ほど働いてみて、すぐに一緒に働くのは無理だと断念した。少なくとも、今のスタートアップのフェーズでは、彼の能力や経験を生かしきれないと思ったからだ。 スタートアップに必要なのは「雑でもいいから速い人」先に少しだけ夫のバックグランドを話すと、彼は20代後半まで大学の研究室で働いており、その後私と出会ったVR系のベンチャー企業に転職し、30代前半でソーシャルゲームの会社に2回目の転職をした。職歴としては、そのソーシャルゲーム会社での経験が最も長いと思う。 ソーシャルゲームの会社では、ゲームの開発ではなく、不正なユーザーを
イケイケなベンチャーの開発チームが、大企業的な開発チームになってしまう5つの兆候 - Qiita
はじめに この記事は CrowdWorks Advent Calendar 2016 18日目の記事です。1 やすにしと申します。世間一般的に言う、ジャーマネ的なことをやらせていただいております。組織というのはナマモノでして、常に変化し、課題の種のようなものを見過ごすと、後々大変なことになることが多くあります。とはいえ、うまくいっても空気のように当たり前となりますし、うまくいかないと批判の的になるというなんとも世知辛い役割ですね。 我々も、5人ほどのエンジニアだった組織が、9ヶ月ほどで30人を超え、大きな変化を迎えました。人数が多くなるということは、課題が変容し複雑になるということ。当然ながらその複雑な課題に対して対処するわけですが、そこで多くの会社は「マネジメント」をしようとします。ただ、そのマネジメントもやり方を間違えると、活力や改善や変革をする芽を奪ってしまい、一気に硬直化し、数人だ
SE（システムエンジニア）とは、どういうお仕事？ - Milkのメモ帳
一般の方々のイメージのSE 現実のSE 設計編 コーディング編 システム試験編 最後に やぁ！こんにちは。Milkだよ。 昨日は、あの後更に会社から電話がかかってきて＋αであれこれと話をしたんだよ☆ www.milkmemo.com 電話中の俺の顔 まぁ、それについては置いておこうね。先ずは病気を治さないとね。 最近質問されたんだけど、SEって結局何やってんだ？って言われたんですよ。 あれ・・・未だにSEって職種は、ちゃんと理解されていない・・・？ まぁ、そうだよね。と言うわけで、SE（システムエンジニア）について軽く説明をしようと思うのです。（あくまで、私の会社の話になるので、色々なパターンは存在します。） 一般の方々のイメージのSE 多分なんだけど、SEは一日中PCと向き合っていると思っている方が多いのではないかな？ そもそも、こんなにオシャンティーな環境ではない！！ おっと。心の叫び
ウォルマートやLINEも採用--注目される“インナーソース開発”の勘所
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます 「企業のソフトウェア開発は“インナーソース”が当たり前になる」――。 そんな興味深い流れがグローバル企業の間で始まっている。インナーソースとはオープンソースソフトウェア（OSS）の開発手法を企業内に取り入れ、柔軟かつスピーディーで質の高いソフトウェアを開発するというもの。 OSS開発手法は大手ITベンダーが戦略として取り入れるほど効果があることが知られてきたが、一般の企業内でも同様の効果が期待できるとここ数年で話題になっている。具体的にどのような企業がどう取り入れ、どう運用しているかという最新事例がGitHub主催の開発者向けイベント「GitHub Universe 2016」で紹介された。 導入にあわせて体制も変化 GitHubは昨年
技術的負債とどうやって戦うか - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? プロジェクトが進行するにつれて増える『負債』 長いプロジェクトに携わっていると、技術的負債をいつ返すのかが課題になってきます。 リファクタリングはいつの時点でやるのか、これは長いプロジェクトを運用していく上で問題になっていきますが、今回は負債の種類を整理し、それぞれどう対応をしていけばよいかを考えていきたいと思います。 私達の開発では常に時間が足りない 最近読んだ、「アジャイルサムライ」という本には下記のようなことが書いてありました。 (開発における)3つの真実 プロジェクト開始時点にすべての要求をあつめることは出来ない 集めたところで
日本人プログラマーについての記事が Hacker News で話題になった
東京住まいの外国人プログラマーが日本人のプログラミング世界について記事を書いて (Jawaad Mahmood 氏のブログ記事)、その記事が Hacker News で取り上げられて、話題になった。 "My hypothesis is that a lot of Japanese companies produce little new because they have people solving solved problems over and over again." 以下、拙訳。(*) がついているところは訳していて意味がくみ取れなかった部分なのでコメント頂ければ幸い。誰か Hacker News へのコメントも要約してくれると助かる。 昨日、コーヒーを飲みながらアール氏とアキバに関する話題やらボードゲームやビジネスについて話していた。まじめな話題としてはプログラミングについて、
ソフトウェアの納期見積もりは、星占いレベルのものであると思う - メソッド屋のブログ
このエントリでは、ソフトウェアの見積もりがどういうものであるかをシェアした上で、今後日本はどのような方向に向かえばよいのでは？という私のアイデアをシェアしたいと思う。 注：このエントリは、某銀行の件とは全く関係ありません。考えるきっかけになっていますが、中の人がどんな状況だったかもわからないのに、勝手なことを想像して、人や企業を叩くのは私の趣味ではないからです。 ソフトウェアの見積もりの正確さ ソフトウェア見積もりのことを知りたければ、下記の本がお勧めだ。 books.rakuten.co.jp この本に「不確実性のコーン」という開発フェーズごとの見積もりの正確性に関する図がある。これを見ると、最初の企画の段階で実施した見積もりは、誤差が何と16倍もあり、概算見積もりのレベルでも4倍の開きがある。画面帳票仕様を「確定」したレベルでやっと1.6倍程度の開きになる。 請負開発を実施するときに、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://jp.techcrunch.com/2016/12/13/20161211death-to-jira/
エンジニアが納期を守れていないとしたら、そこにはいったい何があるのだろう？（あるいはいったい何がないのだろう？）
“エンジニア35才定年説に挑戦する” 開発チームのマネジメント
