市谷聡啓のレビュー一覧

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

技術書を読むのが得意ではないのだけど、物語仕立てで読みやすかった。

主人公がエンジニアで日本が舞台なので、
あるあるとか、さすがにそうはうまくいかんやろとか、
自分と重ねることができるし、
今後いろいろな場面で江島なんかやってたなーみたいなヒントになりそう。

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

問題が頻発。
実際の開発もそうだから…
進行のために色々なやり方を採れるのが羨ましい。
人にお願いできない…
スクラムの延長のリーンジャーニースタイルの提案。
買いかもしれん、何度も読むのが良さそう

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

過去読んでアジャイル開発に関して基本を学べた本。
いちばんやさしいとある通り、初心者向けで読みやすかった記憶がある。
他にも本を出版されている小田中さんが書いている。

アジャイルなプロダクトづくり 価値探索型のプロダクト開発のはじめかた

ストーリーは「こんな会社嫌だな…」と思ってちょっと読みにくかったのだけど、解説は素晴らしかった。既存事業も新規事業にも活かせるはず

これまでの仕事 これからの仕事 ～たった1人から現実を変えていくアジャイルという方法

最近組織改革、プロセス改革、アジャイル化みたいなことをやっているので、特に後半の内容は刺さった。

組織改革は簡単ではない。組織を超えた「協働」は難しい。
そのためにはFromとToを踏まえて、その間にあるギャップを掴みにいくことが必要。
Toに行くために乗り越えなければならない課題、障壁、リスクに向き合う。
アジャイルに取り組むことでこれまで通りの成果が出せなくなるのであれば、「ふりかえり」で課題を発見し、打ち手を講じる。
「むきなおり」で互いに目標をとらえながら、今やることを合わせていく。

いちばんに変えなければならないのは意識だ、と改めて認識。
意識を変えること、チームとして同じ方向を見ること。

言われた方法論をただ取り入れればよい、というものではなく、新しい働き方をみんなでつくる、という意識合わせが大事。

「関心、チーム、リスペクト、越境でダークサイドを変えていこう」

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

アジャイルの実践が必要になり、メソッドとしての知識ではなく原則を知りたくて読みました。仮説検証型アジャイル開発というプロセスを提唱していますが、それが標準的なアジャイルと何が違うのかは(知識不足で)わかりませんでした。陥りそうなアンチパターンなどがわこりやすく、現在進行形で参考にしたい考え方ばかりでした。間違ったものを正しく作ることを避けること、そのために視座を意識的に行き来することが必要と感じました。

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

# SIerのとしての、自分の世界を変えていく、一人の旅人の物語

## 面白かったところ

* アジャイル開発は決まった型はない事が、ストーリーベースだからわかる
* アジャイル開発すらも、プロジェクトに合うのか検討している
* 突然チームで始めるのではなく、個人単位で始めている

## 微妙だったところ

* 主人公が「何をするひと」なのかは読み進めればわかったのだが、一言では名言されていない点がもやもやした

## 感想

「なんちゃってアジャイル症候群」なんて病気もあるくらい、実際にアジャイル開発を手を動かしてみないとどんなものなのかはわからない。

自身も自分で始めたわけではないし、わからないことが多いからこそ、この本を拠り所にしている。

この本に答えが書いてある時もあればそうでないときもある。

だが何かしらの答えやきっかけを与えてくれるこの本は、とても重宝している。

これまでの仕事 これからの仕事 ～たった1人から現実を変えていくアジャイルという方法

会社のルールで沿って仕事してると(その組織の中では)間違いがない。けど、ルールにない事に遭遇すると思考停止してどうしたら良いか分からなくなる事がよくある。
この本は、そう言った問題の解決策をわかりやすくまとめられていると思います。

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

エンジニア、プログラマーなど開発視点の構成。
フレームワークの使い方などビジネス、コンサル系にも応用がきく内容あり。
良い本でした。

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

物語形式で現場の状況がとてもよく把握できる。そして、本当にありそうな展開です。それゆえに読んでいて、自分がその場にいるような感じがして苦しかった。やってもやってもなかなか状況は改善しない、各部の最後でようやく事態は好転するけれど、身が引き締まるような読書体験でした。巻末の参考文献は1/3くらい読んだことがあるけれど、未読の本は読んでみたい。

