ハードウェアとソフトウェアの境界を越えたチームをセットアップして開発を統合しようとする場合、重要になるのが、ハードウェアとソフトウェアの開発者が互いのことばで話をすることだ。"我々(we)"と"彼ら(them)"ではなく"私たち(us)"に、アジャイルやリーンの用語よりも開発者同士をつなぐ技術的能力に、重点を置くことが望ましい。
Eva Hedin氏は、Agile Tour London 2021で、ハードウェアと組み込みソフトウェアの開発作業を、クロスファンクショナルに実施する方法について講演した。
最大の課題は、ソフトウェアとハードウェアの開発者の間で理解を得ることだ、とHedin氏は言う。同じ開発者であっても、我々は、言わばパラレルワールドの住人なのだ、と氏は説明する。
- 言語 — ソフトウェアとハードウェアでは、使用することばや略語が違う。同じ単語や略語を違う意味で使う場合もあれば、似ているが正確には同じでない場合もある。
- タイムライン — ソフトウェア開発者は短い開発サイクルで作業をする。ハードウェアの開発は製造に時間を要するため、これは不可能だ。
- プロトタイプのコスト — ハードウェアのプロトタイプ制作には費用が必要であるのに対して、ソフトウェアのプロトタイプは"無償"に近い。
ことばが違う例として、Hedin氏は"CI"を取り上げた。CIは、ソフトウェアでは"継続的インテグレーション(Continuous Integration)"の意味だが、ハードウェアでは"継続的改善(Continuous Improvement)"である。前者はソフトウェアとソフトウェアの統合であり、後者は動作方法を改善することだ、とHedin氏は説明した。統合(Integration)ということば自体も、微妙に意味が違う。ソフトウェアにおいては、ソフトウェアとソフトウェアの統合だが、ハードウェアでは、プロダクト(ハードウェア+ソフトウェア)の製品システムへの統合を意味するのだ。
リーンやアジャイルといった単語を使うのはやめて、プロダクトを開発する方法について語るべきだ、とHedin氏は提案する。
ソフトウェアでもハードウェアでも、この点は同じです — 私たちはプロダクトを開発しているのですから、それに最も適した作業方法であるべきなのです。それが何であるのかは、プロダクトがライフサイクルのどの位置にあるかによります。
"我々"と"彼ら"ではなく、常に"私たち"に重点を置くべきだ、とHedin氏は言う。開発に携わる人々は、技術的能力に関心を持つ技術者であって、リーンやアジャイルのボキャブラリに関心がある訳ではないのだ。
ハードウェアとソフトウェアの両方が関与するプロダクト開発について、Eva Hedin氏にインタビューした。
InfoQ: ハードウェアとソフトウェアを含むプロダクト開発において、クロスファンクショナルに作業する人たちを調べる中で、どのようなことが見えてきましたか?
Eva Hedin: 学ぶ、ということですね。お互いから多くのことを学びました。
ソフトウェアに従事する人たちは、プロダクトを小さな"部分"に分割して、短いサイクルで仕事をします。ハードウェア開発でこれを実現するのは難しいのですが、考え方やWoWを取り入れることはできます。例えば、ハードウェアが、現時点ではすべての機能を持っていないが、一部は後日実現する予定である、と顧客に伝えることは可能でしょう。
ハードウェア開発者はトラブルシュートのためにフィールドの反応を受け取っているので、プロダクトに関するカスタマエクスペリエンスを知っています。ハードウェアあるいはソフトウェアだけでなく、プロダクトを一体としてとらえる観点は、ソフトウェア技術者にはないものです。
例えば、現場でインストールや設定を行う場合、プロダクトの立ち上げは指示書に従って行われます。ソフトウェアのテストは、これらの要件から構築されるのです。いくつかのプロダクトでフィールドでの問題解決を経験したハードウェア開発者は、インストール担当者がどのような作業をして、実際にどうやってプロダクトをインストールするのかを知っています。初期のフィールドにおいて発生する微妙な問題に関するフィードバックは、トラブルシュートのためにハードウェア開発者に送られます。それによって彼らは、一般的なインストール障害のほとんどを知っていますから、プロダクトの立ち上げ時にフールプルーフテストを行うことで、このような問題への対応を確認するのです。テスタの多くは仕事を10年以上続けているので、とても経験豊富です。彼らの知識をソフトウエア開発者にフィードバックできれば、ソフトウェアはもっとレジリエントになります。
ソフトウェアとハードウェアの開発者が密接に連携して作業するようになると、さまざまな課題が発生して苦労することもありますが、それを克服できれば、プロダクトはよりよいものになるでしょう。問題の大部分は誤解や、仕事の方法の違いから生じています。その一例がインテグレーションです。ソフトウェアのインテグレーションが問題なく終了した後、ハードウェア担当者が来て"インテグレーションに障害がある"と言うことがあります。インテグレーションに対する目的が同じではないのです。ハードウェアのインテグレーションはソフトウェアとハードウェアの連携を確保することで、ソフトウェアのインテグレーションはレガシソフトウェア内でのソフトウェアの動作を保証することなのです。この問題は、ソフトウェアとハードウェアが関連性を持つ組織においては例外なく見られるものです。
InfoQ: アジャイルの価値感とリーンの価値感には、どのような相互関係があるのでしょう?
Hedin: アジャイルは米国のソフトウェア開発から生まれたもので、リーンは日本の自動車製造(Toyota)が発祥です。つまりこれらは、実際には異なる2つの文化なのです。
数年前に私は、アジャイルと同じような価値観をリーンに設定して、アジャイルとリーンを比較したことがあります。この2つの共通点をある企業に示したかったのですが、その企業はリーンを中心に置いていたので、次図のようにしました。リーンには14のマネジメント原則があり、リーン開発ではさらにいくつかの原則が追加されているので、議論を立ち上げるためにこのようにしたのです。
リーンとアジャイルのステートメントを比較すると、価値観に類似性のあることが分かります。
アジャイルの価値観:
リーンの価値観:
個人が重視されるのは日本よりも米国ですが、その一方で、リーンもアジャイルも人間指向である点は同じです。人が重要なのです。
この2つは、価値観にも関連性があります。
アジャイルの価値観:
リーンの価値観:
フローの最適化は"無駄時間"を削減する方法ですが、ドキュメントの削減もまた"無駄時間"を削減する方法なのです。
InfoQ: リーンとアジャイルはどうすれば連携できるのでしょう、また、組み合わせることによって、どのようなメリットが得られるのでしょうか?
Hedin: 物事をカテゴリに分けることが有効な場合もありますが、同時にそれは、私たちはひとつのチームではない、という印でもあります。
当社のプロダクトシステムは、多数のプロダクトを内包した複雑なシステムです。さらに、開発スピードが速いので、多くのものを並行して開発しなければなりません。プロダクト間のインターフェースを明確にしておくことが重要なのであって、プロダクトを開発する人々の間がそうなのではありません。
InfoQ: どんなことを学びましたか?
Hedin: 今でも、たくさんのことを学んでいるのですが、その中で重要なのは、"開発において何よりも重要なのは、そこで働く人たちである"ということです。
もうひとつは、ことばの大切さです。適切なことばを使って、それが私にとって何を意味するのかを説明することは、すべてにおいて基本なのです。