XP祭り2024の登壇資料です
個人事業主型開発からの脱却
XP祭り2024の登壇資料です
不確実さが増す世界のプロジェクトマネジメントとはとういうものか 倉貫義人氏：そんな不確実さが増す世界のプロジェクトマネジメントはどういうものなのか。（スライドを示して）プロジェクトがうまくいかない（理由）というのは、このあたりを見てもらうと胃が痛くなりそうな言葉がいっぱい書いてあると思います。想定よりコストがかかるとか、作ったものを直せないとか。 （スライドを示して）これに対してどうすればいいかというと、「こうすればうまくいくのかな？」と考えがちですよね。「遅いからプレッシャーをかけようか」とか「少し遅れているので人を増やそうかな」とか「一気に作ったほうがいいんじゃないの？」とか「属人性を排除しましょう」とかと言いがちですよね。 これらはけっこう言いがちですが、全部失敗するやつです。これを全部やってみたら困ったことにプロジェクトが大変なことになるので、ぜひやってみたらいいと思います。 （会
最近、Qiitaで話題になってそこそこバズった（？）記事に、 qiita.com がありました。これ、最初は一読して凄いまともなことばかり書いているように見えましたが、一方で何か妙な違和感がありました。それは、私がいくつかの振る舞いについて思い当たりがあるせいではないか？と考えてみましたが、反省するところがあるなと思いつつも、何かが変だと感じていました。今朝、違和感の理由がわかった気がするので、書いておきたいと思います。 一番大きな問題は、「有害な振る舞い」といいながら、客観的に観察できる行為ではなく、主観的に行為の意図を勘繰っていることです。 そもそも、著者様は 私個人の経験に基づくため定性的かつ主観的な意見にはなりますが、メガベンチャーにて8年間様々なチームメンバと開発業務に携わりながらスクラム開発の各役割を1年ずつ、それからミドルマネージャーを2年経験し、さ> らに周辺チームや他部署
自分でやるべき（ように思える）ことを得意な誰かに任せるという考え方 - knqyf263's blog
完全なるポエムです。自分にとって斬新な考え方だったので思わず勢いで書いていますが、知っている人からすると当たり前ですし、冷静に読み返すとだから何だよという内容に仕上がっています。読んだあとにだから何だよと言われても責任は取れません。 はじめに とある方の話 他人に任せる 記事執筆 社外発表 社内発表 マネージメント まとめ はじめに 以前、苦手分野を思い切って捨てて得意分野に集中してみるという話を書かせていただきました。 engineer-lab.findy-code.io 今回も通ずるところはあるのですが、一歩踏み込んで自分の気の進まないことはいっそ得意な誰かに任せようという話です。一歩引いた視点で見れば上のブログの話も結局誰かが自分の穴を埋めてくれているので同じに見えると思うのですが、自分の気の持ちようとしては大きく異なるので書いています。つまり、これ苦手だけど一生懸命やってるので許し
中島氏、イヌ氏の自己紹介 椿原ばっきー氏（以下、椿原）：まず1人ずつ紹介します。まず中島さんです。よろしくお願いします。中島さん、自己紹介をお願いしてもよろしいでしょうか？ 中島悠輔氏（以下、中島）：はい。はじめまして。中島悠輔と申します。株式会社SEVENRICH Accountingというところで、今はクリニック向けのシステムのプロダクトマネージャーを本業（として）やっています。ご縁があってLboseさんの副業PMの求人を拝見した時に「ぜひお話をうかがってみたいです」というところから、このようにしてお仕事を頂戴するところに今はなっています。 椿原：ありがとうございます。具体的な案件の話はあとであらためてちょっとしようかなと思うので。 中島：よろしくお願いします。 椿原：続きまして、（お名前が）斬新ですね（笑）。イヌさん。 イヌ氏（以下、イヌ）：はじめまして。イヌと申します。すみません、
こんにちは！estieでビジネス部門の責任者をしている束原です。 2024年になりましたね。estieは決算月が12月なのですが、毎年期初に「今年こそが勝負の年だ」と言っている気がしており、それに対して「ガハハ」と笑い合えるメンバーで仕事ができているのが最高に楽しいなと日々痛感しております。 さて、こちらは事業の立ち上げ（事業開発）に関する記事です。 この記事に書いてあること estieでは「仮説検証」をやめようと思っている話 事業開発の成分の8割は営業だという話 かなり極論が並んでいますが(笑)、事業開発を進める上でとても重要だと考えているので、ご興味のある方は少しお付き合いください。 to Bスタートアップは仮説検証をやめようという話 「仮説検証って言葉が嫌いなんすよねー」と、確か弊社の事業責任者の齋藤だったか代表の平井だったかが以前社内で言ってました。 1年前くらいまで私は、その発言
SI案件でアジャイル開発を進めるときの勘所
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 10月に発売となった『プロダクトマネジメント - ビルドトラップを避け顧客に価値を届ける』ですが、まだお読みになっていない方是非よろしくお願いします。 また、ここ数か月新しい書籍の翻訳に取り組んでいて、来年の春くらいには発売になるかと思います。この本も楽しい本だと思うので是非楽しみにお待ち下さい。 さて、先日、プライベート講演で、SIのコンテキストでアジャイル開発を進める場合に、どのような点に気をつけておくとよいかを話して来ました。 汎用的な内容で読者の方の参考になるかと思いますので、資料を公開しておきます。 以下、資料だけ見てもわからない方向けの解説です。 TL;DR（結論）SI案
チームで受講することで、クイックにスタートできる研修メニューをご用意しています。チームの立ち上げ時期や、学び直し、認識合わせとしてご活用ください。
新規事業とアジャイル
みなさんこんにちは。@ryuzeeです。 新刊『プロダクトマネジメント - ビルドトラップを避け顧客に価値を届ける』が10月26日に発売になりますので、よろしくお願いします。 先日、プライベートで新規事業とアジャイルに関する短いセッションをしましたので、そのときの資料を共有します （本当は1時間かかるものをかなり縮めたダイジェスト版です）。 以下、資料だけ見てもわからない方向けの解説です。 TL;DR（結論）何が分からないのかすら分からないこともある。過度に詳細な計画にしない適切な問題を扱っているか、顧客はいるかが重要顧客が関心を持つのは、自分の課題の解決であり、ソリューションそのものではない仮説と検証の繰り返し急いでたくさん作らない。機能の多さは成功につながらない投資モデルを変える(100打数10安打1ホームランなら上等)アジャイルとはフィードバックサイクルの集合体最初から人が多すぎると
スクラムの原則を、いかにして実践するか - 現場にありがちな悩みを吉羽龍太郎に相談してみた - エンジニアHub｜Webエンジニアのキャリアを考える！
スクラムの原則を、いかにして実践するか - 現場にありがちな悩みを吉羽龍太郎に相談してみた スクラムは多くの開発現場で取り入れられており、その原則を学ぶのは簡単です。しかし原則を現実に実行しようとすると、さまざまな課題が……。アジャイルコーチの吉羽龍太郎さんにスクラムの基礎から、ありがちな課題への対処法をたっぷり聞きました。 スクラムは軽量で理解が容易、だけど実際にやるのが難しい 【スクラムの基礎知識】3つの役割を理解する 【スクラムの基礎知識】5つのイベントを理解する 【スクラムの基礎知識】3つの作成物を理解する スクラムを“現実的に”実践する手法 見積もりは誰のもので、誰が作るのか フィボナッチ数列よりも「Tシャツ見積もり」。素早く見積もりを作る手法 スプリントの期間は1週間が計画しやすくておすすめ スプリントプランニングの極意。タスクの粒度は小さければ小さいほど扱いやすい タスク管理
権限委譲でよくある失敗として、「権限委譲しきれていない」というのがある。気になってちょいちょい細かく口を出してしまうのだ。自分の経験だと、もともと優秀なプレイヤーだった人に多い気がする。 権限委譲する側でもされる側でも改善はできるが、どちらかといえば権限委譲する側の方がコントロールしやすいので意識するべきことを雑にまとめておきたい。 自分の集中するべきことを明確にする 口を出してしまうのは、口を出す余裕があるから 委譲した分何か別の集中するべきことがあるはずだが、それが明確じゃないか忘れてしまっている 自分が為すべきことを明確にして、優先順位を考えるべき 期待の認識を合わせる 口を出してしまうのは、期待を下回っているように感じてしまうから そもそもどこまでを期待していて何を任せているのか認識を合わせた方がいい デリゲーションポーカーなどで委譲の分野やレベルなどを確認するべき 情報が渡ってい
実は相性が悪い「開発生産性」と「アジャイル」。うまくいかない開発を好転させるためにPMがやるべきこととは【ryuzee|吉羽龍太郎】
TOPインタビュー実は相性が悪い「開発生産性」と「アジャイル」。うまくいかない開発を好転させるためにPMがやるべきこととは【ryuzee|吉羽龍太郎】 実は相性が悪い「開発生産性」と「アジャイル」。うまくいかない開発を好転させるためにPMがやるべきこととは【ryuzee|吉羽龍太郎】 2024年3月26日 株式会社アトラクタ Founder兼CTO／アジャイルコーチ 吉羽 龍太郎 1973年生まれ。野村総合研究所、Amazon Web Servicesなどを経て、2016年1月から現職。アジャイル開発、DevOps、クラウドコンピューティング、組織開発を中心としたコンサルティングやトレーニングを専門とする。著書に『SCRUM BOOT CAMP THE BOOK』（翔泳社）、訳書に『チームトポロジー』（日本能率協会マネジメントセンター）、『プロダクトマネージャーのしごと』『エンジニアリング
いま読んでる本、「プロジェクトが炎上したら最初にやることはな〜んだ？」という問題の答えがコレなので、完全に信頼できる→「プロマネの極意」
樋口恭介 | Kyosuke Higuchi🇺🇦🇵🇸 @rrr_kgknk いま読んでる本、「プロジェクトが炎上したら最初にやることはな〜んだ？」という問題の答えが「腹をくくる」なので、完全に信頼できる pic.twitter.com/gFPP9bGUgt 2023-12-30 16:59:40
HPEO🌐IT×資格 @hpeo_jp ジョークと見せかけて 営業部門・開発部門・顧客の パワーバランスによっては マジでちょくちょく発生する状況 ってのがIT業界の微笑ましい一面🤮 2022-03-27 18:50:00
スクラムガイドに新たに追加された「プロダクトゴール」とは？ あるいはプロダクトゴールの設定には何が必要か？（前編） Regional Scrum Gathering Tokyo 2022
スクラムガイドに新たに追加された「プロダクトゴール」とは？ あるいはプロダクトゴールの設定には何が必要か？（前編） Regional Scrum Gathering Tokyo 2022 代表的なソフトウェア開発手法として知られる「スクラム」を開発したケン・シュウェイバー氏とジェフ・サザーランド氏によるスクラムの公式ガイド「スクラムガイド」。2020年11月付けの最新版には新たに「プロダクトゴール」と呼ばれる概念が導入されました。 スクラムガイドによると、プロダクトゴールはプロダクトの将来の状態を表しており、スクラムチームの⻑期的な⽬標である、と説明されています。スクラムチームにとって非常に重要なものだと位置付けられているのです。 この重要なプロダクトゴールをどのように考え、どう設定すべきなのでしょうか。 1月5日から7日までの3日間、都内およびオンラインのハイブリッドで開催されたイベント
エンジニアが開発しやすい環境作りをする
はじめに 自分は渋谷のWeb系開発会社にて執行役員兼エンジニアをやっています。(新卒入社3年目) 直近では6~8名程のエンジニアがいるプロジェクトで、ディレクトリ設計やissue作成、コードレビュー、スケジュール管理、PMへのUI/UX及び機能提案などを行なっています。 その中で自分が「エンジニアチームにとって開発しやすい環境整備」を色々試し、実践してきたので整理していきます。 この記事の主な対象者 エンジニアチームの開発モチベーションを上げたい人 エンジニアにとって開発しやすい環境の作り方 おことわり 今回紹介するのは自分が実践してきた一例であり、必ずしも正解というわけではありません 「こうしなさい」ではなく「こうするとより良くなるかも」といったモチベで書いています 具体的な開発の設計を紹介するものではありません エンジニアが開発しやすい環境作り 5つのセクションに分けて紹介していきます
「プロジェクトマネジャーの教科書」とも呼ばれる「PMBOKガイド」第7版の日本語版書籍が2021年11月1日に発売される。第6版は重量が2kgあったが、新版は800gと一気に軽くなった。プロジェクトの流れをまとめたプロセスの記載が姿を消し、プロジェクト運営を成功させる「原理・原則」が前面に出るなど構成が大きく変わったことが影響した。変化が激しい時代に対応するため、開発プロセスにかかわらず活用できるように転換した。 米PMI（Project Management Institute）が発行したPMBOKガイド第7版は、従来版とは全く異なる構成になった。翻訳作業に中心的に携わったPMI日本支部の庄司敏浩標準推進委員会委員は「プロセス中心の構成をやめた」と説明する。 第6版までのPMBOKガイドは、QCD（品質・コスト・納期）をはじめとする要求事項を満たして円滑に成果物を作り上げることを重視して
はじめに こんにちは、CARTA HOLDINGSでエンジニアをしているこんちゃん(@konchanSS)です。 この記事は筆者が新しく発足したプロジェクトのシステムを外部委託で作った経験をチームで振り返った際に得た学びを『システムを作らせる技術』によって補強したものです。 この記事を読んでくれた方は是非『システムを作らせる技術』を一読して欲しいです。 システムを知らないあなたにこそ読んでほしい この記事はビジネスサイドや、PdMだったりマネージャーといったいわゆるシステムの開発を依頼する側の人たちに向けて書いています。 意図した通りのシステムを作ってもらうための術を知ることはあなたにとって以下のメリットがあります。 意図した通りにシステムが動くことで業務の効率的になる 貴方がやろうとしているビジネスを促進させる システムを作ってもらうための術を知ることがなぜそのようなメリットを享受できる
近年のソフトウェアプロダクト開発組織の活動単位としてよく言われるのは、「少人数で安定したチーム」であろう。表現は違えど、どの文献でもそのように述べられる。 それでは、「少人数」と「安定」の2つの要件を満たせば高パフォーマンスなチームが設計できるかと言えば、そんなはずもない。他にも要件があるはずだ。 そこで、チームに共通して必要だと考える要件を、設計に関わったこれまでの組織から抽出して言語化し、原則としてまとめてみた。それが、「安定」「アトミック」「非兼務」「少人数」「流動性」「イテレーティブ」の6つだ。 初期に携わった組織には欠けていた要素もあるが、何度も失敗を重ねるうちに見いだしたものだ。組織設計のプラクティスとしてよく聞くものもあるが、いずれも実体験を経て必要だと感じたものばかりである。 なお、本記事で取り上げる6つのチーム設計原則だけでは、組織設計として不十分だ。チームにどういった機
背景 ゴリゴリ系エンジニア、pageoです。 TwitterでMtgのあるべき姿についてツイートしたところ、ぼちぼちRT/いいねをもらえたので記事を書くことにしました。(お友達欲しいのでフォローしてください🙏) 最近大手クライアントとのPJに関わることが増えてきたのですが、事前アジェンダ共有なしに急にMtgが開催されるなどの無法地帯な場面に何度か遭遇したので、今回の記事では"Mtgの型"のあるべきについて自分の見解をまとめてみました。 はじめに Mtgの型 以下の章で紹介する"Mtgの型"はMtgというより議事録の書き方に寄っていますが、以下の章に書かれたことを実践することにより劇的にMtgの生産性は上がると思うので、この記事を機に是非自分/組織全体の"Mtgの型"について議論や検討をしてみてください。 いきなり結論 "Mtgの型"で説明する"教え"は以下の4つだけです 第一教: ~アジ
![[PM向け]死んだMtgを立て直せ~議事録から考える"Mtgの型"について~](https://cdn-ak-scissors.b.st-hatena.com/image/square/d4b118190a5bf163e1db49bbe20f392453552e68/height=288;version=1;width=512/https%3A%2F%2Fres.cloudinary.com%2Fzenn%2Fimage%2Fupload%2Fs--e1f08BaI--%2Fc_fit%252Cg_north_west%252Cl_text%3Anotosansjp-medium.otf_55%3A%25255BPM%2525E5%252590%252591%2525E3%252581%252591%25255D%2525E6%2525AD%2525BB%2525E3%252582%252593%2525E3%252581%2525A0Mtg%2525E3%252582%252592%2525E7%2525AB%25258B%2525E3%252581%2525A6%2525E7%25259B%2525B4%2525E3%252581%25259B~%2525E8%2525AD%2525B0%2525E4%2525BA%25258B%2525E9%25258C%2525B2%2525E3%252581%25258B%2525E3%252582%252589%2525E8%252580%252583%2525E3%252581%252588%2525E3%252582%25258B%252522Mtg%2525E3%252581%2525AE%2525E5%25259E%25258B%252522%2525E3%252581%2525AB%2525E3%252581%2525A4%2525E3%252581%252584%2525E3%252581%2525A6~%252Cw_1010%252Cx_90%252Cy_100%2Fg_south_west%252Cl_text%3Anotosansjp-medium.otf_37%3ARyuga%252520Irie%252Cx_203%252Cy_121%2Fg_south_west%252Ch_90%252Cl_fetch%3AaHR0cHM6Ly9zdG9yYWdlLmdvb2dsZWFwaXMuY29tL3plbm4tdXNlci11cGxvYWQvYXZhdGFyLzNkYTE4NjRiOTguanBlZw%3D%3D%252Cr_max%252Cw_90%252Cx_87%252Cy_95%2Fv1627283836%2Fdefault%2Fog-base-w1200-v2.png)
概要 試験工程をスプレッドシートで管理していたがそろそろ脱却したいと思ったので色々探してみました。 すると、同じことを考えている先駆者さんがいらっしゃったので参考にさせていただきました！ 導入に至った経緯 QA体制が未成熟 3名までなら無料で利用できる テスト計画・テスト結果をエクスポートできる 入力項目が整理されているので試験表の質を一定にできる 自動化したテストケースを管理できる 手動テストと自動テストの結果を併せて一覧できる APIにより自動テストの実行結果を自動的に反映することができる etc これは、中々良いツールなんじゃないか！？ ということで導入してみました 実際の導入方法を説明していきます 事前準備 以下からサインアップしてください サインアップ完了後、ダッシュボードに遷移した状態からスタートとします それぞれの設定方法は以下を参照してください 新しいプロジェクトを作成 プ
エンジニアが最初に覚えるNotion活用例！
この記事に書いてあること エンジニアがNotionを使い始めよっかな…って思った時、 意外と何から始めたらいいのか一瞬慣れるまでよく分からない場合もある気がするので、 最低限これだけでもやったら便利だよ！ ってのをまとめます。 私がマネージャーやPM・スクラムマスターとして動くことが多いため、プロジェクト管理寄りの視点が多めかもしれません。 動機 昨今のエンジニアは、いやエンジニアでなくても、日々の情報整理の重要性は爆裂に上がってますよね。 皆さんも日々多すぎる情報や思考の整理に疲れてませんか？ 安心してください。Notionを使えばオールオッケーです！！！ さっそく使用例3選 ①議事録・進捗日誌など とにかく黙ってList View。 リストで情報をまとめたかったらとりあえず思考停止でList Viewを使います。 日記 作業進捗 議事録 やりたいことリスト etc… やり方は簡単。/l
デブサミ2021の登壇内容 チーム開発における原則としてScrumは浸透しつつあります。一方で個人単位の行動管理・タイムマネジメントについては方法論が確立されていない状況があります。今回は、Scrumの原則を個人単位の行動管理に適用した上で、実装事例としてNotionを活用した方法を紹介します。
0→1フェーズで最も重要なサービスコンセプトのつくり方 | 実プロジェクトの事例付き｜梶谷健人 / 新著「生成AI時代を勝ち抜く事業・組織のつくり方」
サービスを0→1でつくる上でまず必要になるのが、サービスのコンセプトづくりです。 いままで自社事業や様々な企業との共同プロジェクトを通じてサービスづくりに取り組む中で、サービスのコンセプトづくり、すなわちコンセプトメイキングのプロセスにもある種の型があることに気付きました。 このnoteでは社内ドキュメントである「サービスコンセプトのつくり方」の内容を一部NDAでシェアできない資料を除いて全公開します。 ＜コンセプトメイキングの大前提＞🧐 STEP１：コンセプトとは何かを知ろうコンセプトが何かを知る上で、コンセプトの立ち位置と役割を知ろうコンセプトそれ自体は様々な形があり、非常に漠然としている。 なので、コンセプトがそれ以外の要素とどういった関係にあるのか、どういった役割を果たすのかという観点からコンセプトとは何かを理解しよう。 まずサービスアイデアは下図のような構造を持っている。 ある
2. ● 松岡 幸一郎 (@little_hand_s) ● DDD community jp、Agile Developers Community主催 ● DDD周りの話をするブログ書いてます ● WEB+DB PRESS 2019年10月号 特集「体験ドメイン駆動設計」 ● 「ドメイン駆動設計 モデリング/実装ガイド」執筆 自己紹介 2
架空プロジェクトを通してシステム開発とドキュメント作成を体験してみる（2022 Late） - Qiita
このコンテンツ作成の背景 プログラミングを体験できるコンテンツは沢山存在していますが、開発プロジェクト全体を通した流れを体験したり、実務では不可欠となるドキュメント作成を体験（学習）できるコンテンツは少ないので作ってみました。 とはいえドキュメント作成についてはテンプレート見ながら「こんなもんです」と解説する感じになります。。。 免責事項（いいわけ） 元々は社内の非技術系な人向けに研修用資料として作っていたものを、どうせなら公開するかな。という感じで再編したものなので、足りない部分やオレオレな部分、ゆらぎ、不整合、誤字脱字とかも多いと思います。「間違い」や「こうしたほうがいいよ」というのがあれば、コメント等で"優しく"教えていただけると助かります。少しずつ修正していこうと思ってます。 オレオレな情報だけでは申し訳ないので、一般社会ではプロジェクト関連のドキュメントはどう書くのか？については
私はフロントエンドエンジニアとして働いてはいるのですが、巡り合わせが悪いのでしょうか？まともなテストを書いたことがないんですよね。まあ、それもでテストくらい書けないとなぁ。なんて思ってはちょいちょい調べたりする日々を過ごしていました。 そんなある日、たまたま TDD（テスト駆動開発） についての動画を視聴してみました。 TDD 自体は知ってはいて、なんとなく知っているくらいの知識ではありましたが、分かりやすい説明とその思想が好きで、のめり込むように見てしまいました。 その後も何度か視聴して、フロントエンドでも TDD したいなと考え始めました。 普段テストすら書いていないのにいきなり TDD とも思わないこともなかったですが、実際に普段自分がさわっているようなコードに落とし込んで書いていくと、テストする本当の意味というものが、より正確に理解できてきたような気がします。 そんなテスト初心者の
エンジニアからマネージャになったときにあるだろうなぁってことを想像して遊ぶ - Mitsuyuki.Shiiba
ソフトウェアエンジニアの話ね。想像して遊んでるだけね。 スキルは高い まず、マネージャになってほしいって言われる時点で「仕事を任せられる」というエンジニアなんだろうな。それは、つまりコードを書くことに加えて、プロダクトをなんとかしてリリースする力と責任感をもっていて、それが会社にとってプラスになっている。 だから、チームを任せて同じようなエンジニアを育てて欲しいと期待されている。自分自身も、自分のスキルをもっと会社の役に立てるぞー！とやる気になっている。 任せたい そういう人がマネージャになって、あるだろうなぁと思うのは「どう任せたらいいんだろう？」という悩み。 自分が手を動かせばプロジェクトがなんとかなるのは分かっている。でも、自分はマネージャの仕事があるし、そこは自分の役割ではないし、実際のところ手を動かす時間なんてない。それはメンバーにやってもらわないといけない。 ただ、だいたいの場
近年はマネージャー業務の負荷が増大したことによって、ミドルマネジメントの限界問題が叫ばれています。そんな課題を解決するために株式会社Momentorの坂井風太さんが「マネジメント民主化モデル」を提唱しているということを知りました。 私たちチームメンバーはマネージャーをどう支えていくと良いのか、「マネジメント民主化モデル」とはどのようなものなのか、お話をお聞きしました。 株式会社Momentor 代表取締役。組織効力感などの理論を元に、様々な企業の人材育成/組織基盤の構築を支援をしている。 早稲田大学法学部卒業後、DeNAに入社。6年目で子会社の代表取締役に就任。同時にDeNAの人材育成責任者として、暗黙知化・属人化されやすい人材育成・ピープルマネジメント領域の体系化を行い、独自の人材育成プログラムを開発。2022年に株式会社Momentorを設立。
「アジャイル開発ってのに取り組むことになったんだけど、何を読んだらいいの？」という質問を受けたので答えてみた | DevelopersIO
「アジャイル開発ってのに取り組むことになったんだけど、何を読んだらいいの？」という質問を受けたので答えてみた 事業開発部の塩谷 (@kwappa) です。 いきなり家庭の私事で恐縮なのですが、今朝出がけに妻からタイトルのような質問を受けました。 そのまま「Slackにリンク投げといてね！」と言い残して出て行ったので（我が家では家庭の連絡にSlackを使っています）、やっきになってぺたぺた貼ったリンクをご紹介しようと思います。 といっても、アジャイル開発の経験がある方ならお馴染みのものばかりです。「あーなるほど」と納得していただけたら幸いですし、「これも読んどけ！」という推薦もお待ちしています。 「まずはこれを10回読む」 …と最初に貼ったのが「アジャイルソフトウェア開発宣言」 (Agile Manifesto)です。すべての始まりですから、ここを読まなければ始まりません。ほんとうは「100
こんにちは、こんばんは。年末年始は12/24〜1/9まで17連休を取ってみた執行役員CTO兼VPoPの山崎です。この連休に向けてスノーピークのIGTを買おうと思ったのですが、3ユニットのノーマルと4ユニットのロングどちらを買うべきか、悩みに悩んで、結果ノーマルを2つ買えば6ユニット！ということに気がついて平穏を取り戻しました。もちろんリビングシェルロングProも調達しました。あとは年越しキャンプの予約を取るだけです（さっさと取らないと）。 本ブログはエムスリー Advent Calendar 2022とプロダクトマネージャー Advent Calendar 2022の25日目の記事です。 双方の読者に届くようにダブルエントリーしてみました*1。 昨年は以下のとおり、エンジニア、QA、デザイナー、プロダクトマネージャーのためになりそうな良書を7冊選んでみました。未読の方がいれば是非読んでみて
ソフトウェア開発プロジェクトは、「兼務」を用いるチーム編成が多用されやすい対象ではないでしょうか。エンジニアであれば誰もが経験したことがあるでしょう。1人で複数のプロジェクトやチームを掛け持ちするあれです。マネージャーであれば、組織の人的リソース配置を考える時の手段の1つとして用いたことが何度かあるはずです。 しかし、兼務が引き起こす様々な弊害や問題については、あまり意識されないまま多用されているように感じます。 たとえば、兼務者本人にとってプロジェクトの掛け持ちは、仕事のマルチタスク化やミーティングの増加に苦しむ原因になります。組織の観点からも、兼務への依存は、知識の偏りや負荷の偏りという弊害をもたらすことに繋がりかねません。プロジェクトの観点から見ると、兼務という形での「人的リソースの共有」は、プロジェクト間での「リソースの競合」を引き起こしやすく、それが市場投入までの時間を長くする要
自由と責任を開発チームにもたらしたら開発速度が上がった話
ToDo管理ツール、いろいろありますよね。 古くは Remember the Milk、Evernote、Google GmailのToDoなども便利です。 しかし、たかだかToDoを管理するのに有料のサービスを使いたくはありませんし、ToDoにはそこそこに個人的なセキュリティが求められる要素があります。 Gmail ToDoだと管理が難しい例 GmailのToDoはメールに起因するToDoには便利ですが、カンバン方式のワークフロー、メールに起因しないToDo…例えば「ああ〜、あのイベントの参加費を月末までに精算処理して領収書提出しなきゃ〜」とか「来月のLTでの講演頼まれちゃったけど、上長伺いから広報チェックから事後記事公開まで 面倒くさい たいへん～」など、チェックボックス的な1段階の階層では片付かないToDoにはあまり効率が良くありません。GmailのToDoは期限もメールそのものへの
1時間でさわって学ぶDocker
Dockerを触りながら学んでいく、初心者向けの記事です。 用語の解説等はほとんどせずに、とにかく触ってみることを目的としています。 Phase 1: Dockerの基本 コマンドを試しながら基本操作を学びます。 Phase 2: Dockerfileをもう少し書いてみる Dockerfileを使って、簡単なWebアプリケーションを作成します。 Phase 3: Docker Composeを使ってみる Docker Composeを使って、複数のコンテナを一括管理します。 Phase 1: Dockerの基本 Dockerの基本的な操作を試してみます。 プロジェクトフォルダの作成 次のコマンドを実行して、プロジェクトフォルダを作成します。
【入門】事例で学ぶ要件定義 - Qiita
はじめに 最近プロジェクトマネジメント関連の仕事をする機会が増え、要件定義や設計関連の業務もするようになったので、私の経験を基に要件定義の具体的なプロセスや考え方について、まとめていきます。 本記事について Findy様の「要件定義 先達に学ぶ今日から使える実践テクニック Lunch LT」で登壇した内容を元に作成しています。 この記事の対象者 要件定義の基本や思考プロセスを学びたい人 エンジニアからプロジェクトマネジメントをやりたい人 ビジネスサイドとエンジニアサイドのコミニュケーション能力を向上させたい人 具体的な事例を通して要件定義を学びたい人 前提 紹介する内容はあくまで一例であり、プロジェクトやチームの状況に応じて調整が必要 あくまで自分(駆け出しPM)の経験に基づいた内容を言語化しています プロジェクト規模は10名〜20名のWebアプリ開発を想定しています システム開発の全体像
ソフトウェアの開発手法としてアジャイルを採用したプロジェクトはアジャイル以外の手法を採用したプロジェクトに比べて失敗率が268％も高いという調査結果が発表されました。 268% Higher Failure Rates for Agile Software Projects, Study Finds - Engprax https://www.engprax.com/post/268-higher-failure-rates-for-agile-software-projects-study-finds 268% higher failure rates for Agile software projects • The Register https://www.theregister.com/2024/06/05/agile_failure_rates/ 今回の調査はコンサルタント会社「
すでに終了したプロジェクトで、3億6000万円近い資金を集め、テレビ番組に取り上げられるなど大きな話題になっていた製品だ。その一方で、「優良誤認ではないか」（実際よりも優れていると偽ったり、競合よりも優れているように偽って宣伝する行為）や「怪しい」と疑問視する声が上がり、その反応もまた大きくなっていった。 同プロジェクトは何が問題だったのか。これらの課題に対して、マクアケはどう対処するのか。 関連記事 なぜ「時速5キロの乗り物」をつくったのか 動かしてみて、分かってきたこと 時速5キロで走行する乗り物「iino（イイノ）」をご存じだろうか。関西電力100％子会社の「ゲキダンイイノ」が開発したところ、全国各地を「のろのろ」と動いているのだ。2月、神戸市の三宮で実証実験を行ったところ、どんなことが分かってきたのだろうか。 丸亀製麺は“讃岐うどん”の看板を下ろしたほうがいい、これだけの理由 また
2024/09/28「XP祭り2024」登壇資料 https://confengine.com/conferences/xp2024
大事なのはアウトプットではなく、アウトカムとインパクト 吉羽氏はアジャイル開発やDevOps、クラウドコンピューティング、インフラ構築自動化、組織改革を中心にオンサイトでのコンサルティングやトレーニングを提供する専門家。吉羽氏がCTOを務めるアトラクタも同様のサービスを提供している。また吉羽氏は青山大学では非常勤講師としても勤務。『SCRUM BOOT CAMP THE BOOK』（翔泳社）をはじめ、専門領域に関する著書も数多く手がけている。 吉羽龍太郎氏 セッションはまず「アウトプットとは何か」という問いかけから始まった。「アウトプットに似た言葉として、アウトカムやインパクトといった言葉がある。まずこれらの関係性を整理したい」と吉羽氏。 アウトプットは「人や機械、組織が作ったものの『かたまり』や『量』を示すもの」。プロダクト開発におけるアウトプットとは、リリースしたプロダクトの機能やこな
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
これからのプロジェクトマネジメントに大事なのは「結果にコミットしない」こと クリエイティブな仕事に求められる“アジャイル思考”
Qiita記事「エンジニアの"有害な振る舞い"への対処法」への強烈な違和感 - kmizuの日記
副業PMが正社員PMと同じ認識を持てるように Notionを活用して自社制作したプロジェクト管理ツール
to Bスタートアップは「仮説検証」をやめようという話 - estie inside blog
リーダーのための「スクラムガイド」手引き | サーバントワークス株式会社
権限委譲しきれていない時に意識すべきこと - Konifar's ZATSU
IT業界の日常を図にしてみたら「地獄絵図」「ウチの会社の悪口はそこまでだ！」になった→これから業界に入る人は身震い
2kgから800gに激減、教科書「PMBOK」新版に何が起こったのか
失敗から学ぶシステム開発委託 - CARTA TECH BLOG
チーム中心の組織作りのための6つのチーム設計原則 - mtx2s’s blog
[PM向け]死んだMtgを立て直せ~議事録から考える"Mtgの型"について~
テスト管理ツール「Qase」でスプレッドシートによるテスト管理を脱却した件 - Qiita
Atomic Scrum 個人の生産性を最大化する方法
ベロシティを上手く使って 技術的負債を計画的に解消する
フロントエンド（React Testing Library）で TDD（テスト駆動開発）をする
マネージャーの負担を下げて、事業を伸ばす───『マネジメント民主化モデル』
エムスリーが誇る最強のプロダクトマネージャー育成環境：プロダクトマネージャー定例 - エムスリーテックブログ
兼務による体制構築はプロジェクトの効率を損なわせる｜mtx2s
自由と責任を開発チームにもたらしたら開発速度が上がった話
GitHubを最強のToDo管理ツールにする - Qiita
アジャイルを採用したソフトウェアプロジェクトの失敗率はその他の手法と比べて268％も高いことが判明
クラファンで3億6000万円を集めた製品は、なぜ謝罪に追い込まれたのか
つよつよリーダーが 抜けたらどうする？ 〜ナビタイムのAgile⽀援組織の変遷〜
プロダクトマネジメントの罠「ビルドトラップ」とは？ アジャイルや組織改革の専門家、吉羽龍太郎氏が解説
www.nikkei.com
www.yomiuri.co.jp
dic.nicovideo.jp
miyazaki.e-kurasi.com
yurinavi.com
www.nikkei.com