市谷聡啓のレビュー一覧

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

個人で、チーム内外で壁が立ち塞がった時に手段やアイデアを得るためにまた読みたい。自分もみんなと越境できたらと思う。

いちばんやさしいアジャイル開発の教本 人気講師が教えるDXを支える開発手法

いちばんやさしいの名の通り、アジャイル開発とは何であって何ではないのかが網羅的にまとまっている。

理念、思想から実際のプラクティスの紹介、よくある誤解に対する解説を通して改めてアジャイル開発とはなにかを解説するといった流れで、関連書籍を読むにあたって最初に読む本として適していそう。

この本だけで具体的な実践に進むのは少し難しそうと感じたものの、これから踏み出す方向性を定める上で間違いなく道標になってくれると思う。

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

目次
・アジャイルとは
・なぜアジャイルが生まれた？
・アジャイルの２つの要素
・クイックに開発するための開発組織
・開発組織の２つの壁
・仮説検証で重要な3つのこと
・多様性と共創

・アジャイルとは？
正しいっぽいプロダクトを小さく素早く走りながら作っていくこと

・なぜ生まれた？
➀課題が複雑で正しいプロダクトがなにかわからなきなってきたから
➁チームの役割も多様になったから

・アジャイル開発の２つの要素
➀クイックに動く開発組織
➁仮説検証

・クイックに開発するための開発組織
クイックに開発するために、
-開発のルール
-開発フロー
-スプリント(なに作る)
-機能ゴール
-定期的な開発フロー/組織KPT
の設定、実行が必要

・開発組織の２つの壁
➀アジャイル形式を実践できない
これは実践知になるまでPDCA回すのみ

➁開発側とプロダクトオーナーの言語の壁
これはBiz側がんばろう、あと専門用語ダメ

・仮説検証で大切な3つのこと
➀基準/組織・事業・プロダクトの目的設定/共有
➁正しくないこと(やらないこと)の設定/共有
③目的→機能→手段の順番での検証
(コード書く前に声聞いてPDCA回せ)

・多様性と共創
多様なメンバーの力で、多様な視点(上下、左右)から、問いに向き合う。

ユーザーをも巻き込んで、共創していく。

いちばんやさしいアジャイル開発の教本 人気講師が教えるDXを支える開発手法

アジャイルの考え方そのものから、具体的にどうやっていくかを、細かく学べる本です。

システム開発をメインに記載されていますが、あらゆるプロジェクトで適用できる考え方が多く記載されているので、多くの方が読んでおくべき本だと思いました

チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで

チーム開発で起こるさまざまな問題を物語仕立てで紹介し、それを解決していく「ストーリー」部分と取り組んだ内容をより汎化した「解説」部分の組み合わせ16個で構成されている一冊。

「ストーリー」部分は共感する部分が多く、話は読み進めやすい。「ストーリー」部分の解決のところは「そんなに上手くいかないよなあ」と思うこともあるが、解決策の一事例として捉えておき、それぞれの現場に応じて考えておく必要はあると思う。全くの参考資料がないわけではなく、「解説」部分にて丁寧に問題の本質や解決策の手札について記されているので、都度読み直すと良いかと思う。

個人的には「アジャイル原理主義」みたいなことに出くわすことが多く、その対処を色々と思い悩んでいたので、「ストーリー」で取り上げられていたときには自分だけでなかったんだと安心感と解決策に興味深く読ませていただいた。

もちろん本書もこれが正解と言うわけではないので、これを参考に自分の現場で起きていることに立ち向かうことが必要かと思う。

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

正しいものには行きつかずとも、わかったものを正しく作る。分かるに行きつくことに、もっと向き合わねばと思った。

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

アジャイルとはというよりも
カイゼンとは何か、どういう手法があるか、そしてなによりも自分の考えを向きなおることができる書籍だと思います。
特にですが今に不満がある方にはぜひ読んで欲しいと思います。

いちばんやさしいアジャイル開発の教本 人気講師が教えるDXを支える開発手法

後書きにもあったけど、アジャイルの普及と誤解の払拭に苦心の末発行されたご様子。
故に「手法」も勿論ありつつ「考え方」の伝達が中心で、確かに本ってそれ一冊で全てが理解出来て明日から全部出来るってないよな、と別の部分の思案に至ったり。

読んで終わりではなく、立ち止まった時に振り返る際にめくり直す一冊として、買ってよかったと思わされた。

チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで

‪プロダクト開発において避けては通れないどころか核であるチームビルディングの指南書。小説と解説が交互に来る構成なので読みやすいんだけど、正直PMやってる今の自分の状況に当てはまりすぎるほど当てはまっていて心が痛くなり読み進めるのが怖い面もｗ新型コロナでリモートワークが普及した今となっては第6話が単一チーム基本編に入ってくるのかな？長くお世話になりそう。‬

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

これはサービスなどに関わる人にとって、読むべき本だ。

