2012年9月に行われた札幌Ruby会議2012の基調講演の1つで、Rubyの生みの親のまつもとゆきひろさんが、最近あった面白いエピソードを混じえて“イノベーション”の本質について語っていました（44分の動画）。ポイントとなる部分をまとめてみました。まつもとさんの話はもちろん、統計的裏付けだとか学問的裏付けがある議論というものではありませんし、ご本人も楽しそうに話し、聴衆も楽しんでトークを聞くというゆるい感じのものでした。ただ、「イノベーションの本質は捉えがたい」というメッセージや、「だからあれこれ考えずにコードを書こう、われわれはコードを書くことにアイデンティティを感じているのだから、それこそがハッピーになる道だ」というメッセージは、参加していたRubyistたちの胸に響くものがあったのではないかと思います。 以下、口語文体のまま、ポイントとなる前半のトークをまとめてみました。トーク後半

ふつーのプログラマです。主に企業内Webシステムの要件定義から保守まで何でもやってる、ふつーのプログラマです。 高学歴で長い経験に自信を持つエンジニアは他人の話を聞かなくなる、というのは広く世に知られた真理の1つである。 K自動車ICTシステム部の三浦技術担当マネージャは、そのようなエンジニアの生き見本のような人だった。初めに言葉ありき。私が聞いた三浦マネージャーの最初の言葉はこうだ。 「オブジェクト指向など、実業務では使いものにならない！」 私の名前は川嶋ミナコ。横浜市内の某所にオフィスを構えるシステム開発会社――いわゆるベンチャー企業というやつ――に勤務しているエンジニアだ。社員数は20人前後。最近は受託開発の案件はほとんどなく、大手ベンダやエンドユーザーのシステム部門に常駐して開発を行うことが多い。 K自動車への常駐もその1つだった。部品調達システムの大規模なリニューアル中で、あちこ

こんにちは。草食系妙齢プログラマ　野口おおすけです。最近、さまざまな大盛りメニューが流行っています。さっそく近所の大盛りラーメンを食べてきたのですが、職業柄あまりカロリーを消費しないのに食べて大丈夫だろうか、と心配になる今日このごろです。 今回は、前回に引き続き「マジカル仕様書」についてお送りいたします。前回は「仕様書とは～」という話題でした。今回はケーススタディを通して、「マジカル仕様書」がどのようなものか、なぜそのようなものができてしまうのかをご紹介していきます。 ■データベースは使いません！？ どんな言語を使って実装するか、どのようなフレームワークやパッケージを利用して実装を行うか。これらの内容は開発の初期段階で決定されることの1つです。通常のWebアプリケーションであれば、データを保存する技術として必ずと言っていいほど、リレーショナルデータベースが利用されます。最近ではKVS（Ke

わたしは企業の情報システムを十余年、情報システム部門の責任者として見てきました。数多の失敗や試行錯誤を繰り返す中で、会得した企業の情報システムを運営していくための原理原則がいくつか存在します。そのうちのひとつを紹介したいと思います。今回、第1回目のコラムで紹介する原理原則は、わたしの中でも最も重要なものです。 それは、｢スイッチャビリティの確保｣とわたしが名づけているものです。 このことはほとんどITの教科書に載ってはいません。それには理由が2つあって、1つはあまりにシンプルな原理なので細かく説明するまでもないこと、もう1つは顧客を囲い込みたいベンダにとって好ましいものではないからです。したがって、ホテルなど貸しきって頻繁に開催される大手SIerのセミナーなどでは教えてくれません。 それでは、「スイッチャビリティの確保」について説明します。 スイッチャビリティの確保とは、お金さえ出せば、保

プログラマならC/C++を知らなくても、 if (buffer == null) {return;} と if (buffer == null) return; は同じ動作をするということはお分かりかと思います。 正式な言い方があるのか分かりませんが、「省略が許可されている記述」というやつです。 わたしは「省略が許可されてても省略しない派」（←どういう派閥？）なので、常にカッコでくるむのですが、わたしのコードを読んだ人が「これってこういう書き方していいんだよ」とご丁寧にもカッコをはずしてしまったことがありました。 「それくらい知ってるんですけど」 「なら、なんでわざわざカッコつけてんの？」 「どっちでもいいんならカッコをつけた方が安全じゃないですか」 「どういうこと？」 当時、わたしは結合テストで出てきたバグの原因調査をよくやらされていた（他の連中はテストで出たバグをつぶすのに忙しかったか

株式会社ジーワンシステムの代表取締役。 新しいものを生み出して世の中をあっといわせたい。イノベーションってやつ起こせたらいいな。 まともな議論になっています。炎上というのはコメントをつけてくれた方々に失礼かもしれませんが、何回も炎上してきたし、何回も同じことを書いてきたし、それどころか10年言い続けてるし……。 がしかし、この業界のお客様から、このようにご意見を頂戴した（わたしが猛烈に望んでいたコメントなんですけど自作自演じゃないからね）。 http://el.jibun.atmarkit.co.jp/g1sys/2009/06/vb6-8111.html#comment-24715757 そこで、以前からの蒸し返しですが、「上流の技術者はSQLを高いレベルで習得すべき」と改めて一度、声を大にして言いたい。 その前に余談ですが、VB6と.NET（とSQL）について。 どっかでコメントしまし