デジタルトランスフォーメーション・ジャーニー 組織のデジタル化から、分断を乗り越えて組織変革にたどりつくまで

よくあるデジタルで業務を変えましょうと言ったニュアンスの本ではなく、アジャイル開発のエッセンスを組織適用し改革を行うことを志向している本

現在の組織の多くが深化は行えているが、探索は行えていないのかについても言及されていた。組織の設計、オペレーションの設計で深化を促すために探索をしないように設計されていると言った記載ははっとさせられた

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

伸びしろの若手エンジニアをアジャイル開発に参画させると、旧来のウォータフォール開発に比較して、何倍も大きく成長するように思えます。
「巨人の肩に乗る」とは、若手の方が、プロジェクトのエキスパートにささえられながら、全体を見渡して成長していくという意味なのでしょうか。

大規模な基幹システムの更改については、アジャイル開発はどうも向いていないように思えますが、スクラムマスターが何人もいるような、しかも請負で開発しているプロジェクトが出現し
急速に成長している分野と認識しています。本書は、アジャイル開発の基礎を解説したものですが、用語を含めてとっつきにくい内容だと思います。ブレークダウンをして具体的な作業や、ツールなどを解説していただいたら、もっと充実した内容になるとおもいました。

気になった点は以下の通りです。

・リリース時点で開発から手離れすることはまれになりました。ユーザーの反応をプロダクトに反映しながら改善し、ビジネス価値を向上させ続ける必要がでてきたのです。
・ソフトウエアの利用を通じて達成したいことを「要求」といいます。この「要求」を実現するために必要な機能や性能が定義されたものが「要件」です。
・ソフトウエアの３分の２の機能はつかわれていません。
・ウォーターフォールは、よくも悪くも、不確実性を減らすモデルです。
・想定だけで一度に多くのことを実現しようとしても、的を得たものにならない。だから、少しづつ繰り返し的に作り進めていく。
・統合：インテグレーションとは、ソフトウエアを動作させるために必要なプログラムや、設定ファイル、データ、ライブラリを全て集めて、まとめる作業のことをいいます
・常にリリース可能な状態に整備シテオクプラクティスがあります。それが「継続的インテグレーション」です。テストやビルド、配置のタスクを流れるように自動化しておく仕組みです。
・ソフトウエア開発に価値探求のためのタスク「仮説検証」を織り込む考えがあります。
・アジャイル開発は２つの見積で構成されます。１つは、全体感の見積、もう１つは、実際に開発するにあたってたいむボックスごとに行う見積もりです。
・アジャイル開発における計画づくりとは、大きな計画づくり、小さな計画づくり、その日に計画づくりの３種をさします。それぞれ、リリースプラニング、スプリントプラニング、デイリースクラムといいます。
・アジャイル開発では一度に広範の要件定義ではなく、その時点で必要な範囲と深さでの「作るべきものはなにか」を定義します。その時点は２種類あります。リリースプラニングの段階で全体を知るための整理。スプリント段階で、スプリント分を知るための整理の２種類です。
・段階ごとの青写真を描いて、見えるようにしておくことは思いのほか重要です。
・これまでアジャイル開発が失敗してきた理由は３つあります。①受託開発や、ＳＩでの同意形成が難しい　②他の現場プラクティスをそのまま適用してしまっている　③経験者不足、経験者の偏り。です。

結論は、「アジャイル開発」はいつだれが始めるのか。その答えはもう出ています。アジャイル開発の積み重ねに次の越境を重ねるのは、この本を閉じたときから、あなたが始めるのです。

目次は以下の通りです。

Chapter１　アジャイル開発の世界

　　０１　本書の読み方：アジャイル開発を始める
　　０２　ソフトウエアを取り巻く環境①：進化するＩＴ市場
　　０３　ソフトウエアを取り巻く環境②：ビジネスモデルの変化
　　０４　さまざまなソフトウエアの形：見えるソフトウエア、見えないソフトウエア
　　０５　ＳｏＲ，ＳｏＥ，ＳｏＩ：ユーザーとソフトウエアの関わり
　　０６　アジャイル開発の基本：アジャイル開発とは何か
　　０７　アジャイル開発の原点：アジャイル開発の源流「カイゼン」
　　０８　アジャイル開発の成功率：アジャイル開発の広がり

