====================================================================== 分科会1 セッション S1-4-2 タイトル ：SWEST しゃべり場 時間 ：20:30〜22:30 参加人数 ：11人＋数名 ●形式 ・参加者全員でのディスカッションする ・持ち回りでテーマを決める ・テーマを決めた人がまず話す ・話した人が次に話す人を指名する ・そのテーマで一人ずつ意見を述べる ・一通り回ったら、次にテーマを決める人を指名する ●目的とルール ・相互理解の場を提供する ・話の背景を探る ・結論を出す場ではない ・問いかけ続ける／探求のプロセスである ・正しさや結論を求めない ---------------------------------------------------------------------- １．参加者の自己紹介 話し合いを始める前に、今感じていること、などを各自一言。 言いっぱなしにすること。 コメントしないこと。 ・Aさん 安心して話せる場を提供したい。 ・Bさん どの会場に参加するか迷っていて他会場へも行ったが、ここは少人数で魅力的。 みなで話し合えるのがいい。 ・Cさん SWESTはどんなところか、ということで参加。 この場は自由に話せるので、話したいことを話したい。 ・Dさん 福岡から来た。せっかく参加したので何かを学んでいきたい。 ・Eさん このような場で話すのは初めて。みなからいろいろお話を聞きたい。 ・Fさん 今年は必ず来ると決めていた、来ようと思っていた。 一昨年来たときのような、終わったあとに"皆で飲明かした"ような話し合いがしたい。 ・Gさん ロケットを飛ばすためにSWESTに参加。しかし台風で中止になってしまった。 ・Hさん 前回同様のものに参加したときに自分を丸裸にされるようだった。 が、そのようなのがよくて、今年も参加。 ・Iさん 初めて参加。 ・Jさん 初参加。SoCなどやっている 将来の若者を応援！日本の将来を担ってもらいたい。 本職はデジタルテレビ・組み込みＯＳ。 ・Kさん K社 ロケットに期待していた。組込み業界に関しても興味があり、参加。 初代のマイコン雑誌「アイオー」の編集をされていた。（Jさんからのご紹介） ・Lさん 今年企業に入社したばかり。いろいろな話を聞いて勉強しようと思い来た。 ---------------------------------------------------------------------- ２．テーマ１（by Dさん） 「納期に終われずに、組み込みをするにはどうしたらいいのか」 １０年前までノートＰＣのＢＩＯＳの製作、今は研究者。 １０年前は納期前の徹夜で完了していた。今日、そのスタンスは違うのではないか？ どうしたら納期が守れるか。でも徹夜で納期を守るのは？？？ ・Eさん 今の職場は、物理的に徹夜はないが、夏休み・ＧＷはないような感じ。 身の程を知っていないので、納期に間に合わなくなるのでは。 作業内容や現在の状況、自分（達）の実力を客観的に知った上でやっていけばよい。 要求が来たときに、できないことは断る。 出来ることはどのくらいか、を知る。「我を知る」ことの大切さ。 自分たちの限度をしって、その限度を元にやっていく、というスタンスは いいものか？ 自分の技術の限界を前提とした開発でいいのか？ ・Lさん そもそも納期は誰が決めるのか？真の納期とは何か？ 納期を守らなくていいときと守らなければいけないときとはなにか、どう違うのか？ 開発としての真の納期と、本当に重要な納期の違いを理解・区別するべきである。 必要に応じて品質・機能を削る。しかし、絶対不可欠な機能・最低限の品質に 満たなければ納期を遅らせるべきである。 賢く作るには・・・来てから作る、ではなく、現在たくさんある「部品」を 有効活用すればよいのでは。 徹夜で頑張れば、納期に間に合ってしまうときがある → 出来た、という事実だけが 残る。→ 次も出来るのではないか、という期待が生まれる。 もっと賢く作れば、もっといけるのではないか。 ・Jさん 技術者や経営者など、それぞれ立場によっていろんな意見があるはず。 技術者の出す（工数の）見積もりは甘い。納期は経験則からしか出ない、のではないか。 楽をするための工夫は前向きな発想につながる。ただし、道を逸れ過ぎてもダメ。 前向きなエンジニアであって欲しい。 「プロ意識：決められた時間内に仕事ができる」を（強く）持つことは重要！ プロは「結果」が重要：どれだけ遊んでいても、納期までに完成できればＯＫ！ 「出来なくて残業、でも残業代で給料が多い」のもどうなのか？ ・Lさん 納期に追われることはまだあまりない。 納期に遅れそうな場合は、納期を守るために未完全のまま、納得がいかない状態で出す。 一度納品してしまうと、変えられない。 納期とはなにか・・・「納得できるまで」が納期か？ できれば「納得できないものは出さないで欲しい」。動いてるものは直せない（ことが ある・多い）。 技術者としては納得できなくても、現実がある：納期 ある程度で見切りをつける必要もある。 ・Dさん 納得できないことを、上に報告してはどうか。 一度上司に任せてみる。上司は、納得しながらも現実とぶつかる。 ・Jさん ソフトの肥大化の問題。 Netに接続できる製品はオンラインで修復できる（し得うる）商品によって異なるが・・・ (パッチ当てなどは)ユーザにやらせてはダメ・無理、あるいは商品によりけり。 ただ、それに甘えてはダメ。どこに（製品の品質の）閾値を定めるか、が問題。 現実問題、100％はない。時間をかけてもある程度以上は進捗しない。 最後は上が決めるが、エンジニアには最後までがんばって欲しい。 ・Kさん 出版業界において、納期とはどういうものか、簡単に説明すると次のようである。 納期に関して、新聞は一人では作れない。記事・構成・チェックなど、各役割を各自が 責任もってやることが大事。 調整することも大切。新聞社は社長より編集長が強い。記事をどうするかを決めるのは 編集長。舵取り役の編集長のリーダーシップが問われる。 新聞はデッドリンク：納期は絶対・遅らすことは絶対に出来ない。 しかし、ソフトウェア業界はデッドラインが決まっていない：バグだらけで出すよりは 直してから出したほうがいい。 基本は「納期は待ったナシ！」納期は単純ではない。 納期を考えたとき、（製品の品質を守るためにつける）優先順位がある。 出版においても、記事のトラブルに対して予め原稿を用意しておいて、適度に埋める。 ＜ここでルールの再確認＞ ・Gさん 現在の仕事では納期は特にない。 納期を守るためには「強い意志」が必要だと思っている。 昔は...客が「いつまで」という納期に対し、「それを遵守」するスタイルだった。 今は...そうでもない。納期は自分が決める。それに従ったスケジュールを立てる。 ・Hさん 不具合が報告されると、技術者としての「良心」が痛む。良心と、納期の現実。 ・Iさん 納期は誰が決めるか。「一生懸命の納期」と「ギリギリの納期」 国の予算を決める際、実際の予算より多めに見積もっている。これに見習って、上から の納期の要求に対し、 「できない」という意味も込めて「納期を多めに要求」しては どうか。 エンジニアなどの勉強を含めての納期を要求してはどうか。 ・Aさん はじめから納期は多めに言っておく。自分が勉強したい・楽しみつつやる（遊びながら やる）。でもお客様との約束を守る。 「プロジェクトをどうするか」だけでなく、セカンドライフなどを考慮した「納期」の 提案。 ・Lさん 納期は長めに取る。目先はいいかもしれないが、次の納期はどうなることやら・・・。 目先のことばかり考えていると、ずっと納期に追われ続けるのでは？ ・Bさん 納期はマネージャが決める。 納期までに出来るかどうか、は確率論。 マネージャは顧客に納期を説明する際、「この時点でできる確率は○％である」と伝え るべき。 納期を守るには・・・ 「余裕」の見積もり方・・をどうするか。各タスクマネージャがみんな納期を延ばす → すべてを集約して、全体としての納期はかなり伸びてしまう これでは組織として対策が必要ではないか？ ・Cさん 「納期」は「顧客の要求」 納期は、顧客との約束。 納期を「守る」といった時点で、自分たち（エンジニア）のスケジュールとの約束。 自分の実力を理解したうえでの納期 デマルコの例。「絶対にできる」と約束された製品は、「面白み」あるだろうか？ いい加減な約束か、自分がどうかを理解したうえでの納期 ---------------------------------------------------------------------- ３．テーマ２（by Bさん） 「仕様」が固まってから決まった「納期」か？ 納期を決めるときに、仕様はきまっているか？ 仕様が決まっていない場合、どうやって納期をまもるか その工夫をしているか？ 仕様が決まっていない：極論として「何をやっても（作っても）良い」 仕様の曖昧なところを美味く「着地」させるのは プロジェクトマネージャ ・Aさん そういう（仕様が固まる前の納期が決まった）場合もある。 そういう場合には、自分たちで仕様を決めていく。 できるだけ魅力的な製品を作るために、魅力の優先順位をつけて仕様を決める。 優先順に消化して行き、納期までに出来ないものは諦める。 ・Iさん 客からの要求が、要求というよりも「欲求」にちかいことがある。 実際、中途半端なものができてしまっている場合がある。 ・Hさん 仕様無しでも実際に作ってみると・・・上手くいくとき・行かないとき。 納期を守るのは大切。でも、納期に追われて使えないものを出しても仕方ない。 ・Kさん 仕様の定義とは？：どの程度要求されたら「仕様が決まっている」といえるか？ 仕様は曖昧。だが、「実際のシステム」を顧客に提示できない：作ってみなければ顧客 に提示できるものがない。 仕様はざっくりしたものが決まっている感じ。 客から来るのは「機能仕様」（ならまだ良いほう！） 「なんとなくこんなことがしたい」というレベルでは「仕様」ではない（Cさん） 顧客から提示されるものは「こうしたらこういう結果・応答が欲しい」というレベルの もの。 ・Jさん 仕様を誰が作っても同じ結果が出るような形まで落とし込むか、 いろいろなとり方が取れるような仕様か？ 仕様の定義は奥深い。結論が出ない。 Ｑ、「仕様」がどの程度決まっているかは、会社側の判断か？ Ａ、そうである（Cさん） ・Lさん 「仕様が決まっていないのに仕事はできない」と顧客に言うことはできないか？ 顧客をとるために見切り発車で仕事を受けてしまう、という会社経営としての現実もあ る。 仕様に疑問が生まれたら、顧客との対話・相談をすればいい。 ・Jさん 組み込みは「新しいものをクリエイティブする」という感じ。 組込みは一人のリーダーシップでものづくり：「船頭多くして船山に登る」のことわざ。 Macの例 「Macの創始者は？」と聞けば、だれもが「Ｓ．ジョブス」と答えるが、 ジョブスは実際にMacのコーディングなどしてない。 しかしMacは彼のコンセプトであり、彼がリーダーシップを取ってきた。彼のような存 在が必要。 仕様が決まっているところまでは仕事して、「ここまでしかできません」と割り切る。 ・Jさん 人間には適正がある。 プロ意識をもつことは重要：プロは結果が大事。 コンピュータには、多種多様な職種・専門分野が存在する。人材の適材適所が大切。 リーダーシップが大事だが、リーダーシップの適性がなくてもコーディングが上手な人 もいるかもしれない。 人材の適材適所が大事。 ・Fさん 新しい技術の導入で「これから仕様書を読む」という場合に、納期がわからない・計算 できない。 このようなときは？ ５０％のリスクで 「これをやらないとどうにもならない」ということは必ず消化する。 エンジニアなどのモチベーション・気持ちの持ち方次第で何とかできないか？ 仕様が決まっていないときに、顧客（＆見えないコンシューマ）とのネゴシエートの重 要性。 ・Eさん やっていて、途中で「だめだ」と思う瞬間がある。 でも、それをうまく代替案などでまとめ、頑張る。 ・Dさん ノートPCのBIOSを書いてたとき、当時の仕様は「頭の中にぼんやりとある"何を作れば いいか"」 をもとに作る、という感じだった。 当時のリーダに言われて心に残っていること： −「納期は場合によっては守れなくてもいい。だが、そのときにどのようにすればいい か」 納期が守られなかった場合に、上手く手を打つことが重要である。 逆に、「仕様を守らない・守れないなら納期を延ばしたほうがいい」ということも重要。 どこまで要求を出し切って、要求を客から聞き出せたか？ 納期を守ること：交渉の余地を残しての「納期の設定」か？ 仕様の前に要求がある。顧客からいかに要求を聞き出せているか？ 客からの要求をみたすために、「要求」と「仕様」の見極めと区別の重要性。 何を「仕様」だと考えているか？ 客から受注して、納期を決めている。 客から要求された機能が組み込めないときは、納期をずらす。 上手く納期を決める。 仕様だと思い込んでいたことが、実は本質的でなかった場合、納期をずらす。 ---------------------------------------------------------------------- ４．テーマ３ 「組込みエンジニアをやっていて、楽しいことは何か？」 醍醐味は、「こんなこともあろうかと・・・（宇宙戦艦ヤマト）」の快感： −あらかじめ、（部品を）作っておくことと、それが時として役立ち、活用される・で きることが楽しい。 組込みは、自分が作ったモノが目に見てわかる。子供などに、自分が作ったものを教え られる。 自分の仕事したものがわかる。 組込みの世界に入って、コンピュータの仕組みがより深く理解できた。 ・Jさん 自分が頑張って手がけたものを使ってもらい満足してもらっているのをみて、自分も満 足できること：少し自己満足の世界。 客からの「ありがとう」「感謝」を見る（見れる）こと ウソをつかないこと。コンピュータは正直・やったことに対して、必ず何らかの結果が 現れる。 それを使った人たちが喜んでいるところをみて、ある種の優越感に浸れる。 「どんな商品に化けるか」が楽しみの一つ。 ・Lさん 新入社員で、今組込みが楽しい。人を喜ばせることが好きで、過去に「お笑い芸人」を 目指したかった。 組み込み製品で、人を喜ばせることができて、楽しい。 ・Kさん ITをはじめとした様々な業界を見て、組込みは元気がいい。笑顔があり、楽しそう。 SI企業は暗い。納期や売り上げの不調でぎすぎすしている感じがある。 徹夜はつらいであろうが、組込みにはそれを超える楽しさがあるのではないだろうか。 組込みの楽しさが分かればなぁ、という感想。 ・Hさん 現在Ｙ社所属。音楽が好きで入社。 就職後、テレビで「瀬戸大橋の製作者が記念に橋に記名した」というのを見て、自分も 大きな橋を作りたいと思った。 （瀬戸大橋の製作者が橋に記名した事例のように）、自分も何かを残したい、と思った。 製品を作って、人の心に刻む。組込みに限ったことではないが、そのような仕事がした い。 ・Iさん 音楽は嫌いだが、Ｙ社に入社。 プログラム作るのが好き。 動いたものをみて、思ったとおり動いているのをみるのが好き。 自分が作ったものを誰かが使っているところを見るのがうれしい。 組込みと他業種の違い：実際にモノとして動いているのを見ることができる。 使っている人が満足していることが、自分のエネルギー源。 ・Aさん 若いころ、何かに対して「一番乗り」したかった。 バグを見つけたとき、ドキドキする。バグ探しが楽しかった。 現在、ツールを製作する会社に勤務。お客さんに「これは使える！」といっていただけ るとき。や、「お客さんのブレークスルー」に出くわしたときに感動する。 お客さんが行き詰ってるときに、解決の手助けが出来るときに感動。 他人のバグ取りも楽しいかも。 入社後２年目のとき、OSの使い方がよく解っていなかったときに、先輩が徹夜に付き合 ってくれた。 そのような経験や、自分のバグが見つかったときに楽しかった。 ・Bさん 組込みはやっていないが、プログラミングは楽しい。 プログラムは組んですぐに、結果としてわかる・手に取る事が出きる。それが楽しい。 近頃よくさわっているExcelのマクロなどはBasicだから、おもしろい 自分がやったこ とに対して、すぐに答えが返ってくる。 組込み＆ロボットは、プログラムよりもっと楽しいだろうと思う。−動かない（はず の）モノが動く喜び 組込みでは 論理の世界と直ちにはつながらない。現実のギャップがある。 画面に出るだけではなくてロボットなどでは動作につながる。これは楽しそう。 組込みプログラマになりたい。 ・Cさん 学生のときにプログラムで数値計算させて、面白かった。 数値計算は実行結果として画面に結果を出すだけであったが、 同様にして書くことが出来るプログラムを使って、普通なら動かないハードが動くのが 面白い。 本来動かないものを、ソフトを使って動かす楽しみ。 バグを見つけて、自分の正当性を検証し、自分のバグではないことが照明できたときに 楽しい。 ハードウェアや他人のコードが原因であって、自分は悪くなかったと解ったとき。 ・Bさん 昔、寝ながらデバッグしたことがある。デバッグ風景が夢に出てくる。 夢で原因を突き止め、起きて、それをメモする、という体験。 電車やトイレでふとバグの原因を思い出す。帰り道にふとバグの原因が思いつく。 ・Dさん ソフトとハードどちらにバグがあるかを見つけるのが楽しい。 自分の作ったPCが初めて動作した画面や様子は、PCを作っている自分しか見れない、と いう優越感・うれしさ。 新製品誕生の瞬間に立ち会える喜び。 いままで誰も動かしたことがない（製作段階の）PCで、DOSプロンプトが初めて出る時 のうれしさ。 自分の作った製品を店頭で買ってくれる・選んでくれているのを見て、うれしい。 「自分が作った」と思えるのがいい。 ・Eさん 自分が作ったものに対してシビアに見る・採点するが、それでもいいものができたとき の感動。 仕事をしていて、問題が山ほどある・出てくる。これを改善・対処することが楽しい。 自分が作ったものを自分で使える喜び。 テーマ３について話し合えてよかった。 ---------------------------------------------------------------------- ５．まとめ 「話し合い聞きあったあとの今、思っていることについて・・・」 ・Fさん 最近（というより昔から）ソフトウェアは工業化しなければいけないといわれてきた。 その必要性もあるが みんな関わっているのは職人・職人気質だな、と思った。 ・Jさん 参加者みんなそれぞれ適正がある。職人は大事。頑張ってほしい。 組込みで行っている内容はデジタルであるが、でも結局最後はアナログ。 人間の論理的要素とともに、アナログ的なものも必要であるだろう。 ・Lさん いろいろな意見が聞けて良かった。 他の参加者のような経験ができたらいいな。皆のようになりたい。 ・Kさん ＥＴ２００４で初めてこの業界を知って、ロボット・ロケットに興味を持った。 今日の話し合いでさらにこの業界に興味がわいた。 ・Hさん 現在、仕事でぴんと張り詰めていたものが、仕事が終わるころにトーンダウンする日々。 「仕事は何のためにしているのか」ということを考え込んでしまうことがあり、 今回はそういう時期で、仕事が面白くないと感じていたが、元気をもらった。 ・Iさん ポジショニングペーパに書いたこと、 解決するための方法 工業化などの方法なども考えたが、今回のような話ができたのが よかった。 このような話し合いの場がもっと持てるとよいと思う。 ・Aさん どのような方が参加するだろうと思っていたが、今回のメンバーのような方々が集まっ てよかった。 ・Bさん 少人数の会場がよいと思いこの会場に来たが、みんなで意見を言い合って持ち帰れるも のもあり良かった。 自社内でもこのような場が持てるといいなと思う。 組込みはよい・楽しいと思っているので、ライフワークとしてやりたい。 先日マインドストーム（レゴ社）を購入。自社の中で選抜してサマースクールでのライ ントレーサー競技のようなことをやりたい。 また来たい。 ・Cさん テーマ３のような、自分が思っている「プラスな意見」をみんなで言い合えたのはよか った。 職場で、「みんなのいいところをほめよう」ということを展開。 自分がいいと思っているから・自信を持っているから、話せるのだと思う。 このような場に出れて良かった。 ・Dさん 近頃は組込みから少し離れて、研究的なことをやっていたが、昔のような気持ちが蘇え ってよかった。 ・Eさん テーマ３で、力をもらった。「しゃべり場」はとてもよかった。 ======================================================================