メモ。 志の高い人を雇いたがるのは、志の高い企業のするべきことなのだろうか。志の高い企業は、ふつうの志の人を雇い、高い志を持たせるような企業ではないだろうか。あるいは、ふつうの志の人を雇い、ふつうの志のまま、よい仕事をさせるような企業ではないだろうか。 優れた人を雇いたがるのはよいことなのだろうか。それは極論すれば、優れていないひとはどうでもいい、ということなのではないか？　そのような企業で働きたいと思うだろうか？　そのような企業で働きたいと思う人ばかりの社会で生きていたいと思えるだろうか？ ふつうの人が9時から6時まで（または10時から7時まで）、ふつうにプログラムを書いていればふつうに生活ができる、という世界の実現は困難なのだろうか。 今のソフトウェアエンジニアリングはふつうの人に辛すぎる。ここで言う「ふつうのひと」とは、たとえば「基本的に自分で本を買わない」「就業時間以外はプログラム

del.icio.us/tag/del.icio.usを眺めていたらFlickrのときみたいに面白い資料を見つけたの紹介します。 Things to look out for when building a large application.というタイトルでサーバーサイドの管理等の話が中心かと思って読んでいたらそれ以外のインターフェース、実装すべき機能、spam対策、アプリケーションを如何に広めるかといった話にも触れていて面白いです。 以下にまとめてみました。 スケーリング 早期の最適化を避ける。SQLでスケーリングするのではなく、データを複数マシンに分散させる方法を考慮すべき。SQLプロファイリング重要。Nagiosがお勧め。 タグはSQLと相性がよくない。インデックシングの仕組みを理解し、その方針を決定する。最初の数ページに限定すれば小規模で高速なインデックスを保てる。 Apache

オブジェクト指向開発を行えば、保守性・拡張性が良くなるといわれますが、本当にそうなのでしょうか？ 第1回「保守性と拡張性の定義」では、現状のシステム開発の問題点を指摘し、そのうえで、そもそも保守性・拡張性とはどのようなものなのかを説明しました。今回は、拡張性・保守性を高めるための重要な考え方について解説をしていきます。 オブジェクト指向による問題の解決 前回「ソフトウェアにおける保守性と拡張性の定義」は「機能分割」のような従来型の開発手法における問題点を指摘しました。今回はこれらの問題をオブジェクト指向ではどのように考えるのか、また、どうすればこのような問題を解決できるのかについてお話ししたいと思います。 ［1］ 下流工程における複雑さの解決についての考え方 （1）クラスって何だろう 最初にクラスとはどのようなものか考えてみましょう。オブジェクト指向では、必ず出てくるクラスとはどのようなも

Get a free logo with your purchase of MOGUSA.COM We have a 90%+ satisfaction rate from our customers

前回のエントリーの追記です。 抜本的改良は手遅れな東京証券取引所システム〜問われる技術立国日本の脆弱性 http://d.hatena.ne.jp/kibashiri/20060120 ●耐用期限過ぎていた東証システム 今日（２２日）の朝日新聞速報記事から・・・ 東証システム、耐用期限過ぎていた　導入は１０年前 東京証券取引所の異例の全株式売買停止を招いた清算システムは、約１０年前に導入したコンピューターを使い、当初の耐用期限は０４年後半だったことが分かった。東証は２３日からは現行システムでの能力増強、３０日には予定されていた新コンピューターによる次期システム移行でしのぐ方針だが、綱渡りの状況は続く。 東証の取引システムは売買と清算に分かれ、今回問題になったのは清算だった。 東証決済管理部によると、現行システムのコンピューターは日立製作所の大型汎用機（メーンフレーム）で、独自開発のソフトを

●実は手遅れな東京証券取引所のシステム処理能力拡大策 東証の社長が株式売買システムの約定処理能力について「1日当たり700万件以上に引き上げたい」との意向を表明したそうです。 【東証問題】「約定能力を700万件以上に引き上げたい」、西室社長兼会長が表明 東京証券取引所の西室泰三社長兼会長は1月19日、株式売買システムの約定処理能力について「1日当たり700万件以上に引き上げたい」との意向を表明した。現在のシステムでは、1日当たり450万件が限界。1月30日のシステム刷新で約定処理能力を500万件まで拡大するが、さらなるシステム拡張をしたいとの考えを示した。 東証は1月18日、ライブドアの強制捜査開始による影響で約定件数がシステムの限界に迫り、午後2時40分に東証1部・2部・マザーズ市場の全銘柄の取引を強制的に停止した（関連記事1、関連記事2）。当日の会見で、東証は「年内にも1日の注文処理能

