TMSによるシステム開発

　システム開発プロジェクトが失敗に終わる話をよく聞く。

その時の失敗の原因が、

・ＰＭの管理が甘かった。

・お客の要求を整理できなかった。

・お客の変更要求があまりにも多かった。

などなどである。本当にこのような事が失敗の原因なのだろうか？あまりにも基本的でそんなこと当り前だろうと思われている事が実は失敗の根源の様に思えてきた。

　それは開発プロジェクト・チームの崩壊（コラップス）だと思える。崩壊という一寸衝撃的な言葉を使用したが、敢えて皆さんに注意を喚起してほしくてこのような激しい言葉で表現している。

　多分プロジェクトを指揮、管理する立場の皆さんからは激しい反論を受けると思う。『自分たちはそんな基本的な事は既にできている。』『何を言っているんだ。』そのような声が聞こえてきます。

が、もう一度よく考えてください。私が『プロジェクト・チームの崩壊』と言っているのは、皆さんが編成したプロジェクト・チームが自律的に、モチベーション高く、本来のチームとして機能（働いて）していたでしょうか？

　やらされ感満載のチームメンバーといきりったプロジェクト・リーダー（管理者）のプロジェクト・チームに落ちていませんでしたか？このような状態でチームは正常に機能しますか？チームはお客様のことや、品質、納期等を常に意識していましたか？

　私はこのような事が機能しないチームを『プロジェクト・チームの崩壊』と表現しています。この問題は開発メソドロジー（ウォーターフォールであれアジャイルであれ）やツール、PMBoKといった知識の問題ではありません。何故プロジェクト・チームを編成するのか？プロジェクト・チームの目標、目的は何か？チーム内（関係者全員で）で共有している基本的な価値観は何か？チームが正常に機能するためにはこのような基本的な事が必要です。

　失敗したプロジェクト・チームをこのような観点で冷静に振り返ってみてください。本当にこのような事が出来ていて失敗しているでしょうか？私の経験から言えば、この様な事が出来ていればプロジェクトは失敗しないはずです。

　というのはこのようなチームであればどの様な状況の変化に対しても対処可能だからです。

　対処できないのは、チームが硬直化して、何のためのプロジェクト・チームであるかと言う基本的な価値観が共有されていなく、各人がまちまちの勝手な思いでいるからチームが機能しなくなったり、官僚的な仕事（対処）になるのです。

　ですからシステム開発プロジェクトを成功させたいと考えるなら、しっかりとチーム・ビルディングをしなければなりません。

　プロジェクト・チームを編成した時に管理者の皆さん、この事に意識を傾けて重要視してますか？単に必要工数をカバー出来る人工をそろえるチームを作ってはいませんか？

　アジャイル開発（Scrum）の導入を企業向けに実施してきた経験から、アジャイル開発の基本的な考え方にトヨタ生産方式（ＴＰＳ）の概念が含まれていることは、アジャイル開発を実践された方には感じ取っていただけると思います。

　このような感触からアジャイル開発を指導し始めた頃よりＴＰＳについて並行して学び始めました。

　2009年に豊田マネージメント研究所の高木副社長とお会いしてＴＭＳの紹介をして頂きました。

　ＴＭＳとはＴＰＳ（トヨタ生産方式）がもの作りの現場、所謂製造現場とその周辺に関わる生産部門でのマネジメントですが、この考え方をまったく踏襲して非生産部門、所謂俗に言われるホワイトカラーの人達のマネジメントとして職場の活性化という形で解り易く紹介されております。

　ＴＰＳとＴＭＳの大きな違いは、生産部門のＴＰＳでは指示命令系統が強い職場で適用されるメソドロジーですが、非生産部門のホワイトカラーの職場では必ずしも指示命令系統が強い職場ではありません。

　また生産部門と異なり品質という事を見てみても生産部門では誰にでも見れば品質の良し悪しは明確に判断できますが、仕事の内容、結果が見えにくい事務作業では品質を誰が見ても解るようにはできません。

