成功体験が重荷となる製品開発プロセス(その1)

更新日

投稿日

◆ 現状の課題

 
 スマートフォンの開発マネジメント支援を行った経験から、従来の製品開発のやり方を踏襲した改善では問題の根本解決は難しいと強く感じました。スマートフォンは、ビジネス形態、市場、競合、部品などの製品開発を取り巻く環境が激変した特別な製品と思えるかもしれませんが、ここで起こっていることはいずれも、多くのセットメーカーが直面する課題だと思います。今回は組み込みソフトウェアを中心に、スマートフォン開発で起こったことを事例として解説します。
 
技術マネジメント
 

1. これまでの組み込みソフト開発

 
 多くの組み込みソフトの開発現場では、品質最優先の方針のもとで開発プロセスの整備と運用に力を入れてきました。QCやISOの影響と思われますが、開発プロセスは各社個別であるにもかかわらず、共通している特徴があります。たとえば、次のようなことです。
 
(1) 設計重視/設計書重視
 開発上流での品質確保が重要なため設計書作成を徹底させる。
 
(2) レビュー重視
  設計段階からレビューを徹底させることで上流からの品質を確保する。
 
(3) 工程ごとの品質ゲート重視
 第三者が工程ごとの作業の正当性を確認して次の工程に移行する。
 
 実際、これらの考え方や仕組みは、組み込みソフトの品質を高めてきました。いわゆる成功体験、成功事例ということができるでしょう。
 

2. 組み込みソフト開発を取り巻く新しい状況

 
 スマートフォンでは、Android などのオープンソース・ソフトウェア(以下、OSS)の採用、Wi-Fi や NFC などの通信機能の高度化、各種機能部品の複雑化、そして、開発期間の大幅な短縮など様々な変化が起きています。とくにネットワーク機能は、携帯電話に限らず今後も様々な機器で重要になり、高度化、多様化していくのは避けられないと考えられます。さらに、その技術進展はとどまることなくよりスピードを増していくことでしょう。
 
 一方、このようなネットワーク機能は開発現場にとっては大きな重荷であり、その負担を軽減するために Android などの外部ソフトを採用せざるを得なくなります。次の記事は、ネットワーク機能のように進化が早い技術に対してはOSSが有利であることを述べています。
 

【主役交代 ~ ITの未来はOSSが決める】

 
 この記事自体は組み込みソフトの話ではありませんが、このようなネットワーク機能は組み込み製品にも徐々に採用されていくと思われます。また、OSS に限らず様々なデバイスドライバーや、他社ソフトを組み込みは増加する一方です。つまり、組み込みソフト開発は外部依存度が大幅に高くなっており、それがもっとも進んでいるのがスマートフォンだと言えます。
 

【高い外部依存度が引き起こす組み込みソフト開発の課題】

 
 他社からの購入ソフトの採用は従来から行われていることで、課題も従来からの延長と考えることもできますが、次の2つは新しい課題ととらえて対応を考える必要があると思います。
 

(1) As-Isの幻想

 
 Androidがスマートフォンに採用された当時は、Androidはそのまま使うことができるので(As-Isで大丈夫なので)、ソフト開発はとても楽なものになると判断し、そのような開発体制や開発計画を組んでいたメーカーは少なくありませんでした。しかし、他社との差別化や採用するデバイスの都合などの理由により、As-Isでは製品として成り立たず、Androidの内部まで手をつけることになってしまいました。その結果、予定していたようには開発は軽減できず、大幅な計画変更を余儀なくされました。さすがに、今のスマートフォンはAndroidを採用して数世代経っているので、As-Is幻想はなくなっていますが、これから新たに Androidを採用する計画がある場合には十分な検討が必要です。
 

(2) 開発プロセスの破綻

 
 いまだ十分な対応ができていない、いや、問題を十分に把握できていないと思うのが開発プロセスの課題です。「これまでの組み込みソフト開発」で述べた従来の強みを活かすことができないのです。
 
 早い技術進化に対応するのが OSS であり、Android 採用の大きなメリットのひとつはそこなのですが、反面、最新の Android は品質や完成度が安定するのが遅くなります。通常、リリース直後の最新バージョンの Android を採用することになると思いますが、製品開発の間は Android の品質や機能は安定せず、その間、大規模なバージョンアップが行われたり、頻繁にパッチが発行されたりして、製品開発チームはそのたびに、新しいものを組み込むことになります。また、バージョンアップにしてもパッチにしても、どこが変わったのかという詳しく正確な情報はありません。
 
 他社からの購入ソフトについても、並行して開発が進んでいるものを購入するケースが多く、やはり、新しいバージョンやパッチがリリースされて対応せざるをえないことになっています。
 
 そして、このような状況は次のような問題が引き起こしています。
 

