僕は機械メーカーで組み込み系ソフトウェア開発の仕事をしています。
新規開発なうですが、そろそろプロジェクトが炎上しそうで怖いです(笑)
さて、前回「組み込みソフトウェアの仕事はとにかく時間がない」という話をしました。
わが社のソフトウェア品質について
今回は「ソフトウェア品質の概念が理解されていない」ということを書きたいと思います。
これが本当に困った問題で…。
まずソフトウェア品質とは何か、ということですが「当たり前品質」と「魅力的品質」という大きく分けて2種類がありますね。
当たり前品質：
顧客がサービスのある特性に対して、あって当たり前と感じる品質ですね。何のトラブルもなければ意識されることはないが、ひとたびトラブルが発生すれば顧客はそのサービスに対して大きな不信感を覚える可能性がある、というものです。
顧客がサービスのある特性に対して、なくても不満を覚えることはないが、あれば満足感を覚え、サービスに対して信頼感が増す、といったものです。あるに越したことはない、いわゆる付加価値ですね。
今回話したい内容は前者の「当たり前品質」です。
タイムリーな話題としてみずほ銀行のシステム障害のトラブルがありましたね。
もう6回も大きなシステム障害があったということでユーザはうんざりしていることだろうし、なによりサービスに対して不信感を感じていることでしょうね。
「このままこのサービスを利用していて大丈夫だろうか、ほかのバンクに乗り換えたほうがいいのではないか」
と思うのが自然な感情だと思います。
うちの会社でもとくに上層部の方々は他人事と思わずにいてもらえるといいのですが…。
さて、わが社はある製品を作っているメーカーですが、いちおう世界的なシェアを持っていてありがたいことに愛用してくれるユーザもかなりいるようです。
しかしその一方、わが社の製品はトラブルも少なくなく、「品質がよくない！」というお怒りの声もよく聞く気がします。
それに対して後発の競合他社の製品は非常にトラブルが少ないらしく、徐々にユーザの信頼感を勝ち取り、ついにはわが社から乗り換えるユーザが多発する、という事態に至っています。（ヤバい）
トラブルが発生する原因はさまざまですが、その中の一定の割合はソフトウェア関連のものです。
なぜ、ソフトウェア関連のトラブルが発生するのか？
それはバグや仕様漏れが多いからです。
ではなぜ、バグや仕様漏れが多いのか？
エンジニアの技量が低いから？
それはあります(笑)
しかしそれ以上にみんなソフトウェア品質について真剣に考えていない、ということが理由だと思います。
さらに言えばソフトウェア品質というものを、わが社の多くの人から認識すらされていないと思います・・・。
いちおう僕が所属しているところは組み込み系ソフトウェア開発の部門なのでそれなりに話題に挙がることはあります。
ですが、上層部や他部門の人たちは、そんな言葉を聞いたことも考えたこともない人たちが多いように感じます。
末端の作業者はまあまだしも、設計リーダークラスの人たちは他部署であってもソフトウェア品質についてもっと考えてほしいものです。
わが社では組み込みソフトウェアについてどんなイメージを持たれているかというと、
- 製品をリリースした後でも簡単に修正できてうらやましい
- 開発コストが0でうらやましい
- 開発が遅い！何やってるの！？
- そもそも難しそうでよくわからん（興味なし）
15分ほど考えてみましたがほぼこのどれかですね。
このことが実際の仕事にどのように影響してくるかというと、
メカ的な問題をソフトウェア制御で無理やりカバーして品質が落ちる。負債を抱える。
ということになります。
具体的にはどういうことかというと、
ある新機能でメカ的な問題が発覚した・・・
↓
コストと時間がかかるからもう直すことはできない！
↓
そうだ、組み込みソフトウェア制御でなんとかカバーしよう！
↓
時間がないから急造で制御を組み上げる・・・
↓
当然のようにバグが入る、設計している時間がないからソースコードもぐちゃぐちゃ・・・
（これがわが愛する開発部門の王道パターン）
「バグがあっても後から簡単に直せるでしょ？」
と思われていますが、それは表面的な事象しかとらえていません。
（言われるとすごくムカつく言葉です。組み込み屋さんに言わないように気をつけましょう。）
バグがあったことで製品を購入したユーザはどう思うでしょうか。
みずほ銀行のトラブルのように、
「この製品（サービス）は信用ならん！買って損した！」
と不信感を感じるようになるでしょう。
それによって今後わが社の製品を買ってもらえなくなるかもしれません（というか現にそうなっています）。
さらに口コミで
「あの会社の製品はしょっちゅうトラブルが起きるから買わないほうがいいよ…」
という流れになるかもしれません（ユーザのブログなどを読むとそうなってるような気がします…）。
また、ぐちゃぐちゃになったソースコードは、技術的な負債として残り続けます。
技術的な負債によって、その後の開発のたびにそのいやなソースコードに手を焼かされる、ということになります。
それによって開発工数は増大し、新たなバグも混入しやすくなります。
つまり「開発コストは0ではない」です。
作った成果物（設計書やソースコード、ツール）が資産とならずに負債となってしまえば、その後のコストは増え続ける一方です。（資産運用とか借金に似ていますね）
「ソフトウェア開発はコストがかからなくていいなあ」という発言もよく聞きますが、まったくもって検討外れだと思いますが、・・・目に見えないコストは実感しづらいよなあとしみじみします(笑)
実際にそんな過去の遺物（レガシー）となって誰も触りたがらないソースコードはいくつも存在しています。
今後もこのソースコードと付き合っていくのかと思うと頭を抱えたくなりますね(笑)
※技術的な負債を抱えたソースコードのイメージ
少し暗い話になってしまいましたが、
まとめとしては
ソフトウェア品質が理解されていない
↓
無茶なスケジュールによって開発することになる
↓
バグが増える、ソースコードの品質が落ちる
↓
バグによってユーザに不信感を持たせる、ソースコードの技術的な負債を抱える
といったところでしょうか。
今後どうしていくべきか
製品の品質については全社的な取り組みとなっています。
その中でソフトウェア品質の存在感も上げていきたいですね。
最近ではトップダウンではなくボトムアップで組み込みソフトウェア部門をよくしていきたい、と開発の偉い人たちが少し動きを見せてくれています。
僕やほかの若い有望な仲間たちで組織や開発プロセスを改善していきたいと思っています。
まだ全体を巻き込むような影響力はありませんが、まずは自分の受け持っているプロジェクトで成功例をつくり、そこからほかのプロジェクトにも輪を広げていきたいですね。
具体的に自分のプロジェクトで何をするか。
製品リリースの日程までにこなさなければいけない作業は山のようにあります。その中でどれだけ品質を高めていけるか、が焦点となるかと思います。
地道な取り組みにはなりますが、他部門の要求を取りこぼさないように常にセンサーをはっておき、自分のチームの作業者の作業をできるかぎり可視化し、進捗に遅れがないようにする、リーダーでありつついいコーチとして取り組んでいく所存です。