　見える化の工夫が必要です。

　したがって作業者自らの自律性やモチベーションといった基本的に働くビヘイビアーに結果が左右されることになります。ここで問題になるのは、知識を持ち合わせていたとしても、その知識を自分で実際の行動に移せるか？は知識の有る無しよりも重大な事になります。

　たとえ知識を持っていても、実際に行動レベルまで落とし込んで実行できなければ、その知識は単に知っているという事で、その知識を生かして期待する結果を求められるかという事では、知識が無い事と同義になります。

　トヨタではＴＰＳでもＴＭＳでもまず知識よりの行動を求められます。また個人が経験した体験から生じる暗黙知を見える化することでチーム内、組織内の形式知化する事を求められます。

　このようにして、チーム、組織の全員が形式知化した知識をまた実行して暗黙知を生み出し、さらにまた形式知化することで、カイゼンが廻ってよりよい作業結果や作業環境を整えていきます。自律した開発チームを前提としたアジャイル開発の現場においては、このＴＭＳで言う暗黙知と形式知の循環サイクルを回して、反復的に現地現物のコードで確認しながらお客様に評価される品質や納期（ＪＩＴ）を確保していきます。

　そういう意味でＴＭＳに出合いアジャイル開発を指導するうえで大きな指標を得たと言えます。またウォーターフォールであれ、アジャイルであれ開発メソドロジーの紹介に終始して、特にアジャイル開発で要求される自律した開発チームをどのように育成していくのか？というメソドロジーは提供されておりません。

　ここは従来から、自分で勝手にやってください。そのようなチームを編成してくださいと言った形で触れられておりませんし、その様なチームありきが前提でメソドロジーが論じらております。過去この最初のチームを作る（育成）段階では何か良いメソドロジーが紹介されていなかったのです。

　ＴＭＳはこのチーム育成のメソドロジーを我々に提供してくれます。

またこの方法で成功したトヨタという企業が存在するという目に見える結果も見ることができます。

　ＴＭＳ一番の利点は、プロジェクト・チームを編成した時に、まず自律したチームを育成するメソドロジーを提供してくれる事である。Scrumでも、望ましいチームの形としてある期間（長期間）チームを固定した方が良いとアドバイスしているのは、あながち間違ってはいない。チームを固定化することで、プロジェクト開始時のチームの育成という段階を省略できる。

　では皆さんのシステム開発プロジェクトを編成した時の事を思い起してほしい、プロジェクト案件毎に多分チーム編成は固定されておらずその都度チームを編成していないだろうか？プロジェクトとい性質上案件ごとに異なるメンバー構成になるのは必然である。

　ではチームを編成した後に、このように自律して正常に機能するチーム育成に何か方策をやメソドロジーをお持ちであろうか？ほとんどのプロジェクトではこの段階は現場に放り投げられ、意識することも少ないと思われる。

　これでプロジェクト・チームは皆さんの期待通りに機能するのでしょうか？ＴＭＳはこのような段階で自律したチームを育成する環境やメソドロジーを提供してくれます。

　これはウォーターフォールであれアジャイルであれ開発メソドロジーの問題ではありません。同じです。

　残念ながらPMBoKにもこのチーム育成の知恵は語られておりません。できているという前提に立った知恵です。

　システム開発プロジェクト特に大規模になればなるほどこのチーム編成後のチームの育成という問題は大きくなります。ウォーターフォールでもアジャイルでも触れられていないこの空白の部分をＴＭＳはメソドロジーを提供して見事に補ってくれます。

　自律したチーム（作業者）を育成するステップは、基本的に次のようになります。まず自分の足元が見えていなければなりません。

　自分がどこにいるのかわからなくて、自分の環境や仕事をよりよくすることはできません。その意味で『見える化』が重要な役目を負います。

　また自分が知らず知らずのうちに（無意識で）行っている行動、意思決定（マネジメント）の癖を認知する必要があります。これも自分の足元を見る事と同義です。

