ソフトウェア開発工程の区切りが見えない

ソフトウェア開発の場合、開発工程の区切りがよく見えないことがある。例えば、次のような工程（プロセス）の区切りを明確に見分ける方法は存在するだろうか？

1．ソフトウェア開発計画
2. ソフトウェア要求分析
3. ソフトウェアアーキテクチャ設計
4. ソフトウェアユニットの実装と検証
5. ソフトウェア結合
6. ソフトウェアシステム試験
7. ソフトウェアリリース

別にウォーターフローのプロセスじゃなくてもいい、インクリメンタルでも、ユニファイドプロセスでもなんでもいいが、どこが区切りかどうやって内外に示すのか？

電気回路の設計なら、プリント基板の完成や部品の実装という形で明確に一次試作や二次試作の工程のくぎりが見える。部品が実装され一通りのテストが終わったら「じゃあ、飲みに行こうか」と言える。

しかし、ソフトウェア開発の場合、工程の区切りが曖昧なので、「ソフトウェア開発計画が完成したから一区切りついた」とか、「ソフトウェア要求仕様ができあがったので飲みに行こう」という感じにはなかなかならない。ソフトウェア開発の工程で区切りが明確に分かるのはソフトウェアをリリースするときだけなのだろうか。

ソフトウェア開発の上流工程は特に少数の技術者、場合によってはひとりの技術者の作業に集約されてしまうことが多いから達成感や区切りが見えにくい。

ソフトウェア開発の工程の区切りを見るのに一番分かりやすいのが、アウトプットとなるドキュメントの完成だ。ソフトウェア開発計画工程のアウトプットとしてソフトウェア開発計画書、ソフトウェア要求分析工程のアウトプットとしてソフトウェア要求仕様書を作成する。これらのドキュメントが完成したことで工程の区切りを判断することができる。

ところが、これらのドキュメントで明確に分かるのは書類があるかないかであって、その工程内で実施すべきアクティビティがキチンと実施されたのかどうかはドキュメントの中身を精査したり、プロジェクトにインタビューしたりしないとわからない。電気設計のように「回路図がを出図した！」とか「実装されたプリント基板が動いた！」というほど工程が完了したというインパクトがない。

ソフトウェア開発の場合、悲しいかなドキュメントの中身をキチンとレビューできるレビューワーがいないと、各工程でやるべきことが実施されたかどうかも分からない。工程の区切りが明確でなく、工程のアウトプットドキュメントをきちんレビューできないと、結果としてぐだぐだになってしまりのない開発になる。

しまりがないというのは、計画通りにプロジェクトを進めるとか、ここから先は要求仕様の変更はしないとか、アーキテクチャは大幅に変更しないとかいった判断ができず、プロジェクトリーダーやプロジェクトメンバの個人的な判断、個人的な折衝力で、変更要求をはね返したり、プロジェクトの舵取りをしなければいけない状態のことだ。

ソフトウェアプロジェクトの内外から「ソフトウェアはいつでも変更できる」と見られていると、変更がソフトウェアシステムに与える影響を考えずに開発工程の後半であっても、プロジェクトは変更要求を受け入れてしまう。

複雑な仕事を成し遂げるには、当然のごとく最初の段取りをしっかりしておかないといけないが、開発工程の最初の方がぐだぐだのプロジェクトは開発の後工程で相当苦労する。

日本の組込みソフトウェア開発では、20年も30年も前は、もともと明確な「プロセス」を設定して、ひとつずつ前に進む仕事の進め方ではなく、試行錯誤でソフトウェアを作成し、プロトタイプを動かしてみて問題があったらすぐ直すという作り方をしてきてその進め方が体に染みついているので、にわかルールで開発プロセスが定めてもすぐに形骸化してぐだぐだの開発になりがちだ。

メインフレームのソフトウェア開発の世界では、ソフトウェアの規模と複雑性が限界を超えた時点で、試行錯誤的なやり方では開発が完了しないことがわかり、プロセスアプローチの重要性が認識された。

