注意
本稿は長文ポエムであって、読者のみなさんに考えを押し付けるものではありません。自分は専門家でもなく、知識の抜けやさまざまな議論があると思っています。コメントはたぶん拾いきれないと思うので、皆さんが感じたことは、皆さんが新しく記事を書いて見解を深めていただけると有り難いなと思います。
本稿の概要
「アジャイルは死んだ」は既に以下のように何度も表明されてきた。しばらく時間が取れたこともあり、少し考えてみることにした。アジャイルの「何が」辛いのかと、どうしたら良いのだろうと。
| アジャイルは死んだ | URL |
|---|---|
| Agile is Dead (Long Live Agility) | https://pragdave.me/blog/2014/03/04/time-to-kill-agile/ |
| アジャイルは死んだ。しかしアジャリティは滅びんよ、何度でもよみがえるさ！ | http://pigya.hatenablog.com/entry/20140313/1394703729 |
| Agile is Dead | https://www.linkedin.com/pulse/agile-dead-matthew-kern |
| Agile is Dead – Again | https://www.infoq.com/news/2016/05/agile-dead-again |
| アジャイルは”再び"死んだ | https://www.infoq.com/jp/news/2016/06/agile-dead-again |
| Agile is Dead(Dave Thomas) | http://gotocon.com/dl/goto-amsterdam-2015/slides/DaveThomasPragmatic_EVENINGKEYNOTEAgileIsDead.pdf |
| 方法論の終焉 | http://blogs.itmedia.co.jp/hiranabe/2011/05/end-of-methodology-ja.html |
その結果、自分はすっかり言及の減ってしまったリーンソフトウェア開発や、それらの源流であるトヨタの生産方式、トヨタが現在取り組んでいる自工程完結を評価するのがよいのではないかと思い至った。本稿は、そういうポエムである。
本稿でいうリーン（ソフトウェア）開発とは何か？
- 2003年にメアリー・ポッペンディークとトム・ポッペンディークにより提唱されたトヨタ生産方式を源流とするリーン生産方式をソフトウェア開発に適用した原則集。以下を指す。
リーンソフトウエア開発～アジャイル開発を実践する22の方法～
リーン開発の本質
エリック・リース氏のリーンスタートアップやオライリーのリーンシリーズとは異なるので注意いただきたい。
きっかけとしてのアジャイル方法論の違和感：結局、アジャイルでも多くの課題が残る。
「今回のプロジェクトがやりにくいのはウォーターフォールでやっているからだ」、「今回のプロジェクトが適当なのはアジャイルでやっているからだ」何度となくこういった議論が繰り返されてきた。これらの意見は、どちらも妥当ではないと感じる。
アジャイルにしろ、ウォーターフォールにしろ、成功するプロジェクトは成功し、失敗するプロジェクトは失敗するものではないか、自身の経験からはそう感じている。
実際にプロセスと成否の関係については、こちらが的確にまとまっていて、その経験がそれほど間違いでないと感じる。
この表を見てわかることは アジャイルかウォーターフォールかというプロセスに関わらず規模が大きくなるほどプロジェクトの失敗の確率は増大することである。
アジャイルはウォーターフォールに比べ少しだけ良い成果を上げているように見える。ただ、アジャイルもプロセスに適用するだけで成功を保証するものではなく、どのようなプロセスであったとしても依然として大きな改善余地があることがわかる。
もちろん、このようなアジャイルの課題に対してDAD、ハイブリッドアジャイルなど取り組みはあるようだ。（個人的にはついていけていない。）ただ、個人的には大きなムーブメントとなりえないだろうと感じている。それは方法論をいかにアップデートしようと、「アジャイルは死んだ」で明らかになった問題を解決する方向性とは少し異なるのではと感じるためである。
Agile is Dead.を生み出した源泉は何か。
アジャイル・マニフェストの連名者の一人、Dave Thomas氏は、 2015年のプレゼン Agile is Dead.や2016年の記事（を要約したこちら）において、アジャイルへ警鐘をならしている。
ウォーターフォールなどが形骸化した手法やプロセスとしてアジャイルの標的にしてきた。しかし、アジャイルの方法論やツールを教えようとするアジャイル自身が、今やその立場にいるのではと鋭い指摘である。
このアジャイルで起きている問題の源泉についてより深く考察しているのは、同じくアジャイル・マニフェストの創案者の一人、アリスター・コーバーン氏と思う。コーバーンは方法論の終焉で、以下のように述べている。
これまでに、列挙された役割や仕事の割り当て、用いるテクニック、そして相互作用の接点などが、分厚い教則として書かれてきた。それは多くの組織やプロジェクト、国、文化をまたいで、一様に使われることを想定していた。我々が「プロセス」あるいは「方法論」という言葉でこの30年以上考えてきたのはこうしたことだったが、それは今や終焉を迎えたのである。依然として、それ(プロセスや方法論)を期待する人達もいるだろうし、それ／それらを求める人達がいるだろうことも想像に難くない。しかし、我々はそれらの人達を満足させることはできない。 なぜなら、我々ソフトウェア産業界に身をおくものの多くが、プロセスや方法論といったものが、ひどく部分最適なものであるということを悟り、 それらを生み出すことをどんどん拒否し始めているからだ。そんなものを生み出す者たちに災いあれ。そんなものにお金を払ってうまく行くと期待する者たちに災いあれ。
つまり、アジャイル方法論では最適化/単純化しすぎた状態を万能薬のように様々なプロジェクト環境に押しつけてしまった。アジャイルの柔軟性は受け取り手の裁量次第の技法として、ときに無秩序なプロジェクトが生まれ、また、他方では自身の環境とのミスマッチを無視し、アジャイルの方法論を厳守しようと苦痛が生まれた。それらが「アジャイルは死んだ」と言わねばいけないような、アジャイル「方法論」の閉塞につながったと言えるのではないだろうか。
アジャイル「方法論」の終焉の後は、何に向かうのか
では、アジャイル「方法論」に限界がきたというのであれば、どこに向かうのだろうか。アリスター・コーバーン氏は「方法論の終焉」で更に以下のように述べている。
そこで、私は、これら(Kanban/Scrum/Crystal)を、当面ここではこう呼ぶことを提案したい。ふりかえり改善フレームワーク
(Reflective Improvement Frameworks)
アリスター・コーバーン氏の関心は「一群のソフトウェア開発プロセス」ではなく「着実に改善していく組織状態の構築」に移っている。
ただ、そうなった場合、私は思うのである。もはやアジャイルもウォーターフォールかどうかなんて関係なくて、「改善」という方向で同じように歩むことが出来るのではないだろうか、と。その意味で改善やアジャイルの歴史に私は興味が移ったのであった。
トヨタ生産方式とアジャイルまでの系譜
改善といえばトヨタであるが、実はトヨタ生産方式とアジャイルはつながりがある。アジャイルまでの歴史を振り返っておこう。
まず、戦後の日本産業全体の隆盛に大きく寄与したデミング博士がいた。デミング博士と日本の出会いについては、こちらが詳しい。デミング博士は、社会人なら一度は習うであろう、あのPDCAのサイクル（後にはPDSA）や科学的手法の導入を説いた。現在の日本へ多大な影響を与えた偉人である。
日本産業の品質革命の波はトヨタ生産方式へと繋がる。トヨタ生産方式は1973年に社内のマニュアルとなり、1978年に大野耐一氏の著作として出版されている。そこにはムダの削減だけでなく、人間を中心とする思想が実現されている。
トヨタ生産方式で生産性を飛躍的にたかめた日本企業に対し、'85〜'90年代に米国から視察が盛んに行われ、それらがリーン生産方式として認知されていく。
生産の世界でアイアコッカ研究所でリーン生産方式を超えるものとしてアジャイルというキーワードが生まれた。生産の世界ではアジャイルは普及しなかったものの、リーン生産方式の影響をうけた方法論やプラクティス提唱者が集まり、2001年2月、ユタ州のスノーバードでアジャイル・マニフェストがまとめられる。
つまり、デミング氏、トヨタ生産方式、リーン、アジャイルは、それぞれが深く繋がっている。
その点、マーティン・ファウラー氏はアジャイル対リーンで以下のように述べている。
リーン生産とアジャイルソフトウェアには最初からつながりがあったのだ。 アジャイル手法の開発者は、いろいろな形でリーン生産から影響を受けている。
またアジャイルのフレームワークとして最も人気のあるスクラムを生み出したジェフ・サザーランドは著書スクラムの中でも大野耐一氏の影響を述べている。
スクラムが大野耐一の名著「トヨタ生産方式」に体系化されている生産方式から多くのヒントを得ていることは先に触れた。
デミング氏、大野耐一氏の思想はトヨタ生産方式にもアジャイルにも大きな影響を与えているのである。トヨタ生産方式、リーンの子がアジャイルなのである。
仕掛り品を減らすためTDDをする。未完了の部品ができないよう、スプリント内に作業をするなどの発想はアジャイルがリーン（トヨタ生産方式）から受けた影響であり、リーンとアジャイルの活動で見ると多くは重なり合う。
しかし、なぜ、アジャイルはリーンと分かれたのだろう？なぜ、リーンとなのらなかったのだろう。アジャイルを特徴づけたものは何だろうか。アジャイルの定義を振り返ってみよう。アジャイル・プラクティスでソフトウェア開発がアジャイルであることの定義が述べられている。
開発がアジャイルであるということは、協調性を重んじる環境で、フィードバックに基づいた調整を行い続けることである。
アジャイルはコミュニケーションと調整によって特徴づけられると思う。それはアリスター・コーバーンのアジャイルソフトウェア開発のベンガルトラの表紙に象徴される。
彼は表紙にチーターを選ばず、トラを選んだ。彼はチーターの最高速度を求めなかった。最高速度が重要なのではなく、顧客との対話を密に、チームのコミュニケーションを密にし、小回りで獲物を仕留める、それを表したいためのトラだとアリスター・コーバーンは説明している。
リーンでは重要とされたムダを削ぎ落とすことはアジャイルでは副次的となった。アジャイル・マニフェストにもムダの削減は直接現れていない。その背景思想となっているのである。
一方でトヨタ生産方式などのリーンは零戦のようなものだ。直接ムダを削ぎ落とし、研ぎ澄ます。その極限まで削ったプロセスを作りあげようという活動だ。その結果、最善の場合は小回りすら必要のないようになるだろう。それがリーンだ。
乱暴で正しくないかもしれないが、少し事例を考えよう。アジャイルではアドホックな文書を十分なだけ作成し、コミュニケーションによって補う。しかし、本当に最小限のドキュメントが見極められているなら、リーンであれば、その受け入れ基準まで含めて標準化しようとするだろう。
そうしてムダな会議や確認のためのコミュニケーションも必要がなくなる。工程の中の品質を高めておけばコミュニケーションもなく、自動的に進むことができる。リーンは、コミュニケーションも含めムダを削ぎ落としていく思想である。
Let's get back to the basics.
大野耐一氏は原典となった、トヨタ生産方式で基本思想を以下のように述べている。
トヨタ生産方式の基本思想は「徹底したムダの排除」である。
トヨタは日米の間に何倍もの生産性の差を感じ、このままでは生き残れないという、強烈な危機感をもとに ムダを徹底的に排除する、原価の低減こそが競争力の源泉だと見抜いた。現場の中でもがき、立ち向かった。（日本のソフトウェアも、そうありたいものだ。）
アジャイル方法論もウォーターフォールの中間生成物の多さを嘆き、生み出された。全体が大きなムダとなる前に小回りをして、ムダを削減しようというものだった。
ただ、アジャイル方法論で抜け落ちた観点があったのではないだろうか。アリスターの方法論の終焉より再掲しよう。
これまでに、列挙された役割や仕事の割り当て、用いるテクニック、そして相互作用の接点などが、分厚い教則として書かれてきた。それは多くの組織やプロジェクト、国、文化をまたいで、「一様に使われる」ことを想定していた。
このようなプロジェクト環境が存在することは稀だろう。プロジェクトごとに与えられた制約は異なる。トヨタ生産方式では現地現物を原則とするのに対し、一般にアジャイル方法論とよばれるものには夢想が含まれていたのではないだろうか。
そうであれば基本に帰ろう。どんなプロセスにもムダはある。リーンはそのムダを徹底的になくそうということであり、リーンはスクラムマスターも、スクラムオーナーも必要としない。現地現物からスタートできる。ムダの削減であれば、どの現場でも可能である。
身の丈に合わない環境をアジャイル方法論にあわせる必要はない。リーンにトヨタ生産方式へと回帰しよう。大野耐一氏のあの言葉に。
＞トヨタ生産方式の基本思想は「徹底したムダの排除」である。
リーンを実践するために
リーンソフトウェア開発を再評価する
ソフトウェア開発の中でリーンの考え方を実践する上で、トヨタ生産方式を読み解き、現地現物にあわせて問題を解決することは非常に多くの労力が必要であろう。その意味で前掲のトム＆メアリー・ポッペンディークの著書はソフトウェア開発者にとって大いに参考になるのではないだろうか。
リーンソフトウェア開発では以下の７つの原則が触れられている。
- ムダをなくす
- 品質を作り込む
- 知識を作り出す
- 決定を遅らせる
- 速く提供する
- 人を尊重する
- 全体を最適化する
そのうち、重要な原則の２つ、ムダをなくす、全体を最適化するという点の実践について触れていこうと思う。
ムダを発見する目をチームで養おう
トヨタの生産方式では７つのムダが定義されているが、メアリー&トム・ポッペンディークは、それらをソフトウェア開発に当てはめたムダをまとめている。とにかく言語化されないものは区別できない。ムダとは何かをチームメンバーで共有し、ムダを見つけられるようにするのは、改善の第一歩である。
特にチームメンバーが若く経験がない場合は、ムダの分類を教えるだけでなく、さらに具体例ではこういう場合であると噛み砕いて、共有をしていこう。そうすることで、自分の行動のここがムダなんだという理解や、こういったことはムダじゃないのかといった提案をメンバーとともに行うことができるだろう。
トヨタ生産方式での7つのムダ
| トヨタ生産方式のムダ | リーンソフトウェア開発のムダ | 例 |
|---|---|---|
| 在庫のムダ | 未完成の作業のムダ | コミットされていないコードの溜め込み 未確認の仕様書 動作チェックやテストされていないコード など完全に終わっていない状態で放置されているもの |
| 加工そのもののムダ | 余分なプロセスのムダ | 今までの慣例などで古いやり方を行っている 不必要なペーパーワーク |
| 作り過ぎのムダ | 余分な機能のムダ | 顧客の使わない機能 呼ばれないメソッド 不必要なデザインパターン |
| 運搬のムダ | タスク切り替えのムダ | 開発者がプロジェクトを掛け持ちしている 開発者が開発外の業務を行っている |
| 手待ちのムダ | 待ちのムダ | 人員配分が悪い クリティカルパス |
| 動作のムダ | 移動のムダ | 開発者が拠点を移動する 部屋の間を往復する 成果物を別の人に引き継ぐことで細かなノウハウが失われる |
| 不良をつくるムダ | 欠陥のムダ | 不具合のあるインターフェースにあわせて更に不具合を作る バグのチケットを締め切りまで放っておく ※欠陥を作ることもだが、隠れている期間もムダ |
発見したムダの解決を奨励する：デミング博士の意図に立ち返り、チームが生き生きするために
発見したムダを解決することを支援しよう。大きな組織では改善活動があるだろう。面倒くさいなと思っているかもしれない。ただ、その起源となったデミング博士の願いはあなたが生き生きと働くことであって、「改善ノルマ」のようなものではなかった。
その意図を受け継ぎ、改善は、あなたがより生き生きと働くことが出来ることを目的としよう。押し付けの改善の仕組みでは生き生きできないのであれば、生き生きできる仕組みを作ろう。
チームで発見したムダを解決できるよう、お互いを支援しよう。
全体最適を実現するアプローチ:トヨタの自工程完結
リーンソフトウェア開発では全体最適が原則の一つであるが、問題解決に最も重要な観点になると思う。それを最も体現しているのが自工程完結だと思うので取り上げたい。
前述のとおりトヨタ生産方式が海外に衝撃を与え、それがリーン思想をうみ、メアリー＆トム・ポッペンディーク氏らによりソフトウェア開発の世界へ展開された。その海外の流れは別として、トヨタはトヨタの中で自社のプロセスを磨き、自工程完結を生み出した。
自工程完結は、生産の各工程が責任をもって品質を確保することで、検査時に問題や不良を発生させないという考え方である。全体の工程の中で、きちんと各工程を定義を行い、その工程が果たすべき責務を完結させていく。完結した工程が連鎖ができれば、ムダが生じない。手戻りも発生しない。その状態を目指す活動である。製造だけでなく、スタッフ業務にも適用できる考え方だ。
自工程完結では、いちど全体を俯瞰し、その一つ一つの工程の役割を明確にして、工程内で完結させる。業務フロー図で業務全体を定義し、業務の要件整理シートで各工程に必要な品質水準を整理する。
業務フロー図
要件整理シート
これらのツールにより、必要な基準を満たす最小限のインプット、アウトプットを全体を見渡して決めることができる。バリューストリームマップも良さそうだけれど、全体最適を行う上では、こちらの方が優れた方法だと思う。
結果としてのアジャイル方法論、そこから先の進化
前に述べたとおり、アジャイルはリーンやトヨタ生産方式の影響を受けている。アジャイル方法論はリーンの一部を実現した姿といえる。たとえば、アジャイルに含まれるプラクティス、TDDは未完了の仕掛品を作成時点で減らそうという試みであり、スプリントという短期に区切り、その中でテストも含めて完了させる開発をするというのも同様である。
アジャイルはリーン生産方式に強く影響を受けて作られた方法論やプラクティスである。改善を行った結果として、あるアジャイル方法論に到達するというのは決してマグレではない。（一方でアジャイル方法論が現地現物を見ずに適用され、プロジェクトがデスマーチ化するなどは、その方法論の作者にとっても本意ではないだろうが。）
アジャイル方法論は、ある程度のムダが削除された状態と考えられる。改善手法を逐一生み出すことは非常に労力がかかるため、アジャイル方法論を一つの局所解として、アジャイル方法論を目指して改善する。いわば通過点として改善していくことで、改善にむけた労力を省くことができるだろう。
その意味で、先日のScrum Gathering Tokyo 2017で行われたプレゼンは素晴らしい発見だと思う。問題解決をする結果、スクラムになる、少しスクラムを意識して改善していくのが良いのではないかという見解だ。
アジャイル方法論にたどり着いたとしても終わりではない。リーンやトヨタ生産方式はスクラムにプロセスが到達したからといって、それを良しとしないだろう。もはやスクラムとは呼べなくなくなるような改善であっても、それをよしとするだろう。
マイクロソフトのサイトにある、リーンソフトウェアの説明の中ではアジャイルを超えたリーンについて説明している。
アジャイル方法論は一つの通過点で、その先を見据えていく、その関係は下のように描くことができるのではないだろうか。
黒岩惠氏はリーンやアジャイルの次について論じている。これもアジャイルなどの固定した方法論が一つの通過点であることを仰っているのだと思う。
本論の主題であるウォータフォール型からアジャイル型への転換だけに甘んじるのではなく、もっと積極的にシステム開発のコンピュータ化、自動化に取り組むべき
TPS/Lean/Agile手法だけに甘んじるな
最後に：本気の有無が改善の行く末を決める
自工程完結の中で佐々木眞一さんは自工程完結に取り組むリーダーの心構えとして以下のように触れている。問題は自工程完結をするぞといえば解決するようなことではないのだ。
長野県のある寺の住職から受けた"本気"の教えは今も心に深く刻まれている。そして、事あるごとにその教えに立ち返り、自らを奮い立たせている。短い文言なので紹介しよう。"本気"
本気ですれば大抵のことができる
本気ですれば何でもおもしろい
本気でしていると誰かが助けてくれる
誰かに助けてもらえるほど、本気で取り組まねば解決しないのはなんでも同じだろう。そのような心がけで取り組むか否かで改善の行く末は決まる。あがこう。
最後にまとめる。本稿で述べたのは以下のことだ。
- アジャイルはトヨタ生産方式（リーン）の影響を受けている。
- アジャイル方法論は、どちらかといえば落下傘アプローチであったが、現地現物という原則論からみた場合に、適合できない現場があることへの配慮が不足していたのではないか。
- ムダについてリーンソフトウェア開発はソフトウェア観点で多くのことを触れており再評価の価値がある。
- 自工程完結は全体最適を目指す上で取り入れることが有用である。
アジャイル方法論で表面をなぞるか、ムダ取りを着実に行っていくか、どちらにしろツラい道になることもあるだろう。だからこそ、ここまで理解した今現在は後者を選びたいものだ。
ある程度ムダ取りが進んだ場合に、アジャイル・マニフェストが目指した、あのキラキラしたアジャイル方法論の場所に到達することができるだろう。そして、アジャイル方法論で示された場所から先へもリーンの考え方であれば進んでいくことができるだろう。
会社のPDCAや改善活動もアジャイルも実は源流は実は同じあった。デミング博士はあなたが生き生きと働くことを望んでいた。そのための道具はリーンソフトウェア開発や自工程完結で触れられている。
いろいろ整理をするなかで、基本に戻ろう、デミング氏や大野耐一氏、リーンソフトウェア開発を再評価して、チームを改善していこう。私はこう感じた。このポエムがあなたのお役に立てることを願って本稿を終える。
0 コメント:
コメントを投稿