『リーン開発の本質』のあとがき。日本のアジャイルをつくりたい。

わけあって『リーン開発の本質』を再読しています。る。日本の中でアジャイル開発を、できるだけ管理者の言葉として伝えたかった本です。この本は本当にたくさんの人に読んでほしいなぁ。ここに、そのあとがき、として書いた文章を掲載します。

最後に書いた、

多くの間違った標準化が、「人は本来怠け者でありしっかり働かせるために規則を作らなければならない」とか｢人は交換可能である｣というメンタリティから発している。もし、組織の文化や方針の中心にこのような考え方があると、もしくは多くの管理者がこのように考えているならば、「決して」リーン活動は成功しない。そうではなく、「人の持つ工夫のモチベーションを活かす」こと、「一人ひとりの人を育てる」ことこそ、マネジメントの中心となるべきだ。「人」の要素はプロセスの中心である。ここをやり間違えてはならない。 日本のソフトウエア業界が、人の持つ知恵と力を大切にしながら、高品質、高生産性を上げる体質へと転換するきっかけに本書がなることを願うと同時に、私自身の明日からの行動につなげていこうと強く思う。

という文章が、アジャイルジャパンをはじめるきっかけになったし、日本でこの活動を継続していこうという情熱（気合？）につながっている。以下、あとがきの全文です。

• アジャイル」と「リーン」の出会いが「リーン開発の本質」である

ソフトウエア開発の一手法である「アジャイル」と、日本の工場の生産方式に起源をもつ「トヨタ生産方式」。一見まったく違う２つの分野をクロスオーバーする新しい流れが起こっている。それが、本書の主題である「リーン開発」である。 「アジャイル」は、日本では2000年ごろから、ソフトウエア開発現場のリーダー、プログラマーをはじめとする、最新オブジェクト指向技術やプロジェクトマネジメント技術に明るい層から浸透してきた。中ではXP（エクストリームプログラミング）という手法が最も実践例も多く、そこではテスト駆動開発、ペアプログラミングといった開発手法を含む、フィードバック重視の反復型開発が行われる。もともと、90年代に米国でXPやSCRUM、FDDといった手法が現れ、2001年に、これらを連合する言葉として、「アジャイル」という言葉が創られた経緯がある。 一方で、70年代80年代の日本の自動車製造業で成功をおさめたトヨタ生産方式は、国内の製造業のみならず、海を渡り「リーン」としてさまざまな業種に適用された。生産方式をそのまま適応するのでなく、リーン思考（Lean Thinking）として抽象化された思考方法や原理・原則は、生産方式から離れて「開発」のような知識創造の場面にも有効であることが示されてきている。 この２つの流れ、すなわち、ソフトウエア開発の現場を活性化し、反復によってフィードバックを得ながら人とチームの学習を促進する「アジャイル」の考え方と、顧客価値の流れを重視し、ムダをそぎ落とした改善指向の「リーン」の考え方が、Mary Poppendieck と Tom Poppendieckによって出会い、本書「リーン開発」が生まれた。本書では、リーンをソフトウエア開発に適応することはすなわち、アジャイルの考え方を組織レベルにまで引き上げ、企業価値にまで結びつけることだと主張し、さらにその原則と指針を与える記念碑的な仕事となっているといえよう。

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

