組込みソフト開発悪循環の構図

組込みソフトウェア開発の悪循環のシナリオを考えてみた。想定する具体的なシチュエーションを示してから、その問題の解決方法について考えていきたい。

【組込みソフト開発悪循環のシナリオ】

1970年代、組込み機器開発の世界で、ソフトウェアはハードウェアとハードウェアをつなぐつなぎ役だった。組込み機器にはセンサーやアクチュエータが使われ、これらをいかにうまく制御して、顧客満足の高い製品を作ることができるかどうかが組込みソフトエンジニアの腕の見せ所だった。組込みソフトエンジニアという職種は確立しておらず、エレクトロニクスの勉強をしてきた技術者がマイコンのアセンブラを覚えて制御ソフトを書いていた。ソフトウェアの規模はせいぜい1000行くらい。ソフトウェア技術者はプログラムを試行錯誤で作り、実機レベルでランダムテストを行い実機で検証をしていた。

※好循環の道を歩むソフトウェア技術者はフローチャートやブロック図を描いてソフトウェアの構造を分析していた。その程度でなんとかなるくらいの規模だった。構造化プログラミングを意識している者もいた。

1980年代、8ビット、16ビットのCPUが次々と登場し、さまざまなペリフェラルデバイスが組み込まれたワンチップマイコンを組込み機器に使うことが多くなってきた。ソフトウェアを記述する言語はC言語が主流となり、リアルタイムOSも徐々に普及しはじめ、ハードウェアエンジニアとソフトウェアエンジニアは職種を分けるようになってきた。リアルタイムOSが普及することにより、ソフトウェアエンジニアがソフトウェアをモジュールに分割することを考えなければいけなくなる。悪循環の道を歩むソフトウェア技術者は相変わらずプログラムを試行錯誤で作り、実機レベルでランダムテストを行い実機で検証をしていた。LCDなどの表示用のユーザーインタフェースデバイスも普及し、プログラムサイズは数千行くらいに増加していた。

※好循環の道を歩むソフトウェア技術者はソフトウェアの振る舞いについて分析する際に状態遷移図や状態遷移表、データの流れを考えるために構造化分析手法が使っていた。

1990年代、組込み機器におけるユーザーインタフェースは飛躍的に向上し、スタンドアロンで動くだけでなく他の機器と通信をしたり、ネットワークにつながったりするようになった。CPUも16ビット32ビット64ビットと次々に高性能なものが登場し、ソフトウェアの規模が数万行になっても処理はオーバーフローしなくなっていた。悪循環の道を歩むソフトウェア技術者はソフトウェアの規模が数万行になっても相変わらずプログラムを試行錯誤で作り、実機レベルでランダムテストをしていた。コードレビューも言葉は知っていたがプロジェクト内で習慣化するところまでには至っていなかった。ソフトウェアシステムの増大の対応策としては、過去に使ったソフトウェアの一部を流用したり、前回担当した機能を作った技術者を今回もアサインするなど、特定の技術者に役割を分担させ、その技術者を何世代もの製品開発に使い続けるというアプローチを取った。そのため、社員や協力会社の社員が担当から外れるととたんに開発の効率や品質が下がったりした。担当者を外したプロジェクトマネージャ本人もその原因がよく分かっていなかった。

ソフトウェアの規模が数十万行にもなり、複雑度が高くなって、分かりにくいバグが増えてきた。ソフトウェア開発の工程が進めば進むほど、ソフトウェア技術者の残業が増えるようになり、新しい技術を学ぶ余裕がなくなってきた。

※好循環の道を歩むソフトウェア技術者は、ソフトウェアの大規模・複雑化に対して何か手を打たなければいけないと気づきはじめ、ソフトウェアシステムをサブシステムに分割する方法や、サブシステム同士のインターフェースをきちんと決めて役割を分担するなどくふうをするようになる。

2000年代、組込み機器にも多様な要求が降りかかってきて、組込みソフトの規模も数万行から数百万行まで幅広くなってきた。規模が大きいソフトウェアシステムほどプロジェクトが遅れたり破綻したりするようになる。ソフトウェアエンジニアの残業時間はピークに達しており、月あたりの残業時間が100時間、200時間という者も増えてきた。しわ寄せは、特に下請け、孫請けの協力会社の技術者がかぶることが多く、ソフトウェア技術者になりたくないと考える若者も増えるようになる。失敗プロジェクト、開発日程の大幅遅延プロジェクトの開発スタイルと見ると、1970年代と同じプログラムを試行錯誤で作り、実機レベルでランダムテストを行い検証をしていた。設計工程の後半で発生する月に100件以上のバグのうちのいくつかは非常に分かりにくい複数のモジュールが関係する不具合であり、数日もしくは一週間以上かけないと原因がわからないようなバグであった。

2000年代になると組込み機器のユーザーインタフェースも多種多様な表現方法ができるようになり、試作品ができた後に、試作器を手にしたステークホルダーが「もっと、こういうインタフェースにしよう」などと言って大幅な仕様変更を指示することも多くなるようになった。ソフトウェアプロジェクトにおいてプロセスを切って、確認してから前に進むことの必要性を認識していない上司（1970年代の試行錯誤でソフトウェアを作っていて特に問題が起こっていなかった世代）が上にいると、ソフトウェアの変更容易性から最後の最後で右に向いていたものを左にしろなどということがあった。

ここから、『熊とワルツを』（トム・デマルコ/ティモシー・リスター）より引用

・・・約束した納期に間に合わなくてもよい、大幅に遅れてもかわまないが、その日までの間、期日に間に合いそうにもないと言ってはならないということだ。事前に失敗するかもしれないことを認めるという大罪を犯さなければ、失敗は容認される。このルールを言い換えると、遅れたことに対して後から「赦し」を請うのはかまわないが、遅れることに対して前もって「許し」を求めてはならない。

　：

このような制約があると、「選択的近視」という感染症になりやすくなることがある。この条件を突きつけられたプロジェクトでは、小さな問題しか見えない。健全なプロジェクトでは視野の真ん中に見えるようなおおきな問題がすぐそこに迫っていても、選択的近視にかかった人にはまったく見えない。

