こちらの勉強会で話した資料です。 http://dev-revolution.doorkeeper.jp/events/8881 勉強会のまとめはこちらです。 http://togetter.com/li/631383
「納品のない受託開発」の先にある「エンジニアの働きかたの未来」
こちらの勉強会で話した資料です。 http://dev-revolution.doorkeeper.jp/events/8881 勉強会のまとめはこちらです。 http://togetter.com/li/631383
世界中のソフトウェアアーキテクトの知見や助言がまとめたられた書籍「ソフトウェアアーキテクトが知るべき97のこと」がウェブ上で無料公開中
By tec_estromberg ソフトウェア開発のプロジェクト内で、ビジネスとプログラミング両方の知見が求められるのがソフトウェアアーキテクトで、彼らはプロジェクトを成功に導き、同時に利害関係者のニーズも満たすべく奔走する必要があります。そんなソフトウェアアーキテクトが知っておくべきことをまとめた書籍が「ソフトウェアアーキテクトが知るべき97のこと」で、世界中のソフトウェアアーキテクトが経験から得た知見や同業者へ送った助言がまとめられているのですが、これがウェブ上でも無料で見られるようになっています。 ソフトウェアアーキテクトが知るべき97のこと http://ソフトウェアアーキテクトが知るべき97のこと.com/ 掲載されているエッセイは全部で108個あり、その中でも海外のソフトウェアアーキテクトによる「知っておくべきこと」が97個、日本人アーキテクトによるものが11個あります。 外
銀行再編の裏、勘定系システムめぐるITベンダの死闘 みずほ大障害呼んだ富士通のエゴ
金融庁の畑中龍太郎長官（当時）は昨年1月15日に全国地方銀行協会､翌16日には第二地方銀行協会に出席。居並ぶ銀行トップに向かって「業務提携、経営統合を経営課題として考えていただきたい」と異例の発言をした。金融業界関係者の間では「今年は答えを出す年にしてほしい」と強い口調で迫ったと伝わっている。昨年7月に長官を退任した畑中氏が仕掛け、同年10月に就任した後任の細溝清史氏がダメ押しの口先介入をしたことで、地銀再編にようやく道筋がついた。地銀トップは今年、その本気度が試されることになった。 すでに関東では、地銀首位の横浜銀行（横浜市）が第2地銀の東日本銀行（東京都）と2016年4月に経営統合することで合意。横浜銀が口火を切るかたちで、関東で「玉突き」再編が始まった。 生き残りを懸けた地銀の再編は、預金データを管理する勘定系システムの優劣が問われる闘いでもある。全国に105（上場しているグループ・
発注者として最低最悪、公共機関のシステムをどうするのか
システム開発において発注者責任の自覚やその能力が無く、丸投げしかできないにもかかわらず、お客様は神様であることを信じて疑わず、買い叩くことだけに血道を上げる。しかも開発プロジェクトの最中に要件はどんどん膨らむが、追加料金は出さないし、納期厳守も要求。当然プロジェクトは破綻を来すが、その責任の全てをITベンダーに押し付ける。 こんな危ない客がいたら、ITベンダーはその開発案件を取りに行くだろうか。普通はスルーだ。諸般の事情で商談に参加しなくていけなくなったとしても、“法外な”高値を提示するなどして、間違っても受注しないように努力するだろう。そもそも今どき、そんなとんでもない客がいるのか。それが、いるのである。官公庁をはじめとする公共機関だ。 公共機関だとすると、冒頭に書いた客としての振る舞いは、その多くが「とんでもない」ではなく正当な行為となる。公共系システムは国民・住民からの税金などで作る
トレタのシステムアーキテクチャと恵比寿のメシと酒 : TORETA（トレタ） ブログ
ちわす。11月にサーバサイドエンジニアとしてジョインした佐野です。前職ではウェブサービスやソーシャルゲームのサーバ管理、DBA、運用ツール開発など主にインフラ面を担当していました。入社一ヶ月のペーペーでございます。 「ブログ書けやー」とのお達しが出たのですが、ノリがイマイチわからんので、軽い記事(恵比寿のメシと酒)と真面目な記事(トレタのシステム)を両方書きます。真面目な話の合間にメシの話でもしながら...。真面目な記事はエンジニア職向けの内容になります。 ではよろしくお願いします。 トレタのシステムは種々のクラウドサービスで成り立っています。この一ヶ月で僕がシステムに手を加えた部分としては、監視周りの整備(Pingdom, PagerDuty導入, 監視用hubotを書く)、ログ解析基盤の構築(fluentd -> BigQuery連携)、ちょっとした負荷分散(リバースプロキシを少々)を
システム開発に欠かせない契約の基礎知識まとめ - GoTheDistance
先日識者の方に色々教わったのでメモっておきます。知ってそうで知らない、元々よくわからない、そういう方に向けてまとめてみました。 僕がSIにいた頃は大抵｢基本契約｣と｢個別覚書｣ってのがありました。納期とかお金とかそういうのは個別覚書に書かれたりしていました。 開発の契約体系 ｢仕様策定〜開発まで｣と｢保守運用｣で別契約にすることが多い。 ｢仕様策定フェーズ｣で1つの契約にして、別に新しく契約を締結しなおせるほうが望ましい。リスクが低減できる。 仕様策定までは準委任、開発は請負、保守運用は準委任という契約が多い。 ちなみに準委任は｢事務作業の代行｣という意味合い。委任は｢法的効力がある作業｣の代行。サムライビジネスは後者が多い。 別に運用が事務作業とイコールじゃないけど、成果を問わないタイプの契約の場合は役務提供という位置づけになる。 かといって契約で｢僕らのコンサル案を僕らが実施し成果が出
俺の価値創造契約
〜新しい契約形態での受託開発サービス立ち上げ 1,396日間の記録〜 2010年11月に「価値創造契約」を発表してから4年。数案件を実施し、さまざまな経験をしてきました。その貴重なエピソードを発表します。 @XP祭り2014
永和さんの「価値創造契約」が大苦戦を強いられている件 - GoTheDistance
この資料、非常に衝撃的だった。中の人がここまで公開していいものなのか、という意味でも。 俺の価値創造契約 from Fumihiko Kinoshita 永和さんの価値創造契約とは 新しい契約形態での受託開発サービス「価値創造契約」 ｜ 永和システムマネジメントに詳しくありますが、簡単にいえば「初期費用無料で、常に改善・運用をしながら月額定額制でシステム利用料を頂く」というビジネスモデルです。価値あるシステムは必ず長く使われ変更を伴うのだから、その変更を受け入られるモデルを提供すれば双方にメリットがある。これが立脚点のようです。 2013年営業実績、0件 資料によればテレアポを800社行い、様々な展示会にも出展されたそうです。12社にコンタクトできたけれど受注は0件だと書いてあります。マーケティングに失敗してしまったと言って良いでしょう。 受託開発の弊害と指摘される「価値あるシステムを作り
従来型のSIビジネスはなぜ立ち行かなくなるのか～斎藤昌義×倉貫義人『受託開発のこれからを考える』レポート - エンジニアtype | 転職＠type
2014.09.15 働き方 SIビジネスが直面している問題、ビジネスモデルの未来を危惧する声が聞かれるようになって久しいが、実際のところ、問題の本質をどう理解し、どのように解決への筋道を立てていけば良いのだろうか。 弊誌ではこのほど、くしくもほぼ同時期にこの問題と正面から向き合った本を上梓した斎藤昌義（『システムインテグレーション崩壊』）、倉貫義人（『「納品」をなくせばうまくいく』）の両氏を招き、『受託開発のこれからを考える』と題したイベントを開催した。その模様を2回にわたってレポートする。今回は、イベント前半で両氏が行った、従来型SIビジネスに対する問題提起のパートを詳報しよう。 ネットコマース株式会社 代表取締役 斎藤昌義氏 1982年、日本IBM入社、営業として一部上場の電気電子関連企業を担当。営業企画部門に在籍の後、同社を退職。1995年、ネットコマース設立。産学連携事業やベンチ
IT業界の『多重下請け構造』は社会悪になりつつある - paiza times
Photo by Jonathan Kos-Read 今回のpaiza開発日誌は片山がお送りします。 SIerについて語られる際にIT業界の「多重下請け構造」についての問題点が良く取り上げられますが、「多重下請け構造」がITエンジニアにとってどのような問題点があるのでしょうか？ その点について今回は少し整理してみようと思います。 ■「多重下請け構造」とは何か 説明するまでもないかもしれませんが、「多重下請け構造」とは、受託システム開発において、発注者から直接仕事を請け負った元請（たいていの場合が大手SIer）が、請けた仕事を切り出して2次請け、3次請け、4次請けと仕事を下ろしていくピラミッド構造の事を言います。 良くある例で言うと、元請は要件定義や概要設計等の上流工程を請負い、開発・実装などの下流工程は2次請けに委託する、というような構造です。2次請けは自社リソースで開発を賄えない場合に3
クックパッドとマイクロサービス - クックパッド開発者ブログ
技術部の高井です。 最近、日本でもマイクロサービスという言葉が流行しつつあります。 今回は、なぜクックパッドがマイクロサービスを選択したのか、また実際にどのようなやり方をしているのかということを紹介します。 Conwayの法則 ここ数年の間、クックパッドはレシピの投稿・検索サービスから「食を中心とした生活のインフラ」として事業領域を拡大しつつあります。海外レシピサービスの買収による海外展開は、単なる金銭的な関係にとどまらず、人的・技術的な交流も含めて本格化しつつあります。また、「モバイルファースト」を標語とするモバイルアプリケーションへの取り組みも加速してきました。 事業領域の拡大やグローバル展開、モバイルファーストといったビジネス要求の変化に応じて、会社の組織構造も変化しています。そして、Conwayの法則 として知られているように、組織構造とソフトウェアアーキテクチャには密接な関係があ
HTML5が変える、エンタープライズITの可能性とこれから
こんにちは、川田です。今日からHTML5 Experts.jpでは「エンタープライズ開発特集」を始めます。第一弾の今回は、HTML5とエンタープライズITについてのオーバービューを語ります。サーバサイドのお話はわりとよく見ますが、フロントエンドにフォーカスしているというのは珍しいようにも思えますね。 IT自体が幅広い分野のビジネスや製品に変わりつつある昨今、「エンタープライズITの話をするぞ！」と言うと、いろんな方面の人からこう問われます。 「そもそも、エンタープライズって何？」 エンタープライズ、正式には「エンタープライズシステム」になりますが、直訳すれば「企業向けシステム」。一言で言うなら「企業のビジネスを支えるための仕組み」を意味します。企業の業務の効率化を進めたり、経営戦略や問題解決を進めるためのワークプロセス(仕事の進め方)と道具(アプリやインフラ)のことです。 エンタープライズ
Javaの型システムとコンストラクタ - プログラマーの脳みそ
今回はJavaの型システムのコンストラクタについて考えてみたい。 Javaの型システム、あるいはJavaのオブジェクト指向において、コンストラクタという存在は特殊な存在だ。 コンストラクタ内からはそのクラスのインスタンスフィールドにアクセスできる。これは通常のインスタンスメソッドと同等のスコープであってstaticメソッドのそれとは異なる。しかし、コンストラクタを呼び出すにあたってはインスタンスのメソッドという体ではなく、staticメソッドのように（インスタンスではなく）クラスに属するものとして呼び出すことになる。（もっともnewという専用のキーワードを用いるのでそうは見えないかもしれないが） クラスやinterface、つまりJavaの「型」によるポリモフィズムの世界を考えるとき、コンストラクタはのけものである。継承関係を持つクラスであってもコンストラクタは継承されないし、オーバーライ
Amazon Web ServicesでサーバサイドJavaの実行環境を構築しよう
はじめに 前回は、AWSの提供する仮想サーバサービスであるEC2を使ってWebサーバを構築する手順をご紹介しました。今回は、AWSでWebアプリケーションサーバとデータベースサーバを構築し、サーバサイドJavaのプログラムを動かすためのインフラ構築手順を説明します。 対象読者 本記事は、次の方を対象にしています。 クラウドシステムがはじめての人 JavaによるWebシステムのプログラミングを行ったことがある人 システム基盤について勉強したいと思っている人 データベース連携するWebアプリケーションの構成 AWSのサービスを使って、データベース連携するサーバサイドJavaのWebアプリケーションを実行する環境は、いくつか考えられます。AWSでは前回ご紹介した仮想サーバサービスのほかに、リレーショナルデータベースの機能を提供する「RDS」や、PaaSサービスである「Elastic Beanst
「システム･インテグレーション崩壊」のすすめ | ネットコマース株式会社
「システム･インテグレーション崩壊」は、時間の問題です。むしろ積極的にSI事業者自らが、この創造的破壊に取り組んでゆくことが、最良の生き残りの選択肢ではないかと考えています。 SIビジネスの課題は、Pay for Time (人月単価の積算で金額が決定するビジネス)であるにも関わらず、成果保証(瑕疵担保責任)を負わされることです。
システムの「価値」をどう考えるのか？〜なんで人月換算基準がなくならないか、について - 急がば回れ、選ぶなら近道
「なんで人月換算基準がなくならないか」については、これは作る側での議論が非常に多いのですが、逆側から見た議論があまりにも少ないので、自分の考えを記録しておきます。そもそも、発注した側ではシステムの価値をどう見るのか？という議論があまりにもなさ過ぎの印象があります。いくら作る側が頑張っても、発注サイドで「いやだから、結局いくらかかったか内訳見せろ」という話になった途端に、残念ながら人月単価が登場するわけで、話は振り出しに戻ります。 まず一義的にはユーザーから見たシステム開発は投資になります。確かに、毎年作っているでしょう、という話もありますが、普通は数年に一回作っては動かして、メンテナンスにモードに移行させる、という形になります。投資として、通常はキャッシュ・アウトに相当するコストで資産を認識します。リースにすれば、定常的でしょうという話もありますが、オン・ブックになった途端に普通に取得原価
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
納品のない受託開発を支える レガシーコードを作らない仕組み
July Tech Festa 2014 大規模エンターテイメントサイトを支える技術
システムアーキテクト~My batis編~
COBOLで書かれた米国防総省の給与システム700万行、実質的に更新不可能 | スラド IT