開発手法とコミュ力は捨てろ――SIエンジニアに告げる、Web企業への転職戦略
開発手法とコミュ力は捨てろ――SIエンジニアに告げる、Web企業への転職戦略：きのこる先生のエンジニア転職指南（6）（1/2 ページ） 元プログラマ、現Web系企業の人事担当者による、エンジニア転職指南。「応募書類の書き方」や「自己PRの仕方」について、エンジニアの視点を持ちながらアドバイス。エンジニアの幸せな転職のために、菌類が奮闘する。 皆さん、こんにちは。2011年も残すところあとわずか。忙しい日々をお過ごしでしょうか。 師走ということで、師に負けず菌類も走り回っています。新卒採用のエントリが始まり、やるべきことは増えるばかり。冬眠したい気持ちをぐっとこらえてフル稼働中です。 繰り返す、ここはSIerではない さて今回は、かつて私が所属していた「システム・インテグレータ（SIer）」、そしていま所属している「Web系企業」についてお話します。 SIerは、長引く不況とIT業界の構造変
システム開発におけるフリーマンの役割について : mwSoft blog
という資料を捏造したい気分だったので書いてみた。特に意味はないしオチもない。 フリーマンを置く目的は、以下である。 ・システムの品質向上 ・プロジェクトに潜伏している問題の早期発見 ・メンバーの技術レベルの把握と向上 フリーマンは明確なタスクを持たず、名前の通り、手の空いた状態でプロジェクトに携わるエンジニアである。 システム開発におけるフリーマンが行うべき主な作業は以下である。 ・ソースコードレベルでの問題の発見と指摘 ・テストコードの不足分の拡充 ・仕様が曖昧且つ後日問題となりそうな点の明確化 ・メンバーの技術レベルの把握と作業分担の適正化 フリーマンは直接コードは書かない。その代わり、製造されているすべてのソースコードを把握し、問題があれば指摘を行う。 また、技術レベルに問題があるメンバーがいる場合は、指導もしくは適切な作業の割り当てを提案する。 フリーマンの存在が効果を発揮するのは
「日本のゲームが持つ問題点」や「開発における日本とアメリカの明確な違い」を最前線にいる当事者がハッキリと語る
日本のゲームを愛するが故に「日本の有名なゲームクリエイターが最新のゲームをやっているとは到底思えない」などと「日本のゲームが持つ問題点」について歯に衣着せぬ意見をバシバシ飛ばしまくる講演「僕の海外ゲーム開発ストーリー++ ～日米両方でAAAゲーム開発をして分かったこと～」が日本最大のゲーム開発者向けカンファレンス「コンピュータエンターテインメントデベロッパーズカンファレンス2011(CEDEC2011)」で行われました。 講師は、Microsoftの343 Industriesでディレクターを務めたライアン・ペイトンさん。2003年に来日し、小島プロダクションにて「メタルギアソリッド4」などの人気作に関わった後、故郷のシアトルに戻ってからMicrosoftに入社して「HALO 4」を含むHaloシリーズのクリエイティブ面のディレクションを担当した人物です。 講演は自身の半生から始まり、「ゲ
Martin Fowler's Bliki in Japanese - フィーチャーブランチ
@@ -1,25 +1,29 @@ http://martinfowler.com/bliki/FeatureBranch.html -gitやMercurialの様な分散バージョン管理システム(DVCS)の台頭と共に私はブランチとマージ、どの様に継続的インテグレーション(CI)に適合に向けての戦略に関して、より多くの会話を見てきた。ここ、特にフューチャーブランチのプラクティスとどの様にCIに適合させるかに関して、少し戸惑いがある。 +gitやMercurialの様な分散バージョン管理システム(DVCS)の台頭と共に私はブランチとマージ、どの様に継続的インテグレーション(CI)に適合に向けての戦略に関して、より多くの会話を見てきた。ここ、特にフィーチャーブランチのプラクティスとどの様にCIに適合させるかに関して、少し戸惑いがある。 -シンプルな(分離した)フューチャーブランチ +
詳説！Redmineを使ったスマートな開発プロセス改善（画面キャプチャ付き）
最近は、課題管理システム、チケット管理システムがメジャーになっており、私もこの種のツールをサービス開発、ソフトウェア開発で利用し、開発プロセス改善を試みています。 今回は、Shibuya.trac第12回勉強会 ～チケット管理システム大決戦 第二弾～で紹介させていただいた、Redmine利用事例の詳細解説を、共有させていただこうと思います。上記、勉強会の資料は、こちらに公開されています。各種ツールの事例が詰まった内容ですので、ぜひご確認ください。 Redmineのプロジェクト画面 上記が自社のRedmineのプロジェクト画面です。私のチームは「A-Team」といい、すべての作業は「A-Team」プロジェクトで管理しています。トップページには、勤怠の連絡や、Redmineを利用するときのルールなどがまとめてあり、資料を見ていただければわかると思いますが、プロジェクトメニューにはたくさんのモジ
デザイナーが RailsとGitのことを少し知ってると色々捗る
The document contains a series of dates from 2011-6-22 repeated many times. Between some of the dates are short phrases such as "Don't Repeat Yourself" and "Convention over Configuration". The overall document does not appear to have a clear purpose and consists primarily of a date repeated with occasional unrelated text fragments.Read less
本当はすごい codefirst の開発環境 - suer のブログ
(本記事は @suer, @mallowlabs, @mzp がノリノリで共同執筆しました！) 近代的なソフトウェア開発に必要なツールは3つある。 分散バージョン管理ツール ITS CI ツール 私はこれに AsakusaSatellite (以下AS)を加えたいと思う。 以上の4ツールを使用することによって、迅速なコミュニケーション、洗練された自動化をベースとした開発リズムを体験することができる。 このあとの節では具体的なユースケースをベースに、上記ツールの連携方法及びそのメリットをみていく。 ユースケース：開発中にソースコードの特定行で例外が発生した原因を探る ここは codefirst の開発室。 @suer と @mallowlabs と @mzp はリズム良くコードを書いています。 そんなとき、ビルドの異常を知らせるポップアップが表示されます。 さっそくAS 上でミーティングがは
Nokiaが３年で地に堕ちた理由(3) ～グローバルカンパニー～ « for what it's worth
たとえ、山ほどの人材を持っていようとも、愛がなければ、無に等しい 前の二つのエントリーにも共通して言えることだが、とにかくNokiaには無駄が多いのだ。そしてその無駄を無駄にして終わっているのだ。このエントリーも一言で言えば無駄に対する指摘なのだが、その対策が異なる。 Nokiaは10万人を越える社員を抱え、そのサイトは世界各地に広がっている。まるで同じ部屋にいるかのようにビデオ会議ができるシステムや、何百人も同時に参加できるVOIPカンファレンスシステムなどが整備され、会議といえばオンラインが当たり前だ。しかし、11日の発表はオンサイトのみで行われるという異例の通達がでており、社員の間でも様々な憶測を呼んでいる。 それは置いておいて、とにかくこのオンライン会議が毎日ある。理由はプロジェクトが世界中に分散しているからだ。正確に言うとより細かいレベルで担当者が世界中に分散しているのだ。例えば
Facebook、memcachedに300TB以上のライブデータを置く大規模運用の内側
クラウドのように大規模なシステムでは、ソフトウェアの開発と同等以上に、大規模運用の巧拙が、システム全体の成功を大きく左右します。 6月22日から、米サンタクララで行われていたWebサイトのパフォーマンスと運用に関するオライリーのイベント「Velocity 2010」で、FacebookのTechnical Operations teamを担当するTom Cook氏が「A Day in the Life of Facebook Operations」（Facebook運用のある1日）と題したセッションで、Facebookがふだんどのような運用を行っているか、紹介しています。 世界でトップクラスの大規模サイトが、普段どのようなツールを用い、どのような方法で運用しているのか、セッションの内容を紹介しましょう。 6年で4億アクティブユーザー、3カ所のデータセンター Tom Cook氏。Facebo
開発現場で一度は耳にする「何で聞いてくれなかったの！？」なんて台詞は二度と聞きたく無い。 - ぐらめぬ・ぜぷつぇんのはてダ(2007 to 2011)
異なる二種類以上の開発現場で、ほぼ同様の条件で題名の「何で聞いてくれなかったの！？」という台詞がマネージャ/リーダから発せられるのを確認した。 ソフトウェアの開発現場で受託・内製問わない（両方の開発現場で確認）。ある担当者にアサインしたソフトウェアコンポーネントが（１）完成した後バグが発覚し、マネージャ/リーダが感知していない作りや設計になっていた、（２）〆切に近づいているが仕上がる感じが無く、確認してみたところ実装上の問題に嵌っていたりマネージャ/リーダが予測できないトリッキーなor複雑な設計orコードになっていた。 そのような場合に、「何でもっと早く相談してくれなかったんだ・・・」というマネージャ/リーダの無念の思いが込められ、「何で聞いてくれなかったの！？」という台詞が担当者に降りかかる。 最初に結論、というかリーダ/マネージャに対する「お願い」になってしまうが、離れ小島的にやけに静
エンジニアによる技術革新を妨害するのはエンジニア:Geekなぺーじ
エンジニアによる技術革新に対する大きな障害は、非エンジニアではなくエンジニアであるという場合もあります。 技術者やエンジニアは、新しい発想に対して無駄にネガティブな意見を連発したり、単なる抵抗勢力でしか無くなる瞬間もあるような気がしています。 例えば、熟練度が高いエンジニアほど新しいものよりも、枯れたものを好む傾向があるような気がします。 以下、エンジニアによる抵抗勢力的発言としてありそうなものを考えてみました。 なお、フィクションなのでご注意下さい。 (自分が過去にやって「あれは自分が間違っていた」と思ったことが一部含まれたりしているわけではないのでご注意下さい。そんなことはありません。) 1.「先行事例が既にあるよ」 ちょっとでも似たようなものがあれば「先行事例があるから無駄」という意見を言う人がいます。 「このような先行事例がある」というアドバイスは非常にありがたいのですが、「やるの
「俺が知っていることは大事なこと・俺が知らないことはどうでもいいこと」病 - 極北データモデリング
転職したばっかりのとき、Accessのリンクテーブルの作り方がわからなくてもたもたしていたら上司に「えー？こんなことも知らないの？」みたいな感じで「クックックックッ」て笑われてカチンと来たんだけど、カチンときた内容を明文化するならば 今まで知らなくても今日覚えたらそれでいいじゃねえか Accessなんてしょうもない*1ツールを知らなくても別に恥ずかしくないだろ みたいなことを感じたわけだ。 で、この上司にあるプロジェクトのソースのありかを聞いたら「どこ行ったかな...」「うちに帰ったらあるかも」「やっぱり無いかも」とか言われて、びっくりして社内にSubversionか何か立てるから既存のプロジェクトは全部そこに放り込んでくれと言ったら、「Subversionて何だ。何の役に立つんだ。XCOPYでいいんじゃないの」等々と言われて拒否された*2。 この時思ったのが「えー？バージョン管理システム
「はてな」を作り出す人的ネットワークの仕組みとは：ネットワークコラム ─ ＠IT
Web2.0的サービスを次々と作りだし、多くのファンが存在する「はてな」。米国法人が設立されたいま、社内ではどのようにコミュニケーションをとっているのだろうか？ 2001年に京都で産声を上げ、はてなアンテナやはてなダイアリーといった、現在のネットを象徴するようなサービスを次々と生み出し、一躍、Web2.0を代表する企業としてその名をいまにとどろかせているはてな。その後も、はてなブックマーク、リィモ、はてなスターといったサービスを送り出して、ネットの住民たちから熱い信頼を得ているのは、ご存じのとおり。 そんなはてなの社内では、どのような体制で仕事が進められているのだろうか、サービスはどうやって誕生し、どのようにはぐくまれ、日々の運用はどのようにして行われているのだろうか、筆者はかねて、そんな思いを抱いていた。今回、取締役経営企画担当の輿水宏哲氏（id:kossy）に、そのあたりの疑問をぶつけ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
