保守できなくなり、塩漬けにしたままのオープンシステム—。いま“オープンレガシー”が情報システム部門を苦しめている。
…
　1990年代から2000年代の初め、オープンシステムは「早く安く作れる」「新しい技術が使える」「1社のベンダーに縛られない」といった輝きを放ち、“自由”の象徴だった。このメリットを追って、多くの企業がメインフレームからオープンシステムへと開発の軸足を移した。
　だが今、その輝きは色あせ、輝きの裏に隠れていたデメリットが情報システム部門に重くのしかかっている。「早く安く作れる」というメリットは「作りすぎて保守できない」というデメリットに裏返された。「新しい技術が使える」というメリットの裏には「選んだ製品が廃れる」というデメリットが、「1社のベンダーに縛られない」の裏には「組み合わせの制約で更改しにくい」というデメリットが存在した。
…
　メリットを追い続けてとにかく作り続けた結果、振り返ればオープンシステムはレガシーとなって企業を苦しめている。しかし、開発コストとスピードを考えるとメインフレーム時代には戻るのは現実的ではない。

今そこにある「オープンレガシー」 – 記者の眼：ITpro

同記事は、「オープンレガシーを救う七つの鍵」をこの様に挙げています。

1. 運用を立て直す (ISMS、ITILを導入する等)

2. 保守切れソフトを更改する

3. 標準化で範囲を狭める

4. 技術マップを持つ

5. 陳腐化させない努力を続ける

6. 仮想化は一時避難所と考える

7. 所有か利用か、スタンスを明確にする

この中で出来ていないとすれば最優先すべきは、「3. 標準化で範囲を狭める」でしょう。

このご時勢ですしIT投資は抑制気味でしょうから、オープンレガシーがどんどん増えていく状態ではないかもしれませんが、ハードウェアやミドルウェアのリース契約更新、耐用年数、保守期限など、ハードウェアやOSやミドルウェアのマイグレーションは定期的にやってくるでしょう。

これ以上増やさない為にも、情報システム、特にハードウェア、OS、ミドルウェア、インターコネクト（ネットワーク）などのインフラストラクチャ部分の「社内標準化」と、情報システム部門による稟議フローへの積極的介入が必要です。

何より、最適化するチャンスでもあります。
モノによっては、SaaSに移行した方がええやん、と言うモノも結構あるでしょう。
特にコモディティ化が顕著なモノは沢山あるでしょう。
例えばDNS、メールサーバ、勤怠管理、グループウェア、等など。

運用系の人は、世の中の技術トレンドをよくウォッチして、積極的に経営層に具申していかなければいけません。
そのためには、まずなんでもオンプレミスでやりたとか言うこだわりは捨てましょう。
あと、レイヤの違う人と話をするスキル、プレゼンテーションをするスキルを身につけないといけません。
最初はなかなか判って貰えないでしょうけど、場数も必要でしょう。
相手に理解してもらうには、辛抱強く訴え続ける事も必要かもしれません。頑張りましょう。

それにしても、どうも「システム運用」系の人々は地位が低い事が多い。

アプリケーションを作る開発系の人々は元より、運用系にも開発系にもどちらにも生息するインフラストラクチャを設計・構築する構築系の人々よりも、一段下の扱いを受ける事が多いです。

原因は色々あるんだけど、運用系は「売り」に直結して無い事で経営層から軽視され、「技術スキルと単価」から相対的に開発系と構築系から下に見られがちです。（あくまで一般論です）

あと、職責上どうしても「安全側」に偏った考え・発言が多いのも運用系の特徴です。それが仕事の一部だから当たり前だけど、嫌われ者役にならざるを得なかったりします。

運用上見つかった不具合を報告するのも仕事なので (ITIL的に言うと RFC、Request For Changeですね)、これまた喜ばれる事は少ないです。開発者の方々、フィードバックをくれる運用系の人にはちゃんと感謝しましょう。

不具合の対処といえば、原因究明できれば治ったも同然なんですが、それが一番難しいんです。
オープン系のシステム、特にオープンソースを多用していると、何が起こっているかを正しく知る事はあまり重要でないというか、難しいんです。それよか怪しい所を交換してみようとか、そういう運用になる事が多いです。Googleのハードウェアに対する考え方がそうですね。

