前回技術者の話が出たので、プロジェクトチームの方に触れたいと思います。私が経験した中でも最も優れたチームは半事業部、半研究所の文化をもつところでした。元は研究所だったのが事業にも手を染めたという形だったのですが、ここに配属される人はトップクラスの人材です。個々人のスキルが高く、何を言わなくても、勝手に自分でテーマを決めて調べるといった文化がありました。私自身は関連会社の人間だったのですが、このプロジェクトチームに応援という形で加わることで私自身も変わりました。この事業所は次々と優秀な若手が配属され、中堅になると他部署へ移されるといった人材育成所みたいな面もありました(^^!。設計の正攻法というものはここで学びました。このようなチームはほぼ無敵ですね。。このチームが競争相手だったら、まず、勝てないなと思いました。しかし、これは大手でかつ資金が無いと、このようなチームを作るのは不可能です。関連会社などではこのようなチームを作ること自体無理です。自前の研究所を持つくらいの規模があれば話は変わりますが。。
で関連会社でのチームでどうだったのかというと。。幸いにも私は別の関連会社のチームと共同で仕事をする機会に恵まれました。仕事を請け負うというのは、分野を特定すると不利な訳です。例えば映像システムのＬＳＩのこの機能の”ＲＴＬ設計をやります”という話で営業するよりも、ＬＳＩのこの機能の”フロントエンド・バックエンドまで面倒見ます”の方が客受けが良いです。実際そういう仕事のとり方が出来るチームだったのですが、意外にもメンバーは１０人程度でした。このチームには他の関連会社（私が知る範囲ですが(^^!）で見られない特徴を持っていました。それはメンバーの全員がフロントエンドからバックエンドまで何でも出来るという事でした。メンバーはそれぞれ得意な分野があるのですが、他のところへも応援に入れるだけのスキル持っているのです。バックエンドの主担当の方が、ＳＷを書いてデバッグしたり、ＲＴＬの検証を手伝ったり、ＳＷ担当がＲＴＬを書いたりなどです。客からの問い合わせが来たときに主担当の方が不在でも、別の担当の方が分かる範囲で（といいながらほぼ主担当と同じレベルの）回答したりしてました。なのでメンバーが遊兵化せず、大きな仕事も無駄なくこなす事が出来たわけです。私はいずれ自分の会社に戻される時があり、そうなったときには、このチームとビジネスを参考にしようと思いました。これなら大手でなくても出来そうだと当時は思ったのです。"メンバー全員が何でも屋さん"チームですね。
後年自分の会社に戻されたときにチームの構築から始めましたが、文化が大きく違ってましたね。リソースが二極化、専門化してました。リソースは優秀かそれ以外に分かれており、優秀な人材はヒモがついておりまず回って来ないです。その時に手が空いているリソースが回ってくる訳ですが、大体問題児との評価まで付いて来るのです。私自身が感じたのは、これらのリソースは光る原石を持っていたりするのですが、その会社の文化の中で長年芽を出さなかったので、すっかり原石の覆いが固くなってしまった感じですね。Ｃ言語をやった事がないとの事で勉強しといて下さいとお願いしたら、”テーマが必要です”と言われた時は”えっ！！ここからか？”と思ったものです。これがverilog言語やsystem verilog言語など難易度の高い言語なら話が分かりますが。それまで他社の色々なチームを回りましたが、どこも簡単な言語なら自分で学習してしまいます。新しい言語を始めるには、”習うより慣れろ”が基本です。それは自発的にやるものなのですが、そういう文化が無く勉強の仕方を知らないところでした。
又専門化ですが、作業担当が厚い壁をつくる文化もあり、ある日、担当者が長期の休みに入ったので代わりに回答したら、その担当者に休み明け怒られました(^^!。
結局”メンバー全員が何でも屋さんチーム”構想は諦めました。その時に初めて気づきました。私が参考としているチームは普段から自発的に勉強する文化を持っていた事をです。強いチームには、このような文化の裏づけがあるものです。リソースの素質はあまり変わらないと思うのですが、文化がその行く末を分けてしまうのです。
別の解もあります。辞める前に偶然そのような形になったのですが。優秀な外注を雇うことです。実際今はこの方法が主流のような気がします。
ところで後日、辞める少し前ですが、いくつかの客先に営業に行った時、私が参考としたチームにほとんど仕事を取られていました。しかも単価はこちらの1.5倍の値段です。私自身が発注する側だったら、残念な事にやっぱり同じ判断をします(^^!。
（2012/12/9 記）
元
RTL
検証技術者
が
考える
あ
れ
こ
れ
プロジェクトチームについて
サイト内検索
カスタム検索
