角谷信太郎のレビュー一覧

アジャイルサムライ――達人開発者への道

JonathanRasmusson / 西村直人 / 角谷信太郎 / 近藤修平 / 角掛拓未

2023/5/14
■インセプションデッキの10の設問
1.我われはなぜここにいるのか?
　何のために自分たちはチームを組むのか。自分たちの顧客は誰なのか。そもそもこのプロジェクトが始まった理由は何なのか。こうしたことを再確認する。
2.エレベーターピッチを作る
　30秒以内に2センテンスでプロジェクトをアピールするとしたら、何を伝えるべきだろうか?
3.パッケージデザインを作る
　何気なくめくった雑誌のページに、自分たちのプロダクトやサービスの広告が載っているとしたら、それはどんな内容がいいだろうか?それからもっと大事なのは、その広告を見た人は君のプロダクトを買いたくなるだろうか?
4.やらないことリストを作る
　プロジェクトで実現したいことというのはかなり明確になっているものだ。それと同じかそれ以上に、やらないこともはっきりさせよう。そしてそれをわかりやすく一覧にするんだ。
5.「ご近所さん」 を探せ
「プロジェクトの関係者」に含まれる範囲というものは、自分たちが思っているよりもずっと広いものだ。そうした「ご近所さん」を招いて、コーヒーでもごちそうしながら自己紹介ぐらいしてもいいんじゃないだろうか。
6.解決案を描く
　チーム全員の認識が揃っていることを確認するために、概要レベルのアーキテクチャ設計図を描こう。
7.夜も眠れなくなるような問題は何だろう?
　プロジェクトで起きる問題のなかには、考えることすら恐ろしいものだってある。だが、あえてそうした心配事について話し合おう。どうすれば最悪の事態を避けられるだろうか?被害を最小限に食い止める方法はあるだろうか?
8.期間を見極める
　どれぐらいの期間が必要なプロジェクトだろうか?3ヶ月? 半年?それとも9ヶ月?
9.何を諦めるのかをはっきりさせる
　プロジェクトにはいくつか操作可能な要素がある。期間、スコープ、予算、それから品質。現時点で譲れない要素はどれだろう?譲ることになるのもやむを得ない要素はどれだろう?
10.何がどれだけ必要なのか
　期間はどれぐらいかかりそうか?コストは?どんなチームならプロジェクトをやり遂げられるだろうか?

・作ろうとしているものは何なのか、それはなぜ必要なのか。
・このプロジェクトの魅力はどこにあるのか。
・プロジェクトで解決したい課題は何か。
・「ご近所さん」は誰なのか。
・解決策はどんな風になりそうか。
・向きあうことになりそうな課題とリスクは何か。
・プロジェクトの期間はどれぐらいの長さになりそうか。
・柔軟に対応すべきところはどこか。
・(期間や費用は) ざっくり何がどれだけ必要なのか。




＝＝＝
アジャイル開発のお勉強。

・ソフトウェア開発の３つの真実
　1.プロジェクトの開始時点にすべての要求を集めることはできない
　2.集めたところで、要求はどれも必ずといっていいほど変わる
　3.やるべきことはいつだって、与えられた時間と資金よりも多い

・アジャイルプロジェクトの3つの特徴
　1.役割分担がはっきりと分かれていない
　2.分析、設計、実装、テストといった開発工程がどれも、途切れることなく続く連続的な取り組みになる
3.チームが一丸となって成果責任を果たす

・インセプションデッキの課題一覧
　1.我われはなぜここにいるのか？
2.エレベーターピッチを作る
3.パッケージデザインを作る
4.やらないことリストを作る
5.「ご近所さん」を探せ
6.解決案を描く
7.夜も眠れなくなるような問題は何だろう？
8.期間を見極める
9.何を諦めるのかをはっきりさせる
10.何がどれだけ必要なのか

・荒ぶる四天王
　・スケジュールは圧縮される
　・予算は削減される
　・バグのリストは長くなる
　・やるべきことは際限なく湧き出てくる

・文書化の難しさ
　実際のソフトウェアプロジェクトで、重厚な文書化が要求を捉える手段として本当にうまく機能したことなんて一度もない。顧客は自分たちの欲しいものを手に入れることはほとんどなく、開発チームは求められたものを構築しきれない。

・ユーザーストーリーVS要件定義書と仕様書
　無駄がない、正確、必要な分を必要なときに　vs　重厚、不正確、最新じゃない
　対面でのコミュニケーションを促す　vs　憶測や誤った前提を招き寄せる
　計画がシンプルになる　vs　計画が複雑になる
　低コスト、素早い、手軽　vs　コストがかさむ、遅い、手間がかかる
　最新の情報が反映されている　vs　情報が古くなったまま放置される
　チームが学習するということを踏まえている　vs　チームが学習するということを考慮しない
　フィードバックを即時反映できる　vs　フィードバックを即時反映できない
　見積り精度の高低を当てにしない　vs　さも見積り精度が高いかのように取り繕う
　チームの協調作業や新しい取り組みを歓迎する　vs　オープンな協調作業や新しい取り組みを歓迎しない

・アジャイルソフトウェア開発の12の原則
1.顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
2.要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。
3.動くソフトウェアを、2-3週間から2-3ヶ月という、できるだけ短い時間間隔でリリースします。
4.ビジネス側の人と開発者は、プロジェクトを通して、日々一緒に働かなければなりません。
5.意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。
6.情報を伝えるもっとも効率的で効果的な方法は、フェイス・トゥ・フェイスで話をすることです。
7.動くソフトウェアこそが進捗の最も重要な尺度です。
8.アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。
9.技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
10.シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
11.最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
12.チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