－引用終わり－

ソフトウェアプロジェクトのリーダーとメンバは、製品の開発計画を突きつけられたとき直感的に「（いままでの試行錯誤的な開発を行っていたのでは）この日程では間に合わない」と感じる。しかし、『熊とワルツを』にあるように、運がリスクを消し去ってくれるのではないかと期待している。期待するだけでリスクと正面から向かい合うことはしない。また、楽観主義（嘘をつくこと）があたりまえの環境でプロジェクトマネージャーだけが真実のリスクを話すと、「やる気がない」とか「あいつはネガティブだ」という烙印を押される。そういう環境ではその日が来るまで期日に間に合いそうにもないと言えないので、プロジェクトリーダーはダメだと分かっていても、その日まで最大限努力したというポーズを作ろうとする。メンバは組織上位層にポーズを取る必要はないが、期日に間に合わないことを知っているから、「組織は、また、無理な日程を押しつけている」と感じ、プロジェクトリーダーがかわいそうだと思いつつ残業を続ける。（あたたかい人間関係の中のやさしい一員の特徴）　そして、プロジェクトメンバは組織上位層のことを「無理な日程を押しつけるソフトウェアを理解していない人種」と考え、ソフトウェア開発の現場でどんな問題が起こっているのか説明しても無駄だと考えるようになる。

この状況においてソフトウェア開発の現場がやっていることは、1970年代と同じ「試行錯誤的開発アプローチ」だけだ。場合によっては、構造化設計をちょっとだけやっていたり、ソフトウェアの構成管理だけに力を入れている状態かもしれない。いずれにせよ、ソフトウェアの規模・複雑化の増大に対する抜本的な対応は取っていないので、日程にも間に合わないし品質も上がらない。

この状態が長く続くと、組織上位層も原因は分からないが、ソフトウェア開発に問題があることに気がついてくる。品質に関する問題でお客さんに迷惑をかけることが多くなり、開発日程についても「事前に失敗するかもしれないことを認めるという大罪を犯さなければ、失敗は容認される」とは言えなくなってくる。

そうなると問題の矛先は特定の個人や協力会社に向いてくる。「やっぱりあいつじゃダメか」とか「あそこに仕事を出したのが間違いだった」ということになり、人やソフトウェアの発注先を入れ替えたりする。しかし、試行錯誤的な開発アプローチでは、ソフトウェアシステムの機能・責務の分割と割り振りを人ベースで行っているため、人の入れ替えは開発効率や品質悪化の原因になってしまう。

かくして、組込みソフトの開発は遅れに遅れ、品質は下がり、組込みソフトエンジニアの残業は増え、職種として若者から敬遠されるようになり、優秀であればあるほど仕事が降りかかってくるようになり、中にはプレッシャーに潰れてしまう者もでてくる。労働力を補充することで状況が打開できると勘違いする組織が協力会社や派遣社員に頼るようになり、技術的にも空洞化する。

これが、組込みソフト開発悪循環のシナリオ＆構図である。

【組込みソフト開発の悪循環から抜け出す方法】

組込みソフト開発の悪循環から抜け出す方法が簡単に分かれば苦労はしないが、悪循環脱出のきっかけは特に組込みソフトの歴史や日本人の特性を考えると、「意識改革」と「技術導入」をセットで進めることが重要ではないかと最近考えている。テーマは多すぎると散漫になるので3つだけだ。

－組込みソフト開発の悪循環から抜け出すためにすべきこと－

1. 品質文化と設計の規範の確立
2. 価値観の一致
3. 試行錯誤的アプローチからの脱却
   

<品質文化と設計の規範の確立>

組織やプロジェクトに品質文化がないとルールは形骸化し新しい方法論は難しいからイヤだと敬遠される。また、設計の規範がないと、過去に発生した問題を教訓にすることができず、プロジェクトリーダーが技術的なリーダーシップを発揮することができない。

品質文化と設計の規範の確立という「意識改革」の具体的施策の第一歩としては、ソースコードの行数を数えグラフを描いて可視化し、不具合（バグ）を紙や電子的に管理することをおすすめする。ちなみに、この2つがキチンと行われていない状態から習慣・慣習化するのはとても大変なことである。もしも、この2つがクリアできたなら、変更管理、構成管理についてできるようにしよう。

品質文化と設計の規範の確立におけるポイントは、どんな小さなことでも習慣・慣習化するまであきらめないことだ。

<価値観の一致>

次のテーマは価値観の一致だ。悪循環のシナリオに書いたように、問題は組織上位層とプロダクトマネージャ、ソフトウェアプロジェクトリーダー、プロジェクトメンバ間の間で、言葉が通じ合っていないことに原因がある。

ソフトウェア特有の言葉や環境が通じないから説明しても無駄だと感じ、上はとんちんかんな要求をし、下は無視（最初から無理だと考え思考停止）し、中間層は板挟みになって苦しんでいる。

この状態を打開するには、この三者が共通の価値観のもとに問題に正面から向き合わなければいけない。その価値観の共有は、製品に対する市場要求・ユーザー要求を実現しているソフトウェアの機能や性能が何かを可視化することで実現できると考えている。（組込みプレス vol.8 特集1 を参照のこと）

価値観の一致に対するキーワードは徹底した顧客志向だ。お客さんのため、顧客満足を高めるために○○の技術を導入したいとか、ツールを買いたいとか、教育を受けたいという主張が悪循環からの脱出につながる。

<試行錯誤的アプローチからの脱却>

21世紀になっても試行錯誤でソフトウェアを作り、ランダムテストでバグ出ししているようでは、悪循環から抜け出すことはできない。まず、そのことを認識する、意識改革しなければソフトウェア技術者としても成長が見込めない。組込みソフトの場合は黙っていてもその仕事に関わっているだけでドメインの知識が蓄積されるため、一見成長しているように錯覚することがあるが、技術的にはほとんど1970年代と変わっていないという状況もあると推測する。

