よく使うC++のイディオム 「NVI」と「RAII」CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。
「業務はプロ、開発は素人」が取り組むシステム画面のラフスケッチ
「業務はプロ、開発は素人」が取り組むシステム画面のラフスケッチ：闘うマネジャー（1/3 ページ） 「システム開発なんて、とてもとても」という職員に開発のリーダーになってもらうための方法がある。BPRを大上段にかざして「To-Be」「As-Is」を熱く議論する必要はない。 確実に1歩を踏み出すための方法論 毎年4月になると、筆者のもとには「システム開発なんて、とてもとても」という職員が配置される。もちろん人事課には「業務を知っている人をくれ」とお願いしているので、それなりに優秀な人材であるが、「休暇担当として、現行システムの運用と追加開発を担当してくれ。それと施設予約システムの再開発にも着手して欲しい」と言われれば、「頑張ってはみますけど…うぅぅ……」としか答えられないのが実情だ。他の自治体なら、「経験豊富なベンダーに助けてもらって」となるわけだが、長崎県は歳入に占める県税の割合が14％程度
発注者の考える「脱・丸投げ」マニュアル
システムに何か不具合が起こったとき、もはや開発会社の責任では片付けられない。組織内の多くの人の意見を集約できる洗練された「システムの見取り図」作りが、使い勝手のいい、安いシステムの構築の鍵となる。 発注者側は「発注者責任」を正しく認識せよ 前回は、「システム開発に移る前に、発注者側で画面デザインを徹底的に詰めるべきだ」という話を書いた。「あれ？ そうなの？」と思った読者の方が多かったかもしれないが、筆者は発注者側が行っておくべき当然の作業と考えている。 「システムは業務効率化のための道具に過ぎない」という考えは、いずれの読者も賛成してくれるだろう。そこで、「道具であるなら使い勝手が重要であるはずだ」ということになるが、その使い勝手の責任は誰にあるのだろうか。発注者側のシステム部門なのか、開発ベンダーなのか、はたまたシステムの利用者なのか整理されているだろうか。実例をみてみよう。 「みずほ証
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
