日本一ガラパゴス（独自進化）な企業のグローバル・スタンダード

アジャイル開発とトヨタ生産方式

はじめに

　ジェフ・サザーランド著『スクラム(仕事が4倍速くなる世界標準のチーム戦術)』で、ジェフはプロダクト・オーナーという役割は、トヨタのチーフエンジニアから発想を得たと記している。チーフエンジニアは、一つの製品ライン全体の責任を持つ，その為には各ラインにそれぞれ技術に精通したスタッフを集めておく必要がある。チーフエンジニアはこうした技術者の集団から機能横断的なチームを編成して車を生産できるチームを作る。

　社外から見るとトヨタの名高いチーフエンジニア制度といえば、強い権限を持って「トヨタ生産方式」を率いるリーダーのようにイメージするかもしれない。ある意味ではそうなのであるが、実際、チーフエンジニアには権限はない。直属の部下は持たず，逆に自身がチームに報告する義務がある。代わりに，どんな車にするかというビジョンと，その車をどう作るかを決める役割を担う。この決定を強制や圧力ではなく、説得を通じて行うのだ。スクラムで実現したいのはまさにこの考えだった。

　数ある要素の中でリーダーシップに特に重要なのは、知識とサーバントリーダーである事だろう。チーフエンジニアはただこうしろと指示を出せばいいのではない。メンバーを納得させ、うまくその気にさせて、自分が提案するやり方が正しくベストなやり方だという事を示さなければならない。普通ならその道で30年くらいの経験がなければ務まらない役割だ。これをスクラムに取り入れようと考えたが、相当する経験とスキルを備えた人はなかなかいない。そこでこの役割を二つに分け、仕事の進め方をスクラムマスターが、仕事の内容をプロダクトオーナーが管理する分担制にした。

　またケント・ベック著『エクストリーム・プログラミング』でケントは、こう記している。TPSの多くの側面は、ソフトウエア開発との強い類似性がある。たとえば作業者の多能工化、工場のセル化、顧客とサプライヤー間の利益配分契約の作成などは、いずれも役に立つ考え方だ。興味があれば、まずは大野耐一氏の著書「トヨタ生産方式」を読んでみるといいだろう。これらの記述のようにTPSとアジャイル開発の代表的な手法であるスクラムとXPは発案者が強くトヨタ生産方式に影響を受けており、その考え方をソフトウエア開発に適用している。

　ならばもっとソフトウエア開発に携わる人々は、トヨタ生産方式(TPS)について学ぶべきである。TPSの価値観、手法を学びアジャイル開発に取り組むことで、真に成果の挙げられるソフトウエア開発が実現する。更にアジャイル開発でプロダクトの成功を左右する自律した(自己組織化された)開発者、チームを育成する為には、トヨタ生産方式(TPS)のコア(基本的な仕事への取り組み方)であるTMSが、チームビルディングに最も有益である。

　このホワイトペーパーは、ソフトウエア開発に関わる関係者に正しくTPSを理解しその価値観、手法の使用目的、価値を吟味できる一助となる事を期待している。

　2008年に筆者は、スクラム・アライアンスの認定スクラムマスターを得てから幾多のアジャイル開発プロジェクトの指導をしてきた。この間、筆者が強く意識していたのがTPSであった。理由は、アジャイルを学び始めて欧米のアジャイル紹介本を読み漁った時に、一つの言葉が、筆者の脳裏に焼き付いて離れなかった。それはアジャイル紹介本の「はじめに」で出合った「TPSに学んだ」「トヨタに学んだ」と言う言葉である。

　以来、筆者はTPSの考え方を独習し、スクラムでの開発プロジェクトで、何度もトライして来た。不遜にも2010年頃より「TPSアジャイル」を標榜してTPSで紹介されている製造業の考え方をソフトウエア開発の世界でどの様に実現できるか？改良を加えてきた。またトヨタOBの方に筆者が指導していた生産管理システムのプロジェクトを見て頂き、TPSの観点からみてこのスクラム・チーム、スクラムのプロジェクトの進め方についてご意見を頂く、貴重な機会を得た。その時のトヨタOBの方のコメントが筆者のアプローチに対して間違った方向ではない事を強く自信を得た。以来、アジャイル開発のプロジェクトは、スクラムとXPを基本とした手法を取り入れ、プロジェクト運営の基本は、TPSの『一個流し』を強く意識して開発プロセスの整流化をどの様に実現するか？を追及して来た。今でも、この考え方は、間違っていなかったと強い確信を持っている。

