「闘うマネジャー」関連の最新 ニュース・レビュー・解説 記事 まとめ

闘うマネジャー：
「積算根拠の説明」をめぐる苦渋――発注側と開発側のギャップ
最近の自治体関係者の話を聞くと、「業者から見積もりを取って予算要求すればいい」というやり方に限界が来ていることに気付かされる。（2009/9/15）

闘うマネジャー：
人を育てる地方IT振興策――「調達」より「創る」
ITコストの低減と地場IT企業の振興を並行して進めてきた「ながさきITモデル」だが、8年間の成果を踏まえて、他の自治体にプレゼン巡業を行っている。そこでぶつかる考え方の違いとは。（2009/8/17）

闘うマネジャー：
自治体にとってのクラウドコンピューティングのメリットとは
クラウドコンピューティングは各地方自治体にとっても重要にキーワードだ。しかし共同でシステムを活用して「割り勘にすれば安くなる」となればいいが、参加者全員が満足・納得するようなシステムは複雑かつ高額でしかなく、「割り勘にしても安くならない」のが現実だ。（2009/7/21）

闘うマネジャー：
「電子自治体化」プロジェクトが通らなければならない関所
自治体の予算策定でも、当然、費用対効果を明確に示すことが求められる。しかし「ちょっとどうなの？」と言いたくなることも…。（2009/6/4）

闘うマネジャー：
良いものを公開し共用する、という全体最適への早道
システムの全体最適というと、まずは関係各所の意見をまとめて…というスキームが基本のように思われるが、本当にそんな方法で全体最適は実現できるのだろうか。（2009/5/13）

闘うマネジャー：
「全部任せちゃえばいいじゃないか」が間違いのもと
丸投げして使えないサービスを作るぐらいなら、発注者責任を意識し、具体的な要求定義ができる仕事の仕方を考え出そう。（2009/4/2）

闘うマネジャー：
戦略モデルを導入するなら「毎年5度ずつ」舵を切れ
一定の成果を上げた戦略モデルをまねる場合でも、個別の事情から断念してしまうことがある。ここを突破するには、あせらず、問題の本質をしっかりと見据えなくてはならない。（2009/2/20）

闘うマネジャー：
「もしもの時どうなさるのですか」――分割発注への疑問に答える
システム構築を分発注で仕事を進める際、個々の仕事をどのようにつなげるのか不安を感じる向きもあるようだ。しかし日常の仕事をどのようにこなしているかを考えれば、解決策は見えてくる。（2009/1/27）

闘うマネジャー：
人を稼ぐと、人が育つ――分割発注の発想
もし、官の役割が「足らざるものを補うこと」にあるとするなら、分割発注により中小零細企業に直接受注の機会を与えることは理にかなっている。（2009/1/21）

闘うマネジャー：
リーマン・ショックと「ながさきITモデル」
7年の期間をかけて構築してきた「ながさきITモデル」。少しずつではあるが、地元企業に変化を起こしつつある。（2008/12/25）

闘うマネジャー：
面倒なことから逃れたいという「裏の目標」をふさぐ
一気にではなく、時間をかけてダウンサイジングを進める意味について「ITの地産地消」という観点から考えてみる。（2008/12/16）

闘うマネジャー：
頼れる人材はすぐそばにいる――地元SEのすごい提案
汎用機システムのダウンサイジングには、さまざまな課題につきあたる場面がある。しかしそこをブレークスルーするアイデアをひねりだしたのは、地元SEだった。（2008/11/20）

闘うマネジャー：
複雑・怪異と思えた汎用機を丸裸に
業務知識の世代交代を着実に行いダウンサイジングを実現するために、長崎県では一気に進めるのではなく、2期構成とし、OpenCOBOLを利用することにした。（2008/11/14）

闘うマネジャー：
できることから始めたダウンサイジング
ダウンサイジングには教科書的な手順があるようだが、まず自分たちが使うシステムをあらためて眺めてみることから始めてみると、最初にできることは何なのかが見えてくる。（2008/10/28）

