分科会1 セッションS1-4-1 『組み込み百物語 最近の行進 -です ver.- 』 日時：2006/07/13 20:30〜22:30 -------概要------- 参加者に自分の体験を話してもらって、みんなで議論。 自分が仕事でやったことなどを一般化、あるいは、仕事で困っている・大変な目にあっていることについて。 こういうことをやった時は上手くいかなかった・最初にこういうことをやらなかったから上手くいかなかったなど、みんなで共有。 -------議論------- ＊製品の全体図について A氏：ハードウェアを作るうえで、自分たちで作ろうとしているものと、相手が作ろうとしているもので食い違っている。 B氏：目的が食い違っている？ A氏：ずれたことで、スリあわせで時間を取られている。ソフト・ハードの問題だけではなく。 B氏：ソフトウェアを万能に考えている面もある。 A氏：お互い理解しあうのは大変。みんなが全部知っていればいいが、お互いのことを教えあうのは大変。ソフトの次元の方が複雑性が高い。状態数の面で言えば、ソフトの方が数字が大きい。 B氏：ハードがあってソフトがそろえる。ハードの側からすれば、ソフトが出来てこないと、どうしてできてない？と言う話になる。予算的な問題がある。ソフトは実体がない。 A氏：本当はハードでやれば簡単なものもある。お互いに相手を理解しないといけない。モデル・ドリブン・デベロップメントは、全然役に立たないと思っていたけど、勉強すると役に立つ部分があるのかもしれない。ソフトウェア屋さんとハードウェア屋さんの考え方が違う。もっとみんなが勉強しなくてはならない。 A氏：ソフトでやっていることのうち、ハードでやったいいこともあり、逆もある。ケースバイケース。みんなソフトウェアがやることは考えているが、逆はやっていないから、随分アンバランスだ。 C氏：ソフトウェア屋さんは分かりやすさを追求。ハードウェア屋さんは今あるものを追求。出来るだけ最小のコストで実現しようとする。 A氏：ハードとソフトの間にすごい深い溝がある。マニュアルにの書き方にも距離がある。ハードとソフトの適材適所が出来てるものとできてないものの差が大きくなっている。大げさに言えば、将来に不安を感じる。学校で教えると言う話があったが、色々難しい。組込みは雑学の塊と言う部分があって、色々経験してみないとわからない。ソフトで言うと、浮動小数点型があると誤差が出ると言うことは、マニュアルに書いてあるものもあるが、経験からじゃないとわからない場合もある。スタックがないプロセッサとはGOTOしかない。構造化プログラミングしか知らない人は使ったことがないかもしれない。スタックがないと、どこから呼んだかわからない。呼んだ順番で覚えるもの。C氏の場合、スタックがあるだけ使う。ちゃんと保護があるOSの場合、使いきった場合に保護してもらえるが、組込みの場合、他のメモリを上書きしてしまう。アドレスマッピングがどうなっているかはOSの中身を見ないとわからない。あるスタックが溢れると、他のスタックを壊してしまうが、これを知らないと大変なことになる。スタックが1番深いところまでいって、割り込みがかかった時にバグを出す。 A氏：大したことじゃないけれど、大事なことを共有したい。組込みシステムの制御は、すごく責任が重い。 ------ D氏：自分の開発しているものが、失敗した時に、これぐらいの損害が出ると脅されたことがあるか?私自身の経験にもあり、何か物を持ち上げる制御のソフトを作ったことがあるが、持ち上げるところの軸が壊れるといくら、落とすといくら、と言われたことがあるが、みんなはそういう経験があるか？若い人にとってはそういう経験がないのでは？ E氏：フラッシュロムを載せてる場合、ファームウェアに載せる。外部の使用がバラバラで、内部もマクロの使用によって制御がバラバラ。失敗したらデバイスがだめになる。 A氏：フラッシュロムを焼く専用のマイコンをつけるのが1番楽。固定のロムかマクスを使って。 E氏：物はデバイスだが、作りはソフト。自分たちのやっている仕事のコストを知ると言うの大事なこと。お金に関わらず、人命がかかると言われる。量産ものが大変。バーチャルな部分で仕事をしてしまう部分があるので、たまに生々しい話を聞くことはいいこと。 A氏：個人に工場で頼んで作れるサービスがある。基盤は作って失敗すればごみ。個人で作れると言っても安くない。個人で5万と言うと考える。2〜3日やってみてオーダーを出す。 D氏：ハードウェア屋さんは具体的な形のあるものを意識している。ソフトウェア開発だとそういう感覚がつきにくい。自分のプログ ラムがいかに恐ろしいことをやっているか知ることがある。 A氏：ソフトウェアの場合、何かの拍子にだめになると言う可能性がいつでもある。みんながちゃんと上手くいって初めて結果が出る。それがダメだと同じことをやっても結果が違う。 D氏：ハード屋さんは、リアルに接しているが、ソフトウェアも制御系はリアル。ハードと密接した環境で開発している場合、ソフトと言えども、バーチャルじゃない。 ------ F氏：ハードウェアを専門にやってきた人と、ソフトウェアにやってきた人とで対立はある？ A氏：上手くお互いにやっていける場合にはいい。相手のものが上手く動かない場合、自分がその中身を見ないといけない。お互いどういう背景で動いているかわからないと、対立意識を持つ。お互い暗黙の知識が、分からないことがある。複雑なものはしょうがないが、当たり前のものとして省略されているものがある。 A氏：ソフトウェア屋さんの手助けが出来ないと思ったのは、CPUをスリープモードにして寝せておくモードがあるが、そのときにメモリの内容が化ける。それを確認するコードを書けとハードウェア屋さんに言うのは無理。 G氏：ハードウェア屋さんは、ドライバの簡単なところを書いて、ソフトウェア屋さんがそれを組み込みのがいい。 A氏：割り込みが絡んで来ると面倒。CPUのマニュアルを読んでみると、CPUごとに随分違う。割り込みハンドラからアクセスできないことがある。特定のプログラムでそれを使う場合がある。 G氏：具体的な部品名⇒値段。その瞬間、現実を見る。マスクを投げ出すといくらかかる、とか、いつまでかかるとか、具体的な数字が出てくる。ハードウェア屋さんがチップ抵抗を減らす努力をしているのに、ソフトウェア屋さんがメモリを増やせと言うと、ひずみが出来る。 A氏：お互いもう1歩ずつ踏み込んでいかないと、今後関係が悪くなる。 G氏：お互い情報が伝わっていないから、作業効率が悪くなる。全体として問題意識はある。組織間で意思の疎通が出来てない。双方のことが分かっていて、全体のことが分かってないといけない。お互いのしんどいところを見る。ちゃんと動いてるプロジェクトは、両者の中間的な立場の人がいる。それは、危機感を持った人がやる。 A氏：それはまずい。みんなQOSの感覚が麻痺してきている。 H氏：某社はハードとソフトの舞台がちゃんと侍従関係がある。ハードに不具合があっても、ソフトで解決。完全に分かれているので、トラブルは基本的にはないが、最近の状況を見ると、ソフトの方が占める工数が大きくなってきているので、ソフトを作りやすいハードを設計することが重要になってきている。主軸がソフトに寄ってきた。 G氏：ハードウェア屋さんとソフトウェア屋さんの違いは、ハードは細かな部品とマテリアルベースの発想である点。視点がどんどんPCの中に入って行ってる。一方、ソフトウェア屋さんの視野は、規模が大きくなるとPCの外に出て行ってる。サービスから始めていかないといけない。アプリケーションはお客さんの要求から分析を進めていく。分析をちゃんとしないと、デスマーチに陥る。それが出来てないのが、ハードの方が多かった。組織的に未成熟だったこともあるかもしれない。大元のよりどころになるところが、明確に答えられる人がいないといけない。デスマーチのほとんどがマネージメントに問題がある。現場にいる人は現状が見えない。 A氏：マネージメントとプログラミングを一人が同時にやると失敗する。他の人と確認していかないといけない。 G氏：成功しているプロジェクトは、技術に長けている人とそれをサポートする人が二人三脚している。技術だけで行こうとすると難しい。それを実現するためにサポートする人が必要。 H氏：ソフト・ハードの溝じゃなくて、色んな立場の人がそれぞれ特定分野のプロフェッショナルになって、その間に壁ができている。ハードとソフトの隙間を埋めるために、お互いオーバーラップするようにしていくようにすると良い。プロフェッショナルじゃないけど、お互いちょっとは分かる、と言う部分を作るべき。当然・暗黙と言う言葉が、お互い上手くいかなかった原因。分からないところはお互いコミュニケーションを取って埋めあう。隙間は黙っていても埋まらないし、お互いやりたがらない。文書としてかけないのか？ A氏：まず動くものを作る。動く状態に変える。と言う人がいる一方で、とにかく大きいものを考えていく人もいる。チームで開発していく中で1番問題になるところ。 G氏：チームでやる時も目標がある。コミュニケーションを取って、共有物を作ることができていない。暗黙の了解ほど危険なものはない。1つのプリミティブな定義が出来ているか。同じ用語でも、立場によって意味が異なる。OSの世界でも優先度と言う言葉の意味が違う。同じだと思って話をしていると全然話がかみ合わない。 C氏：自主的に、と言う言葉は1番危険。 G氏：お互いの領域を定義出来る人がいないと、お互い主張するだけで終わってしまう。全ての判断をする人が必要。 A氏：できれば組織として、プロセス的に上手くいかないかと言う希望がある。プロジェクトを上手くいかせるには、人を育てる。 I氏：ハード屋さんとソフト屋さんが共同で作業をすることはあまりないのでは？ G氏：デバイスを触らない限り、単独で作業をすることが増える。 J氏：世代間のギャップを感じる。経験してるものが全然違う。どういう情報共有をして、ギャップを埋めていくのか？ G氏：自分の成長と業界の成長が同じだった。最初から出来ているものを与えられた人にとっては分からない。 K氏：最近の人は物を触っていない。教育をするにも、初歩から始めないといけない。 ------ L氏：技術研修でやる内容は、すごい基礎を飛ばしてやっている印象がある。何ヵ月後かに期待、あとは成長してくれると言う状況。基礎は自分でやってくれと言うのをすごく感じる。全然やったことない人は、すごい混乱しているのが分かる。新人教育は、いきなり立派なものを目指す必要はない。いきなりそれにぶち当たると、社会人としても挫折してしまいそう。 G氏：技術研修はある程度の前提を持っている。そこに差があるが、誰か1〜2人できる人がいればどうにかなると思っていた。やらなきゃいけないことをやれないまま社会に出るのはどうか。 A氏：世間一般のテクノロジーに対する認識とそれを作り上げるまでのこと。 G氏：企業はかなり大きなことを期待している。 I氏：作ることが面白いと思う人が少ない。 G氏：個人差が大きくなりすぎている。教育の仕方が悪い。 A氏：やってる対象に興味があれば、モチベーションが上がってどんどんやる。 G氏：モチベーションをいかに持続させるか、と言うことをやらないといけない。 A氏：割と早い時期から興味を持って自分で色々試していくこと。 G氏：工学部はエンジニア養成のはずなのに、それに興味が持てないのは問題。ソフトにしても、作るものと買ってくるもの、と言う意識の違いがある。 G氏：自分で作る人が少ないと言うことは、この先産業を支える人が少ない。と言うこと。5〜10年した時、国内にエンジニアの数が確保できないかもしれない。アウトソーシングした結果、よく見ると貢献者が育っていない。ソフトは誰でもできると言う誤解がある。大事なシステム設計が出来ない。 A氏：システム全体を一通り出来ないとできない。 G氏：経験させると言うのは1つの例。今扱っている製品が大きくなりすぎて、一人では作れなくなってしまっている。 A氏：博物館で、メカニカルなものより、映像資料が増えている。動いているものを見ないとダメ。 G氏：小さい時の『楽しい』という経験が大事。 C氏：いかに技術を見につけさえるか。小さい頃からやってないとダメなのか?小さい頃からやってない人が興味を持つためには、と言うアプローチをしていかないといけない。こういう教え方をしてもらったやる気になる、と言う方法は? M氏：目標を決めてもらって、どういうことをしないといけないと決められたら、それに向けて頑張れる。要求だけ言ってもらったらあとは自分でやれる。 C氏：目標が欲しい？ M氏：自分がモチベーションを保つために。 J氏：制約を用いて、それを乗り越えるものを作ると言うのも1つのモチベーション。 G氏：何がしたいか?と言うことを自問させる。 A氏：そういうところに帰着している例として、HAMANA-3やSSESTがある。みんなで問題を共有できた。 G氏：今後の討論のネタになればよい。