Googleによるシステム開発・維持管理ノウハウをまとめた本が無料公開中
Googleで培われたシステム管理とサービス運用の方法論である「サイトリライアビリティエンジニアリング(SRE)」のノウハウをまとめた本が「Site Reliability Engineering」です。英語版の内容が無料で公開されているほか、オライリーから発刊予定のSREに関する書籍「The Site Reliability Workbook」も、2018年8月23日までの期間限定で公開されています。 Google - Site Reliability Engineering https://landing.google.com/sre/book.html Site Reliability Engineeringを読むには上記のサイトにアクセスし、「READ ONLINE FOR FREE」をクリック。 目次が表示されるので、まずは序文から読んでみます。「Foreword」をクリック。
システム仕様（モデル・設計・実装）の本質について思ったこと - HITORIGOTO
渡辺幸三氏のブログ記事『「科学研究」としてのシステム開発』を読んだ。プログラマ寄りな思考の私には、記事の趣旨を汲み取って発展させるような意見を述べることはできないが、インスピレーションを受けた部分があるので書き残しておきたい。 watanabek.cocolog-nifty.com システム仕様（モデル・設計・実装）の本質って何だろう 記事の後半で、システム仕様の本質が次のように述べられている。 ところが、システム開発の成果物は、人間が世界のあり方を理解するためだけでなく、その記述自身として機能するという不思議な性質がある。成果物を機械に渡せば、機械がその内容にもとづいて振舞い始める。世界のあり方に関するモデルとして構築されたものが、世界の一部に組み込まれて機能し始める、と言ってもいい。 これこそが、システム仕様の本質であり、強みなのだと思う。ある角度から眺めれば、人間に対する「現実に関す
システム開発の契約が民法改正で変わる
民法の契約に関する内容が、120年ぶりに改正される。明治時代に制定された法律が現在まで変わらなかったというのも驚きである。当然ビジネス形態やそれを取り巻く環境は大きく変わり、現状に沿った改正がなされることになった。民法は私たちの生活やビジネスに直結するため、大きな影響が予想される。 改正案は2015年に既に通常国会で審議され、2017年度の国会で可決されれば2019年頃に施行される見込みである。施行までに期間が空いているのは、周知に時間がかかり、かつ影響が大きいことを示している。 民法が改正される点は約200項目あり、その中でもIT業界はシステム開発委託契約が大きく変わると見られている。委託契約が多いIT業界においては広範囲で影響を及ぼす可能性があるため、事前にどのようなものか把握し対応する必要があるのである。 ※2016年7月22日に公開した記事ですが、リライト記事に必要な文言等を一部追
ある判決、要件にないことで責任を負わされたシステム開発会社の悲劇
「ITの専門家なら情報漏えい対策は施しておくべきじゃないですか！」、「いや、システム要件にない機能は実装しませんよ」――。あるECサイトにおける悲劇の現場を再現すると、システム発注者側とシステム開発を受注した会社の間では、おそらくこのような会話がなされたに違いない。 上記は、セキュリティ関係者の間で話題になった判決（東京地方裁判所判決 平成23年（ワ）第32060号）を読んで、筆者が想像した会話だ。 インテリア用品の販売会社（原告）が運営するECサイトが、外部からのSQLインジェクション攻撃によってクレジットカード情報などの個人情報を流出させてしまった。SQLインジェクションとは、Webサイトの入力フォームを悪用し、データベースで不正な処理を実行するプログラム（SQL文）を送り付ける攻撃手法だ。 販売会社側は、顧客の個人情報が漏洩した責任はECサイトのシステム開発を受託した会社（被告）にあ
アプリの未完成 東京地判平26.10.28（平24ワ35991） - IT・システム判例メモ
スマホアプリが完成といえるために必要な機能は，どこまでなのかが争点となった事例。 事案の概要 アプリ開発会社Xが，Yから委託されたiPhone用アプリ（本件アプリ）を開発したが，Yから代金が支払われないとして，業務請負契約（本件契約）に基づく請負代金168万円の支払いを求めた。 これに対し，Yは反訴として，Xによる訴訟提起が不当訴訟であること，Xの仕事が納期に遅延したこと等による損害賠償合計約190万円の支払いを求めた。 本件アプリは，次のようなものだった。 本件アプリは，基本的に，個人の年収や貯蓄金額を他者と比べて勝ち負けを競うゲームであり，それに加えて，ユーザー間における貯蓄や年収のランキング表示がされるものであった。 他のユーザーとの対戦は，「ゲームを通じて，互いの収入を気軽に話題にできることを狙いとして」対面で対戦できるようにするため，通信手段にBluetoothを使うことを検討し
システム開発の現場改善記 - esa.io 導入編 - Tbpgr Blog
概要 esa.io 導入の過程について 経緯 世の中のシステム改善の情報はよく見かけるが、 自分も改善しようとした時に、どのようにしたらいいか分からない 。 実際の改善をするまでの 細かな過程などを参考にしたい 、という相談を受けました。 同じような情報が欲しい、という方が他にも居るかもしれないので 私の業務の改善実績を公開することにします。 需要がありそうなら、シリーズ物として地道にアウトプットして行こうかと思います。 ポイントとして、私自身は優秀なハッカーや優れたマネージャーなどではなく、 ありふれた開発者の一人 に過ぎません。 私の性格については、引っ込み思案で内向的。 どちらかという消極的で、お世辞にもコミュニケーションが上手なほうではありません。 勉強会に行って、 懇親会でほとんど発言せずにしょんぼり して帰ったり、 RubyKaigi のオープンスペースの昼食が怖くて、 豪華な
「納品をなくせば」の倉貫CEOたちが語る新しいSIへの道 (2/2)
大手のSIerが肥大化する理由とは？ そして、開発責任を丸投げする先となるSIerは、おのずと肥大化せざるをない。これは合併の相次ぐSI業界を見れば明らかだ。倉貫氏は、「大手のSIerはもはや合併して、より大きくならないと儲らない。納品しないとキャッシュが入らないので、体力が必要になる。でも、結局は人月ビジネス。要はマンパワーでビジネスを仕事しているのに、スケールを目指そうとしているのが、すでに経営の戦略としてねじれを生んでいる。でもそうせざるを得ない」と指摘する。 SIerが大きくなって、数字が積みやすい人月単価を続けるという労働集約的なモデルを続ければ、確かに利益も読みやすい。数多くのプロジェクトを獲得すれば、マイナスがあっても、トータルでプラスになれば、やっていけるというモデルだ。しかし、植草氏は「こういうモデルを脱却しなければならない。僕らはプロジェクトを速く終わらせて、価値に対す
詳細設計書は死んだ。とっくの昔に死んでいる。でも生き返る必要はある - L'eclat des jours(2014-03-11)
_ 詳細設計書は死んだ。とっくの昔に死んでいる。でも生き返る必要はある 流儀や呼び名はいろいろあるだろうが、ここでは3種類あることにする。 ・要件定義書 要件を定義したもので、ユースケースについて記述したものだ。 ・機能設計書 要件を機能として記述したものだ ・詳細設計書 機能を実装に落とし込むものだ で、詳細設計書って何それおいしいの？ ということだが、もちろん不味い。むしろ毒だと言うべきで、そんなものを記述するよりさっさとプログラムを書けば良いし、その時間を使ってテストプログラムを書けばさらに良い。 特に、1990年以降、オブジェクト（あるいはクラス）ライブラリが拡充され、APIがほとんどなんでもやってくれて、コンポーネントがそこら中に転がり始めてからは、単にそれらをグルーでつないでいくのがほとんどなのだから、そんなものを書いてもまったく意味がない。 しかし、実はそう単純でもない。 問
ソフトウェアのアップデートとウェブサービス運用における継続性リスクについて - kazuhoのメモ置き場
Webサービスのようなプロダクトについての議論について教えて下さい - Kentaro Kuribayashi's blog で呼ばれたような気がしてたけど放置してた。でも今日、express という node.js 上で動作するメジャーなウェブアプリケーションフレームワークを作っているチームが、次世代の製品に取り組み始めたと聞いたので、メモを以下に貼ります。 ------------------------------ ✂ ------------------------------ ソフトウェア技術の配布手法のトレンドは以下のように推移してきた。 プロプライエタリ（仕様も実装もベンダー固有） オープンシステム（仕様は共通、実装はベンダー固有） オープンソース（実装を皆で共有） ハードウェアにしても、プロプライエタリから業界標準主導なアプローチにかわってきている。 つまり、時代とともに、
The Product Owner Problem
“We’re really struggling with the Product Owner concept, and many of our Scrum teams just don’t feel very productive.” they told us. “We’d like you to take a look at this and make some recommendations.” The company had several vertical markets, with a Scrum team of about ten people assigned to each market. Each market had a Product Manager, a traditional role found in most product companies. The c
終わるSIerの底辺を見てきた - ミッションたぶんPossible
ご挨拶 今月の第二日曜日は3月11日でした。言わずと知れた、あの「3.11 東日本大震災」から丸一年が経過した日です。改めまして、当時亡くなられた方々のご冥福をお祈り申し上げます。また、被災され現在も不便な暮らしを強いられている大勢の方々にお見舞い申し上げます。一日も早く元通りの日常が送れるようになることを願って止みません。 3.11の14:46、オレは代休で自宅にいるところにあの大地震がやってきました。自身が立つこともままならないような衝撃の中、不安定なテレビ台とPC棚をなんとか抑えて揺れが収まるのを必死で耐えたのは、今でも鮮明に思い出すことができます。それもあって我が家の被害は全くなく、妹も職場の方の好意で車で送って貰え、日付が変わった頃に無事帰宅できました。都内では翌日昼を過ぎても帰宅できなかった人が多かった中、我々は非常に運が良かったと思います。 はじめに さて、オレにとって、この
家の設計費とソフトウェアの設計費 - biac の それさえもおそらくは幸せな日々@nifty
注文住宅を建てるときのお値段。 もちろんピン・キリありますが、 まぁ普通レベルで坪60万円として、 建坪 33坪 ( 110m2 ) の家を建てると、 ざっと 2000万円です。 ところで、 2000万のうち、 設計費用は幾らぐらいでしょう? だいたいの標準としては、 設計士 29人・日くらい掛かり、 100～150万円といったところなんだそうです。 ※ 参考: 辻建設一級建築士事務所 - 標準業務人・日数 ※ 実際には、 それでは高いと言われるのでしょうか、 一括請負の見積書の場合はそれよりかなり低い内訳金額が提示されることが多いようです。 ちなみに、 今の家を建てたとき、 たしか 50万円だったと記憶してます。 さて、 ソフトウェア開発のお値段。 業務用のアプリケーションをゼロから開発すると、10画面くらいのもので、 1500万円くらいです。 「へぇ～、 十数画面くらいのアプリと、 家
業務システム設計に関する本 - プログラマの思索
業務システムの要件を定義して設計する手法は、プログラミング手法とは大きく異なる。 プログラミングはオブジェクト指向がベストプラクティスだが、要件定義や設計の手法は日本独自のDOA(データモデリング)の方がやりやすいような気がしている。 特にRailsという優れたWebフレームワークが出現して、データモデリングの重要性が増してきたように思う。 理由は、テーブル設計さえできれば、マイグレーション機能によってDBスキーマを一発で生成できるし、scafold機能によってテーブルのCRUD画面はあっという間に実装できるからだ。 つまり、テーブルさえ作れれば、業務システムをWeb上で動かして簡単に理解できるようになってきた現状があるからだ。 僕が今まで読んできた本の中で、自分が役に立ったと思う本を列挙しておく。 【1】グラス片手にデータベース設計編 グラス片手にデータベース設計~販売管理システム編 (
スタートアップ企業で8年間Webの開発をしてみての反省点いろいろ - Masatomo Nakano Blog
2002年、当時設立したばかりの会社に入り、何もない状態から、コンテンツとシステムを作り続け8年が経った。日々、試行錯誤しながら、それなりに会社も大きくなり、まだ、大成功とは言えないけど、それなりにうまくやってきたつもりだ。 しかしながら、その8年という短くはない時間の中で、色々な課題や問題が発生し、その時々正しい選択をしてきたつもりだったけど、反省点も多い。もう一度スタートアップに参加するとしたら、やり直したいところや、もっと早くこうしていれば良かったというところがたくさんある。 そんなわけで、次の挑戦のときに忘れないように、また、もしかして誰かの参考くらいになればと思い、メモっておくことにした。1 まず、反省点の前に、何をやっているのかというのを簡単に。 ビジネスとしては、英語e-learningのWebサービス(ネットを使った英語のお勉強)をASPな形で、企業や大学などに提供している
Joel on Software - やさしい機能仕様 - パート 1: なぜわざわざ書く必要があるのか?
Joel Spolsky ジョエル・スポルスキ 翻訳: Yasushi Aoki 青木靖 2000/10/2 The Joel Testを発表したとき、読者から寄せられた最大の不満の種は、仕様書を書かなければならないということだった。仕様書はデンタルフロスみたいなもので、みんな書かなきゃいけないと思ってはいるが、誰も書かない。 なぜ人々は仕様書を書きたがらないんだろう? 人々は仕様書作成フェーズを飛ばせば時間を節約できると主張している。彼らは仕様書作成がNASAのスペースシャトルのエンジニアか巨大な保険会社で働いているような人たちのための贅沢品であるかのように振舞っている。戯言だ。何よりも仕様書を書かないというのは、あなたがソフトウェアプロジェクトに持ち込む、最大かつ不必要なリスクである。それは着替えだけリュックに詰めて、その場になれば何とかなることを期待してモハーベ砂漠の横断に出発するの
ソフトウェアの設計とリズム：An Agile Way：オルタナティブ・ブログ
yachさんのブログより。 http://d.hatena.ne.jp/yach/20060927 ソフトウェアの変更は、そのソフトウェアに関わる人間の活動によって発生する。人間の活動には周期があり、その周期によって発生する変更の内容も変わってくる。変更は種類に応じて周波数を持つことになるので、その周波数をソフトウェアの設計で考慮することで、「変更を予測」せずとも、変更に強い設計が得られる。 そういえば、この「変更周波数」というアイディアは、ぼくも考えたことがあった。 http://blogs.itmedia.co.jp/hiranabe/2005/08/_eocease_of_cha_602c.html yachさんは、この周波数が「人間活動」に関連していることに気づいている。 また、これらをふまえた、ぁまんにょさんの「リズムについて」 http://d.hatena.ne.jp/ama
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
システム開発 | :::: init.D 開発実績 ::::
Access to This Page Has Been Blocked
いまだにSE・PGな発想から抜け出せないSI業界？
Site Under Maintenance
