市谷聡啓のレビュー一覧
-
-
-
-
Posted by ブクログ
アジャイルサムライを読んだ後に読むと良さそうな本。
実際の開発現場で起こりそうなエピソードとともに、課題解決に使えそうなプラクティスがうまく紹介されている。立場を超えて問題と向き合う、自分から相手の立場に越境して一緒に難関を乗り越える、それがカイゼンジャーニーというタイトルの意図するところらしい。
開発者から見ると、発注側のリテラシーを責めたくなることも多いけど、発注側は発注側の事情で、予算やリスクと向き合う必要がある。現実には簡単には乗り越えられない問題ばかりかもしれないけれど、いろいろな人の経験から勇気をもらいながら乗り越えていきたい。
ちょっとライトノベル的なノリが苦手な人もいるかもしれないけれど、それゆえの読みやすさもあるし、もしドラよりも共感できる。もっと流行ってほしいなｗ。 -
Posted by ブクログ
チームビルディングについては興味はなかったが、ソフトウェア開発のことについては学びたいと思っており、会社の先輩などにも勧められたため、読んでみました。
この本は現代のソフトウェア開発におけるチームビルディングのお話で、変化に対応するフレームワークを提唱しています。チーム内の問題をあげているので、自分の現場に紐づくところが何点かあったたり、いくつか参考になりました。
まず、チームの共通理解は常に頭にないと、齟齬が生まれると無駄な手戻りが発生する点です。この点は開発だけの問題はないため、自分の現場でも意識して取り組んでいきたいなと感じました。
そして、目標に向かう段階設計です。この本のメインとも言われるものです。よく会社で段階的に行動をしなさいみたいなことを言われてきてるけど、具体的な方法がわからず、中途半端になっていたので、この本を参考にしてやってみたいと思いました。
この本を一周だけですべて理解できていなかったので、何度も読んで参考していきたいと感じました。 -
-
-
-
Posted by ブクログ
完全にリモートワークでのスタイルとなった今、これを良い機会としてコンサルティングという仕事の進め方を見直したいという問題意識の元、プロジェクトスタイルという仕事の進め方が似ているITシステム・サービス開発から学ぶべきは多いのでは、という仮説から手に取ったのが本書。
ストーリー仕立てでアジャイル開発、特にスクラムの方法論を学ぶことができる。こうした具体的な方法論にちゃんと触れるのは実は初めてであり、具体的かつ様々な失敗も踏まえて改良された方法論のシャープさが非常に面白い。
例えば、コンサルティングという仕事では、クライアントに納品するアウトプットを当然、一定の大きさのモジュールに切り分けて各コンサルタントが分担することが一般的である。その際、分析の手法やスライドライティングのノウハウは、一定のお作法・ルールが決められている。とはいえ、細部になれば個々人の経験による独自のTipsなどがあるわけで、そうしたものの標準化にスクラムの開発Tipsである”モブプログラミング”(複数人で一つの画面を見ながら、ワイガヤ的にプログラミングする手法)を援用するとどうなるだろうか。
このような観点で、自身の仕事の進め方を改善する様々なヒントを得られた気がしており、さらにこの分野を突っ込んでいこうと思った次第。 -
-
-
Posted by ブクログ
正しいものを見つけ出す「価値探索」と正しくつくるための「アジャイル開発」について、著者の実践経験に基づく知見がまとめられた1冊。著者の市谷聡啓さんは『カイゼン・ジャーニー』の著者でもあり、日頃からリアルなプロダクトづくりを伝えてくださるので、とても興味を持っていました。また自分が普段、デザインスプリントという「価値探索」手法とアジャイル開発で仕事をしているので、より引き出すを増やせるのではないかと期待して読み始めました。
本書で特に参考になったのは、「スクラム開発でいうプロダクトバックログを用意するために、やっておくべきこと」「プロダクトオーナーとはどうあるべきか、その役割と観点」の2点でした。
著者が唱える『仮説検証型アジャイル開発』は、いきなりアジャイル開発を始めるのではなく、もっと他の手段で『探索』を進めて、「ユーザーに体験してもらわないとこれ以上の検証はできない」と判断したときに、初めて開発を行うほうがいい、と読み取りました。言い換えると「アジャイル開発のスタート地点に立つまでにやるべきことがたくさんある。」だと思います。
これまでのアジャイル開発やスクラム開発の書籍は、いきなりプロダクトバックログを用意して、開発を始める、そのためのプラクティスの観点が強いものが多いなと感じていました。どうやってプロダクトバックログを用意するのか、プロダクトバックログの正しさ/妥当性はどうやって評価するのかが抜けているのです。自分もデザインスプリントという手法を取り入れ、妥当性のあるプロダクトバックログを用意するようにしているため、本書のノウハウはとても参考になるところが多かったです。
プロダクトオーナーには求められる観点が3つあり、
・「要求は何か」→「要求(プロダクトバックログ)の言語化、整理」
・「インターフェースはどうあるべきか」→「UIの方針決め」
・「ビジネスモデルはどうあるべきか」→「ビジネスモデルの設計」
プロダクトづくりのBusiness, Technology, Design領域で言うところの、BusinessとDesignの要素が強いことを感じました。もちろんTechnologyの観点も蔑ろにするわけではないが、開発チームを頼ることができるので、割合は低いのだと思います。またプロダクトオーナーに求められる観点・役割が幅広いため、適切な権限移譲によって負担の軽減を狙うのもよいとのこと。
不確実性のあるプロダクトづくりでは、教科書的な成功法はないため、本書のようなベストプラクティスや、そこから予想される原理原則を知り、自分の中に選択肢を増やすことが大事であることを再認識しました。 -
-
-
-
-
-
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.時間軸を明らかにし、期限も明確に決める。
・バリューストリームマッピング。プロダクトの価値がお客さんの手に渡るまでの仕事の流れを見える化するプラクティス。流れのどこで付加価値が生まれるのか、プロダクトが滞りなく実現に向けて動いていけるのかを確認する。 -