Chapter２　なぜアジャイル開発なのか

　　０９　ウォーターフォール開発：従来型の開発手法「ウォーターフォール」
　　１０　作ったけれど使われない：顧客が本当に欲しかったもの
　　１１　不確実性コーン：ソフトウエア開発は不確かなもの
　　１２　ムダ：ソフトウエア開発のぜい肉
　　１３　ウォーターフォールの課題：手戻りできないウォーターフォール
　　１４　アジャイル開発の原則：アジャイルは不確かさと踊る
　　１５　アジャイルソフトウエア開発宣言：なぜアジャイル開発なのかを考える

Chapter３　アジャイル開発がもたらす変化

　　１６　アジャイル開発がもたらす変化：チームの成長とプロセスの進化
　　１７　アジャイルソフトウエア開発宣言の実践①：個人と対話
　　１８　アジャイルソフトウエア開発宣言の実践②：動くソフトウエア
　　１９　アジャイルソフトウエア開発宣言の実践③：顧客との協調
　　２０　アジャイルソフトウエア開発宣言の実践④：変化への対応
　　２１　タックマンモデル：職能横断型モデル
　　２２　チームの機能期：自己組織化チームとリーダーシップ
　　２３　成長戦略：アジャイルチームの成長戦略
　　２４　ＹＡＧＮＩとＫＩＳＳ：筋肉質なソフトウエア
　　２５　トレードオフの神話：質とスピードは両立する

Chapter４　アジャイル開発の中核にあるコンセプト

　　２６　コアコンセプト：アジャイル開発の３つのコアコンセプト
　　２７　チーム①：チームのフォーメーションを定める
　　２８　チーム②：チームの共通理解を育む
　　２９　チーム③：チームの活動する場を用意する
　　３０　インクリメンタル①：少しづつ形づくる
　　３１　インクリメンタル②：構想とプロダクトを合わせる
　　３２　イテレーティヴ①：反復的に作る
　　３３　イテレーティヴ②：反復的な計画作り
　　３４　イテレーティヴ③：反復的な作成物レビュー

Chapter５　小さく始めるアジャイル開発

　　３５　方法論、プラクティス：アジャイルのはじめの一歩
　　３６　スプリントバックログ、プロダクトバックログ：タスクの見える化
　　３７　タスクボードの作り方：状況の見える化
　　３８　プラニングポーカー：タスクのサイズをチームで見積もる
　　３９　朝会：日常の見える化
　　４０　ペアプログラミング、ペアワーク：ペアで作る
　　４１　ふりかえり：やったことの見える化
　　４２　習慣化：プラクティスの習慣化

Chapter６　上手にのりこなすためのカイゼン手法

　　４３　方法論：より上手にレベルアップする
　　４４　継続的インテグレーション、バージョン管理：流れるように自動化するには
　　４５　テスト駆動開発：エンジニアリングでテストのムダを解消する
　　４６　チーム①朝会とふりかえりのステップアップ：チームの活動が形骸化し始めたら？
　　４７　チーム②見える化のステップアップ：散乱した見える化を棚卸しする
　　４８　チーム③カンバン、モブプログラミング：成果の停滞感に直面したら
　　４９　契約：契約ってどうするの？
　　５０　パターン：プラクティスを自ら実践し自ら作る
　　５１　組織にスケール：日本の既存の組織に合わせて拡大させる

Chapter７　アジャイル開発の理解を深める

　　５２　アジャイル開発の誤解：なぜ、アジャイル開発は誤解を生みやすいのか
　　５３　仮説検証：アジャイル開発は早く安くできる？
　　５４　見積もり：アジャイル開発は見積もりしない？
　　５５　リリースプライニング、スプリントプラニング、デイリースクラム：アジャイル開発は計画しない
　　５６　ドキュメント：アジャイル開発はドキュメントを書かない？
　　５７　要件定義：アジャイル開発は要件定義しないの？
　　５８　不確実性：アジャイル開発は設計しない？
　　５９　テスト戦略：アジャイル開発はテストしない？
　　６０　アジャイル開発の進め方：アジャイル開発は本当にできるのか？

