スクラム入門 の商品レビュー

ケンシュエイバー(著者),テクノロジックアート(訳者),長瀬嘉秀

2019/03/07

「スクラム」ってのはアジャイル開発手法の一つ、という説明でええんかな。
具体的なことはこの本なり適当にぐぐるなりで(こらこら)。
まあ著者はスクラムを教える仕事をしているので多少「お仕事ちょーだい」
風味なのはあるけど、それでも「スクラムで失敗した場合」ってのを最初の方に
持ってきてたりとか、かなり公平な書き方にはなってる。

まあ本でも書いてあるように、「固定納期・固定価格」な仕事の受け方では
この手法は全然使えないのだけど、前のところとか次かも知れないところみたいに、
「ROIを最大にするために、仕様とか納期とかを調整できる」ところなら
なかなか使えるかもなあ。

2013/04/30

プロジェクト一般の手法「スクラム」に関する入門書。スクラムとはこういうものですよ、という説明と実例からなり、非常に読みやすい。

スクラムのプラクティス（「やり方」という感じで考えてください）の特徴は、メンバーが自発的に取り組むことと、その環境を提供することに尽きると思う。
「課題に対して短期間でできることをみんなで考えてください、マネージャーは応援しますが指示はしませんから、完全な機能を、みんなの力で提供してください」というプラクティスと、そのために必要なターム（「スプリント」とか「バックログ」とか）でできているのがスクラム開発の大枠。その中でどういう技法を使うか、まではうるさくない。テストファーストもガントチャートも、それが必要もしくは効果的であればやってかまわない。
とはいえ、これだけでもウォーターフォールとは違ったスタイルになる。指示よりは自発、工程の分割よりは統合、指示待ちよりは作業支援。個々人の間で責任を分かち、上位に投げるのではなく、それぞれがそれぞれの工程の影響を受けるがゆえに、全体でひとつのチームとして取り組んで、責任を共有してゆく。

スクラムに関する「やるべきこと」「やってはいけないこと」はあるにせよ、そのあるべき姿だけを追求すると、会社の文化と衝突することを著者はたびたび警告している。たとえばスクラムの考え方は、プログラマーを下に、設計者を上位に見る考え方とは両立しにくいだろうし、管理者と実務者という見方でも成立しにくい。スクラムはあくまで、チームの中はみんな平等かつ緊密に連携し、作業する人（＝実務者）を外部の邪魔者（＝管理者）による介入から守ることを旨としているから。
衝突を回避するためには、
・開発側ではスクラムのプラクティスを適用しつつ、管理側ではガントチャートなど、ウォーターフォール時代のビューを提供する
・スクラムの見方と既存の見方を両方示しておき、実際には既存の見方に従ったプロジェクトを行うにせよ、結果を公開する
といった方法があり、スクラムを・開発体制を破壊するくらいであれば折れた方がいいことも示されている。

スクラムの課題は以上のことからも見えているが、付録として残されている「固定価格・固定期日の契約」については、もっと深く読者の側で考えなければいけない。
入札案件にウォーターフォールを適用することは簡単だが、要求仕様が二転三転したり、顧客が案件にコミットしないといった事態は容易に発生しうる。しかし、スクラム開発で取り組もうとしても、分割納品や顧客の参加が望めなければ破綻する。そして、えてして入札案件はそういうものが多い...
IT関係の入札なんて、期日と予算が公開された段階で成功するか失敗するか見えてしまい、どんな手法でもそれは避けられない、のかもしれない。少なくとも、業者側だけで回避することは不可能なのかもしれない。

2009/11/12

スクラムには３つの役割がある。
プロダクトオーナー、チーム、スクラムマスター
チームは要件を診て、自分たちのスキルや能力に照らし合わせて利用すべき技術を決める。
新しい複雑性や困難や予想外の問題に遭遇したら日次でチームの手法を修正する。