suicaは実はたまに落ちている - 紅茶屋くいっぱのあれこれ日記
suicaのサーバーはみんなの知らないところで、実はたまに落ちているそうだ。 だがシステムが止まることはない、計算上センターは3日ぐらいは止まっていても大丈夫だそうだ。 だからサーバーが落ちたなどとニュース沙汰になることは殆ど無い。 suica開発陣頭指揮をされていたかたが、その実績をまとめてと頼まれ、博士論文にしたそうだ。 suicaの実例を述べるだけだと技術論文になってしまうので、一般化して論文を書きあげたそうなのだが、審査に携わった専門家の人達はそんなものが動くわけないだろうといったらしい。しかし現実問題としてsuicaは動いてしまっている。 本人いわく、だってそれで動いちゃってるんだもん。だそうだ。 実装は時として奇妙に見えるかもしれない。 フィールドには神がいる。 …その意や、なんで落ちても大丈夫かなどはまた後ほど。 スイカのセミナー 昨日はスイカのセミナーだった。 JR東でスイ
ソフトウェア品質のジレンマ - ありえるえりあ
Recent entries Apache2.4のリリース予定は来年(2011年)初め(あくまで予定) inoue 2010-12-23 Herokuの発音 inoue 2010-12-20 雑誌記事「ソフトウェア・テストPRESS Vol.9」の原稿公開 inoue 2010-12-18 IPA未踏のニュース inoue 2010-12-15 労基法とチキンゲーム inoue 2010-12-06 フロントエンドエンジニア inoue 2010-12-03 ASCII.technologies誌にMapReduceの記事を書きました inoue 2010-11-25 技術評論社パーフェクトシリーズ絶賛発売中 inoue 2010-11-24 雑誌連載「Emacsのトラノマキ」の原稿(part8)公開 inoue 2010-11-22 RESTの当惑 inoue 2010-11-22 「プ
9万8000円のオーダーメイド・システムで“Excel難民”を救いたい
スターロジックは5月1日，1業務（1帳票とそれを承認するワークフロー）を9万8000円でオーダーメイドによりシステム化するサービス「ギョイゾー」を開始した（関連記事）。システム・インテグレーション（SI)業界の常識から大きくかけ離れたこのサービスをなぜ始めたのか。どのようにしてこの価格を実現したのか。代表取締役社長 羽生章洋氏に聞いた。（聞き手は高橋信頼=ITpro編集） なぜ「ギョイゾー」を始めたのですか。 昨年，「DIY（DoITyourself）」というサービスを始めました。ユーザーが「マジカ！」というカードを使って仕様を書き，1タスク当たり8万円でシステム化するサービスです（関連記事）。 人月からの脱却 「DIY」では人月からの脱却を目指しました。SI業界は長らく人月で仕事をしてきました。人月は時間あたりの労働力を売る業態で，技術者の付加価値は認められない。生産性を上げるよりだらだ
第1回 データ・クレンジングと名寄せ技術：ITpro
皆さんは，企業のシステムが提供している情報（データ）をどれくらい信用していますか。 例えば，社内の製品担当者に問い合わせをしたい場合，社内システムを使って，製品から担当者を割り出し，担当者名から電話番号を検索，その電話番号に電話をかけてみるでしょう。この場合，社内システムから得られる情報はおおむね信用できるでしょう。製品担当者の変更が更新されていないといったこともあるかもしれませんが，そのような場合は社内であれば引き継ぎ担当者を教えてもらうことで状況を理解できるので，まずは情報を信じて電話をかけてみるのではないでしょうか。 では，社外のお客様へ連絡するときはどうでしょうか。この場合は少し慎重になるでしょう。社内情報を検索するとき以上に各種システムから信用できる必要な情報を慎重に収集し，行動に移すはずです。私の友人のA君もそうでした。 使えないデータたち A君はある電気製品の販売を担当する営
へ〜たのめも:Google のソフトウェア・エンジニアリング - livedoor Blog（ブログ）
2007年06月07日 Google のソフトウェア・エンジニアリング Google Developer Day Tokyo の鵜飼さんのプレゼンより、「Google のエンジニアはどうやって開発しているのか?」 Google の研修 入社して最初の 3ヶ月は本社(Mountain View)で研修 研修中は、メンターがついて「Google での開発の仕方」を学ぶ 内部ウェブ・サイトで社内共有ライブラリの使い方などを説明する動画があるので、それで自習 Google のプロジェクト・チーム 開発拠点は米国、スイス、オーストラリア、インド、日本など 場所とプロジェクト・チームは関係なく、プロジェクト・チームが拠点をまたがることは普通。世界中の拠点全部合わせて、一つの Google エンジニアリング・チーム 開発はデザイン、コーディング、テスト、改善、デモの運用まで上流から下流まで同じチーム(同
UIEngineのデザイン・プリンシプル
このブログを書き始めて約１年が経つが、考えてみれば私の会社（UIEvlution Inc. 本社シアトル）がビジネスのコアに置いているUIEngineについてまだ一度もちゃんと解説していなかったことに気がついた。そこで、これから何回かのエントリーにまたがって、UIEngineとは何かどんな発想のもとに作られたのか、を書いていこうと思う。 第一回の今日は、UIEngineのデザイン・プリンシプル（良い日本語訳が無いのだが、あえて訳せば、設計理念）。デザイン・プリンシプルを持っておくことは、どんなソフトウェアを作る場合でも大切だが、特にUIEngineのようなプラットフォーム・ソフトウェアを作る場合には、しっかりと筋の通ったものを設計当初から持っておくことがものすごく大切である。 UIEngineのデザイン・プリンシプルは、ひとことで言えば、「いつまで経っても小さくて軽くてシンプルなウェブ・ア
「アート・オブ・プロジェクトマネジメント」読書感想文（その5）
■優れたPMは質問の達人 筆者は「優れた質問は優れたアイディアを惹きつける」という。では、優れた質問とは何か? ここでは5章で紹介される、アイディアを生み出す方法から、「質問」に焦点を絞って考察する。 焦点合わせの質問 創造的な質問 修辞的な質問 まず「焦点合わせの質問」から。プロジェクトのどんなフェーズであろうとも、質問者が誰であろうとも、最もパワフルな質問がある。わたし自身、ミーティングで必ずする質問。自問も含めると、一日に何回、この質問をすることやら。その「質問」は、反転表示で以下に記す。ドラッグの前に、ちょっと考えてみて欲しい↓ 解決しようとしているのは、どのような問題なのだろうか? 仕様書の記法について議論しているときも、不具合の正体を見極めようとしているときも、「問題の本質を定義しなおす」行為は、ホウレンソウ並に基本動作となっている。ものすごく重要なので、わたしの手帳の第一ペー
プログラマではなくテスターとして現場デビューする - 設計者の発言
筆者はプログラミングは好きだったが、テストについてはずっと苦手意識があった。プログラムがそれなりに完成してしまうとそれで満足してしまって、さっそく次のプログラムにとりかかりたくなる。結局、システムテストの段階でハデにバグが見つかってどれだけ周りに迷惑をかけたかわからない（今思い出しても冷や汗が出る）。「自分に代わってテストだけをやってくれる要員」がいてくれたらと本気で願っていた。 だから、１年前にある小さなソフト開発企業で、「新人をまずテスターとしてみっちり仕込むようにしている」と聴いたときは感心した。その発想は考えれば考えるほど合理的かつ発展的だ。筆者なりに肉付けした形で紹介したい。 ◆新人は現場のお荷物である 多くのソフト開発企業での新人教育が何から始まるかというと、大学の一般教養課程のような「コンピュータ概論」だったりする。その後に「ソフトウエア分析・設計」とか「プログラミング」の学
システム設計は「成果物を他人にジロジロ見られるハズカシイ仕事」 - 設計者の発言
◆設計図を見られたくない設計者たち 筆者もパネラーとして参加した「ＤＯＡ＋コンソーシアム第三分科会」の第１回会合「データモデリングって実際どうなの？(2005.2.15)」の議事録が公開された。読み物としてもなかなか面白いのでお勧めしたい（ただし閲覧するためにはＤＯＡ＋への会員登録が必要）。 とくに興味をそそられたのは、基調講演をしたテプコシステムズの國澤（くにさわ）氏のパネルディスカッションでの発言だ。社内での設計事例を集めたモデルライブラリーを作ろうとして挫折した理由として、彼は次のように語っている。 プロジェクトをやっている人自身が自分のつくったモデルを公開したがらないということがより大きな問題でした。自分が作成したモデルを公開して、周りから文句をつけられたくないというメンタリティが非常に強いようです。 ◆テクニカルレビューの困難 筆者も同じような経験をしたので彼の無念さがよくわかる
真髄を語る 経営者がITを理解できない本当の理由
佐藤正史 氏 JTB情報システム 代表取締役社長 当サイトにおいて、企業情報システムにかかわってきたベテランが引退する、いわゆる「2007年問題」について色々な議論がされております。私は1971年にJTBに入社して以来、ほぼ一貫して情報システムの仕事に従事してきました。私が情報システムに関係してきた期間は、日本における約40年の企業情報システムの歴史と概ね重なっております。 2001年から取締役（情報システム担当）として、CIO（最高情報責任者）の仕事をし、現在はJTBの情報システム関連会社の社長を務めています。おそらく、あと数年で2007年問題の一方の主役として、この舞台を去ることになるでしょう。まもなく企業人生を終えようとする一介のシステム屋ではありますが、ぜひとも多くの方に申し上げたいことがあり、この場を借りて思うところを綴ってみます。 私は今、日本のITを巡る状況に大変な危機感
ksh Days - デスマーチについて考える（デスマーチ経験のエピローグ）
このエントリは デスマーチについて考える前にデスマーチの経験を書く の続きです。(2007/2/16追記) 私はテスタとして、必ず バグの修正を「お願いします」と言う。 バグ修正確認時は、必ず直してないところも最低１箇所は触ってみる。（でよく落ちる） バグ修正が確認できたら、できるかぎり早く「確認できました。ありがとうございました」と言う。 を実践してゆきました。 ある日、一人のプログラマさんから相談を受けました 「今度の機能なんですが、納期が近いから単体テストせずにkshさんにテスト依頼しろってSEさんから言われたんですが、そんなことしたくないんです」 以下、全文はこちら
「ポケモンスナップ」の情報・産地直送！ ほぼ日刊イトイ新聞 - 樹の上の秘密基地
Sponsored by Nintendo. 「ポケモンスナップ」の情報・産地直送！ （第５回の６） 「特別座談会・今だから言えること」 〜 ものをつくるとは何か 後編 〜 NEW！ クリックして本文へ （第５回の５） 「特別座談会・今だから言えること」 〜 ものをつくるとは何か 前編 〜 クリックして本文へ （第５回の４） 「結果を出すことが大事だったんです。」 クリックして本文へ （第５回の３） 「写真を撮るだけでゲームになりますか？」 クリックして本文へ （第５回の２） 「リーダーは、現れず。」 クリックして本文へ （第５回の１） 「ジャックの豆の木計画、始動する。」 クリックして本文へ 1999-6-20-SUN 閉じる
非機能要件を見極める【前編】：ヒアリングでは不十分
「要件定義を難しくする」とクローズアップされてきたのが“非機能要件”の存在である。非機能要件とは，性能や信頼性，拡張性，セキュリティなど，機能要件以外のもの全般を指す。これらはユーザーへのヒアリングからだけでは洗い出しにくい。漏れがあると，稼働後のトラブルの種になる。こうした事態を未然に防ぐ，非機能要件の見極め方を探る。 旅行代理店のアールアンドシーツアーズは，今年10月末に予定しているホテル予約システムの稼働に向けて，今，開発の真っ最中だ。このシステムは，仕入れた航空券の在庫や宿泊の空室情報を管理するホストに，2次代理店からインターネット経由で送信されてくる予約データを受け渡すもの。 開発を主導する大平雅義システム部長は，「機能要件はほぼ固まったが，性能に関する非機能要件が懸案として残っていて悩ましい」と語る。 予約データはインターネットを介してやり取りされる。そこに含まれる顧客情報は暗
製品開発でもコタツモデルは有効だ
筆者は，建設業界向け業務ソフトの開発ベンダーでソフトウエア開発に携わってきた。ここでは，自社における要求開発の事例を紹介したい。受託開発や社内システムの開発などと違い，不特定多数のユーザーが使う製品の開発では，要求開発にも多少異なる点がある。とはいえ，Openthologyが提唱する手法の多くは，製品開発における要求開発においても有効だ。読者の方々が要求開発に取り組む際に，参考になれば幸いである。 たまったバックログは3000件以上 当社では，営業部門やカスタマ・サポート部門が顧客からの要求を受け付けている。起案される要求は，多い月で100件程度。これが整理されないまま乱雑に積み残された結果，バックログの数は3000件以上にも達していた。現場では，このバックログの中で「何をやって，何をやらないのか，やるとしたら何からやるべきなのか」を判断しきれずに，混沌としていたのである。 さらに，要求の
わたしが知らないスゴ本は、きっとあなたが読んでいる: 名著！「デッドライン」
長くなりすぎたこのエントリのレジュメ …というか、見出しの一覧。これ見てご興味ある方はお読み下さいませ。 マネジメントの4つの本質 マネジメントおける簡潔で痛切なエッセンス（一部） 設計とデバッグに関する恐ろしい事実 残業と生産性とプレッシャーに関する恐ろしい事実 生産性の測定について 管理者の怒りについて 会議を効率よく行うための、たったひとつの冴えたやりかた 大事なことが、ずばり書いてある。背中を押したのは「ソフトウェア開発の名著を読む」なんだけど、確かに名著だ。初読は物語を楽しみ、再読、再々読で血肉にすべきだな。 延ばし延ばしにしてた一冊を読み始めて「どうして今まで読まなかったんだあぁぁっ」と叫びだすような逸品がある。本書がまさにそう。デマルコは「ピープルウェア」がピカイチと決め付けてた自分が恥ずかしい。 「ピープル」がプログラマ・チームリーダーの視点で書いているが、「デッドライン」
日の丸検索エンジン - 池田信夫 blog
先週の「シグマ計画」についての記事には多くのアクセスがあり、1日のページビューが1万を超えた。今週の『サンデー毎日』にも「国策検索エンジンは300億円をドブに捨てる!?」という記事が出ているが、当事者以外から肯定的な評価はまったくない。「日の丸検索エンジン」が成功する可能性は、客観的にみてゼロに近いと思われるが、むしろ興味あるのは、そういう失敗がなぜ繰り返されるのかという問題である。当ブログは経産省でも読まれているようなので、少し専門的で長くなるが、これを経済学的に考えてみる。 こうした「産業政策」についての実証研究としては、三輪芳朗他『産業政策論の誤解』、マイケル・ポーター他『日本の競争戦略』などが知られている。いずれも「産業政策は最初から失敗の連続であり、日本で成功した産業は政府が放置した部門だった」という結論を出しているが、これはいささか疑問である。終戦直後の日本の製造業のように、
ITPro: 基本設計におけるレビューの勘どころ
どんなに基本設計をしっかりやっても，その後のフェーズで「欠陥」が見つかれば意味がない。欠陥が発見されれば手戻りが発生し，進ちょく遅れや収益悪化といったプロジェクトの混乱を招く。基本設計フェーズにおける品質向上のプロセスや成果物のレビュー方法について解説しよう。 「考慮していない外部システムとの連携が詳細設計で見つかった」，「仕様間の不整合が実装フェーズで発見された」――。どんなに基本設計をしっかりやっても，その後のフェーズで「欠陥」が見つかれば意味がない。欠陥が発見されれば手戻りが発生し，進ちょく遅れや収益悪化といったプロジェクトの混乱を招く。基本設計フェーズにおける品質向上のプロセスや成果物のレビュー方法について解説しよう。 「欠陥防止」を徹底する 改めて言うまでもないが，基本設計の成果物の品質を向上させるプロセスは，(1)設計作業を実施する，(2)成果物をレビューして欠陥を洗い出す，(
404 Blog Not Found:サルでも生産性が上がるオープンソース
2006年09月02日22:15 カテゴリOpen Source サルでも生産性が上がるオープンソース というわけで、続き。 404 Blog Not Found:1998年じゃ遅すぎる 次のentryからそのあたりを考察していくことにしよう。 主題は、こちら。 「Googleはオープンソース組織を内部に持つ営利企業」---梅田望夫氏が語るシリコンバレー精神とオープンソース：ITpro 謎のひとつは「スケジュールもなければロードマップもない。てんでばらばらなのに，非常にクオリティの高いソフトウエアが生まれてくる」（吉岡氏）という，オープンソース開発モデルの生産性の高さだ。 なぜ、オープンソースの生産性は高いのか? 身も蓋もない答えを言ってしまおう。 生産性が充分高いプロジェクトしか手をつけられないからだ。 「生産性が充分高い」とはどういうことか、というと、「すでに他でうまく行っているプロジ
「日本への執着」が日本のソフトを弱くする - 雑種路線でいこう
宋文洲氏は日本のソフトウェア技術者の卑屈な「日本人特殊論」こそ日本に於けるパッケージソフトが流行らない理由と論じているが，これはミスリードも甚だしい．IBMが独禁法の排除勧告を受けてハード・ソフト分離を行って以来30年有余年の歴史を持つソフトウェア産業振興の議論を蒸し返し，ちょっとした補助金を受け取ろうという魂胆なら却って芳ばしい時代錯誤かも知れないけど． 確かにパッケージソフトウェアが入りにくいことは日本のエンタープライズ市場の際だった特徴だが，これは宋氏の論ずるパッケージソフト・ベンダの怠慢より，長らく閉鎖的だった資本市場やユーザー企業の問題である．土地や機械といった実物資産を担保にしか資金を借りられず，株式会社をつくるのに一千万円もの資本が必要だったから，多くの零細ソフトハウスがリスクを取れず人月商売に精を出した．80年代，90年代を通じて生まれたなんちゃってパッケージ業務ソフトの多
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
プロジェクトの「補助線」