市谷聡啓のレビュー一覧
-
Posted by ブクログ
システム開発における様々な問題を、主人公が成長しながら解決していく物語。
他の一般的な書籍と違い、物語として読むことができるため、自分の境遇と比較しながら読みすすめることができます。ポイントを逐一紹介しているため、説明はとても分かりやすいです。特に一番最後のあとがきで全てをまとめているのはとてもありがたかった。
主題は物語ではなく、様々な問題をどうやって解決するかを学ぶことなので、物語の全てが
・問題発生
・解説
・解決策を遂行
・うまくいった
という流れで進みます。1〜2章は解決策を他人が提示するので、まるでドラえもんみたいだと感じましたが、学びを得るのが主題なのでやむを得ないかなと思います。
主人公が最初に絶望していた割に、本人も周囲も都合が良すぎると感じることもあるにはありますが、そもそも物語の形をとって解説をしている本なので、出来事にリアリティがないことを責めるのもちょっと違うかなと思います。(リアリティ重視で分かりにくいと本末転倒ですし)
1つだけ不満を言うならば、発生する問題がほぼ全て解決手段の提示ありきで、特にスクラム開発における解決手法を次々と利用していく流れなのですが、手段はともかくなぜその解決策なのか、この問題の本質はどこなのかといった、手段を講じる前の段階を深く掘り下げてほしかったと思います。
とはいえ、全体的にはわかりやすくまとめられており、読後感も良いのでおすすめです。 -
Posted by ブクログ
新規事業のシステム開発は要求や仕様が明確でない場合がほとんど。
何を作るか、何故作るかを常に考えるが、
それが正解かどうかは分からない。
分からない中でも前に進んでいくために
アジャイルの考え方は必要だと思う。
ただ、チーム全員がその考えを持っていることは少なく考えを浸透させるのは難しい。
この本ではフィクションとしながらも
事実をベースにしているため
現場の緊迫感が伝わってきて良かった。
自分が一歩前に進むきっかけになりそう。
アジャイルや、事業開発で使うツールや
その使い方が分かりやすく説明されており
解説書としても使えそう。
一人でできること、
チームで出来ること、
チーム外部と出来ること、を
ストーリーと解説を交えて
記載されているのも読みやすい。
それで、あなたは何をしている人なんですか？ -
Posted by ブクログ
アジャイルに作るとは、作ることを通じて学びを得る活動
現在の私たちが手がけるプロダクトづくりは、誰かの頭の中に正解のイメージがあってそれをうまく取り出してコードにしていくという開発ではない
どうあるべきか本当のところ誰にもわからないが、なんとかして形に仕立てていく
顧客やユーザーという言葉は便利だが、代名詞でしかなく、その中身は多様だ
早く少しだけ形にする
アジャイルは開発手法の共通性を表現するための言葉
暗黙的な期待を放置したままでは合意形成にならない
自分自身の期待に当事者が気づいていない場合もある
広さでコミットし、深さを調整する
アイスボックス＝開発対象から外しておくための受け皿
仮説検証で正解を見つけにいこうとするのではなく、自分たちが捉えられていないことを見つけるつもりでいく。
ネガティブな反応は、それに対処し、条件を変えることで結果が変わるのか確かめるうごきをとれる
課題仮説
機能仮説
インターフェース仮説
正しいものを正しく作る、とは「わかったことを正しく作る」ということ
多様性は不確実性を高めるが、その不確実性に適応する術もまた多様性。
役割を中心とした調整によるプロダクトづくりから、問いと向き合い続ける共創によるプロダクトづくり
-
Posted by ブクログ
昨日の「プロダクトをつくるとはどういうことなのか？ -正しいものを正しくつくる-」に参加して、言われてみたらまだ本を買って読んでいなかったこともあり帰りに購入。
著者の体験を書籍にまとめたとのことですが、特に衝撃だったのは「アジャイル開発は二度失敗する」という章。早く少しだけ形にすることで新たにわかってきたこと(特に不安的要素)を現実的にどう受け止められるかという第1の壁、そして、プロダクトオーナーと開発チーム間の境界線という第2の壁がアジャイル開発に存在するということを痛切に思い知りました。私自身はアジャイル開発の経験がほぼないに等しいのですが、実際に取り組むときはこの2つの壁を意識しつつ、仮説検証をして回せるようにしたいものです。特にアジャイル開発をして上手くいかないと感じる方には一読すると良いかも知れません。 -
Posted by ブクログ
300ページを超える本書は、特に初めてプロダクトオーナーなど「プロダクトでの視座を求められる」エンジニアに勧めたい。
第一章 なぜプロダクトづくりがうまくいかないのか ではどこの現場でも失敗や混乱が起きていることを伝え
第二章 プロダクトをアジャイルにつくる ではアジャイル開発の基本について解説され
第三章 不確実性への適応 では「暗黙的な期待」「成り立たないトレードオフ」といったアジャイルを導入してもなお立ち上がってくる不確実性と向き合い、ひとまず「正しくつくる」方法を身につける。
第四章 アジャイル開発は2度失敗する では文字通り、2つの壁が提示され「正しくつくる」だけでは不十分であることが示され
第五章 仮説検証型アジャイル開発 では「正しいもの」を探索する方法を知り
第六章 ともにつくる で「目的に忠誠を誓う。しかし心中はしない、問いを持ち続け共創する」という価値観が掲げられ、またそのためには「正しいものを正しくつくれているか」という問いの重要性が説かれる。
上上下下左右左右過去未来、視座と視野を動かし
正しいものを探し
正しくつくる
300ページを超える重厚な本書を読めばたちどころにプロダクトがよくなるわけではないが、本書の内容を咀嚼し、実践し、失敗し、カイゼンし、血肉としていくことで「正しいものを正しくつくる」力がついていくのではないだろうか。
2019年、エンジニアにとって令和最初の必読書である。 -
-
-
-
Posted by ブクログ
スウェーデン警察のプロジェクトという実在のプロジェクトで、どのようにカンバン・リーン原則を適用したか、これに対して何を学びどのように解決しようとしたか、が書かれた本。
リーンやアジャイルの原則に則り、自分たちでいろいろ試してプロジェクトに合う方法を見つけていった過程は非常に刺激になる。
本に書かれている基本的なやり方だけをやっているだけではだめで、自分たちで何が問題かを考えてそれをどのように解決したらよいかを実践することが大事であることを再認識させられた。
手法としては「因果関係図」が目から鱗だった。なぜなぜで掘り下げるだけではなく、ループ図を作るように事象の関係を結んでいくことで、システム思考的に自分たちの問題点が何かを浮き彫りにしていく手法はとてもしっくりきた。
自然にできるようになるためには相当な数の実践と訓練が必要そうだけど、意識して行うことでなんとかモノにしていきたいところ。
「ループ図」などのバズワードを使わない、といったところもその通りで自分たちのシチュエーションに合わせて言葉を選ぶというのは非常に大切。
訳者あとがきにもぐっときたけど、平鍋さんの解説はほんとに素晴らしい。
リーンの定義もそうだけど、大野さんの「トヨタ生産方式」がアジャイルの源流であることは知っておいたほうがいいと再認識できた。
これから自分が遭遇するコンテキストの中で絶対に失ってはいけないものを再確認できたということで、この時期に出会えたことに本当に感謝。 -
-
Posted by ブクログ
非常に実践的な内容で学ぶべきところが多かった。アジャイルの難しい所は、どう実践すればよいかが分からない、これに尽きると思う。ここでは実際のプロジェクトでどのように問題を解決してきたかの一端を見ることができる。プロジェクトの規模、内容が違うのでこのまま使えるわけではないが大いに参考になると思う。そして一つのやり方にとらわれることなくプロセスも常にカスタマイズするべきであることもわかる。決まった手順にとらわれがちであるが、組織、チームに合ったやり方というものもあるし、全ての開発フェーズで同じやり方で良いわけではない。プロセスを変えることを恐れてはいけないし、むしろプロセスを適切に変化させることが開発を成功に導くカギであることが分かる。
技法そのものの説明としては「テスト自動化の戦略」「因果関係図」が特に有用だった。「テスト自動化の戦略」はプロジェクトの途中からテスト自動化をするという難しい問題に対する一つの解が示されている。テスト自動化を導入する手順書は多くあるが、プロジェクトの途中から導入するということを扱ったものは見たことがなく、大いに参考になった。また、「因果関係図」はいわゆるトヨタの「A3シンキング」であるが、具体的な例と主に気をつけるべきポイントが端的に示されており、ほんの数ページであるにもかかわらずそれの意味するところ、有効性、やり方までがしっかりと示されており、すぐにでも使えるようになっていた。 -
-
-
-
-
Posted by ブクログ
デブサミ関西2013にて、本書訳者の藤原大さんのセッションを聞いて以来、発売前から楽しみにしてました。そしたらなんとRakuten Technology Conference 2013で、@jcoplienさんに質問させていただいたのがきっかけで発売直後に頂きました。嬉しすぎてわけわからないです。
で、内容はとても生々しくて良いです。現場で考え続けてきたことを、なぜそのように考えたのか、どんな課題があったのか、つぶさに書かれています。200ページ弱の薄めの本ですが、内容はとても濃かったです。
「スクラムを取り入れたチームに起きる問題は、スクラムを採用したことが原因ではない。むしろ、抱えている問題がスクラムによって掘り起こされたんだ。(p.24)」
「あらゆるキューを制限する(p.57)」この考え方は目から鱗でした。これがないとWIP(Work In Progress)が無制限に増えていき、なおかつその状態が見えないとフォローも不十分になって、デスマに突入するんだろうな。
「プロダクトのバグは、プロセスのバグから生み出される症状だ(p.58)」プロセスのバグをほっとくと、プロダクトのバグが増え、その対応に追われてプロセスのバグを直す時間がなくなり、さらにプロダクトのバグを生み出すってゆう悪循環に陥ってしまう。継続的にプロセスを改善することが重要。 -
-
-
Posted by ブクログ
◼️ Q.（問い）
「正しいもの」をどうやって見極めればいいか？
◼️ A.（答え）
仮説検証で「正しくないもの」を除外する →「正しそうなもの」をアジャイルに作る
◼️ Why（ なぜこうまとめた？ ）
- 多様性が増したことで作るべきものの「正解」が描けなくなった
- とはいえ方向性の決めは必要 → 仮説検証で絞り込んでいく
- 方向性に沿って小さく作る →「正しそうなもの」に近づける
◼️ Why（ そのために必要なことは？ ）
- ×「正しいもの」を見出す ではなく ○「正しくないもの」を除外する マインドセット
- プロダクトのWhyを言語化してチーム全体の共通了解にする
- 「正しいものを正しく作っているか？」を常に問い続ける
◼️ Keywords
- 作るべきものが曖昧に → 誰も「正解」を描けない
- プロダクトの多様性 x 作り手の多様性 が曖昧さを増やす要因
- Why（プロダクトのミッション, 大切にする価値観）を突き詰める
→ インセプションデッキでチーム全体の共通了解にする
- アジャイルでは「学びへの適応」「期待マネジメント」の両立が必要
→ 学びも期待も時間とともに変化していくことに留意
- ユーザーストーリーマッピング→ MVP 特定＆ユーザー理解向上
- PO が受入条件を明確に示す＆実際にテストして判断する
- ビジョン実現方法＝コンセプト（Why＋How）を併せて示す
- ×「正しいもの」を見出す ○「正しくないもの」を除外する
- 仮説検証で「正しい」の基準を随時アップデートしていく
- 仮説を「仮説キャンバス」で可視化＆検証計画も漸進的に更新
- 方向性が固まったらMVPに注力 → プロダクトのコアを固める
- 視座・視野を変えて見る → 何が「正しい」かは見方次第
- 「正しいものを正しく作っているか？」を常に問い続ける -