組込みソフトウェア開発の世界では、ソフトウェアの規模と複雑性が限界を超えていない開発が多いので、まだ、試行錯誤的なやり方では開発が完了しないという事態にまでは至っていないのではないだろうか。

そして、日本ではそんなぐだぐだな開発プロジェクトがたくさんあるはずなのになんだかんだいって製品はちゃんとリリースされていく。

おそらく、ギリギリのところで破綻していない理由は開発の前工程がぐだぐだでも、後工程で残業してがんばってなんとかつじつま合わせているのだと思う。表面的には破綻していないように見えて、プロジェクトメンバーの中には倒れている者もいるかもしれない。

このぐだぐだの先の見えない開発スタイルの流れはこのブログでも何度となく言っているように実際に開発に関わっている技術者が幸せになる目がない。毎回、前工程ぐだぐだで後工程でがんばるというやり方を繰り返していると、ソフトウェアの規模が増大し複雑化していくので、後工程でがんばる部分の負担がどんどん増えていく。

開発を重ねるたびに楽になっていくとか、クリエイティブなことを考える時間が増えるとかいった感じがしない。自分が不思議なのはこの悪循環な状況を改善したいと考える、もしくは、改善しなければ自分たちに明日はないと考える組込みソフトエンジニアが驚くほど少ないということだ。

なぜ、少ないのかはいろいろ理由があると思うが一番大きな理由は、このままではダメだと思っても状況を改善するには各方面に働きかけをしないといけない、人間系の壁を動かさないといけない、自分たちはソフトウェアを作るのは好きだけれど、人を動かすのは得意じゃないし面倒だと考えいるからではないだろうか。または、改善をして開発が楽になるというイメージを想像することができないのか。

自分が考える「開発を重ねるたびに楽になっていく開発」「クリエイティブなことを考える時間が増える開発」とは、その製品や製品群の価値が凝縮されているソフトウェア資産を明確にし、その資産の完成度を高めて再利用し、再利用資産を徐々に積み重ねていく開発だ。

これは一回の開発ではうまくいかない。何回か開発を重ねていくたびに徐々に楽になっていく。そして、再利用資産を抽出して隔離するときが一番時間も工数もかかる。だから、約三回の開発を経て効果がでることをプロジェクトの内外に説明して納得してもらう必要がある。

ぐだぐだの開発から抜け出せない理由は、複数の開発という長期レンジの視点を組織上位層もプロジェクトも持てていないのと、「最初は時間がかかるが、次かその次には開発効率とソフトウェア品質は確実に改善する」と宣言する自信とか気迫がないからだと思う。

組込みソフト開発の現状を打開するには、複数回の製品開発のプランとソフトウェア開発の技術の修得と変革を宣言して実行するリーダーシップのすべてが必要となる。
　

日本の組込みソフトウェア開発はこうすればよい

あるセミナーで、アメリカの有名企業が採用するような学生は、学生時代に『実践ソフトウェアエンジニアリング-ソフトウェアプロフェッショナルのための基本知識』を教科書として学んでいるという話を聞いた。『実践ソフトウェアエンジニアリング-ソフトウェアプロフェッショナルのための基本知識』は650ページの分厚い本で日本語版は7980円である。

セミナーの講師曰く、学生もこの本をすべて頭の中にたたき込んでいるのではなく、どこに何が書いてあるのかを知っており、必要なときに参照するのだそうだ。

そういえば、ソフトウェア系の海外規格を見ているとソフトウェアの開発計画を立てる際に、どんな方法論(Methodology)を使うのか書く欄があったりする。日本の組込みソフトウェア開発を始める前に、どんな方法論を使うのか？と聞かれて即答できるプロジェクトはいくつあるのだろうか。

欧米の企業がソフトウェアを開発する際にソフトウェア工学の知識・スキルを持ったものを採用し、基本的なソフトウェア開発の方法論を知っているという前提なら、ソフトウェア開発計画を立てる際にどんな方法論を使うのかという質問をするのは理解できる。以前書いた「インドのソフト会社」のときも同じように、ソフトウェアの開発者は基本的なソフトウェア工学の知識を身につけているというようなことを言っていた。

