ここ数年、ソフトウェアの開発効率はどうすれば高まるのか、ソフトウェア品質はどうすれば維持できるかかを考え続けてきた。しかし、教科書や文献に載っている方法論をそのままやってみてうまくいくような気がしない。雑感として次のようなことを感じる。
- 方法論は昔に提唱されたものの方が効果が高く、新しければ新しいほどハードルが高いような気がする。（問題の根は共通で人間はそれほど成長していない）
- 日本の組込みソフトウェアシステムの品質は高度な技術で維持されているように思えない。
- 方法論をツールに隠蔽して解決しようとして失敗するプロジェクトが山ほどある。
とはいうもののいろいろな文献や講演を聴いたときに「これは使える」と思うこともある。後で冷静に「使える」「使えない」を考えたとき、「商品化までたどり着いて、かつ、実際に効果があった」のか「実施したが商品の価値に貢献するところまで確認していない」の違いではないかと思った。
今回の話しは、第7回 クリティカルソフトウェアワークショップ(WOCS2009）の講演を聴いて、「これは使えそうだ」と感じたことと、なぜ、日本では教科書に書かれたことがすんなりと導入できないのかの理由について考えたことだ。
まずは、冒頭の図を見て欲しい。ソフトウェア職人気質とソフトウェア工学を対比させた図で、「ルール/責任」「システム/ツール」「顧客や品質に対する意識」という「USとJapanの文化の違いと商品品質との関係」の記事で引用したGD3 コンサルティング代表/JMAC GD3 センター長 の吉村達彦氏の視点を組み合わせている。
自分の中では日本の多くの組込みソフトウェアプロジェクトの現状はこの図で言い表せるのではないかと考えている。この図で言いたいのは次のようなことである。
- ソフトウェア工学の教科書にはソフトウェア技術者の職人気質が品質に与える影響が書かれているものが少ない。（逆に書かれているのは『ソフトウェア職人気質』や『ピープルウェア』など）
- 日本で古くから提唱されている品質向上施策は職人気質的だ。（TQMなど）
- 「ルール/責任」「システム/ツール」「顧客や品質に対する意識」は日米でかなり異なる
- 日本的ソフトウェアプロジェクトには何か特殊性がある
- 日本のプロジェクトに欧米のアプローチをそのまま取り入れようとするとうまくいかないことが多い
- 日本のプロジェクトは表面的には欧米のアプローチを取り入れるポーズはとるが実際には役に立たないと考えていることが多い
- 日本では「ソフトウェア職人気質」と「ソフトウェア工学」どちらかに偏ったままでは未来はない
- それぞれのよいところを見極めながらバランスよく取り入れることが大事
「ルール/責任」「システム/ツール」「顧客や品質に対する意識」の比較の詳細は、「USとJapanの文化の違いと商品品質との関係」の記事を参照してもらうとして、ここではJAXA（宇宙航空研究開発機構）とIPA（情報処理推進機構）が共催した 第7回 クリティカルソフトウェアワークショップ(WOCS2009)の講演でこれならうまくいくのではと感じたことを書こうと思う。
まずは、MITのナンシー・レブソン教授が言った「安全性と信頼性は区別して考える必要がある」と言ったことについて。
WOCS2009では、ソフトウェアのシステム安全のオーソリティであるMITのナンシー・レブソン教授が来日(二度目)し、2時間40分のチュートリアルを講演した。ナンシー・レブソン教授はいつものように安全性と信頼性は異なる、区別する必要があると話し、信頼性を高めたソフトウェア部品を組み合わせてもシステムとして安全にはならないことを説明した。なぜかという理由は複数ある。
【信頼性の高いソフトウェア部品を組み合わせたシステムは安全とは言えない】
- ソフトウェア部品の信頼性を100%にするだけのテストができない。
- 仮に信頼性を100%にしても、ソフトウェア部品は簡単に変更できてしまう。
- 部品が完全でも部品の組み合わせかた使い方で事故は起こる。（デッドロックなどが典型的な例）
だから、「ソフトウェア部品の信頼性を高める」とシステム安全は必ずしもイコールではないのだ。ナンシー・レブソン教授はこれまで数々のソフトウェアが起因する事故を調査することにより、このことを確信した。だから、安全性と信頼性は区別して考える必要があると言っている。実際に起こった事故から再発防止策を考えることは次回役に立つ可能性が高い。
自分は、クリティカルソフトウェアの開発に長く関わっていたし、そのドメインにおける事故や事故を起こした原因について常にアンテナの感度を高くしていたので、安全性と信頼性を同一視すると危ないということは直感的に分かっていた。
ところが、世の中ではソフトウェアの信頼性を高めることが、ソフトウェアシステムの品質を高めるために有効であるという考え方が流行っているように感じる。例えば、ソフトウェア部品が機能安全(IEC61508)の認証を得るとシステムが安全になるという考え方や、形式手法（フォーマルメソッド）のような数学的に漏れのないことを証明したソフトウェアを目指すことで品質が高まるというアプローチだ。
自分は形式手法がこれだけ話題になっているのは、情報処理系のアカデミアが論文にするのに格好のテーマだからではないかと予想している。ソフトウェア工学は自然科学ではないから、主張が正しいことを証明することがとても難しい。ソフトウェアは技術者の日々の積み重ねであるため、そもそもソフトウェアを作っている技術者の特性によって、ソフトウェアの品質も左右されてしまうのだ。そして、人間の脳は必ずしもコンピュータのようにロジカルではないため、いつも一定の動きをするとは限らない。
そうなると、ある方法論を提唱したとしてもそれが常に同じような効果を現すわけではない。だから、情報処理系の論文で、何%バグが減ったとか、開発効率が向上したとかいった記述を見つけたとしても、自分の組織で同じ数値をたたき出せるかどうかはわからない。
ところが、形式手法（フォーマルメソッド）は正しいことが数学的に証明できるから、論文のテーマとしてはうってつけだ。形式手法（フォーマルメソッド）は安全性と信頼性が同じではないということを分かっている技術者、組織が適用すれば効果的に働くが、信頼性を高めることでシステムの安全性を確保できると考えてしまったらかなり危ない。形式手法（フォーマルメソッド）はFelicaの開発に有用だったという実績が有名だが、どんな開発のどのようなシーンに適用するとよいのかを考える＝実績から有効な範囲を予測し、自分の開発に投影してみることができないと失敗すると思う。
さて、WOCS2009の2日目の講演で、三菱電機の白坂成功氏と、JAXAの片平真史氏と、ナンシー・レブソン教授の話は、非常に欧米的でかつシステマティックでスマートな感じがした。ナンシー・レブソン教授はアメリカ人で白坂氏と片平氏のミッションはロケットや宇宙開発がテーマでその技術や施策はNASAの影響を強く受けているから当たり前ではある。一方、プログラムの最後に企画されたパネルディスカッションで発言された自動車系のソフトウェア技術者の方々のお話は非常に職人気質な感じがした。
この感覚は、冒頭の「ソフトウェア職人気質」と「ソフトウェア工学」の比較に合致している。三菱電機の白坂成功氏と、JAXAの片平真史氏の話しは、基本的にはソフトウェア工学的なアプローチでソフトウェアの安全設計を実現しようとしていて、欧米で培われたアプローチの弱点と思われる「顧客や品質の対する意識」が低い点をカバーするアクティビティとして第三者による独立検証と妥当性確認が行われたいたように思う。三菱電機の白坂成功氏は日本で開発したソフトウェアシステムの設計情報、アーキテクチャを第三者のレビュー（IV&V）によって徹底的に見直すアプローチを説明していた。JAXAの片平真史氏はソフトウェアシステムの安全設計のベースには安全文化が必要と語っていた。また、ナンシー・レブソン教授は安全性と信頼性の区別の他には、「ソフトウェアの定量的な計測だけでなく、システムを全体から定性的に分析することが安全設計には必要」と言っていた。この3方の話しに共感する感じがしたのはそれぞれ実経験、実績に基づく話しだったからかもしれない。
一方、パネルディスカッションで日本の自動車の開発ですでに確固たる品質の実績を上げてきた人たちは何を語ったかといれば、ハイブリッド車という新たなテーマに対しても「顧客満足、品質向上を高めたいと思う意識と、その意識から生まれる方法を醸成させる」というアプローチで品質を維持している内容だったと思う。これは宇宙開発での方法論の後に聞いてしまうとあまりスマートな話しには聞こえない。でも、今後はどうかわからないが少なくともこれまでは、この日本の職人気質から生まれた安全ソフトウェア設計に関するアーキテクチャとエンジニアの粘り、がんばりが日本のソフトウェアシステムの品質を維持してきたのだと思う。
だからこそ、今一度冒頭に掲げた「ソフトウェア職人気質」と「ソフトウェア工学」の比較をよく見て、自分の組織、自分のプロジェクトがどちらかに偏りすぎていないかどうかをチェックして欲しいのだ。
ソフトウェア技術者はソフトウェアをアウトプットする機械じゃない、生身の人間で必ずしもロジカルな思考をするとは限らない。それに気がついていた一部の人たちは、ソフトウェア工学をベースにしながらも、予想できない人間の思考や行動からくるズレを補正するために、プロセスを繰り返すことで軌道修正したり、改善のプロセスを導入することを思いついた。アジャイルやXPなども、人間の不確定な部分からくる品質の低下を防ぐアプローチではないかと思う。
だから、日本で安全ソフトウェアを実現させるためには、人間の特性や日本人の特性・集団心理等をよく理解した上でソフトウェア工学を導入する必要がある。
日本のソフトウェアエンジニアが目指すのはやはり『スマートな職人気質』なのだと思う。（スマートといっているのは職人のいい仕事の裏付けがソフトウェア工学で説明できるということ。単なる職人気質はスマートではない。）
今後、この比較文化論的考察は今後も続け、何かしらのタイミングで公開していきたい。
0 件のコメント:
コメントを投稿