前著「リーンソフトウエア開発」において最初に指摘されたアジャイルとリーンの共通点、原則および思考ツールは、再編成され、事例を加えられ、そして「人」に関する考察に強調を加えられて第二版となった。第一版とはまったく別の一冊となる本書は、前作の「具体版」とも「補足版」ともとることができる内容だが、抽象度と議論の説得力が格段に上がっており、私はまさに「本質版」と呼ぶべきものだと思う。副題となる「コンセプトをキャッシュに変えるまで」（From Concept To Cash）は、価値の流れ（バリューストリーム）の両端を指している。ある製品が「コンセプト」からはじまり、開発、生産を経て販売され「キャッシュ」に変わるまでの一連の流れ全体に注目し、その流れに、顧客価値を少量ずつすばやく流す、という考え方がリーンなのである。だから、「ソフトウエア開発」とはいっても、本当に局所的な「ソフトウエア開発チーム」に焦点を合わせるのは近視眼的である。そのチームが開発しようとしているソフトウエアの要求がどこから来ており、どこに納品することでキャッシュとなるのか、という製品サイクル全体を見ることが必要であり、そこに流れている「顧客価値」を見極めることが重要だ、という主張である。 これにはとても大きな意味が３つある。1つ目は、エンジニアに対するメッセージ。ソフトウエア開発、という活動がそれ１つでは独立して価値をなすものではない、という気づきを読者に与え、ソフトウエア開発者が他の企業活動と協調すべきであるという認識を生む。エンジニアは、いわば技術屋の集まりであるソフトウエア開発チームから、品質保証チーム、顧客チーム、管理部門と協調して企業活動の「大きな絵」に参加せよ、というメッセージである。2つ目は、現場リーダーに対してアジャイルを管理者に説明する語彙を提供する。もし、企業活動の中でソフトウエア開発が重要であり、そこから価値をすばやく引き出したいのであれば、それはアジャイルである必要がある。つまり、リーンの言葉を使うことによって、企業の競争力の１つとしてアジャイル開発を位置づけられる。3つ目は、マネジメント層に対するメッセージ。どんなにソフトウエア工学が発展しても、人の要素こそが重要であり、人のモチベーション、人の技術に対する誇り、人が持つ「良いものをつくろう」と考える向上心を大切にすることを外してしまっては、ソフトウエア開発のマネジメントは不可能であることを声高らかに宣言しているのだ。

• 本書のみどころ３点は、「人」、「変化を受け入れる技術」、そして「デミング博士」

私が特に気に入っている本書の新しい視点を紹介しよう。1つ目は、一人の人の重要性について強く焦点をあてたこと。「チーム」の重要性はアジャイルの中でたびたび協調されてきたが、「リーダシップ」について深く掘り下げた本はなかったのだ。トヨタのCEに代表されるような、一人の人間が、ひとつの製品についてマーケティング側と技術側の両方の責任を持つ形態のあり方、また、技術を持ち、かつそれを教えることができる現場のリーダーのあり方である。 2つ目は、変化を受け入れる手段として、「セットベース設計」と「リファクタリング」を位置づけたこと。もっとも情報が集まる最終決定時点まで、複数の設計判断の選択肢を維持する「セットベース設計」は、取り返しが効かない判断を最適に扱う手法である。一方、テストを通過するようにシンプルにソフトウエアを実装してから、後で追加される機能に応じてその内部構造を変更する手法である「リファクタリング」は、ソフトウエア特有の長所を生かした、先に作って後で変更する手法である。この２つの手法を、問題に応じて使い分けることが設計の肝になる。 3つ目は、これは歴史的な発見なのだが、日本の製造業とアジャイルの共通の原点としてデミングの思想があることを指摘していること。1950年に来日してから、80年代までの日本の製造業にあたえたデミング博士の功績については、日本の品質管理を語る上で欠かすことができない。同時に、アジャイルの源流には、1970年代にはじめて進化型反復開発手法として定式化されたイギリスのTom Gilb によるEvo (Evolutionary Project Management)があり、これは、デミング博士のPDCAサイクルを理論の基礎にしているし、SCRUMもリーン思考を基礎にしている。XPも第二版でTPSについての章を１つ割いているのだ。本書６章の、デミングの１４項目を再度読んでみてもらいたい。そこに書かれていることは、人を中心にすえるリーンとアジャイルの本質に迫る視点である。 日本のなかでTPSやリーンとアジャイルを展開するときに、ここを出発点とすべきではないだろうか、と私は考える。日本で旧世代にアジャイルの言葉が浸透しにくくても、新世代に品質管理の言葉が浸透しにくくても、ここで述べられているデミングの言葉を共通の理解として出発点とできないだろうか。

• 私とリーン開発の関係、日本での活動

