新井剛のレビュー一覧

ここはウォーターフォール市、アジャイル町 ストーリーで学ぶアジャイルな組織のつくり方

大事なのは何のプロセスを選択するか、いかに遵守するかではない。いかに目的地を定め、そこに共に向かうか
だ。そういった本質が詰まった小説形式の一冊。

タイトルにはガッツリ「ウォーターフォール」、「アジャイル」とあるが、本文中では意外なほどその言葉が出てこない。職場をニューノーマルにトランスフォームさせていくには？というのが主題のようにも思える。
芯の部分にはアジャイルソフトウェア開発宣言が確かに息づいているが、変化球といえば変化球。タイムボックスが出てこない(少なくとも前には)というのは、アジャイル本として捉えると異例ではある。

しかし、この現場で発生するであろう(していたであろう)リアルな課題を解決していくことにフォーカスしたストーリーを、私は全面的に支持する。ひとつのBe Agileの形がここにはある。

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

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

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

カイゼン・ジャーニー たった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回以上あれば，断続的インテグレーション導入

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

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

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

システム開発における様々な問題を、主人公が成長しながら解決していく物語。
他の一般的な書籍と違い、物語として読むことができるため、自分の境遇と比較しながら読みすすめることができます。ポイントを逐一紹介しているため、説明はとても分かりやすいです。特に一番最後のあとがきで全てをまとめているのはとてもありがたかった。

主題は物語ではなく、様々な問題をどうやって解決するかを学ぶことなので、物語の全てが
・問題発生
・解説
・解決策を遂行
・うまくいった
という流れで進みます。1〜2章は解決策を他人が提示するので、まるでドラえもんみたいだと感じましたが、学びを得るのが主題なのでやむを得ないかなと思います。

主人公が最初に絶望していた割に、本人も周囲も都合が良すぎると感じることもあるにはありますが、そもそも物語の形をとって解説をしている本なので、出来事にリアリティがないことを責めるのもちょっと違うかなと思います。(リアリティ重視で分かりにくいと本末転倒ですし)

1つだけ不満を言うならば、発生する問題がほぼ全て解決手段の提示ありきで、特にスクラム開発における解決手法を次々と利用していく流れなのですが、手段はともかくなぜその解決策なのか、この問題の本質はどこなのかといった、手段を講じる前の段階を深く掘り下げてほしかったと思います。

とはいえ、全体的にはわかりやすくまとめられており、読後感も良いのでおすすめです。

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

新規事業のシステム開発は要求や仕様が明確でない場合がほとんど。
何を作るか、何故作るかを常に考えるが、
それが正解かどうかは分からない。
分からない中でも前に進んでいくために
アジャイルの考え方は必要だと思う。
ただ、チーム全員がその考えを持っていることは少なく考えを浸透させるのは難しい。

この本ではフィクションとしながらも
事実をベースにしているため
現場の緊迫感が伝わってきて良かった。
自分が一歩前に進むきっかけになりそう。

アジャイルや、事業開発で使うツールや
その使い方が分かりやすく説明されており
解説書としても使えそう。

一人でできること、
チームで出来ること、
チーム外部と出来ること、を
ストーリーと解説を交えて
記載されているのも読みやすい。


それで、あなたは何をしている人なんですか？

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

版元の翔泳社の方からいただきました。

本書は、プロジェクトを前に進めるために、さまざまなプラクティスがストーリーの中で紹介されています。

・KPT
・カンバン
・インセプションデッキ
・狩野モデル
・合宿
・期待マネジメント
・ユーザーストーリーマッピング
etc

世のプロジェクト、プロダクトマネージャーで悩みがある人には是非手に取ってもらいたい本です。
自分のもつプロジェクトでの悩みの解決の一歩がかかれてるかもしれません。
私は書かれてました。

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

開発現場の問題を物語を通して、いろいろな解決手法を用いて、解決していくお話し。

開発現場でよくあるは問題が取り上げられているため、とても実用的な書籍でした。

ここはウォーターフォール市、アジャイル町 ストーリーで学ぶアジャイルな組織のつくり方

アジャイルのやり方をストーリー形式で話す本
ストーリーの出来がよく、章ごとの振り返りがイメージしやすくなり取っ掛かりとして良い

アジャイル：個人と対話、動くソフトウェア、顧客と協調、変化への対応
チケット管理、優先順位、履歴、見える化
タスク管理ツール、重複させない、ガイドラインと検索性
チーム：得意なこと、貢献すること、大切に思う価値、期待

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

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

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

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

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

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

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

## 面白かったところ

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

## 微妙だったところ

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

## 感想

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

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

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

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

ここはウォーターフォール市、アジャイル町 ストーリーで学ぶアジャイルな組織のつくり方

少し専門的だったけど、
このカタカナに興味がある人や、
勉強しないとなと考えている人には、
ちょうど良いレベルの本だと思う。
「相手のキーワードに飛び込む」
いい言葉を頂きました、

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

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

ここはウォーターフォール市、アジャイル町 ストーリーで学ぶアジャイルな組織のつくり方

最近、「アジャイル開発」という言葉に会社で振り回されているので、敵を知るために（？）色々読み漁っている。。。

アジャイルな仕事のやり方を取り入れていくことで、仕事がうまくまわるようになった話。
今の仕事のやり方の中に、少しずつでも取り入れていけば、よい流れを作れるかも？という希望は湧いた。

一番大事で、できていないことは
「ふりかえり」
どうにかうまくできるようにならないかな。
①データを収集する
　その期間に起こったこと。うれしかった、楽しかったことでもOK（Keep/Problem)
②アイディアを出す（Try)
③何をすべきかを決定する
場合によって他のフレームワークを使ってみるのもあり。
毎日のふりかえりはKPT
月に一度の戦略の練り直しはYWT
研修や道のことを実施した際にはFun!Done!Learn！

まずは自分ができるようにならないといけないので、
毎日…は’無理でも、週１で［振り返り］をしてみようと思う。
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

ここはウォーターフォール市、アジャイル町 ストーリーで学ぶアジャイルな組織のつくり方

ウォーターフォールが主流の環境で、アジャイルの良いところを取りながら組織改革をしていくストーリー仕立ての内容のためとても読みやすい内容でした。
アジャイル初心者向け。

ここはウォーターフォール市、アジャイル町 ストーリーで学ぶアジャイルな組織のつくり方

タイトルから想像される内容とは一致しないけど、読み終えると言いたいことは伝ってくるタイトルです。

ウォーターフォールの中でアジャイルを実現する前提であるが背景がウォーターフォールであるかどうかはわからないが、現場でアジャイルを体現する具体的なストーリーを見せてくれる。実際にやろうと思うと、そんなにうまく行くかどうかはチームメンバー次第かもしれない。

個人的には、アジャイルというものをある程度わかってきた人たちが改めてアジャイルとはなんなのかを再認識するのに有用な書籍かなと感じた。そういった点ではアジャイルになりたい人の理想が詰まった楽しいストーリーだった。

あなたやあなたのチームにとってのアジャイルが見つかる助けになるかもしれない一冊。

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

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

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

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

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

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

目次は以下の通りです。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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