Rubyをはじめとするスクリプト言語ではなく、なぜJavaを選ぶのか。 そして、XPをはじめとするアジャイル開発ではなく、なぜウォーターフォールを選ぶのか。 そこには、言語の良し悪しや、開発プロセスの考え方などが理由の中心にあるわけではなくて、SIerというビジネスの仕事の仕方（ビジネスモデル）に起因している。 RubyやXPは、考え方や技術としてはとても良くて、生産性もあがるし、何よりもソフトウェアをクリエイティブに作り上げることができ、利用者にとっても使い勝手がよく、スポンサー（経営者）にとっても経営戦略に沿ったものが手に入り、開発者にとっては何よりも仕事に対してやりがいを感じることができる。すばらしい！・・・・が。。。 しかし、だからといって、誰でもRubyやXPを使って開発をするべきか、というとそうではない。もし、本質を理解しない誰かが、「やってみたいのだが・・・」と相談に来たら、

ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） さて、お正月気分も今日で終わりということで、お正月気分のお遊びのしめくくりとして、 ウィリアムのいたずらによる、今年ありえそうなものの予言でも。 （無責任にテキトーなことを書いてます。はい。本気にしないでね（＾＾；）） ■■　（１）脳力トレーナーのケータイ版、AJAX版とかでる あれ、出てたっけ？？よくわかんないけど。。 最近、脳を鍛えるやつ、はやってますよね。セガでも、任天堂でもあるよね。 でも、あれって、ソフト的には、足し算引き算とかなわけでしょ。 iアプリでもBREWでも、AJAXでもできるよね。 ということで、iアプリでもBREWはメーカーから出してもおかしくない。 AJAXは、誰かが酔狂で作ってもおかしくない。 ■■　（２）ケータイ端末、アプリで社内システムを開発しよう

前のエントリid:mkusunok:20051224:carrierについて、id:fromdusktildawnさんから素晴らしいコメントをいただいた。考えてみると昨今IT業界で元気がいいのはApple, Google, AmazonといったB2C企業や、OracleやSAPといったB2Bでもパッケージ製品を多数の企業に展開している企業である。日本をみてもプロ野球に名乗りを上げたYahoo!、楽天、Livedoorいずれも大量の顧客に対しサービスを提供している。*1パッケージソフトウェアに強いジャストシステムやOBCも、同様に無数の小さな顧客をたくさん持っているといえるだろう。*2 少数の大きな顧客と取引するから、その顧客と力関係で負けて、おいしくなくなりがちなのであって、無数の小さな顧客をたくさんもてば、それは土方的でなくなるという指摘は、受託開発よりもパッケージや販売といった製品ビジ

ぼくはIT業界の中で技術者からマーケティングに移った人間で、最初こそ張り切ってコトラーとか読んだけど、外資系企業で日本法人にいて3Cとか分析しても4Pのどれも殆ど触れないことに気づいて、これじゃマーケティング戦略の勉強にはならないなぁと感じて途中から技術渉外っぽい仕事に路線変更した。*1技術渉外というのも一風変わった仕事で、似たような仕事があるといっても非常に限られているだろうし、日本企業のそういった部署で中途は採ることは少ないだろうから、日々潰しが利かなくなっているのではないかという不安はある。けれどもまぁ、英語とか段取りとか、自分の苦手なところを鍛えつつ、少し突き放して業界の仕組みを眺める居場所としては面白い。 どこかでいざとなったら技術者に戻れるという気持ちもあって、Virtual PCでLinuxとかの環境はつくっているし、手元の環境には一通りのコンパイラは入れているし、研究所でつ

本連載は、メタボリックスの山田正樹氏が、仕事の合間に読む数冊の書籍に刺激を受けて思考した過程やその結果を記述したものである。参考にするのは必ずしもソフトウェア工学に関わる書籍ではないかもしれないが、いずれその思考の軌跡はソフトウェア工学的な輪郭を帯びることになる。（＠IT編集部） 生産性向上のメカニズム ソフトウェア開発における「生産性」とは何か。厳密に定義するのは難しい。生産性とは基本的には「あるアウトプットを得るのにどれだけのコストをかけたか」という尺度だ。さすがに「アウトプット」をソース・コード行数で測っても無駄だという認識は広まってきたと思うが、じゃあ代わりに何を使えばいいのかはいまだにはっきりしない。ユースケースやストーリーで測る考え方もある。そんなものは存在しないという意見すらある。 そういう場合には視点を1レベル上げて考えてみよう。つまり、ソフトウェア開発だけ考えているから分

