Software in 30 Days 〜 スクラムによるアジャイルな組織変革"成功"ガイド

翻訳に参加した本について紹介いたします。

Software in 30 Days スクラムによるアジャイルな組織変革"成功"ガイド

最初のアジャイルチームが成功した先に

現場向けのアジャイルの知識は、もう十分ついただろうか？

チームビルディングはできていて、毎日朝会をしてチームの状態を知ることができ、プロダクトバックログは整備されて、リリース計画は明らかで、プロダクトオーナーはこれからチームが生み出すべきものを提案し、チームは着々と信頼を積み重ね、期待以上の成果を顧客や利用者に届けているだろうか。

さて、次はどうするだろう？成功したチームは成熟し、もしかしたら現在のプロダクトでできることはもう先が見えてしまい、マネージャーはもっと別の新しいことに、チームのメンバーを使いたがっているかもしれない。一方で、製品がうまくいかなかった場合は、チームの解散の危機とともに、「アジャイル否定説」が一部のマネージャーの中に盛り上がっているかもしれない。成功しようとしまいと、チームは有限の寿命を持つ存在だ。

ソフトウェアづくりは、開発チームだけでは完結しない

現代社会では、ITは経営と直結する。ソフトウェアを作るにせよ、誰かに作ってもらうにせよ、マネジメントは必要で、コストをかけて、将来の需要に対し着実に手を打っていかなければならない。個人のスキル、チームのスキル、組織のスキル。これらを上手に組み合わせて、市場や組織の需要に合わせたソフトウェアが常に必要になる。

ソフトウェアづくりは、開発チームだけでは完結しない。

スクラムを作ったケン・シュエイバーとジェフ・サザーランドは、ソフトウェア開発の外側にいる人向けの本を書いた。エグゼクティブとマネージャに向けて、現代的なソフトウェア開発組織の作り方を、スクラムを足がかりに作り上げる方法を説明した。

Software in 30 Days スクラムによるアジャイルな組織変革"成功"ガイド

ここからは、本書の内容を章を追って紹介していく。

イントロダクション

私たちがソフトウェア開発を扱った本を書くのは、本書がはじめてではない。
しかし、ソフトウェア開発を「しない」人に向けて書いたのは、本書がはじめてである。
本書は、生き残りと競争力をソフトウェアに依存している組織のリーダーたちに向けて書いたものだ。ソフトウェアを高速かつ漸進的に、できるだけ高い投資収益率（ROI）を得られるように開発することで、その恩恵を享受することのできる組織のリーダーたちに向けて書いたものだ。
ビジネスと技術の複雑性に直面し、ソフトウェアを届けることが困難になっているリーダーたちに向けて書いたものだ。このようなリーダーたちが組織の目標達成を支援し、組織内部の能力を高め、プロダクトを改善できるように、私たちは本書を書いた。

もしあなたが開発者なら、スクラムの価値を理解している開発者なら、あなたにとって、あなた以外の人々、開発チームの外側にいる人達への説明のために、この本は役立つかもしれない。

あなたがマネージャーなら、開発チームが何をしようとしていて、経営は何を求めているか、その中で自分がどういう価値を提供できるか、どう生き残っていくか、この本からヒントが得られるかもしれない(実際マネージャーは成功の鍵を握る)。

あなたが経営者なら、アジャイルを理解するためにこの本を読むのは正解だと思う。事業としてのソフトウェア開発が多少なりとも分かっているなら、スクラムの意味するところを直感的に理解できるのではないだろうか。この不確実でスピーディに変化する社会において、ビジネスを継続的に進めていくためには、確固たる実績の上に学習を積み重ねるしかないのだ。

第1部 なぜ世界のあらゆるビジネスが30日間でソフトウェアを作れるのか (Why Every Business in the World Can Produce Software in 30 Days)

あなたは、自分のソフトウェア開発組織に不満を持っているのだろう。より速く、より柔軟性があり、自分のニーズを理解してくれて、もっと収益が上がるようにしてくれる、そんな組織を期待しているのだろう。ここでは、あなたが不満を持っている理由と、その解決方法について考察する。

第1部は、旧来型のソフトウェア開発ではなく、スクラムを採用するべきなのかを説明し、どうやって最初のチームを立ち上げ、何を学ぶべきかが語られていく。2013年の現在では、完全なウォーターフォールプロジェクトなどほとんど存在しないのではないかと思う。自分たちは旧来型のウォーターフォールだと思っていても、実際は手戻りや、ドキュメント不足、テスト工数の増大や、品質や納期の遅延、プロジェクトマネジメント人材の不足、競争激化に伴う不十分なスケジュールに悩まされているのではないだろうか。すでに、完全な工程の分割や、手戻りの少ない開発ができるほどに、ビジネスも組織も安定していないかもしれない。

第1章 ソフトウェアの危機

多くのソフトウェア開発組織は、ムダがあり、制御不可能なリスクを持ち、予測可能性がなく、想定外で、価値の低いことが約束された開発プロセスにしたがっている。ここでは、なぜこのプロセスを選択しているのか、どのようにして失敗が約束されているのかを考察する。そして、そこから脱出した組織をいくつか紹介する。

ソフトウェア開発プロジェクトには多くの不確実性が存在する。作ってみたらユーザーの反応が異なり、要求は変更せざるをえなくなる。開発者の理解がスムーズとは限らない。技術的な問題が生じることもあるし、チームの人間面で問題を抱えることもあるだろう。誰か一人のプロジェクトマネージャが工程全体をマネージすることは、難しいかもしれない。ガントチャートで全てを管理することは
、変更のための多大なコストがかかるかもしれない。情報量と変動要因が多すぎて、誰も責任を取れないかもしれない。