Qiita Conference 2023で登壇の機会をいただきましたので、登壇内容を一部noteにもしておきます。登壇資料は最後に貼ってあります。 前提プロダクトマネジメントはUX、Tech、Businessの交差領域であり、各々の専門性が重なるというのが基本概念のはずです。（左）しかし、プロダクトマネージャーという職種が増えてきた結果、分業したままなんとかプロダクトマネージャーがその糊となって繋げている組織をみることがあります。（右） プロダクトマネージャーではなく、プロダクトマネジメントは各領域の専門家が集まるチームでやっていきましょう。プロダクトマネージャーはその旗を降る人であって一人でプロダクトマネジメントをするわけではありません。 エンジニアがプロダクトづくりを推進するためには、Tech x UXやTech x Businessの領域に積極的に手をだして重なりをつくっていきまし

# ソフトウェアエンジニアリングサバイバルガイド: 廃墟を直す、廃墟を出る、廃墟を壊す、あるいは廃墟に暮らす、廃墟に死す https://www.youtube.com/watch?v=PSCmjrrbNkg # Howだけ考えると複雑さを導入して仕事が増える https://soudai.hatenablog.com/entry/2020/08/14/101657 # 質とスピード（2020春版） / Quality and Speed 2020 Spring Edition https://speakerdeck.com/twada/quality-and-speed-2020-spring-edition # 判断と決断の違いと決断のコツ https://soudai.hatenablog.com/entry/2022/01/04/151923 # Worse Is Better -

みなさんこんにちは。@ryuzeeです。 2023年5月9日に開催されたNTT Com Open TechLunch #7「エンジニアリングマネージャーと目標設定」の登壇資料を公開します。 このイベントはNTTコミュニケーションズの社内ランチ勉強会を一般に公開しているものです。 ぼくは、NTTコミュニケーションズの技術顧問をしており、顧問業の一環として登壇しています。 多くの組織では、この時期に期初の目標設定を行っているのではないかと思いますが、目標設定の意味や位置づけ、それをどのように使うのか、評価や報酬との関係はどうなるのかといったことについて組織のなかで認識が揃っていることはまれです。 こうなると、人事制度のなかで目標設定をすると決められているのでめんどくさいけどやる、という感じになったり、目標設定が終わったら内容を綺麗さっぱり忘れて、期末になって「あー、そういえば……」みたいなこと

ベロシティは、スクラムの要素だったことはありません。 ソフトウェア開発に「ベロシティ」を適用することは、エクストリーム・プログラミング（XP）の先駆者たちによって考案されましたが、今ではそれが良くないアイデアだと考える人たちもいます。 残念ながら、スクラムの世界では、いまだに 「4倍のベロシティ向上 」や 「超生産性」などの言葉を押し付けている人がいます。私はこれを恥ずかしく思っています。これは、私が ケン・シュエイバーから学んだ スクラムではありません。ケン・シュエイバーは代わりに、 厳格な完成の定義 と、守れない約束を避けるということを強調していました。 もし私たちが、 実験から学び、適応する能力 を促進するのであれば、特に私たちの近視眼性（木を見て森を見ない傾向）と短絡的な認知バイアスを考えると、従来の生産性重視の姿勢は（それがどのような理由であれ）有害となりえます。あなたが昔に書い

この記事は、以下サイトの機械翻訳です。 何を作るか（あるいは次に何を作るか）を決めることは、プロダクトマネージャーの仕事の中で最も重要な部分の一つです。インパクトを与えるチャンスは何度もありません。だからこそ、賢く選択して、チャンスを最大限に生かすことが重要なのです。 プロダクトの優先順位を決めるには、さまざまな要素を考慮する必要があります。しかし、何よりもまず、お客様の真の問題を解決することを優先しなければなりません。多くの企業では、このプロダクト開発の基本方針が守られていません。おそらく、価値よりも革新性を優先しているからでしょう。私たちは皆、自分たちが最先端の先駆者であると他人に思われたいと思っていますが、市場が求めているのは必ずしもそうではありません。 市場が求めているのは、すでに機能しているものを適度に改良することだったりします。究極のゲームチェンジャーを追い求めるのではなく、フ

4プロダクトを成功させようと悪戦苦闘しているものの、プロダクトの行く末についてプロダクトオーナーやプロダクトマネージャといった一部の人の意思決定に依存しすぎてしまっていると悩んでいるチームが、彼らと共にプロダクトマネジメントを実行できるようにするセッションです。「プロダクトオーナーがボトルネック」という状況から、おさらばしましょう。 概要 https://confengine.com/conferences/regional-scrum-gathering-tokyo-2023/proposal/17655 発表者 https://twitter.com/_N_A_ https://note.com/mryy