私自身、ソフトウエア開発の現場にXPを紹介しはじめたのが2000年である。以来アジャイル開発を中心として翻訳・執筆活動を行うと同時に、現場のプロジェクトにそれらを適用し、実践的な現場活性化手法として「プロジェクトファシリテーション 」としてまとめてきた。ここでも、TPSの考え方には深く影響されたし、さらに最近、仕事のやりがいを示す言葉として、デミング経営哲学を引き継いでいる吉田耕作氏の「Joy of Work」という言葉があることを知り、とても共感している。私は、海外でアジャイルムーブメントが盛んになる中、2003年に米国のソルトレイク市で開催された Agile Development Conference 2003 に参加し、そこではじめて Mary の講演を聴いた。米国人の口から、大野耐一の名前をソフトウエア開発の文脈で聞いたことにショックと嫉妬を覚え、この本が日本から出版できなかったことを恥じると同時に、第一版を訳したいと強く思って本人に掛け合った。第一版の日本語版が出版されたのが2004年。そして、2007年には、日本でトヨタ工場見学に夫妻を案内することもできたし、再度米国ワシントンD.C.でAgile2007 に参加、Maryの本書の講演を聞くと同時に、私自身も彼女と二人で “Learning Kaizen from Toyota [with Mind Maps]” というセッションを持つことができた。日本とアメリカを行ったりきたりしながら、「リーン」と「アジャイル」というもしかしたら歴史的な日米合作とも言えるコンセプトに携われたことを、うれしく思うと同時に、これが日本のソフトウエア開発を「組織的に」変える力を持っていることを確信するにいたった。 本書で伝えられている日本のコンセプトリーダーは、豊田佐吉、豊田喜一郎、大野耐一、新郷重夫といった「伝説」となっている方々だけではありません。ものづくりアーキテクチャ論で日本のものづくりの強さを解明した藤本隆宏氏、製品品質の独創的なモデルを提示した狩野紀昭氏、そして、適応型組織を使った「知識創造」手法としてスクラムを始めてモデル化した野中郁次郎氏など、現在も活躍中の日本の諸先輩方へ敬意を表します。

• 「リーン開発の本質」の概観

ここで、本書を振り返って、各章をまとめてその要所を見ていこう。

第１章 歴史

ここでは、米国の大量生産型（フォード）の手法と日本の少量生産型（トヨタ）の手法が現れた歴史的必然性を述べている。「交換可能な部品」という概念の延長に米国自動車産業の最初の発展である大量生産モデルがあり、それを「交換可能な人」という概念の始まりとしている。それとは逆に、日本では戦後の状況から少量生産がはじまり、大野耐一がトヨタ生産方式を生み出す動機になっている。そこでは、人は現場の工夫の源泉と捉えられている。その後、トヨタ生産方式は、米国で「リーン」という概念で整理され、その原則は製造現場のみならず、リーンサプライチェーン、リーン製品開発へと発展する。そして、リーン製品開発のその流れの先に、本書での主題である、「リーンソフトウエア開発」がある、という位置づけが示される。導入として有効に機能している章だ。

第２章 原則

ここでは、リーンの原則を７つ導入している。「ソフトウエア開発」の特異性とはなんだろうか。ハードウエアでなく「ソフトウエア」であるからには、変化を受け入れなくてはならない宿命がある。また、製造ではなく「開発」であるからには、決定論的（定義してから実現する）ではなく、経験論的（徐々に、フィードバックを得ながら固めていく）であるべきだ。そしてそれは「知識創造」のプロセスであるから、一方向で決定論的なウォーターフォールプロセスとは本質的に合わない。これらのソフトウエア開発独自の性質とリーン思考から、リーンソフトウエア開発の７つの原則が解説される。

原則１：ムダをなくす
原則２：品質を作りこむ
原則３：知識を作り出す
原則４：決定を遅らせる
原則５：速く提供する
原則６：人を尊重する
原則７：全体を最適化する

これらは第一版から踏襲され、名前付けを含めて再構成されたものだ。よりソフトウエア開発の特性を捕らえ、そこにリーンを適用した内容になっている。

第３章 価値

価値とは顧客の価値のこと。本書原書の副題でもある「コンセプトをキャッシュ（現金）に変えるまで」（From Concept To Cash）の流れ（バリューストリーム）に「価値」を少量ずつ高速に流すようにすることがリーンの本質である。そのためには、何が顧客を喜ばせるか、を理解すること。この価値がトヨタのチーフエンジニアに代表されるような、リーダシップによって確立されること、ITだけでは価値とならず、ビジネスの協調の中でITが価値となることが主張される。この章が全体の中心になる。

第４章 ムダ

逆に、価値のないものすべてがムダである。コードをできるだけ書かないこと、複雑さを増大させないこと、必要な機能しか作らないことなど。そして、TPSの７つのムダを、ソフトウエア開発にあてはめている。さらに、バリューストリームマップを取り上げ、自分の組織で顧客に「注文」を受けてからそれを顧客に「納品」するまでの「価値の流れ」を書き出し、そこにあるムダを発見する。

第５章 スピード

