アカウント名:
パスワード:
システムの発注元である行政側のキーマンが、システム開発の委託業務に関して経験が浅い(もしくは皆無)なのは仕方ないとして、システムに組み込むべき業務内容の理解に乏しい(もしくは皆無)というパターンもあるのでは?
#出世コースに乗った管理職は2~3年毎に「さまざま」な部署に異動していたような気がする。
管理職はそんな細かいところに口出ししたりしませんよー
「システムに組み込むべき業務内容の理解に乏しい(もしくは皆無)」だろうがなんだろうが要求した製品を時間通りに納品するのは同じでしょう。
理解に乏しいまたは皆無だからスケジュールを守らなくていいなんてありえない。
何を要求していいかわからない何を要求しているかわからない要求しているものにカタチがないから何を納品しても違うと言い出す。何もわかってない担当者様はこんなもんです
業界の知識が無いのかもしれませんが、開発手順として、最初期の段階の「要件定義」という工程で要求を明確にしてお互いに合意を取ります。そこで合意が取れなければ開発に入れません。また、納品物や納品条件についても明確にして合意の上で契約書が交わされます。特に行政との契約なんて、詳細にガチガチに。
開発スケジュールに関してはどちらが提示したのかわかりませんが、開発側は開発するに当たってのリスク(現システムのドキュメントが無いとか、市の担当者の知識不足とか)を織り込んだ上で合意をしているはずなので、結局「現行システムの基本情報の不足」なんて言っている時点で開発側の見積もりが甘かったという事なのでしょう。
現実の入札は、こういうことをしたい、しかありません。業者は こういうことをこのくらいの期間と費用でできます という提案書を提出(入札)します。顧客は提案書を評価して業者を選定するわけですが、当然この段階ではまだ詳細は未定です。詳細な実現方法は契約後に詰めていきますが、こういうことをしたいの範疇で要求が膨れることはあります。こういうことをしたいの範疇を拡大解釈したがる顧客だと、何があってもおかしくないことになります。
もし契約後に詰めるのだとしても、無理な機能実装や無理なスケジュールなら実現可能なレベルに摺り合わせるだけですよ。結局、それが出来ないレベルの開発会社だったということでしょう。
弊社でも行政のシステム開発部門がありますが、契約解除なんてよほどの事をしないとそういう措置にならないですよ。開発会社の対応が悪く信頼できないとか、コミュニケーション含めた技術力がないとか、もう見込みが無いと判断されたのでしょう。
摺り合わせをするというのは同意ですが、摺り合わせとは相手と合意するということなので相手次第の部分がありますよね。御社がうまくいったうまくいってるからと言って、他の担当者がついてる他の案件が同様にいくとは限らないんですよ。相手が合意しても合意を反故にすることもあるし、えーとどこだったかの病院でも無茶ぶり振りかざして敗訴してましたよね。ああいうことが行政相手では起こりえないなんて保証があるわけではなくてですね、今わかる情報だけでは業者側に瑕疵があるとは断言しかねるのですよ。あなたは業者側の瑕疵を確信してるみたいですけど、何か知ってるなら教えてくださいよ。
要件定義の解釈に違いがあって、開発が終盤に差し掛かってから揉めるなんてのは結構ありますよ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
行政固有の問題? (スコア:2)
システムの発注元である行政側のキーマンが、システム開発の委託業務に関して経験が浅い(もしくは皆無)なのは仕方ないとして、システムに組み込むべき業務内容の理解に乏しい(もしくは皆無)というパターンもあるのでは?
#出世コースに乗った管理職は2~3年毎に「さまざま」な部署に異動していたような気がする。
Re: (スコア:0)
管理職はそんな細かいところに口出ししたりしませんよー
Re: (スコア:0)
「システムに組み込むべき業務内容の理解に乏しい(もしくは皆無)」だろうがなんだろうが要求した製品を時間通りに納品するのは同じでしょう。
理解に乏しいまたは皆無だからスケジュールを守らなくていいなんてありえない。
Re:行政固有の問題? (スコア:1)
何を要求していいかわからない
何を要求しているかわからない
要求しているものにカタチがないから何を納品しても違うと言い出す。
何もわかってない担当者様はこんなもんです
Re: (スコア:0)
業界の知識が無いのかもしれませんが、開発手順として、最初期の段階の「要件定義」という工程で要求を明確にしてお互いに合意を取ります。
そこで合意が取れなければ開発に入れません。
また、納品物や納品条件についても明確にして合意の上で契約書が交わされます。
特に行政との契約なんて、詳細にガチガチに。
開発スケジュールに関してはどちらが提示したのかわかりませんが、開発側は開発するに当たってのリスク(現システムのドキュメントが無いとか、市の担当者の知識不足とか)を織り込んだ上で合意をしているはずなので、結局「現行システムの基本情報の不足」なんて言っている時点で開発側の見積もりが甘かったという事なのでしょう。
Re: (スコア:0)
現実の入札は、こういうことをしたい、しかありません。
業者は こういうことをこのくらいの期間と費用でできます という提案書を提出(入札)します。
顧客は提案書を評価して業者を選定するわけですが、当然この段階ではまだ詳細は未定です。
詳細な実現方法は契約後に詰めていきますが、こういうことをしたいの範疇で要求が膨れることはあります。
こういうことをしたいの範疇を拡大解釈したがる顧客だと、何があってもおかしくないことになります。
Re: (スコア:0)
もし契約後に詰めるのだとしても、無理な機能実装や無理なスケジュールなら実現可能なレベルに摺り合わせるだけですよ。
結局、それが出来ないレベルの開発会社だったということでしょう。
弊社でも行政のシステム開発部門がありますが、契約解除なんてよほどの事をしないとそういう措置にならないですよ。
開発会社の対応が悪く信頼できないとか、コミュニケーション含めた技術力がないとか、もう見込みが無いと判断されたのでしょう。
Re: (スコア:0)
摺り合わせをするというのは同意ですが、摺り合わせとは相手と合意するということなので相手次第の部分がありますよね。
御社がうまくいったうまくいってるからと言って、他の担当者がついてる他の案件が同様にいくとは限らないんですよ。
相手が合意しても合意を反故にすることもあるし、えーとどこだったかの病院でも無茶ぶり振りかざして敗訴してましたよね。
ああいうことが行政相手では起こりえないなんて保証があるわけではなくてですね、
今わかる情報だけでは業者側に瑕疵があるとは断言しかねるのですよ。
あなたは業者側の瑕疵を確信してるみたいですけど、何か知ってるなら教えてくださいよ。
Re: (スコア:0)
要件定義の解釈に違いがあって、開発が終盤に差し掛かってから揉めるなんてのは結構ありますよ。