試行錯誤的アプローチから脱却するためには、まずはソフトウェア開発のプロセスアプローチがなぜ必要なのかを自分の頭で考えることが必要だろう。開発の後工程で大きな仕様変更を受容してしまえば、多大な後戻りが発生し、バグを生み、日程を遅らせることくらい少し考えれば分かる。問題は、それを防ぐために工程を切って、どの工程で何をやるのか決めてそれを守ることができるかどうかだ。

開発の後工程での仕様変更を受容したり、跳ね返すためには、変わりにくい部分と変わりやすい部分を分離するソフトウェアシステムのアーキテクチャ設計が必要になる。また、ユーザーインタフェースの変更要求に対しては、商品コンセプトを明確にし、最初の計画したユーザーインタフェースがその商品コンセプトに基づいて作られていることを説明できるようになることも必要だろう。テスト技術がソフトウェア品質の向上に付け焼き刃ではなく、本質的に効いてくるのはプロセスアプローチがキチンとできるようになってからだ。

組込みソフトウェア開発の悪循環から脱出するには、意識改革と技術導入をセットで推し進める必要がある、これは本当にそうだと思う。
　

ソフトウェアシステムの分割法

先日、豆蔵のコンサルタントでEEBOFのメンバーでもある井上樹さんと、ソフトウェアシステムの規模のことで話をしていた。自分はプロセスネットワークの金子龍三氏が語っていた30人、30万行以上というソフトウェアプロジェクト、ソフトウェアの規模が分岐点になるという話をしたら、井上さんも同じような別の指標を教えてくれた。

まず、プログラマが自分の作ったソフトウェアについて誰かに聞かれたとき、あのモジュールのあの関数の部分とパッと頭の中に浮かぶソフトウェアの規模はだいたい5000行くらい、そして一人のソフトウェアエンジニアがソースコードだけで保守できる範囲はせいぜい10000行くらいとのこと。また、プロジェクトチームは人数が増えてきたらチームリーダを含めた一チーム6人に分割し、プロジェクト全体では最大5～6チーム以上にはしないようにした方がよいだろうという話だった。これを超えるようならプロジェクト自体を分割して別々のプロジェクトになるようにマネージメントした方がよいのだそうだ。

井上さんの話から、プログラマのソースコードレベルでの守備範囲が10000行だとすると、1プロジェクトの限界が30人で30万行となり、冒頭の30人、30万行の話を符合する。30人、30万行の指標はソースコードレベルで把握できるレベルの限界であるというのは、ソフトウェアエンジニアの管理限界の平均値に近いのだろう。

ちなみに、プロジェクトメンバの数は簡単に数えられるが、ソフトウェアのコードの規模としてコード行数を数えるのはそれほど簡単ではない。自分の中ではソースコードの行数と言えば、コメント行や宣言文を除いた実行コード行数ということになる。実行コード行数を目視でカウントするのはあまり現実的ではない。そうなると何らかのツールを使わないとある程度正確なカウントができない。でもツールがないからといってコード行数をカウントしないとソフトウェアシステムの規模が把握できない。組込みソフトの場合、実機にアップロードするときのコードサイズをソフトウェア規模の指標にする場合もあるが、プログラミングをソフトウェアエンジニアの文章書き作業だと考えると、ソフトウェアの複雑性を計る意味ではプログラムサイズよりも実行コード行数の方が実態に近いのではないかと思う。

もしも、実行コード行数を計るツールを持っていない場合は、C,C++,java,htmlプログラムの行数を計算する C&C というフリーツールがあるので参考にしてはどうかと思う。（このツールはSESSAMEメンバーの國方さんに教えてもらった。このブログでツールを使うときは宣伝文句に惑わされるなといったことを何回も書いているが、できるエンジニアは大抵いくつかのツールを上手に使いこなしている。常にアンテナを張っているので、ツールの選び方も上手い。）

さて、30人、30万行の規模に達していないプロジェクトは何もしなくてよいのだろうか。それは、もちろんそうではない。ソフトウェアの規模が徐々に拡大して何の危機感も感じることなく試行錯誤的なアプローチで30人、30万行の規模に達してしまったら、もう身動き取れないし、その状態からソフトウェアの構造やプロジェクトを立て直すのは相当大変だと思う。

感覚的には10人、10万行くらいの規模に達したら、何かしないとまずいと感じないといけないし、その時点から対策を打っていけば、30人、30万行に達したときでも破綻することはないと予想する。そもそも組込みソフトでゼロからスクラッチで作ることはないので、一回の開発で作るソフトウェアの量はそんなに多くないと思っていると、いつの日か痛い目にあうときがくる。もともと先々のことまでよく考えずにスクラッチでソフトウェアを作っていると CPUやOSが変わったとたんに、これまで作ったソフトウェアのいろんなところに手を入れないといけなくなる。結果的にスクラッチでゼロから作り直したのと同じぐらいの時間がかかってしまうこともある。

さて、そうなると最初に考えるべきはソフトウェアシステムをどのように分割すべきかということだ。ソフトウェアシステムのモジュール分割については30年以上も前から不文律がある。それは「システム分割に際しては分割したモジュールを高凝集、疎結合にすべし」という考え方だ。

【凝集の種類】　（数字が大きくなる方がよいとされる）

1. 暗号的凝集度 プログラムを単純に分割しただけで、モジュールの機能を定義できない。または、複数の機能をあわせもつが、機能間にまったく関連はない。
2. 論理的凝集度 関連した複数の機能をもち、モジュールが呼び出されるときの引数（機能コード）で、モジュール内の１つの機能が選択、実行される。
   
3. 時間的凝集度 初期設定や終了設定モジュールのように、特定の時期に実行する機能をまとめたモジュール。モジュール内の機能間にあまり関連はない。
   
4. 手順的凝集度 複数の逐次的に実行する機能をまとめたモジュール。
   
5. 連絡的凝集度 手順的凝集度のうち、モジュール内の機能間にデータの関連性があるモジュール。
   
6. 情報的凝集度 同一のデータ構造や資源を扱う機能を１つにまとめ、機能ごとに入口点と出口点をもつモジュール。
   
7. 機能的凝集度 １つの機能だけからなるモジュール。
   

※参考文献：平成16年度　ソフトウェア開発技術者合格教本　ISBN4-7741-1882-6