　さらに仕事を通して、達成感（必ずしも成功体験ばかりではありません）を味わえる事が大事です。これも『見える化』されていないと、味わえません。

　達成感を味わえることで自信が芽生えます。この自信が発展しなければ自律へとは向かいません。自信を持てることが自律への第一歩を踏みだせる要件です。

　このようなステップを経なければ自律したチームを育成できません。ＴＭＳはこの自律へのステップをメソドロジーとして提供しています。

　結果として自律したチームでは自然とカイゼン（ＰＤＣＡ）が廻り始めます。これは『やらさせ感のないカイゼン』です。

　アジャイル開発、特にScrumでは、ＴＰＳの概念が多々流用されています。ＴＰＳで言われているところの、お客様第一、後工程引き取り、一個流し、自工程完結、平準化、現地現物、カンバン（タスクボード）、見える化、等々。

　また具体的なメソドロジーも借用されています。振り返り（ＫＰＴ）、スタンドアップ・ミーティング（朝会、昼会、夕会）がそうです。

　また、ＴＭＳもScrumもどちらも指示・統制型マネージメントから現場での自律したマネージメントへのマネージメントスタイルの変換を求めているところは同じです。

　特に振り返り（ＫＰＴ）はScrum Alliance（Scrumの振興団体）の欧米でのプロジェクト成功要因として重要視されておりますが、その具体的な指導方法やメソドロジーについては、スクラムマスターの個人的な力量としか扱われておりません。ただ残念なのは、形式に囚われて、その意義、目的が正しく理解されていないという事です。

　ですからアジャイル（Scrum）の形を真似て実施しても、その真意がわからずに実施すれば、やはり失敗とは言いませんが、成功させることはできません。

　このようにアジャイルScrum）を実施しようと考えたならば、まずＴＭＳを学ぶことが先決です。

　基本的な意義や目的を理解した上でScrumのメソドロジーを知れば、自律したScrumチームを育成でき、かつ効果的にScrumのプロセスを回すことができます。

　2000年以降、わが国でもアジャイル開発が取り入れれて幾多の成功事例が報告されておりますが、その殆どは、Web系の開発やベンチャー企業などの単一の開発チームであったり小規模なチーム構成です。

　それで大規模なシステム開発や大企業での適用は向かない等の意見が散見されますし、アジャイル開発に向いた案件規模等の議論がされてきました。

　確かに開発チーム内でのプロセスやチームマネジメントについては有用なメソドロジーを提供してくれておりますが、大規模なチーム、組織での大規模な案件ではどの様に対処すべきか？はScrumでも簡単にScrum of Scrumといった概念を提供しているだけです。

　ではアジャイル開発の利点を求めながら大規模案件ではどのように対処すればよいのでしょうか？

　これまでの議論では、ウォーターフォールのメソドロジーと組み合わせてハイブリッドやＲＵＰを起源とするＤＡＤなど種々なメソドロジーが語られております。私のアジャイル開発指導経験とＴＭＳの経験からＴＭＳの職場活性化のメソドロジーとScrumのプロセス、メソドロジーを組み合わせる手法が、大規模なプロジェクトでも効果的であるという結論に至りました。

　その理由は、ＴＭＳのメソドロジーはシステム開発手法に囚われず、自律したチームの育成とマネジメント能力の向上を支援してくれます。ウォーターフォールであれ、アジャイルであれ大規模なプロジェクトの効果的な運営については、特にメソドロジーを提供しておりません。

　一方、このような大規模なプロジェクトのマネジメントとしてトヨタで実際に活用されて効果を発揮している『大部屋』という概念と手法は大規模なシステム開発プロジェクトにはうってつけです。　

　Disciplined Scaling Agile (DSA)という概念は、このようにＴＭＳの『大部屋』の概念、手法でプロジェクト全体を見える化します。

　そして、マネジメントできる事と各チーム内で実施されるScrumのプロセス、マネジメントを組み合わせることで、全体と個の双方の同期をとることができ、プロジェクト全体を現地現物でマネジメントできるようになります。