闘うマネジャー：
着実な「業務知識の世代交代」が将来のリスクを減らす
長崎県庁では「高止まりしている運用経費の削減」を目的に汎用機のダウンサイジングを進めているが、もう1つ大きな目的がある。「システム上の業務知識の世代交代」である。（2008/10/23）

闘うマネジャー：
ダウンサイジングに8年、その背景と理由
安易なシステムのダウンサイジングはコスト増に陥る結果になりやすい。次世代にしっかりと受け継がれるものを構築する必要がある。（2008/10/2）

闘うマネジャー：
システムを守っていくための正しい世代交代とは
システムのダウンサイジングは、複雑化したアプリケーション群をあいまいなまま放置して進めることではない。さらに言えば長年蓄積された開発担当者の業務ノウハウを若い世代に伝えないままでは、新しいシステムを守りきることはできないのではないか。（2008/9/18）

闘うマネジャー：
コスト削減の努力を正しく評価する方法――地方行政でのアイデア
行政のシステムは高価格だと言われるが、その主原因は入札仕様書の曖昧さにある。長崎県では職員が中心となってシステムの設計書を書き、曖昧さをなくし、コスト削減の努力を続けている。この努力が、システム稼働後の改修作業などでマイナス評価につながらないよう、さまざまなアイデアの実行で対処している。（2008/9/5）

闘うマネジャー：
「オープンソースを多用」だからこそ作るサンプルアプリ
駄目なものは駄目、と言いたいけれどなかなかうまくいかないのがシステム構築。オープンソースを多用したシステムの場合はなおさら不安が先立つことが多いのではないか。少しでもプロジェクト失敗のリスクを減らすため、発注に際してサンプルアプリを付けることは効果が大きい。（2008/9/1）

闘うマネジャー：
お盆休みに考える「プロSE論」――ITマネジャーが見抜く設計書
発注側のIT担当者として、マネジャーは外部のSEの質をどう判断すればよいのか。業務のプロではない、システムのプロであるSEに求められるものは、誠実に、丁寧に顧客とともにシステムを作っていく姿勢だ。（2008/8/15）

闘うマネジャー：
開発現場の混乱、紛争はRFPで解決されない
市民権を得たような見えるRFPだが、発注者側が主体的に書くという状況が当たり前、ということではないようだ。（2008/7/15）

闘うマネジャー：
DBのテーブル設計は「収納問題」である
テーブル設計というといかにも専門的だが、自宅を建てるときの話で考えれば、収納をどうするかという事に過ぎない。収納が十分に検討されていない家は、玄関は靴だらけでどこに脱いだらいいのか分からない、ということと同じだ。（2008/7/3）

闘うマネジャー：
「業務はプロ、開発は素人」が取り組むシステム画面のラフスケッチ
「システム開発なんて、とてもとても」という職員に開発のリーダーになってもらうための方法がある。BPRを大上段にかざして「To-Be」「As-Is」を熱く議論する必要はない。（2008/6/19）

闘うマネジャー：
パッケージを選択する理由は何？――OSSサポーター発掘のススメ
業務システムの構築では、パッケージソフトウェアを活用することが大半だ。しかしその理由を紐解くと首を傾げたくなることも多い。（2008/6/5）

闘うマネジャー：
発注者の考える「脱・丸投げ」マニュアル
システムに何か不具合が起こったとき、もはや開発会社の責任では片付けられない。組織内の多くの人の意見を集約できる洗練された「システムの見取り図」作りが、使い勝手のいい、安いシステムの構築の鍵となる。（2008/5/28）

闘うマネジャー：
業務のプロ＝発注者が仕様を書く、は無謀か
設計書は発注者が用意する。「そんなことできるものか」という読者もいるかもしれないが、ここから直さなければ失敗はいつまでたってもなくならない。（2008/4/25）

闘うマネジャー：
行政のシステムコストは健全か？――削減に向けた視点の転換
民間からCIOとして長崎県庁に入り、8年目。「電子自治体化にかかるコストを大幅に削減せよ」というミッションを与えられ奮闘中だが、自らの経験をもとに、コスト削減に必要な「視点」について考えてみた。（2008/4/22）