PdMについて学んだら生まれた“優しい目”と“厳しい目” いちエンジニアがPdMについて調べて感じたこと
日本XPユーザグループ（XPJUG）が主催になり、毎年秋に開催されている「XP祭り」。ここでナビプラス株式会社の水越氏が登壇。まずは水越氏がこれまで関わってきたプロジェクトを振り返りつつ、PdMの役割などについて話します。 水越氏の自己紹介 水越明哉氏：よろしくお願いします。「エンジニアからPdMになって苦労している話」というタイトルです。水越明哉と申します。Twitterアカウントは「@akiyah」です。 では進めていきます。自己紹介です。今、ナビプラス株式会社というところに2年半ぐらいいて、レコメンドサービスという「あなたへのおすすめアイテム」みたいなものを出すサービスをしています。タイトルにあるように、エンジニアをやっていて、2022年3月からPdMをやっています。 あと、アジャイルプロセス協議会という会をやっています。その中にアジャイルマインド勉強会があって、読書会をやっています
だれかの進捗をうまく把握できないときのフレーズ集 - Qiita
ほとんどの人はだれかと恊働しています。マネージャーやリーダーであるなら、この割合はより大きくなります。 筆者は、仕事の重要な要素のひとつを「進捗を出すこと」と定義しています。そして進捗を出すには、進捗をただしく把握することも重要になってきます。 しかし「進捗を把握する」と言っても、想像以上に難しいと感じる場面が多々ありました。たとえば、 進捗はどうですか？ → 進行中です／〜をやっています なにか問題はありますか？ → とくにないです 〜までに終わりそうですか？ → たぶん大丈夫だと思います というようなやりとりは一般的なコミュニケーションだと思いますが、あまり有用な情報は得られていません。 この記事では、自身の経験則をもとに、進捗にまつわる良い情報をゲットするための具体的な質問を考えてみました。 なぜ進捗を把握すべきなのか 話の前に、なぜ進捗を把握すべきなのでしょうか。 それは良い計画づ
プロダクトマネージャーの役割と育成、評価
プロダクトマネージャーの育成や、役割などの悩みに対する取り組み方法を記載しています。 1. Product Managerの役割や立ち位置は？ 2. Product Managerをどう育成している？ 3. Product Managerってどう評価したら良い？
なぜ、ソフトウェアプロジェクトは人数を増やしても上手くいかないのか - Qiita
はじめに ソフトウェアプロジェクトには不思議な性質があります。現状のスケジュールに課題を感じて、短くするために人員を投下しても、なかなか思い通りに短くならない。それどころか悪化してしまうことがあります。場合によってはプロジェクト自体が破綻して失敗してしまうことすらあります。 今回は、このようなソフトウェアプロジェクトに潜む直感に反する性質を数理的なモデルを介して理解していく試みです。ある種の思考実験としてお楽しみください。 宣伝 Qiitaさんとコラボ企画でアドベントカレンダーをつくりました。 DXをめちゃくちゃ改善した話を募集しています。 https://qiita.com/advent-calendar/2021/dx-improvement 10人の妊婦がいても1ヶ月で一人の子供は生まれない これは誰かの技術力やプロジェクトマネジメント力に欠陥があるのではなく、「人月の神話」で有名な
不安とストレスから解放される見積りとスケジュール方法
はじめに 何かはじめてのことをする場合、人はとても「不安」を感じます。人は未来を考えることができる生き物です。その特異な能力ゆえに、未来に起こるかもしれないよくないことを考えると「不安」を感じてしまうのです。 仕事のプロジェクトなどは、「間に合わなかったらどうしよう」とか「この仕事はちゃんと終えられるのだろうか。」など、未来のことを考えてしまうので「不安」に満ちたものになりがちです。 また、不安なものに取り組むというのは大きなエネルギーが必要です。試験勉強をしている時などに、部屋の掃除をしたくなってしまって、気が付いたら時間がなくなっていたという経験を多くの人が体験したことがあるのではないでしょうか。人は、不安なものを直視することを無意識に避けてしまうクセがあるのです。 本稿では、プロジェクトにおける不安とはなんだろうか？を考え、できる限り不安を最小化させるということを主眼に置いたスケジュ
プロジェクトリーダーというお仕事 - Qiita
概要 そろそろ年度末だし、新年度からプロジェクトリーダーとしてやっていく人もいるかと思うので、プロジェクトリーダーはどういうことをしないといけないかと、心得的なものを投稿しようと思います。今業界全体的にリーダー不足になってるんで、プロジェクトリーダーという役割について興味持ってくれる人が増えると嬉しいです。 ※ここでのプロジェクトとはシステム開発等IT関連のプロジェクトを指すものとします。 軽く自己紹介 2013年頃から7年くらいプロジェクトリーダーとして請負業務などの仕事をしてきました。最近はプロジェクトマネージャーも兼ねてやっていたり、うまくいっていないプロジェクトにコンサルとして入って立て直すというようなこともしています。 レジュメ https://www.resume.id/branch まずは結論から プロジェクトリーダーの使命 「担当するプロジェクトを成功へと導く」 「プロジェ
オープンソースガイドライン
オープンソースガイドライン オープンソースソフトウェアはちょうどあなたのような人々によって作られています。プロジェクトを立ち上げて成長させていく方法を学んでいきましょう。
仕事ができたあの人は、とことん腹黒かった。
少し前、こんなツイートを見た。 以前も言いましたが「出過ぎた杭は打たれない」と考えるより 『誰も打ちたがらない杭になる』のが一番良いと思います 例えば会社で利己的な欲求を排除し「会社への貢献」を念頭に行動している人は周りが応援するしその人を打とうとする人のことも制する 目指すなら『誰も打ちたがらない杭』一択です — マルコ👔 (@marco_biz_man) August 17, 2019 「利己的な欲求を排除し、会社への貢献を念頭に行動する」は、経営者や管理職がいかにも好みそうな話だし、なんとなく「いい話」っぽいのだが、実務的には、私は少し異なった考え方を持っている。 ＊ 私が駆け出しのコンサルタントだった頃。 ようやく現場のプロジェクトを仕切らせてもらうほどの経験を積んだときのことだ。 そのプロジェクトは、業務プロセスに関するもので、業務フローの作成が必要だったので、私はクライアント
成長できる機会は無い、技術者はもうプロマネを目指すな
この「極言暴論」の記事はIT業界や技術者の間でちょくちょく物議を醸す。「暴論」とうたっているわけだし、人月商売のIT業界の悪弊やユーザー企業のIT部門の駄目さ加減などを徹底的にこきおろしているから、当たり前といえば当たり前だ。 記事や私に対する大概の批判は感情的なものなので、「おいおい、もっと冷静になって現状をよく見たほうがいいぞ」と思いつつ、スルーすることにしている。ただ、あるテーマに関しては理性的な批判も多く、「この違いは何なのか」とずっと考えていた。 そのテーマとは「プロジェクトマネジャーは誰が担うのか」である。私の答えは随分前から決まっている。「プロマネは技術者の仕事ではない」。そう言い切っていた。技術者が担っても構わないが、SEやプログラマーといった技術者カテゴリーの仕事とは全くの別物なのだ。 だってそうだろう。プロマネはマネジメントが仕事なのだから当たり前である。技術者だけでな
デスマーチが起きる理由 - ３つの指標
デスマーチが起きる理由 - ３つの指標 著者： 青い鴉（ぶるくろ）さん @bluecrow2 これは結城浩さんの運用されていた YukiWiki に当時 Coffee 様 (青い鴉（ぶるくろ）さん）がかかれていた文章です。 ただ 2018 年 3 月 7 日に YukiWiki が運用停止したため消えてしまいました。その記事のバックアップです。 今は 404 ですが、もともとの記事の URL は http://www.hyuki.com/yukiwiki/wiki.cgi?%A5%C7%A5%B9%A5%DE%A1%BC%A5%C1%A4%AC%B5%AF%A4%AD%A4%EB%CD%FD%CD%B3 になります。 昔、自分がとても感銘を受けた文章なので、このまま読めなくなるのはとてももったいないと思い、バックアップとして公開しています。 お願い もしオリジナルの図を保存されていた方いら
プロジェクト管理のエモいはなし - Qiita
前置き 私のキャリアは少し変わっています。 この業界に新卒で入ってから十数年は、大手ゼネコン的SIerにて、ほぼ一貫してプロジェクトマネジメントをやってきました。最終的には100人月程度の案件を回していたので、中堅クラスではあったと思います。それなりに経験も積んだとは思いますが、あれ、そもそも私って人の管理をやるためにIT業界に入ったんだっけ。。というレーゾンテートル的な理由で、プログラマーに転身しました。 そんなわけで、おそらく日本のIT業界におけるプログラマーから管理職に至るという一般的なキャリアパスを逆行している形になります。 そういった事情もあり、プロジェクト管理からは距離を置くようにしていたのですが、最近またプロジェクトマネジメントについて考える機会が多くなったので、この辺で昔話をしてみようと思います。 他山の石としてワカモノの役に立てば。 前提として ガチガチのウォーターフォー
フィボナッチ工数見積は「完成させます！（徹夜で）」という無理ゲーによる弊害を最小化するプロジェクトマネージメント手法 - ベルリンのITスタートアップで働くジャバ・ザ・ハットリの日記
今まで数々のプロジェクトマネージャーとそのプロジェクトマネージメント手法に翻弄されてきたが、現在の勤め先であるベルリンのITスタートアップで取り入れている手法が歴代の中でも一番マシ。まず工数見積がとても洗練されている。エンジニアが無理やりに「今週中に完成させます！」と言わされて、結局はその約束が守りきれずに翻弄される、というような弊害が最小化できているな、という話。 プロジェクトマネージメントチームのメンバー達はその見積方法を「フィボナッチ」と表現している。 だいたい工数見積なんてものが正確にできる人に出会ったことが無い。複雑なITプロジェクトの全体像を把握して「これをうちのチームで完了するためには＊＊日を要する」なんてピタッと当てたためしがない。絶対にズレる。 エンジニアに向かって「お前さー『今週中に完成させます』って言ったよな？誰だっけ、それ言ったの？オレじゃねーよ。お前だよ。おめーの
コードの半減期とテセウスの船 | POSTD
プロジェクトが発展する際は、単純に新しいコードが古いコードの上に追加されているのでしょうか。もしくは、時間をかけて徐々に古いコードが新しいコードに置き換えられているのでしょうか。これを解明するために、手ごわい GitPython プロジェクトの助けを借りて、Gitプロジェクトを分析する 簡単なプログラム を構築してみました。履歴を年ごとに振り返り、 git blame を実行してみようと思ったのです（この処理を多少でも速くすることは簡単ではないと分かりました。しかし、ファイルのキャッシングを便宜的に含ませることや、変更された点を履歴から見つけること、 git diff を使って変更したファイルを無効にすることなどの詳細を、いつかお伝えします）。 頭がさえている時に、 テセウスの船 をダサくもじって、 “テセウスのGit” と名付けました。私は父親になって、ひどいダジャレを作れるようになった
なぜプロジェクトは炎上するのか？炎上しやすい4つの傾向と、炎上を防ぐ3つの対策 - paiza開発日誌
Picture by ITエンジニアを目指す女子高生たちの学園ライフ4コマ漫画『ぱいじょ！』 こんにちは、谷口です。 某Mずほ銀行の案件のニュースが出たとき、弊社でも結構話題になりました。 あんなに巨大なプロジェクトをしずめるのは、もう本当に不可能なんじゃないかと思いますが、どんなに大きな炎上も、恐らくは小さな火種が集まって、やがて大きな炎となってしまった結果だと思いますし、最初の小さな火種の段階からぷちぷち消していけたらこんな結果にはならなかったはず……。 という話をしていたときに、paizaのエンジニアが「かつて炎上しているプロジェクトに自ら突入していくのが趣味だった」などと言い出しました。「そういう性癖なのかな」と思ったんですが、聞いてみると 「炎上しているプロジェクトに行くと『優秀な人たちはどんな振る舞いや働きをして炎上をしずめているのか』『何が原因で炎上したのか、どの時点で何をし
指示が意図した通りにメンバーに伝わったら、むしろ驚け
この連載では、先が見えないプロジェクトを「暗闇プロジェクト」を担当するマネジャーにとって参考になりそうなヒントやノウハウを紹介している。 前回（部下はマネジャーのようには決して考えない、期待しても無意味）から、「暗闇」でのメンバーマネジメントを取り上げている。今回も、二つのセオリーを紹介したい。 セオリー1 時には指示をあいまいにするのも手 マネジャーのD氏はイラついていた。中途で入社したU氏に対してである。 U氏の学歴や職歴は申し分ない。発言や質問の内容から、地頭の良さがうかがえる。問題は、言われた仕事しかしないことだ。 「次の打ち合わせのための資料を作成してくれないか」などと明確に指示を出すと、U氏は確かに言われたことはする。ただ、それだけである。「これはどうなった？」と付随する作業について尋ねると、まず間違いなく「指示になかったので、やっていません」と答える。 「お前はロボットか？」
エンジニアの常識はマネジャーには「非常識」、意識を変えないと地雷踏む
エンジニアの常識はマネジャーには「非常識」、意識を変えないと地雷踏む エンジニア出身マネジャーの注意点（上） ITに関わるプロジェクトは多様化する一方だ。新規事業やサービスの開発、業務改革などと密に絡み、あらかじめゴールを設定できない状況で開始せざるを得ないケースも少なくない。 この連載では、そうした先が見えないプロジェクトを「暗闇プロジェクト」と呼び、この種のプロジェクトを担当するマネジャーにとって参考になりそうなヒントやノウハウを紹介している。 プロジェクトには様々なステークホルダー（利害関係者）が関わる。実は顧客以上に厄介で面倒なのは、社内関係者のコントロールだ。今回からしばらく、暗闇プロジェクトを進める際にマネジャーが知っておくべき社内コントロールの心得を紹介する。 今回と次回は主に、エンジニア出身の新任マネジャーが陥りやすい注意点を中心に見ていく。 セオリー1 マネジャーは自信満
プロジェクトが失敗する10の兆候
今年こそは失敗プロジェクトをなくしたいと思っているみなさんこんにちは。ryuzeeです。 先日海外のサイトを見ていたところ、10 Signs When Projects Are Doomed to Failureという面白い記事を見つけたので、10の兆候それぞれをご紹介しつつ私の私見を述べておきたいと思います。 なお、アジャイルなのかウォーターフォールなのかは関係なくあてはまります。 失敗プロジェクトの兆候(1) プロジェクトメンバーが自分たちのタスクをこなすよりもプロジェクトの悪い状況について話し合いをするのに時間を使っている よくあるパターン。 たとえばなかなか仕様が決まらないので見切りで発射してみたら、途中で色々な仕様変更がおこったり考慮漏れが出てきたりして常に対策会議をしなければいけなくなったり、 品質が悪すぎて品質改善のための会議を頻繁におこなうことになったりといった状況。 タス
Android Best Practices のディレクトリ構成を作れるテンプレート作った - tomoima525's blog
Android Studioでプロジェクトを新規で作る時、テンプレートは何を選択していますか？ テンプレートには自動でNavigation Drawerを生成してくれるものや、最近だと広告をつけてくれるものなど色々ありますが、実際のところ、Add No Activityを選択するか、Blank Activityを選択する人が多いのではないのでしょうか。 テンプレートはプロジェクト作る時に必ず通るのですが、正直あまりイケてると思えないので、今回もうちょっとましなテンプレートを作ってみました。 Android Studioの標準テンプレートの問題点 Android Studioの標準テンプレートの問題点としては、以下があると思います。 余計なリソースファイルやコードが自動で生成されてしまう →例えば、Blank Activityだと、activityごとのmenu(menuリソース + onC
現場ロックインが技術力さげてるのかもしれない - Javaプログラマのはしくれダイアリー
はじめに 技術を学ぶというのはすごい個人差のあることだと思います。 個人特性もあるし、興味の向く対象も違う。 組織にはいろんな人間がいる。 そんな中、いくら「技術力を学ぼう！」と啓蒙しても、 響かないことってありませんか。 最終的には人それぞれの問題にはなってくるのだけれど、 それって、現場ロックインが一因なのではないかなと思う。 現場ロックインの定義 「特定ベンダー（メーカー）の独自技術に大きく依存した製品、サービス、システム等を採用した際に、他ベンダーの提供する同種の製品、サービス、システム等への乗り換えが困難になる現象」をベンダーロックインという。 (Wikipediaより引用) 現場ロックインは僕の思いついた単なる造語で、 「特定のプロジェクトに特化した技術や顧客の事情を重視しており、 その他の現場に移動しても殆ど役に立たないローカルルールに依存している現象」を指す。 会社に対して
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ITプロジェクトのはじめ方 / How to work around software project
