「クラウド化は、コスト削減のためとちゃいます」 東急ハンズ・長谷川秀樹氏がAWSイベントで語る
東急ハンズにて情報システムと通販事業の責任者を務める長谷川秀樹氏が、AWS Cloud Roadshow 福岡 powered by Intel に登壇。大手小売企業が仮想サーバを導入するにあたって注意した点、また新しく気がついた点を具体的に列挙。後発組へもAWSの採用を勧めました。 東急グループにおける情シスの責任者が登壇 長谷川秀樹氏：東急ハンズ、長谷川でございます。よろしくお願いします。「一体何者やねん？」っちゅうところなんですけども、東急ハンズで情シス（情報システム）と通販事業の責任者をやっています。ハンズラボという会社で、これSI（システムインテグレーション）の会社なんですけど、そこで代表やらさせてもらっています。 あとは東急不動産ホールディングスのほうで、マーケティングIT戦略部長みたいなのもやらさせてもらっています。今日はどっちかと言うと、ユーザー企業の情シス部長みたいな感じ
Git入門 v1.1.0
Frontrend Vol.6 powered by CyberAgent, Inc. http://frontrend.doorkeeper.jp/events/6907 で発表したプレゼン資料です。 こういう資料に対する投げ銭的なのがどうなるのか気になっていたので、もしよろしければ・・・！15円からできるソーシャルカンパサービスだそうですm(_ _)m http://kampa.me/t/dev
Rubyist Magazine - スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0063 号 バックナンバー Rubyist Magazine 0063 号 Rubyist Magazine 0062 号 Kaigi on Rails 特集号 RubyKaigi Takeout 2020 特集号 Rubyist Magazine 0061 号 Rubyist Magazine 0060 号 RubyKaigi 2019 直前特集号 Rubyist Magazine 0059 号 Rubyist
ソフトウェア開発プロセス残酷物語 - give IT a try
昔々、あるところにジェイソンという、大変真面目な開発者がおりました。 彼がとある会社の情報システム部にやってきたとき、彼は社内システムのクオリティのひどさに衝撃を受けました。 情報システム部といっても、その会社では外注はせず、社内の開発メンバーがシステムを作っていました。 ジェイソンがそこで最初に担当したシステムは、見事なまでのスパゲッティコードでバグだらけ、データ設計も素人レベルでパフォーマンスも最悪、エラー処理もずさん、おまけにまともなドキュメントもなく、ちょっとした障害を調査したり、小さな改造を実施したりするのにも、大変な苦痛を伴うという、それはそれは大変なシロモノでした。 このシステムは元々エセーグルという、ちょっと変わった名前の開発者によって作られていました。 しかし彼はすでに別の開発チームに異動していて、こちらの質問には答えてくれますが、もはや本人が直接手を動かすことはありませ
WEBシステム開発の値段
1 名前:以下、はてなにかわりまして元増田がお送りします。 投稿日:2012/02/23 11:49:47うちの団体で、インターネットで講習会を申し込めるようなシステムを作ることになって、ネットで調べた何社かに見積りを頼んだら、出てきた金額が業者によって２５万～４００万で出てきた。 見積りの項目も各社バラバラだしそれぞれの意味も、なにがなんだか素人の俺にはさっぱりわからない。 年間に１万人ぐらいが100会場でやる研修の申込みを受付けられるようにするってだけの機能なのになんで各社こんなにもバラバラなのかが理解不能。 若いってだけでITに詳しいと思われて、担当にあてがわれて、２５万～４００万の間で業者決める手掛かりが全くない状態でどうすればいいんだ？（それでもし業者選びに失敗したらやっぱり俺のせいなのかな。。） 続きを読む
いわゆる仕様と業務例外について - 急がば回れ、選ぶなら近道
最近とにかく、移動が多いので、その中でちょいちょい考えたことをまとめておきます。まずは仕様の理解の仕方とか、業務例外とか、押さえておきましょうという視点から。別にこれが正解で必須というわけではないので、あくまで個人の経験をまとめただけです。 モデリングとか、なんというかそういう高尚な話ではなくて、実際に仕様をまとめるときに、現実的に落ちる穴を、経験的に書きます。大抵のプロジェクトでは、仕様が固まらずに、または手戻りが発生して酷くコストが膨らむということがやはり多いわけで。理屈はともかく自分の経験的な対策案です。 （なんというか、開発方法論や手法・ドキュメントのまとめ方は、なんとかBOKから始まって、アジャイルや押しくらまんじゅうやらでいくらでもであるのですが、その一方で丁寧な要求定義や設計それ自体ができる人材は、むしろ急激に減っているような印象すら受けます。海外からの翻訳や輸入はやたらと多
特許庁の基幹システム失敗の背景にある、日本におけるITプロジェクトの実態
今週月曜日に公開した記事「特許庁の基幹システムはなぜ失敗したのか。元内閣官房GPMO補佐官、萩本順三氏の述懐」は、記事に対して数多くのブックマークやツイートが行われ、大きな反響をいただきました。 その萩本氏から「問題提起だけで終わるのではなく、こうあるべきだという提案もしたい」、という依頼をいただいたので、記事にいただいた反響への返答という意味も込めて、萩本氏の提案についても掲載したいと思います。 以下からは萩本氏の文章となります。 これまでのIT業界の慣習を捨て去り、あるべき姿へ 僕が日記（注：記事の元になったFacebookへの書き込み）を書いたのは、二度とこのような案件が出ないよう本質的な問題提起をしようと思ったからです。 それが僕の責任だと思いました。 本質的問題を提起したつもりですが、しかし本当に理解していただいたのかというのが心配でもあり、また理解していただいたとしても、今後何
特許庁の基幹システムはなぜ失敗したのか。元内閣官房GPMO補佐官、萩本順三氏の述懐
特許庁が進めてきた基幹系システムの刷新プロジェクトが失敗に終わり、開発に投じた約55億円が無駄になってしまったことが、先週相次いで報じられました。 ［スクープ］特許庁、難航していた基幹系刷新を中止へ - ニュース：ITpro 朝日新聞デジタル：費やした５５億円、水の泡に 特許庁がシステム開発中断 - ビジネス・経済 このプロジェクトに「内閣官房GPMO（ガバメントプログラムマネジメントオフィス）補佐官」の肩書きで2009年まで民間から参加した萩本順三氏（現 匠BusinessPlace 代表取締役社長）がFacebook上で当時を述懐しつつ、失敗の要因を分析していました。今後、失敗プロジェクトを繰り返さないためにも、重要な発言として本人の許可をいただいてまとめました。 特許庁の情報部門に幾度も中止を迫った 萩本順三氏の発言の主要な部分を引用します。 内閣官房GPMO（ガバメントプログラムマ
「無理です、ダメです、できません」＋「仕様です」で済ませないように・・・（追記あり）：田中淳子の”大人の学び”支援隊！：オルタナティブ・ブログ
わが「心の師匠」の一人に元SEの方がいらっしゃって、今、50代半ばの彼が20代のばりばりSEだったころの話。 お客様との打ち合わせで、「こういうことしたいんだけど」と言われると、つい「あ、それ、無理です」と反応し、「こんなことはできるのかな？」と言われれば、「ああ、ダメですねぇ」と答えてしまったのだそうです。 しばらくは辛抱強く相手をしてくださっていたお客様が、とうとうキレて、 「私たちは、コンピュータに関しては素人だ。だから、技術的にできるかどうかなんかわからない。でも、”したい”ことはある。あなたたちSEは、私たちが”したい”ことをどう実現するかを考えるのが仕事ではないのか。”こうすればできる”とか”こういう風に条件を変更できませんか?”とか言ってくれれば、こちらも考える。どういう風に問題解決をするか、共に考えてほしいと思って、こうやって話をしているのだ。 だから、二度と”できない”と
システムはどこまで内製化できるか - 急がば回れ、選ぶなら近道
どこでも何回も何十回も言われているが、システムを経営の変化に対応させるにはある程度のシステムの開発を内製化すべきである、という論調が強い。この問題は、古くて新しい問題であり、と同時におそらく、いままでとは違うコンテクストで語られることになるような気がしている。ここ１０数年の流れを見れば、内製化の議論はアウトソーシングの流れとそのより戻りの反復運動の繰り返しだといっていても過言ではなかったと思う。近年はむしろ、SI屋さんの全体的な弱体（特に技能として）化とクラウド等によるインフラの導入しやすさと相まって別の背景で語られることが多くなってきている。また、見逃せない背景としては、そもそもの就労可能若年層の減少と、若年層の総体数減少による能力のばらつきの顕在化も強くあげられる。特にシステム開発の供給サイドの問題は、エンドユーザーの内製化の議論においては、今までのコンテクストでは語られることがなかっ
変形 - Akiba Hideki
今回は、「設計変更」が発生したときの設計者とクライアント間のコミュニケーションを考慮しました。 あなたは、あなたのために仕事を注文するクライアントやディレクターとどのような意識を持っていますか？ たとえば、少し大規模なシステム開発の場合、「このように動くものを作る」と言った直後にプログラムを作成する開発者などはいないようです。 実際、システム開発の予算の大部分は非常に重要であるため、「設計（要件定義を含む）」に充てられています。 つまり、この「設計」フローがなければ、手を動かすことで作業することはできません（大まかに言えば）。 一般的なデザイナーの仕事には大きな懸念があります。 つまり、「要件を設計および定義するためのフローなしで設計を行う設計者が多すぎます」。 現在、特にWeb制作では、「デザイナーと開発者」は異なる次元の人種のように切り離されていますが、それは本当ですか？ 私はデザイナ
ホーム - ウェブパッケージ
整理され、シンプルで、使い勝手が良い。メトロスタイル（カードスタイル）は、すべてのメインコンテンツが配置されたセクション（カード）を使ってサイト構造を構築するという原則に基づいています。
工数見積もりで陥りやすい罠 - プログラマの思索
「ソフトウェア見積り」を読んだ後に「アジャイルな見積りと計画づくり」を読み直したら、とても理解しやすかった。 理解できたことをメモ。 間違っていたら後で直す。 ※追記：一部修正した。 ※追記：Velocityの計算方法を「塹壕よりScrumとXP」から参照するようにした。 【元ネタ】 Twitter / @akipii: 見積について色々考えている。1.0MD(人日)という単位は規模・出来高・工数という複数の意味を持ち混乱しやすいから、ソフトウェア開発の計画づくりに支障をきたしているのではないかという仮説を考えている。その考えを深めるとScrumのストーリーポイントはよく考えられた概念だと思う。 アジャイルサムライで一番難しくて面白い概念～Velocity: プログラマの思索 ソフトウェア開発に特有な技術～ソフトウェア見積り: プログラマの思索 チームは加速するのか～Velocityの使い
「絶対落ちないシステムを作れ」という要件に、開発者たちはどう対応したのか。東証arrowheadの当事者が語る
「絶対落ちないシステムを作れ」という要件に、開発者たちはどう対応したのか。東証arrowheadの当事者が語る 「素人的に言えば、絶対落ちないシステムを作れ、というのがユーザーから見た要求条件」と発言したのは、東京証券取引所の株式売買システム「arrowhead」開発のプロジェクトマネージャ 宇治浩明氏。 東京証券取引所は2005年にシステム障害を起こし、取引が一時全面停止するという事態を引き起こしました。そのため2010年に稼働を開始した新システム「arrowhead」の開発では、高性能と高可用性という高い品質を実現することが絶対の目標となっていました。 東京証券取引所と、arrowheadの開発に当たった富士通。両社はどのように開発プロジェクトを通して高いソフトウェア品質を実現したのでしょうか？ 9月9日、早稲田大学 西早稲田キャンパスで行われた日本科学技術連盟主催「ソフトウェア品質シ
DeNA&GREEの海外展開についてまとめてみた【田中翔太】 | TechWave（テックウェーブ）
これまで何度もTechWaveに寄稿していただいている大学生の田中翔太さんから寄稿頂きました。「まとめてみた」というだけあって充実のボリュームです。リファレンスとしても是非お使い下さい。（本田） どうも、ご無沙汰しております。@edy_choco_edyです。（編注：前回の記事は4月23日） 先日（2011年9月8日）、GREEの時価総額がDeNAを抜いたことが話題になりました。正確には2009年にGREEのほうが上位だったことがあるため「抜き返した」ということになります。（2011年9月12日には再びDeNAが逆転しましたが、僅差です）。 時価総額の話題ひとつとっても大きく取り上げられるこの2社。その競争がSNS、ソーシャルゲーム業界、さらにコンソールゲーム業界に与えている影響は、賛否両論あれど非常に大きく、今後ますます目が離せないものになると言えるでしょう。 現在、この2社を語る上で欠
ソフトウェア開発者が読むべき IT系雑誌の一覧と，おすすめの読み方 - 主に言語とシステム開発に関して
中級クラス〜のデベロッパにとって，フォローする事が望ましいIT系雑誌のリスト。 また，それらの読み方。 つまり，書店における立ち読みのポイントと，購入の判断基準。 （１）Web+DB PRESS （２）Software Design （３）日経Linux （４）日経NETWORK （５）日経SYSTEMS （６）日経ソフトウェア 補足 なぜ雑誌なのか？ 読者層としては， 主にWebアプリの開発をチーム内でリードするエンジニアやアーキテクトを想定。 （１）Web+DB PRESS 雑誌のホームページ http://gihyo.jp/magazine/wdpress この雑誌の読み方： 「特集」は無条件で精読する。 「プログラミング言語の記事」は，下記の点に注目して把握する。 言語の癖や特色，他の言語と差異化するファクター その言語から，あるサービスを利用するためのAPIの存在 バージョンアッ
「思いつく人はたくさんいるが、実際に作った人はごく少なかった」 “学び”を流通させる「Cyta.jp」
「思いつく人はたくさんいるが、実際に作った人はごく少なかった」 “学び”を流通させる「Cyta.jp」（1/3 ページ） ネットで探したさまざまな分野の先生から、好きな場所、好きな時間、割安な料金で高品質な個人レッスンを受けられる――そんな“プライベートコーチ”サービス「Cyta.jp」（咲いたジェイピー）が静かな人気を集めている。2009年のβ版公開以来「ほぼ口コミだけ」で受講者を増やし続け、今年6月に正式オープン。総受講者数は1万人を突破した。 学べるジャンルは語学や楽器、資格など100以上。レッスン会場は全国1700カ所のカフェやレンタルスペースだ。ユーザーは希望する場所や時間をWeb上で入力すれば、厳しい採用試験を通過しているプロの講師と1対1の対面レッスンを受けられる。レッスン後はSNS風の「マイページ」で、メッセージのやり取りや写真の共有などを通じて講師と継続的にコミュニケーシ
要求工学 第12回：シナリオ分析(エンタープライズICT総合誌 月刊ビジネスコミュニケーション)
概要 今回はシナリオを用いた要求分析手法について紹介する[1]。シナリオは問題自体を分析するための手法である。シナリオはヒューマンインタフェースなどの人間工学分野でも使われており広い適用範囲を持つ。 欧州では要求仕様を記述するのにシナリオが従来からよく使われている。たとえば業務情報システムの開発でビジネスプロセスを厳密に記述するために、ビジネスの状態遷移を形式的に表現できるペトリネットを用いたところ、120以上のビジネスプロセスが発生し管理不可能になっただけでなく、全状態を確認することも、状態の組み合わせが爆発的に多くなりすぎて処理不能になった。このような結果になった背景には現場の担当者にはペトリネットは十分に理解できなかったことが挙げられる。そこでペトリネットの適用を断念して27 個のシナリオで本質的な利用形態を表現することで、システム開発がうまくいったという[1]。 本稿では、まずシナ
知るだけで天地の差が出る、テスト仕様書の必須項目＆表現方法
テスト仕様書で絶対に必要な項目リスト テスト仕様書に記述すべきものとして、以下の事項があります。 テストを実施した環境 実施するテストの内容 テストを実施するためのシステムの操作手順 テストの実行結果 個々のテスト項目を識別するための番号や記号（通し番号など） テストを実施した年月日 テストを実行した担当者 障害報告票番号（発生した障害の詳細を開発グループに報告する帳票の識別番号） まずはテスト環境について明記する テスト仕様書の先頭には、「テストを実施した環境」を記述します。ここでは、ハードウェア環境やソフトウェア環境、ネットワーク環境など、「どのような環境でテストを行ったか」を説明します。 ただし、テストを実施した環境を記述するだけでは十分ではありません。「顧客にとって必要な情報は何か」を考えるのです。ここで必要なのは、「要件定義書で規定した環境」との関係が分かることです。 なぜなら、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
