正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について [Kindle]

著者 :
  • ビー・エヌ・エヌ新社
4.45
  • (12)
  • (8)
  • (2)
  • (0)
  • (0)
本棚登録 : 163
感想 : 11
本ページはアフィリエイトプログラムによる収益を得ています
  • Amazon.co.jp ・電子書籍 (399ページ)

感想・レビュー・書評

並び替え
表示形式
表示件数
絞り込み
  • 会社の仲間と輪読会形式で読了した。
    毎週、章ごとに精読して、ディスカッションし合う形で進めたのが色々と学びが多かった。
    特に今の組織状況やプロジェクト状況との置き換えや比較などで経験をシェアしあうのがまさに対話形式でより深い気づきが得られた。
    最初はエンジニア系の人ばっかだったけど、越境してビジネス系の人たちまで巻き込めたので、アジャイルやスクラム開発をやっている人たちはこの本というツールをフックに対話を深めてもいいかもしれない。

    【目次】
    イントロダクション 正しいものを正しく作れているか?

    第1章 なぜプロダクトづくりがうまくいかないのか
    1-1 なぜ、プロダクトづくりに苦戦し続けるのか?
    1-2 多様性がプロダクトの不確実性を高める
    1-3 不確実性とのこれまでの戦い方
    1-4 アジャイル開発への期待と失望

    第2章 プロダクトをアジャイルにつくる
    2-1 アジャイル開発とは何か
    2-2 スクラムとは何か
    2-3 スクラムチーム
    2-4 スクラムイベント
    2-5 スクラムの成果物
    2-6 自分たちのアジャイル開発とどう向き合うべきか

    第3章 不確実性への適応
    3-1 アジャイル開発で乗り越えられない不確実性
    3-2 共通の軸を持つ
    3-3 余白の戦略
    3-4 スプリント強度を高める戦術
    3-5 全体への共通理解を統べる作戦

    第4章 アジャイル開発は2度失敗する
    4-1 チームは2度、壁にぶつかる
    4-2 プロダクトオーナーの果たすべき役割
    4-3 チームとプロダクトオーナー間に横たわる2つの境界

    第5章 仮説検証型アジャイル開発
    5-1 自分たちの基準を作る
    5-2 正しくないものを作らないための原則
    5-3 仮説検証型アジャイル開発における価値探索
    5-4 1回目のモデル化(仮説キャンバス)
    5-5 1回目の検証(ユーザーインタビュー)
    5-6 2回目のモデル化(ユーザー行動フローのモデル化)
    5-7 2回目の検証(プロトタイプによる検証)
    5-8 その他の検証手段
    5-9 仮説検証の補足―本質、実体、形態

    第6章 ともにつくる
    6-1 正しいものを正しく作る
    6-2 視座、視野を越境する
    6-3 チームとともに作る

  • 自分のあり方ややり方と
    チームや会社の現状やあり方ややり方にギャップがあるときに
    自分とは合わない だったり そこは自分の範疇じゃない とかで線を引くのは簡単だけど
    つくること(というよりアウトカムかな)から本当に目を逸らさないのであれば
    そこを自分なりに認識して、受け止めて、消化して、理解することも必要なことだと思った
    それが 視座、視野を広げる ということかな

    絶対的に正しいものはないけれど、そこに向き合う姿勢を崩さず(崩されず)保ち続けることは大事で
    そのさきに、そのときにおいての正しいものを見つけられて、その喜びも苦しみも背負えるチームがある
    という意味で6章はこれからのビジョンの提示(表明かな)で、私たちがこれから選択できる可能性のひとつ。

    そのための考え方ややり方として1〜5章という形にみえた。
    表題にはないけれど、やっぱり"旅"というたとえがよく似合う。

  • とても勉強になった。構成も内容もよいと思います。
    読み物的なのにしっかりおさえられてる感じ。
    アジャイルかじったものには、あるある満載。
    参考文献もうまく引用してくれてるので効率的に学べます。

  • プロダクト、プロジェクトマネジメントの本
    仮設検証とアジャイル開発について

  • アジャイル開発における起きがちな問題や
    考慮すべき事項をまとめてくれている本。

    確かにそうだなっと思うことが多く書いてあり、
    プロダクト開発において、大変参考になりました。
    何を大事にすべきか?といったことを意識しても、
    日々忙殺されて忘れがちなポイントが多かったので、
    繰り返し忘れないように学び続けて定着化したい。

    【勉強になったこと】
    ・プロダクト開発における過去と現在
     これまで:
      決められていることを実現することの難しさ
     現在:
      決められないこと、あるいは分かっていないことを
      実現する難しさ
     より不確実性の高い課題に迎えるスキルや姿勢が
     求められる時代になってきている。

    ・要求、要件、仕様の違い
     要求:こうしたい、こうありたいという希望
     要件:要求を実現するには何が必要か?
     仕様:要件を実現するための手段、仕組み

    ・変化に対応するために必要不可欠なのは、
    「誰も正解が分からないんだから、アタリを付けて、
      間違う前提を念頭に置きつつ、合意形成しながら
      進めていく」という一歩踏み出す勇気と、
     リスクに対するあらゆる対策を考えておくこと。

    ・スクラムにおける、スプリントには、
      スプリントプランニング
      デイリースクラム
      スプリントレビュー
      スプリントレトロプロスぺクティブ
     という要素で構成されている。

    ・デイリースクラムで共有することは、
     ①昨日何をやったか?
     ②今日やることは何か?
     ③昨日新たな障害を発見したか?

    ・早く少しだけ形に出来ることで得られる9つの意義
     ①フィードバックに基づく調整で、目的に適した
      プロダクトに仕立てられる。
     ②形にすることで、早めに関係者の認識を揃えられる
     ③作るものやチームの問題に早く気づける
     ④チームの学習効果が高い
     ⑤早く作り始められる
     ⑥結合のリスクを早めに倒せる
     ⑦Time to Marketが短い
     ⑧サンクコストを小さく出来る
     ⑨開発チームのリズムを整えられる

    ・変化に耐えるためには、調整の余白を意識する必要
     があり、調整の余白とは、
      「広さでコミットし、深さで調整する」
     ことを意味している。
     広さとは「プロダクトへの要求の範囲」を言う。

    ・やり抜く力を高める力の強化が変化に対応するには
     必要不可欠。あらゆる手段を考えてどうすれば出来る
     といったことを常に考え、ゴールに向かって進んで
     いく力が無いと上手く応対出来ない。
     場合によっては、これまで検討してきたことも、
     捨ててしまうといった思い切りも必要。

    ・成功循環モデル
     関係の質 → 思考の質 → 行動の質 → 結果の質

    ・プロダクトづくりの状況をクリーンに保つ条件
     ①実運用担当のデータが揃っている
     ②受入条件を定義している
     ③受入テストを実施している
     ④ベロシティを計測し、安定させている
     ⑤振り返りを実施し、カイゼンし続けている

    ・SAR(Share-Assert-Reflect)
     Share:共有
     Assert:表明
     Reflect:振り返り

    ・プロダクトを形にするために必要なスキルと知識
     プロダクトがどうあるべきかの牽引のため:
      ・受入テストの実施とテスト結果の活用
      ・ユーザーテストによるフィードバック取得と
       継続的な計測
     チームとの協働のため:
      ・コミュニケーション設計
      ・プロダクトバックログの管理方法
     プロジェクトを遂行するため:
      ・プロジェクトマネジメント
     開発メンバーとの意思疎通のため:
      ・ソフトウェア開発の基本的な知識

    ・正しいことを見つけるのは難しいこともあるので、
     むしろ正しくないことの学びを積み重ねることで、
     正しいことに近づく努力をしていくアプローチの
     ほうが効果的なこともある。

    ・仮説キャンバス
     対象者視点:
      ビジョン
       状況(傾向)
       代替手段
       チャネル
       顕在課題 潜在課題
      想定する市場規模
     提供者視点:
      目的
       提案価値
       優位性
       評価指標
       実現手段
      収益モデル

    ・プロダクトオーナー1人で回らないのなら、
    「補佐」ではなく「代行」を置いて意思決定の一部を
     委ねてしまうことも大切。

    ・別の視座を手に入れる手段として、
      自分で経験してみる
      その立ち位置の人との対話を通じて考えに触れる
     の2つがあり、後者をより実践していくべき。

  • プロダクトを作る上で大切な事が書いてある本。
    いわゆるプロダクトオーナーの教科書かな。

    しかしながら、プロダクトに関わる人みんなが意識して良いと思う内容が詰められているので、プロダクトを作ることを理解したい人に読んでほしい。

    不確実性や仮説検証は一人で立ち向かうんじゃなく、チームで立ち向かえるようにする。
    そんな戦略や戦術と進め方が学べる本。

    今でもたまに流しながら読んでいる。プロダクトやチームの向き直りにつかわせてもらっています。

  • エンジニアとしてもすごく学びの多い本。
    是非プロダクト開発に携わるすべての人に読んでほしい。

  • アジャイル開発が世間一般に広く知られた今、「アジャイルで開発する」というのは珍しくなくなってきた。ただし、それをうまく運用できていない現場も多々ある。

    以下のようなアジャイルがうまくいっていない案件に入っている人は読むべき本だと思う。

    ・アジャイル開発の案件に入ったがなぜかうまく機能していないチームにいる人
    ・明確な理由もなくアジャイルを選択したチームにいる人

  • アジャイルの中でもスクラム開発の手法を中心にプロダクトをどうプランニングし、どう開発するかの型が書かれている本。プロダクトオーナーであればある程度理解していることも多いので振り返りや辞書的に使うのがよさげ。

    メモ
    改めてSORはかたくつくる、SOEは不透明なので進化し続ける
    要求は、こうしたい、ああしたいというユーザーの業務や活動として実現したいこと。オフィスの外から見積もりみたいなー、とか
    こうしたい、の実現が要件
    その詳細条件で仕様
    回収不可能になったことをサンクコスト

