アジャイル型かウォーターフォール型か、どちらが品質を「保証」できるのか -トヨタの自工程完結に学ぶソフトウェア開発-

Qiita

トヨタの自工程完結とソフトウェア開発

言うまでもなく日本最強の企業トヨタ。トヨタ生産方式は、「リーン」として、その名を世界に知られています。
では、トヨタの中のソフトウェア開発はどうなっているのか?その答えがないまでも、トヨタのホワイトカラーはどうやって品質を高めながら生産性を高めているのか?
その手がかりになるような本です。(この本では、ソフトウェア開発には触れていませんが、トヨタの「スタッフ部門」(著書曰くホワイトカラー)にもフォーカスしながら2007年からトヨタ全社的に始まった
「自工程完結」を紹介しています。

ここでは、この「自工程完結」の考え方がソフトウェア開発にも応用できないか考察してみることにします。

トヨタの自工程完結

トヨタにも「銀の弾丸」は無かった

組織の壁

トヨタ程の企業であれば、組織の壁なんて無いのだろう、と考えていました。私は様々な本を読んできましたが、GEやAppleには組織の壁なんて無いと思っていましたので(コンカレント・エンジニアリング
、ましてトヨタにはそんなものがあるとは思いませんでした。
しかし、「自工程完結」を始める前のトヨタでは、組織の壁があった。
自工程完結を日本で試すために、全部門にまたがる問題であった車の水漏れ対策を「自工程完結」で進めた際に、以下のように書かれています。

日本に戻ってきて「活き活きしてないなぁ」と思っていた工場の雰囲気は、格段に変わりました。しかも、部門間の壁もなくなった。「そっちのせいでこっちが迷惑をこうむっているんだ」という空気がなくなりました。

水漏れ対策という、すべての部門にかかわる取り組みを進めたことで、「何がいちばん大事なことなのか」ということが共有できたからです。それは各部門がエゴを貫き通すことではありませんでした。みんなで良い車を作るということです。風通しも本当に良くなりました。

トヨタの自工程完結 p68より引用

非生産的な仕事

著書は、ヨーロッパで仕事をしてきたあと、日本に戻ってきて愕然とされます。
ヨーロッパのスタッフ部門とは仕事のやり方がまるで違う。日本では、何かを求めても、根回しから始まるというのです。
現場で権限委譲が進んでおらず、自らが決められない。上司に「お伺い」を立てる。
根回し、手直し、やり直し。調整会議、対策会議に明け暮れる毎日。これでは何も生み出せません。生み出すスピードが遅くなる。

大丈夫か、日本の産業界

トヨタにもある、ということは日本の多くの企業でもあるということではないでしょうか。
昨今の日本の現状を鑑みるとそう思わざるを得ません。
社内でごちゃごちゃやってる場合じゃないんじゃないですか。少子高齢化とか英語の壁とか、今までの文化とか、そんなんじゃないんじゃないですか。

アジャイルかウォーターフォールか、どちらが品質を「保証」できるのか。

自工程完結とは何なのか

水漏れ対策を例にとってみると、水漏れに対する検査は、車が組み上がった後に検査部門がやっていたとのことでした。
厄介なのは、それぞれのプロセス毎にチェックするのではなく、最後の検査で一度にチェックするので、どこに問題があったか把握するのに大変な労力がかかる。
車の組み立てだけでなく、塗装その他の工程も含めて、チェックしないといけない。すべての部門は「もしかしたら自分たちの責任ではないのではないか?」と疑心暗鬼になり、嫌な思いをする。ここでもまた組織の壁が生まれます。
ここで、銀の弾丸ではなく、それぞれの部門がしっかりと水漏れ対策をする、という地道なことを実行する。これがまさに「自分の工程」で「仕事を完結させる」=「自工程完結」。
最後の検査をしなくてもいいぐらいまでのレベルで、水漏れを防ぎます。

言葉だけでは終わらない取り組み。
「自工程完結」は心がけではなく、すべての工程を洗い出して、見直して精査し、きちんと「何をすればいいのか」という行動まで落とし込まなければいけない。
だから、これをやれば確実に結果が出せると信じることができる、拠り所となる。

工場のみんなが愚直に、2000以上の水漏れに関係する作業を見直し、一つの同じ方向に向かって取り組みを進め、
生産性が上がり、結果が出る。後に回さないため、仕事がラクになる。モチベーションが上がるのが「自工程完結」。

そして一度、この体験をすると、工場内は自発的に動き出すようになったとのこと。
これはチームが自律するのと同じ効果かと思いました。

自工程完結の10のメリット

  1. 部分最適がなくなる
  2. 上司が進捗確認できるタイミングを作れる
  3. 上下左右のコミュニケーションが深まる
  4. 各部署の固有の強みを最大限に活かせる
  5. 部門内の情報共有が進む
  6. 会議が減る
  7. 理不尽なところが増える
  8. 失敗が減り、妥協がなくなる
  9. 生産性が上がる
  10. モチベーションが上がる

アジャイル手法を導入する際の効果と似ています。

品質保証には2つの方法がある

検査の理念は、検査しないことにあり

豊田英二 トヨタ自動車株式会社会長

品質保証には大きく2つあります。品質を検査に頼るやり方と、品質を工程で作りこむやり方です。
前者は、第3者が良し悪しを判断し、悪ければやり直しを命じる。それに対して後者は、一つひとつの工程で良し悪しを判断しながら、最終的な品質を高めていく。
この後者こそが、文字どおり「自工程完結」の考え方です。

自工程完結.png

ただ、この考え方から最終検査をやめるかというと、そうでもなく、
「最終検査にて不具合が0件であること」、そうしてはじめてお客様に品質を「保証」できるということです。

工程の不安定さを最終検査でカバーしてはいけないのです。

ソフトウェア開発における「工程」とは?

トヨタでは、「検査に頼らないモノづくりをする」、「検査の理念は、検査しないことにあり」、「品質は工程で造りこもう」というキャッチコピーがありました。それらが「自工程完結」へ繋がります。
では、ソフトウェア開発における「工程」とは何でしょうか?
よく言われるのがウォーターフォール、V字モデルです。

v.png

一般的には、要件定義、基本(外部)設計、詳細(内部)設計、コーディング(実装)、単体試験、結合試験、システム試験というあたかも「工程」のような感じを受けます。
ですが、私はこの本を読み進めているうちに、これは工程ではないという考えに至りました。
要件定義をどれだけ綿密にやったとしても、ユーザの欲しいものはわからない。品質は、時間とともに劣化していく(ユーザニーズが変わるから)。
品質を決めるのは、ユーザである。ソフトウェアは、その名の通り「柔らかい」。変化可能である。
基本設計が抜群に出来たとしても、正しいソフトウェアかどうかは誰にもわからない。実装してみないと、ソフトウェアが正しく作られるかもわからない。ユーザや検査部門からのフィードバックがないと、その基本設計が正しかったかわからない。つまりこれは一つで完結した工程に成り得ないということです。
今まで言われてきた工程は、工程ではなく、フェーズのようなものです。

ソフトウェア開発における工程というのは、「ソフトウェアを考え始めてからユーザに使ってもらうまで」、だと思います。
スクラムで言うところの、スプリントが工程にあたります。
XPで言うところの、週次サイクル(Weekly Cycle)ないし、4半期サイクル(Quarterly Cycle)が、1つの工程です。

「自工程完結」をソフトウェア開発に応用するには

「自工程完結」は、まさに「アジャイル」。ただし、ソフトウェア開発における「工程」を勘違いするな

品質保証には2つの方法がある、で載せた図を見て驚きました。アジャイルの絵なのです。
小さいぐるぐるが何回も出てきます。そして「工程で品質を造りこむ」、工程は、スプリントです。決して基本設計や詳細設計ではない。
最終検査は必要ですが、不具合0件です。それが出来てはじめて「自工程完結」になっていると言えるでしょう。

ソフトウェア開発は「マニュアル化」できるのか

この本を読んでいて、違和感があったのが、ホワイトカラーの仕事の「マニュアル化」です。
プログラマーは誰しも、自分のやっていることをマニュアル化できるとは考えていません。
コーディングスタイルのガイドラインや、設計指針は必要だと思いますが、全てのステップが詳細に記録された「マニュアル」ではありません。
プログラミングは設計行為そのものであり、非常にクリエイティブです。おそらく、マニュアル化しても出来上がるものは異なるでしょう。
マニュアル化する時間があるなら、自動化しますよね。

個人ではなくチームで挑め

自工程完結も、当初は小さな取り組みから大きく発展していき、2007年にはトヨタの全社で実行されることになります。
この取組は個人では成し得ません。スクラムやXPもそうですが、必ずチームで挑む必要があります。

常に改善し続ける状態(=アジャイル)

アジャイルは、状態だと言われています。「常に改善し続ける状態」です。
自工程完結を読み、まさにアジャイルだと思いました。各工程が自律的に改善をし続ける状態になっています。
工場も活き活きとしたと著者は述べています。
そしてこの活動に終わりはない、ということで締めくくっています。
ソフトウェアにおいてもまさにその通りで、プロダクトの命が終わっても、チームが存続すればその意識は引き継がれます。
ソフトウェア開発は、終わりのない旅です。

Qiita

 

アイ・ティ・イノベーション

アジャフォール型開発手法

今回のブログは再び開発方法論を取り上げてみたい。最近、久しぶりにアジャイル/ウオーターフォール論争がネット上で活況を呈しているようだ。エンタープライズ・アーキテクチャの転換を唱えている本シリーズでも、構築するターゲット・アプリケーシヨンの変化や構築技術の進化を背景に、ここらで一つの開発手法をまとめておくことにしたい。“一つの”と書いた理由は、本来、開発手法はプロジェクトの性質にマッチした様々なスタイルがあり、しかも、ベースとなる方法論をプロジェクト毎にテーラリングして活用するものだからだ。今回取り上げるプロジェクトは基幹系/情報系のアプリ種別やパッケージ/スクラッチ等の実装方法を問わず、数百人月規模のビジネスアプリケーションを対象にしていると思っていただきたい。期間は半年~長くて1年程度といったところ。なお、全体で数千人月の大規模アプリケーションでも1リリース単位を1年以内に刻んだ際はこの規模になり得る。

かねてより「プロジェクトの成功からプロダクトの成功へ!」、「システムを作ることから創ることへ!」を標語に、あるべきシステム開発の姿を模索し続けてきた私としては、まず、開発工程の中核に位置する“設計・構築・テスト工程”にアジャイル手法を取り入れることを推奨したい。ここでお断りしておくと、財務会計に代表されるような定石がある業務アプリケーション(通常パッケージシステムを適用)はこの対象にはならない。なぜなら、それらは既に設計の大部分を終えており、イテレーションによる最適デザインの模索が不要だからである。

図1はタイトル通り、「モデル主導でかつテスト駆動型の反復開発手順」を絵にしたものである。右上の時系列での作業比率の絵は懐かしいRUPのなごりであるが、ここでは分析作業は入っていない(システム分析は要件定義フェーズへ移動)。この手法の大きな特徴は何と言ってもモデル主導にある。各スプリントには当然ながら“設計”の要素が入っており、ドキュメントレスのアジャイル開発でもモデル図(データ及びプロセスモデル)だけはメンテンナンス対象として、反復の回数を重ねる度にそのバージョンを上げて行く。

これと並行して変更管理するものにテストデータが挙げられる。教科書にないところは、このテスト工程で用いるテストデータ品質に力点があるところである。私のエンタープライズ・アプリケーション開発経験から、プログラマーの作り物のデータによるホワイトボックス・テストに長時間を割くより、既存システム上の生データを元にしたブラックボックス・テストにできるだけ早く取りかかる事が重要と思われる。このテストデータは、スプリントを回す度に、より本番データに近付けるべく、既存システムを熟知した“テストデータ作成チーム”が裏方として機能し、各スプリントにタイムリーに供給する。

さて、ここまでは、アジャイル開発のメリットをできるだけ享受してプロダクト品質を磨く為に考えられた“開発プロジェクトのBODY“に相当する部分である。問題はここからだ。往々にして、”ちまた”のアジャイル/ウオーターフォール論争は、お互いの事を知らない者同志が相手を揶揄するばかりで、かみ合わないものが多い。これは、ウオーターフォールが、エンタープライズ・アプリケーションを対象とすることに起因する(最近ではエンタープライズ・アジャイルにも関心が高まりつつあるが)。エンタープライズ・プロジェクトの性格は、厳しい非機能要件に基づく高度な品質(Quality)、厳格な納期(Delivery)やコスト(Cost)がその特徴である。自由奔放に開発したいと思っても、背に腹は代えられない厳しい制約条件が突きつけられている。

ではこれらのリスクを最小化しつつアジャイルの良さを活かすにはどうしたら良いだろうか?現時点での現実解としては、要件定義までは通常のウオータフォール型を採用することが賢明である。論理モデル、採用アーキテクチャ、インフラ環境等の大枠が一旦確定した状況下で、アジャイル開発に突入しないことには、あまりにプロジェクトリスクが大きいからだ。図2にその概要を絵にしてみた。真ん中の設計・構築・テストフェーズはアジャイル開発を採用し、両端の要件定義フェーズと移行フェーズはウオーターフォール型で実施するというハイブリッドなものである。下段には、開発に参画する各種プレイヤーをフェーズ別の役割とともに大よその面積比で示した。言うまでもなく、ここでのユーザ側情シス、エンドユーザの参画は必須である。

表題の”アジャフォール”はアジャイルとウオーターフォールをミックスした造語だが、反復によるシステムの進化も、要件定義から移行までの開発全体の進行も、どちらも曖昧なユーザ要求から具体的システムに落とし込む様は、高い所から低い所へ水が流れ落ちる状況の方がなぜかしっくりする。つまり言葉的にはスパイラルアップとは逆のイメージである。

エンタープライズに浸っている人間は、自由度の高いアジャイルによって、要件が発散し収集がつかなくなるのではという潜在的不安がある。このリスクをヘッジし”物事が収束するイメージ”を加えたものが、この”アジャフォール”である。慣れない事に取り組む際には、まずは少しずつ馴染ませるのが良い。大事な事は、自己(社)流でも良いので、新たな開発手法にチャレンジする事である。なぜなら変わらない事も大きなリスクだから。

アイ・ティ・イノベーション

0
システム品質を左右する「組織体… Micro Services …

コメントはまだありません

No comments yet

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です