無料マンガ・ラノベなど、豊富なラインナップで200万冊以上配信中!
従来のソフトウェア開発とは、「既に正解があり、記述された正解をそのまま形にする」というものづくりであり、いかに効率よく作るかという観点が主眼でした。そのため、正解の見えないなかで手探りで進んでいくことが必要となる不確実性の高い現代においては、うまく噛み合わない状況になっている開発現場も少なくありません。
本書では、共創を実現する具体的な手段としてのアジャイル開発を下敷きに、これからのソフトウェア開発/デジタルプロダクトづくりに、作り手(エンジニア、開発者、デザイナーなど)と、それを必要とする人(クライアント)がどのように臨むべきなのか、その考え方と行い方を具体的に提示する一冊です。
「正しいものを正しく作る(著者の掲げる理念)」とは、すなわち「正しくないものを作らない」戦略をとることであり、そのためには粘り強く「正しく作れているか?」と問いに置き換えながら探索的に作っていく必要があります。問いを立て、仮説を立て、チームととともに越境しながら前進していく。本書はそのための力強い手引きとなるでしょう。
※アプリの閲覧環境は最新バージョンのものです。
Posted by ブクログ
なぜプロダクト作りやソフトウェア開発はいつまで経っても上手くいかないのか?この永遠の課題に立ち向かう武器となるアジャイル開発の解説本。体系的理論よりも実践と失敗をベースにした構成になっており、自分が何に陥っているのかカウンセリングされているかのごとく見えてくる(ただし本書でも繰り返し言及されている「習得は非常に困難」には留意すべし)個人的には不確実性との向き合い方が書かれた第3章、特に「学びから生まれる課題」の話は目から鱗。開発が進み次にやることの洗い出しの精度が上がるのに比例してスケジュールが混沌としてくる違和感の正体はこれだったのか。今後も末永くお世話になる一冊になりそう。
Posted by ブクログ
# 読む前
アジャイル開発ができていれば価値あるプロダクトを作れるかというと、必ずしもそうではないということをまた改めて実感していた最近、まさになテーマの本だったので手にとった。
# 内容
プロダクトそのものの多様性と技術や作り手の多様化がプロダクト作りの不確実性を高めている。不確実性の中でいかに正解に近づけて行くか。その手法として早く少しだけ形にするアジャイル開発がある。
が、アジャイル開発をし、学びをすることでやることが増え、やることが変わり、よりプロダクト作りの不確実さが上がる。この不確実性に対処するためにやること
・共通理解(ミッション、目的)
・余白の調整(広さでコミット、深さで調整)、期間の余白、受け入れの余白
・成功循環、受入基準と受入テスト、ベロシティ計測とふりかえり
正しくつくっても間違ったものを作っていてはダメ
- 間違ったものを作ってしまう要因:開発チームとプロダクトオーナーの間の境界
作る人と作らない人/アウトプットとアウトカム
-> 「プロダクトとして何が正しいのか」の基準(あくまで見立て。
常に見直される。)にもとづいて越境
仮説検証とは分からないものを減らし、分かったことを増やしていく活動、
チームとしての何が正しいかの見立てを共通理解とする活動
- 正しくないことの学びを重ね、除外していくことで正しい(と思われる)もの
の範囲を狭めていくアプローチ
- 目的、実態、手段の順に段階的に絞っていく
- ユーザーに体験してもらわないとこれ以上の検証はできない、この検証のために
ソフトウェアを作る必要がある、という判断に達し多段階で初めてMVPの開発に
着手する
- MVP開発までの価値探索はモデル化(分かってることの図式化・言語化)と
検証の繰り返し
# 所感
アジャイル開発の理論は理解し、いざ実践してみるとぷつかる壁がいくつもある、そんな上手くいくもんじゃない。経験ある人ならほんとそれ、と思うことが冒頭イントロダクションの著者の経験、またそれ以降でも語られていた。そんな経験からくる「正しいものを正しく作れているか?」という問いかけは実践者にとても刺さる。
作る前の価値探索は間違ったものを作らないためにもとても大事。作ることはコストがかかる、作る前に検証できることはしてチーム共通理解の基準を持ってMVPを作る。
ただ、やっぱり絶対の正しさがないものを探索することは簡単ではないと思った。何を信じて分かった/分からないとするのか、何を検証していくのかはその時その時の判断をチームでしていくしかないんだろうなぁ。ただ、分からないことを分かったつもりになって進むのはやめよう。問い続けよう。
Posted by ブクログ
正しいものを正しくつくることへの挑戦は未来永劫続く。
そして、「正しくつくれる」一部の「できる」エンジニア、マネージャーが暗黙的に持っている知見を見事に言語化した良書である。
スクラム開発についても言及しているが、あくまで本書を完結させるために記載したものである。スクラム開発を深く理解するためには、一度同著者が書いた「カイゼンジャーニー」を一読することをお勧めする。(カイゼンジャーニーを読んだ後、本書を読むと良いかもしれない)
私見だが、「できる」エンジニア、マネージャーに最も必要な要素は視座と視野だと考えている。それを上上下下左右左右過去未来とはよくもまあ良い表現を思いついたものだと感心した。
とはいえ、視座と視野を広げる「教育」が必要だと思うが、いっそメンバーを巻き込んだコンサル的な教育も取り入れられれば良いのかな、と考えている。
個人的には近年SoRの案件が多いため、不確実性に挑戦することは少ないが、SoEの案件に携わる際には参考にしていきたい。
しかし、カイゼンジャーニー含め、なにかの節目で必ず開く本になりそうだ。
Posted by ブクログ
アジャイルに作るとは、作ることを通じて学びを得る活動
現在の私たちが手がけるプロダクトづくりは、誰かの頭の中に正解のイメージがあってそれをうまく取り出してコードにしていくという開発ではない
どうあるべきか本当のところ誰にもわからないが、なんとかして形に仕立てていく
顧客やユーザーという言葉は便利だが、代名詞でしかなく、その中身は多様だ
早く少しだけ形にする
アジャイルは開発手法の共通性を表現するための言葉
暗黙的な期待を放置したままでは合意形成にならない
自分自身の期待に当事者が気づいていない場合もある
広さでコミットし、深さを調整する
アイスボックス=開発対象から外しておくための受け皿
仮説検証で正解を見つけにいこうとするのではなく、自分たちが捉えられていないことを見つけるつもりでいく。
ネガティブな反応は、それに対処し、条件を変えることで結果が変わるのか確かめるうごきをとれる
課題仮説
機能仮説
インターフェース仮説
正しいものを正しく作る、とは「わかったことを正しく作る」ということ
多様性は不確実性を高めるが、その不確実性に適応する術もまた多様性。
役割を中心とした調整によるプロダクトづくりから、問いと向き合い続ける共創によるプロダクトづくり
Posted by ブクログ
昨日の「プロダクトをつくるとはどういうことなのか? -正しいものを正しくつくる-」に参加して、言われてみたらまだ本を買って読んでいなかったこともあり帰りに購入。
著者の体験を書籍にまとめたとのことですが、特に衝撃だったのは「アジャイル開発は二度失敗する」という章。早く少しだけ形にすることで新たにわかってきたこと(特に不安的要素)を現実的にどう受け止められるかという第1の壁、そして、プロダクトオーナーと開発チーム間の境界線という第2の壁がアジャイル開発に存在するということを痛切に思い知りました。私自身はアジャイル開発の経験がほぼないに等しいのですが、実際に取り組むときはこの2つの壁を意識しつつ、仮説検証をして回せるようにしたいものです。特にアジャイル開発をして上手くいかないと感じる方には一読すると良いかも知れません。
Posted by ブクログ
300ページを超える本書は、特に初めてプロダクトオーナーなど「プロダクトでの視座を求められる」エンジニアに勧めたい。
第一章 なぜプロダクトづくりがうまくいかないのか ではどこの現場でも失敗や混乱が起きていることを伝え
第二章 プロダクトをアジャイルにつくる ではアジャイル開発の基本について解説され
第三章 不確実性への適応 では「暗黙的な期待」「成り立たないトレードオフ」といったアジャイルを導入してもなお立ち上がってくる不確実性と向き合い、ひとまず「正しくつくる」方法を身につける。
第四章 アジャイル開発は2度失敗する では文字通り、2つの壁が提示され「正しくつくる」だけでは不十分であることが示され
第五章 仮説検証型アジャイル開発 では「正しいもの」を探索する方法を知り
第六章 ともにつくる で「目的に忠誠を誓う。しかし心中はしない、問いを持ち続け共創する」という価値観が掲げられ、またそのためには「正しいものを正しくつくれているか」という問いの重要性が説かれる。
上上下下左右左右過去未来、視座と視野を動かし
正しいものを探し
正しくつくる
300ページを超える重厚な本書を読めばたちどころにプロダクトがよくなるわけではないが、本書の内容を咀嚼し、実践し、失敗し、カイゼンし、血肉としていくことで「正しいものを正しくつくる」力がついていくのではないだろうか。
2019年、エンジニアにとって令和最初の必読書である。
Posted by ブクログ
◼️ Q.(問い)
「正しいもの」をどうやって見極めればいいか?
◼️ A.(答え)
仮説検証で「正しくないもの」を除外する →「正しそうなもの」をアジャイルに作る
◼️ Why( なぜこうまとめた? )
- 多様性が増したことで作るべきものの「正解」が描けなくなった
- とはいえ方向性の決めは必要 → 仮説検証で絞り込んでいく
- 方向性に沿って小さく作る →「正しそうなもの」に近づける
◼️ Why( そのために必要なことは? )
- ×「正しいもの」を見出す ではなく ○「正しくないもの」を除外する マインドセット
- プロダクトのWhyを言語化してチーム全体の共通了解にする
- 「正しいものを正しく作っているか?」を常に問い続ける
◼️ Keywords
- 作るべきものが曖昧に → 誰も「正解」を描けない
- プロダクトの多様性 x 作り手の多様性 が曖昧さを増やす要因
- Why(プロダクトのミッション, 大切にする価値観)を突き詰める
→ インセプションデッキでチーム全体の共通了解にする
- アジャイルでは「学びへの適応」「期待マネジメント」の両立が必要
→ 学びも期待も時間とともに変化していくことに留意
- ユーザーストーリーマッピング→ MVP 特定&ユーザー理解向上
- PO が受入条件を明確に示す&実際にテストして判断する
- ビジョン実現方法=コンセプト(Why+How)を併せて示す
- ×「正しいもの」を見出す ○「正しくないもの」を除外する
- 仮説検証で「正しい」の基準を随時アップデートしていく
- 仮説を「仮説キャンバス」で可視化&検証計画も漸進的に更新
- 方向性が固まったらMVPに注力 → プロダクトのコアを固める
- 視座・視野を変えて見る → 何が「正しい」かは見方次第
- 「正しいものを正しく作っているか?」を常に問い続ける
※アプリの閲覧環境は最新バージョンのものです。
ビジネス・実用
試し読み
ビジネス・実用
試し読み