組込みシステムでよく見られるのは、3の時間的凝集を意識したモジュール分割だ。リアルタイム性を重視する余り、10ms毎、100ms毎、1秒毎に起動するモジュールといった感じで時間的な視点のみでモジュールを分割する。リアルタイム性が非常に強いシステムでは当然時間的凝集を意識したモジュール分割も必要だが、ソフトウェアシステムが巨大化した場合は、時間的凝集や手順的凝集だけを意識していると移植性や保守性、再利用性が悪くなる。

巨大化したソフトウェアシステムに立ち向かうには、機能的凝集の考え方が必要であり、責務ごとにモジュールを分割する必要がある。システム全体を責務に分割し、機能的凝集に成功すると分割したモジュールの内部でやっていることについて、モジュールの外部は意識する必要がなくなり、そのモジュールが外部に対して公開しているサービスについてのみ考えればよくなる。ようするにシステムの上位層から見たときにモジュール内部の（不要な）データや処理を隠蔽していかないと、システム全体を把握することが難しくなる。人間が一度に把握できる構造には限界があるので階層的にソフトウェアシステムを眺めていくには、機能的凝集のモジュール分割、責務に基づいたモジュール分割が必要になる。

このようなモジュール分割の考え方は、ビジネス系でオブジェクト指向設計を行う際には普通に行われていると思うが、組込み系のシステムで制約条件のことに考慮せずに機能的凝集のことだけ考えてモジュール分割を行っていると、リアルタイム性やメモリ容量、CPUパフォーマンスをクリアできない場合もあるから注意が必要だ。だから、『組込みソフトエンジニアを極める』では、第1章で時間分割のハードルを越える 第2章で機能分割のハードルを越える といった順番で、時間分割、機能分割の考え方を書いた。

だから10万行を超えた組込みソフトウェアシステムでは、いろいろな凝集についての考え方があることをきちんと理解しながら、トップダウンの視点（機能分割）とボトムアップの視点（時間分割）の両方の視点でシステムを眺めることが大事だ。組込みソフトエンジニアは機能分割と時間分割の最良のバランスポイントを見つけなければいけない。

次に、結合の種類 6種類を挙げておく。ちなみに、この分類は最初に提唱したのは、G.J. マイヤーズだと思う。

【結合の種類】　（数字が大きくなる方がよいとされる）

1. 内容結合 絶対番地を用いて直接相手モジュールを参照したり、相手モジュールに直接分岐する。
2. 共有結合 共通領域（グローバル領域）に定義されたデータを参照する。
   
3. 外部結合 必要なデータだけを外部宣言し、ほかのモジュールから参照を許可し共有する。
   
4. 制御結合 機能コードなど、モジュールを制御する要素を引数として相手モジュールに渡し、モジュールの機能や実行を制御する。モジュール凝集度の論理的凝集度がこれに相当する。
   
5. スタンプ結合 相手モジュールで、構造体データ（レコード）の一部を使用する場合でも、構造体データすべてを引数として相手モジュールに渡す。
   
6. データ結合 相手モジュールをブラックボックスとして扱い、必要なデータだけを引数として渡す。
   

※参考文献：平成16年度　ソフトウェア開発技術者合格教本　ISBN4-7741-1882-6

G.J. マイヤーズがこの6つの結合を分類したのは30年以上前のことだ。だから、この結合の分類はC言語ならば関数と関数の結合といった関係のことしか書かれていない。オブジェクト指向設計で考慮の対象になる、結合の方向性（結合の方向性は一方向にした方が結合度が低い）については考えられていない。

何はともあれ、巨大化してしまったソフトウェアシステムは何らかの視点でシステムを分割していかないとすぐに手に負えなくなる。何らかの視点の何らかの部分は組織や商品やプロジェクトによって異なるのだか、多くの場合は機能的な分割をベースに、時間的分割を考慮する方法がセオリーになると思われる。

また、データの取り扱いが重要とされるシステムでは、プレゼンテーションレイヤー、ドメインレイヤー、データソースレイヤーといったレイヤリングの分割視点が有効な場合もある。

さらに、商品に求められる価値をQFD（品質機能展開）で分析して、その要求・価値を実現する機能や性能をモジュールとして括りだすという視点もある。

どっちにしても、大規模・複雑化した組込みソフトウェアシステムでは、どんな視点でシステムを分割するかといった戦略（＝アーキテクチャ）が、製品の開発を効率化し、信頼性や安全性を高めるカギとなるのは間違いない。
　

理系白書から考えるソフトウェア工学（つづき）

『理系白書から考えるソフトウェア工学』の記事のつづき。ソフトウェア工学が自然科学で証明できるものでなく、先人の知恵を体系化したものであるならば、ソフトウェア工学を現場で普及、適用させようとする人々は、ソフトウェア工学が現場にもたらす効果や組織への貢献について丁寧に説明しなければならない。

正しいか、正しくないかではない。現場にどんな効果をもたらすか、組織にどんな貢献をするのかがキチンと説明できないといけない。

今、自民党の総裁選挙のまっただ中だが、新しいソフトウェア開発手法や検証技術を現場で普及させようとしている人は政治家と似たところがあると思った。

政治家は政策を国民に説明し理解を求める。政策がより多く支持された方が選ばれる（べきだ）。これが、その人の人柄とか人気とか風貌とかで支持してしまうと、最初はよくても後で問題になることが多い。

自然科学のように効果効能の是非を白黒付けることが難しいソフトウェアの世界では、ソフトウェア工学をいかに現場の技術者が理解できることばで説明し、習慣づけるところまで持って行けるかどうかがカギとなる。そのときの流行とか有名な人がいいと言っているとか、あの企業が採用したからという持って行き方は、人・者・金を動かす権限を握っているハードウェア出身の組織上位層には使ってもいいかもしれないが、現場のエンジニアには使わないほうがいい。（そういうステークホルダの人たちとは提案する施策に対する価値観を共有できるようにしたい）

