ワクチン接種しました
モデルナワクチン接種2回目を受けました。いまは受けてから2日たったのですがほとんど副反応はありませんでした。腕がちょっと腫れていてちょっと痛いくらいです。たくさんスポーツ飲料を飲んで、カロナールを予防内服したのがよかったのでしょうか。
職域接種で社内の人が同時にワクチン接種したのですが、1日たった昨日は発熱やだるさで会社を休む人がとても多かったです。僕の所属するプロジェクトメンバーは3割程度の人しか出社していませんでした。副反応があまりでなくて僕はラッキーだったと思います。
本題
さて本題ですが、前回の続きで「組み込みソフトウェアエンジニアはつらいよ」という話です。いちおう補足ですが基本的には楽しいです。たまに理不尽を感じることがあってそれについて書いています。大なり小なり別の会社でも組み込みソフトウェアエンジニアは同じような経験があるのではないでしょうか。
前回の記事のリンクは以下にあるので、ぜひ見てみてください。
前回、こんなところが大変だよ！というのを6個ほど羅列しました。
- 必要な情報が落ちてこない
- 要求レベルではなく、仕様レベルで依頼をしてくる
- とにかく時間がない
- ソフトウェア品質の概念が理解されていない
- デバッグ環境がまともに用意されない
- トラブルがあった時の最終的な責任を負わされることが多い気がする…
今回は3番目の項目について書きたいと思います。
3. とにかく時間がない
実際にあった例ではこんな感じです。
メカ屋さん「この製品には新しいオプション機構が搭載されます」
僕「（初耳だ…）」
メカ屋さん「この二つのセンサでモータの位置を制御してもらって、本体から送り出されたモノを安定して搬送できるようにしたい」
僕「（センサとアクチュエータが複数個ある機構か。本体との連携をしっかり考えないといけないぞ…）」
メカ屋さん「スケジュールの兼ね合いもあるので1週間でいけます？」
僕「せめて2週間はください…」
※心情
ほかの部署も同じように忙しいのですが、もう少し人道的な日程でお願いします…と言いたい時があります。
「なんでそんなに時間がかかるの？」
と言われることがありますが、「仕様検討と設計と実装とテストがあって～」といっても他部署の人はなかなか理解してくれません。
メカや電気だと成果物として実際のモノが出来上がる一方、ソフトウェアは目に見えないものなので扱っていない人からするといろいろ想像がつきづらいですよね。
「ソフトウェア屋さんは長時間デスクにいるけど、何してるのかわからん」と言われたこともあります。
ところで常々思うことですが、どうして組み込み屋さんは装置の構成を検討する段階に呼んでもらえないのでしょうか？
うちの会社だけかもしれないけど…。
<対策方法>
割とすぐできる対策
時間の管理は上の人の仕事だからなかなか対策するのは難しいかもしれません。
これもやはり他部門とのコミュニケーションを密にとっておき、今後開発がどのように進展していくのかしっかり把握しておく必要があると思います。
そのうえで大きな工数が発生しそうだと感じたら、できるだけ早い段階でプロジェクトリーダーに、このくらい工数がかかりますよ、と伝えておくのがいいでしょう。
そんなことばっかり言っていると煙たがられるかもしれませんが気にしている場合ではないです。
ソフトウェアの仕事としてちょっと仕事をすすめてみないと工数が読みづらい、というのはありますよね。実際にやってみたら案外簡単にできてしまうこともあります。
ですが、工数は楽観的に見積もるべきではありません。
トラブルが発生してもなんとか間に合うくらいの工数見積もりで考えておいたほうがよいでしょう。
「どのくらいでできる？」と聞かれて、いいところを見せたいから「3日でできます！」というのではなくて「5日ほどでできると思いますが、正確な見積もりはのちほどお伝えします。」ときっぱり伝えましょう。
当たり前の話ですが、「3日でできます！」と言ったのに4日かかった場合と、「5日あればできます」と言って4日でできた場合、どちらが心象がよいでしょうか。
今までの経験上、前者は仕事できないやつ、後者は仕事ができる優秀なやつとみなされがちです。
臆することなく確実に到達できるであろう工数見積もりをしましょう。
長期的な対策
あと、この問題の長期的な対策としては、ソフトウェアの仕事の内容をほかの部署の人たちからもわかるように可視化する、というのがあると思います。
もしも他部署の人たちがソフトウェアの仕事内容を理解してくれたら、きっとこれほど組み込みソフトウェアエンジニアにとって幸せなことはないと思います。
僕がここで上げた6個の問題もほとんどが解消されるかもしれません！
他部署の人たちが、組み込みソフトウェアの仕事はプログラムを書くことだけではなく、要求抽出、要件定義、仕様検討、設計、コーディング、デバッグといった一連の流れでできていることを知れば、ちょっとした動作仕様の変更でも工数がけっこうかかるんだ、ということに気づいてくれるかもしれません。
そうすれば前半で上げたような、突然の無茶なスケジュールの要求をすることはなくなることを期待できます。
これは僕にとっても今の課題だと、書いていて気づきました。
いかに組み込みソフトウェアの仕事を見える化できるか、今後取り組んでいくべきことですね。
自分たちが働きやすい環境を作るためなら惜しまず努力します(笑)
ただ、今の所属しているプロジェクトでは、プロジェクトリーダーと電気屋さんの設計リーダーは組み込みソフトウェアの仕事に対してかなり理解してくれています。（十分なレベルではないと感じていますが）
それによって実際、僕はけっこう楽しんで仕事に取り組めているんだと思います。
もしも他部署がまったく理解を示してくれなければ、それは組み込み屋さんにとって大きなストレスの原因となるでしょうね…。
他部署に理解してもらうためにどんな方法が考えられるか、これはいろいろ考えていく必要がありますね。
うちの会社でも「看板」を使った試みをしたことがあります。もう3年くらい前だったと思いますが、とつぜん各プロジェクトの島にホワイトボードが出現して、"ToDo", "Doing", "Done"という文言が3つのセクションの一番上に書かれていました。
いま思うと他部署に対して仕事の見える化をする取り組みだったんだなとわかりますが、当時は突然すぎてしかも何の説明もなかったので、この取り組みは実を結ぶことはありませんでした…。
やるにしてももう少し意義を説明してくれないと…。
ひとまず、今はまだ具体的な取り組みは考えついていませんが、今後見える化の活動を検討していきたいと思います。
そのこともブログに書いていけたらいいなと思います。
今回はここまでにします。
次回、組み込みソフトウェアエンジニアはつらいよ-その3-です。
