今そこにある「オープンレガシー」
保守できなくなり、塩漬けにしたままのオープンシステム---。いま“オープンレガシー”が情報システム部門を苦しめている。 「仕事の6割を保守切れソフトの更改だけに費やしている」。ある大手損害保険会社のシステム子会社でシステム基盤を開発保守するリーダーはこう打ち明ける。「2009年からIT投資の削減が要求が厳しくなり、開発リソースは限られている。一刻も早く整理して、新規開発にリソースを回さなければならない。ところが現状では、保守切れソフトに足を引っ張られている」と同氏は続ける。 この損保が抱えるオープンシステムは3000個。使われているOSとミドルウエアと運用手順を掛け合わせると140種類にも上る。同社はこれを今後10年で40種類まで減らしていくという。少なくともあと10年はオープンレガシーの呪縛から逃れられないという見方もできる。 オープンシステムのデメリットが重くのしかかる 1990年代か
役職の偉い順にIPアドレスを自動的に振るにはどうしたらよいでしょうか。 - カレーなる辛口Javaな加齢日記
http://ap.atmarkit.co.jp/bbs/core/fnetwork/21576 http://slashdot.jp/askslashdot/article.pl?sid=10/05/03/0232248 役職の偉い順にIPアドレスを自動的に振るにはどうしたらよいでしょうか。 現状、DHCPで固定IPアドレスを割り当ているのですが、昇格時のメンテナンスが大変です。 こだわる幹部とその取り巻きがいて困っています。 これを読んだ感想は「なんじゃ，そりゃ〜〜〜〜」だろうなあ． これって事実上「馬鹿な順で経営患部にIPアドレスを割り振ってる」のではないだろうか．*1 しかし，ある意味でとても日本企業的．こんな馬鹿なことで無駄な作業が増えてサービス残業してるなんてねえ？さらには派閥争いとかあって，もっと訳の分からない論理的に矛盾している指示も来たりする． でも実は似たような話は既に
「作る」から「使う」への転換〜「アプリを作らない」ノンコーディング開発基盤Nintex - 組織を進化に導くIT羅針盤
■アプリを「作る」ことは価値を生まない 日本の生産性は悪化の一途をたどりOECD加盟30カ国中第20位まで落ち込んだ。その原因の一つはナレッジワーカーの業務非効率にある。優秀な社員が手間をかけて素晴らしい業務をしているが、それは本来手間をかけるべきではない非戦略領域である事が多い。ITの面でそれが如実に現れているのが乱立するアプリケーションである。 例えば、ある大手企業Ａ社の例を見てみよう。 大手企業Ａ社は10年前からNotesを利用し始めた。現場のニーズに合わせたアプリを容易に作ることができるためEUCが進展、現場発で次々とアプリが作られ、最終的にDB数が2,000DB近くまで達した。 10年間でIT化は大きく進んだが、その反面DB数の多さがメンテ・サポートコストに跳ね返ってきた。また、バージョンアップや移行をしようとしても、DB数が多すぎて身動きがとれなくなった。ユーザーからみてもイン
システムのコストを下げる vs システムでコストを下げる - masayang's diary
今回の出張でもお客様から直接話をうかがったり、同業の皆様達との情報交換で色々な現場の状況が見えてきた。 クラウドという言葉の引きは強いが、そこにある期待は「システムコスト削減」が中心。正確にはシステム「の」コストをクラウド活用で減らそう、というもの。 もちろん、コスト削減は重要だよ。年間1000万円の節約は、利益率5%の企業なら2億円の売上増と同等だ。 だけど、このようなコスト削減は持続的な成長にはつながらない。今季1000万円節約できたから、来季もさらに1000万円削ろう、などという作戦は長続きしないのだ。企業に求められるのは持続的な成長力のはずである。 では、なぜこのような「システムのコストを削ろう」という発想が出てくるのであろうか。 そもそものシステムを導入する理由は以下のいずれかの筈である。 システム導入「で」無駄なコストを削減する。 システム導入「で」新たな付加価値を生む。 なん
ユースケース、それともユーザストーリー？
Murali Krishnaはこう言う(リンク)。 アジャイル開発へ効果的に移行できないという失敗は、ユーザストーリーが何たるかを理解できていないという根本的な失敗に根ざしていることが多い。 ユーザストーリーの最も重要な側面は、ユーザストーリーが要件（機能）の「スケジュール可能な」ユニットであり、スケジュールは他に依存していないということです。ユーザストーリーの「他に依存せずスケジュール可能な」特徴を実現する鍵となるのが、「ユーザ」がどう使うかという目線に立ってユーザストーリーを表現することです。そうすればユーザが実際にインタラクトできるエンドツーエンド（UIからバックエンド）に実装された機能性のユニットが手に入ります。 Krishnaはアジャイルコミュニティで多数の人々が信じている「ユーザストーリーは唯一、最良のよりどころ」を正確に描写し、Mike Cohnによる「Advantages
Kei-z.biz | [Break]乗り越えられるか？
ソニーの「イノベーションのジレンマ」について一言, Life is Beautiful 先のエントリの続きじゃないですが、この示唆深い書き込みを読んで2つのことを感じた。 ・スーツはギークを理解しなければいけない いや、むしろ「理解する」という上から目線な段階で、すでに理解できていないというか、交わることはないのかな、と。というか「ギーク」という言葉自体ナンセンスな気がする。 このギークが、誰からお金をもらっているとかそういう社への帰属意識が皆無というどうしようもない状態なら、それは相手にする必要ないんじゃないかな。"The Art of Innovation"のIDEOとかだって、それなりにまず最初に人をセレクションしてるし。その上で、スーツは「ギーク」を理解する必要がある。 この業界、「俺、技術はわかんないから。俺は、ビジネスだから。」という人が多いですが、私はそれに対して、
Kei-z.biz | [Break]スーツ議論について
自分はかなり宙ぶらりんな立場なんですが、思うことを簡単に。 まず、ギークに対しては、「どうやってお金をもらっているか？誰からお金をもらっているか？」は考える必要があると思うんです。やはり何かを売ってその対価をもらって給料が支払われているわけなんで、やることとそれが同じベクトルを向いている必要はあると思うんです。逆に言うと、すきなことやって金をもらえると言うのは、結構稀なケースなんじゃないかな。 続いて、スーツに対しては、勘違いはやめる必要があると思うんです。ビジネスを担当すると標榜しているんであれば、ちゃんとビジネスを考えましょう、と。自動車会社で「俺、自動車のことはわかんないから」なんて言えないよね？競争力をつけたけりゃ、バリューチェーンを考えるなんて、ビジネスの教科書の初め半分に出てくる基本中の基本。その大部分を占める技術的なことを無視して競争力なんてつかない。ましてや戦略なんて絶
IT業界の00年代を振り返る - プログラマーの脳みそ
00年代のIT業界というと、2000年問題に始まった。西暦を数字2桁で管理していたがために桁あふれするだなんて、今になって思えばなんとメモリをケチッていた時代だろうと思うところだが、当時のマシンスペックを思えば仕方無くもある。 2000年初頭のマシンスペック 2000年2月17日に発売されたWindows2000の要求スペックは、Pentium 133MHz以上、メモリ 32MB以上、ハードディスク 850 MB以上の空き容量であった。 1996年にリリースされたJavaは2000年5月8日をもってJ2SE 1.3がリリースされ、かなりこなれてきていたし、Java VMのパフォーマンスもほどほどだった。当時の19200kbpsほどのモデムではJavaAppletのダウンロードには時間がかかったし、当時のJREの起動の遅さもあってJavaといえば遅い、というステレオタイプが根づいていたが、ビ
プロフェッショナルなら政策メッセージを使え - かとじゅんの技術日誌
あけましておめでとうございます。今年もよろしくお願いします。 引き続き、ロジカルシンキングの話。前々回、前回と論理の基礎をざっくりと述べた。 同僚や上司、顧客から、納得を得るために必要なこと 〜演繹法〜 同僚や上司、顧客から、納得を得るために必要なこと 〜帰納法〜 これ以上深い論理学の観点には触れずに、、、今回は論理的な表現としての「メッセージ」（命題ともいう）について触れたい。*1 メッセージのタイプは４つあります。 事実メッセージ 評価メッセージ 政策メッセージ 希望メッセージ 簡単に説明すると、 事実メッセージは、単なる事実を述べる命題。 評価メッセージは、ある事柄に対する自分の評価を述べる命題。 政策メッセージは、政策を提言したり、何かアドバイスする命題。 希望メッセージは、依頼や希望を述べる命題。 となる。 この4つのメッセージを理解すると、コミュニケーションや意志決定が円滑にで
そろそろ内製回帰について一言いっておくか。 - なからなLife
最初に、誤解のないように宣言しておくが、自分は内製回帰厨である。 だがしかし、 受託モデルのSIerよりも価値を出せない内製部隊なんかイラネ。 システムを作ること自体が目的化している内製部隊なんかイラネ。 何のためにシステムを作るのか？ 何のために内製部隊としてそこに存在しているのか？ 作業の手戻りを気にして、利用者が要求仕様を固めないと動けないとか、使い勝手の悪い仕様を押し付けてくるとかするのは、内製外製問わずクソだと思うが、内製の方が乗り換えが効かない分タチが悪い。 仕様は「もらう（受動）」じゃない、「まとめる（能動）」だ。 仕様をもらってコードに落とすことしかできないなら、低賃金人海戦術なアジア各国との単価競争にさらされて当然だ。 内製エンジニアは受託のエンジニアに比べ、仕様をまとめる活動に際して有利な条件、環境が与えられている。 会社間のカベがないことで、いろいろな情報を拾いやすく
SIer にとっての最新技術 - SiroKuro Page
最新技術を一式、SIer に与えるとする。 まずは RoR を与えてみよう。「RoR で作れば生産性が高まる」という噂を聞いて、SIer は興味を持つ。そして【自分のやりたいことが RoR で実現可能か否か】を調べはじめる。実現できなかったら【どのようにすれば RoR で実現できるか】を調べはじめる。そして RoR は SIer に使われずに終わる。SIer の生産性は元のままだ。SIer がしたかったことは、独自の規約を作ることだった。独自規約が RoR の規約と衝突し、結局のところ RoR は使用されたが活用はされなかった。 次に、適当な KVS を与えてみる。実行速度が上がるという噂を聞いて、SIer は興味を持つ。しかし KVS から手を引くのはとても素早かった。高度な SQL が動かせず、また諸々の政治的理由により【安価な】 KVS は【高価な】 RDBMS に敵うことはなかった
ポタージュを箸で飲む技術 - SiroKuro Page
「ご飯はちゃんとお箸で食べなさい」と躾られて以来、素直にそれを守っている SIer 「箸で食事することが日本古来の伝統だ」と習慣や風習を頑固に守っている SIer 「この箸は両親の形見なんです」と箸自体に特別な意味を見いだす SIer そういう SIer が、いざポタージュを食卓に出されると、箸でポタージュを飲もうと四苦八苦をし始める。 「箸を使う技術力が試される時だ」と自らを奮い立たせるが、そんな技術力を試して欲しいなんて周囲は全く望んでなんかいない。 苦労して得られるものは満足感しかない。 とある SIer は先割れスプーンを発明した。 また別のとある SIer は、ポタージュをマグカップに入れることを考案した。 彼らは四苦八苦する SIer を尻目に、有意義な食事を楽しんでいる。 そんな「ひとつ抜きん出た SIer」にならなければならない。 多くの SIer は、目の前にあるのがポタ
Google App Engineでコードを書くと、処理のひとつひとつが課金に見える
先週末、ちょっとしたプログラムをGAE/Jで動かして実際に使ってもらってみたのですが、そうすると、いままでテストでちょこちょこやってたときには全部のDaily Quotaが0%だったものが、数%の数字を示すようになります。 これを、ちゃんとプロモーションして多くの人に使ってもらおうとすると、課金が発生したり制限にひっかかったりしそうです。 で、たとえばDatastore APIの呼び出し回数がヤバいとして、API呼び出しを減らすためにキャッシュしようとすると、MemcacheのほうのAPI呼び出し回数がヤバくなってきます。 で、じゃあということでデータストアにデータを置くようにすると、保存量の制約で課金がかかってきます。で、それならと、データストアに置くのはシリアライズしたデータにしてデータ量が最低限になるようにすると、今度はその処理をするためのCPU時間で課金がかかってきます。 コードを
第12回 価値を描くための“自分改革”
ビジネスとITの摩訶不思議な世界を“創発号”に乗って旅する匠Style研究所。第9回から前回までは、価値の正体を追い求めてきました。今回からは、企業の問題から離れて、自分自身を見つめる旅になります。会社の問題や課題の前に、自らを見つめ直し“自分改革”を起こしてみましょう。それはきっと会社の問題解決や、本質的な課題発見につながることでしょう。 今回は、みなさんの自分改革のきっかけになるよう、僕が取り組んでいる自分の中での改革について話しましょう。みなさんの自分改革に、少しでも参考になれば嬉しいです。 価値を描いていないエンジニアリング 僕自身が仕事に物足りなさを感じていた頃は、「画期的なプログラミングをしたい」とか、「ユーザーの要望を実現する素晴らしい設計をしたい」とか、「もの凄くためになる開発方法論を作りたい」などと思っていました。そのような夢を追い続けてはいましたが、何か物足りなさを感じ
“ITゼネコン”という言葉は、とてつもなく失礼だ！
最近、コンピュータ・メーカーや大手システム・インテグレータを称して“ITゼネコン”というらしい。しかし、これはとてつもなく失礼な言い方だ。もちろん、建設会社に対して、である。 少し前だが、ある中堅ゼネコンの情報システム担当者と会ったとき、そのゼネコンの社長がシステム・インテグレータに対して激怒したという話を聞いた。その“事件”の発端自体は、システム開発が遅れ納期に間に合わなくなったという、ITサービス業界にはお馴染みのものだ。しかし、その話を聞いた社長は、担当のシステム・インテグレータを許せなかったという。納期に遅れそうでも、どんなことしてでも間に合わせるのが仕事。その社長の常識からいうと、システムの納期遅れなど信じられない事態だったらしい。 「ゼネコンのプロジェクト管理能力はすごい。我々はその足元にも及ばない」。大手システム・インテグレータからも、そうした声が漏れてくる。実際、建設業界は
2009-11-21
雨はないかなぁ〜 朝晩は寒そう なんとなく寝る前に思いついた言葉 続きを読む 朝起きた直後にふと思いついた言葉 続きを読む
過半数が要求精度向上図る---利用企業が進める満足度向上策
中でも最も多い取り組み策が，「発注先に伝える要求の精度を高めている」こと。回答件数は，半数を超える896件である。要求をしっかりと固めて発注することが，情報システムや，それを構築したIT企業に対する満足度を高めるというわけだ。 要求精度を高めるといっても，その具体的な取り組み策は様々だ（図2）。以下では，代表的な取り組み策を紹介する。 要求定義は利用者の義務---JTB 「IT企業に“ITのプロ”としての義務を果たしてもらうためには，我々利用者にもやるべきことがある」──。JTBの野々垣典男IT企画部長は，利用企業が果たすべき役割の存在を，こう強調する。 野々垣部長が指摘する利用者の義務とは，「要求定義」である。情報システムに求めることを明確にしたうえで，IT企業に提示する。そこでは，あいまいさをなくし，IT企業に伝えた要求がぶれないようにする。 利用者からの要求が変わらなければ，開発途中
ワークVSライフ＝デスマーチ：プログラマで、生きている：エンジニアライフ
10月のお題は「就活生からの『ITエンジニアの仕事についての質問』」ということですので、ワークライフバランスとデスマーチについて、わたしの考えをちょっと書いてみます。 IT業界に足を踏み込もうとしている方々の関心事の1つに「ワークライフバランスを保てるのか」というものがあるらしいです。 この業界は私生活を犠牲にして仕事に捧げている人ばかり、とか思われてるんですかねえ。個人的には、どの業界だって似たようなもんで、IT業界だけが特殊ってことはないと思ってるんですけど。 わたしは「仕事（残業）と私生活の両立はうまくいっているか」と問われたら、「だいぶうまいこといってる方だと思う」と答えます。 今の会社に入って3年ほど経ちますが、1カ月で20時間を超えたのが1回、10時間を超えたのが1回、年の半分以上は残業ゼロという状況です。有給休暇もきっちり全部消化します。世間様が想像するプログラマライフから、
【コラム】システム開発のウソと迷信を見抜ける経営者を目指して (1) もう開発ベンダー任せにはできない(1) - 非常によくあるトラブルの例 | 経営 | マイコミジャーナル
システムを発注するユーザ企業の経営者や事業責任者にとってIT投資は頭痛の種のひとつであるに違いありません。 「リリースしたはずなのに幾度となく繰り返される追加開発。いったいいつまで続くのか? 結局いくらになるのだろうか?」「社内では新システムの不満こそあれ、良くなったという声を聞かない。本当に投資対効果があったのだろうか?」――このような疑問をもっていらっしゃる経営トップは、決して少なくないと思います。 そうした経営トップの皆様に力添えをすべく、本連載では、経営者の立場からは見えづらいシステム開発の裏事情に触れながら、上記のような事象が発生する原因とその解決策について解説していきます。 開発したシステムに対して、不満や疑問を抱く経営者は少なくないはず。その背後には、経営者からは見えづらいシステム開発業界独特の事情が。 第1回となる今回は、システム開発の現場でよく起こるトラブルを紹介しておき
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Kei-z.biz | [Business]一連の話への結論