【段階的品質積み上げの破綻】

 
 単体テスト、結合テスト、システムテストと段階的に品質を積み上げていってもバージョンアップやパッチのたびに動かなくなり(デグレが起き)、品質は振り出しに戻る。
 

【設計重視の破綻】

 
 Android はソースコードで提供されるとはいえ、その内部構 造や動作を把握することは困難で、実質ブ...

◆ 現状の課題

 
 スマートフォンの開発マネジメント支援を行った経験から、従来の製品開発のやり方を踏襲した改善では問題の根本解決は難しいと強く感じました。スマートフォンは、ビジネス形態、市場、競合、部品などの製品開発を取り巻く環境が激変した特別な製品と思えるかもしれませんが、ここで起こっていることはいずれも、多くのセットメーカーが直面する課題だと思います。今回は組み込みソフトウェアを中心に、スマートフォン開発で起こったことを事例として解説します。
 
技術マネジメント
 

1. これまでの組み込みソフト開発

 
 多くの組み込みソフトの開発現場では、品質最優先の方針のもとで開発プロセスの整備と運用に力を入れてきました。QCやISOの影響と思われますが、開発プロセスは各社個別であるにもかかわらず、共通している特徴があります。たとえば、次のようなことです。
 
(1) 設計重視/設計書重視
 開発上流での品質確保が重要なため設計書作成を徹底させる。
 
(2) レビュー重視
  設計段階からレビューを徹底させることで上流からの品質を確保する。
 
(3) 工程ごとの品質ゲート重視
 第三者が工程ごとの作業の正当性を確認して次の工程に移行する。
 
 実際、これらの考え方や仕組みは、組み込みソフトの品質を高めてきました。いわゆる成功体験、成功事例ということができるでしょう。
 

2. 組み込みソフト開発を取り巻く新しい状況

 
 スマートフォンでは、Android などのオープンソース・ソフトウェア(以下、OSS)の採用、Wi-Fi や NFC などの通信機能の高度化、各種機能部品の複雑化、そして、開発期間の大幅な短縮など様々な変化が起きています。とくにネットワーク機能は、携帯電話に限らず今後も様々な機器で重要になり、高度化、多様化していくのは避けられないと考えられます。さらに、その技術進展はとどまることなくよりスピードを増していくことでしょう。
 
 一方、このようなネットワーク機能は開発現場にとっては大きな重荷であり、その負担を軽減するために Android などの外部ソフトを採用せざるを得なくなります。次の記事は、ネットワーク機能のように進化が早い技術に対してはOSSが有利であることを述べています。
 

【主役交代 ~ ITの未来はOSSが決める】

 
 この記事自体は組み込みソフトの話ではありませんが、このようなネットワーク機能は組み込み製品にも徐々に採用されていくと思われます。また、OSS に限らず様々なデバイスドライバーや、他社ソフトを組み込みは増加する一方です。つまり、組み込みソフト開発は外部依存度が大幅に高くなっており、それがもっとも進んでいるのがスマートフォンだと言えます。
 

【高い外部依存度が引き起こす組み込みソフト開発の課題】

 
 他社からの購入ソフトの採用は従来から行われていることで、課題も従来からの延長と考えることもできますが、次の2つは新しい課題ととらえて対応を考える必要があると思います。
 

(1) As-Isの幻想

 
 Androidがスマートフォンに採用された当時は、Androidはそのまま使うことができるので(As-Isで大丈夫なので)、ソフト開発はとても楽なものになると判断し、そのような開発体制や開発計画を組んでいたメーカーは少なくありませんでした。しかし、他社との差別化や採用するデバイスの都合などの理由により、As-Isでは製品として成り立たず、Androidの内部まで手をつけることになってしまいました。その結果、予定していたようには開発は軽減できず、大幅な計画変更を余儀なくされました。さすがに、今のスマートフォンはAndroidを採用して数世代経っているので、As-Is幻想はなくなっていますが、これから新たに Androidを採用する計画がある場合には十分な検討が必要です。
 