本連載は、オブジェクト指向言語（Java言語など）の経験がある方に、オブジェクト指向における分析設計の流れ・考え方を理解していただくことにより、少しでも現状の改善に役立てられることを目標としています。 一般的に、オブジェクト指向を使うと、保守性・拡張性に優れたシステムが作れるといわれています。しかし、実際には、「オブジェクト指向を使った開発手法のどの部分が保守性・拡張性に貢献するのか分かりにくい」というのが実情ではないでしょうか。この連載では、システム開発における分析から実装の中でも、特に保守性・拡張性の視点から重要なポイントをピックアップして、説明していきたいと思います。 連載第1回は、まず、現状のシステム開発（ビジネス・アプリケーション）における分析設計手法の問題点を整理し、変更性・拡張性の重要性と定義を説明したいと思います。 現状のシステム開発における問題点 ビジネスアプリケーション

ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） ジェイコムショックの件、スラッシュドットで、なんか、みんな解説してるようですが、すぱっと説明してないので、よくわかんないですよね。つーか、誤解もあるし。。 っていうので、ちょっと、書いておきますね。 （ほんとうは、これで問題になりそうなケースと対策を書きたかったけど、そこまで書く余裕がなくなったので、今回は、説明まで） で、問題の スラッシュドットの記事は、こちら http://slashdot.jp/articles/05/12/11/1448250.shtml 東証の説明はこちら　http://www.tse.or.jp/news/200512/051211_a.html ■■　前提知識 （１）株の売買には、値幅制限（ストップ安、ストップ高）というのがあります。 これは、前日

いま仕事でバンガロールにいる。インド人というのは本当に25x25くらいまで覚えているらしく、インド人のツアコンの前で1万円札を両替したら、いきなり1の位まで5桁の割り算を暗算されて、びっくりした。この調子なら、32bitや64bitの2進、10進、16進の変換なんざ一瞬であろうし、さぞ素晴らしいプログラムを書いてくれるのではないか、と期待が沸いてくる。にしても、話し始めると止まらないし、妙に聞き取りにくい英語を話す人々なので、口から生まれてきたのではないかと評されがちな私でさえ、あまり長丁場の議論はしたくない。理詰めで延々と議論が続くものだから、曖昧な仕様書を渡そうものなら、きっと著しく生産性が下がるに違いない。仕様のはっきりしているカーネルやプロトコルスタックとか、機能のはっきりしたミドルウェアとか、いまあるソフトの最適化は頼みたいけれども、業務システムとかユーザー・インターフェースとか

混乱するプロジェクトを1から10までガチガチに管理するのではなく、うまくいくようにそっと手を貸してやること。そんな発想の転換が実はいまどきのプロジェクトを上手に運営するコツなのかもしれない。本連載では「自己組織化」という概念をプロジェクト運営に応用するノウハウをお伝えする。（＠IT編集部） 1. プロローグ～大火事プロジェクトの火消し役が計画した、あるひそかな実験 昨年、火が付いたプロジェクトに火消しマネージャとして参画することになりました。チームメンバーは連日の徹夜で疲弊し切っていました。マネージャ陣との信頼関係すら怪しい状況でした。クライアントからは怒声が飛び、連日のように詳細な進ちょく状況報告を求められます。報告作業自体が開発スケジュールを圧迫していました。データベースのテーブル定義でもめている段階なのにもかかわらず、カットオーバー予定日は目前に迫っていました。タフな判断と徹夜の作業

図2●東証とシステム関連ベンダーの関係<BR>東証は2002年2月、東証コンピュータシステムの株式65％を譲渡。これを2004年9月に、富士ソフトABCが取得している 東京証券取引所で11月1日に発生したシステムダウンの根本的な原因は、運用体制の不備にあった。本来はシステムの本番機に触れない開発ベンダーである富士通が、東証が許可したとはいえ本番機上でバグを修整するなど、「あってはならない」運用がまかり通っていた。 東証におけるシステム障害の直接原因は、富士通が作成した手順書の記載ミスによるロード・モジュールの登録漏れ、つまり人的ミスである。だが、問題の本質は「手順書の記載ミス」で片付けられるものではなかった。本誌がトラブルに至る経緯を洗い出した結果、基幹システム運用の基本ルールを守っておらず、人的ミスが起きやすい状態で運用していたことが明らかになった（図1[拡大表示]）。 東証は株取引の増

近ごろ，「アスペクト指向」というキーワードを耳にする機会が増えてきました。「アスペクト指向プログラミング（Aspect Oriented Programming）」，略して「AOP」と呼ばれることもあります。もっとも，「アスペクト指向って何？」と聞かれて正しく答えられる人は，まだ多くないでしょう。オブジェクト指向にすら振り回されている方は，「また～指向？」と拒否反応を起こしてしまうかもしれません。 しかし，アスペクト指向は何もないところから突然変異的に発生した，得体の知れない概念ではありません。従来のオブジェクト指向に足りない部分を補うものです。さて「足りない部分」とは何でしょうか。 オブジェクト指向ではモジュール化できない機能がある 現在利用できる主要なプログラミング言語のほとんどは，オブジェクト指向に対応しています。JavaやC++はもちろん，Visual Basic，Perl，PHP