日本でもソフトウェアを開発する技術者は『実践ソフトウェアエンジニアリング-ソフトウェアプロフェッショナルのための基本知識』を熟読しろとは言わないが、ソフトウェア工学にはどんな方法論があるのかくらいは知っておいた方がよいのだろう。

でも、今回の記事のテーマは日本のすべてのソフトウェアエンジニアがソフトウェア工学の知識を身につける必要があるという主張を否定するところから始まる。

アメリカの一流企業では学生時代からソフトウェア工学の知識を見つけているという話を聞いたときに、欧米のソフトウェアエンジニアはソフトウェア工学の基礎知識くらいは誰もが身につけている、日本の技術者は不勉強で、その不勉強さがソフトウェア品質の問題を引き起こしていると言われているように感じた。

確かにそういう面もあるだろう。しかし、そこで疑問に思ったのは、「それでは、なぜ、日本の組込み機器のソフトウェア品質は平均的にどれも高いのか？」という点だ。欧米の組込み機器を使う機会はそれほど多くないが、一般的な評価として日本の組込みソフトの品質は高く、欧米や他のアジア諸国で作られた組込みソフトの品質には当たり外れがあるということをよく聞く。

このことについて、自分は何年も「なぜだろう」と考え続けている。何となく確信が膨らんでいるのは、そこには国民性や技術者の気質が関係しており、そこに差がある以上、欧米で効果を上げているソフトウェア工学の方法論を日本にそのまま適用しても同じような効果が得られるとは限らないと考えている。

欧米と日本で何が違うのか、どんな気質の違いがあるのか、何をどうテーラリングすれば欧米で成功したといわれるソフトウェア工学が日本の組込みソフトウェア開発にも役に立つのか？

ここにひとつの仮説がある。日本のエンジニアは自分の失敗、ミスを恥と感じる。だから、自分が作ったソフトウェアに問題があると分かると、それを恥と感じすぐに直す。これは、個人だけの話ではなく、仲間が起こした問題であってもそれをプロジェクトの問題であると感じ、プロジェクトや製品の信頼を回復するために寝食を忘れて問題の解決にあたる。

また、日本の消費者は非常に品質にうるさい。品質が悪い状態を決して許さない。食品の原材料の表記の順番が間違っていただけで自主回収する。消費者が製品の品質に対して敏感であり、問題が発覚するとその問題を自分やプロジェクトの恥と考え、自分の都合は横に置いてユーザーの信頼を回復しようとする。

この性質は日本特有のものであり、欧米や他のアジア諸国にはないと仮定する。すると、この性質が組込みソフトの品質を高めるケースと、逆に品質を低下させるケースが見えてくる。

－日本に特有の条件が組込みソフトの品質を高めるケース－

ソフトウェアの規模が小さい（10万行以下）の場合。ソフトウェア工学や方法論を使わずに試行錯誤で作ったとしても、問題が発覚した後の修正のスピードが速く、すべてのエンジニアがどんなに残業しても何とか納期と品質を守ろうとするため、リリースしたソフトウェアの品質が高い。また、フィールドで問題が起こってもすぐに修正し対応を終えるため、リリースしてから時間が経過するほど安定性が増す。

おそらく日本の組込みソフトはほとんどがこのパターンだったのだと思う。問題が発生してもすぐに直すので問題は大きくならず、対応を早くすることでエンドユーザーの信頼も上がる。

このような10万行以下のソフトウェア規模の場合、冒頭で紹介した『実践ソフトウェアエンジニアリング-ソフトウェアプロフェッショナルのための基本知識』を読まなくても、何か起こったらすぐ直せば問題を解決できるのだ。ただ、「修正が別の不具合を生む」危険性はある。問題が起こるとすぐに直してしまうので、別の不具合を引き起こしてしまう可能性が高い。