VenkatSubramaniam / AndyHunt / 角谷信太郎 / 木下史彦

タイトルにあるように、現場開発者にとって有用なアジャイル・プラクティスを紹介する本。

変化に対応するために色々な本・雑誌を読め、など、アジャイル・プロジェクトとは直接関係がなく、要は「職業人としてアジャイルであるためのプラクティス」といった事柄にまで言及している点に特徴。

ただ、他のアジャイル本をいくつか読んだ人間からすると、特に新鮮味のない提言が並んでいるようにしか見えなかった。

☆３つ。

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

HenrikKniberg / 角谷信太郎 / 市谷聡啓 / 藤原大

実際にアジャイル（リーン）プロジェクトを経験した著者が、自身のチームで実施した具体的施策（カンバンの便箋にどういう情報を書き、また逆に何を書かないか、など）を紹介する本。

アジャイルの理念、一般的施策及びその意図に関する記述は薄いので、「そもそもアジャイルとはなんぞや？」というレベルの人間にはおすすめできない。

しかし、アジャイルの入門書を一冊でも読み、上記を把握しているのであれば、アジャイル・プロジェクトの雰囲気や、実際に直面する困難、これに対する具体的対応策を知る上で、参考になる。

ただ、アジャイルとはまさに「あらゆる状況に対応できる銀の弾丸はないのであるから、状況に応じて最適なプロセスを組め」という取組みであるから、本書に紹介されている思索をそのまま自分のプロジェクトに持ってくることはできない（特に、著者のプロジェクトは60人体制という、アジャイルにしては大きめのプロジェクトであり、円滑なコミュニケーションを担保するための施策が多くあったが、大抵のプロジェクトはより少数であり、そうした施策は悪戯に時間を浪費するだけになる可能性が高い）。

要は「ふーん、アジャイル開発って、こんな雰囲気のもとで、こんな感じでやると、こんなふうに成功しうるのか」という感覚値を得る、程度の期待値で読むのが最適。

その意味で、悪くはないが、劇的効果が望める類の書籍でもない。☆３つ。

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

VenkatSubramaniam / AndyHunt / 角谷信太郎 / 木下史彦

凄く良くまとまっていて、アジャイル開発何も知らない人が読むなら良いと思う。自分にとっては見聞きしたことのある話が多かったかなぁ。

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

VenkatSubramaniam / AndyHunt / 角谷信太郎 / 木下史彦

アジャイルの考え方が、具体例を交えながら書かれてて、とても分かり易くよい入門書。

アジャイルの考え方は、システム開発だけでなく、小規模のチームで何かをやる時にも当てはまる。そういう人たちが読んでも気づきがあると思う。

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

VenkatSubramaniam / AndyHunt / 角谷信太郎 / 木下史彦

アジャイル開発のキーワードを45個にしぼり、１つずつでも実際に取り入れられるよう記載されている。
例えば、「顧客に決めてもらう」「デプロイを自動化する」とか。

一番興味深い一言は「ソフトウェアを仕事にするのは、ランニングマシンに乗っているようなもの」「イテレーティブかつインクリメントに学習する」「顧客は、実装された機能を使って初めて自分たちの出した要件の理解を深めていく」「メンターとはチームメイトの成長を助けると同時に自分自身も成長すること」「ブタとニワトリ。ベーコンエッグ。」

アジャイルサムライ――達人開発者への道

JonathanRasmusson / 西村直人 / 角谷信太郎 / 近藤修平 / 角掛拓未

内容としては、知っていることが多かったが、メンタルな部分は参考になり、読みやすかった。
初心者から上級者、誰向けにいいとも思わないが、軽い読み物かな

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

VenkatSubramaniam / AndyHunt / 角谷信太郎 / 木下史彦

会社に置いてあったので、読んでみました。

私はソースとにらめっこして開発する業務は出来ませんが、
読んでみました。

サービスを企画開発販売するうえで、アジャイルって手法は
無視できないのかなーと思って手に取ってみました。
無視できない理由としてはアジャイルを採用して
ビジネススピードが速くなるのかなと。

まあ、アジャイルに切り替えるとかって、みんなの共通理解が
ないと難しいよね。


書かれていたのは、こんなことのような気がします。
・各プロセスにおけるプログラムの書き方
・各プロセスにおけるバランスの取り方
　－スピードのバランス
　－品質のバランス
　－メンバとの共有のバランス

朝会とスタンディングの打ち合わせが、有効だってことも納得。


ところどころプログラムの書き方については、飛ばして読みました。

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

VenkatSubramaniam / AndyHunt / 角谷信太郎 / 木下史彦

Agile入門書。読むに当たってオブジクト指向への理解があることが好ましい。
HOW-TOより心構えに多くの紙面が割かれている。そしてそれらはAgileに限らずエンジニア全般に有効な意識だと感じた。
しばらく寝かせて、何度か読み返す（レトロスペクティブ！）必要がありそうだ。

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

VenkatSubramaniam / AndyHunt / 角谷信太郎 / 木下史彦

なんかよく覚えてないけど、そこそこ面白かった気がする。
とにかく、アジャイルってなにか良く分からないし。
とりあえず読んでおく分には刺激になるだろうってとこか。

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

VenkatSubramaniam / AndyHunt / 角谷信太郎 / 木下史彦

アジャイル本やらプラグマティック・シェルフから読み漁っている人には、特に目新しい話はなく、そのエッセンスだけを抜き出して短いエッセイ風の読みものにまとめた感じ。逆にアジャイル本とかに馴染みの無い人には、入門書としては薄くて読み易く丁度良いかも。