55億円無駄に、特許庁の失敗
政府システム調達における失敗の典型例が、特許庁の基幹系システム刷新プロジェクトだ。5年がかりで臨んだが、結局は55億円を無駄にしただけ。新システムは完成しなかった。失敗の最大の要因は、発注者である特許庁にあった（図1）。関係者の証言から、失敗に至る経過を改めてひもとく。 特許庁は2004年、政府が打ち出した「業務・システム最適化計画」に沿って、特許審査や原本保管といった業務を支援する基幹系システムの全面刷新を計画した。システムアーキテクチャーに詳しい情報システム部門のある職員（以下A職員）と、刷新の「可能性調査」を担ったIBMビジネスコンサルティングサービス（現・日本IBM）を中心に、調達仕様書を作成した。 業務プロセスを大幅に見直し、2年かかっていた特許審査を半分の1年で完了することを目指した。度重なる改修によって複雑に入り組んだ記録原本データベース（DB）の一元化に加え、検索や格納など
Twitterのログ保存サービス rec.to をつくりました（苦労した事、僕たちと非公開アカウント） - 9mの日記
http://rec.to rec.to（ﾚｯｸﾄｩｰとよんでます）はTwitterのログ保存サービスです。以下の機能があります。 ツイートを自動で記録 非公開アカウントに対応 アイコン履歴を保存 最近の画像一覧を表示 スマートフォン対応 サイト内でふぁぼとか まだなかった さてツイートのログ保存サービスといえば老舗のTwilogがあります。とてもすばらしいサービスです。サービスの開始当初あたりからずっと便利に使わせてもらっています。こんなすばらしい既存サービスがあるのにもかかわらず似たものを作った理由ですが、いくつか欲しい機能要件があったわけです。中でも一番欲しくて、作るきっかけになったのが非公開アカウントのログ保存機能です。アイコンの履歴とかも記録したい。そろそろ競合サービス出てもいいよね…ともおもってたし… サービスをつくるにあたって苦労した事 名前について このサイトを作るにあたっ
YAPC::Asiaで発表＆ベストトーク賞1位をいただきましたー - ゆーすけべー日記
世界最大級のPerlの祭典「YAPC::Asia 2012」に参加＆トークして来ました。 そして参加者の投票で決まるベストトーク賞をいただきました！ 60個ほどのトークの中での1位です！ありがとうございます＞＜ どうやらベストトークの賞品が「YAPC::NA または YAPC::Europe へ派遣」ということで、 来年ヨーロッパもしくはアメリカのYAPCに行って発表してきます。 発表する際、エロ禁止って言われたので、 それ以外のネタを探りつつ、エロネタをなんとかごまかして喋れないかなーと策略をこれから 練ろうと思います。楽しみです。 ベストトーク賞は確か前々回のYAPC::Asiaで導入されました。 過去賞をもらった人たちを見て、僕も今年なんとかして取りたかったものです。 そこで割と狙いにいって1位になっちゃったんで、嬉しいという思いと、うまくいったという達成感と、驚きが、 混ざった気分
自動改札機の運賃計算プログラムはいかにデバッグされているのか？ 10の40乗という運賃パターンのテスト方法を開発者が解説（前編）
自動改札機の運賃計算プログラムはいかにデバッグされているのか？ 10の40乗という運賃パターンのテスト方法を開発者が解説（前編） ふだん何気なく使っている鉄道。改札を降りるときにICカードを自動改札にかざすと、「ピッ」という音と共に一瞬のうちに運賃を計算してくれます。けれど、複数の路線を乗り継いだり、途中で定期券区間が挟まっていたりと、想像しただけでもそこには膨大な組み合わせがあります。それでも運賃計算プログラムはわずか一瞬で正しい運賃計算が求められ、バグがあったら社会的な一大事にもつながりかねません。 爆発的な計算結果の組み合わせがあるはずの運賃計算プログラムは、どうやってデバッグされ、品質を維持しているのでしょうか？ 9月12日から14日のあいだ、東洋大学 白山キャンパスで開催された日本科学技術連盟主催の「ソフトウェア品質シンポジウム 2012」。オムロンソーシアルソリューションズ 幡
米国人からコーディングについての怒りのメールを頂戴した - その手の平は尻もつかめるさ
"米国人からコーディングについての怒りのメールを頂戴した" の補足 - その手の平は尻もつかめるさ ↑の方で補足いたしました。(2012.09.04 追記) 最近、英語のメールでよく怒られます。moznion です。 海を隔てて共同作業しているアメリカ人から、僕のコーディングについてお叱りのメールを頂いたので、 自戒の念を込めて邦訳して記します。 書いてあることは「当然」とも言うべき内容ですが、僕はその「当然」も守れていなかったのかぁ〜と反省。 以下、邦訳(意訳)です。 1. 郷に入っては郷に従え 既にソースコードが存在しているって事は、そこには同時にコーディングスタイルも存在しているってことだ。 その既存のソースコードに手を加える場合、別のコーディングスタイルを導入してはならない。 もし君がバックエンドのソースコードを弄っているなら、バックエンドのコーディングスタイルで記述するんだ。 フ
ソフトウェア開発プロセス残酷物語 - give IT a try
昔々、あるところにジェイソンという、大変真面目な開発者がおりました。 彼がとある会社の情報システム部にやってきたとき、彼は社内システムのクオリティのひどさに衝撃を受けました。 情報システム部といっても、その会社では外注はせず、社内の開発メンバーがシステムを作っていました。 ジェイソンがそこで最初に担当したシステムは、見事なまでのスパゲッティコードでバグだらけ、データ設計も素人レベルでパフォーマンスも最悪、エラー処理もずさん、おまけにまともなドキュメントもなく、ちょっとした障害を調査したり、小さな改造を実施したりするのにも、大変な苦痛を伴うという、それはそれは大変なシロモノでした。 このシステムは元々エセーグルという、ちょっと変わった名前の開発者によって作られていました。 しかし彼はすでに別の開発チームに異動していて、こちらの質問には答えてくれますが、もはや本人が直接手を動かすことはありませ
技術革新は何のためにあるのか？ - 急がば回れ、選ぶなら近道
技術革新は須く斬新的なものであるべし、という肩に力の入った信念の人は流してください。ちょっと、力の抜いた小ネタなので。 最近というかここ10年来、いわゆる業務系のシステムに関わっていてよく思うことではあります。特に最近、NoSQLやHadoopといった「新技術」が登場するにつけて強く感ることではあるのですが、なんというか、「こんな感じ」のことができます、というようなプロダクトアウト的でありながら、かつ、漠然とした抽象的な話が多すぎる気がします。要は、全般的に問題の設定が苦手だよなということです。 特定の技術の各論はともかく、まず、大上段に構えると、実はITでは一般の人が想像する以上にユーザーとベンダーで期待ギャップがあります。ユーザーから見ると、大抵は「こんなこともできないのか？」ということがごく普通にできません。一方、一般のTVとか報道とかは、スパコンや遺伝子やビッグデータや、なんやらか
iPhoneアプリで食べていく――「ぐんまのやぼう」ができるまで
全国を群馬県にしてしまう人気ゲーム「ぐんまのやぼう」を開発したのは、アプリ開発だけで生計を立てている28歳の自称「ネオニート」。これまで100本以上のアプリを作ってきたが、「できれば働きたくない」「ひっそりしたい」と話す。 「東京都は群馬県になりました」「日本の都道府県はすべて群馬県になりました、つまり日本は群馬県です」 日本中を群馬県にしてしまうスマートフォン向けゲーム「ぐんまのやぼう」がヒットしている。5月初めの公開から2カ月で60万ダウンロードを突破。関連グッズが発売されたり、開発者が群馬県の観光特使に任命されるなど、アプリの枠を超えた盛り上がりを見せている。 開発したのは、群馬県出身のプログラマー・RucKyGAMES（ラッキーゲームス）さん。スマートフォン向けアプリからの収入だけで生計を立てている、自称「ネオニート」の28歳男性だ。RucKyGAMESは彼とデザイナーから成る2人
デプロイ作業の属人化を徹底的に排除したい話 - @kyanny's blog
ここ数カ月、デプロイとリリースについて、同僚や友人と議論したり雑談したりする機会が数多くあった。そんな折に、友人から Facebook のリリースエンジニアリングチームについて教えてもらった。曰く、 Facebook ではリリース作業を専門とするチームがあり、そこのメンバーは開発ブランチのコミットとそれに付随する ITS の議論を精査した上でリリースに値する変更をリリースブランチへ cherry-pick するのだそうだ。 2012/07/25 追記 Facebook のリリースエンジニアリングについては Facebook のリリースと文化 - Kato Kazuyoshi を参照のこと cherry-pick は無いわー、というのは置いておくとしても、リリースという極めて重要な作業が特定の人たちに委ねられている点に恐ろしさを感じた。嫌だと思うのはなぜなのかしばらく考えて、デプロイ作業の属
ウェブの「受託開発」が面白くないという8つの誤解 - Zerobase Journal
ぼく自身は多くのベンチャー企業とかよりよっぽど面白い仕事を「受託開発」でやってきているので（あ、もちろん「面白い」というのは主観的な問題だとお断りしておきますが）、ウェブ業界にはびこる「受託開発はダサい」という思想に強い反発を持ってきました。今日はそいつらをバッサリ斬ることにします。 ぼく自身は多くのダメなベンチャー企業とかよりよっぽど面白い仕事を「受託開発」でやってきているので（あ、もちろん「面白い」というのは主観的な問題だとお断りしておきますが）、ウェブ業界にはびこる「受託開発はダサい」という思想に強い反発を持ってきました。 今日はそいつらをバッサリ斬ることにします。 これまでに見聞きしてきた「受託開発が面白くない理由」を一つずつ取り上げて検証します。 × 受託開発なんて所詮「自分の事業」じゃないから自社事業がやりたい。 ○ 「受託開発」でも「自分の事業」としてコミットすることができる
「開発者のためのリーン・スタートアップ」「リーン・キャンバス入門」の資料を公開します - Kentaro Kuribayashi's blog
隣席のるびりすと氏(@hsbt)と僕とで、この半月ほど、東京・福岡で合計3回にわたって勉強会ツアーをやっていました(その他のこともたくさんやっていたので、それだけではもちろんないのですが)。今日でそれもひと通り終わったので、どのようなことをやっていたのかについて、ここで公開したいと思います。 我々の話はどの回も以下の順番で行われており、いわば三題噺みたいな構成となってます。 リーンスタートアップ インセプションデッキ Scrum それは、我々が議論している模様を撮った以下に掲げた写真に見られるように、開発プロセスというものが階層的な構造を持っているからです。 www.instagram.com ここでは、その最初の話「開発者のためのリーン・スタートアップ」および「リーン・キャンバス入門」のスライドを紹介します。 開発者のためのリーン・スタートアップ 僕は技術者です。また、技術者としてさらな
受託開発脳から自社開発脳へ切り替えの7つの壁 - ヴェルク - IT起業の記録
これ、思ったより大変でした。 自分含め、うちにいるメンバー全員、 これまでの経歴では受託開発をメインにやっていたため、 自社サービス開発の経験はかなり少なかったです。 でも、ヴェルクでは、受託開発をしつつ、 時間を作って色々と作っていこう、というスタンスのため、 起業直後から色々と企画を考えていました。 でも、受託開発脳から自社開発脳への切り替えは思った以上に苦労しました。 要件定義等でお客さんと一緒に要件を考えたりしますが、 最終的に「やりたい事」を持っているのはお客さんになります。 要件定義の前の企画やグランドデザインと言った分野は お客さんの戦略に沿ったものになります。 だから、最終的には、誰かが答えを持っている事が殆どです。 そのため、ゼロからそれを考える事があまりないんですよね。 いざ、ゼロから自分たちで企画を考えようと思った時、 いろいろと壁がありました。 1. 本当の意味での
Re: エンタープライズシステムの開発言語選定の一考察（C#とJava） - 平々毎々（アーカイブ）
エンタープライズシステムの開発言語選定の一考察（C#とJava） - torutkのブログ 前提も明らかで、丁寧に比較されていると思いました。ついでに.NETの情報を補足してみます。 ケーススタディ1 C#で開発していた場合 アプリケーション開発／実行基盤は、3番目の候補を挙げてみます。 開発環境: Visual Studio 2010/C# 2.0/.NET Framework 3.5SP1(2.0) 実行環境: .NET Framework 3.5SP1(2.0) .NET Framework 3.5SP1のCLR(Javaで言うところのJavaVM相当)は.NET Framework 2.0と基本的に同じもの。その上、.NET Framework 3.5SP1からはOSのサポートライフライクルに準じるようになったので(ソース:http://msdn.microsoft.com/ja-
エンタープライズシステムの開発言語選定の一考察（C#とJava） - torutkのブログ
アーキテクチャ設計の一部に、プログラミング言語の選択があります。選択に関わるのは仕事では10年振り（うん？ ちゃんと数えると13年か・・・）です。3月から下調べを開始して、可能な限り公平に。 もちろん人間の判断なので、主観が大きく関与せざるを得ません。特にプログラミング言語は、パラダイムの選択になるので。 前提の明確化 技術選定にあたっては、前提を明確にしておかないと、果てしない議論に陥ってしまいます。 ここでは、開発対象をエンタープライズ・システムとします。エンタープライズ・システムは、開発期間よりも運用（保守）期間が数倍（たとえば、開発１年に対して運用10年といったことも珍しくない）になります。また、システム化範囲も昔に比べて増えてきており、その分作成されるアプリケーション規模（機能量）も大きくなります。 また、運用（保守）期間では、随時機能の変更・追加が行われる想定とします。 システ
サービス終了のお知らせ - NAVER まとめ
サービス終了のお知らせ NAVERまとめは2020年9月30日をもちましてサービス終了いたしました。 約11年間、NAVERまとめをご利用・ご愛顧いただき誠にありがとうございました。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Rails3、Twitter Bootstrap、Bootswatch を使ったレスポンシブなエロサイトをリリースしました
「新しい」を生み出すためのWebアプリ開発とその周辺
XP matsuri 2012 LT
25re.com is for sale | HugeDomains
効率的なWebアプリケーションの作り方 // Speaker Deck