================================ 分科会F2 「組込みソフトウェアの品質向上を目指して 〜第 2 部: 技術 vs 人間(チームワークとやる気と人間関係)」 参加者:30人程度 人数の割には非常に大きな会場であったが,議論に参加しやすい雰囲気を作る ため,長机を四角く配置し,全員が顔を付き合わせる形で席についた. 司会より,前日の分科会B3(技術vsプロセス)のまとめから紹介.本分科会で は,「技術vs人間」ということを中心の議論をする.2名の方によるポジショ ントークから始まった。 ○ポジショントーク 1 10数年,ある大きな組込みシステムの開発をやり,その後,研究所に移った. 現在チームリーダー.人のやらない技術を試行してきた.やりたいことをやる ためには,日頃から他人がやらないことをやっておく.常に第一人者であるこ とが大事.そうすると自分が3日かかると言えば1日で終わる仕事も3 日もらえ る.空いた時間でまた勉強する.メンバーには好きなことをさせる.しかし放っ ておくとそれぞれが勝手な方向に行く恐れがあり,それはまずい.自分が興味 があることを日頃から伝えておくようにして方向付けをする.自主性を尊重す るやり方をとっている. ○ポジショントーク 2 アクティビティが上がるカルチャを研究所に作ろうとした.人のインセンティ ブを上げるのには評価が密接に結びついている.日米の採用システムの違いと インセンティブの違いには関係があると思う.研究所や工場などを問わず平等 な評価システムが必要.仕事に対するモチベーションの維持には,個人の仕事 への興味はもちろん,個人やチームへの評価(出世であったり,ボーナスであっ たり)によるところがあるのではないか? この後,大きく二つの話題について議論が交された. 1) 個人に関する話題 2) チームに関する話題 前半は,どうやって個人が向上心を持つか,またそれをどう結果につなげるか, 向上心の動機は何か,後半は,プロジェクトのモチベーション,成果とマネジ メントや,納期について議論が行われた. 1) 個人に関する話題 まず,現場で感じる人についての問題点について議論が始まった。次のような 意見があった. 「少し先をやりたいと思っている人と思っていない人で活躍の度合いが違うし, 次への取り組み方も違う.自分が面白いと思うことを見つけ,それを回りの人 に明言するようにとアドバイスしている.また,それなりに自分でやっていく 人が少なくなってきている.」 「向上心を持っていても結果が出ない人もいるのではないか? 向上心を持って いるかではなく,結果を出したかで評価されるべきだ.」 「向上心を持っているアクティブなグループとそうでないノンアクティブなグ ループに別れる.前者は,ウチの会社は求めれば与えられるというか,自信を 持って言えば結構やらせてもらえるということが分かってきているポジティブ サイド.そうでないネガティブサイドの人はそれを横で指をくわえて見ている. それではだめで,自分から動かないといけない.」 ここで「アクティブになりたくてもなれないという人がいる」という意見が出 た,この意見に対して次のような意見が出た. 「時間は作ろうと思えば作れるはずだ.休日だってある.」 「自分で自分の首をしめている.技術者はみんなそれなりの価値を持っていて, たとえば会社を辞めて,技術者として市場に価値を問えばそれなりの価値がつ くはず.自分で動こうとしないような人は会社から買い叩かれる.自分で価値 を下げている.」 「向上心を持っている人のほうが不幸だったりする.大企業ではいくらやって も報われなくて辞めて行く.そうなったらその個人としては解決するかもしれ ないが,抜けられた部署,グループとしては不幸.」 この意見に対して「不幸な向上心を持っている人はいるのか?」という質問が 出た.次のような意見があった. 「残業しても終わらないのはその人のせいだと思う.自分は,できないものを やれと言われたら「できない」とはっきり言う.それでもやれと言われたら, 「やるけど間に合わなくても責任は持てない」ということをはっきり言う.た だ,こういうやり方をしていると,結果は残すのだけれど評価は上がらない.」 「できないのにやれと言うのは問題があり,マネージャの責任が大きい.マネー ジャがソフトを知らないから評価されない.マネージャも向上心が必要.」 「時間も向上心もあって,たとえば本をたくさん買ってきて勉強したり努力は するが,なかなか向上しなくて悲しい,ということはある.」 続いて「結局みんなはお金のために働いているのか?」という質問が出た.意 見としては次のようなものがあった. 「少なくても自分がやった分以上は欲しい.正しく評価されれば,出世とか, 自分の周りへの影響力が大きくなっていろいろできるようになる,とかあるが, そういうのとは別にお金での評価が欲しい.」 「今,自分は,好きなようにプロジェクトをデザインできたりとか,いい環境 がある.それは大事.お金や環境などトータルのバランスだ.」 この意見に対して「もちろんバランスがよければいいが,最終的にはどちらを 取る?」という質問が出た。 「自分がやりたいことをやるために,その会社にいるのがいいことかどうか. 志が同じ仲間として会社や周りと仕事ができるかどうか.」 「自分のやりたい仕事があるかどうか.やらされてやるとやっぱり面白くない. その中に面白さを見つけるようにしたい.やりたくないことは,お金をもらえ れば,と割り切る.」 「自分は学生だが,自分の興味ある課題がでたりするとやる気をもって勉強で きる.興味・関心を持てることの方がお金より重要だと思う.」 「自分個人としてはお金は最重要ではない.チームとしてのインセンティブを あげていくためにわかりやすい評価指標としてはやっぱりお金.」 ここで「それぞれの評価制度はうまく機能しているか?」との質問に対して 「ウチは成果主義だが,チームとしての総額が決まっているので,みんな頑張っ ていて全員を増やしてあげたい時はあるが,そうもいかない.相対的な評価に なるしかないから,頑張っていても下がる人もいる.」との意見が出た。 ここから,チームとしての向上というテーマについて議論を行なった. 2) チームに関する話題 まず,どのようなチーム作りが良いのか? という点について、「方向性だけ を示して,後は個人に任せる方法(放任主義)」と「仕事の枠組みを作って仕 事をさせる方法(管理主義)」とが示された.次のような意見が出た. 「やる気のない人は論外として,やる気があって技術力がある人と,やる気は あるが技術力がない人がいる.技術力がある人に管理主義は窮屈.技術力がな い人に放任主義は不安,どこから手をつけてよいか判らない.」 「ある程度まかせること.チームのモチベーションをあげるためにはそれが一 番だと信じている.チーム内で完全にじゃないけど,ある程度は個人個人にま かせる.報告はさせるが口は基本的に出さない.」 「全員ができる人ではない.PSP(Personal Software Process)という考え方 がある.ある程度のそこそこの品質ができる.個々を規格化するという感じ. ただ,ロボット,兵隊を作っているという批判もある.」 「できる人とできない人を分けた考え方として,RUP(Rational Unified Process)がある.例えばアーキテクチャやタスクの割りあて方などを熟練者 がやり,手続き等は各モジュールの担当者に任せる.スキルの低い人には,よ くレビューをさせるようにしている.技術的興味が呼び起こされたりする.」 「個人が能力を発揮できるリーダーの下につけることが肝心.つまり,技術力 がある人は,好き勝手やらせるタイプのリーダーにつける.技術力がない人は, 個人を細かく管理するタイプのリーダーにつける」 この意見に対して「小規模なチームなら,上の方法でよいだろうが,数百人規 模のプロジェクトをうまく管理し,能力を発揮させるためには?」という質問 が出た.大人数でうまくいっている例として,次の意見が出た. 「組織でのプロジェクトの作り方は2つあると思う.一つは枠組みをきちんと作っ てあげるやり方.もう一つは,今いる人を組み合わせて最強のチームにすると いう人ベースの方法.ギリギリまでカスタマイズして,このメンバーだからで きる,というチームを作る.チームの中心にはリーダーシップのある人を据え て,相性が良いメンバーを集めてアクティブに利用する.管理主義のマネージャ には,あまりできない人をつける.そういう人はその方が仕事ができる.」 「マネージャの観点に立つと,人をベースに作戦を立てる.サッカーのよう に,人が変われば作戦が変わって当然.企業は人の集まりだから,人を無視し て仕事はできない.マネジメントを良くすればチームの力は上がる.」 続いて,小さいチームの場合について次のような意見が出た. 「ひいたスケジュールが守れない.頑張ればできるというラインまで到達しな い.毎回だと,そのマネージャが悪いんだろうな... となる.チームメンバー のモラルも低下する.そういうことが重なると,誰も日程を本気にしなくなり, 守ろうと努力しなくなる.あと,日程をだいたい何月とかしか言わない.」 「そういうチームに優秀な人がいても,そのチームは信頼されなくなる.自分が 信頼されていないと感じて,よりモラルが下がる.」 「ひいた日程には意味があるし,遅れたにも何か理由があるはず.原因を分析 しないといけない.スケジュールの理由と遅れの理由が正当か見直さないと.」 「技術的にじゃなく経営的に時間を短縮されることが多い.しかたなく無茶す ると,かえって反動がくる.それでひどい目にあっているチームは真剣に見積 もれるようになってきている.そうでないチームは自分達のスケジュールを信 じてない.やはり最初から自分で時間内にできると思っていないプロジェクト はうまくいかない.」 ここで「デッドラインが先に決まってる場合のマネージャはどうしたらいい?」 という質問が出た.次のような意見があった. 「無謀なデッドライン設定に対して,できないものはできないと言うのがマネー ジャーの務めだ.」 「スケジュールに遅れが発生した時に,人日が足りないからと,さらに人員を 投入すると教育などのために開発が遅れ,さらに事態が悪化する.マネージャー の言い訳になるだけ.「できる限りのことをしました」と報告するためには, 人員増強くらいしかできることがないから.」 「延びない場合,デッドラインには暫定版を出荷し,後で修正する.」 「意思の統一と慎重な見積もりの2つが重要.技術はみんなすごいのに戦略が まったくない.初歩のことができてない.」 「技術としてできることと仕事としてできることは別に考えないと.」 「お客さん−営業−管理者−技術者で,言いたいことが伝わらない.営業は技 術の言うことを聞かないのが現実.」 「営業は営業で,ここでお客さんの無理を聞かないと,という場面もあるし, それぞれの立場がある.組込みの場合は,ソフトは不遇.「士農工商,メカ, エレ,ソフト」というくらい立場が低い.」 「同じ企業の中でソフト開発者と営業で対立している場合じゃない.企業とし てのチームワークを考えるべきで,それを理解しないのはソフト開発者の幼稚 さだと思う。どうしても納期について無理を言われたら,できないとはっきり 言うべきだが,最終的には聞くしかない.その場合は,こっそり実現可能な計 画を立ててやるしかない.そこはソフト技術者のプライドをかけて守るべき. 中間のマネージャは上からの無茶を下に丸投げしては絶対にだめ.下のモチベー ションをうまく保ってやらないと.」 「単にできないと言うだけではなくこれなら出きるを示すことが重要.」 最後に「うまくいくチームのコツは?」という質問に対して,以下の意見が出 た. 「ある部署ではソフト屋もオシロスコープを見るし,ハード屋もテストプログ ラムを書いていた.別の部署では,お互いをまったく信じていなかった.」 「ソフト屋が生まれる前はハード屋が全部やっていた.だんだんソフト屋が新 人として入ってくる.指示はハード屋が出すから良い関係.世代交代が行なわ れるうちにうまくいかなくなる.」 「メンバーは同じでも組織が変わってしまいうまくいかないこともある.同じ プロジェクトに属するデバイス屋,ソフト屋,LSI屋,電気屋などが同じパー ティションにいた時は風通し・見通しがよかった.自分の専門外で判らないと ころは,隣の席にいる専門家にすぐに聞けるので開発しやすかった.別フロア に分けてチームではなくソフト屋はソフト屋で集まるようになった途端にうま くいかなくなった.ほんのちょっとした打ち合わせが,それぞれのマネージャ が出てきたりして大げさになる.ハードとソフトが一体になって作る実感はな くなった.」 「指示系統が1つである方が下はやりやすい」 まとめとしては,個人については「やりたいことを見つける.向上心を持つ」. チーム力の話では「マネジメントの果たす役割は想像以上に大きい」.来年は 組込みに特化したいいプロジェクトの組み方など,組込み特有の部分を議論し てみたい.という総意で幕を閉じた.