シリコンバレーで新卒採用でソフトウェアエンジニアとして働く先輩として，君たちにN○Tよりシリコンバレーで働くことを勧告したい．理由は大きく3つある． 給料が遥かに高い．就労環境が極めて良い．グローバルな人材になれる．もう少し正確に言うと，ソフトウェアエンジニアとして仕事があるところなら，世界中どこででも働けるようになる．一言でいうと，シリコンバレーでエンジニアとして働くことはとても幸せで充実しているからおすすめしたいということなのだが，何に幸せを見出すかは人それぞれ違うので，特に思いつく以上の3つのメリットをもう少し詳しく説明するので，一つでも興味が当てはまるのならいいから黙って話を最後まで聞いて欲しい． 給料が遥かに高い．大まかにいって，20万ドルから30万ドルの年収が期待できる．これは日本でサラリーマンとして働くことに比べると大変高給だと思う． 別に高給だから偉いというわけではないが，
Web の会社でエンジニアを始めて 4 年、ずっと運用エンジニアをやってました。運用とは端的に言うと、社内外の他人が作ったソフトウェアを期待通りに動作させるためのエンジニアリングだと思ってます。アプリケーションはもちろん開発者が作ったものですし、MySQL や Apache や Linux も全部他人が作り上げたソフトウェアであり、それらの設定を変更したりパッチを当てたり運用ツールを駆使することで、協調動作させることに磨きをかけてきました。 ただ、いつまでたっても他人の作ったものの面倒を見てることには変わりないし、運用ツールを開発したところでそれはあくまで誰かが生み出す価値のサポートにすぎないのが自分的には満足できなくて、ずっとアプリケーション(ビジネスロジック)が作りたいと思ってました。 で、今年の始めからたまたまタイミングよく新規開発の部署に入ることになって、いきなり開発者をやることに
元糞コードマイスターとしては、生産性については思うところある。 技術的到達深度が深い人じゃないとそもそもかけないコードってのももちろん存在して、その前提で10倍とか100倍になりうる話をする。 そもそもマイナスになる人がいるって話。 隠しパラメータをモデル化 エンジニアA:「週に10の成果を出して3の負債を生む人」を考える。この人は開発を止めてリファクタリングをすれば10-3 = 7の技術的負債を返却できるとする。 ここで正確には成果10には* aの係数が掛かっている。これはプロジェクト開始時1.0で、技術的負債が貯まるほど0に近づいて行く 次に、エンジニアB:「週に15の成果を出して10の負債を生む人」を考える(これにも係数aがかかる)。この人は見た目上は上の人の1.5倍速く成果を出しているように観測できるが、負債もたまりやすい。リファクタしても綺麗になりにくい。 これは割とエンジニアに
「アジャイルがダメだと思う7つの理由」という刺激的なタイトルのエントリを、先週木曜日、3月21日にグロースエクスパートナーズの鈴木雄介氏が公開してから、アジャイル開発に関する議論の波紋が広がっています。 おそらく、これだけさまざまなブログを通じてアジャイル開発の議論が活発化したことはこれまで国内ではなかったのではないでしょうか？ ここでは現時点での議論をまとめますが、興味のある方はぜひここを起点にそれぞれのエントリを読んでみていただきたいと思います。 発端は鈴木雄介氏（id:arclamp）のブログarclampにポストされた「アジャイルがダメだと思う7つの理由」というエントリ。以下がその7つの理由として挙げられたものです。 1.全体スケジュールにコミットできない 2.アーキテクチャ上の無駄が生じる 3.コーチって何だよ 4.変化ヲ抱擁スルために固定化している 5.実証主義的な説明に過ぎな
「仕様変更」という言葉はプログラム書く人じゃないと、そのイメージが掴めないと思う。イメージが掴めない人に対してそれを説明するとしたら何がいいだろう？ と思った。 とりあえず、料理に例えたらいいのではないかと思ったので、それに例えて考えてみる。 仕様とはレシピのことであり、最終的には具体的に「食べることができる美味しい料理」すなわち「うまく動くプログラム」を作ることを目的としている。 仕様というのは、最初は「イタリア料理」「日本料理」「中華料理」程度しか示されない。当然この時点では方針程度しか考えることができない。食材を買うこともできない。せいぜい使う調味料を揃えるぐらいしかできない。 もう少し進むと、料理名まで具体化される。スパゲティを作りましょうとか、ピザを作りましょうとかだ。とりあえずここまできたら小麦粉を買おうとかまではできるかもしれない。でも実際に作りはじめることはできない。 さら
悪い意味での典型的なSIエンジニアの口癖は、 「なんで○○なの？」 だ。 なんでそうなるのかを興味があるのではなく、否定するためになぜなぜ聞いてくるのだ。 説明できなければ、「×」。 こういう人とは建設的な議論にならない。 そういう人と話していても、話は広がらない。 雰囲気が悪くなるし、とりあえず否定しようと構えている人とやる仕事に良いアイデアは降ってこない。そのうち案も出なくなる。 それが続くと、無難なことしか言わない非イノベーティブなSIエンジニアの出来上がりだ。 一方で、(悪い意味での)典型的SIエンジニアには、 「これはこうだから、こうした方がいいんじゃない？」 という人は少ない。 対案を出すだけの技術的な素養はないからだ。 技術的な裏付けはなくても否定はできる。 プロ野球の観戦者や国の政策を否定するオバサンと同じで、 否定するのは実はすごく簡単なのだ。 そもそもどのような場合も完
2008年07月19日16:00 カテゴリLightweight Languages フローチャートがダメな3つの理由 というわけで、前世紀の遺物、フローチャートを供養する試み。 フローチャートとFizzBuzz問題 - novtan別館 さて、研修の話だけど、低水準言語ってだけではなく、きちんとフローチャートを書かせて処理の流れを整理し、あるいは効率が悪くないかを考えさせる、ということも重要だと思っています。フローチャートがそんなにいいなら、なんでビジュアルプログラミング言語が現場で使われないの? まずは経験則による終了宣言。ちなみにここで言うビジュアルプログラミング言語の定義は、Wikipediaのそれと同じ。 ビジュアルプログラミング言語 - Wikipedia ビジュアルプログラミング言語（英: Visual programming language、VPL）とは、プログラム要素を
「プログラミング経験のない人がソフトウェアの設計をすること」の是非について、どう考えますか？ もしかしたら、このブログの読者であれば、プログラミングが出来ないのにソフトウェア設計をするなんてありえない！という意見の方が多いかもしれません。私もそういう意見ではあったのですが、色々な人と話をするにつけ、どこか違和感を感じていました。 その違和感の正体を探るべく、ソフトウェア設計とプログラミングについて考えてみました。そこでわかったことは「ソフトウェア設計」について、人それぞれに捉え方が違うために、話が通じないことがあることから産まれた違和感だったということです。 この記事では、私の考える「ソフトウェア設計とは何か」について書きました。 ソフトウェア開発はすべてが「設計」である モノづくりにおいて、大きく工程を２つに分けるとしたら「設計」と「製造」に分けることが出来ます。何をどう作るかを決めるこ
特許庁と東芝の新システム開発契約打ち切りについて、なぜこの開発プロジェクトが破綻したのかについて私なりの解説をしようとバックグラウンドを調べたところ、調べれば調べるほど、この問題の根底には（１）コスト意識が欠如し自分たちが「公僕」であることを忘れてしまった霞ヶ関官僚、（２）霞ヶ関から流れて来るお金にたかる IT ゼネコン、（３）そのお金の流れに対する影響力を利用して票を稼ぐ政治家、という原子力業界と全く同じような構図があることが明らかになり、ウンザリしてしまった。 破綻の原因は、ソフトウェア・アーキテクチャやプロジェクト・マネージメントにあったのではなく、「競争原理が正しく働かない社会構造」そのものにあるのだ。これではうまく行くはずがないし、たとえうまくいったとしてもやたらと高くつく。 そもそも破格だと言われた９９億円という落札価格も、私から見ればどうみても高すぎる。特許庁のシステムであれ
「コードがもうメチャメチャでも、動いて金が回れば正解なんですよ」という発言を含むインタビューが話題です。 エンジニアよ、ゼネラリストなんて目指すな！- VASILY 金山裕樹のキャリア論［2］ 一部界隈で大きな話題になっているのは、主に以下の部分です。 極端な話、コードがもうメチャメチャでも、動いて金が回れば正解なんですよ。「アイツの書くコードは汚いけど、アイツが入ったプロジェクトは絶対勝つよね」ってエンジニアは、絶対に呼ばれます。もう間違いない。少なくとも、僕は欲しいですし。 私のまわりでは、「汚いコードをその後運用させられるエンジニアもいるんだからね」という意見が非常に多い印象です。 個人的には、こういうことを表明している会社でエンジニアとして働きたいとは思わなかったです。 「汚くてもいいよ」はエンジニアとしては楽な面もあるよね 今は文章を書くことが私の主な仕事ですが、前職はプログラマ
2012-11-30 コードの綺麗さの先にあるもの 久々の更新になりますね。せっかくなのではてなブログに移りました。 昨日弊社代表の 「コードが汚くてもいい」っていう社長のインタビュー記事に対して 「コードが汚いのは悪だろ」って脊髄反射してるブクマコメントとかツイートが たくさんあるのでCTOとしての自分なりの意見を書いてみようと思う。 実際の現場 最初に記事を目にしたプログラマー達はまぁ「コードは汚くてもいい」にしか目にいかないだろう。そんな会社で働きたくないって思うかもしれない。この会社には汚いコードが溢れてるんだろうなと。 脊髄反射的にブコメしたり、ツイートされているものは全て拝見させていただいた。 では実際の現場はどうなのか。 盛大に勘違いされてそうだが、そもそもの大前提としてうちのコードは別に汚くない。 綺麗、汚いとかの定義は人それぞれだが、仮にその評価軸をリーダブルコード(可読
イケてる人材は3つの“Ｊ”を持っている ―VASILY 金山裕樹のキャリア論［1］から読む 大手企業とスタートアップとの、決定的な違い。 ― 金山さんは、大手企業とスタートアップの両方を経験されていますよね。両方で求められる能力に違いは感じますか？ まったく違うと感じます。決定的に違うのは、ビジネスとして「成立させる」フェーズ。そこにくると、必要になるスキルが全然違うんです。 大企業の場合は、すでに独自の強いビジネスモデルってものがあるんですね。すごく雑な言い方をすると、“Yahoo! の強み”って「どんなページを作ったとしても、広告が入って、収益があがる」ところなんです。Yahoo! として広告がガンガンまわっているから、極論、あとは“どれだけ低コストで広告が入るようなページを量産できるか”の勝負なんです。あとは、自分がやりたいことをビジネスモデルに“どうはめるか”だけを考えればいい。
本日、「第2回 grails code reading」に参加いたしました。 私にとっては、懇親会を含め(懇親会のほうが？）大いにインスパイされる、有意義なものでした。参加者の皆様および、会場を提供いただいたＣＩＪさまにおかれましては、ありがとうございました。 帰りながら思うに、GrailsとRailsの関係というのは、「ソフトウェア(J2EE技術群)の複雑さの増大」に対するアンチテーゼとしての典型的な２大アプローチをそれぞれに代表しているのだな、と思いました。ひとつは、バッドノウハウ*1に対する「グッドラッパー的アプローチ」（グッドかどうかは置いとくとして、ラッパー的アプローチ）としてのＧｒａｉｌｓ、「セカンドシステム症候群」気味にシンプルなものに立ち戻ろう、という立場のRails、です。 ＩＴ業界２大ドグマの対決というわけです*2。この認識からいえるのは、Ｇｒａｉｌｓについては、「ラッ
http://d.hatena.ne.jp/JavaBlack/20101014/p2 の続きかな？ なれる!SE 2週間でわかる?SE入門 (電撃文庫) 作者: 夏海公司,Ixy出版社/メーカー: アスキー・メディアワークス発売日: 2010/06/10メディア: 文庫購入: 49人 クリック: 883回この商品を含むブログ (155件) を見るなれる！SE ２週間でわかる？ＳＥ入門 (電撃文庫) 作者: 夏海公司,Ixy出版社/メーカー: KADOKAWA / アスキー・メディアワークス発売日: 2012/10/04メディア: Kindle版 クリック: 4回この商品を含むブログ (23件) を見る なれる!SE (2) 基礎から学ぶ?運用構築 (電撃文庫) 作者: 夏海公司,Ixy出版社/メーカー: アスキー・メディアワークス発売日: 2010/10/10メディア: 文庫購入: 35
2020-03-11追記: タイトルの「未だ」がいつなのかわかりづらいので「2012年現在」を追加しました。 バカバカしい話ですが、ソースコードをSubversionなどでバージョン管理しているにもかかわらず、未だ修正前をコメントアウトして残す習慣は残っているところも多々あります。こういうのです。 // 2012/08/15 irof 修正開始 // hoge = fuga(1); hoge = fuga(2); // 2012/08/15 irof 修正終了 見た事無い方は、そのまま見ないままで生きていかれることを切に願います。 コメントの修正がある場合 2012/07/21にあった、SCMBCでこんなツイートがありまして。 この時点でお見せしたのはこんな感じ。 // 2012/07/21 削除開始 // // 間違ったコメント // 2012/07/21 削除終了 someMethod
富士通と富士通アドバンストソリューションズ（FASOL）は2012年8月15日、企業情報システム向けの「設計書化モダナイゼーションサービス」を発表した（図1）。同日より販売活動を開始する。 このサービスでは、富士通およびFASOLの担当技術者が顧客企業のメインフレームを調査。COBOLやPL/Iなどで書かれているアプリケーションのソースコードを解析し、日本語の設計書に置き換える（図2）。アプリケーションの保守担当者はソースコードではなく日本語の設計書によってアプリケーションの仕様が把握できるため、アプリケーションの保守性が向上するという。 また、日本語の設計書から新規システム用のJavaソースも生成可能。この作業で富士通側はFASOLの開発支援ツール「InterDevelopシリーズ」を使う。同ツールはテスト関連の機能も備えており、設計書からJavaソースの動作テスト項目の候補を自動抽出す
あまり技術力もない、口も下手で、日々のシステム開発を大きな不具合がないように先回りをしながら大きな苦難の無いように仕事をしているプログラマーよりのエンジニアによる感想です。 何回か転職をしてきて、エンジニアの採用面接は非常に不思議だと思うようになってきました。 その思いを完成させてくれたのはJunichiItoさんによる このたびソニックガーデンの7人目のメンバーになりました でした。 自分が不思議と思ったことを5つほど挙げたいと思います。 システム開発の判らない人が評価をするのですか？ 最初に不思議に思ったのは面接を人事の方がすることが多いことでした。 システム開発をしたことがない、することのない人が面接官をして、 エンジニアが自分がどれだけ優れているのかを面接でお話をする。 エンジニア同士ですら、昨今の技術は多岐にわたっており、自分の専門としていない分野に関しては評価ができないような状
このエントリーはStartup Scrumなブログではありません。Scrumというものに興味をもった当時23歳うさみみ系エンジニアがScrumという言葉を借りて開発してみた。という話です。2011/3から2011/5あたりの話。 2011/3。僕はデスマ４年目を終えて、新しいプロジェクトに移りました。 あるプロジェクトの中の4人チームのうちの1人として。もちろん僕はいちばん下っ端として。 （元請け会社の2人、当時同じ会社だった先輩、僕の4人） そのプロジェクトはWFだったんですけど、タイムボックスやリスク管理について理解があることは雰囲気で伝わってきました。 僕はその頃勉強し始めていたあらゆることを現場で試してみたいって強く思いました。 僕はMercurial、Jenkins、Groovyを趣味的に使い始めていて(MercurialとJenkinsは2010/10から。Groovyは201
テストというのは、基本的にはソースコードの冗長化だと思う。本来ならプロダクトコードだけ書けばよいところを、信頼性を高めるために複数の視点でのコードを追加する。 また、サーバーの冗長化で、２台構成を３台構成にするよりも、はるかに１台構成を２台にするのが難しいように、テストも、10本のテストを20本にするよりも、最初のテスト(プロダクトコードも含めると２本目のコード)を書くのが一番難しい。 テストがソースコードの冗長化であるなら、アクセスのないサイトでサーバーをクラスタリングするのが単なる金や設定時間の無駄であるように、長期的な信頼性の求められないプロダクトにテストを書くことも金の無駄だ。 アクセスが多いのにサーバー冗長化の金を払わない顧客に対してクラスタリング構成を構築する義理がないように、信頼性が求められるのにテストの金を払わず時間も確保しない顧客のためにテストを書いてやる必要もない。もち
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