　冒頭で紹介したジェフ・サザーランドやケント・ベックの最近の著書からも、TPSの考え方をアジャイル開発に取り入れて誤りではない事が解った。このホワイトペーパーは、これからアジャイル開発に取り組む方、既にアジャイル開発に取り組まれて、アジャイルの効果を十分に得られていない方々に読んで頂きたいという思いで書いた。必ずや品質の高い、柔軟な、そして真にユーザーに評価される、透明性の高いプロジェクト運営での自律したチームによるソフトウエア開発の一助となると期待している。

TPSとは？その目指すモノ

　Win-Win-Win。 お客様の幸せ-企業(経営サイド)の幸せ-社員(作業者)の幸せという三方丸く収ま

る仕事の仕方にある。その基本的価値観は、開発、製造プロセスの整流化であるが、TOC（ゴ

ールドラッドの制約理論）とは同じ整流化を目指してもそのアプローチ方法が異なる。大野耐一氏（元トヨタ副社長）が説く整流化のアプローチは、とことん作業単位を小さく分解して、一個づつ仕事を流して全プロセスを停滞させる事なく流せるようにすることによって、ボトルネックを発生させない整流化である。19世紀の産業革命以降我々は、大量生産の仕組みに慣れ親しんできた。無意識のうちに仕事をまとめて処理する方が効率的であると考えている。

　したがって仕事のプロセスもその様にまとめて処理する仕組みを洗練させてきた。トヨタのTPSはこの考えと真逆の発想である。仕事は一つずつ処理した方が、多様化した現代では効率的である事を示している。彼らの業績がそれを証明している。TPSの基本は、「ジャストインタイム」と「自働化」であると大野耐一氏は、彼の著書（トヨタ生産方式）で述べているが、ジャストインタイムと自働化の基本コンセプトを実現する先の目的は、一個流しによる生産の柔軟性の確保と、資金の早期回収による回転率経営だと筆者は理解している。

　この一個流しでの仕事の進め方を追及する上で、TPSで紹介されているカンバン、大部屋方式等の各種手法や後工程引き取りや、ムダ取り＆改善、自工程完結等の考え方が存在する。したがって読者に強く意識して頂きたいのは、これらの手法や、考え方に飛びつく前に、その狙い、目的等全体最適での自身のプロセスの整流化について思考を巡らせて貰いたい。その上での手法や考え方である。

　ソフトウエア開発の現場で考えると、この『一個流し』と言う事は、機能する（働く）ソフトウエアを一機能づつ作成してリリースを行い、インクリメンタルにシステムを構築していくアジャイル開発に他ならない。またこのような仕組みで製品を作るプロセスを滞りなく運用する上で、作業者が遣らされ感が無く自律的に行動できる多能工のチームが必須となる。これもTPSでもアジャイル開発でも同様に自律した社員、自己組織化されたチームと言う表現で述べられている。TPSとアジャイルの深い、そして強い関連性を理解いただけたと思う。

それではアジャイル開発、ここではスクラムとXPを中心にTPSの側面から見ていきたいと思う。

１．ジャストインタイム

　このジャストインタイムと言う考え方にはソフトウエア開発では二通りの意味がある。一つはTPSオリジナルの考え方であるお客様（ユーザー）のビジネス・ニーズに合わせたシステムのリリースと言う意味と、開発現場の方々には理解しやすいと思うが、プログラムを書いた時点にできるだけ近い時間に修正を掛ける方が、時間が経って修正を行うよりも作業効率が高いという事である。

　そういう意味で修正をできるだけ開発直後にジャストインタイムで行う事である。また頻繁なリリースによるユーザーからのフィードバックがソフトウエアの品質の向上やユーザー要望への対処として有効である。

　従ってスクラムやXPで言われる頻繁なリリースによるフィードバックが重要な意味を持ってくる。またこのように頻繁なリリースを実現する上でイテレーション（スプリント）と言う一定期間のタイムボックスでの開発作業の意味があるので、イテレーションをむやみに長く取る事は、得策ではない。

　筆者の経験から言えばイテレーションはXP同様に1週間のスプリント（イテレーション）が望ましい。

２．自働化

　自働化とは、プロセスの中に人間の知恵を埋め込み、自動的に不具合が発生した時点で、全てのプロセスを停止させる考え方である。