で、原因がアプリケーションだと判明した時、それを直そうと思っても最新のソースコードどこにあるねんとか、ビルド環境ってどうやったけとか、その言語はもう使える人いませんよとか、ドキュメントないですけど直したとして他との影響が無いかどうやってテストすりゃええねんとか、ステージング環境なにそれとか、なんかガッカリな状態だったりする訳ですよ。

結論として「運用対処の方が安くつくよね」と言う事が結構あります。
それはそれで良いんですけど、運用系の人はちょっとだけ傷つきます。
私もその台詞良く言いますごめんなさい。

運用系側の視点に立つと、開発・構築系の方々の担当するフェーズ（企画、設計、開発、実装、試験）での短納期でやっつけちゃったね的な事とか、コスト制約とか、大人の事情とかでの、ムリのしわ寄せ出てるでしょう的なシステムが大半な訳です。ぶっちゃけた話。

何色々ケチってクライアントや上の言いなりになってテキトーにつくってやがんだこのやろうドキュメント出せやとか、本音では思ったりする事もしばしばなんですよ。

それでも運用系の方々の大半は、開発系の方々を技術的にリスペクトしているんです。自分には出来ない事が出来るから。開発系が良いモノを作ってくれた時なんか、我が事の様に喜ぶもんです。

どうです。愛おしい気持ちにさえなってきませんか。

逆に開発系の方々は運用系の仕事が出来るか？と言えば、オペレーションはある程度は出来ちゃうんです。良くも悪くもドキュメンテーションが運用管理の基本だから。

開発系の方々は、なんとか頑張って研修制度とかを設けて3ヶ月位やってみたらえーんですよ。マジで。運用フェーズの経験が無い開発者の方は特に。

なぜなら、運用フェーズがイメージ出来ない人には保守性の高い成果物なんて作れないからです。さもなくば座禅組んでTCOについて72時間位考えて見てください。

Twitterでは大量のサーバを運用しており、それらのサーバに対してのアップデートは素早く行わなければならい。しかしGitサーバに対するアクセスによってデプロイを行うことには非常に問題があった。

そこでBitTorrentを使ってデプロイする「Murder」というツールを開発をした。Murderは、BitTorrentを包含して内部ネットワーク用にオプティマイズしたもの。これまで約900秒かかっていたデプロイの時間が約12秒になり、75倍も速くなった。

なぜBitTorrentをベースに選んだかといえば、多くのライブラリがあることが理由の1つだ。
…
Murderはオープンソースで作られており、基本的にはPythonのスクリプトとCapistranoスクリプトでできている。
TwitterがBitTorrentで高速にデプロイしている仕組みについて － Publickey

このLarry Gadea氏と言う人も頭が柔らかい人ですね。

優れた技術力を持ちながら、かつ既に有るものは最大限利用すると言うマインドのある開発者には、なかなかお目にかかれません。

加えて、比較的ネガティブなイメージが強いBitTorrentを利用しよう言う自由な発想と、それを許容する企業風土が無いと、こういうシステムは具現化しないんでしょうね。

請負開発がメインの日本のSIerとかでは絶対に生まれないモノだと思いました。

逆に、こういった大規模システム運用技術は、ネットワークゲームとかを手がける企業こそ得意分野なんじゃ無いでしょうかね。

うーん。ネットワークゲーム屋と大規模WEBアプリーケーション屋。なんか似ているぞ。

「いままで企業内のコラボレーションといえば、メッセージング、スケジュール管理、電子掲示板、ドキュメント共有といった機能を備えるグループウェアが主役でした。しかし、いまそれが大きく変わろうとしています。
いま開発中の企業内コラボレーションツールの多くが、TwitterやFacebookのように、つぶやきとタイムラインを中心としたマイクロブログ的なユーザーインターフェイスを備えているのです。画面を並べてみましょう。」

企業内コラボレーションのTwitter化 － Publickey

以下の企業向けコラボレーションツール（サービス）の画面が比較されています。

・セールスフォース・ドットコムの「Salesforce Chatter」（現在β公開中）

・IBMが開発中と伝えられている「Project Vulcan」

・マイクロソフトの「Office Talk」（開発中）