退職後4カ月を過ぎたある日、斉藤さん（仮名）のもとに前職の同僚から連絡がありました。 急に退職した彼を心配しており、困っているのであれば協力したいというのです。 懇意にしている協力会社が人を探しているので、そちらを受けてはどうかという話でした。しかし、彼はきっぱり断りました。前職の協力会社にいくのであれば、転職をした意味がないと考えたのです。 しばらく大手中堅企業を中心に応募を続けまました。 しかし、大手から中堅までの企業は手当たり次第に応募したため、新しい求人も見つからなくなりました。 応募を続けても結果は惨たんたるもの。退職からすでに6カ月が過ぎていました。 生活を支えてきた退職金も底をつき、遂に長年蓄えてきた貯金を切り崩し、生活費に充てなければなりません。 「このままでは、生活すら危なくなる」と、危機感ばかりが募っていきました。 ここまで来ると、どのようにキャリアアップするかよりも「

いよいよ今年も、残すところ数週間。 私は今年、およそ300名以上のITエンジニアやWebクリエイターの方々の転職活動をお手伝いさせていただきましたが、実はそのうち9割が「女性」なんです。 ■結婚は転職の足かせ？ 女性のITエンジニアとの面談の中で、「結婚していることは転職活動に影響するのでしょうか？」とよくご質問いただきます。 性別を限らず結婚は、ご夫婦が共有する時間の確保のために、ワークライフバランスについて考える良い転機になると、私はポジティブに考えています。 ところが女性の中には、結婚をしていると家事や出産などによって業務に影響が出る可能性があるという考えから、企業が女性を積極的に採用しないのではないかと不安に感じている方が多くいらっしゃいます。 以前、転職活動のお手伝いをさせていただいた江本さん（仮名）もその1人でした。 中堅規模のシステム開発会社に入社して4年目のITエンジニアで

エンジニアは、自分が作ったプログラムやシステムにバグはないと思っています。 そういった非現実的な思いがエンジニアを狂わすのでしょうか。バグが発生すれば、「きっと自分のせいじゃない！」、自分が出したバグであることが判明すれば、「すぐに直さなければ！」、お客様に「トラブル発生！」と迫られると、「早急に原因を特定します！」と反応してしまうことはありませんか？ 【余裕のないエンジニア】 私が大規模なプロジェクトに関わったとき、開発チームとは別に20名程度のテストチームが組まれたことがありました。SIerではテストの役割を当てられるのは新人や2年目などの社員で構成されることが多く、チームの立ち上がりに時間がかかりながらも、若いだけあって高いモチベーションを保ちつつ、テストチームとしてかなり有機的に機能していきました。 やがて、彼らはゲーム感覚でバグを発見するようになり、バグを見つけるとガッツポーズま

世の中、非常に数多くのIT屋と呼ばれるSIerやソフトハウスが存在し色々仕事を行なっていると思います。ですがこのIT屋と呼ばれる中でも問題のある企業や人というのは数多く存在しています。 開発を行なっている人にとってはプロジェクト管理の話というのはよく耳に目にすると思います。またソースや納品物などで構成管理というのもよく話題になるのではないでしょうか。 しかしIT企業の中で果たしてどのくらいの企業が（ある程度以上の）管理を行えているか、と言われると恐らく半数にも満たないのではないでしょうか。中小企業になればその割合は更に減ることと思われます。 ある会社での話ですが、「ソース管理はしっかり行なっています」とプロジェクトマネージャーや担当SEなどが言っていたのでどれどれと見せてもらったところ、APのソースはビルド時に圧縮し専用のフォルダに時系列で保存していたので「気持ちは微妙だけどまぁいいか」と

先日、大学を卒業して新たに小児科医になろうとする先生が減少しているという報道を見ました。 大学生の声も紹介されていたのですが、「すき好んで過酷な条件のところで働こうとは思わない」という声が上がっていました。「医師というのはなぁ、自分を犠牲にして命と向き合うからこそ、命の大切さが分かるんだよ」と理想を懇々（こんこん）と語ることはできますが、自分がこれから働く職場を選ぶ時に、よほど強い意志や、これまでの何かしらの強い体験がなければ、わざわざ大変なところに飛び込む人は確かにいないだろうなぁ～と思いました。 一方で、これから医者になろうとする大学生が、「過酷だ」という情報をどこから得たんだろうと想像しますと、おそらくマスコミやインターネットなど、何かしらの情報媒体からの情報なのではないかと察しています。そんな情報が溢れれば、「小児科医？ そんな大変なところはやめておけ！」と、周囲からの反対が起きる

本音が語れるエンジニア参加型メディア「＠IT自分戦略研究所 エンジニアライフ」。日々、ITエンジニアの「生の声」を公開している。 ここでは、＠IT自分戦略研究所 編集部おすすめのコラムを紹介する。あなたのエンジニアとしての成長に役立つ内容であれば幸いだ。 ■みんな「自分の身の周りのこと」を語っているだけ 東海地方で働くシステムエンジニア 小沢英裕氏による新コラム『地方エンジニアリングライフに四苦Hack』。小沢氏は「もじら組」のスタッフとしても活動している。 第1回は、「ITエンジニアの在り方」や「IT業界の現状」に関する巷（ちまた）の言説を斬る。小沢氏いわく、「『ITエンジニア』や『IT業界』といっても、自分の身の周りのことを語っているに過ぎない」。 ITエンジニアやIT業界について考えるセミナー・イベントが盛んだ。だが、そこには「大多数のサラリーマンIT社員の姿」は見えない。 ■仕事を