だから、日本の組込みソフト開発では、ソフトウェア構成管理や変更管理、レグレッションテストがソフトウェア品質の劣化防止に役立つ。これらの方法論はもちろん、基本的なソフトウェア工学の教科書に載っているが、ソフトウェア設計の方法論を使わなくてもソフトウェア品質が保つには、問題が発生したときの対応のスピードが早くして、かつ、修正が他の問題を起こさないことに注力を注ぐとよい。

でも、こんなソフトウェアの作り方はソフトウェア工学の基礎を学んできた人にとっては、理解しがたいと思う。試行錯誤で作って問題が発生したらさっさと直す。こんなのソフトウェアエンジニアリングじゃないといわれれば「その通り」というしかない。でも、できあがった組込みソフト製品の品質を見れば、そんな作り方したソフトウェア製品の方が、機能や性能が最適化され品質もよかったりする。

－日本に特有の条件が組込みソフトの品質を低下させるケース－

ソフトウェアプロジェクトやソフトウェア自体の規模が30人、30万行を越えてくると、発生した不具合が複数の人間のサブシステム、モジュールにまたがることが多くなる。一人のエンジニアでは問題の解決を帰結できなくなる。こうなるととたんに日本特有のエンジニア気質はソフトウェア品質の劣化防止に対して機能しなくなる。自分のパートの不具合はすぐに直すが、他人のパートの不具合かもしれない場合、積極的にその指摘をしない。たとえ、他人のパートの不具合であることという確信があっても、その技術者に「恥をかかせるかもしれない」という心理がはたらくからだ。

また、ソフトウェアも30万行を越えてくると、ソフトウェアシステムの設計図がないとさすがに一人のアーキテクトではシステム全体を把握しきれない。問題を起こったときにどこを調べればよいのか分からないこともある。

30人、30万行を超えるソフトウェアプロジェクト、ソフトウェアシステムでは、問題が起こったらすぐに直すというアプローチだけでは、ソフトウェアの品質を保つことができない。もし、かろうじてソフトウェア品質を保てているのなら、それは何かあったらすぐ直すというアプローチを徹夜してでも繰り返して納期に間に間に合わせているだけだ。単純な修正アプローチを時間をかけ繰り返すことで、力ずくで収束させようとしている。

ちなみに、この作り方はソフトウェアを付け足し続ける、ソフトウェアを修正し続けるため、機能ばかりたくさんあってコンセプトが不明確な商品になることが多い。最初からソフトウェアシステムのコンセプトを明確にして着手していないのだから、ソフトウェアの付け足しでシステムの規模が大きくなれば、商品コンセプトがぼけてくるのは当たり前といえば当たり前だ。

－じゃあ、どうすればいい？－

今後、日本の組込みソフトウェア開発は30人、30万行を超えるプロジェクトが多くなるだろう。日本人のエンジニア全員が品質に対する意識が高く、問題が起こったときに素早く対応しする特長を活かしながら、ソフトウェアの大規模、複雑化に対応するにはどうすればいいか、ここでアイディアを提言しておこうと思う。

【日本の組込みソフトウェア開発はこうすればよい】

まず、ソフトウェア開発のプロジェクトをグループ分けし、ひとつのグループが10万行以下になるようにする。そして、それぞれのグループの開発ソフトウェアの責務を明確にする。

そのこころは、問題が発覚したときの修正のスピードが早いことが日本のエンジニアの特長なら、問題が発覚したときにどのサブシステムの問題か一発で分かるような機能分割をしておき、そのサブシステムを作ったグループをすぐに特定して問題の解決に当たらせるためだ。少人数のグループで他のサブシステムにまたがった不具合でなければ修正のスピードは速いはずだ。

次に、システムをサブシステムに分割するときに、その商品の価値が凝縮されている部分をくくり出し、このサブシステムを開発、保守するメンバには優秀な技術者をアサインする。

