この国はきっと変わるはずだ
昨年末、クリスマス・イブのころから早々とIT企業各社のトップによる年頭所感がメールで届き始めた。そのほとんどが、クラウドをはじめとする流行語をちりばめ、事業の軸足をどこに置くかに言及したもの。だが、なかには一企業としての事業計画だけではなく、国やIT業界の明日について意見を述べたものもあった。 折りしも1月3日にNHKで大河ドラマ「龍馬伝」の放送が始まった。すでに第1部の放送が終了した「坂の上の雲」と併せ、これら年頭所感には何か相通じる思いが込められているように感じた。それは、「何かおかしい」という疑問と「この国はきっと変わるはずだ」という希望である。このことを感じていただくために、以下では「龍馬伝」の一場面、そしてソフトバンク社長の孫正義氏とインフォテリア社長の平野洋一郎氏の年頭所感の抜粋を紹介したい。 「みんな変わらん言うけんど、わしはそうは思わん」---NHK「龍馬伝」 まず、「龍馬
IT Japan Award 2009
■IT Japan Award 2009について■ ■応募要綱 IT Japan Award 2009事務局（日経BP社 日経コンピュータ編集部内）に、電子メールまたはFAX、郵送で「応募用紙」を送付。応募用紙の主な記入内容は以下のとおり。 （1）情報システム名（またはプロジェクト名） （2）構築・活用しているシステムの稼働日、成果が表れた年月 （3）構築・活用しているシステムの狙いや目的 （4）構築・活用しているシステムの特徴について以下から2つ選び、それぞれのアピール点を記入 ・経営革新・業務改革への貢献度 ・システム構築・活用における独創性 ・費用対効果の高さ ・採用技術・手法の先進性 ・業界へのインパクト （5）構築・活用しているシステムの構成 （6）その他のアピールポイントとして、構築・活用しているシステムにかかわる記事が新聞や雑誌で紹介されたり、各種イベントで紹介されたりした実
COBOL入門 ひよこグミ
サルでもわかるCOBOL入門 サル並みの知能しかない私でも覚えることができました 笑いながら楽しくCOBOLを習得しましょう！ リンクフリー ※フレーム分割画面表示 検索などで辿り着いた場合は、クリックして下さい 【更新履歴】 2007/05/22 >COBOL記述時の注意点の中で誤字がありましたので修正。PERFROMになってますた。。 2007/03/09 >How to ダウンロードのCOBOL85ダウンロード先がいつの間にか移転してたためURLを変更 2007/02/07 【テーブル操作】検索3用データ配信を追加 【近況報告】 2007/05/22 ４月の残業が２３０時間を超えました。よく倒れずに頑張ったと思います。 【サイト紹介】 2003/08/19 大先輩であるvokさんのサイト 何で今更構造化プログラム 監督職の方々は必見！ 初めてのお客様へ 【COBOLとは？】 COBO
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といえば遅い、というステレオタイプが根づいていたが、ビ
ブコメとコメントについての回答 - なからなLife
そろそろ内製回帰について一言いっておくか。 - なからなLife について、結構いろいろな反響をいただきましたので、そのいくつかについて、こちらにまとめてレスしていきたいと思います。 開発者は、自分たちが作っている製品なり商品をもっと分り易く伝えなくてはならないね。 http://b.hatena.ne.jp/imai78/20091225#bookmark-18144775 内製でも外製でも、アピールはもっとやっていい（やるべき）と思います。 ござ先輩のエントリにも 経営は基本的に技術屋のことなんかわかるわけないんですよ。 http://d.hatena.ne.jp/gothedistance/20091226/1261808023 という一文があるとおり、相手が勝手にわかってくれるようになるのを待つんじゃなくて、こちらからわかってもらうためのアクションが大事だと思います。 経営者に伝わ
そろそろ内製回帰について一言いっておくか。 - なからな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 は、目の前にあるのがポタ
第2回 開発力の向上工期半減を目指す
開発期間半減に向けた七つの取り組み 倍速開発は七つの取り組みで実現する。開発工程だけでなく、要件定義段階からメスを入れて効率化を図る。 「要件定義段階のミスは、大きな手戻りにつながる。上流の作業品質強化は生産性向上の必須条件だ」と、技術開発本部副本部長の木谷強ソフトウェア工学推進センタ長は話す。 上流作業の強化の一環で、同社が来年4月から本格的に開始するのが、要件定義書のレビューだ。技術開発本部が各プロジェクトの要件定義書に点数を付けて客観的に評価する（図2）。 点数を付けるために、同社はまず、「要件定義書に何を記載するべきか」を規定。同社の開発標準や国際標準のドキュメントを参考にし、全5章、18節からなる「要件定義ガイドライン」として昨年9月に作成し、さらに採点の仕方を「要件定義書スコアリング手順書」としてまとめた。 ソフトウェア工学推進センタの大杉直樹シニアエキスパートは「形式的に正し
Google App Engineでコードを書くと、処理のひとつひとつが課金に見える
先週末、ちょっとしたプログラムをGAE/Jで動かして実際に使ってもらってみたのですが、そうすると、いままでテストでちょこちょこやってたときには全部のDaily Quotaが0%だったものが、数%の数字を示すようになります。 これを、ちゃんとプロモーションして多くの人に使ってもらおうとすると、課金が発生したり制限にひっかかったりしそうです。 で、たとえばDatastore APIの呼び出し回数がヤバいとして、API呼び出しを減らすためにキャッシュしようとすると、MemcacheのほうのAPI呼び出し回数がヤバくなってきます。 で、じゃあということでデータストアにデータを置くようにすると、保存量の制約で課金がかかってきます。で、それならと、データストアに置くのはシリアライズしたデータにしてデータ量が最低限になるようにすると、今度はその処理をするためのCPU時間で課金がかかってきます。 コードを
第12回 価値を描くための“自分改革”
ビジネスとITの摩訶不思議な世界を“創発号”に乗って旅する匠Style研究所。第9回から前回までは、価値の正体を追い求めてきました。今回からは、企業の問題から離れて、自分自身を見つめる旅になります。会社の問題や課題の前に、自らを見つめ直し“自分改革”を起こしてみましょう。それはきっと会社の問題解決や、本質的な課題発見につながることでしょう。 今回は、みなさんの自分改革のきっかけになるよう、僕が取り組んでいる自分の中での改革について話しましょう。みなさんの自分改革に、少しでも参考になれば嬉しいです。 価値を描いていないエンジニアリング 僕自身が仕事に物足りなさを感じていた頃は、「画期的なプログラミングをしたい」とか、「ユーザーの要望を実現する素晴らしい設計をしたい」とか、「もの凄くためになる開発方法論を作りたい」などと思っていました。そのような夢を追い続けてはいましたが、何か物足りなさを感じ
“ITゼネコン”という言葉は、とてつもなく失礼だ！
最近、コンピュータ・メーカーや大手システム・インテグレータを称して“ITゼネコン”というらしい。しかし、これはとてつもなく失礼な言い方だ。もちろん、建設会社に対して、である。 少し前だが、ある中堅ゼネコンの情報システム担当者と会ったとき、そのゼネコンの社長がシステム・インテグレータに対して激怒したという話を聞いた。その“事件”の発端自体は、システム開発が遅れ納期に間に合わなくなったという、ITサービス業界にはお馴染みのものだ。しかし、その話を聞いた社長は、担当のシステム・インテグレータを許せなかったという。納期に遅れそうでも、どんなことしてでも間に合わせるのが仕事。その社長の常識からいうと、システムの納期遅れなど信じられない事態だったらしい。 「ゼネコンのプロジェクト管理能力はすごい。我々はその足元にも及ばない」。大手システム・インテグレータからも、そうした声が漏れてくる。実際、建設業界は
第3回 「大企業だから」「中堅だから」という固定的発想ではダメ
情報システムの“ユーザー企業”にとって、情報システムをどう活用すれば競争力を強化できるのか。ITベンダーやシステム・インテグレーターなどの営業トークや提案内容を見極めるうえで何に留意するべきか。ITベンダーなどに何かを求める以前に、“ユーザー企業”が最低限考えなればいけないことは何か――。 野村総合研究所で約20年間勤務した後に、人材派遣大手スタッフサービスのCIO（最高情報責任者）を務め急成長を支えた著者が、情報システムの“ユーザー企業”の経営者・担当者の視点から、効果的な情報化のための発想法を解説する。 第1回と第2回で、情報システムの活用を誤るダメな“ユーザー企業”の3つのパターンのうち、「流行に踊る“ユーザー企業”」と「業種で物事を考える“ユーザー企業”」の2つを挙げました。 ダメな“ユーザー企業”の3つ目のパターンは、会社の「規模」で物事を考える姿勢です。 この姿勢は、企業規模が
2009-11-21
雨はないかなぁ〜 朝晩は寒そう なんとなく寝る前に思いついた言葉 続きを読む 朝起きた直後にふと思いついた言葉 続きを読む
業務知識の豊富さをアピール 見積料金の見直しに腐心
自社の知名度の向上やパッケージソフトの拡販につながりそうな案件だ。業務知識を武器に、商談は順調に進んだ。ところが見積額と顧客の予算に1000万円の開きがあった。 「この案件を受注できれば、関東地区では無名に近かったアイルの知名度を一気に高められる。何としても受注したい」。 大阪市に本社を構える中堅SIerであるアイルのシステムソリューション事業部大阪営業グループねじ製造・流通チーム係長である樋口隆洋は、こう意気込んだ。電子機器用ねじなどの生産・販売を手掛ける、神奈川県のユニオン精密に声を掛けられた、2008年2月のことである（表）。 このとき、ユニオン精密は生産管理システムの再構築を検討していた。同社の取締役で工場長を務める雨森和彦は、アイルに打診する以前からシステム構築の委託先の選定を進めていたのだ。 雨森は有力候補として、ITベンダーのA社とB社に絞り込んでいた。だが、いずれの提案も決
過半数が要求精度向上図る---利用企業が進める満足度向上策
中でも最も多い取り組み策が，「発注先に伝える要求の精度を高めている」こと。回答件数は，半数を超える896件である。要求をしっかりと固めて発注することが，情報システムや，それを構築したIT企業に対する満足度を高めるというわけだ。 要求精度を高めるといっても，その具体的な取り組み策は様々だ（図2）。以下では，代表的な取り組み策を紹介する。 要求定義は利用者の義務---JTB 「IT企業に“ITのプロ”としての義務を果たしてもらうためには，我々利用者にもやるべきことがある」──。JTBの野々垣典男IT企画部長は，利用企業が果たすべき役割の存在を，こう強調する。 野々垣部長が指摘する利用者の義務とは，「要求定義」である。情報システムに求めることを明確にしたうえで，IT企業に提示する。そこでは，あいまいさをなくし，IT企業に伝えた要求がぶれないようにする。 利用者からの要求が変わらなければ，開発途中
ワークVSライフ＝デスマーチ：プログラマで、生きている：エンジニアライフ
10月のお題は「就活生からの『ITエンジニアの仕事についての質問』」ということですので、ワークライフバランスとデスマーチについて、わたしの考えをちょっと書いてみます。 IT業界に足を踏み込もうとしている方々の関心事の1つに「ワークライフバランスを保てるのか」というものがあるらしいです。 この業界は私生活を犠牲にして仕事に捧げている人ばかり、とか思われてるんですかねえ。個人的には、どの業界だって似たようなもんで、IT業界だけが特殊ってことはないと思ってるんですけど。 わたしは「仕事（残業）と私生活の両立はうまくいっているか」と問われたら、「だいぶうまいこといってる方だと思う」と答えます。 今の会社に入って3年ほど経ちますが、1カ月で20時間を超えたのが1回、10時間を超えたのが1回、年の半分以上は残業ゼロという状況です。有給休暇もきっちり全部消化します。世間様が想像するプログラマライフから、
業務システムの再定義－閑話休題（３） (mark-wada blog)
役に立つためのシステムがもつべき要件 これまでビジネスの役に立たないシステムを作り続けたというようなことを書いたが、役にたたないシステムとはどんなものを指しているのだろうか。逆に役に立つシステムの要件とは一体何なのだろうか。 そこで一応つぎの3つを上げることにしている。 1．ビジネス要求をはじかないこと 2．とにかく安いこと 3．継続的な改善ができること 最初の「ビジネス要求をはじかないこと」というのは、こうしてほしい、こんな機能があるといいと言ったのにできあがったら実現できていなかったので使わないといったことがないようにという意味である。 ここには2つの問題があって、要求定義をしてもそれがどう実装されているのかを確認するのがずっと先になるということと、実現手段がないことがあるということである。実現手段がないならないと言わないといけないし、実現手段があったとしてもすぐに見せなくてはいけない
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
業務システムの再定義－まとめ（１） (mark-wada blog)
はてなブログ | 無料ブログを作成しよう