スクラムで言う所の常時インテグレーション（継続的インテグレーション）や、XPで提唱されている10分間ビルドと言った手法は、この自働化の為のプラクティスである。

　TPSでは行灯の仕組みとその考え方である。何かプロセスの中で不具合や問題が発生したならば、全プロセスの作業を中断してチーム全員でその解決に当たる姿勢が重要である。そのためにアジャイルでは常に自動化して短期間でビルドを作成し、継続的インテグレーションのテストを毎日実施する仕組みを構築している。

４．現地現物

　アジャイル宣言の中で『包括的なドキュメントよりも、働くソフトウエアを』という考えは、TPSでの現地現物そのものである。全ては現地(現場)で現物を見てその事実で判断するという事である。したがってアジャイル開発での進捗を見る基本姿勢は出来た（完了基準を満たした）プログラムの本数で管理している。要は働くソフトウエアでの管理であり、DoD（完了基準）をチームでしっかり定義して、その基準を自らが順守することが自律したチームである。

　これによって、開発プロジェクトの進捗の透明性が担保され、ユーザーから信頼されるチームへと成長していける。また管理者もプロジェクト・ルームに足を運び現場で見る事がどの様な進捗レポートよりも正しい判断ができる。更に、ソフトウエア開発プロジェクトでの作業標準もこのような考え方から、現場（開発チーム）で作りその標準を振り返りを繰り返して高めていく事が現場（開発チーム）に求められる。

５．稼働率より可動率（べきどうりつ）

　稼働率とは、ある一定時間内での正味の仕事に費やした時間の割合だが、可動率(べきどうりつ)とは、仕事が到着した時点での、即座にその正味の仕事(作業)に取り掛かれる数の割合(全仕事数に対する割合)である。

　タスクをとったら即座に作業(仕事)に掛かれるのか？という事が可動率(べきどうりつ)というTPSの考え方である。プロセスの整流化にとっては、この可動率（べきどうりつ）が重要な要素になる。この可動率（べきどうりつ）を向上させる為には、有名な５Ｓ（整理、整頓、清掃、清潔、躾）と仕事を小さく分解する事が重要である。

　タスクボードに貼られているタスクの記述がこのように明瞭な表現で記述されているか？もチームとしての改善テーマとなりえる。

６．自律した(自己組織化された)チームと管理者

　自律したチームとは、TPSで言う所のプロセスに自律神経を埋め込むことに他ならない。自律神経を埋め込むとはどういうことか？問題や不良を発見したら、直ちに全てのプロセスを停止させる事である。この権限は現場が持っている。

　一方、管理者の仕事は部下の仕事の管理では無くプロセスの流れを作ることである。

それは、全てのプロセスに渡って、ボトルネックを排除して、仕掛かりを残さず整流化させる事である。この整流化のアプローチには、リーンプロダクションの理論的バックボーンであるTOC(制約理論;ゴールドラット)でのドラムバッファーロープとTPS（トヨタ生産方式）の一個流しという考え方のふた通りがあるが、TPS（トヨタ生産方式）での一個流しのアプローチの方が普遍的である。

　この考えを適用する為には改善の努力が求められる。スクラムやXPでは、TPSの一個流しの考え方に影響を受けているが、一方KANBAN（D.J.アンダーソン）はTOC（制約理論）の考え方を採用している。

　自律したチームを育成することは、大変難しい。ではどの様にしてこのようなチームを作る事ができるのか？はTPSの基本的価値観（コア）としてのTMSが大変役に立つ。TMSの改善塾で実施するチームビルディングの考え方は、具体的なチームビルディングの方法を提示しているし、この活動によってスクラム・プロジェクトの成功に重要な部分を占めるレトロスペクティブ（振り返り）の品質を向上する事が出来る。

　また、この様な開発チームを支援（育成）するためにもスクラムマスターや管理者にはサーバントリーダーシップ（下支えのリーダー）が要求される。更に現場のチーム、管理者がそろって「流れを作る（全体最適）」を自覚して取り組むことがアジャイル開発や、その後に続く継続的デリバリー（ＣＤ）やDevOpsでは基礎的条件となる。

７．自工程完結

　XPの手法であるTDD（テスト駆動開発）は自工程完結をソフトウエア開発で適用する上での有益な手法である。この考え方は不良を作らない、不良作業をしない。不良を次のプロセスに流さない。前のプロセスでの作業の不良を受けたらない。と言うTPSのジャストインタイムでの一個流しを実現する為の考え方である。自ら定めたDoDの完了基準をしっかりと守って不良作業をしない、不良品（バグ）を貯めないと言うチーム全員の意識統一が必要である。