・シスコの「Cisco Quad」

・SAPが開発中の「SalesOnDemand」

企業向けSNSはイマイチ浸透しなかったけど、今度はソーシャル機能単体じゃ無くて、ビジネス支援のアプリケーション又はサービス群と協調するTwitterライクなミニブログ、という位置づけである事が大きな違いでしょうか。

企業向けSNSがイマイチ浸透していない理由の一つに、既存システムとの親和性があると思います。既にOpenIDでSSO（シングルサインオン）を実現してます、とかいう先進的な企業は、あまり聞いたことがありません。

最も企業内で普及している認証サービスは、多分Microsoft社のActive Directoryでしょう。
ただActive DirectoryはWEBサービスとの連携という意味ではイマイチです。

殆どの企業は、グループウェアを導入していたらそのアカウントは別に持っているんじゃないでしょうか。そこに仮に後付けでSNSをポンと立てても、アカウントを覚える数が増えるので面倒くさくなって使わなくなってしまうんじゃ無いでしょうか。

そういう意味では、Salesforce.comのChatterにはちょっと期待しています。

早速テキストに書き起こしてくださった方がいます。ご苦労様でした。
【書き起こし.com】孫正義VS池田信夫「光の道」対談（夏野剛司会）
わたしも一度UStreamで見てはいましたが、今一度全部読んでみました。

光の道も大切ですが、電波の再編は喫緊の課題です。
これは討論のお三方の共通意見でもありますが、司会役の夏野さんがアゴラの記事で詳しく書いておられます。

周波数政策と通信業界の競争戦略　―　夏野剛 : アゴラ

既得権を持つ側のテレビ局や新聞社はこれを報道する事はありません。

今わたしに出来る事は、出来るだけ関心を持ち続ける事と、この事実を出来るだけ広める事です。

「このままでは将来iPhoneやAndroidが日本で使えなくなります」と言う部分は、技術に明るくない人にでも説明しやすいですね。

ITは、今でも経済の最大のエンジンである。環境保護で成長するなんてナンセンスだが、日本の通信インフラは世界一で、成長のポテンシャルも大きい。それなのにIT産業がだめになるのは、新規参入と競争がないために賢いIT消費者が出てこないからだ。特に付加価値の低い工業製品が新興国との競争にさらされている今は、高度な情報サービスを開発するイノベーションが、IT産業の――そして日本経済の――立ち直る鍵である。
池田信夫 blog : ITはもう成長産業じゃないのか

激しく同意しつつも、その為に必要だと思うことがあります。
それは、中小企業に企画力と要件定義力のある人材をもっと増やさないといけない事です。

IT自体はただの仕組みであり、経営に役立てないと意味が無い。

パッケージソフトウェアが適用できる分野は兎も角、それを活用して業務を改善するのは結局ヒトであり、導入したシステムを用いて成果をあげて初めて経済的に役に立つ訳です。

情報システムは結局道具でしか無いので、その成果は常に従業員の仕事ぶりを通じて間接的に経営に反映されるケースがが殆どです。

（勿論ソフトウェアそのものを売ったり、システムのサポートで食うビジネスモデルもありますが、それは全体から見て小数でしょう）

いくらITで業務を効率よく出来るようになっても、楽になった人的リソースが効果的に新規事業や既存業務の改善に振り向けられないと、経営者にとっては何の意味も無いですね。

またサービス業においては、他社との差別化を図るために情報システムでサービスの付加価値を上げられる可能性があるけど、そういう情報システムの企画・開発には、その業界や他社サービスの知識に加え、自社のサービスそのものを深く理解した上で、どの様にすれば勝てるのか、という思考をした量が、アウトプットの質を決めるのに重要だと思います。

しかしITに明るい人材とか企画力がある人材を確保しやすい大企業なら兎も角、圧倒的多数の中小企業において、ITを絡めたサービス戦略を立てられたり、企画できたりする人材が不足していると思うんです。

中小企業は、情報システムを発注する立場として、色々やりたい事を社内で取りまとめる力や、市場動向や予算や技術の制約条件を考慮しながら企画を練り上げる力が、不足しがちなんですよね。

