プロダクト作りの在り方を探るコラム第5回｜ 仮説キャンバスでプロダクトの仮説を立てよう 市谷聡啓 | 国内唯一のCTO/VPoE育成・転職支援サービス「OCTOPASS（オクトパス）」
プロダクトバックログに作るべき内容を積み上げていく。スプリントによるプロダクト作りを運営しているようであれば、プロダクトバックログが開発の中心にあることでしょう。プロダクトバックログはプロダクト作りを駆動する存在と言えます。では、肝心のプロダクトバックログはどのようにして生み出されるものでしょうか。「プロダクトオーナーの勘と経験によって積み上げている」だけでは、作るべきものの妥当性は分からないままですし、プロダクトチームの開発に対する自信も一向に高まっていかないでしょう。ゆえに、プロダクトバックログを積み上げていく前に仮説検証が必要です。今回は、仮説検証のための基本的な道具となる「仮説キャンバス」について扱います。 なぜ仮説キャンバスが必要なのか まず、仮説検証とはどのような活動でしょうか。その言葉の通り、仮説を立てて、その内容の確からしさを検証する活動のことです。立てる仮説の対象は、様々
【資料公開】マネジメント向けアジャイル開発概要
みなさんこんにちは。@ryuzeeです。 2020年1月20日にとある企業の経営レベルの方向けにアジャイル開発の概要について説明した際の資料を公開します。 自社で経営者の方やマネージャーの方にアジャイル開発がなぜ必要なのかを説明する際の参考になれば幸いです。 （スライドはこちらからもご覧いただけます：https://slide.meguro.ryuzee.com/slides/101） 本資料は、なぜ今アジャイルが必要なのかという点をまず理解していただけるようにコンテキストのすり合わせに主眼を置いています。 経営者やマネージャーの方にとってはスクラムの具体的なやり方といった手法部分はあまり関係なく、それによって組織がどういう影響を受けるのか、組織としてどんな取り組みをすべきなのかが分かることが重要なためです。 単一チームや小さなプロダクトでアジャイル開発をするのと、組織的にそれをスケールし
「アジャイル開発ってのに取り組むことになったんだけど、何を読んだらいいの？」という質問を受けたので答えてみた | DevelopersIO
事業開発部の塩谷 (@kwappa) です。 いきなり家庭の私事で恐縮なのですが、今朝出がけに妻からタイトルのような質問を受けました。 そのまま「Slackにリンク投げといてね！」と言い残して出て行ったので（我が家では家庭の連絡にSlackを使っています）、やっきになってぺたぺた貼ったリンクをご紹介しようと思います。 といっても、アジャイル開発の経験がある方ならお馴染みのものばかりです。「あーなるほど」と納得していただけたら幸いですし、「これも読んどけ！」という推薦もお待ちしています。 「まずはこれを10回読む」 …と最初に貼ったのが「アジャイルソフトウェア開発宣言」 (Agile Manifesto)です。すべての始まりですから、ここを読まなければ始まりません。ほんとうは「100回読む」と書きたかったのですが、のっけからハードルは上がるし感じ悪いしなので自重しておきました。 しかし、表面
アジャイル宣言の背後にある原則
私たちは以下の原則に従う: 顧客満足を最優先し、 価値のあるソフトウェアを早く継続的に提供します。 要求の変更はたとえ開発の後期であっても歓迎します。 変化を味方につけることによって、お客様の競争力を引き上げます。 動くソフトウェアを、2-3週間から2-3ヶ月という できるだけ短い時間間隔でリリースします。 ビジネス側の人と開発者は、プロジェクトを通して 日々一緒に働かなければなりません。 意欲に満ちた人々を集めてプロジェクトを構成します。 環境と支援を与え仕事が無事終わるまで彼らを信頼します。 情報を伝えるもっとも効率的で効果的な方法は フェイス・トゥ・フェイスで話をすることです。 動くソフトウェアこそが進捗の最も重要な尺度です。 アジャイル･プロセスは持続可能な開発を促進します。 一定のペースを継続的に維持できるようにしなければなりません。 技術的卓越性と優れた設計に対する 不断の注意
アジャイルソフトウェア開発宣言
私たちは、ソフトウェア開発の実践 あるいは実践を手助けをする活動を通じて、 よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。 プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を、 価値とする。すなわち、左記のことがらに価値があることを 認めながらも、私たちは右記のことがらにより価値をおく。 Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler
大規模にアジャイルをやるにはどうしたらいいか、に対する答え - 海と山が好き
大規模にアジャイルをやるにはどうしたらいいですか？ 答え 大規模にしない 以上終わり。 先日大規模な組織レベルでのアジャイル導入をするという人と話す機会があったのだが、どうするのがいいですかね？って聞かれて出た感想が、「大規模にしない」だった。 ドメインも違う、プロダクトも違う、顧客も違う、作るチームも違う そんなチームのプロセスを同期や依存させる意味あるのかと。 「DB にアクセスするときは必要ないけどこっちの DB へもコネクション確立してね！」 って言われたらどう考えても頭おかしい人でしょ。 依存がいらないところをわざわざ依存させない。 偉い人が同じ？組織上同じだから？ 依存を増やしてどうやって変化に対応するのか？ 変化に対応するコストを高めるだけの価値がその偉い人が気持ちよくなることにあるのか？ そんなことを感じないでもない。 アジャイル界隈で悪名高い？Scaled Agile F
プロダクト開発を内製化やアジャイル化する際のどこからはじめるかの勘所の話 #postudy - @i2key のBlog
本ポストは特に私が所属する組織の見解ではなく、私が今までの経験＆自分がチームを作るときにチームの目標を考えたり、組織内にアジャイルを導入したり、組織内での開発チームの位置づけをどうするかなどなどを考えるときに意識していることですのであしからず。 内製化や、アジャイル化のビジネス上の効果を得やすい部分をビジネスモデルから考える 昨日、プロダクトオーナー祭り2016で「DevOpsとリーンスタートアップ時代のプロダクトオーナーシップ」というセッションでパネルディスカッションに登壇させていただきました。 postudy.doorkeeper.jp そこで内製化や、アジャイル化はどの部分からやるのがよいかみたいな話の流れかなにかで、「System of Engagementでなおかつ成果課金のようなエンジニアの書いたコード上で売上が立つモデルだとエンジニアリングが直接売上に寄与しやすいためビジネス
“面白さ”を追求したら生き物みたいな会社になった 「つくる人を増やす」カヤックの組織戦略 | DHBR最新号から｜DIAMOND ハーバード・ビジネス・レビュー
1974年生まれ。慶應義塾大学環境情報学部卒業後、ソニー・ミュージックエンタテインメントを経て、1998年に学生時代の友人とともに面白法人カヤックを設立。神奈川県鎌倉市に本社を構え、オリジナリティのあるコンテンツをウェブサイト、スマートフォンアプリ、ソーシャルゲーム市場に発信。ＴＯＷ、クックパッドの社外取締役を務める。著書に、『面白法人カヤック会社案内』（プレジデント社、2008年）、『アイデアは考えるな。』（日経ＢＰ社、2009年）など。 創業時の思い「仲間と面白い会社をつくろう」と、経営理念「つくる人を増やす」を追求していくと、アジャイル組織になっていた面白法人カヤック。事業は徐々に、広告やＰＲの受託開発、ソーシャルゲーム、ブライダルなどと幅広く膨らんでいくが、組織構造はフラットで、意思決定は現場で下されている。存在目的を重視し、自主経営を徹底しながら、全体性を確保している同社は、いま
なぜモダンなプロダクトチームによるリーンなプロダクト開発が必要なのか｜川嶋一矢@メルペイPM
はじめにメルカリUK版の立ち上げを終え2018年3月に帰国しました@tsumujikazeです。今は東京でメルペイのProduct Managerをしています。 イギリスではいわゆるモダンなプロダクトチームでのLeanなプロダクト開発を経験しました。得るものが多かったので、なるべく多くの人に知ってもらいたいと思いこのポストを書きました。 PMF →リーンプロダクトのプロセス →モダンなプロダクトチーム（組織論）という流れになっています。 はじめに 本編 ・何のためにプロダクトを作るのか ・プロダクトマーケットフィット ・PMFピラミッド ・要件定義フェーズのリーン化 ・モダンなプロダクトチームでのリーン開発とは おまけ ・Problem Space vs. Solution Space ・Problem Solution Fitとは ・エンジニア組織とPM組織の特性について ・バリュープロ
続・拝啓『変わらない開発現場』を嘆く皆様へ ～ ウォータフォール ＆ アジャイル編～ – とあるコンサルタントのつぶやき
とあるコンサルタントのつぶやき とあるコンサルタントのつぶやき MCS （Microsoft Consulting Services） の某コンサルタントがまったり語るテクノロジのお話です。 ご存知の方も多いと思いますが、ここ最近、うちの会社の歌って踊れる DevOps エバの牛尾さんが、こんなエントリを書かれていました。 私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い http://simplearchitect.hatenablog.com/entry/2016/06/20/080807 「自分で人生を決めない」ことが、決定的に業界の進化を遅らせているのかもしれない http://simplearchitect.hatenablog.com/entry/2016/06/24/080049 特に前者は炎上気味でしたが；、二回分のエントリを通して読めば、牛尾さんが言いたい
永和さんの「価値創造契約」が大苦戦を強いられている件 - GoTheDistance
この資料、非常に衝撃的だった。中の人がここまで公開していいものなのか、という意味でも。 俺の価値創造契約 from Fumihiko Kinoshita 永和さんの価値創造契約とは 新しい契約形態での受託開発サービス「価値創造契約」 ｜ 永和システムマネジメントに詳しくありますが、簡単にいえば「初期費用無料で、常に改善・運用をしながら月額定額制でシステム利用料を頂く」というビジネスモデルです。価値あるシステムは必ず長く使われ変更を伴うのだから、その変更を受け入られるモデルを提供すれば双方にメリットがある。これが立脚点のようです。 2013年営業実績、0件 資料によればテレアポを800社行い、様々な展示会にも出展されたそうです。12社にコンタクトできたけれど受注は0件だと書いてあります。マーケティングに失敗してしまったと言って良いでしょう。 受託開発の弊害と指摘される「価値あるシステムを作り
「大手SIerに負けない」、永和システムとクラスメソッドがタッグ
中堅システムインテグレーターの永和システムマネジメントとクラスメソッドが協業に向け準備を進めている。永和システムはアジャイル開発やRubyによる開発、クラスメソッドはRIA（リッチ・インターネット・アプリケーション）技術やクラウドを利用した開発、スマートフォン向け開発に強みを持つ。両社の強みを合わせれば、「大手SIerよりも素早く、価値をもたらすシステムを開発できる」と、永和システムの市谷聡啓サービスプロバイディング事業部アジャイルグループ主任は自信を見せる。 永和システムの持つ強みの一つとして、独自の契約形態がある。システム開発を継続して進めることを前提とするアジャイル開発では、契約が導入のネックになるケースが多い。同社はこの問題の解決を狙い、「価値創造契約」と呼ぶ契約形態を打ち出している。 価値創造契約では、システムを継続的に改善・発展させていくことを前提に、主要部分をひと通り開発する
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
歴史ある会社・組織で、VUCA時代に対応できるプロダクト作りをするための課題と対応方法とは / Building products for the VUCA era in a long-lasting company
Ron Jeffriesが、開発者は"Agile"を捨てるべきと発言
国内の開発者が使っている言語、1位C、2位VB、3位Java。アジャイル開発は2割が採用、半数以上がウォーターフォール。IDC調べ