―貴方の著書『キャズム』（原題：Crossing the Chasm）ライフサイクル イノベーション』（原題：Dealing with Darwin）は、日本でも良く読まれ、「キャズムを超える」という表現は、キーワードとして定着した感があります。現在のエンタープライズITの事情をどのようにご覧になられているか、お聞かせ下さい。 日本で私の本が読まれたことは非常に光栄です。現在でも、エンタープライズITのトレンドには非常に関心があります。大きくは、仮想化、SaaS、SOAといった領域です。これらの技術を私は2つの方向性でとらえています。 一つは、過去のレガシー資産を統合（Consolidate）する方向性、もう一つは統合した資産をプラットフォーム化する方向性です。レガシー統合の方向性で注目してきたのは、データセンターの仮想化とSOAです。 データセンターのサーバー運用は、すでに成熟段階にあり

印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます この連載の始めでは、「晩飯作り」を例に挙げ、「プロセス志向」を導入することによってものの見方がどう変わるかを確かめてみた。今回は、もう少し業務、あるいは企業全体のビジネスという視点から、プロセス志向、プロセスの見える化のメリットについて考えてみることにしよう。 改めて「ビジネスプロセス」って何なの？ ここで、これまであまり明確に意識せずにきた「ビジネスプロセス」について触れておきたい。その定義をちょっと難しく言うなら、企業内で営まれている「ある目的を達成するために行う活動の連鎖」ということになる。具体的な例で、その意味するところを確認していこう。 たとえば、請求書を郵便で取引先に送る「郵送プロセス」を想定してみる。流れは図1のようになっ

2006年2月期、吉野家ディー・アンド・シーは牛丼なしで黒字転換を成し遂げた。 当初は新メニューのオペレーションをこなし切れずに店舗が大混乱に陥る。 それでも営業を続けられたのは経営への信頼と現場の実行力があったからだ。 牛丼の吉野家から、牛丼も売るメニューミックスの吉野家への進化を追った。 （文中敬称略）<日経情報ストラテジー 2007年3月号掲載> プロジェクトの概要 2003年末、米国でBSE（牛海綿状脳症）感染牛が見つかり、日本政府は米国産牛肉の輸入を停止した。全国の約1000店で牛丼を販売する吉野家ディー・アンド・シーは使用する牛肉の99％を米国からの輸入に頼っており、米国産牛肉の在庫が尽きる2004年2月に牛丼の販売を休止せざるを得なくなった。米国産以外の牛肉では吉野家の牛丼の味と品質を再現できず、かつ1000店規模で必要になる牛肉を新たに調達できないと判断したためだ。 それか

祖母の白寿のお祝い 先日、満99歳(数えで100歳)になった祖母の白寿のお祝いをやった。 さすがに身体のあちこちに不具合が出てきており、そろそろ本格的に外出も難しくなってきたので祖母と一緒に家族で集まれるのはたぶんこれが最後だろう。 下は0歳から上は99歳までいるので、移動と諸々…

IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.

IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.

20年前くらいに、つまりCASEツールが流行したころ、SA/SDなり、データ中心アプーロチを啓蒙しましたが、やってみて、ジャクソンクラッシュなり、いくつか欠陥を発見され、多くの方のように、OOA/OODに転向しました。 その際に、オブジェクトの旗をふっていた会社で、データ中心アプーロチについて、レクチャーし、採用を進める身になるとは、なんとももはやグンニョリ。 10年前くらいRDBの生みの親である会社に、RDBについて説明して以来のグンニョリ感。 なんか欠陥商品を売りつけているようで(ようではなく欠陥商品だと思っている)、腰が引けているのですが、ソフトウェアエンジニアリングの下地がないところには、導入しやすいのは、20年前と変わりません。 しかし、ちょっと調べてみると、ERDとDFDを併用する、いわゆる堀内式データ中心アプーロチは、浸透していなくて、ERDはERD、DFDはDFDと書いてい

画面設計とか外部設計とか、もうやめようよに対し色々意見をいただいた。感謝。 要点繰り返し 自分は「画面の見本を使ってフィーチャを抽出する」というやり方に反対はしてない。 ただし、その「見本」が妙に具体的かつ詳細になってくると、本来フィーチャではないものまでフィーチャとして取り出してしまい、後続の工数が膨れちゃうよ、ということを警告しているのである。 「妙に具体的かつ詳細な見本」ってのは、世の人がいう「画面設計書」でしょ？ なのでそんなのはやめちゃえ、ということ。 以下、頂いた意見に対しての感想などを。 家やマンションに例えない 「家やマンションは最初に完成像をみてもらい納得してもらう必要がある。システム開発も同じだ。」みたいな意見があった。 画面の見本があれば完成像を想像しやすくはなるけど、実際に動く見本があれば想像する必要はなくなる。 むしろ、操作することで「紙芝居」ではわからなかった要

昨日は特徴(Feature)、粗筋(Story)、脚本(Scenario)でちょいと言及した「Feature, Story, Scenarioがごっちゃになりかけている」プロジェクトの人達とお話しする機会があった。 よくよく見ると、FeatureとFunctionとがごっちゃになっていた。 つまり、要件分析の段階で実装のことを考えていたのである。 なぜ、そうなったのだろう？ 画面から要件分析をすると、こうなる どうやら要件分析する前の段階で「コンサルタント」の人達が、画面を使ってお客さんと「要件定義」をしていたらしい。 「この画面でこういうデータを入力すると、こんな画面に遷移します」みたいなやりとりがあったのだろう。 紙芝居感覚で交渉できるからわかりやすい。 だけど、先に画面を決めちゃうというのはいくつかの(そして時に致命的な)問題を抱えている。 実装をフィーチャとして捉える可能性。 例え

気になる記事をスクラップできます。保存した記事は、マイページでスマホ、タブレットからでもご確認頂けます。※会員限定 無料会員登録 詳細 ｜ ログイン

IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.

厳しい時にこそ、積極的な攻めの姿勢が必要 先行きが見通しにくい経済環境になってきています。このような厳しいビジネス環境ですから、お客様の判断で商談がいきなり無くなることも珍しくなくなってきました。導入を決めたお客様も、導入範囲や初期投資を最小限に控える傾向にあります。 既に、企業のIT投資も前年対比ベースの予算策定が許される状況ではなくなっています。現行システムの維持運用費用の削減が強く求められるとともに、新規投資は業務遂行に必要不可欠なものに限って認めるという声が多くなってきました。 こうした企業のシステム投資計画を見越して、ITベンダーの大半は来年度の活動方針のキーワードを「コスト削減」にしようと考えています。この方針自体は間違っていないと思いますが、今回のような100年に一度と言われる未曾有の経済危機をコスト削減だけでは生き残れるようには思えません。業務効率を大幅に向上し、高度な情報