組み込みソフト開発において

機器の組み込みソフト開発についてです。
部署に９人のメンバーがいます。
1テーマというか、１つの制御ソフトを一人で請け負って行います。
ここでいう機器は、白物家電(冷蔵庫,洗濯機など)レベルです。
ルネサスのマイコンでいえば、M16CやR8C。
　Ｃ言語で開発しています。

それで質問したい内容は、ソフトの作り方です。
例えば、誰かが緊急入院したり、退社した場合、
その人の仕事を別の人が引き継ぐことになります。
各個人のソフトの作り方が各々違うため、他人が作ったソフトを見ても、
どういう構成になっているか分からなく、引き継ぎにかなりの労力と時間を費やします。

制御変更の依頼を受けても、何処のどの部分をどのように変更すればよいのか分からない。
といった感じです。

ソフトの作り方をみんなで議論して統一すれば良いかもしれません。
しかし、それにはおおきな壁があります。
例えば、先輩の人は今までのやり方を変えられたくないので、
自分のやり方を正論化するでしょう。
逆に若い人(初心者)は、違うやり方をされると分からなくなるでしょう。
つまり、損をする人と得をする人が表れます。

皆さんの会社ではどのように工夫されているのでしょうか？
差支えなければ教えてください。
よろしくお願いします。

No.3 ベストアンサー 回答者： AsanoNagi 回答日時： 2011/03/04 11:16

こういうときには、「損をする人がいないように（不満を感じる人がいないように）」という方針だと何も進みません。

業務全体でどう最適化できるかという観点から考えましょう。

「開発管理」というカテゴリを勉強するのはいい方法です。
その前にというなら、先輩の作業効率が平均以上なら、まずは、それをお手本にするもいい方法です。
その際、先輩に先生役をお願いして、若い人たちに教えてもらいましょう。

また、「制御変更の依頼を受けても、何処のどの部分をどのように変更すればよいのか分からない」というために、実際の変更に入る前、どの程度の時間が無駄になっているかは計測すべきです。
そして、時間がかかっている案件、スムーズに進んだ案件を集計します。

その時間を計測すると、

・この人は、どんな案件でもスムーズに改造してしまう
・この人の書いたシステムは、どの人でもスムーズに改造できる

というケースが見つかるかもしれません。
そうすれば、

スムーズに改造してしまうひとは、ソースを読むノウハウを知っている人ですし、スムーズに改造*される*ソースを書いた人は、ソースが読みやすい人です。

そうすれば、どの人のスタイルをまずお手本にすればいいかがわかりますし、「そうすれば、これだけ時間短縮ができる」というのは、動機付けにはいいと思います。

この回答へのお礼

回答ありがとうございます。

「スムーズに改造*される*ソースを書いた人は、ソースが読みやすい人です。」

なるほど、こういう考え方も　ありですね。
参考になりました。

お礼日時：2011/03/04 22:34

No.2 回答者： higeG 回答日時： 2011/03/04 08:13

失礼かもしれませんが、御社はCMMIで言うところのレベル1に当たると思われます。

組込み系で言えば、IPAのETSSなどをお手本にされては如何でしょうか。
うちも中小ですが、大手さんとお付き合いする上で一般的な方法論は必要と思っています。
職人的な先輩がいる場合は、標準化するのにかなり苦労するかと思いますが、頑張って下さい。

この回答へのお礼

回答ありがとうございます。
察していただいた通り、職人的な先輩がいなければ話は早いです。

例えば、Ｃ言語は複数の書き方ができます。
初心者でもわかるような教科書的な書き方をしてくれればよいが、
職人的な先輩は上級者的な書き方をします。
この文法はどういう意味なのかを聞くと「本を読んで勉強して」と
一方的に言ってきます。会話になりません。
私は、上級者的な書き方をしなくても、初心者的で教科書的な書き方で、
間違いなくバグがなく出来ればそれでいいと思います。

IPAのETSSですね、ちょっと見てみます。
ありがとうございます。

お礼日時：2011/03/04 22:28

No.1 回答者： ICE_FALCON 回答日時： 2011/03/03 23:37

Ｃ言語でもオブジェクト指向っぽく開発できるような

プラットフォームを作るっていうのが、よく行われているのでは？

あとはシステム仕様書、テスト仕様書を開発前に作ってレビューですね。

この回答へのお礼

回答ありがとうございます。

お礼日時：2011/03/04 22:34