全11件中 1 - 10件を表示

著者プロフィール

株式会社レッドジャーニー 代表。サービスや事業についてのアイデア段階の構想からコンセプトを練り上げていく仮説検証とアジャイルについて経験が厚い。株式会社リコー CDIO付DXエグゼクティブ、政府CIO補佐官も務めた。プログラマーからキャリアをスタートし、SIerでのプロジェクトマネジメント、大規模インターネットサービスのプロデューサー、アジャイル開発の実践を経て、自らの会社を立ち上げる。株式会社リコー CDIO付きDXエグゼクティブ。それぞれの局面から得られた実践知で、ソフトウェアの共創に辿り着くべく越境し続けている。著書に『カイゼン・ジャーニー』『チーム・ジャーニー』『デジタルトランスフォーメーション・ジャーニー』(翔泳社)、『正しいものを正しくつくる』『組織を芯からアジャイルにする』(BNN新社)、『いちばんやさしいアジャイル開発の教本』(インプレス、共著)、訳書に『リーン開発の現場』(オーム社)がある。

「2023年 『これまでの仕事 これからの仕事 ~たった1人から現実を変えていくアジャイルという方法』 で使われていた紹介文から引用しています。」

市谷聡啓の作品

  • 話題の本に出会えて、蔵書管理を手軽にできる!ブクログのアプリ AppStoreからダウンロード GooglePlayで手に入れよう
ツイートする
×