組込みソフトウェア開発の悪循環のシナリオを考えてみた。想定する具体的なシチュエーションを示してから、その問題の解決方法について考えていきたい。【組込みソフト開発悪循環のシナリオ】
1970年代、組込み機器開発の世界で、ソフトウェアはハードウェアとハードウェアをつなぐつなぎ役だった。組込み機器にはセンサーやアクチュエータが使われ、これらをいかにうまく制御して、顧客満足の高い製品を作ることができるかどうかが組込みソフトエンジニアの腕の見せ所だった。組込みソフトエンジニアという職種は確立しておらず、エレクトロニクスの勉強をしてきた技術者がマイコンのアセンブラを覚えて制御ソフトを書いていた。ソフトウェアの規模はせいぜい1000行くらい。ソフトウェア技術者はプログラムを試行錯誤で作り、実機レベルでランダムテストを行い実機で検証をしていた。
※好循環の道を歩むソフトウェア技術者はフローチャートやブロック図を描いてソフトウェアの構造を分析していた。その程度でなんとかなるくらいの規模だった。構造化プログラミングを意識している者もいた。
1980年代、8ビット、16ビットのCPUが次々と登場し、さまざまなペリフェラルデバイスが組み込まれたワンチップマイコンを組込み機器に使うことが多くなってきた。ソフトウェアを記述する言語はC言語が主流となり、リアルタイムOSも徐々に普及しはじめ、ハードウェアエンジニアとソフトウェアエンジニアは職種を分けるようになってきた。リアルタイムOSが普及することにより、ソフトウェアエンジニアがソフトウェアをモジュールに分割することを考えなければいけなくなる。悪循環の道を歩むソフトウェア技術者は相変わらずプログラムを試行錯誤で作り、実機レベルでランダムテストを行い実機で検証をしていた。LCDなどの表示用のユーザーインタフェースデバイスも普及し、プログラムサイズは数千行くらいに増加していた。
※好循環の道を歩むソフトウェア技術者はソフトウェアの振る舞いについて分析する際に状態遷移図や状態遷移表、データの流れを考えるために構造化分析手法が使っていた。
1990年代、組込み機器におけるユーザーインタフェースは飛躍的に向上し、スタンドアロンで動くだけでなく他の機器と通信をしたり、ネットワークにつながったりするようになった。CPUも16ビット32ビット64ビットと次々に高性能なものが登場し、ソフトウェアの規模が数万行になっても処理はオーバーフローしなくなっていた。悪循環の道を歩むソフトウェア技術者はソフトウェアの規模が数万行になっても相変わらずプログラムを試行錯誤で作り、実機レベルでランダムテストをしていた。コードレビューも言葉は知っていたがプロジェクト内で習慣化するところまでには至っていなかった。ソフトウェアシステムの増大の対応策としては、過去に使ったソフトウェアの一部を流用したり、前回担当した機能を作った技術者を今回もアサインするなど、特定の技術者に役割を分担させ、その技術者を何世代もの製品開発に使い続けるというアプローチを取った。そのため、社員や協力会社の社員が担当から外れるととたんに開発の効率や品質が下がったりした。担当者を外したプロジェクトマネージャ本人もその原因がよく分かっていなかった。
ソフトウェアの規模が数十万行にもなり、複雑度が高くなって、分かりにくいバグが増えてきた。ソフトウェア開発の工程が進めば進むほど、ソフトウェア技術者の残業が増えるようになり、新しい技術を学ぶ余裕がなくなってきた。
※好循環の道を歩むソフトウェア技術者は、ソフトウェアの大規模・複雑化に対して何か手を打たなければいけないと気づきはじめ、ソフトウェアシステムをサブシステムに分割する方法や、サブシステム同士のインターフェースをきちんと決めて役割を分担するなどくふうをするようになる。
2000年代、組込み機器にも多様な要求が降りかかってきて、組込みソフトの規模も数万行から数百万行まで幅広くなってきた。規模が大きいソフトウェアシステムほどプロジェクトが遅れたり破綻したりするようになる。ソフトウェアエンジニアの残業時間はピークに達しており、月あたりの残業時間が100時間、200時間という者も増えてきた。しわ寄せは、特に下請け、孫請けの協力会社の技術者がかぶることが多く、ソフトウェア技術者になりたくないと考える若者も増えるようになる。失敗プロジェクト、開発日程の大幅遅延プロジェクトの開発スタイルと見ると、1970年代と同じプログラムを試行錯誤で作り、実機レベルでランダムテストを行い検証をしていた。設計工程の後半で発生する月に100件以上のバグのうちのいくつかは非常に分かりにくい複数のモジュールが関係する不具合であり、数日もしくは一週間以上かけないと原因がわからないようなバグであった。
2000年代になると組込み機器のユーザーインタフェースも多種多様な表現方法ができるようになり、試作品ができた後に、試作器を手にしたステークホルダーが「もっと、こういうインタフェースにしよう」などと言って大幅な仕様変更を指示することも多くなるようになった。ソフトウェアプロジェクトにおいてプロセスを切って、確認してから前に進むことの必要性を認識していない上司（1970年代の試行錯誤でソフトウェアを作っていて特に問題が起こっていなかった世代）が上にいると、ソフトウェアの変更容易性から最後の最後で右に向いていたものを左にしろなどということがあった。
ここから、『熊とワルツを』（トム・デマルコ/ティモシー・リスター）より引用
・・・約束した納期に間に合わなくてもよい、大幅に遅れてもかわまないが、その日までの間、期日に間に合いそうにもないと言ってはならないということだ。事前に失敗するかもしれないことを認めるという大罪を犯さなければ、失敗は容認される。このルールを言い換えると、遅れたことに対して後から「赦し」を請うのはかまわないが、遅れることに対して前もって「許し」を求めてはならない。
：
このような制約があると、「選択的近視」という感染症になりやすくなることがある。この条件を突きつけられたプロジェクトでは、小さな問題しか見えない。健全なプロジェクトでは視野の真ん中に見えるようなおおきな問題がすぐそこに迫っていても、選択的近視にかかった人にはまったく見えない。
－引用終わり－
ソフトウェアプロジェクトのリーダーとメンバは、製品の開発計画を突きつけられたとき直感的に「（いままでの試行錯誤的な開発を行っていたのでは）この日程では間に合わない」と感じる。しかし、『熊とワルツを』にあるように、運がリスクを消し去ってくれるのではないかと期待している。期待するだけでリスクと正面から向かい合うことはしない。また、楽観主義（嘘をつくこと）があたりまえの環境でプロジェクトマネージャーだけが真実のリスクを話すと、「やる気がない」とか「あいつはネガティブだ」という烙印を押される。そういう環境ではその日が来るまで期日に間に合いそうにもないと言えないので、プロジェクトリーダーはダメだと分かっていても、その日まで最大限努力したというポーズを作ろうとする。メンバは組織上位層にポーズを取る必要はないが、期日に間に合わないことを知っているから、「組織は、また、無理な日程を押しつけている」と感じ、プロジェクトリーダーがかわいそうだと思いつつ残業を続ける。（あたたかい人間関係の中のやさしい一員の特徴） そして、プロジェクトメンバは組織上位層のことを「無理な日程を押しつけるソフトウェアを理解していない人種」と考え、ソフトウェア開発の現場でどんな問題が起こっているのか説明しても無駄だと考えるようになる。
この状況においてソフトウェア開発の現場がやっていることは、1970年代と同じ「試行錯誤的開発アプローチ」だけだ。場合によっては、構造化設計をちょっとだけやっていたり、ソフトウェアの構成管理だけに力を入れている状態かもしれない。いずれにせよ、ソフトウェアの規模・複雑化の増大に対する抜本的な対応は取っていないので、日程にも間に合わないし品質も上がらない。
この状態が長く続くと、組織上位層も原因は分からないが、ソフトウェア開発に問題があることに気がついてくる。品質に関する問題でお客さんに迷惑をかけることが多くなり、開発日程についても「事前に失敗するかもしれないことを認めるという大罪を犯さなければ、失敗は容認される」とは言えなくなってくる。
そうなると問題の矛先は特定の個人や協力会社に向いてくる。「やっぱりあいつじゃダメか」とか「あそこに仕事を出したのが間違いだった」ということになり、人やソフトウェアの発注先を入れ替えたりする。しかし、試行錯誤的な開発アプローチでは、ソフトウェアシステムの機能・責務の分割と割り振りを人ベースで行っているため、人の入れ替えは開発効率や品質悪化の原因になってしまう。
かくして、組込みソフトの開発は遅れに遅れ、品質は下がり、組込みソフトエンジニアの残業は増え、職種として若者から敬遠されるようになり、優秀であればあるほど仕事が降りかかってくるようになり、中にはプレッシャーに潰れてしまう者もでてくる。労働力を補充することで状況が打開できると勘違いする組織が協力会社や派遣社員に頼るようになり、技術的にも空洞化する。
これが、組込みソフト開発悪循環のシナリオ＆構図である。
【組込みソフト開発の悪循環から抜け出す方法】
組込みソフト開発の悪循環から抜け出す方法が簡単に分かれば苦労はしないが、悪循環脱出のきっかけは特に組込みソフトの歴史や日本人の特性を考えると、「意識改革」と「技術導入」をセットで進めることが重要ではないかと最近考えている。テーマは多すぎると散漫になるので3つだけだ。
－組込みソフト開発の悪循環から抜け出すためにすべきこと－
- 品質文化と設計の規範の確立
- 価値観の一致
- 試行錯誤的アプローチからの脱却
<品質文化と設計の規範の確立>
組織やプロジェクトに品質文化がないとルールは形骸化し新しい方法論は難しいからイヤだと敬遠される。また、設計の規範がないと、過去に発生した問題を教訓にすることができず、プロジェクトリーダーが技術的なリーダーシップを発揮することができない。
品質文化と設計の規範の確立という「意識改革」の具体的施策の第一歩としては、ソースコードの行数を数えグラフを描いて可視化し、不具合（バグ）を紙や電子的に管理することをおすすめする。ちなみに、この2つがキチンと行われていない状態から習慣・慣習化するのはとても大変なことである。もしも、この2つがクリアできたなら、変更管理、構成管理についてできるようにしよう。
品質文化と設計の規範の確立におけるポイントは、どんな小さなことでも習慣・慣習化するまであきらめないことだ。
<価値観の一致>
次のテーマは価値観の一致だ。悪循環のシナリオに書いたように、問題は組織上位層とプロダクトマネージャ、ソフトウェアプロジェクトリーダー、プロジェクトメンバ間の間で、言葉が通じ合っていないことに原因がある。
ソフトウェア特有の言葉や環境が通じないから説明しても無駄だと感じ、上はとんちんかんな要求をし、下は無視（最初から無理だと考え思考停止）し、中間層は板挟みになって苦しんでいる。
この状態を打開するには、この三者が共通の価値観のもとに問題に正面から向き合わなければいけない。その価値観の共有は、製品に対する市場要求・ユーザー要求を実現しているソフトウェアの機能や性能が何かを可視化することで実現できると考えている。（組込みプレス vol.8 特集1 を参照のこと）
価値観の一致に対するキーワードは徹底した顧客志向だ。お客さんのため、顧客満足を高めるために○○の技術を導入したいとか、ツールを買いたいとか、教育を受けたいという主張が悪循環からの脱出につながる。
<試行錯誤的アプローチからの脱却>
21世紀になっても試行錯誤でソフトウェアを作り、ランダムテストでバグ出ししているようでは、悪循環から抜け出すことはできない。まず、そのことを認識する、意識改革しなければソフトウェア技術者としても成長が見込めない。組込みソフトの場合は黙っていてもその仕事に関わっているだけでドメインの知識が蓄積されるため、一見成長しているように錯覚することがあるが、技術的にはほとんど1970年代と変わっていないという状況もあると推測する。
試行錯誤的アプローチから脱却するためには、まずはソフトウェア開発のプロセスアプローチがなぜ必要なのかを自分の頭で考えることが必要だろう。開発の後工程で大きな仕様変更を受容してしまえば、多大な後戻りが発生し、バグを生み、日程を遅らせることくらい少し考えれば分かる。問題は、それを防ぐために工程を切って、どの工程で何をやるのか決めてそれを守ることができるかどうかだ。
開発の後工程での仕様変更を受容したり、跳ね返すためには、変わりにくい部分と変わりやすい部分を分離するソフトウェアシステムのアーキテクチャ設計が必要になる。また、ユーザーインタフェースの変更要求に対しては、商品コンセプトを明確にし、最初の計画したユーザーインタフェースがその商品コンセプトに基づいて作られていることを説明できるようになることも必要だろう。テスト技術がソフトウェア品質の向上に付け焼き刃ではなく、本質的に効いてくるのはプロセスアプローチがキチンとできるようになってからだ。
組込みソフトウェア開発の悪循環から脱出するには、意識改革と技術導入をセットで推し進める必要がある、これは本当にそうだと思う。