この方法で注意しなければいけないのは、サブシステムとサブシステムのインタフェースの明確化と、サブシステム間のインタフェースは簡単に修正してはいけないという点だ。日本人の特長である、問題が発覚したらすぐに修正するという習性には、修正していいところと簡単に修正してはいけないところの明確な区別がない場合が多い。サブシステム間のインタフェースまで簡単に修正してしまったら、大規模システムを責務のあるサブシステムに分けた意味がない。サブシステム間のインタフェースの修正には、その修正の妥当性を確認する工程を設け、簡単には実施できないようにする必要がある。

また、システムをサブシステムに分割する役目は優秀なアーキテクトが行うとして、きれいにサブシステムが責務に分かれたとしても、インターフェースのオーバーヘッドが大きくなって製品に求められる性能要件が満たせなくなる危険性はある。

この問題の解決方法は、『組込みプレス vol.8 』の特集1 Part 2 の再利用資産の抽出法を読んでいただきたい。すでに、製品に求められている市場要求を分析し、すでに実現できているソフトウェアシステムの構造をマッピングして、製品の価値が凝縮されている重要なソフトウェア資産を抽出する方法を解説している。

「じゃあ、どうすればいい」のエッセンスをまとめると次のようになる。

1. 製品に求められる要求品質とすでに実現しているソフトウェアシステムの構造を分析して、ソフトウェア再利用資産を抽出しておく。
2. 抽出したソフトウェア再利用資産をベースに、システムをサブシステムに分割し、ひとつのサブシステムの規模が10万行以下になるようにする。
3. 10万行以下のサブシステムに対して、特定の技術者をアサインする。
4. サブシステムの重要度に応じて、優秀な技術者をアサインする。
5. システムのアーキテクチャとサブシステム間のインタフェースは簡単に変更してはいけないことを、プロジェクトメンバ全員に伝える。

上記のアプローチで欧米のソフトウェア開発のメソッドにない点は、すでにあるソフトウェアシステムのアーキテクチャを分析するというリバースエンジニアリングが先頭にある点と、サブシステムを分割するだけでなく、そのサブシステムを開発するエンジニアも固定すべしと主張している点だ。

このアプローチでは、ソフトウェア工学を熟知している必要があるのは、極端に言えばアーキテクトだけでよい。ただ、アーキテクトは一般的なソフトウェア工学だけでなく、市場要求の内容や製品に求められる機能要件と性能要件も熟知している必要がある。

したがって、今、日本に求められるのはその業務ドメイン、製品群を取り巻く環境、ハードソフト合わせた要求の実現手段を知っているアーキテクトを育て、そのアーキテクトにシステムのアーキテクチャとサブシステムの分割を行わせ、サブシステムを担当する技術者を特定してしまうことだ。

以前、トヨタのソフト戦略の記事を書いたときにECUの統合戦略が危ない方向に向かっているのではないかと思ったのは今思い返せば、統合すればするほどサブシステムと技術者がセットになって他のサブシステムと切れているという一体感が薄れることが、日本の技術者の気質に合っていないのではないかと感じたからだと思う。

P.S.

図らずも、一般のエンジニアはソフトウェア工学を学ばなくてもよいような論調になってしまったが、決してそう主張したいのではない。自分自身 SESSAMEやEEBOFに参加して2003年頃から相当ソフトウェア工学を勉強したつもりだ。でも、2003年以前15年以上に渡って、自分の業務ドメインに関する領域でどんなやり方が最もふさわしいか考え続けたことが、最適なソフトウェアアーキテクチャの構築に貢献したように思う。

この記事で言いたいのは、もしも、現在組込みソフトウェア開発の品質で大きな問題が発生しているのなら、日本の技術者の特性をよく考えて、いま上手くいっているところがどこなのかをおさえた上で、欧米で培われたソフトウェア工学の方法論を適用するべきだということである。日本の技術者の特性を考えれば、まずはボトムアップの視点で役に立ちそうなものに着目し、その一方で今回の記事に書いたようなトップダウンで改善すべき点を探るのが効果的だと思うということである。