システムインテグレーション崩壊、斎藤昌義著、読了 - 未来のいつか/hyoshiokの日記
システムインテグレーション崩壊 ~これからSIerはどう生き残ればいいか?を読んだ。 編集の傳さんから直々の献本。ありがとうございます。 先日読んだ、倉貫さんの「納品」をなくせばうまくいくが面白かったという日記 *1 を読んだ傳さんが送ってくれた。 刺激的なタイトルである。副題が「これからのSIerはどう生き残ればいいか？」である。このままでいいのか、いやいいわけはない、という問題意識の本である。 わたしは、SIerでもないし、SIerに勤めた経験もないので、あくまで部外者の感想にしかすぎないのだけど、本書で述べられていることはいちいちその通り、おっしゃる通りである。 IPAの「IT人材白書2014」からの引用があるが、それが衝撃的で、ユーザー企業が今後新規／拡大をしていく分野（SaaSやPaaSなど）、IDCサービスへのSIerの関心は低く、SIerの今後の新規／拡大を予定している事業に
SQLを作った人たち - 未来のいつか/hyoshiokの日記
リレーショナルデータベース管理システム(RDBMS)は言うまでもないことだけど、データベース管理の基礎中の基礎だ。NoSQLというRDBMSではないデータベース管理システムが出て来ているがそれもSQLがあってこそのNoSQLだ。 リレーショナルモデルはIBM E.F. Codd博士が提唱した。Edgar F. Codd - Wikipedia Codd博士は後にチューリング賞を受賞している。 http://en.wikipedia.org/wiki/File:Edgar_F_Codd.jpg そのデーターモデルを利用したデータベース管理システムのプロトタイプがSystem Rだ。IBM System R - Wikipedia 1974年ごろ発表された。 その成果の一つがSQLだ。誰でも使っているSQLはSystem Rの論文が発祥の地である。そしてその論文を読んでRDBMSを作った男がL
オープンソースのコンプライアンス問題と利用の成熟度 - 未来のいつか/hyoshiokの日記
先日、オープンソース関連のセミナーを聞く機会があって、弁護士の先生がオープンソースをコンプライアンスの観点から解説をされていた。 弁護士の仕事はクライアントからの相談事を主に法律等の観点からアドバイスすることなので、クライアントがオープンソースにはどのようなリスクがあるかという質問をすれば、当然ながら「XXXというリスクがある」とか「XXXのリスクを避けるためにYYYという対策をとる必要がある」とか言う回答になる。 コンプライアンスという観点から、オープンソースのライセンスを検討すれば、GNU GPLのオープンソースを利用して、著作権者から訴えられない利用方法とか、MITの場合はどうだという方向になる。 クライアントも別にオープンソースに詳しいということもないから法律的な相談をするわけで、いかにリスクを最小化するかという文脈では上記のようなやりとりになる。 つまりこの文脈の中では、オープン
エンタープライズ系とウェブ系 - 未来のいつか/hyoshiokの日記
エンタープライズ系ってなんだろう。ウェブ系ってなんだろう。勝手に脳内イメージを言語化してみた。読者諸氏のコメントを待つ。(想像でものを言っています) エンタープライズ系 ウェブ系 開発手法 ウォーターフォール アジャイル 開発 外注 内製 会議 多い、長い 少ない、短い 資料 人数分カラー印刷 印刷なし 進捗管理 エクセル バーンダウンチャート ソースコード管理 ファイル名日付 Git 服装 スーツ Tシャツ 新技術の取得 ベンダーのセミナー 勉強会 テスト 人海戦術 自動化している 休日の過ごし方 休日出勤 趣味のプログラミング 休日の過ごし方、その２ ゴルフ 趣味のプログラミング、子供と遊ぶ ダイバーシティー 最近結婚してやめた人がいる 最近外国籍の人が増えている 上司 年上 年下もいる 飲み会 おじさんばっか おたくとコスプレ 転職 したことがない 同業他社から転職して来た 趣味、尊
ブルックスの法則とはなにか - 未来のいつか/hyoshiokの日記
ソフトウェア開発におけるブルックスの法則とは何か。 http://ja.wikipedia.org/wiki/%E3%83%96%E3%83%AB%E3%83%83%E3%82%AF%E3%82%B9%E3%81%AE%E6%B3%95%E5%89%87 遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせる ブルックスはIBM System/360用オペレーティングシステムOS/360の開発総責任者だった人で、その経験をもとに人月の神話【新装版】というエッセーを執筆した。 人月の神話は、ソフトウェア開発を志す人なら必ず一度は読まなければいけない良書だ。読んでいない人は、悪いことは言わないから、ともかく読むことをおすすめする。 初版が出版されたのが1975年（日本語訳は1977年）で、20周年記念版が1995年に出た。ブルックスの発見した法則があきらかになって約40
かつてオープンソースが当たり前じゃないころがあった - 未来のいつか/hyoshiokの日記
先日文明塾の修了生のみなさまとお話したときのこと(コミュニティとしての大学 - 未来のいつか/hyoshiokの日記参照)。ハッカー文化とかオープンソースのことをあれやこれやお話したのだけど、その中で現役の学生さんから「ゼミでIT係を担ってからよくソースコードを何気なく閲覧してしいました。しかし、自由にソースコードが見れる環境が衝撃的で素晴らしいことであることに吉岡さんのお話を聞いて学ばせていただきました。」という感想をいただいた。 そうだ。すっかり忘れていた。オープンソースが当たり前じゃない時代があった。とてつもない衝撃を受けた自分がいたことをすっかり忘れていた。 1998年1月。Netscapeが自社のブラウザのソースコードを公開するということを発表した。当時のシリコンバレー日記にそのことを書いている。http://web.archive.org/web/19990423102903/
ユーザー企業が開発するということ - 未来のいつか/hyoshiokの日記
ウェブ系のサービスを提供しているところは常識なんだけど、世間ではあまり知られていないことは、サービスは基本的には自社で作るということだ。 日本において、ITシステムはユーザー企業が作るのではなく、それを専業にしているベンダーが作る事が多い。SI (System Integrater)と呼ばれる企業だ。ハードウェアベンダーのSI部隊であったり、独立系と呼ばれるベンダーだったりする。統計では受注ソフトウェアの売上になる。 *1 わたしはSI企業にいた経験がないので、本当の実態を知る立場にはないけど、想像するに、大手ベンダーが受注したシステム開発の案件を、誰かが要求定義して、それを文書にして、その文書をもとに誰かが設計して、その設計書をもとに、誰かが実装をする。テスト仕様書を誰かが作って、誰かがテストをする。発注側とシステムを受注する企業が別の場合は、何をいくらでいつまでに作るかというのを契約で
Can-Do vs. Can’t-Do Culture - 未来のいつか/hyoshiokの日記
http://recode.net/2014/01/01/can-do-vs-cant-do-culture/ As a venture capitalist, people often ask me why big companies have trouble innovating while small companies seem to be able to do it so easily. My answer is generally unexpected. Big companies have plenty of great ideas, but they do not innovate because they need a whole hierarchy of people to agree that a new idea is good in order to pursue
パクればいいんだよパクれば - 未来のいつか/hyoshiokの日記
イノベーションが新しい産業を興し雇用を生み社会を豊かにする。多分それは間違いないだろう。 本書は、イノベーターではなく模倣者（イミテーター）に焦点をあてている。企業が生き残って行くためには、模倣（イミテーション）はイノベーションと同じくらい重要な意味を持っている。にも関わらず、それの重要性については十分に議論されていない。暗黙のうちに、イノベーションは善であり、イミテーションは悪であるという呪縛にかられている。 科学も芸術も模倣から生まれている。 オープンイノベーションは、自組織が生み出せなかったものを外部とのコラボレーションとによって行う。その対極にあるのが、自社の技術に拘って、ビジネス的にも技術的にも劣ったものを投入して自滅して行くというNIH症候群である。 オープンソースはいいものをコピーすることによって発展している。それはアルゴリズムであったり、ベストプラクティスとして知られる、い
プログラマが知るべき97のこと - 未来のいつか/hyoshiokの日記
和田さん監修、夏目大さん翻訳。下記のような日本人プログラマに書き下ろしもついている。 命を吹き込む魔法 森田 創 ロールプレイングゲーム 関 将俊 ルーチンワークをフローのきっかけに 宮川 達彦 プログラマが持つべき3つのスキル 吉岡 弘隆 快適な環境を追求する 舘野 祐一 見知らぬ人ともうまくやるには 小飼 弾 不具合にテストを書いて立ち向かう 和田 卓人 育ちのよいコード 森田 創 Noといえることの大事さ 宮川 達彦 名前重要 まつもと ゆきひろ 誰かに向かって、「〜するべき」というのは、いささかおこがましい感じもしないではないが、「プログラマが持つべき3つのスキル」というエッセイを寄稿した。日頃言っている、ソースコードを読むスキル、テストするスキル、デバッグするスキルなどについてあれやこれや申し上げた。 書き下ろしの中で、まつもとさんの「名前重要」や森田さんの「命を吹き込む魔法」は
テストを書くこととテストをすることの違い - 未来のいつか/hyoshiokの日記
会社でレガシーコード改善ガイドの読書会をやっていて、次回で読了だ。4月に入ってから週に1回くらいのペースでやっていて、2ヶ月半くらいかかった。途中、ゴールデンウィークや所用で開催しないこともあったので、１０回くらいで完走したことになる。 一人当たり、1章ないし2章くらいを担当して、その章に書いてあることを説明した後にみんなであーだこーだ議論をする。気になったことを質問したり、どうも良く分からないことをみんなで考えたりする。 テストがないコードはレガシーコードだ！というキャッチフレーズはわたしの心をとらえた。 参加者の皆さんとその価値観を共有できた事はうれしい。 現場での開発の実情をいろいろ教えてもらった。テストを書くことはあまり一般的ではないということにわたしは衝撃を覚えたのであるが、この読書会を通じて、テストを書かない開発というのがレガシーコードを作っている事に他ならないという共通の認識
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
