GitHub時代の開発委託とは？ デブサミでQA@ITの事例の話をします - QA@IT公式ブログ
2013年2月14日と15日の2日間にわたって東京・目黒で開催されるDevelopers Summit 2013（デブサミ2013）の1セッションで、QA@ITの委託開発の話をさせて頂くことになりました。 ソーシャルコーディング革命後の開発委託の世界〜QA@ITの事例（仮） 私はこれまでいつも、デブサミは取材記者という立場で見て来ました。記者として取材して、例えば以下の様な記事を書いて来ました。聴衆に混じって講演を聞く側だった私が、まさか話す側に回ることになるとはと、今からドキドキしています。 デベロッパーズ・サミット2008：すばらしいソフトを作るには、カリスマが講演 未来の言語は「APL」？ Rubyのまつもと氏が講演 IIJのRuby対応PaaS「MOGOK」は、どんなサービスか？ さて、デブサミは開発者のイベントですが、私は委託側、つまり受託開発における「お客の声」ということでお話
ウノウラボ Unoh Labs: FarmVilleの開発 - FacebookのNo.1ゲームを5週間で作りあげスケールさせた手法
こんにちは、五十川です。 2010年12月1日に、ウノウがジンガジャパンとなってから初めてのタイトルとなるファームビレッジがリリースされました。ファームビレッジはFacebookで永らくNo.1の座にあるFarmVilleの日本語版ですが、先月そのFarmVille開発のリーダーで、現在はZyngaの共有テクノロジーをリードしているAmitt Mahajanが来日していました。 今回ご紹介するのは、そのAmittが2010年3月のGame Developers Conference（GDC）で行った、Rapidly Developing FarmVille - How we built and scaled a #1 Facebook game in 5 weeksと題したプレゼンテーションです。今回Amittの許可を得てそのときのスライドの日本語版を作成しましたので、それに解説を加えてご
複数人(2-3人)でウェブサービスを開発するコツ - リート開発者ブログ
こんにちは。開発ブログ言いだしっぺの satoshi です。リートでは、AddClips と Lancers というサービスが現在の主力サービスですが、AddClips は1人のエンジニアが担当し、Lancers は2-3人 のエンジニアが開発を担当しています。 当たり前ですが、1人と3人では開発スタイルが大きく異なり、気をつけるポイントも全く違います。当たり前の事が多いのですが、リートで特に気をつけていることをご紹介できればと思います。 開発環境 VMware ESXi を使って開発環境は5秒で用意する 通常、VMwareはLinuxやWindows上で動作しますが、VMware ESXi はその上で直接、複数のVmware（仮想化マシン）を立ち上げることができます。 Vmwareを導入するために、Linuxを導入したりする必要はなく、その容量も32MBとコンパクト。しかも無償で利用可能
品質を上げたいなら、「レビュー」よりも「検討会」に力を入れよ - 現場のためのソフトウェア開発プロセス - たかのり日記
以前に、以下の記事を書きました。 進捗管理は「遅れ」か「残り」か これは、今までのやり方を少し変えるだけで、プロジェクトマネジメントの効果を向上させられる良い例でしょう。 ソフトウェア開発プロセスの中では、同様のことが言えるケースがたくさんあると思っていますが、私がこれまでに気付いたノウハウをまとめてみたいと思います。 今回は、まず、レビューについて。 レビューは、大抵のベンダー／SIerでは実施されていると思います。 レビューの目的は、上流工程における不具合の除去、要件の明確化などだと思いますが、なかなか効果が上がらないと感じている人は多いのではないでしょうか？ レビューのやり方については、議論されることも多いですが、そもそもレビューだけで問題を解決しようというのに、無理があると感じています。 そのため、私は、設計工程の最初で「設計検討会」を行うようにしています。 これは、 要件は十分に
SaaS - バグ管理/バージョン管理システム | ciklone(サイクロン)
初めてのお客様へ ciklone(サイクロン)ってなに? ciklone(サイクロン)とは、ソフトウェアに関わる人たちにとって必須の開発環境をお手軽に実現した 「SaaS版 バージョン管理/バグ管理システム」です。 もう開発環境を自分たちで整備したり、メンテナンスする必要はありません。 面倒な仕事は ciklone(サイクロン)にお任せ下さい。 多くの企業でプロジェクトがはじまるとき、ドキュメントの管理、ソースコードの管理、議事録、 大量に作成される中間成果物の管理、プログラムのバージョン管理、課題管理、 それらのバックアップと運用が必要になります。 ソフトウェアの開発をする場合、とりあえずプロジェクトをスタートすることはできますが 開発をスムーズに、品質を保つための仕組みには環境を整備しておく必要があります。 オープングルーヴは、バージョン管理システムやバグ管理システム(バグデータベース
社員２人が２カ月で完成、自前開発の喜びを取り戻す
IT研修サービス大手の富士通ラーニングメディアが2009年7月、研修受講者が利用する「新受講管理サービス」を、セールスフォース・ドットコムのPaaS（プラットフォーム・アズ・ア・サービス）「Force.com」上に構築して運用を開始した。全国6カ所の拠点で同時に1000人が利用するシステムを、2人の社員がわずか2カ月で作り上げた。＜日経コンピュータ2009年8月5日号掲載＞ 「コーディングを一切外注しない開発がこんなに楽だということを、久しく忘れていた。テスト運用中に生じた利用者の不満も、その日の内に解決できた。外注したコードを自分で修正できないことに今までどれだけストレスを感じていたか、改めて気付かされた」。富士通ラーニングメディア システム推進部で「新受講管理サービス」の開発を担当した若松英寿氏（写真）は、Force.comを使った「クラウド開発」の感想をこう述べる。 富士通ラーニング
ITでは当たり前の開発技術が組み込みでは使われていない
日産自動車による電気自動車「リーフ」の予約受付が4月1日に始まった。発売は12月になるという。リーフには、充電ステーションの位置表示など電気自動車の必須機能に加えて、携帯電話を使ったリモートコントロールでのエアコン作動など、自動車の付加価値を高める機能が搭載される予定だ。 日産リーフだけでなく、自動車にはカーナビをはじめ様々なデバイスにIT技術が持ち込まれて始めている。もちろん自動車に限らない。インターネットやほかの機器との通信/連携機能を持つ家電製品も登場している。 以前から自動車や家電製品には、組み込み（ET：Embedded Technology）ソフトウエアが搭載されており、ハードウエアを制御してきた。その基本的な仕組みは今後も変わらないが、ITと同じようにシステム間で連携するようになってきたり、ITで実績のあるプラットフォームが採用されるようになってきた点がこれまでとは違う。この
ソフトウェアのアウトソース
渡辺千賀さんのエントリーにはシリコンバレーではアウトソースが間に合わないのでどんどん内製していくという話が紹介されている。 最先端のウェブサービス開発の現場は、とてもアウトソースなんかできない状況になっている。「仕様書を文章で作って、それを誰かが作る」なんていう悠長なやり方は通用しない。どんどん機能開発して、どんどんリリースして、ユーザーのフィードバックを元にさらに進化させる、というのを、毎日行い続けないとならない。私が働いていたカナダのベンチャーもNZのテレコム系の会社も下請け、孫受けである。 どちらもインフラ系のシステムで、業務内容が大規模、複雑で仕様が比較的安定しているためか、仕様書ベースでのシステム納品を行っている。ウェブサービスのスタイルとは違う。 しかし、下請けといっても日本のそれとはかなり違っていることが経験してみて分かった。 ・上から下への丸投げはない。 ・社員の給料は上も
Joel on Software - ジョエル・テスト
Joel Spolsky ジョエル・スポルスキ 翻訳: Fukushige Erika 福重 永里香 翻訳チェック: Takeda Toshiyuki 武田俊之 9.8.2000 SEMAについて聞いたことがある？かなり難解なシステムで、ソフトウェアの開発チームがどれくらい良いかを測るためのものだ。ちょっと待った！そのリンクに飛ばない方がいい。きっと書いてあることを理解するだけで6年はかかるだろう。そこで、私は自分で作ることにした。これはソフトウェア開発チームの質を評価するものだが、とっても当てにならないいいかげんなテストだ。このテストの素晴らしいところは、3分程度で終わることだ。節約した時間を使って、医学部に通うことだってできるだろう。 ジョエル・テスト ソース管理システムを使っているか？ １オペレーションでビルドを行えるか？ 毎日ビルドを行うか？ 障害票データベースを持っているか？ 新
前向きなヒューマンエラー対策をしよう。 - Sacrificed & Exploited
SIerが仕切っている開発現場でありがちなのが、何かミスを犯すと、そのミスを防止するようにすごく手間がかかるチェックが追加されて、開発効率とモチベーションが下がるというダメなパターン。 たとえば、「今年度は申請書(EXCELシート)書いて上司の判子もらわないと svn commit すらできない職場で仕事することになりました。 - SiroKuro Page」とか。 これはプロセスマネジメントでもなんでもない、管理ごっこだ。管理したつもりになって自己満足しているに過ぎない！！ プロセスをマネジメントしたければプロセスを削れ: DESIGN IT! w/LOVE では、次のように述べられている。 プロセスマネジメントにありがちな間違いのひとつに、ミスを減らそうとして、そのチェックをするプロセスを増やしてしまうということがある。 もちろん、すべての場合にそれが間違いというわけではない。 そのチ
ソフトウェアプロダクトラインが組込み企業の技術力を左右する - プログラマの思索
チケット駆動開発でアジャイル開発を運用すると必ず並行開発が現れる。 並行開発、ソフトウェアプロダクトラインの関係について連想した事をメモ。 【元ネタ】 ソフトウェアプロダクトラインを考えるセミナーに参加 - Basic CACM の特集記事：ソフトウェアプロダクトライン工学(1) - IT、アイスホッケーそしてヒップホップのある日常 衛星標準プロセス展開支援 成果報告 【1】Redmineでチケット駆動開発をアジャイル開発っぽく運用すると、必ず2個のコードラインを保守するようになり、自然に並行開発になる。 つまり、リリースした本番システムはリリースブランチ、裏で機能改善中のシステムはtrunkの2本を常時保守しなくてはならない。 特にアジャイル開発を実践すると、2～4週間のサイクルで小刻みにリリースしていく為、リリースしたコードラインと次のイテレーションのコードラインの2本を並行で作業しな
ロートルの嘆き、アジャイル開発って何 - 未来のいつか/hyoshiokの日記
20数年前に大学を卒業しプログラマになって、この変化のとっても早い業界でまだ禄を得ている。最近でこそコードを書くことはないが（今でも職業としてコードを書きたいと強く思っている）、それでも、ソフトウェア開発について20数年前に得た知識、経験、スキルが役に立っているように思える。 日進月歩で日々新しいバズワードが登場し、若い人たちはそれをフォローするのにひーひー言っている。クラウドだアジャイル開発だなんだかんだ。 プログラマの一日は、会社に来て、テストを書いて、テストをして、不具合があればコードを修正し、またテストをして、問題がなければコード管理システムにチェックインする。その作業を淡々と日々こなす。この日常の流れというのは、使う道具立てこそ変わったとしても、基本的に変化がないように思える。コードを書くのは20数年前も今もプログラマだし、テストを書くのもそうだし、テストを自動化することは20数
システム開発ジャーナル Vol.12が25日発売 - 特集は「開発ツール連携」 | エンタープライズ | マイコミジャーナル
システム開発ジャーナル Vol.12 毎日コミュニケーションズは12月25日、季刊のITプロフェッショナル向け専門誌『システム開発ジャーナル Vol.12』の発売を開始する。価格は1,880円。判型はB5正寸で、全国の主要書店やネット書店にて販売される。 同誌は「価値を"創造"するITプロのための技術支援情報誌」として、主に開発現場の上流工程を担当する人材や、ユーザー企業の情報システム部門に従事する読者層をターゲットとしている。 Vol.12の特集1は「開発ツール"連携"活用術」。 本特集はEclipseやSubversion、Trac、Maven、Hudsonといった現場でおなじみのツールを使った効率的な作業の実現を目的とし、各ツールの連携活用方法が一挙に紹介されている。また、注目度の高まりを見せている分散型バージョン管理システム「Git」の活用方法も網羅されており、保存版的内容となっ
HELP ME!とは!? - Fly me to the Luna
オブジェクト倶楽部の中の人、こんぴろです。 7/7のオブジェクト倶楽部で1セッション持つことになりました。先週素振りをしてみました。思いのほか好評です。 HELP ME!に参加したオブラブスタッフの喜びの声 本音モードの私の悩みを、他の人がズバッと斬ってくれました。信じられないぐらいの効果がありました。自分が箱を作ってそこに閉じこもっていたのかがはっきりと感じられました。素振りであることも忘れ、kompiroさんそっちのけで盛り上がる30代男性たち。終わるころには、握手をしていました。 今回は、中の人での素振りだったので盛り上がったのかもしれませんが、効果は強力です。ぜひ皆さん参加してください。私も、このワークショップに参加して、自分の悩みと喜びを分かち合いたいです。 「HELP ME!」ワークショップ - ぁまんにょですぅ〜 「HELP ME!」というワークショップの素振りに参加したんで
開発プロセスと技術の相関関係 - rabbit2goのブログ
上手くソフトウェア開発が出来るチームは、開発プロセスも良好だし、技術・スキルもそれなりに高いようだ。細かく見ていけば問題が無いわけではないけれど、それらは許容範囲内に収まっているし、絶えず改善活動を行っているせいか昨年の状態より良くなっていることが明らかだ。「良好なプロセス→高いレベルのアウトプット→さらにスキルアップ」という正のサイクルがうまく回っているように見える。 その一方、リリースしたソフトウェアにデグレばかり出しているチームは、開発プロセスも悪いし、技術的な問題も多く、スキルの課題も少なくない。毎日残業をしている割には抜本的な対策が取れておらず、「障害が多い→対策に追われる→レベルを上げる余裕が無い→さらに障害が生まれる」という負のサイクル（死のサイクルか？）にはまり込んでいるようだ。 不思議なことに「プロセスは良いけれど、技術が追いついていない」とか「技術はあるけれど、プロセス
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: 情熱プログラマー ソフトウェア開発者の幸せな生き方: Chad Fowler (著), でびあんぐる (翻訳): 本