COBOL「私を殺すと言ってた言語は、みんな死んだよ」 | おごちゃんの雑文
ITPro方面に火種があったので。 COBOLやVB6との決別、初手は不良資産の一掃 中を読めばいつもに日経コンピュータなんだが… 例によって、日経コンピュータがCOBOLを悪者にしている。まぁ、いつものことなんで、それ自体は割とどうでもいいんだが、見出し詐欺はいけない。何がそうかと言えば、後半の「かんぽ生命」の話。 1200億円の巨費を投じて基幹系システムをNEC製メインフレームから米IBM機に移行し、2017年1月に稼働させたかんぽ生命保険も、ツールで全体の1割に相当する不要資産を廃棄した。NECの独自言語「IDLII」からCOBOLにツールでリライトした。 見出しに「COBOLやVB6との決別」とか言いながら、よく見れば COBOLにした という話だ。見出しと違う話なんで「あれれ？」と思ってTwitterで聞いたりもしたんだが、 かんぽ生命副社長・井戸潔が語る基幹系システム刷新、成功
システム・ソフトウェア開発業者の倒産数、過去最悪に - 帝国データバンク
帝国データバンクは1月15日、2000年から2012年にかけてのシステム・ソフトウェア開発業者の倒産動向調査結果を発表した。 システム・ソフトウェア開発業界では、事業立ち上げの容易さやPC・携帯電話の急速な普及を背景に、バブル以降、数多くの企業が設立された。しかし競争が激化し、リーマン・ショックや東日本大震災の影響などもあって2008年を境に倒産が急増。2007年以降は、設立企業が大幅に減少するなかでの倒産増となっている。 2009年12月には中小企業金融円滑化法(円滑化法)が施行されたが、以降も倒産件数は増え続けている。同社によると、システム・ソフトウェア開発業者は無形の商品を扱っており、代表者の人脈や実績、スタッフのスキルなどによって会社の信用が査定されるため、資産背景に乏しく資金調達ができず、金融機関に対する依存度の低い企業が多いことが、円滑化法施行の影響が及んでいない大きな要因だと
あなたの知らない超高速開発
あなたが携わるシステム開発プロジェクトで、開発速度が10倍速くなったらどう思うだろうか。「利用者にすぐに使ってもらえたり早く帰れたりするので、嬉しい」と思うか、「人月で見積もっているので売り上げが減ったりこれまでのマネジメントの方法が変ったりするので、嬉しくない」と思うか。 いずれにしろ、その後にこう思うことだろう。「そもそも10倍なんてできるわけないじゃないか」。だが、実際にできているユーザー企業が登場している。 記者は今年の1月と2月、日本と韓国で25社以上のユーザー企業を訪ねた。日経コンピュータの3月15日号に掲載した特集「『超高速開発』が日本を救う ～サムスンは既に始めている～」の取材のためだ。その中で、スクラッチ開発と比べて「10倍以上に開発効率が高まった」という声を、いくつも聞くことができた。三井住友海上火災保険や朝日生命保険、東京都足立区役所などである。 これは簡易的なシステ
開発者が知っておくべき、6つのUIアーキテクチャ・パターン - ＠IT
.NET開発者中心 厳選ブログ記事 開発者が知っておくべき、6つのUIアーキテクチャ・パターン ―― 「matarillo.com」より ―― 猪股 健太郎 2011/12/15 「.NET開発者中心 厳選ブログ記事」シリーズでは、世界中にある膨大なブログ・コンテンツの中から、特にInsider.NET／.NET開発者中心の読者に有用だと考えられるブログ記事を編集部が発掘・厳選し、そのブログ記事を執筆したブロガーの許可の下、その全文を転載・翻訳しています。この活動により、.NET開発者のブログ文化の価値と質を高め、より一層の盛り上げに貢献することを目指しています。 Martin Fowler氏の『GUI Architectures』を訳して公開しようと思ったのだが、FAQページに「PofEAAの続編などは商業出版する予定なので翻訳はしないでほしい」と書いてある。なので翻訳の公開はやめて、「
今、システム開発に求められるもの
激動の今、システム開発に最も求められるものは何か？こう聞かれたら、記者はおそらく「スピード」と答えるだろう。情報システムが社会・企業の基盤となった現在、「すぐに使える」「すぐに復旧する」「すぐに変更できる」といったスピードに関するニーズは高まる一方である。 東日本大震災の後、多くのITベンダーは1週間経つか経たないかのうちに、自らの製品やサービスを無償で提供したり、復興に役立つツールを開発したりするなどの支援策を続々と打ち出した（関連記事）。このような取り組みはすべてが時間との戦いとなる。スピード開発を超えた、“超スピード開発”が求められる。 従来の開発スタイルでは、超スピード開発を実現できないという面は否定できない。開発現場には速さを阻害する役割分担があったり、ゼロから作る部分が多くあったりする。これらを克服しなければ、超スピード開発は望めない。 折しも創刊5周年を迎えた日経SYSTEM
アジャイル開発の現在・過去・未来
9月4日土曜日に、有志によるアジャイル開発のイベント「XP祭り2010」が早稲田大学西早稲田キャンパスで開催されました。イベントは200名以上の参加者が集まる盛況となり、アジャイル開発への注目の高さをうかがわせました。 基調講演では、「アジャイル開発の現在・過去・未来」というタイトルで、アジャイルの第一人者であるチェンジビジョン代表取締役社長の平鍋健児氏が登場。タイトル通り、アジャイル開発の全体と最新動向を俯瞰する、アジャイル開発のイベントでしか聞けない充実した内容となっています。 この記事では、その基調講演の内容を紹介しましょう。 なぜアジャイルが注目されるようになったのか なぜいまアジャイルが注目されるようになったのか？ 何かのビジネスを行う際には、企業が市場を分析して、企画を立て、IT関連のシステムを発注する、といったことが行われる。すると、ITが「仕様通りにできました」と納品してく
鶴は千年、亀は万年、システムは百年
「システムって、一定期間後にすべて作り直すものなんですか」。20年ほど前の話だが、あるコンピュータメーカーのベテラン営業担当者を取材していた時、思わずこう言ってしまった。システムエンジニア（SE）が苦労して作ったシステムの寿命が案外短いことに驚いたのである。 「オンラインシステムがよれよれになる」。この表現を聞いたのも、その営業担当者からであった。企業の情報システムについて詳しくない、と正直に言ったところ、彼は次のように説明してくれた。 「新しいオンラインシステムを開発して動かしますね。最初はぴかぴかです。でも、使っているうちに、一部を直したり、新しい機能を追加したりします。するとだんだん、プログラムが傷んできます。10年も使ったら、よれよれでもう直しようがなくなる。そのころには最新のコンピュータが発売されていますから、それを買ってもらって、プログラムをまた一から作るわけです」。 「せっか
アジャイルはウォーターフォールよりも難しい
ここにきて、アジャイル開発手法を業務システム（アプリケーション）の開発に適用しようとする動きが本格化している。これまで小規模、Webシステムへの適用が目立ったが、最近は業務システムや大規模プロジェクトへの適用事例も出てきた。アジャイルはもはや“ブーム”ではなく、本格的な普及が始まったと見てよさそうだ。 ところが、実際にアジャイルを採用した現場に話を聞くと、何とことごとく失敗している。そもそもアジャイルは、大規模プロジェクトを想定していないし、請負契約が多い国内のプロジェクトは、要求の増加に歯止めが利きにくいアジャイルと相性が悪い。さらに業務システムへの適用となると、コストや納期の制約があり、品質優先で開発を繰り返しながらシステムを成長させていくアジャイルと考え方が相反する面がある。 それでも開発現場はアジャイルに望みをかけている。刻々と変わる要求やリスクに迅速に対応する必要があるからだ。最
BABOKはアジャイル開発に使えるか
超上流の知識体系「BABOK（Business Analysis Body of Knowledge）」が、注目を集めている。雑誌やWebでも、BABOKに関する記事は増えているし、取材先でも、「BABOK」という言葉を、当たり前のように耳にするようになった。 BABOKを開発・出版しているのは、カナダのIIBAという団体だ。昨年12月7日には、IIBAの日本支部が、BABOKの日本語版である「ビジネスアナリシス知識体系ガイド（BABOKガイド）Version 2.0」」を発行している。 実は、筆者は、2008年12月23日にIIBA日本支部が正式に発足する前に、支部を設立するための準備室にメンバーとして参加していた。この当時は、BABOKという言葉も、BABOKが対象としているBA（ビジネスアナリシス）という言葉も、世間にはほとんど知られていなかった。“プチブーム”のような今の状況は、当
Part2 現場の作成テクニック-どう洗い出すか？
「プロジェクト・マネジメント体系のPMBOKに大きな穴がある。その穴というのはWBSの作成ルールだ」─。こう強調するのは，プロジェクト・マネジメントや開発方法論に詳しいプライドの大上建氏（常務執行役員 チーフ・システム・コンサルタント）である。事実，現場で広く使われるPMBOK（Project Management Body of Knowledge）は，WBSの説明が薄いといっていい。大上氏は「現場でWBSの作成に悩むのは，むしろ必然だろう」と，ルールのなさを問題視する。 Part1ではそれを裏付けるように，読者4人のWBSには苦労の跡が見えた。4人は「重要なのは分かっているが，これまでWBSの作り方をきちんと学んだことはない」と口をそろえる。 抜け・漏れは論外，細かすぎてもダメ WBSは，プロジェクトの開始前にゴールまでの作業を見通したものでなければならない。Part1のWBSや，多く
第6回 ウォーターフォール開発と使い分け
今回は、情報システム部門や開発プロジェクトの特性に応じてウォーターフォール開発とアジャイル開発を適材適所で使い分けられるように、そのポイントを解説する（図1）。 情報処理推進機構がITベンダーに対して調査したところ、国内のシステム開発の実に95％以上がウォーターフォール型で開発を進めているという。おそらくユーザー企業の側でも採用の比率は同様だろう。 しかし、すべてのプロジェクトにウォーターフォール開発が適しているわけではない。システム開発は一つひとつに特性があり、特性が違えば開発の進め方も変わってくるためだ。 全プロジェクトに適用できる“銀の弾丸”となる開発プロセスは存在しないため、特性に合わせて複数の開発プロセスを使い分けることが欠かせない。ここで筆者が勧めたいのは、ウォーターフォール開発とアジャイル開発を使い分けることである。 この二つに絞るのは開発プロセスの性格が全く異なるためだ。ウ
技術要求の概要
技術要求とは，システムに求める機能や性能を総称したものである。また業務要求が機能要求と呼ばれるのに対して，技術要求や運用要求に属する機能は非機能要求と呼ばれることがある。技術要求は細かく挙げていくと種類が多いが，いくつかのカテゴリーに分類できる。まずはその分類例を示す（図1）。 （1）インフラに関する要求 ・ハードウエア（サーバー，クライアントPC，ストレージ，ネットワーク機器など） ・ソフトウエア（サーバーOS，データベースソフト，ミドルウエア，クライアントOS，Webブラウザなど） ・ネットワーク（LAN/WAN構成，回線など） ・機器構成（本番機，開発機，テスト機，バックアップ機など） ・障害対策（多重化，ホットスタンバイ/コールドスタンバイ，代替機など） ・仮想化（仮想化の有無，対象範囲など） ・モバイル（モバイル利用の有無，制限など） （2）システム能力に関する要求 ［パフォーマ
COBOLこそスピード経営に必要
家電通販最大手のジャパネットたかた。同社における開発言語のメインはCOBOLだ。通信販売で取り扱う商品は日々追加され、客先でのセッティングといった付帯サービスも多様化している。情報システムを統括する星井龍也専務執行役員は、「こうした状況変化に迅速に対応するためには、COBOLの高い生産性が必要だ」と語る。（聞き手は井上英明＝日経コンピュータ、写真は林田大輔） メインの開発言語にCOBOLを据えていると聞く。 2008年1月、基幹システムをメインフレームからUNIXサーバーにオープン化するプロジェクトを開始する際に、「当社はメインの開発言語をCOBOLとする」と宣言しました。26人いる情報システム部員の全員が、COBOLを読み書きできるようにしています。それまでは、COBOLを読み書きできる部員は3人だけでした。 当社のシステムにおいて基幹となるのは、販売管理システムです。お客様からの注文や
アジャイル開発の潮目が変わった
ここ一年、アジャイル開発の取材がぐっと増えた。アジャイル開発が日本に上陸して10年、記者が追うようになって8年。今ようやく、地に足がついた形で盛り上がってきたと実感している。 そう思う理由の一つは、取材先が多様になってきたことだ。最近は、一般企業や自治体で働くCIO（最高情報責任者）やシステム部長、大手ベンダーの幹部、経済産業省の外郭団体である情報処理推進機構（IPA）などがアジャイル開発を“熱く”語り始めた。 開発プロジェクトにも広がりが出た。数年がかりでの基幹系システム刷新、SOA（サービス指向アーキテクチャ）にのっとったシステム開発、クラウド上でのSaaS型サービスの開発、ケータイ向けのソーシャルゲームの開発などでもアジャイルが利用されている。 記者がアジャイル開発を追い始めたころ、取材先はたいてい小規模のベンダーか技術に長けたリーダーだった。開発対象も情報系システムばかりで、しかも
仮想化の計画に際して考慮しておくべき事項10選
文：Brien Posey（Special to TechRepublic） 翻訳校正：村上雅章・野崎裕子 2010-02-16 07:00 サーバを仮想化することで大きな利点が生み出されるものの、それにはしっかりとした計画が必要不可欠である。仮想化に踏み切る前に、以下の重要な項目について十分な検討を行えているかどうかを確認しておいてほしい。 サーバの仮想化に踏み切る企業は増加の一途をたどっており、皆が先を争って自社のデータセンターを仮想化しようとしている風潮も見受けられる。サーバを仮想化する利点については議論の余地がないものの、実際にサーバの仮想化に踏み切る前には、以下のような事項を検討しておく必要がある。 ＃1：自社の仮想化計画には単一障害点がないだろうか？ 筆者は最近、自社サーバのすべてを仮想化した企業のコンサルティングを請け負った。この企業の問題は、ドメインコントローラをすべて仮想
アジャイルって受託開発との相性が最悪な気がする - GoTheDistance
全くもって、その通りだなぁと思った。 初期段階ですべての意志決定をしても、問題はコードを書き始めてから表れるのです。そして終わりに近い時点で判断する方が、より正しい判断ができるはずです。ですから、できるだけ意志決定は先延ばしにして、正しい意志決定をしようとするのがアジャイルのやり方です。 「有能な人がコードを書くべき」「意志決定はできるだけ先延ばし」「契約を変えるのは難しい」アジャイルの専門家の答え － Publickey ｢ウオーターフォールとは｣のラベル貼りの議論になるとめんどくさいから、とりあえず｢初期段階ですべての意志決定をしようとするシステム開発の進め方｣という定義で話を進めたいと思います。 滝 ｢要件定義｣→｢設計｣→｢実装｣→｢テスト｣という一連の流れがあって、ウオーターフォールなるものは前工程が100になるまでひたすらそこでPDCAを回します。100になると言う意味は、ソフ
プログラマーには、コーディングの生産性で10倍、コードレビューの速度では6倍もの能力差があるという
プログラマーの生産性をテーマにした有名な著書「ピープルウェア」には、最も優秀なプログラマと最低の成績のプログラマのあいだには約10倍にあたる生産性の違いがある、というデータが出てきます。 これは、1984年から1986年にかけて92社、延べ600人が参加したプログラミングコンテストのデータを分析した結果から導き出された結果で、課題として与えられたプログラミング作業の開始からコンパイル時のエラーを消すところ（第1チェックポイント）へ到達するまでにかかった時間を比べています。 グラフを見ても分かるように、最優秀者と最低者のあいだには作業時間にして約10倍のひらきがあります。また最優秀者は平均の約2.5倍の生産性だそうです。そして、COBOLやFortranのような旧世代のプログラミング言語と、PascalやCのような現代的なプログラミング言語でのコーディングでの生産性はほとんど同じであったそう
最近SIerがだいぶヤバくなっている件 - GoTheDistance
via IT業界から思ったことを。 Twitterでつぶやいたら結構こんな感じで厳しい状態になっているSIerが増えているようなので、僕なりに現状をまとめてみる。 よくわかるSIer涙目の構図 サブプライム、金融危機でSIerのお得意様の金融・メーカー様が大打撃を食らう。 2008年はとりあえず様子見で予算編成は据え置きだったが、今年に入って財布にチャックがかかる。 先行き不透明なので、GW明けぐらいの今期のIT予算が相当カットされた数字になった所が続出。 計画していた新規案件を中止するなどする。運用でなるべくカバーする方向へお客様が動く。 その結果SIerは新規案件がなくなる。案件自体がなくなっていく。予算が無いから当たり前。 大手がプロパーの仕事がなくなってきたのでプロパーで人数減らしてまわし始める。 プライムで食い込んでいるお客様の仕事が減ってきたので、外注に仕事が依頼できる余裕がな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
エンジニアtype 技術者のキャリアを考えるWebマガジン - 転職＠type
http://www.ntts.co.jp/SO/so8/kantou/