物理や化学の方法論の場合、その方法論の効果はやろうと思えばその場で実験できる。環境さえ整えればいつでも再現できるのが自然科学の強みだ。でも、ソフトウェア工学は人が相手なので、どんなに著名な人が提唱した方法論でも、どんなに参照回数の多い論文でも、目の前にいるプロジェクトで効果を発揮するかどうかはわからない。（もちろん、多くのプロジェクトが取り入れて成功した方法論は成功の確率が高い）

そう考えると、ソフトウェア工学の適用を現場に説明する際に一番大事なのは「いま、このプロジェクトに足らないものは何か」「なぜ、それが必要なのか」「これを適用するとこのプロジェクトにどんな効果をもたらすのか」を説明することだと思う。そして、その方法論をプロジェクトに適用し、何らかの形で効果を計測しなければいけない。やりっぱなしではいけない。だから、ソフトウェアの世界で小さいながらも組織やプロジェクトでイノベーションを起こしたいと考えている人は、適用しようとしている方法論についてまず、考えて、考えて、考えて、考えて、理解して、説明できるようになることが大事だ。間違っても、ツール屋さんの宣伝文句を右から左に流してはいけない。

プロジェクトマネージャとして経験を積んでいる方やソフトウェアプロジェクトを支援している組織内外のコンサルタントの方達に話を聞くと、みな「現場に方法論を押しつけてはいけない」「納得させながら一歩一歩進むことが大事」という。

開発現場からプロジェクトを支援する立場に移ると何かとイライラすることが多い。自分が主導権を持ってやっていたときの時間の流れ方とプロジェクトを側面から支援して必要なことをやってもらうときの時間の流れ方がまったく違う。プロジェクトマネージメントのベテランは過去を振り返ると、最初は自分の経験をベースにあれやれこれやれと現場に支援・指導するのだが、しばらくするとそれではうまくいかないことに気づくという。現場が「今のままではまずい、新しい何かが必要だ」と感じさせることがまずは大事だというのだ。

このことがよく分かっていなかったころ、『ここが変だよ日本の管理職』や『日本人はリスクを表に出すのが嫌い？』といった記事で、現場のプロジェクトマネージャやプロジェクトメンバの問題点について愚痴を書いていた。しかし、問題点は問題点として、今後もその状況ではまずいということを自分だけでなく現場にも気づいてもらわなければいけないし、そうしないとカイゼンは進まない。

『ここが変だよ日本の管理職』的な考え方は、ひとつは欧米的にトップダウンでカイゼンを推し進めることができないのかという問いかけなのだが、日本人は『アメリカ人と日本人』の記事で書いたように「あたたかい人間関係の中のやさしい一員」的気質であるため、もともと『ここが変だよ日本の管理職』的な進め方がうまくいきにくい環境なんだと思う。だから、カイゼンが早く進まないことに対してブツブツと愚痴をこぼし、プロジェクトマネージャのふがいなさを嘆くのではなく、ほんの少しでもプロジェクトが今とは違うカイゼンの一歩を踏み出す方策はないのかについて、何とか知恵を絞ることの方が大事だ。

このことに気がついた、というよりはそんな心境になったはプロジェクト支援の仕事をするようになって1年を過ぎたころだろうか。新しい職務に就けば誰だって早く成果を上げ、組織に貢献していることを示したいものだが、ことソフトウェアの開発効率アップとか品質向上の成果を示すのには根気もいるし時間もかかるということがだんだん分かってきた。

今現在、これは正しいといえるのは、何か新しいことをプロジェクトにやってもらいたいと思うのなら最初は大変でもできるだけ環境を整え敷居を低くして、さんざん文句を言われても「がんばれ」「効果はでてきたぞ」と現場を励ましながら、新しいことをルーチンワーク化して、結果的にその施策をプロジェクトの習慣にさせることだ。習慣になると自然と何がよくなったのかが見えてきて文句も言わなくなる。この明確な計画なしに「あたたかい人間関係の中のやさしい一員」の中で慣習化させるどちらかと言えばボトムアップ的なカイゼンこそ、日本的プロセス改善なんだと思う。

さて、ピーター・F・ドラッカーは著書『プロフェッショナルの条件』で、イノベーションの成功の条件として次の3つを挙げている。（こちらの記事も参照のこと）

【イノベーションの成功の条件】

1. 第一に、凝りすぎてはならない。イノベーションの成果は、普通の人間が利用できるものでなければならない。多少とも大きな事業にしたいのであれば、さほど頭のよくない人たちが使ってくれなければ話にならない。つまるところは、大勢いるのは普通の人たちである。組み立て方や使い方のいずれについても、凝りすぎたイノベーションは、ほとんど確実に失敗する。
2. 第二に、多角化してはならない。散漫になってはならない。一度に多くのことを行おうとしてはならない。これは「なすべきこと」の一つとしての的を絞ることと同義である。
3. 第三に、未来のためにイノベーションを行おうとしてはならない。現在のために行わなければならない。たしかに、イノベーションは長期にわたって影響を与えるかもしれないし、20年たたなければ完成しないかもしれない。だが、「25年後には、大勢の高齢者がこれを必要とするようになる」というだけでは十分ではない。「これを必要とする高齢者はすでに大勢いる。もちろん時間が味方だ。25年後には、もっと大勢の高齢者がいる」と言えなければならない。

※ピーター・F・ドラッカーは著名な経済学者で『プロフェッショナルの条件』は6年間で44刷りもしている。ここでドラッカーを引用したのは自分が考えていたことと、この本に書かれていたことに共通点があり、ドラッカーを引用することで、その考え方の根拠がより広範囲に裏付けられると考えたからである。

ちなみに、ここで論じていることはとどのつまり組織成熟度と組織成熟度に応じて適用すべき適切な施策のことを言っている。それって、CMMIのことかっていうことになるが、そのとおりCMMIと同じことを言っている

CMMI（Capability Maturity Model Integration）

米カーネギーメロン大学ソフトウェア工学研究所が公表したソフトウェア開発プロセスの改善モデルとアセスメント手法であるCMM（Capability Maturity Model）に、有識者の意見や多くのプロセス改善事例を反映させて作成された新しい能力成熟度モデルのこと。