そういう意味で、SIerやその下請けに集中している日本のソフトウェアエンジニアは、もうちょっとエンドユーザ企業にちらばった方が良いと思うんです。

デジタル土方と揶揄される過酷な労働条件の下、言われたものを理不尽な納期で作る事に納得のいかないエンジニア・プログラマの方も多いと思います。

鶏口牛後と言う言葉もありますが、ITに明るい人材が重宝される中小企業に行けば、必要とされそれに応える喜びを見出せる可能性が高いと思うんです。

情報システム戦略は経営戦略と密接である事が多いので、中小企業では、たとえヒラでも技術に明るい人材は、経営トップに意見を聞いてもらえる立場になれる可能性が高いです。

もちろんその為には、大好きな要素技術以外にも、経営やその会社の業界とか業務とかに興味を持ち学ぶ事も必要な訳で、コード書く量が減ったりする訳ですけど、長い企業人生を考えたらそれもアリなんじゃないかと思います。

そして、中小企業で発注側にまわった時、受注側にいた時判らなかった事が色々見えてくると思います。
両方判っているエンジニアは、まさに賢いIT消費者と言えるでしょう。

日本の携帯電話が、iモード全盛の時期に機能だけみると世界よりも２年ぐらい進んでいたのにも関わらず、今や「ガラパゴス・ケータイ」と呼ばれる世界市場でまったく競争力を持たないものになってしまった一番の原因は、電電公社時代から受け継がれて来た官僚主導の「既得権を持った企業からの横並び調達」にある。

　競争原理が働かないからコストを度外視した開発スタイルが身に付いてしまい、一度既得権を取った大企業がいつまでも保護されるから、ベンチャー企業が育ちにくい。日本の携帯電話メーカーが、世界市場で勝ち抜いて来たAppleやSamsungと正面切っては戦えない企業ばかりになってしまった一番の原因はここにある。

Life is beautiful: ガラパゴス・ケータイと「政府の役割」と

日本国内での携帯電話が過当競争になり携帯が儲からない。だから撤退するメーカーも出てきた。売れないとはいえ、日本ではまだまだガラケーのファンの方が圧倒的に多い訳で、優秀な技術者も多い筈だと思うんですけど、その人たちの力が活かしきれない様になるのは勿体無い話ですよね。

漏れ伺った話では組み込み系のエンジニアの方々の労働環境はかなり過酷と聞きますが、その方たちは今のiPhone、iPadフィーバーとAndroidの台頭をどのようにみておられるんだろう。

元々私はモバイルPCのヘビーユーザーだったこともあり、携帯電話の付加価値には何の興味もなかったので、型遅れで0円の携帯を電話専用で使っていました。メールも、家族との連絡にショートメッセージを使う程度だったので、型落ちでも特に不都合は感じていなかったです。

初代iPhoneが発表されたときも、一昨年iPhoneが日本で発売された時も、最初は全く興味が無かったんですが、3GでGoogleMapが使える ＝ カーナビ代わりになる、と言うのに惹かれiPhoneを買ったわけですが、今一番よかったと思うことは、GMailのおかげでメール環境のポータビリティがすこぶる便利になった事です。

だから人に勧めるときは、母艦PCの要らないAndroidを薦めるんですけど、iモードな人たちはまだiモードなメールアドレスに執着している人が多くて、なかなか耳を貸さないんですよね。

こういう時、つくづく人は変化を嫌う生き物なんだなぁ、と思います。

私自信はゲームをクリエイトする能力も立場でも無かったんですが、何故ゲーム開発会社に行ったのか？と問われると、大げさに言うと、日本の国際競争力の向上に繋がりそうだ、という想いがあったんですね。私なりにですが志をもっちゃってた訳です。

ゲーム開発に携わる人は、プレイヤー(開発者、クリエイター)として非常に優秀な人が多いです。

日本のこういう人達のスキルとパワーが、もうちょっとソーシャルアプリケーションにシフトしてくれたら、もっとブラウザのプラットフォーム化が早まり、Google様の野望実現が早まったりしながら、ウェブの世界でも日本の存在感も高まるんじゃ無いかなぁ、なんて思いました。

