スクラムガイドに新たに追加された「プロダクトゴール」とは？ あるいはプロダクトゴールの設定には何が必要か？（前編） Regional Scrum Gathering Tokyo 2022 代表的なソフトウェア開発手法として知られる「スクラム」を開発したケン・シュウェイバー氏とジェフ・サザーランド氏によるスクラムの公式ガイド「スクラムガイド」。2020年11月付けの最新版には新たに「プロダクトゴール」と呼ばれる概念が導入されました。 スクラムガイドによると、プロダクトゴールはプロダクトの将来の状態を表しており、スクラムチームの⻑期的な⽬標である、と説明されています。スクラムチームにとって非常に重要なものだと位置付けられているのです。 この重要なプロダクトゴールをどのように考え、どう設定すべきなのでしょうか。 1月5日から7日までの3日間、都内およびオンラインのハイブリッドで開催されたイベント

プロジェクトが始まるときにかなり初期の段階でWBSを作ることは多いとおもいます。そのWBSの作成、プロマネやディレクターに任せっぱなしになっていないでしょうか。WBSはスケジュールをガントチャートで表したものを指していると思われがちですが、実はスケジュールだけでなく見積もりやアサインを精度高く行うためにも重要なものです。 たとえば「Webデザイン作成」というスコープにどのような実作業が含まれているかはWBSを作ることによって見える化しプロジェクトメンバーやクライアントと共有できるようになります。ときどき下記のように書かれたWBSを見ることがあります。 Webデザイン作成 ・作成 ・確認 ・修正 ・確認2 ・修正2 ・確定 しかし、これでは「Webデザイン作成」に必要な知識、さらには作業量・スケジュール・予算も分かりません。Webデザイン作成の例を続けると、下記のように「作成」のスコープを分

訳者注 本記事は、Dan Schmidt 氏のブログ記事「A Visual Vocabulary for Product Building」をご本人の許可のもと日本語訳したものです。 ninjinkunさん、Koshiro Kumikoさんにレビューにご協力いただきました。的確かつ、建設的で思いやりのあるアドバイスとフィードバックに感謝します。 同一著者の関連記事としてこちらもぜひ合わせてご覧ください：【翻訳】プロダクトマネジメントトライアングル 以下、翻訳本文です。 プロダクトビルダー（訳注：プロダクトをつくる人たち）が自分のプロダクトに当てはめられるような、成功するプロダクトをつくる方程式はありません。これは、プロダクトが置かれている常に変化するコンテキストに、プロダクトづくりの詳細が大きく左右されるからです。あるプロダクトで成功した戦略が別のプロダクトではまったくあわないこともありま

このコラムでは過去3回、「ピグマリオン効果」、「根負けさせる技術」、「感心させてYESと言わせる技術」という具合に、社会心理学を根底にしたヒューマンマネジメント論の具体的事例を説明しています。 私は、社会心理学をマネジメントに応用してきましたが、その過程での悩みは「心理学で学ぶ基礎的な知識と実際の実務レベルで駆使すべき策」がなかなか一致しないということでした。心理学やマネジメント論を知識として学ぶ意欲をもった人間は多いのですが、その知識を駆使して上手くマネジメントしている人物に会うことはほとんどありませんでした。 多くの人は、勉強は勉強、実務は実務と割り切っているように思えます。しかし、私は学問は実務を効率的に行うために存在しているということを正しく理解しています。このため、学問を実務に応用するための方法論を体系化してきたわけです。 前置きが長くなりましたが、今回も心理学を応用したマネジメ

今年こそは失敗プロジェクトをなくしたいと思っているみなさんこんにちは。ryuzeeです。 先日海外のサイトを見ていたところ、10 Signs When Projects Are Doomed to Failureという面白い記事を見つけたので、10の兆候それぞれをご紹介しつつ私の私見を述べておきたいと思います。 なお、アジャイルなのかウォーターフォールなのかは関係なくあてはまります。 失敗プロジェクトの兆候(1) プロジェクトメンバーが自分たちのタスクをこなすよりもプロジェクトの悪い状況について話し合いをするのに時間を使っている よくあるパターン。 たとえばなかなか仕様が決まらないので見切りで発射してみたら、途中で色々な仕様変更がおこったり考慮漏れが出てきたりして常に対策会議をしなければいけなくなったり、 品質が悪すぎて品質改善のための会議を頻繁におこなうことになったりといった状況。 タス

クックパッド検索・編成部の五十嵐啓人です。本業はレシピなどの料理検索を中心とした、主に「さがすユーザー」のサービス責任と、ユーザー数の拡大に責任を負っています。本日は部門を超えて取り組んでいる、ディレクションの役割を持つスタッフの活躍を広げるための取り組みについて紹介します。 ディレクションの役割を取り巻く当社の状況 日本のインターネットサービス界隈で「プロダクトマネージャ」の話題が盛り上がりを見せつつありますが、当社でもプロダクト開発を牽引・補佐する役割を担当しているスタッフを（名前の議論はありますが）慣習的に「ディレクター」と分類しています。 当社では、以前からエンジニアリングで活躍するスタッフについては、エンジニアマニフェストやエンジニア専用の評価制度作りなどに注力し、組織として期待するエンジニア像の言語化による職種の価値向上、およびキャリア支援を充実させてきました。しかし、エンジニ

) 4月1日に10年続くとあるWebサービスをフルリニューアルしました。 リニューアルの目的は、システムが度重なる機能拡張により、必要以上に複雑化してしまい、ちょっとした修正でも非常に時間がかかるので今後、事業のスケールを拡大していく上のが難しくなってきたためです。 特に大きなところですと、スマホサイトがリニューアル前のサイトだと、スマホとPCで機能が完全に分断されてしまっていました。サイトを立ち上げた当初はスマートフォンすらなかった時代なのでしょうがないとは思いますが、これをこれ以上保守していくのはしんどいので、スマホファーストの思想を取り入れサイトを設計していきました。 技術的にも、PHPからRubyに変更して、ELBやS3をとりいれ、Githubベースの運用に変更することで、時代の流れに取り残されていたWebサイトを今風な感じの仕組みへと変更しました。 リニューアル自体はプロジェクト

