ニッポンはもうIT大国になれない
ソフトウェア業界はドラゴンボールの世界と似ています。 「私の戦闘力は５３万です」 というのはフリーザの有名なセリフなのですが、ソフトウェア産業でもまさに同じようなことが起きていて、戦闘力（＝生産性）が桁外れの人がごろごろいるのです。 １００人のプログラマが２週間かかって出来ないことをスーパープログラマが２時間であっさり解決とか普通にある世界です。 Google Code Jam とか Top Coder のアルゴリズム部門といったオンラインプログラミングコンテストに出場してみればわかると思います。（誰でも出場できます） 全世界一斉によーい・・ドン！と始まって、１問目の問題文を読み始めます。 すると・・三分の一も読むか読まないうちに、スコアボードにはすでにプログラムを提出して正解判定をもらっている人がちらほら出始めます。 なん・・だ・と・・？！ あなた方は魔人ブウの団体様ですか？？ なんとか
採用プロセスを真剣に考えろという話
アジャイル開発チーム向けのコーチングや、技術顧問、Scrum Alliance認定スクラムマスター研修などのトレーニングを提供しています。お気軽にご相談ください（初回相談無料） 人材流動性の高まりを日々感じているみなさんこんにちは。 最近いろんな会社にお呼ばれしていて、その中でエンジニアの採用の話になることがとても多いのでちょっと整理しておきます。 ポイント▼「面白いプロダクトもないし、仕事内容は面白いとは思えないし、よい給与は払えないし、仕事環境にも自由はないけど、良い人雇いたいんだけど、どうしたらよいですか？」悪いが諦めろ。良い人は当然のことながら複数の会社が興味をもつことになるし、働く場所を自分で選択します。Pros/Consを見極めて選ぶことになるので、Prosがない場所で働く理由がありません…だとあまりに冷たいので、もしあなたが次に転職するとして、それでも今の会社に入るのであれば
理想的なエンジニアでありたい - kurainの壺
前回のエントリにかなり反響があって、友人達が数ブクマして終わりという想定もしていたので、少々驚いている。 エクスキューズを全く入れなかったのもあって、いろんな感想を持たれた。 フワッとした文章で論点もはっきりしてないので、 941 さんのブコメはもっともだと思う。 ただ、一番言いたかったことは、 "プライベートを犠牲にしなきゃ、理想的なエンジニアになれない" って発想が嫌だってことだ。 結構ブコメで"好きだからやっているんだ"っていうコメントが多くて、そんなのは僕も知っている。 僕もコーディング大好きで、なんの制約もなければ体力の続く限りやることもあるだろう。 自分の時間の内であれば、コードを書くのも勉強するのも犠牲なんて思わない。 でも、それでいいの? 持続可能なの?って話なんだ。 独身のひとは、好きなようにすればよいかと思う。その人だけの人生だし。 でも、テレビゲームしたり、漫画読んで
IT業界でありがちな説明下手について - 文系プログラマによるTIPSブログ
横着しちゃいかんのです。 IT業界に限った話しではありませんが、説明下手な人っていますよね。 私がIT業界でよく日頃から感じている説明下手（質問下手とも言う）なエピソードについて書いてみます。 例 この話から私が理解できた部分 この話から私が理解できなかった部分 どうして話が伝わらないか どうすれば伝わったか こういう質問が返ってきたら説明下手かも！？ 雑感 例 やらないおさん、落ちちゃうんですけど、getHoge()のこの部分があれで、多分ああなんじゃないかと思うんですけど、どうすればいいですか？ ？？？？ え？ごめん。何の話？いきなりソースコードの具体的な箇所の話されても理解できないから、落ち着いて順を追って話してみようか ※ 以降、質問をする側を「やるお」、される側（私）を「やらないお」とします。 ※ getHoge() メソッドはやるおが自分で作った独自メソッド。当然やらないおは知
[翻訳] コードレビューについて
この記事は::..: glen.nu :.: ramblings :.: on code review :.::の意訳記事です。@9len氏の許可を受けて投稿しています。 This article originally appeared in English at :..:: GLEN D SANFORD :.: RAMBLINGS :.: ON CODE REVIEW ::..: and has been translated with @9len’s permission for posting to this blog in Japanese. この記事は2014年3月に書いている。Twitterでユーザ検索チームを私が率いていたころの話だ。この記事は、コードレビューに関するセオリー・アプローチを体系化することを狙いとしていて、いくつかの基本的なプラクティスの確立を狙っている。あな
Inspired: 顧客の心を捉える製品の創り方を読んだ - ninjinkun's diary
プロダクトマネージャーの職能+ユーザー体験設計の本です（と解釈しています）。 最近Rebuild: 98: Superhumans Wanted (Naoya Ito)やエンジニアからみた良いプロダクトマネージャとは？ - サンフランシスコではたらくソフトウェアエンジニア - Higepon’s blogで話題のプロダクトマネージャーに興味があって、関連しそうな本を読みたいと言っていたら、知人がこの本を紹介してくれました。 Netscapeなどでプログラマーをしていたバックグラウンドを持ち、eBayなど複数の会社でプロダクトマネージャをしていた経験を持つ著者がプロダクトマネージャーの職能について語る本で、以下のような内用が含まれています。 プロダクトマネージャーとは何か どうやって他の職種と連携して働くか どうやって製品を見つけ出すか どうやってユーザー体験を作っていくか 自分にとっては、
ドワンゴの準エンジニア手当という制度が面白い - 続・はてなポイント３万を使い切るまで死なない日記
ドワンゴにはエンジニア手当というものがあって、プログラマーの給与水準が全体的に高くなっている。要するに優遇されている。 しかし、プログラミングの知識はエンジニアだけでなく企画者、あるいはデザイナーにとっても重要である。したがって、エンジニアから他の職種へのコンバートも積極的に進めるという方針がドワンゴにはあるのだが、このときにエンジニア手当というのが問題になる。要するにエンジニアをやめて他の職種にいくと給料が下がるのだ。 そのため元エンジニア手当みたいなものを作ろうとかいうような話もあったのだが、それはそれで不公平ではないかという議論もあり、結果として準エンジニア手当というものを創設し、一定の技術スキルがあることが試験で認められれば、元エンジニアだろうが、元からの企画者やデザイナーだろうが、給料が上がるという仕組みを導入することにしたのだ。 これがいまドワンゴ社内で盛り上がっているらしい、
エンジニアから非エンジニアに歩み寄る方が捗る - Konifar's WIP
非エンジニアのメンバーと話していると、 なんだかもどかしい気持ちになることがあります。 なんか話が噛み合わないというか、すごく他責な言い方をすると 「もっと開発のこと理解してほしいなぁ」と感じてしまう時があるんですよね。例えば、難易度の高い修正をさらっとできそうな感じで話されたりとか、逆に超簡単なのに難しいと思って遠慮されてたとか。そういう認識の違いから来るもどかしさです。 最近、このもどかしさを解消するには エンジニアから非エンジニアに歩み寄る方がいいなぁと思い始めたので、考えをまとめてみます。 相手の立場に立って考え直す このもどかしさ何とかならないかなぁと考えていた時に、 SHIROBAKO 17話『私どこにいるんでしょうか…』を見ました。 この回では、新人制作の佐藤さんがアニメーターの遠藤さんにちょっとキツいスケジュールの仕事をお願いし行くシーンがあります。 佐藤「宜しくお願いしま
共通化でモチベーションと効率が低下した話 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 自分は普段ソーシャルゲームの開発に関わっていますが、群雄割拠のグリモバ全盛期にその開発を効率化するために社内ではいろいろな取り組みがなされました。そのひとつにアプリ別ではなく機能別のチームを作るということがありました。結果としてそれは失敗だったと言えるのでそのことについて書いていきます。 背景 当時のソーシャルゲームの主流はカードゲームで、クエスト・レイドをこなしつつガチャで引いたカードを合成して強化していくスタイルが一般的でした。そしてその多くがシステムはほとんど同じで見た目だけを変えた「柄替え」アプリでした。 その中で行われたのが二
【ノンプログラマ向け】プログラマの仕事内容を理解する(1) ～「テスト」という工程が必要な理由 | きのこる庭
前書き 「一緒に働いている以上、プログラマのことを理解して仕事をしたい」そう考えている企画・ディレクションの方は経験則的に少なくない。 ノンプログラマから見て、プログラマの仕事はイメージが湧きづらく、何故その工程にそこまでのコストをかける必要があるのかわからない事が多い。 プログラマは作業の必要性を説明してくれるかもしれないけれど、専門用語も多いしイマイチピンとこなかったりする。 ここで重要なのはまさに「イメージ」だと思う。すなわちイメージを提供するための良質なメタファーだと思う。メタファーが良質であれば より直感的に理解できる。 実際メタファーの力はバカにならない。「Chef」も「Jenkins」も それぞれ 統一的な世界観が学習者の直感的な理解を後押ししてくれる。 というわけで、今回から数回に分けて なるべく「技術的な話」をせずに イメージを想起しやすいストーリーを導入することで プロ
些末なゴミは出所を問わず拾うのが客商売 : 404 Blog Not Found
2014年03月13日16:30 カテゴリArtCode 些末なゴミは出所を問わず拾うのが客商売 USJのジェットコースターは なぜ後ろ向きに走ったのか? 森岡毅 たとえ話を一つ。 些末なコードレビュー - naoyaのはてなダイアリー あるサービスの JavaScript が重いとか、そのコードが難読化されてないとか、担当者とおぼしき人間が書いたコメントがそのまま残ってるから消しましょうよとか、そんなことが書かれていた。JavaScript が重い、という話は結局そのサービスの JavaScript が重かったのではなく、ユーザーが自分で導入した広告が重いというだけの話だった。駐車場に停めてあったクルマがぐしゃぐしゃになっている。向かい側に停めていた人が、アクセルとブレーキを踏み間違えて、いきおいよくぶつけちゃったらしい。クルマの持ち主はもちろん、クルマのメーカーも何も悪くない。だけどつ
自転車置場の議論 - bkブログ
自転車置場の議論 人が集まると、なぜかどうでもいいようなことほど議論が紛糾してしまう傾向がありますが、このような現象のことを、FreeBSD のコミュニティでは自転車置場の議論 (bikeshed discussion) と呼んでいることを知りました。 この、「瑣末なことほど議論が紛糾する現象」はパーキンソンの法則という本の「議題の一項目の審議に要する時間は、その項目についての支出の額に反比例する」という法則として知られています。 この本の中で著者は、原子炉の建設のような莫大な予算のかかる議題については誰も理解できないためにあっさり承認が通る一方で、市庁舎の自転車置場の屋根の費用や、果ては福祉委員会の会合の茶菓となると、誰もが口をはさみ始めて議論が延々と紛糾するというストーリーを紹介しています。 このように、「瑣末なことほど議論が紛糾する現象」はパーキンソン氏によって見事に説明されているの
『ゾーン』に入る方法
『ゾーン』とは、極度に集中した精神の状態のことです。『フロー状態』とも言います。 極度に集中した状態では、時間の流れが遅くなり、作業は、なめらかに転がるように、よどみなく進んでいきます。 私はプログラマーですが、『ゾーン』に入ってバリバリ書きまくれるときもあれば、躓いてばかりでちっともコーディングが進まない時もあります。 今日は私が実践している『ゾーン』に入るための方法を説明します。 あらかじめ断っておきますが、私がこの方法で『ゾーン』に入れるのは、10回に３回です。 気温の変化、体調の変化、途中で割り込みがないか、前日よく眠れたか、合コンで意中の相手に無視されたか、などなど、 ありとあらゆる影響が『ゾーン』に入ることを妨げます。 それでも知りたい、という方は続きをお読みください。 事前準備人の脳のうち、自覚して使われていない部分を「無意識」の領域と呼びます。 「無意識」には、「意識」下に
DHH語録 - COBOL技術者の憂鬱
David Heinemeier Hanssonという方は「Railsを作った偉い人」という印象が強いのですが、エンジニアの仕事や生き方について普段からとても深い発言をしている方なので、私なんかはそちらの方に注目してしまいます。 彼の言葉を目にする度にいつも、思わずハッとさせられた後、しばらくしてからじんわりと心に響いてくるような力に打ちのめされてしまうのです。なんか怪しげな宗教のような感じですが、そんな彼の数々の言葉をネット上からかき集めてみました。 ソースはこのあたりから。 Error 404 (Not Found)!!1 David Heinemeier Hansson | The Great Surplus 翻訳 - Ruby on Rails: David Heinemeier Hanssonへのインタビュー #2 Ruby on Rails作者 David Heinemeier
自分を首に出来るように働く - プログラマでありたい
年末ということで、自分がどのような働き方を目指しているのかを改めて考えてみました。結論的には、自分がいなくても仕事が回るような仕組みやチームを作り、いつでも抜けられる状態にするということです。つまり、いつ首になっても問題が無いポジションに落としこむということです。この働き方は、圧倒的に楽です。自分にしか出来ないことがないので負荷が集中しないし、代わりの人間がいるので心理的にもプレッシャーは少ないです。そもそもルーチンの仕事は、自動化などでシステムが出来るようになります。そうすると、面白い仕事が出てきた時に取り組み易くなります。 反対に自分にしか出来ない仕事を抱え込んでしまうとどうでしょう？自分自身がボトルネックになるので、休めないし心理的なプレッシャーもあります。そして、延々と同じ仕事を続ける必要があります。10数年働いてそれなりの数の人を見てきましたが、自分のポジションを保つために仕事を
ソフトウェアエンジニアの成長カーブ（再掲載）：柴田 芳樹 (Yoshiki Shibata)：So-netブログ
「ソフトウェアエンジニアの成長カーブ」 最近良く話していることなのですが、社会人として働き始めた新卒の技術者は、最初の数年は成長していきます。与えられた業務を遂行しながら、そのための学習もしていくからです。しかし、2、3年すると開発業務をこなせるようになり、特に新たな勉強をしなくても、日々、会社に行って開発業務が遂行できるようになります。 この状態、つまり、継続した学習をしなくなった状態で、10年とか経過すると、ソフトウェアの世界は大きく変化している可能性があり、新たな技術が登場し、その人の技量は相対的に今度は低下しはじめます。しかし、この時点で、新たなことを学習するのは困難だったりします。学習する習慣が無いわけですから、勉強しろと言っても、「なぜ、休みの日に勉強しなければならないのですか」ということになります。 そのような人に対して、マネジメントは、その人ができる仕事を与えて、何とか仕事
前向きなヒューマンエラー対策をしよう。 - Sacrificed & Exploited
SIerが仕切っている開発現場でありがちなのが、何かミスを犯すと、そのミスを防止するようにすごく手間がかかるチェックが追加されて、開発効率とモチベーションが下がるというダメなパターン。 たとえば、「今年度は申請書(EXCELシート)書いて上司の判子もらわないと svn commit すらできない職場で仕事することになりました。 - SiroKuro Page」とか。 これはプロセスマネジメントでもなんでもない、管理ごっこだ。管理したつもりになって自己満足しているに過ぎない！！ プロセスをマネジメントしたければプロセスを削れ: DESIGN IT! w/LOVE では、次のように述べられている。 プロセスマネジメントにありがちな間違いのひとつに、ミスを減らそうとして、そのチェックをするプロセスを増やしてしまうということがある。 もちろん、すべての場合にそれが間違いというわけではない。 そのチ
初心者レベルの言い訳をしない
出来上がったコードの可読性も含めた品質の悪さを、時間がなかったとかプロトタイプだからと言い訳する人がいます。スキルが高い人の場合は、同じ時間制約でも高い品質のコードを書きます。それは、ある程度無意識になるまで、訓練を重ねているからです。無意識になるまで意識して普段から活動するのです。 ソフトウェア開発ではないですが、熟練者と初心者の差を比較するために短時間でどれだけの成果が出るかを競うテレビ番組を時々見かけることがあります。必ず熟練者の方が量も質も圧倒的に初心者を凌駕しています。つまり、時間がなかったとかプロトタイプを言い訳にした時点で、経験年数に関係なく、初心者レベルだということです。 1988年に米国への赴任前の送別会で今は亡きS.Uさんに言われたのは、「与えられた仕事をこなして初めて次の難し仕事が与えられる」と言われたことがあります。逆に言えば、できないと判断されたら、仕事を与えない
プログラマが楽しく読めるLink集 Vol.1 - 乱筆乱文お許し下さいorz
ネットサーフィン（死語）をしていて、プログラマなら誰でも楽しく読めるハズ！ と思ったサイトや記事を紹介して行きます。 とりあえず、Vol.1ッ！ ハッカーになろう (How To Become A Hacker） 実は、この5つすべて（Python, Java, C/C++, Perl, LISP）を勉強しておくのがいちばんいいのです。 これらはもっとも重要なハッキング用言語だというだけでなく、 それぞれプログラミングに対してまったく違ったアプローチをしているので、どれも非常に有益な勉強となるでしょう。 Rubyは？（´・ω・｀）ｼｮﾎﾞﾝ Fine Software Writings 特に僕が好きな記事を！ ホワイの(感動的)Rubyガイド (why the lucky stiff) どうしてプログラマに・・・プログラムが書けないのか? (Jeff Atwood) ソフトウェア開発者のた
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
デスマーチが起きる理由 - ３つの指標