トヨタの自工程完結とソフトウェア開発
言うまでもなく日本最強の企業トヨタ。トヨタ生産方式は、「リーン」として、その名を世界に知られています。
では、トヨタの中のソフトウェア開発はどうなっているのか？その答えがないまでも、トヨタのホワイトカラーはどうやって品質を高めながら生産性を高めているのか？
その手がかりになるような本です。（この本では、ソフトウェア開発には触れていませんが、トヨタの「スタッフ部門」（著書曰くホワイトカラー）にもフォーカスしながら2007年からトヨタ全社的に始まった
「自工程完結」を紹介しています。
ここでは、この「自工程完結」の考え方がソフトウェア開発にも応用できないか考察してみることにします。
トヨタにも「銀の弾丸」は無かった
組織の壁
トヨタ程の企業であれば、組織の壁なんて無いのだろう、と考えていました。私は様々な本を読んできましたが、GEやAppleには組織の壁なんて無いと思っていましたので（コンカレント・エンジニアリング）
、ましてトヨタにはそんなものがあるとは思いませんでした。
しかし、「自工程完結」を始める前のトヨタでは、組織の壁があった。
自工程完結を日本で試すために、全部門にまたがる問題であった車の水漏れ対策を「自工程完結」で進めた際に、以下のように書かれています。
日本に戻ってきて「活き活きしてないなぁ」と思っていた工場の雰囲気は、格段に変わりました。しかも、部門間の壁もなくなった。「そっちのせいでこっちが迷惑をこうむっているんだ」という空気がなくなりました。
水漏れ対策という、すべての部門にかかわる取り組みを進めたことで、「何がいちばん大事なことなのか」ということが共有できたからです。それは各部門がエゴを貫き通すことではありませんでした。みんなで良い車を作るということです。風通しも本当に良くなりました。
トヨタの自工程完結 p68より引用
非生産的な仕事
著書は、ヨーロッパで仕事をしてきたあと、日本に戻ってきて愕然とされます。
ヨーロッパのスタッフ部門とは仕事のやり方がまるで違う。日本では、何かを求めても、根回しから始まるというのです。
現場で権限委譲が進んでおらず、自らが決められない。上司に「お伺い」を立てる。
根回し、手直し、やり直し。調整会議、対策会議に明け暮れる毎日。これでは何も生み出せません。生み出すスピードが遅くなる。大丈夫か、日本の産業界
トヨタにもある、ということは日本の多くの企業でもあるということではないでしょうか。
昨今の日本の現状を鑑みるとそう思わざるを得ません。
社内でごちゃごちゃやってる場合じゃないんじゃないですか。少子高齢化とか英語の壁とか、今までの文化とか、そんなんじゃないんじゃないですか。アジャイルかウォーターフォールか、どちらが品質を「保証」できるのか。
自工程完結とは何なのか
水漏れ対策を例にとってみると、水漏れに対する検査は、車が組み上がった後に検査部門がやっていたとのことでした。
厄介なのは、それぞれのプロセス毎にチェックするのではなく、最後の検査で一度にチェックするので、どこに問題があったか把握するのに大変な労力がかかる。
車の組み立てだけでなく、塗装その他の工程も含めて、チェックしないといけない。すべての部門は「もしかしたら自分たちの責任ではないのではないか？」と疑心暗鬼になり、嫌な思いをする。ここでもまた組織の壁が生まれます。
ここで、銀の弾丸ではなく、それぞれの部門がしっかりと水漏れ対策をする、という地道なことを実行する。これがまさに「自分の工程」で「仕事を完結させる」＝「自工程完結」。
最後の検査をしなくてもいいぐらいまでのレベルで、水漏れを防ぎます。言葉だけでは終わらない取り組み。
「自工程完結」は心がけではなく、すべての工程を洗い出して、見直して精査し、きちんと「何をすればいいのか」という行動まで落とし込まなければいけない。
だから、これをやれば確実に結果が出せると信じることができる、拠り所となる。工場のみんなが愚直に、2000以上の水漏れに関係する作業を見直し、一つの同じ方向に向かって取り組みを進め、
生産性が上がり、結果が出る。後に回さないため、仕事がラクになる。モチベーションが上がるのが「自工程完結」。そして一度、この体験をすると、工場内は自発的に動き出すようになったとのこと。
これはチームが自律するのと同じ効果かと思いました。自工程完結の１０のメリット
- 部分最適がなくなる
- 上司が進捗確認できるタイミングを作れる
- 上下左右のコミュニケーションが深まる
- 各部署の固有の強みを最大限に活かせる
- 部門内の情報共有が進む
- 会議が減る
- 理不尽なところが増える
- 失敗が減り、妥協がなくなる
- 生産性が上がる
- モチベーションが上がる
アジャイル手法を導入する際の効果と似ています。
品質保証には２つの方法がある
検査の理念は、検査しないことにあり
豊田英二 トヨタ自動車株式会社会長
品質保証には大きく２つあります。品質を検査に頼るやり方と、品質を工程で作りこむやり方です。
前者は、第３者が良し悪しを判断し、悪ければやり直しを命じる。それに対して後者は、一つひとつの工程で良し悪しを判断しながら、最終的な品質を高めていく。
この後者こそが、文字どおり「自工程完結」の考え方です。
ただ、この考え方から最終検査をやめるかというと、そうでもなく、
「最終検査にて不具合が０件であること」、そうしてはじめてお客様に品質を「保証」できるということです。工程の不安定さを最終検査でカバーしてはいけないのです。
ソフトウェア開発における「工程」とは？
トヨタでは、「検査に頼らないモノづくりをする」、「検査の理念は、検査しないことにあり」、「品質は工程で造りこもう」というキャッチコピーがありました。それらが「自工程完結」へ繋がります。
では、ソフトウェア開発における「工程」とは何でしょうか？
よく言われるのがウォーターフォール、V字モデルです。
一般的には、要件定義、基本（外部）設計、詳細（内部）設計、コーディング（実装）、単体試験、結合試験、システム試験というあたかも「工程」のような感じを受けます。
ですが、私はこの本を読み進めているうちに、これは工程ではないという考えに至りました。
要件定義をどれだけ綿密にやったとしても、ユーザの欲しいものはわからない。品質は、時間とともに劣化していく（ユーザニーズが変わるから）。
品質を決めるのは、ユーザである。ソフトウェアは、その名の通り「柔らかい」。変化可能である。
基本設計が抜群に出来たとしても、正しいソフトウェアかどうかは誰にもわからない。実装してみないと、ソフトウェアが正しく作られるかもわからない。ユーザや検査部門からのフィードバックがないと、その基本設計が正しかったかわからない。つまりこれは一つで完結した工程に成り得ないということです。
今まで言われてきた工程は、工程ではなく、フェーズのようなものです。ソフトウェア開発における工程というのは、「ソフトウェアを考え始めてからユーザに使ってもらうまで」、だと思います。
スクラムで言うところの、スプリントが工程にあたります。
XPで言うところの、週次サイクル(Weekly Cycle)ないし、４半期サイクル(Quarterly Cycle)が、１つの工程です。「自工程完結」をソフトウェア開発に応用するには
「自工程完結」は、まさに「アジャイル」。ただし、ソフトウェア開発における「工程」を勘違いするな
品質保証には２つの方法がある、で載せた図を見て驚きました。アジャイルの絵なのです。
小さいぐるぐるが何回も出てきます。そして「工程で品質を造りこむ」、工程は、スプリントです。決して基本設計や詳細設計ではない。
最終検査は必要ですが、不具合０件です。それが出来てはじめて「自工程完結」になっていると言えるでしょう。ソフトウェア開発は「マニュアル化」できるのか
この本を読んでいて、違和感があったのが、ホワイトカラーの仕事の「マニュアル化」です。
プログラマーは誰しも、自分のやっていることをマニュアル化できるとは考えていません。
コーディングスタイルのガイドラインや、設計指針は必要だと思いますが、全てのステップが詳細に記録された「マニュアル」ではありません。
プログラミングは設計行為そのものであり、非常にクリエイティブです。おそらく、マニュアル化しても出来上がるものは異なるでしょう。
マニュアル化する時間があるなら、自動化しますよね。個人ではなくチームで挑め
自工程完結も、当初は小さな取り組みから大きく発展していき、2007年にはトヨタの全社で実行されることになります。
この取組は個人では成し得ません。スクラムやXPもそうですが、必ずチームで挑む必要があります。常に改善し続ける状態（=アジャイル)
アジャイルは、状態だと言われています。「常に改善し続ける状態」です。
自工程完結を読み、まさにアジャイルだと思いました。各工程が自律的に改善をし続ける状態になっています。
工場も活き活きとしたと著者は述べています。
そしてこの活動に終わりはない、ということで締めくくっています。
ソフトウェアにおいてもまさにその通りで、プロダクトの命が終わっても、チームが存続すればその意識は引き継がれます。
プロダクト開発は、終わりのない旅です。