でも、日本の組織でCMMIのレベル○○を取るように頑張ろうというと、多くの場合うまくいかず、無理にごり押しするとすぐに形骸化する。形骸化する理由は、ドラッカーが言っているイノベーションの成功の条件に合っていないからであり、凝りすぎて、散漫であり、現在のための施策になっていないからだ。凝りすぎて、散漫であるというのは、すなわち CMMI のレベルが低いということになるのだが、そもそも CMMI で組織成熟度を格付けすることが、そのプロジェクトやその組織の“現在のための施策”かという点が引っかかる。（皮肉にも日本ではCMMIを受けいられるくらい組織が成熟している場合のみCMMIの効果がでる）

さらに、日本人の気質は「あたたかい人間関係の中のやさしい一員」であるため、特に格付けや監査を毛嫌いする傾向があると思う。ようするに格付けされたり、監査で重箱の隅をつつかれてカイゼンするのではなく、誰とは言わず自分たちのプロジェクトの内側から問題を解決することを望む傾向があるということだ。

そして内側からのカイゼン力が低い組織・プロジェクトに外側から格付けや監査をしようとすると、バリアを高くしてどんどん殻に閉じこもる。これが、『日本人はリスクを表に出すのが嫌い？』といった状態だ。こうなってしまった場合は外側から殻をこじ開けようとするのではなく、内側のカイゼン力を回復させてあげることに注力を注ぐべきだと思う。（『カイゼンを実現できる多能工を目指そう！』を参照のこと）

こういう場合、一番いいのはプロジェクトリーダのリーダシップで引っ張ってもらうことだが、プロジェクトメンバ全員がリーダも含めて「あたたかい人間関係の中のやさしい一員」的気質である場合は、支援者が小さなカイゼンの方法論と環境を提供し、その小さなカイゼンを自分たちのものになる（ルーチンワーク化する）までサポートしてやるといいと思う。その心は「内側からのカイゼンに対して自信を付けさせる」ということだ。

日本の製造業においてQC活動は生産品質向上に大きく貢献した。おそらく、内側からのカイゼンで組織の成熟度を高めるというやり方が、「あたたかい人間関係の中のやさしい一員」的気質にピッタリ合っていたからだと思う。CMMIも目指しているところは同じだと思うのだが、対象としているのが人間であり、その人間は地域や組織によって気質が違うということを考慮しなければいけないのだ。

ソフトウェア工学は先人の知恵を体系化したものであり、対象は人間である、だからソフトウェア工学をプロジェクトに適用するときは、凝りすぎず、散漫にならないように気をつけ、現在の問題の解決のためになることを明確にする、そして、終わってみればそのカイゼンがプロジェクト内部のエネルギーで成就したことになっていることが大事である。

ちなみに、本当にこの通りうまくいくと、そのプロジェクトは成果を内外で発表したくなる。このように成果を発表して振り返ることはその組織やプロジェクトにとって非常に大事なことであり、積極的に行うべきだ。

でも、その発表を聞いたカイゼンが進んでいないプロジェクトはこの成果を取り入れる前に、方法論採用の是非をこの記事に書いた原理原則に照らし合わせてよく考えてみる必要がある。自分のプロジェクトに対して凝りすぎていないか（難しすぎないか）、現在の問題の解決のためになっているかチェックしなければならない。

ソフトウェアにおけるカイゼンは対象が人間であるが故に、技術的な施策にも増して意識改革への取り組みが重要なことが多い。ソフトウェア工学は自然科学では証明できない部分が大きいということに着目すると、現場に対して何を支援・指導すべきかが見えてくる。

P.S.