HTML5を使えば、SketchPadみたいなアプリケーションも実際に作れる訳だし、手っ取り早くFlushだって良いんです。
OpenSocialに準拠しといてとりあえずmixiアプリでもイイし、なんならfacebookアプリで3憶人のマーケットへ参入してもイイ。

個人的には、アプリやろうぜ！by GMOみたいな動きがもっと盛り上がってもいいのになぁ、と思っています。

アドミニストレーションも、マネジメントも、共に「管理」と訳される場合が多い。

個人的なイメージとしては、

アドミニストレーションは「行政執行」、マネジメントは「経営管理」。

システムのライフサイクル上の運用フェーズにおいて、「システム管理」と言う言葉は、システム・アドミニストレーションの方がしっくりくる。

また「運用管理」と言う言葉は、オペレーション・マネジメントの方がしっくりきますね。

コンピュータ・システムに関する用語は横文字がやたら多いけど、日本語に適切な語彙が無いんだから仕方が無い場合が多いですね。

でも、「管理」に関しては、何もコンピュータ・システムに限った話では無い筈。最初に訳した人達が悪いのか、適切な言葉が見つからなかったのか定かでは無いけど、ちょっと困りんです。

仮のWEBシステムを、脳内でAmazon EC2に移行してみる。

■EC2 インスタンス

次の3つから選択する。Smallで充分。

Small　1.7GB / 1CPU / 160GB HDD / 32bit　($0.1/時間）

Large　7.5GB / 2CPU / 850GB HDD / 64bit　($0.4/時間）

Extra Large　15GB / 4CPU / 1690GB / 64bit　($0.8/時間）

■EC2 データ転送料

次の通り。

$0.1/GB（受信）

$0.18/GB（送信）※ 最初の10TB/月まで

$0.16/GB（送信）※ 次の40TB/月まで

$0.13/GB（送信）※ それ以上

1日当たりのデータ転送量は、仮に4GB/日として、30日で120GB

■S3

ストレージとしてS3を利用した場合、

保存は最初の50TBまで、1GBあたり$0.15。

$0.150 per GB – first 50 TB / month of storage used

$0.140 per GB – next 50 TB / month of storage used

$0.130 per GB – next 400 TB /month of storage used

$0.120 per GB – storage used / month over 500 TB

コンテンツ、画像、DBでだいたい50GB位と仮定。

■S3のデータ転送

2009年6月30日までは1GBあたり$0.03。7月1日以降は1GBあたり$0.1。

■合計

・Webサーバ1台 $0.1(/h)×24h×30day=$72

・DBサーバ1台 $0.1(/h)×24h×30day=$72

・EC2転送料 120GB×$0.18/GB=$21.6

・S3利用料　　$0.15(GB)×50GB=$7.5

・S3転送料 120GB×$0.1/GB=$12.0

計 $185.1

サーバを5、6台追加して、8台構成になったとしても、$600～$1000位、10万円以下でいける計算になる。

これを国内のホスティングサービスで実現しようとすると、監視やら色々ついているので

単純比較は出来ないけど、どんなに安くても30万は下らないと思う。

ヴォータンの独白 – 負の成果主義の悲惨な結末（再論）

内側から見た富士通「成果主義」の崩壊 (ペーパーバックス)

posted with amazlet at 09.05.20

城 繁幸
光文社
売り上げランキング: 13877

おすすめ度の平均:

富士通が崩壊しつつある
勇気ある内部告発であり、そこまで書くのかと辛さを感じる本
人事制度の設計時に反面教師として
まぁ成果主義が日本にあわないのは同意しますが・・・
まずは制度ありきだと失敗するね

Amazon.co.jp で詳細を見る

「内側から見た富士通「成果主義」の崩壊」は昔読んで、大いに納得する所があったし、ヴォータンさんの発言内容も大いに納得です。

http://wotan.cocolog-nifty.com/blog/2008/05/post_dc34.html

一言で纏めると、直属の上司の主観的な評価の方が実情を反映しやすく、評価の階層構造が客観性を担保する、になるのかな。

でも一番はっとさせられたのは、このくだりでした。

「俺達のいる世界は、実は作戦通り行かなくて、小さな失敗の連続の中でいかに大負けしないかって闘ってる様に思う」

まさに言いえて妙。

なんか少し、自己反省させられました。