こんにちは。 EC基盤グループ サーチチームの 山村です。 この記事は、 Elastic Stack (Elasticsearch) Advent Calendar 2022 の 23日目です。 2か月ほど前になりますが、2022年10月26日に実施された 第50回 Elasticsearch勉強会 で発表させていただきました。 私が外部での発表するのは、2016年6月のSolr勉強会 以来で、非常に緊張しました。 日々の業務にかまけて、ブログが後回しになっていたことで大変遅くなってしまいましたが、上記の発表で話した内容とスライド資料から、話したかったポイントを抜粋するとともに、勉強会で不足していた部分について補足をします。 当日、発表を終えたところで気が抜けてしまい、Twitter で頂いていた質問に満足に答えられませんでしたので、この場で補足説明を含めて出来るだけ回答したいと思います。

みなさんこんにちは。@ryuzeeです。 2022年12月9日に行われたイベント「Developers CAREER Boost」の登壇資料を公開します。 今回は、「マネージャー」と名のつく職種を分類して、それぞれの職務や定義を確認した上で、有効なマネージャーであるにはどうしたらよいかを整理してみました。 資料を作るにあたって、過去の日記を読み返したり記憶を思い起こしたりして、当時の活動や出来事、悩みを整理してみたのですが、自分はやっぱりマネージャーに向いていないし志向していないことを再確認できました（笑）。 全員がマネージャーにならなければいけないなんてことはなく、自分が日々楽しく過ごせるキャリアを選択すればいいと思いますが、資料が少しでも役に立てばうれしい限りです。 本セッションで紹介した書籍は以下のとおりです。 エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーに

タイムラインに流れていた『もう発注側企業に要件定義能力はないので、要件定義を専門でやる技術者(Requirement Engineer)が世界でも日本でも出てきている』という話に関する極めて個人的な雑感。あるいは記憶のダンプ。 b.hatena.ne.jp 要件定義を専門でやる技術者(Requirement Engineer)の話はいつか来た道 要件定義を専門でやる技術者という話は新しい話ではなく、ゼロ年代後半から議論がされていたものである。 ゼロ年代後半というと、SIerを中心にわりと適切なプロジェクトマネジメント方法論が普及しはじめて、「要求された通りのシステムは開発できるようになってきた」という時代だ。 一方で「システムは開発できるが、要件定義がゴミだと、完成するシステムもゴミ」という問題が残っていて、要件定義の高度化や専門家育成の議論があったのだ。 要求開発~価値ある要求を導き出す

nori @00oichan お気軽にフォローいただけると嬉しいです。 神奈川県在住／運用設計が得意／外資系企業のSaaSエンジニアです。 好き: servicenow,生成AI,UiPath,Power Automate Desktop,PowerBI … Amazon.co.jp アソシエイトを利用中です

この記事はログラスDevチームAdvent Calenderの5日目の記事です。 SaaS開発のスタートアップ組織がスケールするためにこんにちは、株式会社ログラスの松岡(@little_hand_s)です。 ログラスは経営管理のSaaSを開発しているスタートアップ企業で、これまでアジャイル開発の手法としてDDD(ドメイン駆動設計)、スクラム、エクストリームプログラミングなどのプラクティスを適用しながら開発を行ってきました。 しかし、組織の規模が大きくなってきた(社員数が50人を超え、エンジニアチームも1チームから複数に分割されました)ことにより、それまでのスキルだけでは解消できない組織面の課題が生まれてきました。 そこで、今年の春から海外のアジャイルコミュニティで多く取り入れられている「システムコーチング®」という組織向けのコーチング手法を導入し、大きな手応えを感じているので、この記事では

