組込みソフト開発におけるプロセス改善

ソフトウェア開発の品質向上に関してプロセス改善が大事という話をよく聞くが、開発の現場にいるときはその重要性についてピンと来ていなかった。

しかし、自分が現場のソフトウェアプロジェクトを支援する側に回って初めてソフトウェア開発のプロセスを定義し実践することが大事だということに気がついた。

組込み製品の生産現場では工程を管理することがとても大事である。工程管理なしに生産品の品質確保はありえない。

また、電気系、機械系の設計においても無限に試作を繰り返すことはできないし、設計を終了し生産を移管するに当たっては使用する部品を決定する必要もあるため、自然と回せるプロセスの回数が決まってくる。

ところが、ソフトウェア開発の場合は明確に工程を設定しなくても「もの」はできる。商品が倉庫に入る前までなら極端な話、無限に修正を繰り返すことができる。

このブログで何度も書いているように、だからこそ規模の小さい組込みソフトウェア開発では試行錯誤的な開発が横行しプロセスが定まらない。設計・分析してから実装するという順番を踏むことができない組込みソフトウェアプロジェクトが数多く存在する。

でも、小規模なプロジェクトで優秀なエンジニアが集まっていると、プロセスを定義しなくても、分析→設計→実装→検証というプロセスを2回から3回回して、かつ、その中で再利用資産も構築するといったことがリーダーの指示とコミュニケーション能力の範囲で可能である。

そんな感じのプロジェクトで商品開発をやっていると、なぜ「プロセス、プロセス」とうるさく言われるのか理解できない。

ところが、そんな現場を離れてうまくいっていないプロジェクトを第三者的に俯瞰するようになると、ソフトウェア品質の確保のためにプロセスの定義が必要であることが分かってくる。

組込みソフトウェアの場合は、すり合わせ的な試行錯誤の開発スタイルから歴史が始まっていることもあって、第三者がだまっていると工程の切れ目ができない。ずるずるの開発になりがちである。（過去の記事：ソフトウェア開発工程の区切りが見えない）

電気系・機械系の試作品作りのためのバトンタッチとなる出図（電気回路や機械図面を確定して業者や生産部門に移管する）という行為・セレモニーがソフトウェア開発にはないため、ソフトウェアは踏ん切りがつきにくい。

だからこそ、プロセスを定めてプロセスの切れ目でレビューや設計審査を行うのだが、これがまた形骸化しやすいという問題がある。

組込みソフトでプロセスを定義して、工程と工程の区切りを明確にし、プロセスのインプットとアウトプットが問題ないことを検証するためには、ソフトウェア開発プロジェクトのメンバーにプロセスの存在やプロセスのインプット、アウトプット、そのプロセスで実施すべきアクティビティやタスクを示す必要がある。

言って聞かせることも必要だが、実質的にはプロセスを絵に描いて見せることが必要だと思う。レビューや審査を他部門を呼んで実施するするのならなおさらプロセスチャートを書かないと、関係する部門全部にプロセスの存在が伝わらない。

人間は基本的にはシーケンシャルなつながりで物事を記憶する。だから、それぞれの担当部門の実施すべきアクティビティの手順を示し、どこ時点で他部門と接触するのかを示してあげることで、組織として何をすればいいのか初めて理解されることが多々ある。

多くの部門にまたがって仕事をしたり、調整したりする人でないと、このプロセスチャートはなかなか書けないし、開発の現場にいるとわざわざ他人の業務のことまで書く気にはなれない。

組込みソフトウェア開発では、プロセスを定義しなくても、無限に修正を繰り返していればいつの日かシステムを完成させることができる可能性がある。規模が大きかったり複雑性が高い場合は、品質が低かったり、開発日程が延びたり、エンジニアが死ぬほど残業したりすることもあるが、最終的にリリースにこぎ着けることも少なくない。この成果はいたずらに権利を主張せず、商品をリリースするために寝食を惜しんで働く日本人の気質がなせる技かもしれない。

しかし、このような試行錯誤のアプローチでは、大規模組込みソフトウェアの品質を保持し、開発効率を高めることはできないし、組込みソフトエンジニア自身がクリエイティブな仕事をすることはできない。結果として幸せになることはできない。

大規模組込みソフトウェア開発では、ソフトウェアの開発計画を立案することも、ソフトウェア要求を分析し定義することも、要求を実現するアーキテクチャを設計することも必要である。

それなしに曖昧なまま見切り発車すれば、必ず出荷間際にバタバタするし、結果的に価値の高い商品、顧客満足の高い商品にならないケースが多い。

