実験サービスは業務時間外に、でも「賞金あり」――ウノウラボ
第1回ではポータルサイトgooが運営する「gooラボ」を取り上げた「日本全国ラボめぐり」、おかげさまで大きな反響をいただきました。 第2回の今回は、第1回と同じくサイボウズ・ラボの秋元が、「フォト蔵」や「映画生活」などのオンラインサービスを手がけるウノウを訪問し、山田進太郎社長とエンジニアの山下英孝さんにお話を伺ってきました。 ラボで公開するサービスは業務時間外に。しかし“本業”にする道も 「そこまで公開するか」的な情報も載る「ラボブログ」 「気になるが平日にできないこと」を、まとめて開発合宿で “ラボ活動”は意外と少ない？――エンジニアのある1日 仕事としてのラボブログ執筆や勉強会も オフィスにこだわり、フリーアドレスも導入 会社の本業を持ちながら、個人のやりたいことを満たす仕組み 秋元 ウノウラボを作った動機はなんですか？ 山田 ネットサービスの会社として、正式に公開できないサービスを
なぜいつもITプロジェクトは失敗するのか？
Business Value of IT, Future of business/companies/workers, Ability to innovate. 2005年に米国で遂行されたITプロジェクト17万件のうち、機能、予算、期間等が当初の想定内に収まったものは16％であり、日本でも、「企業IT動向調査2006」（社団法人 日本情報システム・ユーザー協会）によると、システムの仕上がりに満足と回答したユーザーは10％前後だったそうである。（出典：プロジェクトが失敗するのは当たり前？！＠IT情報マネジメント） また、私個人がザッと調べてみたところ、よく「ITプロジェクトの成功・失敗確率」の英語文献で引用されているのは、ITプロジェクトの遂行度合いを10年以上に渡って調査しているStandish GroupのCHAOS Reportのようだ。これの2004年度版（調査対象は4万案件）によ
デモではものができあがっているように見せない
Kathy Sierra / 青木靖 訳 2006年12月27日 (アルファ版のような)開発中のものを私たちが世間や、クライアントや、ボスに見せるときには･･･彼らの期待のレベルを設定することになる。これは3通りの方法でやることができる。磨き上げられたモックアップで幻惑するか、プロジェクトの現状に合ったものを見せるか、ほとんどできていないものを見せながら順調に進んでいるから「信用しろ」と言っていら立たせるかだ。 結論を言うなら: どれくらい「できている」ように見えるかは、実際どれくらい「できている」かに合わせるべきだ。 ソフトウェア開発者はみんなそのキャリアにおいてこのことを何度も思い知ることになる。しかしテクニカルライターもまた、デスクトップパブリッシングツールによって同様の問題に直面する——フォントやレイアウトが完璧に仕上げられたドラフトを誰かに見せるなら、その人はあなたが考えるよりも
[ThinkIT] 第1回：複数人による開発の要所を押さえる (1/3)
PHPは生産性の高い開発言語として広く普及しました。現在も多くのWebアプリケーション開発でPHPが採用されており、その手軽さも手伝って実績を伸ばし続けています。手軽に開発できることから、個人での開発もでき、独自の開発手法が多く存在し、複数人では統一が難しいといわれています。 そのため複数人による開発では、確固とした開発手法がとられてない事例が多いのも事実です。開発手法が確立されてない場合、規模が大きくなるとすぐに破綻してしまいます。それを避けるには、開発手法を確立しておく必要があります。 本連載では複数人によるPHPを用いたWebアプリケーション開発において、実際に筆者の所属するウノウ株式会社が行っている手法を例に効率的な開発手法を解説していきます。本連載の内容はPHPだけでなくRubyやPerlのような他の言語にも適用できます。また1人で開発を行う時に非常に有効な方法です。実際に筆者が
Geekなぺーじ：バグを指摘されたプログラマの返答ベスト20
「Top 20 replies by Programmers to Testers when their programs don't work」という記事がありました。 笑えたので訳してみました。 ただ、かなり意訳気味なのでニュアンスが違っている項目があると思います。 詳細は原文をご覧下さい。 ソフトウェアが正しく動作しなかったときの、プログラマからテスターへの返答。
はてなブログ
なぜブログを始めるのか 自分の意見を言語化するのが苦手だと感じていて，ブログを書くことを通じてそれを解消したいと考えたためである． 言語化が苦手だと感じ始めたのは，ちょうど去年，研究室に配属されてからである．そのときまで正直勉強に困ったことはなかったので，研究生活も余裕だろ…
Six Apart - Tech Talk Blog: Movable Type の開発
こんにちは。Movable Type 製品開発チームの吉松です。そのうち登場する真打ちがやたらに深い技術の話をしてくれると思うんで、その前にまずは前座ということで、Movable Typeの開発チームの生態をさらしてみようと思います。 Movable Typeの開発チームは、サンフランシスコの本社にいるプロダクトマネージャ、エンジニア、QAリード、インタラクションデザイナ、および東京オフィスにいるエンジニアとQAリードから成っています。また、ヨーロッパにローカライゼーションの担当者がいます。いろいろ紆余曲折を経てきましたが、現在はこの太平洋をまたいだ3拠点で開発作業、具体的には外部仕様や内部仕様の策定、実装、テスト、リリースノートの作成までをこのチームで担当しています。この面々は、irc.freenode.netの#movabletypeと#movabletype-jaに出没しています。s
仙石浩明の日記 「ソフトウェア開発」は「モノ作り」ではない
いつのころからか、 ソフトウェア開発がモノ作りに喩えられるようになった。 典型的なのは、製造業(例えば自動車製造)と IT 業界とを比較して、 前者が高度にシステム化されているのに対し、 後者がまるで家内制手工業のようだ、という批判である。 日経ビジネス online の記事に次のようなくだりがあった: 「というより、何といいますか、経営トップからすると、 ITはとにかく非常識な世界だ、としか思えないのではないかなあ。 例えば大きなシステム開発プロジェクトに取り組むと、 すぐ100億円を投資する、という話になってしまう。 100億円の経常利益を出そうと思ったら本当に大変。 ところが、100億円を投じたのに、期限までに完成しない、 出来上がってきたものが当初計画と違う、 直そうとするとさらに金がかかる。 こんなことが起きるわけですから、『一体なぜなんだ』と経営トップは思うわけです」 IT業界
Martin Fowler's Bliki in Japanese - 技術的負債
http://www.martinfowler.com/bliki/TechnicalDebt.html システムに新しい機能を追加するとしよう。2つのやり方があるはずだ。ひとつは、早いけれど、ぐちゃぐちゃになるやり方（将来、変更が困難になることは分かっているよね）。もうひとつは、キレイな設計だけど、導入に時間のかかるやり方。 「技術的負債」とは、Ward Cunningham が作ったメタファーである。上記の問題について考える際に、この言葉が役に立つ。このメタファーを使うと、早いけれど汚い解決方法は（ファイナンスの負債と同じく）技術的な負債が発生する、ということになる。 通常の負債と同じく、こちらの負債も利子を払う必要がでてくる。 早いけれど汚い設計を選んだせいで、将来の開発において余分な労力をさかねばならなくなる、というわけだ。 これからずっと利子を払いつづけていくことも可能だし、 リ
[ThinkIT] 第3回：成果物の管理とプロジェクトのコミュニケーション向上 (1/4)
2005年の夏の話ですが、こんなことがありました。ある花火大会で有料席をとり、友人と見に行くことになりました。有料席で花火を見るのは、はじめてであったため、そのことを会社で一部の人に話しました。 花火が終わり月曜日に出社すると、その話に尾ひれどころか背びれ、胸びれまでついていて、高層ビルのレストランで食事をとりながら優雅に花火を見たことになっていました。花火を見に行ったことを伝えていないはずの部長にも「花火どうだった？スーツ着ていったんだって？」と聞かれる始末。コミュニケーションの限界を感じました。 部長まで話が届いたという情報の伝達の早さには感心しますが、正確でないのは困りものです。情報の伝達は重要ですが、正確でなければいけません。 このようなことは、チームに開発にも当てはまります。正確に情報を伝達することはとても重要なことです。伝達ミスはプロジェクトの成否にもかかわります。現在、私はプ
ITスキル標準にまとわりつく誤解
ITスキル標準（ITSS）の普及に，ようやく勢いがつき始めた。ITSSのことはご存じの方も多いと思うが，IT人材に求められるスキルやキャリア（職業）を示した指標である。11職種38専門分野ごとに，最高7段階のスキル・レベルを設定している。さらに，それぞれのレベルについて，要求される業務経験や実務能力，知識を定義したものだ。 2002年12月に経済産業省が公開してから2年が経過し，ITSSを活用する企業が増えている。ユーザー企業では，製薬大手のファイザー，東京電力，松下電器産業など大手が昨年から採用に乗り出している。一方ITベンダーは，いち早く手をつけたNECソフトのほか，新日鉄ソリューションズ，NTTソフトウェア，日立システムアンドサービスなどが，相次ぎITSSの活用に着手した。 加えて，損保ジャパン・システムソリューションなどのシステム子会社もITSSの利用を進めている。こうしたITSS
PDF 千夜一夜: 2006年03月19日 アーカイブ
.NETの未来 Microsoftは.NETに賭けていないのか 最近、これから新しく開発するツールの言語についてC#（.NET）にすべきかどうか真剣に考えています。 そんな話を社内のメーリング・リストに流したところ、showさんから、 http://slashdot.jp/articles/06/03/16/1143227.shtml やっぱり OS 開発はネイティブコード? という記事が出ているよ、と教えてもらいました。 原文は、Microsoft Vista and .NET 著者はMicrosoftのMVP（Most Valueable Professional） Richard Grimesさんです。 URLはhttp://www.grimes.demon.co.uk/dotnet/vistaAndDotnet.htm です。 早速読んで見ました。この記事は、私にとっては、近ごろ読
DCWiki
2013-04-14 cis 2013-04-02 CandyCane|インストール方法 2013-02-17 プライバシーポリシー 2013-01-29 test 2013-01-20 Arduino 2013-01-18 KinoWiki:プラグイン/カタログ/outline 2012-12-08 AppleScript 2012-11-06 ペルソナ2罰 2012-09-04 LVM 2012-08-02 reveal-js NSISとは 作り方 プラグインのインストールの仕方 Tips 独自のページ、フォームを作る Silent Installation 注意 関連リンク Comment NSISとは Nullsoft Scriptable Install Systemの略。 winampで有名なNullsoftが作ったインストールシステム。フリー。 しかもなんかLinux上でイン
アジャイル開発ではドキュメントを書かないって本当？（1/5） - ＠IT
連載 開発をもっと楽にするNAgileの基本思想 第1回 アジャイル開発ではドキュメントを書かないって本当？ ――より良いコミュニケーションを実践するコツ―― 福井コンピュータ株式会社 小島 富治雄（Microsoft MVP 2006 － Visual C#） 2006/02/22 はじめに 本連載は、人気連載「NAgileで始める実践アジャイル開発」の姉妹版となる別枠の新しい連載である。「NAgileで始める実践アジャイル開発」の連載が基本的にプラクティスを実行する方法やツールにフォーカスしているのに対し、本連載ではアジャイル開発の基本思想を身に付けるためのコツを中心に書いていこうと思う。 どちらの連載もNAgile開発を実践するうえで欠かせない知識となるので、基本版「NAgileで始める実践アジャイル開発」と姉妹版「開発をもっと楽にするNAgileの基本思想」の両連載（NAgileシ
PFの「かんばん」をポータブルに！(^o^)：An Agile Way：オルタナティブ・ブログ
PF(プロジェクトファシリテーション）の１つのプラクティスである、「かんばん」。最近よく講演をするのですが、よく聞く悩みが、「うちのチームには壁がありません…」 そこで、紹介したいのが、これ。 Kanban-nano ... (モバイルかんばん!) 普通は壁に貼るのだが、これをポータブルにする。めちゃめちゃおもしろいです。昨年末のオブジェクト倶楽部クリスマスイベントのライトニングトークスで、CCSの佐藤竜一さんが発表した、「形から入る『見栄っぱり』アジャイル開発講座」に出てくる、アイテムです。 かんばんを安定させるための、「まな板立て」の利用法に注目。こういうちょとしたディテールへの実用的な工夫が泣かせます。(※協力 CCS佐藤竜一) どこにでもかんばんを持ち出そう スーツにも、ベストマッチ。オフィスを颯爽と駆けろ
「ウォークスルー」を成功させるコツ
ソフトウェア開発の世界では，「ウォークスルー」は，プログラム・コードの品質を高める有効な手段であると認識されている．さらに，設計チーム全体の知識の底上げや，リスクの回避にも役立つ．しかし，やりかたを誤ると，たちまち膨大な時間のムダに終わってしまう．そうしないためには，実行するにあたって，参加者の心理的な側面に気を配らなくてはならない． ここでは，ハードウェア記述言語（HDL）を利用しているハードウェア設計者にとっても重要となるであろう「ウォークスルー」の考え方を紹介する． ●たんなる確認行為ではない ソフトウェア開発の世界で，ウォークスルーの考え方が提唱されたのは，ずいぶんと昔のことだ．ウォークスルーに関する名著であるエドワード・ヨードンの『ソフトウェアの構造化ウォークスルー』1)の原書（第1版）が1977年に発行されている．それだけ実績のある手法と言える． ウォークスルーは，もともと「演
紛争勃発に備えよ！──受け入れ検査時のトラブル対策
紛争勃発に備えよ！──受け入れ検査時のトラブル対策：企業システム戦略の基礎知識（10）（1/2 ページ） 受け入れ検査において、明らかに「欠陥」であると判定できる場合は問題ないが、発注側では欠陥だと思って指摘しても、業者からは「それは欠陥ではなく、仕様書に書いてなかったので仕様変更である」と反論されることが少なくない。これは、業務という抽象的なものを対象としているうえに、要求仕様が日本語特有のあいまいな表現で記述され、発注側の意図が業者に正しく伝わっていないことが要因である。 こうした“見解の相違”は、欠陥であれば業者が無償で是正することになり、仕様変更であれば発注側が追加費用を負担する──つまり両者の利害は対立しているので、容易に紛争へと発展する。そうなった場合に、できるだけ禍根を残さずに両者が納得できるような形で解決するには、どうすればよいか考えてみたい。 仕様変更か、欠陥か──それが
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
dW : Linux : configureをデバッグする
IBM Developer
XP 2nd - haru01のめも