Chapter８　アジャイル開発はあなたから始まる

　　６１　失敗の歴史：素直な声に耳を傾けよう
　　６２　ハンガーフライト：アジャイル開発の学びを深める、広げる
　　６３　越境：アジャイル開発を始めよう

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

読み物になっているので読みやすい。ある程度アジャイルやXPの前提知識がある方が読みやすいと思うけど、逆にそのあたりへの取っ掛かりとして読むのもいいかもしれない。
とにかくお手軽なのが本書の素晴らしい点だと思う。

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

自分の抱えているシステム開発の悩みについて、さまざまなヒントが詰まっていた。システム開発の経典になりそうだ。

デジタルトランスフォーメーション・ジャーニー 組織のデジタル化から、分断を乗り越えて組織変革にたどりつくまで

DXや新規ビジネスを推進する事でよくある事象をうまくまとめられた本だと思います。
深化と探索の対立とか、組織の分断とか、絶賛体験中なので、この本を読んでいろいろ考えさせられたw

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

私の担当しているプロジェクトのアジャイル手法が手本のようにアンチパターンとして扱われてて、心が痛くなった(笑)
ウォータフォールからなんちゃってアジャイルで躓いているひとは読む価値があるとおもいます。
※アジャイルザムライ読んでる人はわかる内容かな、私は読んでるのに失敗しましたが。。

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

開発者、PMどちらも読むべき。とても勉強になったし、さっそく一部取り入れはじめた。今のプロダクトの開発前に出会いたかった1冊。

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

仮説を仮説のままに検証する仕組みを持つこと、
わかっていないことをわかっていないままに受け止めることの重要さを感じた

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

読み物的な側面が強いので万人にはオススメできないけど、正しいものを正しくつくるとはどういうことなのか、つまり正しくないものを作らないことが結果的にそれにつながる、ということが新たな発見として感じられたのでよかった。
正しいもの、正しくないものを見つけるために必要な活動をしていこう、と思った。

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

「アジャイル開発」という枠組みだけに留めておくことが勿体無いくらい、開発以外にも適用できる、本質的な考え方についてわかりやすく記載されている本だと思います。個人的には、HowよりもWhyやWhatにおける考え方に大いに共感させていただきました。読み終わった印象として、「顧客のインサイトを捉えて、小さく・早く・継続的にチームでアウトプットを出す。」に尽きるのかなと感じます。

顧客のインサイトを捉えるための方法論として、顧客との協働もありますし、インセプションデッキもあります。前提として、顧客は自身のインサイトを知らないので、そのインサイトを顧客自身に理解してもらうためにも、動くソフトウェアが大切。目的と方法論を整理できれば、アジャイルに物事を進める考え方って、本当に実体験からも論理性からも納得がいくもになります。

小さく・早く・継続的に物事を進めるための方法論として、「見える化」は必要ですし、チームの自己組織化も必要です。継続するためには、効率化も必要なので、様々なプロセスの自動化も必要になり、結果としてCIなども方法論として必要にもなります。これらのことを実践するためには、誰でもできるわけではないので、必然的にプロダクトオーナーやスクラムマスターというタグのついた役割の人も必要になってきます。このあたりの方法論が目的になって「アジャイル開発」が世の中に浸透？したことで、生まれた誤解についてもこの本では触れています。（設計不要？テスト不要？ドキュメント不要？要件定義不要？など。そんな訳ないですよね）

チームで出すアウトプットは、ソフトウェア開発においてはプロダクトになります。ただ、それだけではなく、チームの成長時代も大事なアウトプット。そのためには、改善が必要で、そのための方法論（KPTなど）についても触れられています。ここも、目的と方法論を履き違えなければ、本当に納得いく内容だと思います。

アジャイルは開発プロセスではないです。物事を進める上での本質的な側面を抽出した考え方だと思っています。この考え方は、ソフトウェア開発以外にも大いに役立つと思います。例えば、Whyから始めよなんかはサイモンシネックが言っていることでもありますし、マーケティング理論の基本としてWhyーWhatーHowがあり、この考えはアジャイルの考え方そのものです。方法論自体を軽視するつもりはありませんが、アジャイルの本質を理解して、その上で、自分の組織やチームにどう適用するかを考えていくことが本当に大切だと感じました。