アイスティー大好き_組み込みエンジニア

買ったものや読書のアウトプット、仕事のこと

話を聞こう。仕様レベルでなく要求レベルの話をだ。

こんばんは。keyです。

僕は機械メーカーの開発で、新製品開発プロジェクトの組み込みソフトウェア開発部門の設計リーダーをしています。機械メーカーの組み込みソフトウェアエンジニアの仕事は端的に言ってかなり大変です。たぶん、うちの会社に限った話ではないと思います。

以下に挙げるさまざまな大変さは、「上層の方々が、プログラミングに対して理解があんまりない」というところに起因していると僕は感じています。

 

僕が問題だなと感じていることを以下に列挙しました。

  1. 必要な情報が落ちてこない
  2. 要求レベルではなく、仕様レベルで依頼をしてくる
  3. とにかく時間がない
  4. ソフトウェア品質の概念が理解されていない
  5. デバッグ環境がまともに用意されない
  6. トラブルがあった時の最終的な責任を負わされることが多い気がする…

ひとつずつどういうことか説明し、いまのプロジェクトでどうやって対処しているか書いていきたいと思います。

 

1. 必要な情報が落ちてこない

まずは何といってもこれが困りますね~。

何かしらの課題が存在していて、メカもしくは電気的には課題解決のために動き出しているのにその情報が僕たち組み込みソフトウェア部門には落ちてこない…。

納期は日に日に迫っているというのに…。

それではいつ情報が伝わってくるのか、いままでの経験上それは以下のようなタイミングです。

  • メカ(もしくは電気)的には課題に対して対策を講じた
  • 動作評価の結果問題なし
  • いざ実際のマシン(製品)に適用してみる
  • 問題となっていた箇所とは別の箇所で予想外の新たな問題が発生する
  • 解決するためにはソフトウェア制御的な変更が必要だ
  • 明日までに何とかならない? ←ココ
  • 何とかします…(怒り)

つまりわりと手遅れな状況になってから情報が伝わってきたりします。

いままで何度も経験していますが、組み込みソフトウェアの仕事をしている上でもっとも萎える瞬間の一つですね。

課題解決には本来メカ、電気、ソフトそれぞれの視点が必要なはずなのになぜか情報が落ちてこないことがわりとよくあります。

なぜ情報をくれなかったのか聞くと、「ソフトウェア制御的には問題のない課題だと思ったから」というお決まりの言葉が返ってきます。

「ソフトウェア制御的に問題がないかどうか、他部門が勝手に判断するな!」

と言いたいですよね。

<対策方法>

対策方法としては日ごろから言って聞かせることです。

「ソフトウェア制御に関係のないことだと思っても情報はくれ」

「どんな些細なことでも、不正確な情報でもいいからとりあえず伝えてくれ」

部門間の定例ミーティングの場でしつこくても毎回確認する必要があります。

定例ミーティングをもしやってないとしたら、それは非常に危険な状況です。すぐに定例ミーティングをやるように提言しましょう。

 

他部門の人たちはAという仕様変更を加えるとBやCという仕様に影響がある可能性がある、ということまで考慮していない場合がけっこうあります。ましてやソフトウェア制御的な仕様にまで思いを馳せてくれる人はほとんどいません(考慮してくれるとそれはそれで迷惑かもしれない)。

気をつけましょう。

 

f:id:keyhustle:20210828102735j:plain

罠か・・・?

2. 要求レベルではなく、仕様レベルで依頼をしてくる

これもかなり困りますね~。

何かの機能実装の依頼を他部門の人がしてくるとき、要求レベルで話をしてほしいものですが、はっきり言ってそれができる人は稀です。それができる人は無条件で好感を持ってしまいます(笑)

簡単に言えば「要求」は実現したいことで、「仕様」はその実現方法の規定といったところでしょうか。

※本当は「要件」:実現する手段 というのも間にあると思いますがここでは割愛します。

「こういう機能を実現したいんだけど」っていう風に話しかけてくれればいいものを、「こういう仕様ってできる?」ってな話をいきなりされる場合が非常に多い。

そういう時はこっちは全体像が把握できていないから言葉に詰まってしまう。

(「えっ…、それはまあできるとは思うけど、それをやることによって何ができるようになりたいの…?ほかにも検討しないといけないことはたくさんあると思うし、うかつにできますって言えないぞ…」)

といった心情になります。

実際に僕が経験した例を挙げます。

装置の端面をふき取るワイパー機構をもつマシンがあるのですが、マシンの使用状況によって形状の異なるワイパーをユーザーが任意で取り付けないといけない、というケースがありました。

僕はまだその要求の全体像を知らず、いきなり「ワイパーの使用回数の内部カウントを2つ(プログラム内部で)持つことはできる?」と聞かれて非常に戸惑った。

何しろこちらは何のためにもう一つワイパーの内部カウントを用意する必要があるのか知らないんだから!

話を振ってきた相手は、「ワイパーを2種類用意する必要があるということは、内部カウントも2つ用意する必要があるということだ!」と思ったんだと思いますが、実際に実現しなければならないことはもっともっとたくさんありますよね。

  • ユーザーにワイパーを交換するタイミングを知らせる必要がある
  • ユーザーにいまどちらのワイパーを使っているか知らせる必要がある
  • 使っているワイパーがどちらなのかによって装置の動作を制限する必要がある

など、考えなければならないことは他にもたくさんあります。このようなソフトウェアエンジニアとそうでない人の考えのギャップを埋めることは、ソフトウェアエンジニアにとってはいつでも大変な仕事だといえると思います。

<対策方法>

 要求と仕様の違いを他部門の人にしっかり理解してもらうのは難しいかもしれません。相手の要求をしっかり洗い出すのはソフトウェアエンジニアの大事な仕事の一つだと思います。話を聞くこちら側がうまくインタビューして、相手の要求をしっかり汲み取りユースケースを網羅できるようにしたいですね。

「うん、なるほど。話はおおよそわかった。それでその機能を実装することで実現したいことっていうのは、つまりこういうことかな?はいはい、なるほどなるほど。ということはこういう場合も考えられるよね。その時はどうしたらいいかな?」

といった感じで要求を明確にして、影響範囲となる問題をあぶりだしてあげましょう。

まあ、うちの会社だと自分の言いたいことだけ言って、時間がないから(もしくはそれ以上考えることは重要だと思わないから)なかなか取り合ってくれない人とかもいるんですけどね(落涙)

できる限り忍耐強くベストを尽くしたいところです。

 

いったんここまで

長くなってしまうので、今回はここまでにしたいと思います。

次回、「組み込みソフトウェアエンジニアはつらいよ-その2-」です。