アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー
同社員ってことは (スコア:1)
ってことは、サムスンの責任か・・・。
行政もなんでこんな大事なものを海外に発注するのかね…。
// せめて「お金がからんでいる」ものぐらい日本企業にしてくれ・・・。 //
// 「安いから」って言っていう言い訳だけはやめて。 //
Li-ion DC 1.2V(定格:3.7V) 500mA 乾電池はリサイクルへ
Re:同社員ってことは (スコア:1, 参考になる)
大手メーカーのべらぼうに高い金額を吹っかけられる上、ブラックボックスを押し付けるなどいろいろな問題からオープンシステムという条件をつけたという話だったとおもいます。
記憶があいまいなので、過去の日経をさがしてみてください。
詳しくかかれているかと思います。
ユーザーも仕様書くらい書けるようにしよう (スコア:2, 興味深い)
おそらく仕様書すらないまま「こういう風に計算してください」と行政の担当者から言われて開発、あとで「これではまずいので手直し」といったことを経験しているので、本来の工数に手直し分を最初から含んで見積もりしているからだよね(ここまでは良く聞く話)。
けどユーザーからしたら、システム開発のための仕様書なんてそうそう書く訳でもないし、普段使わない用語や概念を交えて文章化しなければならない。
そもそも役所の場合、業務の手順や判断基準の文書化すらできてないところが大半では。まず業務手順の文書化(モデル化)から始めないといけないですね。
で、ここでまた「普段やり慣れていない業務の用語や概念」という問題が出てきます。思うにシステム化に限らず、業務効率化はできるはず。しかし、それを実行するためには「業務の見直し(その前準備としてのモデル化)」などが絶対必要です。しかし、このために必要な知識って、未経験者が簡単に身につけられるようなものではないと思う。
なので業務のモデル化を手助けする担当者を配置して、まず業務の文書化から始めたらどうでしょうか。
そしてシステム化の時は、まずシステム化が必要なのか、システム化によってどのような効果があるのかの検討、仕様書やテストケースの作成、仕様書通りに作られているかなどまで業務担当課と二人三脚で担当していけば、こういうミスは減らせると思います。
少なくともシステム開発のユーザー側担当者がユースケースとクラス図くらい理解できるようになれば、かなり改善できると思うけど。