ウォータフォール開発とアジャイル開発 ～車載ソフト開発にはどっち！？～
こんにちは。ソフト屋さんのレオハルです。
本日は、ソフトウェアの作り方、開発プロセスのお話になります。
「ソフトウェア開発手法」とも呼ばれていますね。
まだまだ主流なウォーターフォール開発と、これから求められそうなアジャイル開発について、私の経験も交えながらご紹介していき、 車載ソフトの開発手法の今後を考えます。
ウォーターフォール開発
上流から下流へ各工程を順に行う開発方法です。水が滝を流れる様に例えてウォーターフォールと呼ばれます。基本的には、前の工程に戻らないことを前提にしています。
下図のように、設計工程を左側・評価工程を右側に記述し、その見た目のまま、V字モデルとも表現されます。
ウォータフォール開発のメリット
- 工程ごとのチェックがしやすい
- 作業分担が行いやすい
- 進捗状況が把握しやすい
- 計画的な開発が求められるため品質の担保がしやすい
ウォーターフォール開発のデメリット
- 各工程が完了するまで次の工程に進むことができず、開発期間が長くなる
- 必要な開発成果物が多い
- 不具合が見つかった場合、手戻りが大きくなる
アジャイル開発
アジャイル開発とは、小単位での実装とテストを繰り返しながら開発を進め、全体のシステムを作り上げる開発手法です。イテレーションと呼ばれる短い開発期間単位を採用し、この間に設計・実装・評価を完了させ、次の小単位の開発に移ります。
進め方の違いをイメージ図で表してみました。
アジャイル開発には、複数の開発手法が提唱されています。
代表的な３つの手法をご紹介します。
スクラム
ラグビーのスクラムが語源になっています。チーム一体となり、メンバー間のコミュニケーションに重きを置いた開発手法となります。
朝会で昨日やったこと、今日やること、困りごと等を一人一人共有し、チーム全員の状況をプロジェクト全体で見える化します。メンバー自身が計画を立案し、設計・実装・テストを進行し、イテレーションごとに成果物をチェックします。
スクラム開発には、決められた３つ役割が存在します。
- プロダクトオーナー
プロジェクトの責任者です。
基本的には、開発を行わず管理に徹し、開発の優先順位付けや方向性の決定に対して最終決定権と責任を持ちます。 - スクラムマスター
実際に開発を回すリーダー的存在です。
プロダクトオーナーとの調整をもとに進め方を決定し、開発メンバーに説明、実行させる役割を持ちます。
開発がうまくいっているか、困っていることはないかをウォッチし、時には自ら問題の解決にあたります。 - 開発メンバー
アジャイル開発では、個々の開発メンバーで能動的に開発を進めるものです。
スクラムでは、スクラムマスターに管理・調整業務を担ってもらい、より開発に集中する役割になっています。
エクストリーム・プログラミング(XP)
技術面・プログラマを中心に考えた開発手法。
過去の開発手法では、後工程に進むにつれ、変更コストは大きくなると考えられていました。しかし、自動テストを導入したり、ツールを活用することにより、変更コストが増大しないような工夫を取りれることが可能となってきています。
この前提をふまえて、事前の計画よりも、柔軟性を重視する開発手法となっています。
この手法では、5つの価値をチーム内で共有し開発を進めます。
「コミュニケーション」「シンプル」「フィードバック」「勇気」「尊重」です。
- コミュニケーション
クライアントやチームメンバー間で、仕様の共有をドキュメントのみで実施すると、仕様書の作成に時間がかかり、仕様書の理解に時間がかかり、有限である時間をどんどん消費していきます。コミュニケーションを密にするという価値を共有することで、メンバーの時間の無駄を最大限排除することができます。 - シンプル
エンジニアは、いろいろな技術や技法を使いたがります。しかし、思惑が外れることも多く、プロジェクトとしては、時間の無駄に終わることも少なくないと思います。
機能を満たす最低限の単純な設計に止めることに価値を持つと考えます。 - フィードバック
よく使われる機能は、全体の20％であるという調査結果がよく聞かれます。
不必要な機能開発を回避するために、本当に必要な機能なのか、クライアント・関係者を巻き込んでフィードバックを得て開発を進めます。定期的なフィードバックを得ることで本当に必要な機能を早期に提供できます。 - 勇気
変化を受け入れ実行するための”勇気"です。
ウォータフォール開発では、先に決められたことに従い開発を進めることが前提でした。しかし、上記3つの価値を実現するためには、自ら発信し、変化を促すことが必要になります。人間は、流されるほうが楽な生き物です。流れに逆らうために勇気を持ちましょう。 - 尊重
開発は、一人ではできません。他人と何かを共にする必要があり、互いを尊重しながら進めなければ、円滑に進めることは不可能です。
ユーザ機能駆動開発(FDD)
実際に動作するソフトを適切な間隔で提供することを繰り返す手法です。
クライアント・ユーザにとっての価値を重視して開発が進められるのが特徴です。
クライアントの必要機能を見える化し洗い出し、適切な間隔で提供し、システムを完成させていきます。
この手法では、イテレーション=反復期間が、ほかの手法よりも一般的に短く設定されます。通常2~4週間に対して、2～10日間程度になります。
抱える問題や提供する機能を、小さくし解決しやすくすることが重要になります。
アジャイル開発のメリット
- 開発スピードが速い
- 不具合発生時の修正コストが抑えられる
- 顧客の最新ニーズに最大限答えられる
アジャイル開発のデメリット
- 開発方針がブレやすい
- 全体のスケジュールコントロールが難しい
実際の車載ソフト開発は、ハイブリッド(レオハル持論)
さて、ここまでウォータフォール開発とアジャイル開発にさらっと触れました。
車載ソフトウェア開発に従事している私の場合どんな開発手法になっているのか、自分なりに振り返ってみました。
まず結論として、車載ソフトウェア開発は・・・
ハイブリッド型開発
ウォータフォール＋アジャイル
で、進められています。
車載ソフトウェアの開発の特徴として、
「確実な安全性・高い品質」
「カーメーカーと部品メーカーの役割分担」
「車両開発スケジュール」
「商品性の向上」
の4つがあるのではないかと私は考えています。
「確実な安全性・高い品質」を満たすためには、確実な設計をするための設計書やそれに基づいた実装を行い、明確なルールのもと運用することが必要で、ウォータフォール型の開発で進めることが必要だとされてきました。
実際に自分が担当してきたプロジェクトや、公的な開発プロセス企画もウォータフォールがベースになっています。
「カーメーカーと部品メーカーの役割分担」を考えると、各部品・システムへの要求をもとにソフトウェア設計していくため、工程間のINPUT・OUTPUTが明確なウォータフォールが必要だと考えています。
「車両開発スケジュール」も予め決められていることが大半です。車のモデルチェンジ、マイナーチェンジ、改良といったワードを聞いたことがある人も多いのではないかと思います。車は、一定期間毎に必ず新しくなります。新しくしないと売れなくなります。これに合わせて開発を進めるために、ソフトの開発スケジュールは、厳格に守っていく必要があります。
さらに「商品性の向上」にも取り組む必要があります。
ソフトウェア機能(システム動作やフェイルセーフ等の様々機能）についても、新機能の追加やレベルアップを行い、製品価値を上げていく必要があります。
これを短期間で高価値なものを提供しようとする場合に、ウォーターフォール型の厳格なプロセスや時間のかかるドキュメント類は足枷になることもしばしばあります。
また、各カーメーカーで名称に違いはありますが、複数回の試作車作成フェーズから構成されています。この各フェーズ毎にターゲットとなる機能を決め、機能追加を進めていく形が多くなっています。1次試作では、車両運動機能を実装、2次試作では、ダイアグ通信等のサービス機能を実装、3次試作で工場での検査機能に対応といった形です。
「安全性・品質は、絶対！」
「短納期で新しい目玉機能を入れる！」
という、一見無茶な背反する要求のように感じなくもないですが、
これに答えるために、導き出したのがハイブリッド型です。
全体の開発や成果物は、ウォータフォール型で厳格に実施し、
各機能の開発については、アジャイル型で小回りの利く開発を行う。
もう少し踏み込んで言ってしまうと、監査対応はウォータフォール型、実体はアジャイル型。と言ってしまってもいいかもしれません。
ただし、決して監査対応で適当にあとから成果物だけ作ればいい訳ではありません。
結局そういうマインドで取り組んだプロジェクトは、リリース後に不具合だらけで修羅場が待ち受けることになるでしょう。
最後に
色々な種類の車載部品があり、そこにはさまざまなステークホルダーがいると思います。それぞれの実態に合った適切な開発手法を見つけ出し、テーラリング(仕立て直し)しながら進めることが最も大事なのかもしれません。
きっと5年後、10年後には、違う手法が推奨されているでしょう。