８．カンバン

　ＴＰＳでは、後工程引き取り（プル型）のオペレーションの手法として利用されているがアジャイル開発で言うタスクボードは基本的に同様なオペレーションにしなければ、カンバンの効果を発揮しない。失敗しているアジャイルチームで見かける光景として、タスクボードのタスクを一日の開始時に今日の自分の予測で数個のタスクをまとめて取っている様子を見かけるが、このタスクのとり方では、後工程引き取りと言うＴＰＳの考え方から逸脱したオペレーションになり、一個流しを追求する事は不可能である。タスクは一つ作業が完了したならば、次のタスクをタスクボードへ取りに行くと言うオペレーションをチーム内全員でしっかりと守る事が重要である。

９．タクトタイム

　ＴＰＳでのタクトタイムとは、ある作業を実施する上での標準的な作業時間と捉えられているが、真の狙いは、作業時間を短縮する事では無い。作業のリズムを作る上でのタクトタイムである。ソフトウエア開発の現場で考えると、チームのメンバーが小気味よいリズムで作業に取り組める様にすることである。

　大野耐一氏も述べているが作業に一定のリズム感を持つことで、人間は集中力を高められる。しかたって、ポカミスなども防止できムダ取りの基本原則であるムラ、ムリ、ムダ（作業にムラが出るから、そのムラを取り戻そうとしてムリを強いる。ムリを強いれば、結果としてムダが発生する。）のおおもとである作業のムラ取りが出来る。

　この開発チームのリズムを作る上で、大事な点は、タスクの粒度を均一化する事も大きい。

タスクの粒度が大小まちまちであると、開発チームが共同して作業を進めていくうえで、手待ちのムダも起こるが、やはり作業のリズム感も損なわれ、集中力を高める事が困難になる。

　リズムと言う意味では、スクラムの手法であるスタンドアップ・ミーティングも同様な効果を得られる。一日の作業の開始時にスタンドアップ・ミーティングを実施する事で、チームとしての一日のリズムを刻むスタートポイントにできる。

１０．振り返り（レトロスペクティブ）

　スクラムの手法での振り返り（レトロスペクティブ）はＴＰＳの中でも良く見られる改善活動に他ならない。開発チームの作業ペース（イテレーション）にもよるが、基本的には毎週決まった時間帯で振り返りを実施する事で、先週からの改善や自身やチームの成長を確認する事が出来る重要な場である。

　この振り返りではＫＰＴボードが良く利用されているが、ＫＰＴボードはプロジェクトに一つと考える必要はない。チームとして色々な改善テーマが出てくると思うが、それぞれの目的に応じたＫＰＴボードを作成すべきである。

　例えば、プロダクト制作に関わるプロジェクトのＫＰＴ，品質を向上させるＫＰＴ、開発チーム・ビルディングの為のＫＰＴ、中にはＫＰＴをしっかり廻す為のＫＰＴ等有っても良い。スクラムではスプリント・レビューと同時にレトロスペクティブを実施すると言って居るが、筆者の経験では、スプリントの期間と関係なく毎週実施される事を薦める。理由は、人間それほど多くの事を覚えていない。せめて一週間程度であれば、何をしたか思い出せる。

１１．一個流し

　ＴＰＳでは大野耐一氏は、整流化するために仕事を出来るだけ小さな単位に分解する事と、平準化をする事が重要だと説いている、平準化すれば多様化を支援するとも言っている。ならばソフトウエア開発の現場では、これはどの様に取り組むべきものであろうか？一寸考えて頂きたい。取りも直さずソフトウエア開発現場では、スクラムのスプリントバックログ（通称タスク）の粒度を出来るだけ小さく、また均一化させる事である。言葉で言うは易いが、実際チームでタスク出しを行うとなかなか難しい課題である。

　従来のＷＢＳの様な目的の記述では、タスク粒度を小さくすることはできない。タスクを小さくする方法は、制作する目的を実現するための作業手順に分解する事である。こうすればタスクは小さくでき、筆者の経験では1時間（60分） のタスクに分解可能である。

　またこのような基準でタスクを分解すれば、タスク粒度の均一化もできる。この努力によって、作業の平準化も実現できる。タスク粒度を小さく、均一化する為のＫＰＴをチームで廻すと良い。

