新製品開発も佳境を迎えてきました。
果たして納期通りにリリースできるのでしょうか・・・？
今回は「トラブルがあった時の最終的な責任を負わされることが多い気がする…」という問題について書きたいと思います。
いちおう続きものとなっています。
前回の記事はこちらです。
組み込みソフトウェアが最終的な責任をとらされてる・・・？
いま新製品の開発をやっていますが、こういうことが頻発します。
- ある機能を実現するユニットの動作評価を行う
- メカ的な設計ミスによってうまく動作しない場合がある
- 組み込みソフトウェア制御でなんとかする
まあ・・・メカ的な設計変更は時間がかかるし金型変更となると何百万というお金がかかるのは理解しているんですけどね・・・。
それがソフトウェア制御によってカバーできる程度のミスであればそうするべきだとは思います。
でもメカ的なミスがあったことを、まるで何もなかったかのようにしているんですよ。
その話は本来であればプロジェクトに直接かかわらないメカ設計部や統括マネージャーのもとまで伝わるべきだと思います。
まるでメカ的なミスなどなかったかのようにすべて組み込みソフトウェア部門に丸投げ（言い方は悪いけど）。
しかも、組み込みソフトウェア制御の観点では、想定していなかった変更要求があったということになります。
設計の時点で想定していない問題なので、当然変更は不自然な制御とな可能性が高いです。
それによってバグが発生するリスクは大きく高まります。
それでもし市場でバグによってトラブルが発生したら？
（ああ、また組み込みソフトウェア部門がやらかしてくれちゃったな）
という空気になるんですよね。
元はといえばメカのミスなのに、それは隠ぺいされてしまい、現象として組み込みソフトウェアのバグだけが見えている。
かなーり理不尽な話だと思います。
実例を挙げる
最近の実例では、こんなのがあります。
- マグネットによって結合しているユニットAとBがある
- ユニットAはBと結合した状態で走査する
- 走査中に緊急停止すると、慣性力によってマグネットの結合が外れてしまうことがある
- 結合部の上にソレノイドバルブによって開閉可能な金属カバーをつけることで緊急停止時にも結合が外れないようにする
- ただしソレノイドバルブは新規で追加するのではなく、すでに別の目的で使用しているものを利用する（←ここがあやしい！）
この話を聞いた時からいやな予感がしていましたが、いやな予感は的中しました（笑）
すでに別の目的で使用しているソレノイドバルブを利用することで、正常系に関しては問題なく要件を満たすことができました。
しかし、異常系にかんしてはボロボロでした・・・(´;ω;｀)
元の機能と新しい機能の両方の異常系が問題なく動作するのは機構的に無理でした。
そのことをメカ設計の人とプロジェクトリーダーに伝えましたが、もちろんもうメカ設計を変更することはできず（スケジュール的に間に合わないから）・・・組み込みソフトウェア制御でなんとかするしかありません。
いちおう解決案はいくつかありますが、どれも相当無理やりな方法です。
うまくいくかわかりません。
これで市場で問題が発生したら、やはり組み込みソフトウェア部門の（ぼくの）責任となってしまうのでしょうね（笑）
開発プロセスがヤバイ
わが社は短納期でわーっと作り上げるスタイルです。
最初に引かれたデッドラインが後ろに下がることはほとんどありません。
（あれ？でもメカの評価が間に合わないから、という理由でリリース時期がずれたことはあるな・・・。度重なる仕様変更でソフトウェア開発が間に合わないから、という理由でずれたことはない気がするけど）
なので佳境に入ってくるともう開発プロセスはめちゃくちゃで、口頭でなんとなく伝えられたものを仕様として実装しなければいけないということもあります。
そんな中で責任の所在がどんどんうやむやになっていくんですね・・・。
そもそもメカ設計の段階で関わらせてほしい
いまだと出来上がった機構を「はいこれ！」ってバンと見せられてから、「あれ、これおかしくない・・・？」ということがよくあります。
そうなる前にメカ設計の段階から意見を言わせてもらいたいものですが。
なぜなら組み込みソフトウェア制御設計をしている人は、普段から色んなユースケースを検討することに慣れています。
機構に欠陥がある場合、それに気づく可能性は高まるというものです。
メカ以外の第3者目線を取り入れることにもなりますし！
上で挙げた例以外にも、あれもこれも・・・
「なんでもっと考えてから作らないの！？メカ設計は後戻りできないんでしょ！？」
と突き詰めたくなりますね（笑）
おわりに
いま古典的名著である『熊とワルツを』を読んでいますが、ソフトウェア開発におけるリスクとの向き合い方についての本です。
読みながら思わずうなづいてしまうような、あるある話がたくさん出てきて面白いです。
序盤にデンバー国際空港の立ち上げ時の例が出てきます。
手荷物検査システムのソフトウェア制御が完成しなかったせいで空港をスタートさせるのが大幅に遅れた、という話です。
筆者が言及する、
「こういうときに各サブプロジェクトの責任者がよく使う手は、準備は完璧だと主張して、ほかの誰かが最初にボロを出すことを期待するという瀬戸際作戦である」
というのには思わずうちの会社の話かと思って笑ってしまいました。
デンバー国際空港のソフトウェアの遅れは、そもそもの納期が無理な設定だったことが原因のようです。
それにもかかわらず、スケジュールの遅れの責任を追及され、ほかの部門の遅れはそれによって覆い隠されてしまいました。
スケープゴートに使われたような形でしょうか。
ソフトウェア開発に対する理不尽な話はわが社だけでなく、世界各国共通なんだなとしみじみしています。
