アジャイル製品開発: 製造業界はテック業界から発想を得られるか
2000 年前半からアジャイル ソフトウェア開発が急激に人気を得ているが、ハードウェア製造業は蚊帳の外だった。だが、噂は広がるものだ。製造メーカーは今、「アジャイルは、ハードウェア開発にどう適用できるのか？」を問い始めている。
この問いは、好意的なものではあっても、製造業がアジャイルをハードウェア製品に応用する「べき」だとの前提に立っている。だが、ソフトウェアの原則や実践をハードウェアへ無理に適合させると、非現実的でぎこちない方法論の寄せ集めとなる可能性がある。より有効な問いは、こうだろう。「ハードウェア製品開発の問題のうち、アジャイルから“発想を得た”実践によって軽減可能なものは？」。
「アジャイル」とは？/strong>
Agile Alliance によると、「アジャイル ソフトウェア開発は、アジャイル ソフトウェア開発宣言で表される価値と原則に基づいた、一連の手法や実践の包括的な用語である。ソリューションは、それぞれの背景に対して適切な実践を活用する、自己編成的および機能横断型の、チーム間のコラボレーションにより発展する」。
これらの価値と原則は、アジャイル手法として人気の高いスクラムなど、特定のソフトウェア開発手法に対して思慮に富んだフレームワークを提供する。スクラムでは 5 – 9 名から成るチームが「スプリント」と呼ばれる反復工程で、優先されたプロダクト バックログ項目を完了させる。バックログ項目に含まれるのは機能、シナリオ、ストーリーなどで、スプリントには通常 2 – 3 週間のタイムボックスが設定される。チームは各スプリントの最後に、リリース、顧客へのリリースの実演、フィードバックの収集を行う。
慣習的プロセス
このアジャイルの概念をハードウェアへ適用することを検討するには、従来のハードウェア開発プロセス (「ウォーターフォール」とも呼ばれる) の考察から始めると分かりやすい。ここでは Amazon Prime Air プロジェクトにインスパイアされた、宅配用ドローンの開発を例に挙げて説明していこう。
このドローンの基本的な要件: 最大 5 ポンド (2.27 kg) のパッケージを半径 10 マイル (16 km) の範囲に (注文から配達まで) 30 分以内で届けることが可能。安全かつ政府規制に適合しており、販売者とカスタマーの両方に配送状況を通知する必要がある。
ウォーターフォール モデルを採用したチームでは、ドローン開発の大半はリニアなプロセスになる。設計 (Design) > 製造 (Make) > 運用 (Use) の各段階は、その前の段階が完了しなければ開始されない。製品が満たすべき要件や規制など詳細な仕様は、最初に定義されて「設計」段階へ送られ、そこで代替策が作成、分析される。選択されたデザインは「製造」段階に投入され、そこで製品の生産が計画、実行される。最終的なドローンを顧客に対して展開することで「運用」段階がスタートする。ここにはドローンの運用やサービスが含まれる。
実際には、このように厳密なリニア プロセスで実行されることはほとんどなく、チームは何度かの反復を含む、より回りくどいプロセスに従って進むことが多い。顧客のフィードバックを得る機会はあっても、それは所定の段階内に留まる。例えば、ドローンは設計段階中に何度かの反復を経験し、また「製造」段階ではさまざまな生産オプションが検討される。これはリニア モデルの改良版とも呼べるが、やはりウォーターフォール (「スクラムフォール」と呼ぶ人もいる) であることに変わりはない。
いずれにせよ、ウォーターフォール アプローチには、以下のような 3 つの大きな欠点がある:
1. 要件に変更が生じないことが前提
ウォーターフォールは、変更や不測の事態への対処することなく計画と実行が行えるような、予測可能なプロセスに依存している。顧客の要件は、プロジェクトの初期に固定される。だが、要件に変更が生じないという予測が正しいことは、ほとんどない。新たなテクノロジーや発見、市場の変動によって、何らかの変化がもたらされる運命にあるのだ。
2. 顧客からのフィードバックを得ないまま、長い時間がかかり過ぎる
ウォーターフォールでは、顧客との意思疎通のほとんどが、チームによる要件設定時に前倒しされる。製品仕様文書が完成して (固定されて) から、チームは作業に取りかかる。だが、顧客が自身の望むものをプロジェクトの初期段階で正確に把握できていることはほぼないので、間違ったものを、間違った価格で、間違ったタイミングで製造する格好のレシピとなってしまう。それが、たとえ仕様に合致したものであったとしても。
3. ビルドしないまま考察が進む
ウォーターフォール モデルによる設計は、プロジェクトが「設計」段階から「製造」段階へと移行すると、ほぼ固定されてしまう。だが、チームはデザインに影響を及ぼす可能性のある事項を、恐らくは「製造」段階で知ることになる。また顧客は設計が固まる前に「実際の」製品を一度も目にすることがないため、これらが問題となる。固定されたデザインに変更を加えることは難しく、コストもかかる。
こうした欠点を、先ほどのドローンの例で考察してみよう。プロジェクト開始から数週間後、競合他社が 10 ポンド (4.54 kg) のパッケージを 20 分で運搬できるドローンを開発していると、顧客が知ったとしよう。顧客の設計は「完了」しており、チームは既に「製造」段階の真っ只中にいる。競合他社に匹敵するような要件変更は、ドローンの構造の再設計、認可用の解析の再実行、製造計画のやり直しなどを意味する。これは痛い！
さらに、チームはさまざまな形状のパッケージを運搬できるドローンを想定していたが、作成、解析、レンダリング済みの 5 種のデザイン案を提示したところ、このドローンは固定サイズの防水コンテナ内にパッケージを入れて運搬することを想定していると顧客が明かしたとしたら？ 顧客からのフィードバックがないばかりに、かなりの時間とリソースが無駄になる。
また「製造」段階になって、形状に少し変更を加えたり、ジェネレーティブ デザイン を活用したりすることで、3D プリントにより構造の製造が可能になるかもしれないと、デザイナーが閃いたとしたら？ 構造を 3D プリントすることで重量と組立時間を削減できるが、固定されている設計内容の変更には大きなコストがかかる。ウォーターフォールでは、こうなると三振アウトだ。
アジャイルに触発されたプロセス
こうした欠点を考慮すれば、ハードウェア開発にアジャイルを無差別に「応用」するという誘惑には、耐えることが重要だ。その代わりに、ハードウェア向けに調整された、以下のような幾つかのアジャイル的な (主にスクラムからの) 実践と原則が、より道理に適っているだろう。
1. スプリント反復
スプリントがハードウェア製品開発へ最もポジティブな影響を与えるのは、ほぼ間違いない。より早い段階で、より迅速に「設計 – 製造 – 運用」のサイクルを進め、設計段階のより細分化をチームに強制するからだ。プロセスは左から右へと進行する。スプリントはウォーターフォールの 3 つの問題全てに対処する。チームが間違った方向へ長期間に渡って進むのを防ぎ、「考察」と「構築」の間の時間を短縮して、各スプリントで判明したことに基づき要件を修正する機会を提供する。
もうひとつの利点は、設計上の重要な決定をプロジェクトの遅い段階へスケジュールできる柔軟性だ。ウォーターフォール モデルでは、全てのデザイン決定は製造へ進む前の「設計」段階でなされる。アジャイルベースのチームの場合、重要な情報を収集するため、数回後のスプリントまで幾つかの決定を先送りできる。
2. 製品要件文書をいつでも変更可能
要件は優先されるプロダクト バックログ項目で決定される。その項目は、有用性が高く、実行可能で、1 スプリント内で達成できる規模であり、ある程度の融通が利き、検証可能なものでなければならない。また、「誰」、「何」、「なぜ」が取り込まれている必要がある。「製品に何をさせたいのか？」ではなく (これでは単調な要件リストが生まれるだけだ)、「製品で何をしたいのか？」を問うべきなのだ (そうすれば検証可能な使用事例が生まれる)。
3. コラボレーティブなチーム
アジャイルは、製品開発チームの構成と役割を根本的に再定義する。アジャイルでは、部門 (デザイン、分析、製造など) によって分類されたチームではなく、部門の枠を超えて機能し、自立し、自己管理されたコラボレーティブな小規模チームが推奨されている。チームは、プロダクト バックログ項目を、指定のスプリント内で完了する責任を負う。スクラム チームは、例えばプロダクト オーナー (「何」の部分を担当) とスクラム マスター (「プロセス」を担当)、開発チーム (実際の開発を行う) のみで構成される。[編注: 詳細は「スクラムガイド日本語版 (PDF)」を参照]
4. プロセスを通じて細分化された成果を提供
アジャイルのハードウェアへの適用に反対する人は、ハードウェアはソフトウェアとは異なり、各スプリントの最後にリリース可能な成果物を生成することは、経済的にも実用的にも不可能だと主張する。だが、これは的外れな指摘だ。物理的な成果物は、段階的進展への唯一の道ではない。コンピューター シミュレーションや VR によるデモ、デジタル ツイン、コンセプト プロトタイプなどは、全て有益な成果物だ。重要なのは、チームが各スプリントの最後に有意義な成果物をリリースできるよう、プロダクト バックログ項目を細分化することだ。項目はさまざまな方法で細分化できる。例えば、合致レベル (概形から最終形まで) 、バーチャル対フィジカルのレベル、ユーザーの役割などだ。
実践におけるアジャイル
ドローン チームがウォーターフォール モデルで抱えた問題は、アジャイルに触発された実践で防ぐことができた可能性がある。まず、要件の変更に起因する設計への影響は、スプリントの賢明な計画と実行、プロジェクト後半で構造を扱うことで、最小限に抑えられたかもしれない。そして、ドローンがさまざまな形状のパッケージを扱うという (間違った) 仮定を、より早期に発見、修正できたかもしれない。また、ドローンの構造を 3D プリントできるかもしれないという認識に、もっと早い時期に到達できたかもしれない。
これは悪くなさそうだ。だが、アジャイルも完璧ではない。アジャイルの実践は、適切に実行されなかったり、意味を成さない箇所に適用されたりすれば、うまくいかないこともある。だがスプリントを活用し、仕様ではなくストーリーを模範としてチームに力を与えることは、ハードウェア製品開発をより「アジャイル」 (機動的) なものにする優れた開始点となる。