真髄を語る 経営者がITを理解できない本当の理由
佐藤正史 氏 JTB情報システム 代表取締役社長 当サイトにおいて、企業情報システムにかかわってきたベテランが引退する、いわゆる「2007年問題」について色々な議論がされております。私は1971年にJTBに入社して以来、ほぼ一貫して情報システムの仕事に従事してきました。私が情報システムに関係してきた期間は、日本における約40年の企業情報システムの歴史と概ね重なっております。 2001年から取締役（情報システム担当）として、CIO（最高情報責任者）の仕事をし、現在はJTBの情報システム関連会社の社長を務めています。おそらく、あと数年で2007年問題の一方の主役として、この舞台を去ることになるでしょう。まもなく企業人生を終えようとする一介のシステム屋ではありますが、ぜひとも多くの方に申し上げたいことがあり、この場を借りて思うところを綴ってみます。 私は今、日本のITを巡る状況に大変な危機感
CNET Japan Blog - 江島健太郎 / Kenn's Clairvoyance：SaaS時代のベンチャー経営に求められる情報システムとは
現在発売中の月刊ComputerWorld10月号のSaaS特集に、著者の一人として寄稿しました。 「『サーバのないオフィス』でイノベーションを実感する」と題して全8ページ、渾身の記事です。 SaaSという言葉は、これまた例によって定義の広すぎるコトバですが、いわんとすることはソフトウェアを買ってきてインストールして使うというモデルからウェブ上にあるサービスをそのままブラウザ上でソフトウェア的に使うようになりますよー、という意味ですから、これまでの外しまくりな業界のバズワードに比べればリアルなトレンドをはるかにうまく捉えています。イメージ的にはWeb 2.0とも若干かぶるのですが、SaaSはどちらかというと「従来のガチなソフト屋から見たウェブへの進化願望」みたいな気分が表れたコトバだと理解しておけば間違いありません。（現にピュアでネイティブなウェブ界隈でSaaSというコトバが会話に出てくる
過剰品質の美学 : 小野和俊のブログ
レクサスは半ドアでも走行中に自動でドアがスーっと閉まる。 スーパーで売られている卵は保存が良いように尖った方が下に揃えられているし、パックの中身を確認しなくても、卵が抜けたり割れたりしていることはほとんどない。伊勢丹では販売員は売場をお買場と呼び、コンビニでは弁当の胡麻の数までチェックの対象になる。箱ティッシュには指を入れやすいように小さなミシン目がついており、トイレに行けばウォシュレットがある。 求められている品質を満たすのではなく、 求められていない品質を目指す。 それが過剰品質の美学である。 そしてそれがITの遅れの象徴であるかのように指摘する人もいる。 しかし一方で、 自分たちはオーダーメイドという最高の過剰品質を提供しているのだと誇る声も聞こえてくる。 私はパッケージ製品を開発している立場の人間であり、 オーダーメイドのための最高の部品を提供することが私の目指すところだ。 知人で
JavaScriptデバッグツール集:phpspot開発日誌
Ajax Digest // Javascript debuggers overview JavaScript debugging has some specifics in comparison with stand-alone applications. JavaScript programs usually rely on interaction with the loaded page's Document Object Model (DOM) so errors may be caused by wrong DOM usage in a technically correct script. JavaScriptデバッグツール集。 様々なJavaScriptデバッグツールが紹介されてます。 （Microsoft Script Debugger) IE上で動作するもの Micros
第11回 プログラマが知らない，デザイナーの苦労
今回は，デザイナーとして，世間やプログラマに対して言いたい放題書かせてもらう。どうか怒らずに最後まで読んでもらいたい。デザイナーの皆さんには，大いに賛同していただける内容になっているはずだ。 デザイナーだって，タイヘンなんだ！ まず，デザイナーという仕事は，非常に誤解されやすい。例えば次のような誤解をうけて，暗い気持ちで日々の作業をこなしているデザイナーも少なからずいるはずだ。 1) デザイナーという職種に対する，先入観がある 世間（顧客やエンドユーザー）には，「すべてのデザイナー」＝「技術に無知」だという先入観がある。「デザイナー」とは「Webページの配色とレイアウトをする人」だから技術を知らなくて当然，むしろ知らなくてよいとする傾向すらある。開発ツールが完全分業に向けて進化しているのだから，デザイナーはビジュアル・デザインのことだけ考えていればいいという意見を持っている人もいるだろう。
パッケージソフトは、コストが高いのよ。ダウンロードにしてもコスト０じゃないのよ！！ - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） ウサギと亀の共通項が見えますか？ 「特殊への執着」が日本のソフトを弱くする http://it.nikkei.co.jp/business/news/index.aspx?n=MMITzv000018082006 について、批判されているようだが、その批判はさておき、いくらなんでも、これは・・・ と思う言葉がある。今回は、そこを問題にしたい。 それは （以下、斜体は上記IT+PLUSの記事より引用） ソフトウエア製品の複製は材料費と手間費と流通費がほとんどかかりません。普遍性が高く適用範囲の広いソフトウエアがあれば、膨大な利益を手にすることが可能です。 これが、真っ赤なうそだっていうことは誰でも知ってるだろう。 もし、本当ならＬｉｎｕｘのディストリビューターは、大もうけだ。 なの
在庫引当から在庫推移へ（前編） - 設計者の発言
在庫管理分野でのデータ項目として「有効在庫（利用可能在庫）」と呼ばれるものがある。現在庫数量から「直近の出荷予定数量」を差し引いて得られる値を、事実上利用可能な在庫数量とみなして管理する。現在庫には直近の出荷予定が「引当」されていると考えるわけだ。式で表せば次のようになる。 有効在庫数量＝現在庫数量－Σ(直近の出庫予定数量) 現在庫が１００個だとして、直近での出荷予定が合計７０個だとすれば、有効在庫は３０個である。この時点で５０個の注文があったとする。有効在庫が３０個であることを知っていれば、すぐに出荷できる分３０個と、将来の入荷後に出荷できる分２０個とを分けて受注するといった事前の交渉が可能だ。いっぽう有効在庫を認識していないとすれば、すぐに出荷できる受注として５０個分をひとまとまりとして受け付けてしまうだろう。結果的に、出荷時点で欠品に気づいてあわてるハメになる。 在庫数量が規定レベル
CNET Japan Blog - 江島健太郎 - Kenn's Clairvoyance：レグレッション・テストに逆ギレ
どうも更新が滞りがちですが、いよいよ新サービスのリリース・カウントダウンが始まりました。寝ても覚めても開発とバグ取りにいそしむ中毒状態で、メールにさえろくに返事ができておらず、ゴメンなさい！いましばらくご辛抱下さい！ 近況としては、IRS（米国税局）から「キミはちゃんと確定申告を期日までに行わなかったからペナルティじゃ」という、折り目正しくきちんと納税した人間に対してありえない通告があったので、先方が真っ先に小切手を振り出した記録をこれでもかと全部コピーして送りつけて、お前たちはドロボーかと詰問して謝罪をとりつけたり、相棒のダニーが唐突に投票権を持つ米国民の義務であるJury Duty（陪審員義務）に駆り出されて一週間まるまる留守になったり、歯医者に行ってチェックアップしてもらったら$800/月もの医療保険に加入しているにもかかわらず$4,000という高額な治療費の見積もりをもらって開いた
勉強が出来ない奴はプログラマになれ！（バカだからできる勉強法） - IT戦記
どのくらいの人がこのブログを読んでいるか分かりませんが、 もし、勉強が出来ない人が周りにいたら、このブログを紹介してあげてください。 ふと 勉強が出来ない人は、プログラマになったほうがいいと思った。 僕はというと 自分でも驚くくらい勉強というものが出来ない。ものごとを知らない。 はっきり言ってバカなのである。 たとえば、 大学行ってない。 株式公開と上場の違いを知らなくて、一同ぽかーん。 つい最近まで、サイバーエージェントを知らなかった。（技術者には必要ない） 英語が一切読めない。 宮崎料理「冷や汁」を「冷や飯」だと思ってた。 基本的に会議とかでよく出る英語、「さじぇっしょん」とか、「あさいん」とか、「ぶらんでぃんぐ」とか、「うぇぶつーぽいんとおー」とか、よく分からん。 人力（じんりき）検索を入力（にゅうりょく）検索だと思っていた たぶん、まだまだあるけど、自分がバカだから気がつかないんだ
上流設計 - essence-s
会場が会社の近くだったのもあって、行ってきました「上流設計セミナー」。 またまた、いろいろ刺激になった。 どろくさいケーススタディがおもしろいですねー。 とりあえずキーワード。注釈はあとで。 経営戦略と施策からITへの要求定義への関連づけを見える化 要求が迷子のスキーヤーになる現象に注意 ITが目的のターミナル駅になる現象に注意 カスタムメイドではなくレディーメイドの準備 仕様変更は変更でないかもしれない→はっきりしただけで変更ではない。 そもそも、きっちり決める事できるんだっけ？ Asisならできるかもでも作る意味はない。ToBeの要求をどうしたらいいのか。 結局反復をちゃんとやろうよ。 ユーザーの要求粒度がまちまちなので既存のインフォメーションモデルはなりたたない ユーザーの要求粒度によって判断してはいけない 要件確定時ぬけおちる情報に変更可能性が隠れている 量の絶対値ではなく量の変化
仙石浩明の日記 「ソフトウェア開発」は「モノ作り」ではない
いつのころからか、 ソフトウェア開発がモノ作りに喩えられるようになった。 典型的なのは、製造業(例えば自動車製造)と IT 業界とを比較して、 前者が高度にシステム化されているのに対し、 後者がまるで家内制手工業のようだ、という批判である。 日経ビジネス online の記事に次のようなくだりがあった: 「というより、何といいますか、経営トップからすると、 ITはとにかく非常識な世界だ、としか思えないのではないかなあ。 例えば大きなシステム開発プロジェクトに取り組むと、 すぐ100億円を投資する、という話になってしまう。 100億円の経常利益を出そうと思ったら本当に大変。 ところが、100億円を投じたのに、期限までに完成しない、 出来上がってきたものが当初計画と違う、 直そうとするとさらに金がかかる。 こんなことが起きるわけですから、『一体なぜなんだ』と経営トップは思うわけです」 IT業界
「復活」果たしたITサービス業界がこの5年間で失ったもの：ITpro
法人向けのITサービスを提供するソリューションプロバイダが，久しぶりの業績回復を果たしている。 2002年2月から続く日本の景気拡大局面は，4年6ヵ月目に入り，継続期間では戦後2番目の記録を更新中だ。その中で，ずっと景気回復の波に乗り損なっていたのがITサービス業界だった。 しかし，主要ソリューションプロバイダ各社の2005年度決算（2006年3月までの1年間に迎えた決算を指す）は，「4年ぶりの復活」と呼べるような好調さを取り戻した。日経ソリューションビジネス誌が，売上高100億円以上のソリューションプロバイダを対象に毎年まとめている業績調査から，この5年ほどの動向を紹介しよう。 「業界の縮退」と「利益なき繁忙」の4年間 まず，2000年に起ったITバブル崩壊を受け，ITサービス企業の業績に陰りが見えたのが2001年度のことだった。当時の調査対象企業150社で見ると，平均の売上高伸び率はプ
複雑な条件を文章で書くべからず ― ＠IT自分戦略研究所
コミュニケーションスキルの土台となる図解言語。だが筆者によると、実はその裏に隠れた読解力、国語力こそがITエンジニアにとって重要なのだという。ITエンジニアに必須の国語力とはどのようなものだろうか。それを身に付けるにはどうしたらいいのか。毎回、ITエンジニアに身近な例を挙げて解説する。 ■実務的な国語力が必要とされている 前回「メタ情報とサマリーで『伝わる』ビジネス文」に引き続き、典型的な失敗のパターンから実務的な国語力を身に付けよう。 前回の記事で「こんな説明では分からない」10種類の失敗パターンを列挙した。以下のようなものである。 （1）メタ情報の欠落 （2）要点の分からない見出し （3）複雑な条件の文章表現 （4）分類を表さない名前 （5）過剰な言い換え （6）対称性のない表現 （7）指示代名詞の多用 （8）相互関連の分からない個条書き （9）時系列の乱れ （10）語感と実感のミスマ
Webデザイン エンジニアリング 第16回 ボタンを押させるテクニック：ITpro
対象とするユーザーの“慣れや知識”によって，画面の構成を変えたほうが伝わりやすいとするならば，画面上の「ユーザー・インタフェース（UI）部品」の色や形状も，ユーザーに応じて変えるべきでしょう。今回は，代表的なUI部品でありながら，なかなか作り手の思うように押してくれない「ボタン」について考えます。 わかりやすいボタンの形状はユーザーによって違う まず，前回とほぼ同じ絵を用います。Webシステムの操作方法への「熟知度（PCリテラシ）」を縦軸，「提供したいサービスに対する知識」を横軸とします。そして，それぞれの「軸」に対して，受け入れやすいと思われる「ボタン」の形状を例記しました。 上図の【A】や【B】のタイプに当てはまるPCリテラシの高いユーザーは，ボタンの“ラベル”に「submit」と書かれていようが「GO」と書かれていようが，ボタンを認識することはさほど苦ではありません。 しかし，PCに
Matzにっき(2006-07-11)
<< 2006/07/ 1 1. ミッフィー展 2. 弟家族 3. 冷蔵庫 2 1. 第一日曜日 3 1. [Ruby] Ruby on Railsトレーニング 2. 風邪 3. 地上波デジタル 4. [Ruby] るびま原稿 5. [Ruby] Web 2.0の挑戦者:プログラマフレンドリーなバグトラッキングシステム16bugs 4 1. [Ruby] トレーニング2日目 2. 六本木ヒルズ 3. [Ruby] Award on Rails 4. W-ZERO3[es] 5 1. 帰宅、校正 2. [Ruby] 「ブレイク直前のLinux」を思い起こさせるRubyのマグマ 6 1. [原稿] 『たのしいRuby』前書き 2. 「かわいそう」 7 1. 歯医者 2. Pickaxe2校正 3. 『情報処理』 4. [知財] Open Tech Press | 知的財産推進計画2006によせ
40歳前後の技術者が不足！ そこからITサービス業界の事情を読む
最近、ある証券アナリストの人から、「ITサービス会社の年齢別の人員構成に着目すると、いろんなことが見えてくる」という話を聞いた。特に興味深かったのは、38～42歳の人員に凹みがあるITサービス会社が多く、プロジェクト・マネジャー不足の懸念があるというくだり。では、何故その世代の人員が少ないのか。その話を聞いて、私はピンと来るものがあった。 この世代の技術者が少ない理由を、彼らの新卒採用時にまで遡る必要はあるまい。15年前の1991年が「ダウンサイジング元年」で、オープン系への流れが加速するのはそれ以降の話なので、彼らの採用されたのは、まだ平和な“メインフレームの時代”だ。それよりも直近、ユーザー企業がIT投資額を抑制し、「ITデフレだ、オフショアだ」と騒いでいたころの出来事の影響の方が大きいだろう。 その頃、彼らの年齢はちょうど30歳台後半に収まる。そこで思い出されるのは、ITサービス業界
オフシェア開発の先としての自動生成を考える必要性が早まった？最近の国際情勢で！！ - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） 日経コンピューター２００６年７月１０日号Ｐ１８に オフシェア開発、大型案件に浸透 ”今欲しい”技術者確保に向け、発注量は前年度比２割増へ っていう記事があります。 オフシェア開発に大手さんは、大々的には向かっているようですけど、 でも、ここで、オフシェアの比重を増やしてコストダウンなんてことで、 安穏としていたら、次のコーナー回ったところで、時代遅れ、業績急低下！ になっちゃいそーですよねー（＾＾） なぜか、理由は２つ！ １つは、オフシェアの単価を、 国内の（北海道など）地方で経済がぼろぼろに崩壊してしまった地域の人件費と 比べると、そんなに差がなくなりつつある、 いや、将来的には逆転すらありえそうなこと。 上記の記事中にも、オフシェア開発の人件費が「単価４０万前後と」とあります
再利用共有 (Snipplr.com) | 100SHIKI
プログラミングをやっていると、昔のコード部品を再利用する場面が多い。 そう考えるとSnipplrのようなサイトは便利だ。 このサイトではプログラム全体のコードというよりも、コードの一部を投稿して共有することができる。また共有しないまでも、自分のコード部品を管理するサイトとして便利だろう。 コードにはタグもつけられるので見つけるのも簡単だろうし、似たようなコードを探すことも容易だ。また「お気に入り」機能などもあるので、自分と似たようなプログラムを書いている仲間を探すこともできるのかもしれない。 コードに限らず、再利用できる部品を共有できるといいことがありそうですね。
儲からないSIから“逃走”する企業とSIで儲ける企業のコントラスト
SIは儲からない。だから、ビジネスの軸をパッケージソフト販売や運用サービスに変える必要がある----これは、ITサービス会社のビジネスモデル変革の公式と言ってよいだろう。富士通の黒川社長も経営戦略説明会などの場で、よくそんな説明をしているらしい。そのココロは「できるだけ作らない」である。だが、トラディショナルな受託ソフト開発会社で高い利益率を上げる企業もある。さて、その辺りのことを、どう考えるべきか。 ITサービスのビジネスのプロセス順に、パッケージ販売、SI、運用サービスを横に並べ、縦軸に利益率をとると“ITサービスのスマイルカーブ”が描ける。なんのことかと言うと、両端のパッケージ販売と運用サービスは利益率が高く、真ん中のSIは利益率が低いので、曲線で結べば、スマイルマークの口元のラインのようになる。 富士通なんかは、ITサービス事業の収益力向上策の説明でこの図を使う。儲からないSIの比
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Rough Consensus, Running Code