顧客への価値の届け方、そのための取組み手法が、小説だてて見事に擬似体験出来るように描かれている。例えばDX、サブスクなどのキーワードに関わっていて、でもどうやったら良いのだろうと思っている人なら、皆が知りたいと思っている内容じゃないだろうか。

正直、一部はエンジニア向けの言葉が含まれているので、？と思う箇所がある人もいるかも知れない。でも、そこはサラッと流して、仕事の取り組み方として全体をさらっと理解すれば、物凄く価値がある内容と気づけると思う。

いちばんやさしいアジャイル開発の教本 人気講師が教えるDXを支える開発手法

他のアジャイルに関する書籍よりも、日本の開発現場に寄り添った内容で、アジャイルをチームの共通認識とするための書籍として良いと思いました。

いちばんやさしいアジャイル開発の教本 人気講師が教えるDXを支える開発手法

社内でアジャイル，アジャイル言われるものの何なのそれ状態だったのでとっかかりとしてたまたま書店で見つけて購入．
※基本的には，私はウォーターフォールしか経験してないと思っています

気になった（気にとまった）ことをいくつか：
1. 顧客が必要なものにフォーカスし，素早くプロダクトを開発する手法
2. マックだって，ヘルシーな「サラダマック」の売れ行きは乏しかった（顧客インサイト）
3. 短い期間でリリースし，フィードバックを受け，改善するというサイクル（アジャイル開発の基本）
4. 要件定義はあくまでも仮説．本当に必要なものから乖離したソフトウェアを作り込んでしまうリスクがある．
5. 前工程の遅れが後工程を圧縮する（☜まさにこれなんだよなぁ）
6. 要求の変更はたとえ開発の後期であっても歓迎しますという原則（アジャイル開発の原則）
7. 小さく試して軌道修正
（8. YouTubeは元はデート相手を探すマッチングサービス）
9. 目的や目標，前提や制約，優先基準決定にはインセプションデッキ（WhyとHowを明らかに）
10. 一定の間隔で区切って開発する（スプリント，1～2週間）
11. タスクの見える化と優先順位の決定（スプリントバックログ）
12. 作るべきものの一覧で作るもの・作る順番を明確化（プロダクトバックログ）
13. TODO：やること，DOING：やっていること，DONE：やったことの状況の見える化（タスクボード）
14. タスクサイズはフィボナッチ数列を使うと見積誤差とタスク感サイズ比較がやりやすい
15. 昨日やったこと，今日やること，困っていることを把握して軌道修正（朝会，日常の見える化）
16. KPT：振り返りも1～2週間で実施
17. 繰り返し作業が3回以上あれば，断続的インテグレーション導入

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

‪なぜプロダクト作りやソフトウェア開発はいつまで経っても上手くいかないのか？この永遠の課題に立ち向かう武器となるアジャイル開発の解説本。体系的理論よりも実践と失敗をベースにした構成になっており、自分が何に陥っているのかカウンセリングされているかのごとく見えてくる（ただし本書でも繰り返し言及されている「習得は非常に困難」には留意すべし）個人的には不確実性との向き合い方が書かれた第3章、特に「学びから生まれる課題」の話は目から鱗。開発が進み次にやることの洗い出しの精度が上がるのに比例してスケジュールが混沌としてくる違和感の正体はこれだったのか。今後も末永くお世話になる一冊になりそう。‬

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

実際の開発現場を経験したことがある人にはすごく刺さる！
エンジニアじゃない人にもオススメできるような思考フレームワークがたくさんあっておすすめです。
何回か読み返す本になりそう

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

# 読む前
アジャイル開発ができていれば価値あるプロダクトを作れるかというと、必ずしもそうではないということをまた改めて実感していた最近、まさになテーマの本だったので手にとった。

# 内容
プロダクトそのものの多様性と技術や作り手の多様化がプロダクト作りの不確実性を高めている。不確実性の中でいかに正解に近づけて行くか。その手法として早く少しだけ形にするアジャイル開発がある。

が、アジャイル開発をし、学びをすることでやることが増え、やることが変わり、よりプロダクト作りの不確実さが上がる。この不確実性に対処するためにやること
・共通理解（ミッション、目的）
・余白の調整（広さでコミット、深さで調整）、期間の余白、受け入れの余白
・成功循環、受入基準と受入テスト、ベロシティ計測とふりかえり

正しくつくっても間違ったものを作っていてはダメ
- 間違ったものを作ってしまう要因：開発チームとプロダクトオーナーの間の境界
作る人と作らない人/アウトプットとアウトカム
-> 「プロダクトとして何が正しいのか」の基準（あくまで見立て。
常に見直される。）にもとづいて越境