ソフトウェアの世界でも産学の協調がよく話題になる。産学の協調でうまくいったケースとして、1960年代、1970年代の品質機能展開(QFD）の技術があったと思う。（『組込みソフトで勝ちたい人に捧ぐ』参照のこと）　企業は自分たちの製品の品質表を作成し、研究者が現場が一体となって改善点を探り、改善点をQFDの理論として体系化していった。ソフトウェアの世界では対象が人間であるため、産学連携が成功するには研究者が開発現場にどれだけ関われるかにかかっていると思う。また、研究者はある現場で成功した方法論が他の現場でもうまくいくかどうかよく考え、うまくいく根拠を明示して欲しいと思う。
　

トヨタのソフト戦略

ソフトウェア品質シンポジウムの基調講演でトヨタ自動車常務役員の重松崇氏の話を聞いた。トヨタの重松氏はESECなどの組込み系、ソフトウェア系のイベントでよく講演しているのを見掛ける。

もともと重松氏はソフトウェア技術者としてのたたき上げではなく、根っからの車屋から車載ソフトウェアを任されたという経歴を持つ。では、なぜバリバリのソフトウェア技術者ではない重松氏が組込みソフトウェア系、品質系のイベントに呼ばれるのか？　それはもちろんトヨタ自動車が日本だけでなく世界的に高い業績を上げている企業であり、トヨタ式と呼ばれるハードウェアの生産方式と同じように、ソフトウェアの開発にもトヨタ式と呼ばれるものが存在し、それを真似すれば高品質のソフトウェアをアウトプットできるだろうと多くの人が期待しているからだ。

さて、重松氏は90分の講演時間のうち、半分以上を使って現在と未来の自動車に求められること（エネルギー効率のよいモビリティの追求と安全の確保）を語った。さすがだと思う。つい最近、JR のSuicaのプロジェクトを牽引した椎橋氏の話を聞いたが、椎橋氏も講演のほとんどの時間、鉄道を利用するお客さんの利便性を向上するために自分がやってきたことをとうとうと語っていた。

ようするに組込みは業務ドメインを知り尽くし、顧客要求（トヨタの場合は顧客というより地球や人類のことを考えているとのこと）を高める意志と戦略を持った者が、ソフトウェア開発のどこに力を入れればよいのかわかるということだ。（これはビジネス系のソフトも同じか）

でも、なぜ重松氏は車に特化したソフトウェア開発戦略をわざわざあっちこっちでレクチャーするのだろうか。その情報の公開はトヨタにとってどんなメリットがあるのか？　

これは予想だが、トヨタはトヨタのソフトウェア戦略を公の場でしゃべることで、トヨタ社内やサプライヤのソフトウェアエンジニアに対して自分達の考え方を浸透させたいのだと思う。トップの方針を末端まで届けたいという意志があるに違いない。それに重松氏がしゃべった内容は、すぐに日経エレクトロニクスなどに取り上げられちまたの話題となる。なぜなら、冒頭で書いたように日経エレの読者はトヨタ式のソフトウェア開発方式がすべての業務ドメインに使えるだとうと期待しているからだ。

でも、特に組込みソフトの世界ではすべてのドメインに共通して有効な解法はない。なぜなら、業務ドメインや組織によって、市場要求や得意な技術、リアルタイム性などの性能要件、メモリ、CPUパフォーマンスなどの制約条件、組織成熟度、エンジニアのスキルがバラバラだからだ。でも、ツールベンダーやプラットフォーム提供者は、必ず自分たちのソリューションがすべて組込み開発に有効であるかのように宣伝するので気をつけた方がいい。こういうのにコロッとやられてしまう鴨ネギタイプのエンジニアやマネージャは組織の中に必ずひとりやふたりはいるものだ。

さて、重松氏は自動車に搭載する約60のECU群を今後4群に減らしていくと言っていた。自動車におけるECUのプラットフォームを共通化し、ソフトウェアの連携によって多様な要求（交通インフラから上がってくる情報を使って危険回避するような要求）に対応していくそうだ。

この施策の最大のリスクは、エネルギー効率のよいモビリティの追求と安全の確保のうち「安全の確保」の方が危うくなる可能性があるという点だ。

ECUが物理的に分かれ責務分割されている状態では、各ECUが起こす不具合、バグの責任は明確で、ECU別に責務の重さやソフトウェア品質の検証のハードルの高さを変えることができた。でもECUの数が少なくなってしまうと、責務の分割や安全の重要性はソフトウェアの中を見ないと分からなくなる。アーキテクチャを可視化して、システムの安全を確保するための安全アーキテクチャが確立されていることをソフトウェアの範疇で証明しなければいけない。安全クラスの低いアプリケーションソフトがメモリリークを繰り返して、重要なソフトに影響を与えないことを証明しなければいけない。ソフトウェアは人間が作っているモノなので絶対大丈夫とは言い切れないし、誰かがちょこっとなおした1行の変更がシステムに大打撃を与える可能性も否定できない。

ECUの数を極力少なくするのなら、ソフトウェアの安全設計、安全アーキテクチャが絶対に必要だと思う。大規模・複雑化したクリティカルデバイスにおいては、安全アーキテクチャは今後重要なテーマになっていくだろう。また、プラットフォームの共通化のメリットがデメリットを上まわる自信がないといけない。組込みソフトはいろいろなトレードオフのバランスの上で顧客満足を確保しているのだ。

さて、重松氏はモデル駆動開発についてサラッと問題点を口にしたが、自分は大事なその一言を聞き逃さなかった。それは「戦略なきプラットフォームの共通化は失敗（プラットフォームベンダにいいようにやられる）する」ということばだ。

プラットフォームの共通化・モデル駆動開発ということばに踊らされて、商品の価値を高めることができるという確信がないままに、共通プラットフォームを採用してしまうと後々商品開発の基盤をプラットフォーム提供者に握られてしまうことに気がつく。重松氏はこの例として、ヨーロッパの共通規格団体 AUTOSAR が Windows を車載ソフトの共通プラットフォームとして採用する提案をしてきたので、日本の共通化団体の JasPar で使えない部分があることを証明してAUTOSARに進言したという例で語っていた。

重松氏の話を聞いていてトヨタは自前で自動車のソフトウェア全部を作り上げるつもりはないように聞こえた。サプライヤからのソフトウェア供給は今後も続くという考えのようだ。そうなると、クライアントとなる自動車メーカは難しくなっていくソフトウェアの理論についてどんどんうとくなり、サプライヤ側は自動車を取り巻く環境の詳細を把握しきれなくなる。トヨタの重松氏やJRの椎橋氏のように車や鉄道のことを知り尽くし、ソフトウェアの品質がどうあるべきかがわかる技術者がだんだんいなくなって顧客要求をよく理解しないソフトウェア技術者が作ったプログラムを自分たちの商品に実装せざるを得なくなってくると思う。

これはかなり危ない。車や鉄道の特性やリスクを知らない、意識しない技術者が作ったソフトウェアは間違いなく危ない。その機器が使われる場面においてどんな危険やリスクがあるのか知らないツールメーカのツールやプラットフォームも危ない。どうしてもそれらを使うのなら、それらが危なくないことを証明する責任は採用した側にある。それだけは忘れてはいけない。

P.S.

「トヨタはソフトウェアでもトヨタ式を提唱していくつもりなのか？」という会場からの質問（電通大のにしさんより）に対して、重松氏は「生産方式には自信があるが、ソフトウェアについてはむしろ外部の知恵（例えばソフトウェア工学で培われたプロセスアプローチなど）を取り入れていきたいというようなことを語っていた。トヨタ式ソフトウェア開発は参考にするべきもので、生産方式のように安易に真似してはいけないということだ。

Blogger のコメントは読みにくいので本文の方に入れてしまいました。

自動車エンジニアさん さんは書きました...

先日、コメントを書かせて頂きました『自動車エンジニア』です。

また、コメントさせて頂きます。

-----------------------------------
プラットフォームの共通化・モデル駆動開発ということばに踊らされて、商品の価値を高めることができるという確信がないままに、共通プラットフォームを採用してしまうと後々商品開発の基盤をプラットフォーム提供者に握られてしまうことに気がつく。
----------------------------------

確かにそのとおりだと思います。
自動車業界でいうと、モデルベース開発がMATLABという１つのツールに依存しすぎると、ツールベンダーに主導権を握られるリスク当然はあります。

実際そうなりつつありますが...
MathWorksがマイクロソフト状態にならないように、MAAB、J-MAABなんかでも、MathWorksにソフト改良への要求などを（強気に?）行って、かなり牽制しようとしてますが...


デンソーなんかは、ツールベンダーに依存しなくてよいような方向を志向しているのかどうかわかりませんが、最近はプラットフォーム環境を内製化しようとしてしいる感じは、各公演等から感じられます。
トヨタでも同じようなことは考えられているかもしれません。




----------------------------------
重松氏の話を聞いていてトヨタは自前で自動車のソフトウェア全部を作り上げるつもりはないように聞こえた。サプライヤからのソフトウェア供給は今後も続くという考えのようだ。
----------------------------------

参考までに、トヨタは自前で組み込み用のＯＳの開発を行っているようです
あくまで、メディアの情報です。

【トヨタ、「クルマＯＳ」独自開発】

【50人体制の開発組織・トヨタ正発表】

【経済産業省、車載標準OSを開発へ--トヨタや日産らが参加】


トヨタも現状は、サプライヤーにソフトの供給を依存しているかもしれませんが、もしかしたら、将来的に自前でいくことも考えているのかしれませんね。

ただ、本当の戦略？？です


-----------------------------------
これはかなり危ない。車や鉄道の特性やリスクを知らない、意識しない技術者が作ったソフトウェアは間違いなく危ない。その機器が使われる場面においてどんな危険やリスクがあるのか知らないツールメーカのツールやプラットフォームも危ない。
----------------------------------

自動車業界にいる者として、真摯にご指摘を受け止めなければなならないと思います。
現状、車メーカー側には組み込みのエキスパートは少ないように感じます。
いくつかの車メーカーはグループ内にＥＣＵメーカーをもっていて、組み込みは子会社のＥＣＵメーカーに任せて、車メーカーはシステムのアルゴリズム開発に注力するという方向かもしれませんが、それが、大問題の原因になるとのご指摘かと思います。

車メーカー：組み込みの素人、制御アルゴリズムや車両の特性には詳しく、ロジック開発のみやる
⇒どんどん、組み込みに疎くなる。
⇒【組み込み技術】と【制御ロジック/制御対象特性】の両方を把握するエンジニアがいなくなる。
システム/組み込み開発で全体を把握でる人がいなくなり、部分分のみの知識/経験しかない人だけになると絶望的になる。

さらに、自動車の特性に関する知識に疎いツールベンダーが、人命を預かって走る車において、ＥＣＵの組み込みの根幹を握るようにると、さらに怖いというご指摘かと思います。
（間違っていたらご容赦ください）

車メーカー側は組み込み技術の向上（組み込みエンジニアの育成も含めて）を真剣に考えていかなければいけなかと思います。
最後は車メーカーが全ての責任をとらなければいけませんので、組み込みＥＣＵの責任も最後は車メーカーが持たなければなりません。


私も、組み込みに関する知識不足を痛感しています。
最近、組み込み関連の本を何冊か購入して勉強していますが...

『組込みソフトエンジニアを極める』も今、読ませて頂いております！

ＥＣＵメーカーの組み込みエンジニアとも情報交換及び、今後のシステム/組み込み開発のやり方を議論する場なども定期的にもっていたりします。

----------------------------------
こういうのにコロッとやられてしまう鴨ネギタイプのエンジニアやマネージャは組織の中に必ずひとりやふたりはいるものだ。
----------------------------------
私もそんな１人ですね（笑）
ベンダーの営業トーク（いいことしか言わない）によくコロッといったりします（笑）

9月 08, 2007

sakai さんは書きました...

自動車エンジニアさん、コメントありがとうございます。

自動車エンジニアさんは本当に自動車のソフトウェア開発にお詳しいですね。

自動車のソフトウェア安全については、ISO 26262 の策定が進んでいると思いますが、ソフトウェアの安全性を分析する考え方として MISRA-SA というのもあります。

どっちにしても、ソフトウェアの安全性は電気的安全性のようにはっきりと白黒つけることは難しいので、エンジニアがどれだけ客観的な根拠・証拠をもってシステムの安全性や信頼性を証明できるかどうかにかかっていると思います。

自動車ソフトウェアの安全性は、これまでソフトウェアエンジニアがユーザーの要求や機器のメカニズムを熟知しており、どんな風に使われるのか、どんな風に ハードソフトが動くのか知っていてソフトウェアを作っているということで担保されていた部分が大きかったと思いますが、これからは誰がどんなソフトウェア を作り込んでしまうか分からないという前提で、ソフトウェアの安全性や信頼性が確保されていることを客観的に示していかないといけないと思います。

モデルベース開発は安全を客観的に示すための有力な方策の一つだと思いますが、モデル変換のソフトウェアを作っているエンジニアが特に車のメカニズムを意識していない場合、意図しない洩れや抜けにより変なコードが埋め込まれてしまう可能性はあると思います。

ただ、「理系白書から考えるソフトウェア工学」で書いたように、モデルベース開発が自然科学を相手にしているうちは正しく変換できているという信頼性をVerification（検証）することは難しくないと思います。

しかし、自然科学以外のすり合わせ的ソフトウェアアーキテクチャをモデル駆動開発に取り込んでいった場合は、信頼性の証明やシステム全体のValidation（妥当性確認）は難しくなってくると予想します。

組織内部の Closed のすり合わせ的アーキテクチャ・アルゴリズムの安全性や信頼性は、そのハード・ソフトが使われる場面や要求を実現するメカニズムを熟知しているソフトウェ アエンジニアの「慎重さ」「そのソフトウェアが安全を担っているという使命感」のようなものが確保していたのが本当のところでしょう。（要求通りに作られ ているかどうかを検証するのは Verification です）

これからは、その安全アーキテクチャ、安全ソフトウェアをカプセル化して、他の安全クラスの低いソフトウェアから隔離し、影響を受けにくいソフトウェアの構造を作っていかないといけないと思います。

これは ECUが物理的に分かれていることで責任分担され証明しやすかった状態に比べると、自信を持って「安全です」と言えるところまで持っていくのに時間も手間やソフトウェア的工夫もいるだろうと予想しています。

自分は自動車ドメインのエンジニアではありませんが、このブログでもその方策について考えていきたいと思います。

9月 08, 2007