リーン開発の本質 ソフトウエア開発に生かす7つの原則
http://www.amazon.co.jp/exec/obidos/ASIN/482228350X/xpjp-22

ついに、amazonで予約可能です！私は監訳を担当していますが、今回も、前作に劣らずとてもよい本。前作を読んでいない人には、前作を飛ばしてこの本をお勧めします。以下、監訳者としてのあとがきの一部です。。。

■「アジャイル」と「トヨタ生産方式」の出会いが「リーン開発の本質」である

ソフトウエア開発の一手法である「アジャイル」と、日本の工場の生産方式に起源をもつ「トヨタ生産方式」。一見まったく違う２つの分野をクロスオーバーする新しい流れが起こっている。それが、本書の主題である「リーン開発」である。

「アジャイル」は、日本では2000年ごろから、ソフトウエア開発現場のリーダー、プログラマーをはじめとする、最新オブジェクト指向技術やプロジェクトマネジメント技術に明るい層から浸透してきた。中ではXP（エクストリームプログラミング）という手法が最も実践例も多く、そこではテスト駆動開発、ペアプログラミングといった開発手法を含む、フィードバック重視の反復型開発が行われる。もともと、90年代に米国でXPやスクラム、FDDといった手法が現れ、2001年に、これらを連合する言葉として、「アジャイル」という言葉が創られた経緯がある。

一方で、70年代80年代の日本の自動車製造業で成功をおさめたトヨタ生産方式は、国内の製造業のみならず、海を渡り「リーン」としてさまざまな業種に適用された。生産方式をそのまま適応するのでなく、リーン思考（Lean Thinking）として抽象化された思考方法や原理・原則は、生産方式から離れて「開発」のような知識創造の場面にも有効であることが示されてきている。

この２つの流れ、すなわち、ソフトウエア開発の現場を活性化し、反復によってフィードバックを得ながら人とチームの学習を促進する「アジャイル」の考え方と、顧客価値の流れを重視し、ムダをそぎ落とした改善指向の「リーン」の考え方が、Mary Poppendieck と Tom Poppendieckによって出会い、本書「リーン開発」が生まれた。本書では、リーンをソフトウエア開発に適応することはすなわち、アジャイルの考え方を組織レベルにまで引き上げ、横断的に企業価値にまで結びつけることだと主張し、さらにその原則と指針を与える記念碑的な仕事となっているといえよう。

■価値の流れ全体を見ることが、アジャイルを組織的に機能させる

前著「リーンソフトウエア開発」において最初に指摘されたアジャイルとリーンの共通点、原則および思考ツールは、再編成され、事例を加えられ、そして「人」に関する考察に強調を加えられて第二版となった。第一版とはまったく別の一冊となる本書は、前作の「具体版」とも「補足版」ともとることができる内容だが、抽象度と議論の説得力が格段に上がっており、私はまさに「本質版」と呼ぶべきものだと思う。原著の副題となる「コンセプトをキャッシュに変えるまで」（From Concept To Cash）は、価値の流れ（バリューストリーム）の両端を指している。ある製品が「コンセプト」からはじまり、開発、生産を経て販売され「キャッシュ」に変わるまでの一連の流れ全体に注目し、その流れに、顧客価値を少量ずつすばやく流す、という考え方がリーンなのである。だから、「ソフトウエア開発」とはいっても、本当に局所的な「ソフトウエア開発チーム」に焦点を合わせるのは近視眼的である。そのチームが開発しようとしているソフトウエアの要求がどこから来ており、どこに納品することでキャッシュとなるのか、という製品開発サイクル全体を見ることが必要であり、そこに流れている「顧客価値」を見極めることが重要だ、という主張である。

これにはとても大きな意味が３つある。1つ目は、エンジニアに対するメッセージ。ソフトウエア開発、という活動がそれ１つでは独立して価値をなすものではない、という気づきを読者に与え、ソフトウエア開発者が他の企業活動と協調すべきであるという認識を生む。エンジニアは、いわば技術屋の集まりであるソフトウエア開発チームから、品質保証チーム、顧客チーム、管理部門と協調して企業活動の「大きな絵」に参加せよ、というメッセージである。2つ目は、現場リーダーに対してアジャイルを管理者に説明する語彙を提供する。もし、企業活動の中でソフトウエア開発が重要であり、そこから価値をすばやく引き出したいのであれば、少量ずつ短い周期で開発を回さなければならない。すなわちアジャイルである必要がある。リーンの言葉を使うことによって、企業の競争力の１つとしてアジャイル開発を位置づけられる。3つ目は、マネジメント層に対するメッセージ。どんなにソフトウエア工学が発展しても、人の要素こそが重要であり、人のモチベーション、人の技術に対する誇り、人が持つ「良いものをつくろう」と考える向上心を大切にすることを外してしまっては、ソフトウエア開発のマネジメントは不可能であることを声高らかに宣言しているのだ。
（つづく。。。）

牛尾さんが書いています。

オフショア時代を乗り切る明確な要求仕様作成術http://itpro.nikkeibp.co.jp/article/Watcher/20080122/291715/

要求仕様をどう作るか、という話は昔から綿々とあるのだけど、工学の方向に行き過ぎると現場で使えなくなったりするから理想論はおいておいて、今の現場でどういう解があるかという問題にトライしています。

ちょうど、「要求開発」が盛り上がっていて、「アジャイル」が言葉として浸透し、「Ruby」が人気があってかつすばやく作れ、「受託開発」という契約関係の中で、「オフショア」という時代の波、という多くの要素を文脈として、Ruby を使ってすばやくアプリを作って見せるのが「１つの実践できる解」である、ということ。

こういうトライがたくさん現場で発生してくるのが、光に見える。