マガジンのカバー画像

溜池随想録

26
コンピュータソフトウェア協会(CSAJ)時代に書いたソフトウェアに関するエッセイです。
運営しているクリエイター

記事一覧

溜池随想録 #26 「ITと企業戦略の関係を考える(最終回)」 (2011年7月)

溜池随想録 #26 「ITと企業戦略の関係を考える(最終回)」 (2011年7月)

ITは重要ではないのか?

 2003年、米国では企業戦略におけるITの役割について大論争が巻き起こった。きっかけは、このコラムの第1回で取り上げたニコラス・G・カーの”IT Doesn’t Matter”という論文である。
 たとえば、ニューヨーク・タイムズ紙は5月中に2回、6月に1回この論文あるいはこの論文に関する論争を取り上げている。コンピュータワールドやインフォメーション・ウィークなどの業

もっとみる
溜池随想録 #25 「インターネットの衝撃」 (2011年6月)

溜池随想録 #25 「インターネットの衝撃」 (2011年6月)

インターネット技術の利用

 ダウンサイジングの次にやってきた大きな波がインターネットである。インターネットの歴史は1969年に運用が開始された米国防総省のARPANETに始まるが、商用利用が始まったのはそれから20年ほど経った1980年代末であり、企業経営に大きな影響をもたらすようになったのはさらに10年近く経った1990年代末である。

 きっかけの一つはマルチメディアに対応したブラウザ「モザ

もっとみる
溜池随想録 #24 「ダウンサイジングとオープンシステム化」 (2011年5月)

溜池随想録 #24 「ダウンサイジングとオープンシステム化」 (2011年5月)

ダウンサイジング

 企業におけるコンピュータ利用が、会計や給与計算のような計算を中心とする分野から、競争戦略に直結する情報処理分野へと拡大する一方で、コンピュータのダウンサイジングが進展した。

 情報処理におけるダウンサイジングとは、平易に言えば、大型汎用機をワークステーションやサーバーなどの小型で、コストパフォーマンスのよい機器に置き換え、コスト削減を図ることである。

 ダウンサイジングの

もっとみる
溜池随想録 #23 「SIS(戦略情報システム)」 (2011年4月)

溜池随想録 #23 「SIS(戦略情報システム)」 (2011年4月)

SISとは

 SIS(戦略情報システム、Strategic Information System)は、経営戦略や事業戦略の重要な役割を果たす情報システムであり、競合他社との差別化を図り、競争優位の源泉となる情報システムのことである。日本では1980年代後半から1990年代初めにかけてブームになった。

 おそらく最もよく知られているSISの成功事例は、このコラムの2月で紹介したアメリカン航空の座

もっとみる
溜池随想録 #22 「EDI」 (2011年3月)

溜池随想録 #22 「EDI」 (2011年3月)

EDIとは何か

 EDI(Electronic Data Interchange、電子データ交換)は、企業間の電子商取引の一形態である。一般的に「定型的なビジネス情報を標準フォーマットに従って異なる企業のコンピュータ間でやり取りすること」と定義されている。

 個人と企業の取引の場合、自動車や住宅のような高額な買い物を別にすれば、取り交わす書類は領収書程度であるが、企業間取引では注文書、納品書、

もっとみる
溜池随想録 #21 「オンライン・リアルタイム・システム」 (2011年2月)

溜池随想録 #21 「オンライン・リアルタイム・システム」 (2011年2月)

IBM System/360

 UNIVACに続いて、様々な企業が大型コンピュータ市場に参入した。主な企業を挙げれば、バロース、Scientific Data Systems (SDS)、CDC、GE、RCA、ハネウェル、そしてIBMである。
 このうちIBMは、1950年代後半に米国防総省の半自動式防空管制組織(SAGE:Semi Automatic Ground Environment)向け

もっとみる
溜池随想録 #20 「ITと企業経営(はじめに)」 (2011年1月)

溜池随想録 #20 「ITと企業経営(はじめに)」 (2011年1月)

世界初の電子計算機

 かつて、世界最初の電子計算機は、米国陸軍の弾道計算のために開発され、1946年に公開されたENIAC (Electronic Numerical Integrator and Computer)であるとされてきたが、現在では、1936年に試作機が公開され、1942年に完成したアタナソフ&ベリー・コンピュータ(ABC)であると説が通説になりつつある。

 実際、ENIACを開