ムダが取れればスピードが出せる。待ち行列の理論を応用し、バリューストリームを通る時間（サイクルタイム）を短くするための方法が語られる。 1．作業の到着率を平準化する。 2．プロセス内のものの数を最少化する。 3．プロセス内のもののサイズを最小化する。 4．一定のリズムを確立する。 5．作業を許容範囲内に制限する。 6．プル型スケジューリングを利用する。

第６章 人

マネジメントのシステム、リーダシップのありかたなどを取り上げている。アジャイルの中でチームの焦点をあてた本はあっても、リーダシップに焦点をあてた本はなかった。グループとチームの違い、リーダシップのありかた、かんばんなどの職場の見える化、そして、インセンティブや個人評価、そして、デミング博士について。特に、彼の日本に与えた影響とデミングの１４項目。日本のなかでアジャイルとリーンを展開するときに、ここを出発点とすべきではないだろうか。私がもっとも読んでもらいたい章である。

第７章 知識

ソフトウエア開発は知識創造活動であり、現代のソフトウエアは「知識のかたまり」である。この知識を保持する組み合わせがテストとコードだ。反復型開発を通して学習した内容を「ドキュメント」にしさえすれば、組織的な学習ができるようになると考える人もいるが、たいていは、ドキュメントの山は役に立たない。トヨタの問題解決手法と、デミングのPDCAサイクルは相似であり、トヨタは科学的思考方法を取り入れて「ライン・ストップ」と「ジャスト・イン・タイム」を組み合わせた。その結果生まれたのが、利益のじゃまを取り除くことを重視し、全社的に一貫して行われた、詳細なレベルでの規律ある問題解決手法、トヨタ生産方式だ。

第８章 品質

繰り返しリリース型の開発によるフィードバックが、品質を高める。優れたソフトウエアアーキテクチャの目標は、そのような撤回不可能な決定を最小限にとどめ、反復型開発をサポートするフレームワークを提供することだ。アーキテクチャ役割は、機能のサブシステム分割できるようにすること。また、標準は、リーンな環境では、標準はある仕事をするための、「現在の最善の方法」であり、よりよい方法があるという前提なのだ。そして、標準を絶えず変えていくという規律は、組織の骨格の一部であるべきだ。

第９章

パートナーオープンソースや９７年のアイシン火災を例に、グローバルなネットワーク構築、アウトソーシング、契約をまたぐ関係について言及している。

第１０章 　旅立ち

まとめとして、リーン活動を組織に展開していくためのロードマップを示す。そして、組織がリーン活動をはじめるための最も重要な「心構え」について書いている。

リーンとアジャイルを組織で始められるかどうかは、「心構え」できまる。 わたしは、アジャイルとリーン（TPS）が日本のもさまざまな組織に適用されていくことを願っているが、本書からの以下の引用によってそのひとつ警鐘を鳴らしたい。

リーン活動に乗り出す前に、「人について、何を本当に信じているか？」という問いに答えなくてはならない。プロセスにどのような態度で取り組んでいるか、考えてみよう。きちんとドキュメント化され、誰もが質問することなく従えるようなプロセスが、エクセレンスへの道だと考えているだろうか？ それとも、プロセスを標準化するのは、その作業をするヒトに、疑問に思ったり変更したりするための土台を与えるためだろうか？リーン原則は確実に、後者の考えに根ざしているのである。（中略）リーンを成功させるには、作業を行っているその人本人が、その作業のやり方を最もよく知っているのだ、（中略）問題を解決するには、本当に、作業を行う人たち自身に、トレーニングを行ったり、ツールや権限を与えたり、支援をしたりして、自らの問題を解決し、プロセスを改善できるようにするのが最善の手法だということを心から信じなくてはならない。

多くの間違った標準化が、「人は本来怠け者でありしっかり働かせるために規則を作らなければならない」とか｢人は交換可能である｣というメンタリティから発している。もし、組織の文化や方針の中心にこのような考え方があると、もしくは多くの管理者がこのように考えているならば、「決して」リーン活動は成功しない。そうではなく、「人の持つ工夫のモチベーションを活かす」こと、「一人ひとりの人を育てる」ことこそ、マネジメントの中心となるべきだ。「人」の要素はプロセスの中心である。ここをやり間違えてはならない。 日本のソフトウエア業界が、人の持つ知恵と力を大切にしながら、高品質、高生産性を上げる体質へと転換するきっかけに本書がなることを願うと同時に、私自身の明日からの行動につなげていこうと強く思う。