顧客が欲しいのは「タイヤのブランコ」：ベンチャー社長で技術者で：エンジニアライフ
コメントを返せなくて申し訳ございません。弊社サイトの焼き直しで更に申し訳ないですが、コメント代わりとして下さい。 前回、UIについてこそっと書きました。わたしがいいたかったのはこの漫画の内容です。 アメリカの自動車会社のフォードを作った Henry Ford も同じことを言ってます。 「もしわたしが顧客に、彼らの望むものを聞いていたら、彼らはもっと速い馬が欲しいと答えていただろう」 そう、顧客は「速く移動できる手段」が欲しいということを「もっと速い馬が欲しい」と表現するかも知れませんし、「タイヤのブランコ」が欲しいとき「三連のブランコ」と表現してしまうかも知れません。顧客がいった言葉そのものは、必ずしも正しくないのです。 さて、ここからものすごく細かくチープな話になりますが、日付入力について顧客側から「年を4桁入れたら、自動的にスラッシュを付加してくれないか」という要望が出てくることはよく
なぜエンジニアは勉強会で会社名を出せないのか：雲（クラウド）の隙間から青空が見えた：エンジニアライフ
■勉強会で自社名を隠す人々 今年の2月に転職して以降、勉強会やカンファレンスでの発表資料に僕は会社名を書くようになった。 2010年9月にコミュニティで初めてのライトニングトークをして以降、今年の2月に転職するまで、僕は合計9回、ライトニングトークや、セッションで登壇している。そしてそのいずれも、会社名はあえて伏せていた。 そういった場面で名刺交換をする機会はあっても、僕は個人で作成した名刺を使い、会社の名刺を出すこともしていない。その当時、僕がなんという会社に勤務しているのか、おそらくほとんどの人は知らなかったはずだ。 転職以降も、こういった活動は続けているが、今は自己紹介で、どこの会社で、どういった仕事をしているか名乗るようになった。名刺交換でも、会社の名刺を出している。 勉強会やカンファレンスに行くと、様々な人と出会う。登壇者と仲良くなることもある。そういった人たちと話をしていると、
「なんでRubyなんか作った!? 迷惑だ！」に対するMatzの答え：Rails Hub情報局：エンジニアライフ
2012年9月に行われた札幌Ruby会議2012の基調講演の1つで、Rubyの生みの親のまつもとゆきひろさんが、最近あった面白いエピソードを混じえて“イノベーション”の本質について語っていました（44分の動画）。ポイントとなる部分をまとめてみました。まつもとさんの話はもちろん、統計的裏付けだとか学問的裏付けがある議論というものではありませんし、ご本人も楽しそうに話し、聴衆も楽しんでトークを聞くというゆるい感じのものでした。ただ、「イノベーションの本質は捉えがたい」というメッセージや、「だからあれこれ考えずにコードを書こう、われわれはコードを書くことにアイデンティティを感じているのだから、それこそがハッピーになる道だ」というメッセージは、参加していたRubyistたちの胸に響くものがあったのではないかと思います。 以下、口語文体のまま、ポイントとなる前半のトークをまとめてみました。トーク後半
いま読みたいRuby on Rails3アプリ 10選：Rails Hub情報局：エンジニアライフ
ITエンジニア向けの質問・回答コミュニティ「QA@IT」で、「RSpec のテストがたくさんついたオープンソースの Rails3 アプリはあるでしょうか」という質問に対して回答したところ、少しはてブが付いたりしたようです。Railsに限らないかもしれませんが、ちょっとしたサンプルコードや簡易なアプリというのはたくさんあるのですが、そこそこの規模のアプリ、あるいは実運用されているアプリで参考にできるソースコードとなると、意外にパッと思い付かなかったりします。「Railsアプリなら、これを読め」というべきアプリのリストがあればいいのにと、よく思ったりしています。 そんなわけで、いま読むべきだと私が勝手に考えてGitHubのウォッチリストに入れているRails3アプリを、10個ほどリストアップしてみたいと思います（全部で11個ですが）。ほかにオススメなどがあれば、ぜひコチラで情報をお寄せください
自分の稼ぎで食っている：プログラマで、生きている：エンジニアライフ
◆ はじめにおことわり ◆ 今回のテーマは「わたしがプログラマという職業を選んだ理由」で、実は1行で書こうと思えば書けるんですけど、それだとかなり意味不明になってしまって、ちゃんとわかるように書こうとするとやたら長くなります。 自分で言うのもなんですけど、わたしはちょっとレアな人なので普通な人（←表現がおかしい気もするけど、適切な表現が思いつきません）に読んでいただいても、進路選択の参考にはならないと思いますが、もしかしたら、昔のわたしと似たような問題にぶちあたってる人の目に留まるかもしれません。そんな偶然が存在して、なおかつ、この出会いがほんの少しでもよい方向に作用することを期待して、この文章を書きました。 少々、重いお話になるので、そういうのが苦手な方はここで引き返すことをおすすめします。せっかくきてくださったのに、申し訳ありません。 ◆ 10才のわたしは20才の自分に絶望していた ◆
素人がWebサービスを作ってみて分かった9つのこと：Rails Hub情報局：エンジニアライフ
こんにちは、＠IT編集部の西村賢です。IT系のオンラインメディアで編集・記者をしております。タイトルに「ど素人」と書くと、ちょっと嘘になるので「素人」と書きましたが、素人がWebアプリを作ってみた体験談と感想を書いてみたいと思います。「オレもプログラミングを勉強して何か作ってみたい！」と考えている人や、「自分でサーバを借りて何かやってみようと思っていたんだよね」という人の参考になれば幸いです。 去年の夏、Webアプリケーション開発フレームワークのRuby on Railsのことを調べていて「面白そうだな」と思い、ドキュメントに従ってサンプルアプリをいくつか作ってみました。作ったり壊したりしている間に、こう思いました。 「あれ？ これなら自分が欲しかったサービスが作れちゃうんじゃないの？」 で、「Worklista」（ワークリスタ）という名前のWebサービスを作りました。3カ月ほど前から親し
実はオブジェクト指向ってしっくりこないんです！：気分はstatic！：エンジニアライフ
わたしはこれまで、C言語、Visual Basic、SAP ABAP、最近になって ASP.NET C# などの言語を使ってきた。 「自分でクラスを作ってオブジェクト指向っぽいことをしている」なんてことはまったくない。特に「メンバー関数をstatic宣言すればインスタンス宣言をしなくてもいい」ということ知ってからは、メンバー関数を従来のファンクションのように使っている。共有変数も、pubulic static宣言していまう。したがってプロパティなんて作らない。 staticを理解していない人のコードを見ると、いちいちインスタンス宣言しているので笑ってしまう。データベースにアクセスするアプリケーションをC#で書いているのだが、Visual Studioで供給しているSQL関係のクラスを使えばできてしまうのだから。 オブジェクト指向の入門書では、クラスが持つ隠ぺい性が強調されているが、これは他
優秀なエンジニア5人は二流の1000人を完全に凌駕する：Rails Hub情報局：エンジニアライフ
1990年代後半のインターネットブームの火付け役といってもいいWebブラウザ「Netscape」の創業者で、現在シリコンバレーで投資家として活躍するMarc Andreessen氏が、あるインタビュー中で「優秀な5人のプログラマは、二流のプログラマ1000人を完全に凌駕する」（Five great programmers can completely outperform 1,000 mediocre programmers.）と発言したことで、ちょっとした話題となっているようです。インタビューはライターのBill Taylor氏（個人サイト）が、自著「Marvericks at Work – Why the Most Original Minds in Business Win」（アマゾンUSへのリンク）のためにインタビューした際の答えとして、Harvard Business Revie
偽装請負のススメ：ベンチャー社長で技術者で：エンジニアライフ
株式会社ジーワンシステムの代表取締役。 新しいものを生み出して世の中をあっといわせたい。イノベーションってやつ起こせたらいいな。 偽装請負というのは、コの業界（古い隠語だけれどコンピュータ業界のことね）のいわゆる悪弊であったりするのですが、それぞれについて分からないというお話や勘違いしてることも多いかと思うので、ちょっと整理してみよう。 ● まずは言葉の意味から ■ 請負契約 納品物に責任を負う契約。つまり、成果物が完成しなければ報酬はもらえない。どのように作ったかは個別に契約していない限り問われない。受注側が従業員を使う場合、発注側が指揮監督をすることはできない。 ■ 委任契約（準委任契約） 作業に責任を負う契約。ちゃんと作業をしていれば（善管注意義務を果たしていれば）成果物がなくても報酬がもらえる。受注側が従業員を使う場合、発注側が指揮監督をすることはできない。 ※ ここまでを分かりや
SQL ServerでXQueryするには？（準備編3）：XML乱舞：エンジニアライフ
<root xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <row> <TAXCODE>0</TAXCODE> <TAXNAME>非課税</TAXNAME> <TAXRATE>0</TAXRATE> <MODIFIED>2000-01-01T00:00:00</MODIFIED> </row> <row> <TAXCODE>1</TAXCODE> <TAXNAME>課税</TAXNAME> <TAXRATE>5</TAXRATE> <MODIFIED>2001-01-01T00:00:00</MODIFIED> </row> <row> <TAXCODE>8</TAXCODE> <TAXNAME>旧消費税</TAXNAME> <TAXRATE>3</TAXRATE> <MODIFIED>2008-01-01T00:00:00<
御社のITコンサルタントって何するんですか？：ITコンサルタント宣言！ ～MALTな日々：エンジニアライフ
「コンサルタント？ 別に立派な報告書を作る人はいらないよ。欲しいのは動くものなんだ」 「弊社のコンサルタントは必要に応じてコーディングもやるんですよ。」 「それってSEとかプログラマの仕事でしょ。御社のITコンサルタントって何するんですか？」 「弊社に応募された理由を教えてもらえますか？」 「プログラマ、SEと下流工程を積み上げてきたので、そろそろコンサルタントになりたいと思っているんです」 「なるほど。で、おっしゃっているコンサルタントはどういうイメージですか？」 「上流工程の仕事をする人のことだと思うんですが……違いますか？ 御社のITコンサルタントって何をするのですか？」 はじめまして。ウルシステムズの林です。 本コラムでは、ITコンサルタントというキーワードを支点にして、日本のIT業界とそこで働くITスペシャリストのあり方について考えていきたいと思います。ちょっと大上段な感じもしま
SEとPG、どっちが頭がいい？（2）：下流から見たIT業界：エンジニアライフ
刺戟的な題名で続けます。 前回は日本独特のSE／PGの分業体制がどのようにして発生したのか、ということを説明しました。それは日本にソフトウェア開発が産業として根付いたときに、PGが単純作業労働者と位置付けられてしまったため、上級技術者を区別する言葉が必要とされた、それがSE（システムエンジニア）だというものでした。 ●C言語＠UNIXでは COBOLの開発ではSE作業とPG作業がきちんと分けられていると思われがちですが、これも前回述べたとおり実際には形式だけのものになっていました。これはタイムシェアリング端末の普及によってプログラミング作業が格段に効率化されたからでした。プログラミングに残っていた煩雑な手作業の部分が省力化されたのです。 この事情はBasicやC言語でも同じことです。1980年代後半、わたしは最初の会社を辞め、パソコンの開発をするようになりました。現場では、技術者はそれぞれ
SEとPG、どっちが頭がいい？（1）：下流から見たIT業界：エンジニアライフ
ちょっと刺戟的な題名をつけました。しかし決して挑戦的な意図があるわけではありません。SEとPGの分業がIT業界にもたらしている問題が今回のテーマです。 ●SEとは何か、PGとは何か まずそれぞれの職分を正しく認識することからはじめましょう。プログラマ（PG）とはどういう仕事をする人たちでしょうか。 いうまでもありません。プログラムを作る人たちのことです。大工さんは家を作る人、漁師さんは魚を取る人。こういった人々と同様にPGもその仕事の内容から自明です。 一方SE――システムエンジニアの方は必ずしもそうではありません。システムのエンジニア？ システムの技術者？ ひどくあいまいな言葉です。この言葉はじつはもともと英語ではなく、「OL」などと同じ和製英語だといわれます。海外のコンピュータ技術書にもSEという言葉はほとんど見かけません。日本人が適当に言い始めた言葉だとしたら、あいまいなのも当然です
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