１2．大部屋方式

　トータルＴＰＳでは、管理の異なる仕事（部門）間でプロセスの整流化を実現する方法として大部屋方式が紹介されている。これはＩＴの分野で見ると、企画～開発～運用の全てのプロセスでＡＬＭ視点での一気通貫での見える化であり、全プロセスでの整流化である。ＩＴ業界用語で表現すればDevOps（ＣＤ；継続的デリバリー）そのものである。

　DevOpsに取り組むのであれば、トヨタのこの大部屋方式は具体的な手法として利用価値が高い。この大部屋方式を導入する事によって、全てのプロセスに渡って見える化し、全体のプロセスを滞りなく流す整流化を実現する。結果としてはジャストインタイムでのＩＴサービスの提供というDevOpsの目的を達成できる。

１3．先行改善

　トータルＴＰＳでの先行改善と言う事は下流工程から上流工程へ改善要望を提案する事である。スクラムで言うと、開発チームからプロダクト・オーナーへプロダクト・バックログの修正等良いシステムを作る上で有益な提案をする事である。

　スクラムでも記述されているが、プロダクト・バックログはユーザーばかりでは無くプロジェクト関係者誰でも提案できる。成功しているスクラムチームは、開発チームからの活発なプロダクトバックログへの提案がなされている。

おわりに

　如何でしょうか？アジャイル開発特にスクラム、ＸＰとトヨタ生産方式（ＴＰＳ）との強い類似性を確認して頂けたしょうか？アジャイル開発に取り組まれる方々には、トヨタ生産方式を学んで、良くその目的、考え方を理解できると、スクラムやＸＰでの手法（プラクティス）の価値、目的を正しく理解できる様になります。アジャイル開発プロジェクトで真にユーザーに評価されるチームを目指すのであれば、トヨタ生産方式（ＴＰＳ）が大前提となります。

　アジャイル開発の紹介をしている際に、良く聞かれる話だが、アジャイル開発に向いた適用業務や適したプロジェクトの大きさ等が初心者から話題になる。このホワイトペーパーで紹介してきた通りこのスクラムやＸＰの手法や考え方は10兆円企業のトヨタの生産現場で日々実施されている手法や考え方をソフトウエア開発の現場に導入している物であるので、上述の様な疑問は不要である。

　スクラムやＸＰの考え方、手法の意味を正しく理解して、アジャイル開発に取り組めば、どの様な適用業務や規模にも適用可能である事を、トヨタの事例が示している。大事な事は、トヨタの代名詞にもなっている「なぜ、なぜを5回以上繰り返して問い」、ものごとの本質や真因を掴む姿勢が成功への近道でもある。

　是非、ソフトウエア開発の現場で『一個流し』のプロセスを確立し、そのプロセスの整流化を追求していけば、おのずとお客様（ユーザー）に評価されるアジャイル開発での成功が見えてくる。

　最後に、『トヨタ生産方式』の著者である大野耐一氏の言葉を紹介します。

『私どもとして、これだけトヨタ生産方式に関心を寄せてくださることは結構なことであり、ありがたいことだと考えています。しかししだいに注目され、国内の各業界でも研究されていくうちに、一部では誤解されたり、あるいは都合のよい部分だけを濫用されているところもあるように聞いています。

　その端的な例は、トヨタ生産方式すなわち‘“かんばん方式”であるという短絡したものです。そもそも「かんばん」とはトヨタ生産方式の運用手段の一つであり、「かんばん」を採用したから、それだけで生産性が向上すると言うものではありません。』

株式会社戦略スタッフ・サービス　代表取締役

社団法人ＴＰＳ検定協会　理事

戸田　孝一郎

【参照文献】

• トヨタ生産方式　ー脱規模の経営を目指してー　

大野耐一著（ダイヤモンド社刊）

• スクラム　ー仕事が4倍速くなる“世界標準”のチーム戦術　

ジェフ・サザーランド著（早川書房刊）

• エクストリームプログラミング　（第２版）　

ケント・ベック、シンシア・アンドレス共著（オーム社刊）

• トヨタ流の教科書　企業編ー世界最強のものづくりの秘密―　

堀切俊雄著（日経ＢＰ社、日経ものづくり刊）

• トヨタ流の教科書　ＴＭＳ編　

高木徹著（日経ＢＰ社、日経ものづくり刊）