アカウント名:
パスワード:
>ドライバーから不満の声が出ていたようだ。ヤマト側の開発担当者って???「初」だけが目的?
もしかして、日本の車両法に会う改造部分だけの共同開発?
仕様検討とか試験とか、そういうのも開発に含まれますので。車幅、車高、積載量とかのスペック、荷物の積み下ろししやすいような形とか機構なんかはヤマト側が決めているはず。
それじゃあヤマトが自社の利用状況すら把握していないって事やん。流石にそれは無さそうなので、要求してもほとんどは変更不可だったんじゃないかな。
それは仕様検討の段階で現場での要求を把握できていなかったってこと?それとも配備後の利用状況を把握できていなかったてこと?
前者であれば導入時の記事の通り、盛り込んだつもりだったけどダメダメだったということで、パイロット試験みたいの導入していれば良かったねとは思う。後者であれば報道も大きくされて肝いりの企画だったろうから、現場の不満はその上司あたりで止められていたんだろうなー、と想像は出来る。ただどちらにせよ、一番の問題は故障が多いという品質の問題で、調達とか修理工場の関係から国内の自動車会社と組めばいくらかマシだったんじゃないかなぁ。
「とにかく故障が多かった印象。配送途中にとまってしまう。配達スケジュールに大きな影響を及ぼします」「夏の間は主に夜間に使っている。故障して止まっていても目立たない」
>>>車幅、車高、積載量とかのスペック、荷物の積み下ろししやすいような形とか機構なんかはヤマト側が決めているはず。
>>それじゃあヤマトが自社の利用状況すら把握していないって事やん。
>それは仕様検討の段階で現場での要求を把握できていなかったってこと?>それとも配備後の利用状況を把握できていなかったてこと?
以上のような指摘はある程度経験のある開発者ならちゃんと分かっています。でも、今回のような結果はいくらでも起こり得ます。頭で考えたようにはなかなかなりません。今回のヤマトのような事例は、物づくりに携わる方には『開発あるある』だと思います。
以下、自分の経験上考えられる個別な問題を列挙してみる。
・机上検討上(図面上)のほんのわずかな寸法の違いが、現物になると意外と大きい・実機試験をやっても、その期間では出ない問題がある・実機試験の運転者が現場の実作業者ではなかったので目的にかなう情報が得られない (割と多いのが、現場OBで現在開発担当。両方知っているのは強みだが、最新の現場状況を知らない)・実機試験の運転者に優秀な者が抜擢されるために問題が出てこない (腕が良くて問題に気付かない、目的を勘違いして問題ない事を示そうとする、立場上文句が言いにくい、等)
自分は今回のケースでいうとヤマト側の立場でしたから、様々な経験から以下のような配慮をするようになりました。
・既に実用化されたものがあるのなら、多少高額でもリスク回避代として考え、出来るだけ自社開発はしない・必ず本格使用後の手直し予算を確保する(表向き無理なら予算を誤魔化してでも確保する)
# とかなんとか言いながら意外と多いのが、実は誰かが気付いていたり、話題として出ていたにも関わらず対策されないケース。#(忙しさに忙殺されて、なんとなく流されて、無能な上司や予算に忖度、等々割と意識の問題)
社内政治が絡むと、自分の職務範囲でもバレてなければ黙るよね。「気づきませんでした」は言い訳できるけど「知ってました」「直せませんでした」はまずいから。ベンチャーだと会社に飛んでもらっては困る人が突っ込んでいくけど。
要求仕様と現物が違うのはよくあることよ。もちろん仕様作成が現場を知らない人間なことも。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
海軍に入るくらいなら海賊になった方がいい -- Steven Paul Jobs
共同開発? (スコア:0)
>ドライバーから不満の声が出ていたようだ。
ヤマト側の開発担当者って???「初」だけが目的?
もしかして、日本の車両法に会う改造部分だけの共同開発?
Re:共同開発? (スコア:0)
仕様検討とか試験とか、そういうのも開発に含まれますので。
車幅、車高、積載量とかのスペック、荷物の積み下ろししやすいような形とか機構なんかはヤマト側が決めているはず。
Re: (スコア:0)
それじゃあヤマトが自社の利用状況すら把握していないって事やん。
流石にそれは無さそうなので、要求してもほとんどは変更不可だったんじゃないかな。
Re: (スコア:0)
それは仕様検討の段階で現場での要求を把握できていなかったってこと?
それとも配備後の利用状況を把握できていなかったてこと?
前者であれば導入時の記事の通り、盛り込んだつもりだったけどダメダメだったということで、パイロット試験みたいの導入していれば良かったねとは思う。
後者であれば報道も大きくされて肝いりの企画だったろうから、現場の不満はその上司あたりで止められていたんだろうなー、と想像は出来る。
ただどちらにせよ、一番の問題は故障が多いという品質の問題で、調達とか修理工場の関係から国内の自動車会社と組めばいくらかマシだったんじゃないかなぁ。
「とにかく故障が多かった印象。配送途中にとまってしまう。配達スケジュールに大きな影響を及ぼします」
「夏の間は主に夜間に使っている。故障して止まっていても目立たない」
Re:共同開発? (スコア:4, 興味深い)
>>>車幅、車高、積載量とかのスペック、荷物の積み下ろししやすいような形とか機構なんかはヤマト側が決めているはず。
>>それじゃあヤマトが自社の利用状況すら把握していないって事やん。
>それは仕様検討の段階で現場での要求を把握できていなかったってこと?
>それとも配備後の利用状況を把握できていなかったてこと?
以上のような指摘はある程度経験のある開発者ならちゃんと分かっています。
でも、今回のような結果はいくらでも起こり得ます。頭で考えたようにはなかなかなりません。
今回のヤマトのような事例は、物づくりに携わる方には『開発あるある』だと思います。
以下、自分の経験上考えられる個別な問題を列挙してみる。
・机上検討上(図面上)のほんのわずかな寸法の違いが、現物になると意外と大きい
・実機試験をやっても、その期間では出ない問題がある
・実機試験の運転者が現場の実作業者ではなかったので目的にかなう情報が得られない
(割と多いのが、現場OBで現在開発担当。両方知っているのは強みだが、最新の現場状況を知らない)
・実機試験の運転者に優秀な者が抜擢されるために問題が出てこない
(腕が良くて問題に気付かない、目的を勘違いして問題ない事を示そうとする、立場上文句が言いにくい、等)
自分は今回のケースでいうとヤマト側の立場でしたから、様々な経験から以下のような配慮をするようになりました。
・既に実用化されたものがあるのなら、多少高額でもリスク回避代として考え、出来るだけ自社開発はしない
・必ず本格使用後の手直し予算を確保する(表向き無理なら予算を誤魔化してでも確保する)
# とかなんとか言いながら意外と多いのが、実は誰かが気付いていたり、話題として出ていたにも関わらず対策されないケース。
#(忙しさに忙殺されて、なんとなく流されて、無能な上司や予算に忖度、等々割と意識の問題)
Re: (スコア:0)
社内政治が絡むと、自分の職務範囲でもバレてなければ黙るよね。
「気づきませんでした」は言い訳できるけど「知ってました」「直せませんでした」はまずいから。
ベンチャーだと会社に飛んでもらっては困る人が突っ込んでいくけど。
Re: (スコア:0)
要求仕様と現物が違うのはよくあることよ。もちろん仕様作成が現場を知らない人間なことも。