日本一ガラパゴス(独自の進化)な企業のグローバル・スタンダード (アジャイル開発とトヨタ生産方式) はじめに ジェフ・サザーランド著『スクラム(仕事が 4 倍速くなる世界標準のチーム戦術)』で、ジェフ はプロダクト・オーナーという役割は、トヨタのチーフエンジニアから発想を得たと記してい る。チーフエンジニアは、一つの製品ライン全体の責任を持つ，その為には各ラインにそれぞ れ技術に精通したスタッフを集めておく必要がある。チーフエンジニアはこうした技術者の集 団から機能横断的なチームを編成して車を生産できるチームを作る。社外から見るとトヨタの 名高いチーフエンジニア制度といえば、強い権限を持って「トヨタ生産方式」を率いるリーダ ーのようにイメージするかもしれない。ある意味ではそうなのであるが、実際、チーフエンジ ニアには権限はない。直属の部下は持たず，逆に自身がチームに報告する義務がある。代わり に，どんな車にするかというビジョンと，その車をどう作るかを決める役割を担う。この決定 を強制や圧力ではなく、説得を通じて行うのだ。スクラムで実現したいのはまさにこの考えだ った。 数ある要素の中でリーダーシップに特に重要なのは、知識とサーバントリーダーである事だろ う。チーフエンジニアはただこうしろと指示を出せばいいのではない。メンバーを納得させ、 うまくその気にさせて、自分が提案するやり方が正しくベストなやり方だという事を示さなけ ればならない。普通ならその道で 30 年くらいの経験がなければ務まらない役割だ。これをス クラムに取り入れようと考えたが、相当する経験とスキルを備えた人はなかなかいない。そこ でこの役割を二つに分け、仕事の進め方をスクラムマスターが、仕事の内容をプロダクトオー ナーが管理する分担制にした。 またケント・ベック著『エクストリーム・プログラミング』でケントは、こう記している。 TPS の多くの側面は、ソフトウエア開発との強い類似性がある。たとえば作業者の多能工化、 工場のセル化、顧客とサプライヤー間の利益配分契約の作成などは、いずれも役に立つ考え方 だ。興味があれば、まずは大野耐一氏の著書「トヨタ生産方式」を読んでみるといいだろう。 これらの記述のように TPS とアジャイル開発の代表的な手法であるスクラムと XP は発案者が 強くトヨタ生産方式に影響を受けており、その考え方をソフトウエア開発に適用している。 ならばもっとソフトウエア開発に携わる人々は、トヨタ生産方式(TPS)について学ぶべきであ る。TPS の価値観、手法を学びアジャイル開発に取り組むことで、真に成果の挙げられるソフ トウエア開発が実現する。更にアジャイル開発でプロダクトの成功を左右する自律した(自己組 Strategic Staff Services Corporation 1 織化された)開発者、チームを育成する為には、トヨタ生産方式(TPS)のコア(基本的な仕事への 取り組み方)である TMS が、チームビルディングに最も有益である。 このホワイトペーパーは、ソフトウエア開発に関わる関係者に正しく TPS を理解しその価値 観、手法の使用目的、価値を吟味できる一助となる事を期待している。 2008 年に筆者は、スクラム・アライアンスの認定スクラムマスターを得てから幾多のアジャイ ル開発プロジェクトの指導をしてきた。この間、筆者が強く意識していたのが TPS であった。 理由は、アジャイルを学び始めて欧米のアジャイル紹介本を読み漁った時に、一つの言葉が、 筆者の脳裏に焼き付いて離れなかった。それはアジャイル紹介本の「はじめに」で出合った 「TPS に学んだ」「トヨタに学んだ」と言う言葉である。以来、筆者は TPS の考え方を独習 し、スクラムでの開発プロジェクトで、何度もトライして来た。不遜にも 2010 年頃より 「TPS アジャイル」を標榜して TPS で紹介されている製造業の考え方をソフトウエア開発の 世界でどの様に実現できるか？改良を加えてきた。またトヨタ OB の方に筆者が指導していた 生産管理システムのプロジェクトを見て頂き、TPS の観点からみてこのスクラム・チーム、ス クラムのプロジェクトの進め方についてご意見を頂く、貴重な機会を得た。その時のトヨタ OB の方のコメントが筆者のアプローチに対して間違った方向ではない事を強く自信を得た。 以来、アジャイル開発のプロジェクトは、スクラムと XP を基本とした手法を取り入れ、プロ ジェクト運営の基本は、TPS の『一個流し』を強く意識して開発プロセスの整流化をどの様に 実現するか？を追及して来た。今でも、この考え方は、間違っていなかったと強い確信を持っ ている。冒頭で紹介したジェフ・サザーランドやケント・ベックの最近の著書からも、TPS の 考え方をアジャイル開発に取り入れて誤りではない事が解った。このホワイトペーパーは、こ れからアジャイル開発に取り組む方、既にアジャイル開発に取り組まれて、アジャイルの効果 を十分に得られていない方々に読んで頂きたいという思いで書いた。必ずや品質の高い、柔軟 な、そして真にユーザーに評価される、透明性の高いプロジェクト運営での自律したチームに よるソフトウエア開発の一助となると期待している。 TPS とは？その目指すモノ。 Win-Win-Win。 お客様の幸せ-企業(経営サイド)の幸せ-社員(作業者)の幸せという三方丸く収ま る仕事の仕方にある。その基本的価値観は、開発、製造プロセスの整流化であるが、TOC（ゴ ールドラッドの制約理論）とは同じ整流化を目指してもそのアプローチ方法が異なる。大野耐 一氏（元トヨタ副社長）が説く整流化のアプローチは、とことん作業単位を小さく分解して、 一個づつ仕事を流して全プロセスを停滞させる事なく流せるようにすることによって、ボトル Strategic Staff Services Corporation 2 ネックを発生させない整流化である。19 世紀の産業革命以降我々は、大量生産の仕組みに慣れ 親しんできた。無意識のうちに仕事をまとめて処理する方が効率的であると考えている。した がって仕事のプロセスもその様にまとめて処理する仕組みを洗練させてきた。トヨタの TPS は この考えと真逆の発想である。仕事は一つずつ処理した方が、多様化した現代では効率的であ る事を示している。彼らの業績がそれを証明している。TPS の基本は、「ジャストインタイ ム」と「自働化」であると大野耐一氏は、彼の著書（トヨタ生産方式）で述べているが、ジャ ストインタイムと自働化の基本コンセプトを実現する先の目的は、一個流しによる生産の柔軟 性の確保と、資金の早期回収による回転率経営だと筆者は理解している。この一個流しでの仕 事の進め方を追及する上で、TPS で紹介されているカンバン、大部屋方式等の各種手法や後工 程引き取りや、ムダ取り＆改善、自工程完結等の考え方が存在する。したがって読者に強く意 識して頂きたいのは、これらの手法や、考え方に飛びつく前に、その狙い、目的等全体最適で の自身のプロセスの整流化について思考を巡らせて貰いたい。その上での手法や考え方であ る。 ソフトウエア開発の現場で考えると、この『一個流し』と言う事は、機能する（働く）ソフト ウエアを一機能づつ作成してリリースを行い、インクリメンタルにシステムを構築していくア ジャイル開発に他ならない。またこのような仕組みで製品を作るプロセスを滞りなく運用する 上で、作業者が遣らされ感が無く自律的に行動できる多能工のチームが必須となる。これも TPS でもアジャイル開発でも同様に自律した社員、自己組織化されたチームと言う表現で述べ られている。TPS とアジャイルの深い、そして強い関連性を理解いただけたと思う。 それではアジャイル開発、ここではスクラムと XP を中心に TPS の側面から見ていきたいと思 う。 １． ジャストインタイム このジャストインタイムと言う考え方にはソフトウエア開発では二通りの意味がある。 一つは TPS オリジナルの考え方であるお客様（ユーザー）のビジネス・ニーズに合わせた システムのリリースと言う意味と、開発現場の方々には理解しやすいと思うが、プログラ ムを書いた時点にできるだけ近い時間に修正を掛ける方が、時間が経って修正を行うより も作業効率が高いという事である。そういう意味で修正をできるだけ開発直後にジャスト インタイムで行う事である。また頻繁なリリースによるユーザーからのフィードバックが ソフトウエアの品質の向上やユーザー要望への対処として有効である。従ってスクラムや XP で言われる頻繁なリリースによるフィードバックが重要な意味を持ってくる。またこ のように頻繁なリリースを実現する上でイテレーション（スプリント）と言う一定期間の Strategic Staff Services Corporation 3 タイムボックスでの開発作業の意味があるので、イテレーションをむやみに長く取る事 は、得策ではない。 筆者の経験から言えばイテレーションは XP 同様に 1 週間のスプリント（イテレーショ ン）が望ましい。 ２．自働化 自働化とは、プロセスの中に人間の知恵を埋め込み、自動的に不具合が発生した時点で、 全てのプロセスを停止させる考え方である。 スクラムで言う所の常時インテグレーション（継続的インテグレーション）や、XP で提 唱されている 10 分間ビルドと言った手法は、この自働化の為のプラクティスである。 TPS では行灯の仕組みとその考え方である。 何かプロセスの中で不具合や問題が発生したならば、全プロセスの作業を中断してチーム 全員でその解決に当たる姿勢が重要である。そのためにアジャイルでは常に自動化して短 期間でビルドを作成し、継続的インテグレーションのテストを毎日実施する仕組みを構築 している。 ３．無駄をなくす。 無駄には 7 つのムダあると言われている。それは、 1 つくりすぎのムダ 2 手待ちのムダ 3 運搬(コミュニケーション)のムダ 4 加工そのもの(作業)のムダ 5 在庫のムダ(文書、ドキュメント) 6 動作のムダ(手戻り、手直し) 7 不良をつくるムダ この考え方は製造業の生産現場ばかりでは無く、ソフトウエア開発にもそのまま当てはまる。 従来からのウォーターフォール開発に対してアジャイル開発がその価値を問うた基本的価値観 （アジャイル・マニフェスト）でもこの考え方が組み込まれている事がうかがえる。 作りすぎのムダはとりもなおさず使われないコードを作成する事や、一時的にしか参照されな い文書類を作成する事であり、手待ちのムダは開発の各ステップ（プロセス）での他者の作業 待ち、承認待ちと言った時間である。運搬のムダはプロジェクト関係者間のコミュニケーショ ン・ロスなど良く見受けられる。加工そのもののムダは開発の正味作業時間を侵食する会議 （進捗会議）等最終システムとして価値を生まない作業時間である。在庫のムダは、開発途中 Strategic Staff Services Corporation 4 で作成される各種文書（資料）類等がある。動作のムダは頻繁にソフトウエア開発作業現場で 見受けられる手戻り作業その物である。不良を作るムダは、充分にテストされずまた、安易に 将来のシステムテストを期待して起こるバグそのものである。 このようなムダを改善しながらソフトウエア開発プロジェクトを通してチームが成長し、ユー ザーの変更要求を受け入れながら、ビジネスを支援する現実的なシステムを構築していく考え 方がアジャイルの基本ではないだろうか？手法ありきでは無く、何故その手法を利用するとユ ーザーの要望にジャストインタイムで適応できる様になるのか？を常にチームは考える必要が ある。 ４．現地現物 アジャイル宣言の中で『包括的なドキュメントよりも、働くソフトウエアを』という考えは、 TPS での現地現物そのものである。全ては現地(現場)で現物を見てその事実で判断するという 事である。したがってアジャイル開発での進捗を見る基本姿勢は出来た（完了基準を満たし た）プログラムの本数で管理している。要は働くソフトウエアでの管理であり、DoD（完了基 準）をチームでしっかり定義して、その基準を自らが順守することが自律したチームである。 これによって、開発プロジェクトの進捗の透明性が担保され、ユーザーから信頼されるチーム へと成長していける。また管理者もプロジェクト・ルームに足を運び現場で見る事がどの様な 進捗レポートよりも正しい判断ができる。更に、ソフトウエア開発プロジェクトでの作業標準 もこのような考え方から、現場（開発チーム）で作りその標準を振り返りを繰り返して高めて いく事が現場（開発チーム）に求められる。 ５．稼働率より可動率（べきどうりつ） 稼働率とは、ある一定時間内での正味の仕事に費やした時間の割合だが、可動率(べきどうり つ)とは、仕事が到着した時点での、即座にその正味の仕事(作業)に取り掛かれる数の割合(全仕 事数に対する割合)である。 タスクをとったら即座に作業(仕事)に掛かれるのか？という事が可動率(べきどうりつ)という TPS の考え方である。プロセスの整流化にとっては、この可動率（べきどうりつ）が重要な要 素になる。この可動率（べきどうりつ）を向上させる為には、有名な５Ｓ（整理、整頓、清 掃、清潔、躾）と仕事を小さく分解する事が重要である。 タスクボードに貼られているタスクの記述がこのように明瞭な表現で記述されているか？もチ ームとしての改善テーマとなりえる。 Strategic Staff Services Corporation 5 ６．自律した(自己組織化された)チームと管理者 自律したチームとは、TPS で言う所のプロセスに自律神経を埋め込むことに他ならない。 自律神経を埋め込むとはどういうことか？問題や不良を発見したら、直ちに全てのプロセスを 停止させる事である。この権限は現場が持っている。 一方、管理者の仕事は部下の仕事の管理では無くプロセスの流れを作ることである。 それは、全てのプロセスに渡って、ボトルネックを排除して、仕掛かりを残さず整流化させる 事である。この整流化のアプローチには、リーンプロダクションの理論的バックボーンである TOC(制約理論;ゴールドラット)でのドラムバッファーロープと TPS（トヨタ生産方式）の一個 流しという考え方のふた通りがあるが、TPS（トヨタ生産方式）での一個流しのアプローチの 方が普遍的である。この考えを適用する為には改善の努力が求められる。スクラムや XP で は、TPS の一個流しの考え方に影響を受けているが、一方 KANBAN（D.J.アンダーソン）は TOC（制約理論）の考え方を採用している。 自律したチームを育成することは、大変難しい。ではどの様にしてこのようなチームを作る事 ができるのか？は TPS の基本的価値観（コア）としての TMS が大変役に立つ。TMS の改善塾 で実施するチームビルディングの考え方は、具体的なチームビルディングの方法を提示してい るし、この活動によってスクラム・プロジェクトの成功に重要な部分を占めるレトロスペクテ ィブ（振り返り）の品質を向上する事が出来る。 また、この様な開発チームを支援（育成）するためにもスクラムマスターや管理者にはサーバ ントリーダーシップ（下支えのリーダー）が要求される。更に現場のチーム、管理者がそろっ て「流れを作る（全体最適）」を自覚して取り組むことがアジャイル開発や、その後に続く継 続的デリバリー（ＣＤ）や DevOps では基礎的条件となる。 ７．自工程完結 XP の手法である TDD（テスト駆動開発）は自工程完結をソフトウエア開発で適用する上での 有益な手法である。この考え方は不良を作らない、不良作業をしない。不良を次のプロセスに 流さない。前のプロセスでの作業の不良を受けたらない。と言う TPS のジャストインタイムで の一個流しを実現する為の考え方である。自ら定めた DoD の完了基準をしっかりと守って不良 作業をしない、不良品（バグ）を貯めないと言うチーム全員の意識統一が必要である。 ８．カンバン ＴＰＳでは、後工程引き取り（プル型）のオペレーションの手法として利用されているがアジ ャイル開発で言うタスクボードは基本的に同様なオペレーションにしなければ、カンバンの効 果を発揮しない。失敗しているアジャイルチームで見かける光景として、タスクボードのタス Strategic Staff Services Corporation 6 クを一日の開始時に今日の自分の予測で数個のタスクをまとめて取っている様子を見かける が、このタスクのとり方では、後工程引き取りと言うＴＰＳの考え方から逸脱したオペレーシ ョンになり、一個流しを追求する事は不可能である。タスクは一つ作業が完了したならば、次 のタスクをタスクボードへ取りに行くと言うオペレーションをチーム内全員でしっかりと守る 事が重要である。 ９．タクトタイム ＴＰＳでのタクトタイムとは、ある作業を実施する上での標準的な作業時間と捉えられている が、真の狙いは、作業時間を短縮する事では無い。作業のリズムを作る上でのタクトタイムで ある。ソフトウエア開発の現場で考えると、チームのメンバーが小気味よいリズムで作業に取 り組める様にすることである。大野耐一氏も述べているが作業に一定のリズム感を持つこと で、人間は集中力を高められる。しかたって、ポカミスなども防止できムダ取りの基本原則で あるムラ、ムリ、ムダ（作業にムラが出るから、そのムラを取り戻そうとしてムリを強いる。 ムリを強いれば、結果としてムダが発生する。）のおおもとである作業のムラ取りが出来る。 この開発チームのリズムを作る上で、大事な点は、タスクの粒度を均一化する事も大きい。 タスクの粒度が大小まちまちであると、開発チームが共同して作業を進めていくうえで、手待 ちのムダも起こるが、やはり作業のリズム感も損なわれ、集中力を高める事が困難になる。 リズムと言う意味では、スクラムの手法であるスタンドアップ・ミーティングも同様な効果を 得られる。一日の作業の開始時にスタンドアップ・ミーティングを実施する事で、チームとし ての一日のリズムを刻むスタートポイントにできる。 １０．振り返り（レトロスペクティブ） スクラムの手法での振り返り（レトロスペクティブ）はＴＰＳの中でも良く見られる改善活動 に他ならない。開発チームの作業ペース（イテレーション）にもよるが、基本的には毎週決ま った時間帯で振り返りを実施する事で、先週からの改善や自身やチームの成長を確認する事が 出来る重要な場である。この振り返りではＫＰＴボードが良く利用されているが、ＫＰＴボー ドはプロジェクトに一つと考える必要はない。チームとして色々な改善テーマが出てくると思 うが、それぞれの目的に応じたＫＰＴボードを作成すべきである。 例えば、プロダクト制作に関わるプロジェクトのＫＰＴ，品質を向上させるＫＰＴ、開発チー ム・ビルディングの為のＫＰＴ、中にはＫＰＴをしっかり廻す為のＫＰＴ等有っても良い。 スクラムではスプリント・レビューと同時にレトロスペクティブを実施すると言って居るが、 筆者の経験では、スプリントの期間と関係なく毎週実施される事を薦める。理由は、人間それ ほど多くの事を覚えていない。せめて一週間程度であれば、何をしたか思い出せる。 Strategic Staff Services Corporation 7 １１．一個流し ＴＰＳでは大野耐一氏は、整流化するために仕事を出来るだけ小さな単位に分解する事と、平 準化をする事が重要だと説いている、平準化すれば多様化を支援するとも言っている。ならば ソフトウエア開発の現場では、これはどの様に取り組むべきものであろうか？一寸考えて頂き たい。取りも直さずソフトウエア開発現場では、スクラムのスプリントバックログ（通称タス ク）の粒度を出来るだけ小さく、また均一化させる事である。言葉で言うは易いが、実際チー ムでタスク出しを行うとなかなか難しい課題である。従来のＷＢＳの様な目的の記述では、タ スク粒度を小さくすることはできない。タスクを小さくする方法は、制作する目的を実現する ための作業手順に分解する事である。こうすればタスクは小さくでき、筆者の経験では 1 時間 （60 分） のタスクに分解可能である。またこのような基準でタスクを分解すれば、タスク粒 度の均一化もできる。この努力によって、作業の平準化も実現できる。 タスク粒度を小さく、均一化する為のＫＰＴをチームで廻すと良い。 １１．大部屋方式 トータルＴＰＳでは、管理の異なる仕事（部門）間でプロセスの整流化を実現する方法として 大部屋方式が紹介されている。これはＩＴの分野で見ると、企画～開発～運用の全てのプロセ スでＡＬＭ視点での一気通貫での見える化であり、全プロセスでの整流化である。ＩＴ業界用 語で表現すれば DevOps（ＣＤ；継続的デリバリー）そのものである。 DevOps に取り組むのであれば、トヨタのこの大部屋方式は具体的な手法として利用価値が高 い。 この大部屋方式を導入する事によって、全てのプロセスに渡って見える化し、全体のプロセス を滞りなく流す整流化を実現する。結果としてはジャストインタイムでのＩＴサービスの提供 という DevOps の目的を達成できる。 １２．先行改善 トータルＴＰＳでの先行改善と言う事は下流工程から上流工程へ改善要望を提案する事であ る。スクラムで言うと、開発チームからプロダクト・オーナーへプロダクト・バックログの修 正等良いシステムを作る上で有益な提案をする事である。スクラムでも記述されているが、プ ロダクト・バックログはユーザーばかりでは無くプロジェクト関係者誰でも提案できる。成功 しているスクラムチームは、開発チームからの活発なプロダクトバックログへの提案がなされ ている。 Strategic Staff Services Corporation 8 おわりに 如何でしょうか？アジャイル開発特にスクラム、ＸＰとトヨタ生産方式（ＴＰＳ）との強い類 似性を確認して頂けたしょうか？アジャイル開発に取り組まれる方々には、トヨタ生産方式を 学んで、良くその目的、考え方を理解できると、スクラムやＸＰでの手法（プラクティス）の 価値、目的を正しく理解できる様になります。アジャイル開発プロジェクトで真にユーザーに 評価されるチームを目指すのであれば、トヨタ生産方式（ＴＰＳ）が大前提となります。 アジャイル開発の紹介をしている際に、良く聞かれる話だが、アジャイル開発に向いた適用業 務や適したプロジェクトの大きさ等が初心者から話題になる。このホワイトペーパーで紹介し てきた通りこのスクラムやＸＰの手法や考え方は 10 兆円企業のトヨタの生産現場で日々実施 されている手法や考え方をソフトウエア開発の現場に導入している物であるので、上述の様な 疑問は不要である。スクラムやＸＰの考え方、手法の意味を正しく理解して、アジャイル開発 に取り組めば、どの様な適用業務や規模にも適用可能である事を、トヨタの事例が示してい る。大事な事は、トヨタの代名詞にもなっている「なぜ、なぜを 5 回以上繰り返して問い」、 ものごとの本質や真因を掴む姿勢が成功への近道でもある。 是非、ソフトウエア開発の現場で『一個流し』のプロセスを確立し、そのプロセスの整流化を 追求していけば、おのずとお客様（ユーザー）に評価されるアジャイル開発での成功が見えて くる。 最後に、『トヨタ生産方式』の著者である大野耐一氏の言葉を紹介します。 『私どもとして、これだけトヨタ生産方式に関心を寄せてくださることは結構なことであり、 ありがたいことだと考えています。しかししだいに注目され、国内の各業界でも研究されてい くうちに、一部では誤解されたり、あるいは都合のよい部分だけを濫用されているところもあ るように聞いています。その端的な例は、トヨタ生産方式すなわち‘“かんばん方式”であるとい う短絡したものです。そもそも「かんばん」とはトヨタ生産方式の運用手段の一つであり、 「かんばん」を採用したから、それだけで生産性が向上すると言うものではありません。』 株式会社戦略スタッフ・サービス 代表取締役 社団法人ＴＰＳ検定協会 理事 戸田 孝一郎 Strategic Staff Services Corporation 9 【参照文献】 トヨタ生産方式 ー脱規模の経営を目指してー 大野耐一著（ダイヤモンド社刊） スクラム ー仕事が 4 倍速くなる“世界標準”のチーム戦術 ジェフ・サザーランド著（早川書房刊） エクストリームプログラミング （第２版） ケント・ベック、シンシア・アンドレス共著（オーム社刊） トヨタ流の教科書 企業編ー世界最強のものづくりの秘密― 堀切俊雄著（日経ＢＰ社、日経ものづくり刊） トヨタ流の教科書 ＴＭＳ編 高木徹著（日経ＢＰ社、日経ものづくり刊） Strategic Staff Services Corporation 10
© Copyright 2024 ExpyDoc