この問題を回避するためには、組込みソフト開発において、組織としてプロセスを定義し、各プロセスで実施すべきアクティビティやタスクが何かを明らかにする必要がある。

もちろん、定義しただけではダメで、プロセスチャートを示して、プロセスの必要性を理解させ、きちんとできているかどうか監視もしないといけない。

ちゃんとできていないプロジェクトほど、プロセスの必要性を理解しない。分析・設計してから実装するのではなく、いきなり実装を始めてしまう。

だからこそ、なぜ組込みソフトウェア開発においてプロセスアプローチが必要なのかを開発現場に説く必要がある。支援部門に移って、そのことが初めて分かった次第である。

ソフトウェアの設計者の立場からすると、開発の工程はあまり内外に宣言はしたくない。なぜなら、ソフトウェアの最大の特長でもある変更容易性の切り札はいつでも取っておいて、プロセスを何回回すのかはプロジェクトリーダーの権限で自由に決めたいからだ。開発の工程や手順を変える権限を握っているという状態はプロジェクトリーダーとしては気分がいいものだ。

でも、それでうまくいくのは少数精鋭の比較的規模の小さいソフトウェアプロジェクトであり、メンバーの人数が10人を超えるようなプロジェクトでは、プロジェクトリーダーが頭の中で考えているプロセスの区切りはメンバー全員に伝わらない可能性が高い。

自分のソフトウェア設計者としての感覚では、ソフトウェア開発の手順を組織に強制されるのはあまりいい気持ちがしない。「クリエイティブな仕事をしている者に縛りは無用」といいたいところだ。

エンジニアに限らずその道のプロフェッショナルと呼ばれる人々は、常にクリエイティブであるために感受性を高め、アンテナを張り巡らし、創造のためのモチベーションを維持しようとしている。多くの場合、プロフェッショナルクリエーターは自分にも他人にも厳しく、独善的でもある。ソフトウェアエンジニアの場合も同じだろう。えせプロフェッショナルエンジニアも含めてクリエイティブな仕事を追求してい技術者は独善的な部分を持っており、手順を強制されるのを嫌がる。

だからこそ、ビジネス系のソフトウェア開発の世界ではアジャイル的な開発スタイルが考え出され、ウォーターフォールプロセスとの折衷案のような、イテレーションのプロセスが提案されているのだと思う。

クリエイティブなエンジニアが手順を強制されるのを嫌がるという事実はあるとしても、組込みソフトの品質を向上させ、プロジェクトメンバー全員が今現在のプロジェクトの状態を把握して、それぞれの役割を認識するためにはプロセスの定義は必要だと感じる。

プロセスを設計してそれをキチンと実施することは組込みソフトウェアの品質が高いことを示す一つの材料となる。組込みソフトウェアシステムにおける潜在的な価値が高いことを内外に示すためには、どんな工程を経てソフトウェアが作られてきたのかを説明する責任がある。

日本の組込みソフト開発の現場にはそのことをまず理解してもらわないといけない。ソフトウェアの設計者としては「プロセス改善」ということばに違和感や「余計なお世話」という感覚を覚えがちだけれども、そう主張する人達には「それでは、あなたたちが作ったソフトウェアの品質が高いということはどうやって証明できるのですか」と聞きたい。

「十分にテストしている」などと答えるようでは、20年前の組込みソフト開発から進化していない。

組込みソフトウェア開発では、ソフトウェアシステムに科せられた必達の要求がソフトウェア要求仕様書に定義され、そこに定義された項目が漏れなく検証工程で検査されているはずである。

テストするには、その基となる要求仕様が必要だ。要求仕様が何であるかを尋ねて「それは技術者の頭の中にあります」という状況では、必達の要求が確実に検証・妥当性確認されているのかどうかわからないし、証明もできない。

大規模・複雑化した組込みソフトウェア開発の組織は、ソフトウェアの開発計画段階で開発のプロセスを設計し、途中で見直しを加えながらも設計したプロセスに沿って開発を進めていくことが求められているし、それを実行しなければ、ソフトウェアの品質を保つことも品質が高いこと示すこともできない。

現場のソフトウェアプロジェクトを支援する立場、ソフトウェア品質が確保されていることを内外に示す立場になって、そのことが実感として感じられるようになった。

どんなにすぐれた組込みソフト技術者であっても、「自分が作っているのだから安心してくれ」という説明で納得してもらえる時代は終わった。