(2) 開発プロセスの破綻

 
 いまだ十分な対応ができていない、いや、問題を十分に把握できていないと思うのが開発プロセスの課題です。「これまでの組み込みソフト開発」で述べた従来の強みを活かすことができないのです。
 
 早い技術進化に対応するのが OSS であり、Android 採用の大きなメリットのひとつはそこなのですが、反面、最新の Android は品質や完成度が安定するのが遅くなります。通常、リリース直後の最新バージョンの Android を採用することになると思いますが、製品開発の間は Android の品質や機能は安定せず、その間、大規模なバージョンアップが行われたり、頻繁にパッチが発行されたりして、製品開発チームはそのたびに、新しいものを組み込むことになります。また、バージョンアップにしてもパッチにしても、どこが変わったのかという詳しく正確な情報はありません。
 
 他社からの購入ソフトについても、並行して開発が進んでいるものを購入するケースが多く、やはり、新しいバージョンやパッチがリリースされて対応せざるをえないことになっています。
 
 そして、このような状況は次のような問題が引き起こしています。
 

【段階的品質積み上げの破綻】

 
 単体テスト、結合テスト、システムテストと段階的に品質を積み上げていってもバージョンアップやパッチのたびに動かなくなり(デグレが起き)、品質は振り出しに戻る。
 

【設計重視の破綻】

 
 Android はソースコードで提供されるとはいえ、その内部構 造や動作を把握することは困難で、実質ブラックボックスとして扱わざるを得ない。そのため、机上での設計やレビューを徹底しても設計検証にはヌケ・モレを生じる。
 

【工程ごとの品質確認の破綻】

 
 頻繁なパッチに対応するために何度も同じテストを実施する必要がある。回帰テストの実施も従来以上に重要になる。そのため、工程ごとの作業や成果物確認では製品全体の品質確保は難しい。
 
技術マネジメント
 
 このような問題は、小手先、あるいは、現場任せで対応できるものではなく、開発プロセスや開発マネジメントを根本的に変える必要があると考えます。さらに、頻繁なバージョンアップやパッチは Android に限らず OSS や外部購入ソフトに一般的な傾向なため、対応は加速度的に複雑になります。
 
 以上、外部依存度が上がっていることを前提とした新しい開発プロセスを構築する必要があると考えていますが、いかがでしょうか、対策については次回、解説します。
  

   続きを読むには・・・


この記事の著者

石橋 良造

組織のしくみと個人の意識を同時に改革・改善することで、パフォーマンス・エクセレンスを追求し、実現する開発組織に変えます!

組織のしくみと個人の意識を同時に改革・改善することで、パフォーマンス・エクセレンスを追求し、実現する開発組織に変えます!


「技術マネジメント総合」の他のキーワード解説記事

もっと見る
製品設計における文書化の重要性とは

1.製品設計において、文書化は重要  ビジネスの様々な場面において、文書にして残すこと(文書化)の重要性は多くの人が理解していることだと思います。製...

1.製品設計において、文書化は重要  ビジネスの様々な場面において、文書にして残すこと(文書化)の重要性は多くの人が理解していることだと思います。製...


位置関係-1 普通の組織をイノベーティブにする処方箋 (その104)

   現在、KETICモデルの中の「知識・経験を関係性で整理する」を解説しています。随分長く「関係性」の解説をしてきました。前回は「『解決...

   現在、KETICモデルの中の「知識・経験を関係性で整理する」を解説しています。随分長く「関係性」の解説をしてきました。前回は「『解決...


環境 普通の組織をイノベーティブにする処方箋 (その42)

        現在、この連載ではマクロ環境分析の解説をしていますが、今回は、PESTEL(Politica...

        現在、この連載ではマクロ環境分析の解説をしていますが、今回は、PESTEL(Politica...


「技術マネジメント総合」の活用事例

もっと見る
ソフト開発計画の作成方法 プロジェクト管理の仕組み (その5)

 前回のその4:プロジェクトの進捗管理に続いて解説します。前回は CMMI を使い、要件管理、計画作成、進捗管理のポイントを紹介しました。多くの開発組織で...

 前回のその4:プロジェクトの進捗管理に続いて解説します。前回は CMMI を使い、要件管理、計画作成、進捗管理のポイントを紹介しました。多くの開発組織で...


マトリクス体制での品質保証2 プロジェクト管理の仕組み (その31)

 前回のマトリクス体制での品質保証1に続いて解説します。品質計画は、製品開発に必要となる手順やリソースが誰によっていつ適用されるかを明確にした個別製品の開...

 前回のマトリクス体制での品質保証1に続いて解説します。品質計画は、製品開発に必要となる手順やリソースが誰によっていつ適用されるかを明確にした個別製品の開...


技術資源の有効活用: 事例紹介 (その1)

 今回から2回に分けて、TRMによる活動の事例紹介をいたします。TRM(Technical Resource Management)は自社が保有する潜在的...

 今回から2回に分けて、TRMによる活動の事例紹介をいたします。TRM(Technical Resource Management)は自社が保有する潜在的...