もっとみる
溜池随想録 #19 「アジャイルソフトウェア開発に適した契約(その5)」 (2010年12月)

溜池随想録 #19 「アジャイルソフトウェア開発に適した契約(その5)」 (2010年12月)

契約で協力関係を作れるか

 契約は当事者間の意思表示の合致によって成立する。したがって契約書という書面がなくても、口頭による意思表示だけでも契約は成立する。たとえば、消費者の日常生活における購買行動に見られるように、「この商品を売ります」という売り手に対して、消費者が「この商品を買います」という意思表示をすることによって売買契約は成立する。

 しかし、金額の大きな取引や重要な取引の場合には、契

もっとみる
溜池随想録 #18 「アジャイルソフトウェア開発に適した契約(その4)」 (2010年11月)

溜池随想録 #18 「アジャイルソフトウェア開発に適した契約(その4)」 (2010年11月)

 引き続き、ピーター・スティーブンスの「あなたの次のアジャイルソフトウェアプロジェクトのための10の契約」(注)で取り上げられている契約を一つずつ検討していこう。
(注)Peter Stevens “10 Contracts for your next Agile Software Project” (http://agilesoftwaredevelopment.com/blog/peterst

もっとみる
溜池随想録 #17 「アジャイルソフトウェア開発に適した契約(その3)」 (2010年10月)

溜池随想録 #17 「アジャイルソフトウェア開発に適した契約(その3)」 (2010年10月)

 前回に引き続き、ピーター・スティーブンスの「あなたの次のアジャイルソフトウェアプロジェクトのための10の契約」(注)で取り上げられている契約を一つずつ検討していこう。
(注)Peter Stevens “10 Contracts for your next Agile Software Project” (http://agilesoftwaredevelopment.com/blog/pete

もっとみる
溜池随想録 #16 「アジャイルソフトウェア開発に適した契約(その2)」 (2010年9月)

溜池随想録 #16 「アジャイルソフトウェア開発に適した契約(その2)」 (2010年9月)

「10の契約」

 アジャイルソフトウェア開発に適した契約モデルについて、インターネット上で情報を探していたところ、ピーター・スティーブンスの「あなたの次のアジャイルソフトウェアプロジェクトのための10の契約」(注)という資料を見つけた(和訳もインターネット上で公開されている。http://htn.to/cdG2cz
 この「10の契約」は、米国における従来型の契約モデルも含まれており、すべてが

もっとみる
溜池随想録 #15 「アジャイルソフトウェア開発に適した契約(その1)」 (2010年8月)

溜池随想録 #15 「アジャイルソフトウェア開発に適した契約(その1)」 (2010年8月)

請負契約の限界

 一般的に情報システムの開発で用いられる契約は、準委任契約と請負契約である。経済産業省が2007年に公開したモデル取引・契約書<第一版>は、ウォーターフォール型開発を前提として、外部設計までは原則として準委任契約、内部設計からソフトウェアテストは請負契約、システムテストから運用・保守の段階は準委任契約を基本としている(図参照)。

 ただし、実態は外部設計からシステムテストまでを

もっとみる
溜池随想録 #14 「スクラム(Scrum)の概要」 (2010年7月)

溜池随想録 #14 「スクラム(Scrum)の概要」 (2010年7月)

スクラムの原点

 スクラム(Scrum)は、アジャイルソフトウェア開発の様々な手法の中で最もよく使われている手法である。米VersionOne社が2009年7月から11月にかけて実施した調査によれば、スクラムを使っていると答えた回答者が50%、スクラムとXPの組合せを使っていると答えた回答者が24%を占めている(図1参照)。<図1>
 このスクラムの語源は、ラグビーのスクラムであり、その原点は野

もっとみる
溜池随想録 #13 「XP(エクストリーム・プログラミング)その2」 (2010年6月)

溜池随想録 #13 「XP(エクストリーム・プログラミング)その2」 (2010年6月)

XPのプラクティス(続き)

 今回は、前回に引き続きXPのプラクティスを紹介する。


(7) 小さなリリース(Small Releases)
 システムが一部でも動く段階になれば、すぐに発注者に引渡しを行う。XPではこうしたリリースを小規模に何度も繰り返す。ウォータフォールモデルでは最終段階にならないとシステムの引渡しを行わないために、終盤になって要求仕様の誤りが発見されてプロジェクトが火を

もっとみる