ﾃｽﾀｰは一般的にはあまりいないのでしょうか？一般的には
･ﾃｽﾀｰは開発ﾌﾟﾛｾｽにもよるが，必要な時期と必要でない時期に大きく分かれる．このため，会社によっていたりいなかったり，常勤だったり非常勤だったりは分かれる
(･開発者自身によるﾃｽﾄは欠陥を見逃しである
･｢ﾃｽﾄ駆動開発｣はﾌﾟﾛｸﾞﾗﾐﾝｸﾞをｽﾑｰｽﾞに進めるためにうまくいく基準を用意するもので，ﾊﾞｸﾞを見つけ出すものではない)私の理解が甘いままで回答してしまいました．下の議論には関係ないため撤回します．
ということがいえます．
あくまで私の経験ですが，臨時でﾃｽﾀｰをやったことがあります．
その時は途中からﾊﾞｸﾞも見つからなくなってきて，他の仕事も兼業し始めたのでﾘﾘｰｽ前に抜け，｢大したことできなかったな…｣と思いましたが，そこそこのﾋｯﾄ商品になりました．
ところが，次の製品のﾘﾘｰｽの際に臨時のﾃｽﾀｰが見つからず，私も正社員になっていたので手伝えずという感じで開発者のﾃｽﾄのみでﾘﾘｰｽしたところ，重大な不具合が見つかってﾘｺｰﾙになってしまいました．
この経験で，ﾃｽﾀｰがそこまで貢献していないように見えて必要だということを思い知りました．
また，最終的にﾃｽﾀｰによってﾃｽﾄされるということを考慮すると，製品を作る際や企画するさいにも役立つと思います．
もちろん，ずっとﾃｽﾀｰをやるというのはなかなか難しいのですが，少なくともその経験は有意義だと私は思います．
日本における｢ﾃｽﾀｰ｣なんて､たとえばGoogleにおける｢ﾌﾟﾛのﾃｽﾄ技術者｣とは全くの別物｡平たく言えば出来の悪い｢紛い物｣なことがほとんど｡
だから日本は遅れてるんだとは言いたくはないけどね｡
ﾃｽﾄと言っても様々なんだけど､日本企業は色んな意味で40年ほど遅れてるから｡
http://jasst.jp/
JaSSTｿﾌﾄｳｪｱﾃｽﾄｼﾝﾎﾟｼﾞｳﾑ
各地で開催されているので､近くであればいってみるといいですよ｡
http://wacate.jp/
若手ｴﾝｼﾞﾆｱ向けﾜｰｸｼｮｯﾌﾟWACATE というﾃｽﾄの勉強会もあるので参加可能であれば参加してみると勉強になると思います｡
JSTQB認定ﾃｽﾄ技術者資格
http://jstqb.jp/
という世界的な資格もあるのでとってみてはどうでしょうか｡勉強用の資料もｻｲﾄで交換されているので参考になると思います｡(用語集見るだけでも役に立つかも知れません｡用語など社内の方言が多いですから､他社の人と話す時困ることがあります)
JSTQB 運営委員会 委員長 西 康晴先生のTwitterをﾌｫﾛｰするだけで色々参考になるかも知れません｡
https://twitter.com/yasuharunishi
▽4
●
匿名回答3号 ﾍﾞｽﾄｱﾝｻｰ |
>ﾃｽﾀｰは一般的にはあまりいないのでしょうか？
たくさんいますよ｡
ｿﾌﾄｳｪｱの開発規模が小さかったり昔はﾌﾟﾛｸﾞﾗﾏがﾃｽﾄも行っていましたが
だんだんｿﾌﾄ開発の規模が大きくなり､開発と評価を分業で行うようになっています｡
その場合､評価はｿﾌﾄｳｪｱ開発の中から評価ﾁｰﾑが分かれる場合や､品質保証で評価ﾁｰﾑを持つ場合や
評価を社外に外注したり､第三者検証を委託したりとさまざまです｡
某S社の携帯開発に参加した時は1ﾌﾛｱ全体がﾃｽﾄﾁｰﾑでﾃｽﾀｰの人だけで50人以上いました｡
ｿﾌﾄｳｪｱﾃｽﾄを専門に行う会社もありますし､ﾃｽﾄを専門で行うﾃｽﾄ技術者の方もおられます｡
少し前からﾃｽﾀｰをしています｡
今の環境しか経験がなく一般的なことがよくわからないので聞きたいのですが
>･ﾃｽﾀｰはﾁｰﾑまたは会社に1人はいるものなのでしょうか？(検索しても古い記事が多いので)
すごく小規模な開発案件(ﾌﾟﾛｸﾞﾗﾏが1人?数名)であればﾌﾟﾛｸﾞﾗﾏがﾃｽﾄも手分けして行うということもありますが､
ある程度の規模になると専任でﾃｽﾄﾁｰﾑが作られます｡
>･ﾃｽﾀｰがいない場合は､ﾌﾟﾛｸﾞﾗﾏがﾃｽﾄをしてそれがﾘﾘｰｽになるということでしょうか？
ﾃｽﾄと言っても大きくわけてﾃﾞﾊﾞｯｸﾞと評価があると思います｡
開発者自身が動作を確認してﾊﾞｸﾞをつぶしていくのがﾃﾞﾊﾞｯｸﾞで､仕様を満たすよう動作を確認した後
ﾊﾞｰｼﾞｮﾝをつけ社内ﾘﾘｰｽします｡
そのﾊﾞｰｼﾞｮﾝに対しﾃｽﾄｹｰｽを用いてﾃｽﾄﾁｰﾑがﾃｽﾄを行うのが評価になります｡評価を行い仕様通りに動くことを確認してｴﾋﾞﾃﾞﾝｽ(評価結果)を記録して社外へのﾘﾘｰｽとなります｡
評価結果は最終的には検査成績書として成果物になり客先に納品されます｡
仕様書を元に開発者は単体検査仕様書､結合試験仕様書､総合試験仕様書､･･･を作成し動作の確認を行った後
ｿﾌﾄをﾘﾘｰｽし､
評価ﾁｰﾑは評価ﾁｰﾑで仕様書を元にﾃｽﾄ観点からﾃｽﾄｹｰｽを作成し仕様通り動いているか評価を行います｡
開発者と評価ﾁｰﾑでやっていることは同じに見えますが､役割は違います｡
(評価ﾁｰﾑによってはあまりに不具合が多い場合は｢評価に値せず｣ということで評価をやめることもあります｡
ﾊﾞｸﾞ出しと評価は違うのです)
＞正直ﾃｽﾀｰの仕事はあまり好きではなく､なくせるものならなくしたいです｡
無くならないと思いますし､開発とはまた違う色々なｽｷﾙが必要になるので
勉強してみてはどうでしょうか｡
例えば､以下で知らない言葉があればﾈｯﾄで検索してみて下さい｡
同値分割法
境界値ﾃｽﾄ
異常値･特異値分析
ﾄﾞﾒｲﾝ分析ﾃｽﾄ
機能ﾘｽﾄに基づく単機能確認ﾃｽﾄ
制御ﾊﾟｽﾃｽﾄ
制御ﾌﾛｰﾃｽﾄ
ﾃﾞｰﾀﾌﾛｰﾃｽﾄ
ｶﾊﾞﾚｯｼﾞ
ﾓﾃﾞﾙﾁｪｯｷﾝｸﾞ
ﾃﾞｼｼﾞｮﾝﾃｰﾌﾞﾙ
原因結果ｸﾞﾗﾌ
CFD技法(Cause Flow Diagram)
直交表
HAYST法
AllPair法
k-way
状態遷移ﾃｽﾄ
ﾀｲﾐﾝｸﾞﾃｽﾄ
ﾕｰｽｹｰｽﾃｽﾄ
例外ﾕｰｽｹｰｽ
ｼﾅﾘｵ
業務ﾌﾛｰ
ﾘｽｸﾍﾞｰｽ
ｻﾝﾌﾟﾘﾝｸﾞﾃｽﾄ
ﾗﾝﾀﾞﾑﾃｽﾄ
探針ﾃｽﾄ
ﾕｰｻﾞｽﾄｰﾘｰﾃｽﾄ
欠陥仮説法
ﾌｧｽﾞﾃｽﾄ
探索的ﾃｽﾄ
ｴﾗｰ推測
信頼度成長曲線
ｽﾓｰｸﾃｽﾄ
ｽﾗﾑﾀﾞﾝｸﾃｽﾄ
Wﾓﾃﾞﾙ
ｱﾄﾞﾎｯｸﾃｽﾄ
ﾓﾝｷｰﾃｽﾄ
全数ﾃｽﾄ
>それかﾃｽﾄ駆動型開発はﾌﾞﾗｯｸﾎﾞｯｸｽﾃｽﾄは必要ないのでしょうか？
ﾃｽﾄ駆動型開発は開発手法であって､ﾃﾞﾊﾞｯｸﾞの中では有効ですが､評価は必要です｡そのためﾃｽﾄ駆動開発であってもﾌﾞﾗｯｸﾎﾞｯｸｽﾃｽﾄは(評価として)必要になります｡
ﾃｽﾄ駆動型開発の場合､ｿｰｽを組んだ後､ﾃｽﾄｹｰｽを組むより､ﾃｽﾄｹｰｽを組んだ後､それがﾊﾟｽするようにｺｰﾄﾞを組んだほうがﾌﾟﾛｸﾞﾗﾏのﾓﾁﾍﾞｰｼｮﾝが上がるというのが主な利点です｡
他に､最初に仕様に基づきﾃｽﾄｹｰｽを組むときに仕様ﾚﾍﾞﾙのﾊﾞｸﾞに気が付くとか､設計段階前での構造上の問題に早く気が付くとか､常にﾃｽﾄｹｰｽが存在するためﾘﾌｧｸﾀﾘﾝｸﾞが行いやすいとか､ｿｰｽ変更に対するﾃﾞｸﾞﾚが見つかりやすいとか､CIでﾃｽﾄ自動化できるとか色々利点はありますが､あくまでもｿﾌﾄ開発上の利点です｡
製品ﾚﾍﾞﾙでの評価は仕様を満たしてTDDなどのﾃﾞﾊﾞｯｸﾞが終わってﾊﾞｰｼﾞｮﾝがついて社内ﾘﾘｰｽされてから始まります｡
ﾃｽﾄ駆動型開発だから評価は不要ということはないですね｡TDDは内部仕様に基づいて行うのでﾎﾜｲﾄﾎﾞｯｸｽﾃｽﾄにあたりますが､仕様から導かれるﾌﾞﾗｯｸﾎﾞｯｸｽﾃｽﾄも当然必要です｡
仕様の勘違い･解釈違いというのは良くある話で､開発者以外の人が製品仕様を元に検査を行うﾌﾞﾗｯｸﾎﾞｯｸｽﾃｽﾄはとても有効です｡
開発者が仕様を勘違いしている場合､開発者が作ったﾃｽﾄｹｰｽも勘違いした仕様で作るためﾊﾞｸﾞが見つからないわけです｡
ｶﾊﾞﾚｯｼﾞや信頼度成長曲線や不具合の対応状況も最終的な客先ﾘﾘｰｽの判断には必要となります｡
>ﾃｽﾀｰは一般的にはあまりいないのでしょうか？
>今の環境しか経験がなく一般的なことがよくわからないので聞きたいのですが
>ﾃｽﾀｰはﾁｰﾑまたは会社に1人はいるものなのでしょうか？
｢一般的な状況｣はなくて､企業や業務内容でも全く事情が変わると思います｡
金融関係や宇宙開発などでｼｽﾃﾑを新規に開発する場合では､そのﾃｽﾀｰになり得る実力を発揮出来る人物やﾁｰﾑをﾃｽﾀｰに任じるでしょう｡しかし､小修正などの場合ならばそのﾌﾟﾛｼﾞｪｸﾄ開始時にﾃｽﾄ仕様も決まるでしょうから､専任のﾃｽﾀｰを任じるということはないでしょう｡
基本のｼｽﾃﾑの原型が一応稼働していて､それをﾍﾞｰｽにｶｽﾀﾏｲｽﾞする程度の場合も､ﾃｽﾀｰを別人に充てることもあまりないでしょう｡そのような業務を主とする企業では､専任のﾃｽﾀｰを養成し組織的に継続させるのは難しいから､開発ﾁｰﾑ内で何らかの対策を講じるのが普通に行われる方法だと思います｡
下のような開発をする場合には､机上で点検検討するだけではとても実用にはならないから､実機を色々の場面で繰り返しﾃｽﾄしてﾃﾞｰﾀを収集解析するﾃｽﾄ専門ﾁｰﾑは編成されていると思います｡
http://www.mitsubishielectric.co.jp/news/2015/1014-b.html?cid=rss
>ﾃｽﾀｰがいない場合は､ﾌﾟﾛｸﾞﾗﾏがﾃｽﾄをしてそれがﾘﾘｰｽになるということでしょうか？それかﾃｽﾄ駆動型開発はﾌﾞﾗｯｸﾎﾞｯｸｽﾃｽﾄは必要ないのでしょうか？
開発仕様そのものの不備や欠落を問題にしないのであれば､TDDでしっかりやるとほとんどの場合うまくいくでしょう｡ﾃｽﾄﾁｰﾑを作り､専任ﾃｽﾀｰを任命してやらせても､どの期間でどれだけ成果が出せるのかが危ぶまれるのなら､実務上､ﾃｽﾀｰを配するのは妥当なやり方ではないでしょう｡ そのｼｽﾃﾑである範囲では問題ないと認定できればﾘﾘｰｽして問題ないでしょう｡ どのような開発体制や検証方法をとっているかに関係なくて､｢実務の期間､ｺｽﾄ｣と｢発生するﾘｽｸ｣の総合判断でしょう｡
広く販売する一般製品に組み込むものでも欠陥は皆無ではないです｡顧客毎のｼｽﾃﾑでは､問題が発生し対策が見つかれば､放置した場合のﾘｽｸとの兼ね合いを考えて､改修するという方式で十分であるｹｰｽが多いでしょう｡ その程度にまでの完成度が開発ﾁｰﾑ内で確認出来るように開発方法やﾘﾘｰｽ基準を定めている企業が多いと思います｡
>正直ﾃｽﾀｰの仕事はあまり好きではなく､なくせるものならなくしたいです｡
好きかどうかで仕事をされては､企業として困ります｡どうも好きになれないのでほどほどのﾃｽﾄをする担当者にﾃｽﾄを任せたのでは､企業としてﾃｽﾄをさせる意味はないです｡
??????????
ﾌﾞﾗｯｸﾎﾞｯｸｽﾃｽﾄ＝ﾃｽﾄ対象の｢ﾃｽﾄ仕様｣に基づいて､ﾃｽﾄ対象の｢内部の構造を見知らない｣状態で､｢中の見えない箱(ﾌﾞﾗｯｸﾎﾞｯｸｽ)｣として､ﾊｰﾄﾞや全体は問題外にして､｢入力を各様に変えてﾃｽﾄ対象がどう出力を返すか｣をﾁｪｯｸする作業ばかりやっていると､疲労するのかもしれません｡好きになれないのもわかります｡
ただ技術者に開発や設計をしてもらう場合､実力のある人物a､何とかやれるかなぁﾚﾍﾞﾙの人物b､まだとても一部さえも任せることができない人物cがいると､ﾘｰﾀﾞや分担責任者にはaを配し､ﾁｰﾑ内ﾒﾝﾊﾞｰとしてbを配し､cにはｺｰﾄﾞ書きやﾃﾞﾊﾞｯｸﾞ､ｼｽﾃﾑﾃｽﾄの作業をやらせるということはあるでしょう｡cがそうした作業をする中でも､自分の時間を使って自分が独自に勉強し､ｺｰﾄﾞが読める･ｺｰﾄﾞを書ける･仕様を展開できるのようになったり､過去にﾁｰﾑ内で蓄積されているﾓｼﾞｭｰﾙやらｼｽﾃﾑの特徴･長短をある程度理解してくると､bのような仕事もやらせてもらえる可能性は出て来ると思います｡ 知識や実力がないのを｢指導がないから､教えてもらってないから､勉強時間がなくて､そうした機会がないから｣と云っていると､設計や開発の仕事をやらせてもらえる可能性はとても低くなると思います｡
工業製品の抜き取り検査や製品の安全性試験､電磁波試験､温度試験､強度試験､耐久性試験などでも､とても大切な仕事です｡ 多くのﾋﾄはそこに意義を見出し､真剣に誇りをもって取り組んでいます｡ どうにも好きになれないのであれば､異動を申し出るか､転職するしかないでしょう｡ その場合､本人の持っている実力や就業･勤務面から見た特性で､異動の先､転職の先は判断しようとすると思います｡
