新井剛のレビュー一覧
-
Posted by ブクログ
伸びしろの若手エンジニアをアジャイル開発に参画させると、旧来のウォータフォール開発に比較して、何倍も大きく成長するように思えます。
「巨人の肩に乗る」とは、若手の方が、プロジェクトのエキスパートにささえられながら、全体を見渡して成長していくという意味なのでしょうか。
大規模な基幹システムの更改については、アジャイル開発はどうも向いていないように思えますが、スクラムマスターが何人もいるような、しかも請負で開発しているプロジェクトが出現し
急速に成長している分野と認識しています。本書は、アジャイル開発の基礎を解説したものですが、用語を含めてとっつきにくい内容だと思います。ブレークダウンをして具体的な作業や、ツールなどを解説していただいたら、もっと充実した内容になるとおもいました。
気になった点は以下の通りです。
・リリース時点で開発から手離れすることはまれになりました。ユーザーの反応をプロダクトに反映しながら改善し、ビジネス価値を向上させ続ける必要がでてきたのです。
・ソフトウエアの利用を通じて達成したいことを「要求」といいます。この「要求」を実現するために必要な機能や性能が定義されたものが「要件」です。
・ソフトウエアの３分の２の機能はつかわれていません。
・ウォーターフォールは、よくも悪くも、不確実性を減らすモデルです。
・想定だけで一度に多くのことを実現しようとしても、的を得たものにならない。だから、少しづつ繰り返し的に作り進めていく。
・統合：インテグレーションとは、ソフトウエアを動作させるために必要なプログラムや、設定ファイル、データ、ライブラリを全て集めて、まとめる作業のことをいいます
・常にリリース可能な状態に整備シテオクプラクティスがあります。それが「継続的インテグレーション」です。テストやビルド、配置のタスクを流れるように自動化しておく仕組みです。
・ソフトウエア開発に価値探求のためのタスク「仮説検証」を織り込む考えがあります。
・アジャイル開発は２つの見積で構成されます。１つは、全体感の見積、もう１つは、実際に開発するにあたってたいむボックスごとに行う見積もりです。
・アジャイル開発における計画づくりとは、大きな計画づくり、小さな計画づくり、その日に計画づくりの３種をさします。それぞれ、リリースプラニング、スプリントプラニング、デイリースクラムといいます。
・アジャイル開発では一度に広範の要件定義ではなく、その時点で必要な範囲と深さでの「作るべきものはなにか」を定義します。その時点は２種類あります。リリースプラニングの段階で全体を知るための整理。スプリント段階で、スプリント分を知るための整理の２種類です。
・段階ごとの青写真を描いて、見えるようにしておくことは思いのほか重要です。
・これまでアジャイル開発が失敗してきた理由は３つあります。①受託開発や、ＳＩでの同意形成が難しい ②他の現場プラクティスをそのまま適用してしまっている ③経験者不足、経験者の偏り。です。
結論は、「アジャイル開発」はいつだれが始めるのか。その答えはもう出ています。アジャイル開発の積み重ねに次の越境を重ねるのは、この本を閉じたときから、あなたが始めるのです。
目次は以下の通りです。
Chapter１ アジャイル開発の世界
０１ 本書の読み方：アジャイル開発を始める
０２ ソフトウエアを取り巻く環境①：進化するＩＴ市場
０３ ソフトウエアを取り巻く環境②：ビジネスモデルの変化
０４ さまざまなソフトウエアの形：見えるソフトウエア、見えないソフトウエア
０５ ＳｏＲ，ＳｏＥ，ＳｏＩ：ユーザーとソフトウエアの関わり
０６ アジャイル開発の基本：アジャイル開発とは何か
０７ アジャイル開発の原点：アジャイル開発の源流「カイゼン」
０８ アジャイル開発の成功率：アジャイル開発の広がり
Chapter２ なぜアジャイル開発なのか
０９ ウォーターフォール開発：従来型の開発手法「ウォーターフォール」
１０ 作ったけれど使われない：顧客が本当に欲しかったもの
１１ 不確実性コーン：ソフトウエア開発は不確かなもの
１２ ムダ：ソフトウエア開発のぜい肉
１３ ウォーターフォールの課題：手戻りできないウォーターフォール
１４ アジャイル開発の原則：アジャイルは不確かさと踊る
１５ アジャイルソフトウエア開発宣言：なぜアジャイル開発なのかを考える
Chapter３ アジャイル開発がもたらす変化
１６ アジャイル開発がもたらす変化：チームの成長とプロセスの進化
１７ アジャイルソフトウエア開発宣言の実践①：個人と対話
１８ アジャイルソフトウエア開発宣言の実践②：動くソフトウエア
１９ アジャイルソフトウエア開発宣言の実践③：顧客との協調
２０ アジャイルソフトウエア開発宣言の実践④：変化への対応
２１ タックマンモデル：職能横断型モデル
２２ チームの機能期：自己組織化チームとリーダーシップ
２３ 成長戦略：アジャイルチームの成長戦略
２４ ＹＡＧＮＩとＫＩＳＳ：筋肉質なソフトウエア
２５ トレードオフの神話：質とスピードは両立する
Chapter４ アジャイル開発の中核にあるコンセプト
２６ コアコンセプト：アジャイル開発の３つのコアコンセプト
２７ チーム①：チームのフォーメーションを定める
２８ チーム②：チームの共通理解を育む
２９ チーム③：チームの活動する場を用意する
３０ インクリメンタル①：少しづつ形づくる
３１ インクリメンタル②：構想とプロダクトを合わせる
３２ イテレーティヴ①：反復的に作る
３３ イテレーティヴ②：反復的な計画作り
３４ イテレーティヴ③：反復的な作成物レビュー
Chapter５ 小さく始めるアジャイル開発
３５ 方法論、プラクティス：アジャイルのはじめの一歩
３６ スプリントバックログ、プロダクトバックログ：タスクの見える化
３７ タスクボードの作り方：状況の見える化
３８ プラニングポーカー：タスクのサイズをチームで見積もる
３９ 朝会：日常の見える化
４０ ペアプログラミング、ペアワーク：ペアで作る
４１ ふりかえり：やったことの見える化
４２ 習慣化：プラクティスの習慣化
Chapter６ 上手にのりこなすためのカイゼン手法
４３ 方法論：より上手にレベルアップする
４４ 継続的インテグレーション、バージョン管理：流れるように自動化するには
４５ テスト駆動開発：エンジニアリングでテストのムダを解消する
４６ チーム①朝会とふりかえりのステップアップ：チームの活動が形骸化し始めたら？
４７ チーム②見える化のステップアップ：散乱した見える化を棚卸しする
４８ チーム③カンバン、モブプログラミング：成果の停滞感に直面したら
４９ 契約：契約ってどうするの？
５０ パターン：プラクティスを自ら実践し自ら作る
５１ 組織にスケール：日本の既存の組織に合わせて拡大させる
Chapter７ アジャイル開発の理解を深める
５２ アジャイル開発の誤解：なぜ、アジャイル開発は誤解を生みやすいのか
５３ 仮説検証：アジャイル開発は早く安くできる？
５４ 見積もり：アジャイル開発は見積もりしない？
５５ リリースプライニング、スプリントプラニング、デイリースクラム：アジャイル開発は計画しない
５６ ドキュメント：アジャイル開発はドキュメントを書かない？
５７ 要件定義：アジャイル開発は要件定義しないの？
５８ 不確実性：アジャイル開発は設計しない？
５９ テスト戦略：アジャイル開発はテストしない？
６０ アジャイル開発の進め方：アジャイル開発は本当にできるのか？
Chapter８ アジャイル開発はあなたから始まる
６１ 失敗の歴史：素直な声に耳を傾けよう
６２ ハンガーフライト：アジャイル開発の学びを深める、広げる
６３ 越境：アジャイル開発を始めよう -
-
-
-
Posted by ブクログ
「アジャイル開発」という枠組みだけに留めておくことが勿体無いくらい、開発以外にも適用できる、本質的な考え方についてわかりやすく記載されている本だと思います。個人的には、HowよりもWhyやWhatにおける考え方に大いに共感させていただきました。読み終わった印象として、「顧客のインサイトを捉えて、小さく・早く・継続的にチームでアウトプットを出す。」に尽きるのかなと感じます。
顧客のインサイトを捉えるための方法論として、顧客との協働もありますし、インセプションデッキもあります。前提として、顧客は自身のインサイトを知らないので、そのインサイトを顧客自身に理解してもらうためにも、動くソフトウェアが大切。目的と方法論を整理できれば、アジャイルに物事を進める考え方って、本当に実体験からも論理性からも納得がいくもになります。
小さく・早く・継続的に物事を進めるための方法論として、「見える化」は必要ですし、チームの自己組織化も必要です。継続するためには、効率化も必要なので、様々なプロセスの自動化も必要になり、結果としてCIなども方法論として必要にもなります。これらのことを実践するためには、誰でもできるわけではないので、必然的にプロダクトオーナーやスクラムマスターというタグのついた役割の人も必要になってきます。このあたりの方法論が目的になって「アジャイル開発」が世の中に浸透？したことで、生まれた誤解についてもこの本では触れています。（設計不要？テスト不要？ドキュメント不要？要件定義不要？など。そんな訳ないですよね）
チームで出すアウトプットは、ソフトウェア開発においてはプロダクトになります。ただ、それだけではなく、チームの成長時代も大事なアウトプット。そのためには、改善が必要で、そのための方法論（KPTなど）についても触れられています。ここも、目的と方法論を履き違えなければ、本当に納得いく内容だと思います。
アジャイルは開発プロセスではないです。物事を進める上での本質的な側面を抽出した考え方だと思っています。この考え方は、ソフトウェア開発以外にも大いに役立つと思います。例えば、Whyから始めよなんかはサイモンシネックが言っていることでもありますし、マーケティング理論の基本としてWhyーWhatーHowがあり、この考えはアジャイルの考え方そのものです。方法論自体を軽視するつもりはありませんが、アジャイルの本質を理解して、その上で、自分の組織やチームにどう適用するかを考えていくことが本当に大切だと感じました。 -
-
-
Posted by ブクログ
開発ではなく運用チームからの視点で他部署を巻き込みながらカイゼンしていくストーリー
開発手法はウォーターフォールのままでアジャイルで良く使われるプラクティスやツールを用いて徐々に組織のエンゲージメントが高まっていく
読み物としても面白くて、ここ数年自分がやって来たことと重ねながらしみじみ読んだ。
自分達は通り過ぎてしまって当たり前に思える内容も多かったが、自分が取り組んでいた時期に読みたかった（周りにも読ませたかった）
説得より納得させる、0-1ではなく部分的に取り入れても良いというところに共感した。
業種や社風でカイゼンを諦めてしまった人にオススメ -
-
-
Posted by ブクログ
なぜか二項対立で語られがちなウォーターフォールとアジャイルを良いとこ取り的に組み合わせて導入することを提案する一冊。問題地図シリーズ著者とカイゼン・ジャーニー著者（越境というキーワードは今回も登場）の共著と聞けばミーハー心に「すげー！」となってしまうわけだが期待に違わぬ良書。小説パート→解説パートを刻んで繰り返す構成が読みやすい。個人的には振り返り手法のKPTに若干の煮詰まりを感じていたのでYWTやFun! Done! Learn!が印象に残った。強いて言えばコロナ禍で急速に普及しつつあるリモートワークを前提とした話も（全く触れられてないわけではないが）知りたかった。
-
-
Posted by ブクログ
アジャイルサムライを読んだ後に読むと良さそうな本。
実際の開発現場で起こりそうなエピソードとともに、課題解決に使えそうなプラクティスがうまく紹介されている。立場を超えて問題と向き合う、自分から相手の立場に越境して一緒に難関を乗り越える、それがカイゼンジャーニーというタイトルの意図するところらしい。
開発者から見ると、発注側のリテラシーを責めたくなることも多いけど、発注側は発注側の事情で、予算やリスクと向き合う必要がある。現実には簡単には乗り越えられない問題ばかりかもしれないけれど、いろいろな人の経験から勇気をもらいながら乗り越えていきたい。
ちょっとライトノベル的なノリが苦手な人もいるかもしれないけれど、それゆえの読みやすさもあるし、もしドラよりも共感できる。もっと流行ってほしいなｗ。 -
-
Posted by ブクログ
完全にリモートワークでのスタイルとなった今、これを良い機会としてコンサルティングという仕事の進め方を見直したいという問題意識の元、プロジェクトスタイルという仕事の進め方が似ているITシステム・サービス開発から学ぶべきは多いのでは、という仮説から手に取ったのが本書。
ストーリー仕立てでアジャイル開発、特にスクラムの方法論を学ぶことができる。こうした具体的な方法論にちゃんと触れるのは実は初めてであり、具体的かつ様々な失敗も踏まえて改良された方法論のシャープさが非常に面白い。
例えば、コンサルティングという仕事では、クライアントに納品するアウトプットを当然、一定の大きさのモジュールに切り分けて各コンサルタントが分担することが一般的である。その際、分析の手法やスライドライティングのノウハウは、一定のお作法・ルールが決められている。とはいえ、細部になれば個々人の経験による独自のTipsなどがあるわけで、そうしたものの標準化にスクラムの開発Tipsである”モブプログラミング”(複数人で一つの画面を見ながら、ワイガヤ的にプログラミングする手法)を援用するとどうなるだろうか。
このような観点で、自身の仕事の進め方を改善する様々なヒントを得られた気がしており、さらにこの分野を突っ込んでいこうと思った次第。 -
-
Posted by ブクログ
ソフトウェア開発の仕事は大変だ。
毎日夜は遅いし、いつも炎上する。
それをなんとかしたいと思い、たった1人で行動を起こしてみた。しかし周りは誰も協力してくれない。そして挫折。やはり自分1人で開発現場をなんとかするなんて無理なのか？
あなたにも、そんな経験があるだろう。
この本は「ＩＴエンジニアに読んで欲しい！技術書・ビジネス書大賞２０１９」の技術書部門ベスト１０を受賞した人気の本だ。
著者は、ソフトウェア開発のコミュニティ「DevLove」を立ち上げた市谷聡啓氏と運営スタッフでもある新井剛氏。業界では有名なコミュニティだ。システム開発をしている多くのエンジニアが熱心に学んでいる。以前、私も参加して講演を拝聴させていただいたことがある。
・プロローグ
・第1部 一人から始める
第1話 会社を出ていく前にやっておくべきこと
第2話 自分から始める
第3話 一人で始めるふりかえり
第4話 一人で始めるタスクの見える化
第5話 明日を味方につける
第6話 境目を行き来する
第7話 二人ならもっと変えられる
第8話 二人から越境する
・第2部 チームで強くなる
第9話 一人からチームへ
第10話 完成の基準をチームで合わせる
第11話 チームの向かうべき先を見据える
第12話 僕たちの仕事の流儀
第13話 お互いの期待を明らかにする
第14話 問題はありませんという問題
第15話 チームとプロダクトオーナーの境界
第16話 チームとリーダーの境界
第17話 チームと新しいメンバーの境界
第18話 チームのやり方を変える
第19話 チームの解散
・第3部 みんなを巻き込む
第20話 新しいリーダーと、期待マネジメント
第21話 外からきたメンバーと、計画づくり
第22話 外部チームと、やり方をむきなおる
第23話 デザイナーと、共通の目標に向かう
第24話 視座を変えて、突破するための見方を得る
第25話 広さと深さで、プロダクトを見立てる
第26話 チームで共に越える
第27話 越境する開発
・エピローグ
本書は、ソフトウェア開発の現場で起きた様々な改善の様子を、ストーリーと解説という形でわかりやすく紹介している。物語形式なのでとても読みやすく、著者の実体験をベースにしているところが特徴だ。
物語は入社三年目のソフトウェアエンジニアのぼやきから始まる。
『現場のレベル感はひどく低い。いつもプロジェクトは炎上していて、目論見通りに終わることはまずない。メンバーの士気は低くて、プロジェクトの最初からたいていやる気がない。そんな感じだから仕事はうまくいかず、約束されていたかのように燃え盛り、それがまたメンバーの気持ちを挫いていく。ひどい循環だ。』
あなたの現場も、こんな感じではないだろうか。
そんな悩みを抱える主人公が、社外の勉強会に参加する。そしてそこで不思議なセッションに出会い、心を奪われてしまった。
「これは一体何の話なんだ？」
懇親会の席で、そのセッションの発表者に声をかけてみた。すると、逆に質問をされた。その「質問」が、彼の人生を変えることになる。
そして主人公の改善ストーリーは、自分1人でできることから始まり、チームでの取り組みに広がり、他チームを巻き込んだ組織の取り組みへと繋がっていく。
まるで、一本のローソクに灯った炎が、他のローソクに移って、どんどん明るくなっていくようだ。まさに「改善の旅」。KAIZEN JOURNEYだ。
私も、現場で新しいことを始めたり、有志を募って勉強会を開いたり、ささやかではあるが改善の旅を続けているが、本書に書かれていることは、現場で迷ったときに、とても参考になると感じている。やろうと思えば、明日からでも始められるノウハウばかりだ。
しかし実際に、書いてある通りにやろうとすると、なかなか大変なことは事実。「勇気」が必要だからだ。
現場の改善に「正解」は無いだろう。だから迷うし、こんな出すぎたこと自分がやってもいいのだろうか、と悩む。何かを始める勇気、最初の一歩を踏み出す勇気が、なかなか湧いてこないのだ。
著者は言う。
『「今の自分の延長線上に何があるのか」を想像したときに、特に変わりようがないと気づいたとき、行動を起こすことに踏み切れました。』
あなた自身のこれからを大切に思うなら、行動を起こすしかないのだ。
行動を起こすといっても、何もいきなり会社を辞めろと言っているわけではない。ゴミが落ちていたら拾うというレベルでも良い、と私は思う。大事なことは、あなたが良いと思ったことを、勇気を出してやってみることだ。そうしないと何も始まらない。
もしあなたが、現状を変えよう改善を始めてみたが、上手くいかなくて心が折れそうになったなら、ぜひこの本を読み返してみて欲しい。本書の登場人物たちが、あなたの、たったひとりの挑戦を後押しし、力強く応援してくれるだろう。 -
Posted by ブクログ
リーンでアジャイルなソフトウェア開発の考え方とプラクティスを、日本的な現場のストーリーから学ぶことができる。
ホワイトカラーの現場で起こる諸問題を、スクラムとXPのプラクティスで解決していく。極めてプラクティスが多く出てくるため、一読しただけではどのプラクティスがどの課題に対応するのか整理できない。曼荼羅のごとく、対応付けして整理する。
ーフレーズメモー
・仕事をよりうまくやるために何から始めるか？タスクマネジメント、タスクボード、朝会、ふりかえりの4つがある。仕事のカイゼンはまず状態の見える化から始めるべし。
・ふりかえりの基本。プロセスのカイゼンと不確実性の高い状況で前進することを目的とする。ふりかえりのやり方には、問題発見フェーズ、事実発見フェーズ、対策フェーズがあり、できるだけ可視化する。
・ふりかえりは他人に気づかせてもらう。だからこそチームでやる。
・むきなおり。1.ミッション、ビジョンを点検する。2.評価軸を洗い出し、現状を客観的に見定める。3.評価軸ベースであるべき姿と現状の課題を洗い出す。4.課題解決のために必要なステップをバックログにする。5.バックログの重要度と、一番効果の高いものを決める。6.時間軸を明らかにし、期限も明確に決める。
・バリューストリームマッピング。プロダクトの価値がお客さんの手に渡るまでの仕事の流れを見える化するプラクティス。流れのどこで付加価値が生まれるのか、プロダクトが滞りなく実現に向けて動いていけるのかを確認する。 -
-