仮説検証とは分からないものを減らし、分かったことを増やしていく活動、
チームとしての何が正しいかの見立てを共通理解とする活動
- 正しくないことの学びを重ね、除外していくことで正しい（と思われる）もの
の範囲を狭めていくアプローチ
- 目的、実態、手段の順に段階的に絞っていく
- ユーザーに体験してもらわないとこれ以上の検証はできない、この検証のために
ソフトウェアを作る必要がある、という判断に達し多段階で初めてMVPの開発に
着手する
- MVP開発までの価値探索はモデル化（分かってることの図式化・言語化）と
検証の繰り返し

# 所感
アジャイル開発の理論は理解し、いざ実践してみるとぷつかる壁がいくつもある、そんな上手くいくもんじゃない。経験ある人ならほんとそれ、と思うことが冒頭イントロダクションの著者の経験、またそれ以降でも語られていた。そんな経験からくる「正しいものを正しく作れているか？」という問いかけは実践者にとても刺さる。

作る前の価値探索は間違ったものを作らないためにもとても大事。作ることはコストがかかる、作る前に検証できることはしてチーム共通理解の基準を持ってMVPを作る。

ただ、やっぱり絶対の正しさがないものを探索することは簡単ではないと思った。何を信じて分かった/分からないとするのか、何を検証していくのかはその時その時の判断をチームでしていくしかないんだろうなぁ。ただ、分からないことを分かったつもりになって進むのはやめよう。問い続けよう。

チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで

チームの事を考え始める役割になったタイミングで読ませて頂いたため、とても参考にさせて頂きました。

日々チームに起こる様々な問題。
グループからチームになるまで、発生した（発生しうる）問題を解決まで、解説付きで読む事ができます。
チームのスケール時に起こるストーリーもあるため、1チームの問題だけでなく、複数チームに跨った問題まで読む事ができます。
ストーリー形式なので、イメージしやすく読む事ができました。

実際に、チームメンバーの状態や、プロダクトでやり切らなくてはならない問題にぶち当たったタイミングで、参考にさせて頂きました。
プロダクトファーストという作戦で、スクラムを崩し、雁行陣開発に移し、WFに近い形でやり切る事ができました。
この経験があるから、チーム力も上がったと思います。

「カイゼン・ジャーニー」「正しいものを正しく作る」「チーム・ジャーニー」
プロダクトを作る上での三種の神器だと思います。
そのため、教科書のように参考にさせていただける本にさせていただいています。

チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで

チームが成長し機能する過程をストーリーに落とし込み、手に取った読者が自分のハンドルを自分で握る覚悟を後押しする。チームジャーニーは、そんな本だ。

1つのチームが「グループ」から「チーム」へと成長していく第一部、複数のチームが境界を「越境」しながら本当に必要なプロダクトを探求するジャーニーに赴く第二部の二部構成。

名著「カイゼンジャーニー」と同じく、ストーリーの中でチームを成長させていくためのプラクティスが紹介されるため、現場のどのような状況で適用できるのかがイメージしやすい。

そしてプラクティス以上に、「少しずつ変化する」「1つの正解はない、常に問を投げ続ける」というメッセージが重要であると感じた。

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

著者の経験に基づいてプロダクト開発が上手くいかない理由を整理している感じです。
決して書いてある通りにやれば成功する、という話ではありません。
自分の言葉で論理を積み上げられており、筋が通ってる印象でした。

第3章で解説されている余白の話はなるほどそういう捉え方ができるんだ、と感心しました。

How に向きがちな意識を What や Why に向けること、そのためのスキルを身につけることが必要になってきているのだと納得しました。

ソフトウェア開発の方法論は海外からの輸入が多い中、日本語で思考し、綴られた優れた内容だと思います。

リーン開発の現場 カンバンによる大規模プロジェクトの運営

ページ数は少なめでさらっと読めるけど、中身はかなり重厚でとても参考になった。
大規模プロジェクトでの実践的なカンバン運用について書かれている。１章ごとに役に立つ内容も多いので、目次を見て気になる章を見てみるのも良いかも。

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

正しいものを正しくつくることへの挑戦は未来永劫続く。

そして、「正しくつくれる」一部の「できる」エンジニア、マネージャーが暗黙的に持っている知見を見事に言語化した良書である。

スクラム開発についても言及しているが、あくまで本書を完結させるために記載したものである。スクラム開発を深く理解するためには、一度同著者が書いた「カイゼンジャーニー」を一読することをお勧めする。（カイゼンジャーニーを読んだ後、本書を読むと良いかもしれない）

私見だが、「できる」エンジニア、マネージャーに最も必要な要素は視座と視野だと考えている。それを上上下下左右左右過去未来とはよくもまあ良い表現を思いついたものだと感心した。

とはいえ、視座と視野を広げる「教育」が必要だと思うが、いっそメンバーを巻き込んだコンサル的な教育も取り入れられれば良いのかな、と考えている。

個人的には近年SoRの案件が多いため、不確実性に挑戦することは少ないが、SoEの案件に携わる際には参考にしていきたい。

しかし、カイゼンジャーニー含め、なにかの節目で必ず開く本になりそうだ。