アカウント名:
パスワード:
というのが, 大方のユーザの実態ではないでしょうか. このあたりの感覚はエンドユーザ相手に仕様のインタビューを行ったことのあるSEなら誰でも経験することでしょう.
簡単な例ですが 3÷2 の答えは何になるのが正しいでしょうか? 2÷3 の答えと
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
仕様のバグ (スコア:1, 興味深い)
別にMSをたたくのが目的じゃないけど、MSの製品に多いよね。
何が正しい仕様かユーザ自身も分からない (スコア:2, 興味深い)
というのが, 大方のユーザの実態ではないでしょうか. このあたりの感覚はエンドユーザ相手に仕様のインタビューを行ったことのあるSEなら誰でも経験することでしょう.
簡単な例ですが 3÷2 の答えは何になるのが正しいでしょうか? 2÷3 の答えと
自治体相手の場合 (スコア:2, 参考になる)
1.仕様作成について
自治体は、その業務のプロではありますが、システム開発については彼らのビジネスの範疇外です。しかしながら、現在の自治体としては、彼らが仕様書を作成しなければならないことも多いようです。
それで彼なりに仕様を作成するのですが、非常に多くの場合、開発側に意見を求めることが多いです。そして、残念ながら開発側が不適切なアドバイスをすることも多いようです。これは、自治体相手の場合、プレゼンの良し悪しなどが受注に結びつかないことが多いためだと思いますが(入札になると、見られるのは金額だけ)、こうしてせっかくの仕様作成にかかわるチャンスを見逃しているのも事実だとおもいます。
2.受注後
うちであった例として、自治体側が作成した仕様である特定のデータベースソフトを使用してアプリケーションを開発せよ、とありました。最近読んだ要求定義工学などでは、このような制限は仕様にするべきではない、とかかれていますが、まったくそのとおりです。実際、業務内容を聞いてみると、日に1000件のデータが入る代物で、そのデータベースの限界は1年ともたずに超えることがすぐに判明しました。これにもかかわらず何の対策もせずに当初の設計どおり開発したわれわれは、わずか3ヶ月分程の収入で、その後2年間ほど無償メンテナンスをすることになりました。
以上から、私の自治体さん相手のポリシーは、
1.意見を求められたら、たとえ嫌われても、たとえ自分が受注できる保証がなくとも、良い仕様がかけるようにアドバイスする。
2.仕様を変えるのも開発側の仕事のうち。
です。