「プロジェクトマネジメントの基本が全部わかる本」を買ったら、注文ミスして2冊頼んでしまったんだけど、結果的にはむしろ2冊買ってよかった、という話を書きます。 「プロジェクトマネジメントの基本が全部わかる本」 （ @paradisemaker 著）が届いたー。 なんか注文ミスって2冊届いたけど、1冊は誰かに読ませるとき用にしようw pic.twitter.com/evnrXtssm8 — フジイユウジ (@fujii_yuji) 2022年11月10日 制作/開発をするメンバーはいるけどプロジェクトマネジメントは得意ではなくて雑になってしまっているという制作/開発会社も多いと思うのですが、僕もそういう会社からどうしたらいいのか相談されたり、PMの育成の話をすることがあります。 (肩書としてPMだったことはないんだけど、僕も20年くらいPdM的な仕事をやってるんで相談されることがそれなりにある

ちょっと昔まではデータ基盤の管理人・アーキテクト, 現在は思いっきりクラウドアーキを扱うコンサルタントになったマンです. 私自身の経験・スキル・このブログに書いているコンテンツの関係で, 「データ基盤って何を使って作ればいいの?」的なHow（もしくはWhere）の相談. 「Googleのビッグクエリーってやつがいいと聞いたけど何ができるの?」的な個別のサービスに対するご相談. 「ぶっちゃけおいくらかかりますか💸」というHow much?な話. 有り難くもこのようなお話をよくお受けしています. が, （仕事以外の営みにおける）個人としては毎度同じ話をするのはまあまあ疲れるので, データ基盤にありがちな「何を使って作ればよいか？」という問いに対する処方箋 というテーマで, クラウド上でデータ基盤を構築する際のサービスの選び方 （データ基盤に限らず）クラウド料金の基本的な考え方 をGoogle

IT業界のプロジェクトを成功に導くためのノウハウを網羅的に解説した書籍『プロジェクトマネジメントの基本が全部わかる本』（翔泳社）。著者でパラダイスウェアの代表取締役である橋本将功さんは、プロジェクトマネージャーが直面する課題として大きく3つ、「現場で使える知識体系がない」「無茶ぶりされる」「スキルの属人化」を挙げています。これらの課題を解決するために何が必要なのでしょうか。本書から、プロジェクトマネージャーが持つべきスキルセットと、プロジェクトの成功と失敗をどう定義すればよいのかを紹介します。 本記事は『プロジェクトマネジメントの基本が全部わかる本 交渉・タスクマネジメント・計画立案から見積り・契約・要件定義・設計・テスト・保守改善まで』の「序章　プロジェクトマネジメントのスキルの全体像」と「第1章　プロジェクトとはなにか─基本的な知識と考え方をおさえよう」から一部を抜粋したものです。掲載

相手に誠実に、わかりやすい文章を書くための心がけをまとめました。 どういう思考プロセスからどんな表現が生まれるのか、参考として実例を紹介しています。実際に読み比べ、SmartHRの従業員として何かを伝えようとするときの、参考にしてください。 伝わる文章のガイドライン何を伝えるかによって、必要な情報の量や説明の粒度は異なります。 情報が不足していたり、逆に情報が多すぎたりすると、読者が意図を読み取れないことがあります。 読み手となる相手の状況（読む場面、事前知識など）を踏まえ、言葉にする内容や表現を厳選することが大切です。 目的に合わせて情報を取捨選択する読者の目線に立ち、コンテンツの目的に合わせて情報を取捨選択しましょう。 実例1：法律や業務に関わる記事目的業務に関係する「厚生年金保険」について正確に知りたいと思っている人に、わかりやすく内容を伝える。 Before日本の年金制度は、全国民

PMカンファレンス2022の登壇資料です。

pmconf2022で発表した内容です

初めに きっかけ 新人研修中にDDDとか、PoEAAとかの話が少しだけ出ました。 ただ、イマイチわからないとの声が多数。 理由 なぜなら予備知識がたくさん必要だからです。(ほんとに多い) これはわからなくて当然。 そこで 独断と偏見で、予備知識となる用語を解説します。 偏見多いので、より正確な情報は、書籍やWebで調べてね。 この辺を説明します UML クラス図/シーケンス図 デザインパータン GoF/PoEAA 階層化アーキテクチャ DDD本のサマリ 知らなきゃいけない知識が多くて面倒だね。 説明しないけど、オブジェクト指向やデータベースとかの知識も必要だよ。 説明前にDDD本のページを見てみよう！！！ DDD本の最初のページ 「エリック・エヴァンスのドメイン駆動設計」より ??? よくわからないね さっきの図って何? 灰色の中心部分はソフトウェア設計のモデリングを表しています。 モデリ

(GPT補完) 下記ドキュメントバージョンに関する注意点です。 バージョン番号のルールを定める：バージョン番号は、どのようにつけるかルールを定め、チーム全員が同じ理解で使用するようにする必要があります。たとえば、変更内容によって数字がどのように増えるか（major, minor, patch）、何桁で表現するかなど、具体的に決めておくことが重要です。 変更履歴を明確にする：どのような変更があったのか、それがどのバージョンで実施されたのかを明確にすることが必要です。これにより、何らかの問題が発生した場合に、どのバージョンから問題があるのか特定することができます。 ドキュメントの保存場所を一元化する：ドキュメントのバージョン管理には、ドキュメントを保存する場所を一元化することが重要です。それにより、異なるバージョンのドキュメントが、複数の場所に分散してしまい、誤ったバージョンが使用されることを

GraphQL実践ノウハウv2 https://speakerdeck.com/sonatard/graphql-knowhow-v2 宣言的UIの状態管理とアーキテクチャSwiftUIとGraphQLによる実践 https://speakerdeck.com/sonatard/swiftui-graphql GraphQLの誤解 https://speakerdeck.com/sonatard/rethinking-graphql