ミツエーリンクスでは、デジタルメディアにおける企業と顧客とのコミュニケーション課題を解決する、さまざまなサービスをご提供しています。ぜひ一度サービスページをご覧ください。

5つのマイルストーン（10から50）と6つの作業（AからF）がある7カ月間のプロジェクトのPERT図 PERT (ぱーと, 英: Program Evaluation and Review Technique）とは、プロジェクトマネジメントの際に用いられる手法の一つ。特定のプロジェクトの完遂までに必要なタスクを洗い出し、相互関係を明確にすることによってプロジェクトを素早く達成することを目的とする[1]。Project Evaluation and Review Techniqueとも。 PERTは、対象とするプロジェクトの完遂に必要なタスクを分析する手法であり、特に各タスク完了に必要な時間を分析し、プロジェクト全体を完了させるのに必要な最小時間を特定する。 このモデルは、ブーズ・アレン・ハミルトンが1958年、アメリカ国防総省 US Navy Special Projects Office

ほんとにヤバくなってギリギリになるまで相談しない人々: 切込隊長BLOG（ブログ） Lead‐off man's Blog http://kirik.tea-nifty.com/diary/2010/03/post-1da9.html いつも予防線が突破されるので、いずれにせよ年がら年中修羅場になってるわけだが、 修羅場をこなしているうちに、常在戦場みたいな組織が出来上がって、 毎日ラットレースをしている敗戦処理のエキスパート軍団ができちゃう。 戦況だけ見ると実に見事に負けてるんだけど、 担当した局地戦だけはどうにかなっちゃってるというような。 そういう組織は、人が内部から壊れていく。鬱になったり、病気になったりする。 まあ、発展性のない業務に長時間据えられて、 強いストレスに晒されながら安い給料で働くわけだからねえ。 一個一個のデスマーチは、マーチである限り終わりはあるわけだけど、 デス

先の記事ではWikipediaの誕生秘話として、その過程を見ることでどのようにしてWikipediaから今のWikipediaたりえるようになっていったのかという事実を、Wikipediaの前身である「Nupedia」からネット上での各種意見に至るまで、様々なものを見ることで経緯をたどりました。 次はこのWikipediaを裏から支える「管理者」の存在についてです。Wikipediaは決して誰もが勝手に書きまくって編集しまくってそれで質を維持しているわけではなく、その質を維持するために裏で支えている人々が少数ですが存在しているわけです。 今回はそのあたりを見てみましょう。 まず、これが管理者です。 Wikipedia:管理者 - Wikipedia どうすれば管理者になれるかというと、以下の通り。 現在のウィキペディアのルールでは、しばらくウィキペディアの更新をしており、ユーザー名がある程

筆者がドワンゴに入社したのは2000年2月。当時19歳の高校生でした。2000年3月の卒業式には，会社の有給を取って参加しました。ニコニコ動画にかかわる前は，携帯向けコンテンツや，社内向けミドルウエアの開発などにかかわっていました。現在は，ニコニコ動画を開発するチームの統括をしています。 http://d.hatena.ne.jp/shinno/ プロトタイプ「ニワビデ」 話は2006年11月にさかのぼります。ある日，同じ会社＊1で働くエンジニアの戀塚＊2から，メッセンジャー＊3でメッセージが届きました。内容は一つのURLです。送られてきたURLをWebブラウザで開くと，まるでYouTube＊4のような，見るからに動画共有サイトという画面が表示されました。いくつかの動画がサムネイルで表示されて並んでいます。 筆者はサムネイルの中から，OK Goの「Here It Goes Again」＊5

グーグルがどのようにソフトウェア開発を行っているかは、これまであまり詳細が明らかにされてこなかった。だがグーグルは6月10日、開発者向けイベント「Google Developer Day 2008 Japan」を開催し、グーグルのソフトウェアエンジニアがグーグルでの仕事術を語る「Google ソフトウェアエンジニアの日常」という講演会を実施した。スピーカーは、NECでITエンジニアとして勤務した経験がある藤島勇造氏。2006年からグーグルのソフトウェアエンジニアとして働いている。藤島氏は、グーグルでのソフトウェア開発方法について、グーグルのカルチャーと自身の見解を織り交ぜて語った。 グーグル ソフトウェアエンジニアの1日の流れ 藤島氏の1日は、朝10時ごろ出社し、メールをチェックすることから始まる。この時間にメールを見る理由は、米国にいる同僚に連絡が付きやすい時間帯だからだ。 午前中の主な

IPAX 2008を見に行ってきた - 発声練習 @ITの記事は、発言の意図をねじまげて強調しているという指摘があった。確かにこのエントリを見ると、かなり印象が違う。id:next49さんの方が、パネラーの発言の真意をよく理解してまとめている気がする。 しかし、私は、このエントリを読んでますますIT業界に絶望的な気分になった。 多分西垣さんの言いたいことはそうではない。西垣さんが引用した言葉は「10年泥のように働き、次の10年で人材管理などを十分勉強してもらい、次の10年で学んだことを発揮してもらう」というような意味合いだった。言いたい言葉の意図は「業務を体に覚えさせ、体で覚えた業務をもとに人材管理を学び、そして、管理・運営を行える人材となる」ということだと思う。 これは、個人に対する心構えとしては、納得できる部分もある。 実際、私はほぼこの時間割通りに生きてきている。83年に就職して93