【翻訳】How to be a program manager - Joel on Software - GoTheDistance
たまたま見かけたのですが、とても示唆に富む記事だったので頑張って和訳してみました。延べ2週間近くかかった・・・。 ITを武器にする企業は、ベンダーやユーザーに関わらず｢program manager｣と呼べる人たちが必要だと思っています。37Signalsの｢Getting Real｣に近しいことをJoel自身も語ってくれていますし、今後僕らがどのようなキャリアを積んでいけばいいのか、技術力を梃子にしていく組織を作るのにはどうしたらいいのか、そういうヒントが込められています。 Joelの英語は、同じような意味の言葉を複数の言葉を使い分けて言っていたり、ぐるっと回り込んでから要点を記述することが多いので、正確な意味を伝え切れていないかもしれませんが、大きく意味が外れないように留意したつもりです。 原文はHow to be a program manager - Joel on Softwar
いま起きているWeb標準の進化、HTML5、CSS3、JavaScript 2.0
日本が大型連休に入る少し前の4月23日、W3CはHTML5の新しいドラフトを公開しました。いつも最新のWeb標準化動向を伝えてくれるWeb標準ブログのエントリ「Last Callに向け進むHTML5 | Web標準Blog | ミツエーリンクス」によると、今回のドラフトから仕様書に大きく手が加わり、Webサイトを作る人向け（制作者に関係する要件）と、Webブラウザを作る人向け（実装要件についての要件）ごとに見やすくなるようなスタイルシートが用意されたとのこと。 これまでも何度かこのブログでは、HTML5やJavaScript 2.0などのWeb標準の動向を書いてきましたが、今回は分かりやすいようにその動きをまとめてみました。 HTMLはHTML4でいったん進化が終了し、それ以後はXHTMLで進化していくことになっていました。しかし実際にはXHTMLは期待されたほど普及せず、XHTMLによっ
「ソフトウェアは工業製品ではない」、Rubyのまつもと氏が講演 － ＠IT
2009/04/10 ソフトウェアは工業製品ではない――。Rubyの生みの親としてしられるまつもとゆきひろ氏は2009年4月9日、InfoQ主催のイベント「QCon Tokyo 2009」の基調講演で、ソフトウェアと何であり、何でないのか、それはどういう性質のものであるのかを雄弁に語った。 コードとは設計である 「ビューティフルコード」と題した基調講演を行ったまつもと氏は、2007年に共著者の1人として出版した同名の書籍に書いたエッセイに込めた思いを、次のように語る。 「世界に冠たる日本の製造業のノウハウを適用することで生産性を上げることができるに違いないという発想がありますが、ソフトウェアは工業製品ではない。そうした誤解を正していきたい」。 ソフトウェア産業界では、よくエンジニアが何十万人足りないということが言われる。しかし、まつもと氏は、これは工業生産と同じ方法論を当てはめることから来
堀江貴文 エンジニアは誇り高くあれ｜【Tech総研】
東京大学文学部宗教学宗教史学専修課程中退。1996年に「有限会社オン・ザ・エッヂ」を設立。2002年に旧ライブドア社から営業権を取得し、2004年に社名を「株式会社ライブドア」に変更。2006年に証券取引法違反容疑で起訴されて一審、二審ともに有罪判決を受ける。現在上告中。1972年福岡県生まれ。 今、非正規雇用の増加やいわゆる「派遣切り」が社会問題になっていますけど、僕が前の会社（ライブドア）で社長をやっていたときは、技術者派遣やSI会社の常駐社員などは一切使わなかったし、逆に自社の社員を派遣することもしなかった。社内ではこうしたシステムを利用するようにかなり説得されたけど、ここだけは頑固に譲らなかった。 唯一、派遣会社を使ったのは受付の女の子たち。いろいろとあって押し切られてしまったのだけど、彼女たちが望めば正社員にしていたし、希望すれば総務や経理に異動もさせていた。ほかに社員でない人と
「解雇されないだけマシ」「長時間労働こそ鑑」――上司が陥る10の勘違い
ロバート・ハーフ・ジャパンは「管理職者の思い違い」に対する見解を発表した。「仕事があるだけ運がいいと思え」「長時間働く部下はいい部下」など、管理者の思い違いで士気をそがれた部下が転職しがちだという。 人材派遣企業ロバート・ハーフ・ジャパンは3月5日、「管理職者が陥りがちな思い違い」に対する10の見解を発表した。 （解雇されずに）仕事があるだけ運がいいと思え（Feeling people are lucky just have a job.） 達成不可能な場合でも、君ならできる、と仕事を振ればできるはず（Making work"mission impossible".） 部下と管理職は一心同体だ（Tying your employees' hands.） 長時間働く部下はいい部下だ（Equating busy with productive.） 景気好転は待つしかない（Waiting for
『使えない個性は、要らない個性。』 - シロクマの屑籠
21世紀が始まった頃、個性がやたらと礼賛された時期があった。 『ゆとり教育』。 『ナンバーワンよりオンリーワン』。 『自分らしさ』。 『世界にひとつだけの花』。 【個性的であること＝かけがえのないこと】という夢いっぱいの観念を、老若男女を問わず、誰もが礼賛するような空気が、日本じゅうに蔓延していた時期を、あなたも覚えている筈だ。 個性を礼賛した結果がこれだよ！ その結果、何が起こったのか？ 個性を礼賛し、個性を追求し、“自分らしさ”へと突き進んだ青少年の大半は、個性を賞賛されることもないまま、自分は個性的だという不良債権と化した自意識を胸に、平凡な日常をのたうち回っている。自分の個性が生かせない仕事はしたくない・働いたら負けだと思っている・自分の個性を大事にしてくれない社会が悪い・自分の才能を見抜けない上司が悪いetc…。そういう怨嗟をオーラのようにまといながら、心のどこかで“本当の自分”
技術力が足りない私。スペシャリストになりたい！ － ＠IT自分戦略研究所
過酷な環境にさらされながら、常にコンピュータ並みの正確さを要求されるITエンジニアたち。メンタルヘルスをうまくコントロールするには？ 樋口研究室の「ITコーチ」たちが、現場でいますぐ使えるメンタルヘルス改善のワザを教えます。 IT業界では、技術がすさまじいスピードで進歩しています。ITエンジニアには、常に新しい技術を学習し、そのスピードについていかなければならないつらさがあります。 「お客さまから見れば、ITエンジニアはコンピュータの専門家。でも自分は、技術的に未熟」。そんなふうに、期待と現実との差に悩むITエンジニアも多いと思います。 前回「苦手な仕事から逃げず、最後までやり抜く方法」では、気が進まない仕事を頼まれたときの乗り切り方をお話ししました。今回は、技術知識が足りないと感じたとき、上手に自分の心をコントロールして乗り切る方法を考えてみましょう。 ■見たことも触ったこともないミドル
マルチコア、マルチスレッド時代に果たすOSの役割 - builder by ZDNet Japan
SECCON2020レポート第二弾！ 名実ともに世界標準に！ 次の10年に向けたリファクタリング進行中 特集：IT最適化への道 成功の秘訣をその道のプロが解説 カギとなるのはシステムの「見える化」 Identityマスターへの道（5回目） ID一元管理のメリットをライフサイクルから 考えてみよう！ SoRとSoEをつなぐDX推進の要 新しい時代の顧客とのデジタル接点管理 クラウド型商品管理基盤（PIM）の重要性 デジタルを当たり前と言えるか？ 現状を非効率を変える機会と捉え行動する これが今、成長できる企業の共通項 使い慣れたUIのままクラウド化 オンプレミス運用のVDIをクラウド基盤に VMware Horizon on Azure VMware Solution ひとり情シスの在宅環境を公開！ 理想の働き方を実現するための テレワーク環境構築術 リモート、オフィス、オンサイト 働く場所
Geekなぺーじ : エンジニアが見落としがちなこと
過去に自分が間違っていたと思うことや、身近なエンジニア(技術者/研究者等)が「見落としているんじゃないか」と思える部分を列挙してみました。 ただし、それぞれ状況と立場次第であるものが多いのでご注意下さい。 製品を売る場合や、論文を書く場合、個人の場合など、様々な立場での色々なものをごっちゃに書いてしまいました。 1. 技術の凄さのみが戦局を決めるわけではない 「技術が凄ければユーザは勝手についてくる」という発想に出会う事があります。 それは、正しい場合もあれば正しくない場合もあると感じています。 最近は、得てして「技術だけ」ではあまり成功しないような気がしてきました。 そもそも「凄い技術」とは何なのかという部分が難しいです。 その「凄さ」が実現しているものと、ニーズとの一致などが的確で無い場合、いくら凄くても理解してもらえないことも多いです。 2. 誰が言うか、誰がやるかも大事な要素 全く
Java におけるコード進化パターン (Code Evolution Patterns in Java)
Java におけるコード進化パターン (Code Evolution Patterns in Java) asato shimotaki <asatohan at gmail.com> 最終更新日 : 2009/6/21 (2004/4/22 より) [...] For twenty years, I spent two or three hours a day looking at pairs of things -- buildings, tiles, stones, windows, carpets, figures, carvings of flowers, paths, seats, funiture, streets, paintings, fountains, doorways, arches, friezes -- comparing them, and asking my
On Lisp
Paul Graham著，野田 開 訳 前書き 拡張可能なプログラミング言語 関数 関数的プログラミング ユーティリティ関数 返り値としての関数 表現としての関数 マクロ いつマクロを使うべきか 変数捕捉 マクロのその他の落し穴 古典的なマクロ 汎変数 コンパイル時の計算処理 アナフォリックマクロ 関数を返すマクロ マクロを定義するマクロ リードマクロ 構造化代入 クエリ・コンパイラ 継続 複数プロセス 非決定性 ATNを使ったパージング Prolog オブジェクト指向Lisp パッケージ 翻訳者 野田 開のサイト 原著者Paul Graham氏のサイト Copyright (c) 2003-2005 野田 開 NODA Kai <t50473@mail.ecc.u-tokyo.ac.jp>
プログラミングできない元請けがプログラム設計書をレビューするという矛盾 - ひがやすを技術ブログ
人によってプログラム設計書の定義が違っていそうなので、最初に定義しておきます。ここでいうプログラム設計書は、ほとんどプログラムと対応するようなロジックが記述されているようなものです。 プログラム設計書を作るのは「誰が書いても同じコードにするため」だけでなく、元請けがレビューするためでもあります。元請けがプログラミング言語を読めないので、日本語に落としてレビューします。コードを書いてからプログラム設計書を作ることもあります。 プログラミングがあまりできない人が、ちゃんとしたプログラム設計書はかけないのと同じように、プログラミングできない人が、プログラム設計書のレビューはできません。 当然だよね。プログラミングができないのなら、プログラミング言語を自然言語に翻訳したプログラム設計書を理解できるはずがない。 できるとしたら、誤字脱字、単語が統一されていないとか、日本語が変だとかそんな指摘くらい。
プロジェクトは、計画通りに進まなくて当然
簡単なはずのプロジェクト管理が難しいのはなぜ？ 前回「プロジェクト管理は『簡単なことを、確実に』」では、プロジェクトマネジメントとは次の3つを行うことだと説明しました。 成果の設定 仕事の設計 PDCAサイクルを回すを回す 実際に行うべきタスクは、下図の通りです（図1）。これも、前回お話しした通りです。 これも前回の繰り返しになりますが、プロジェクトマネジメントそのものは、簡単なことを確実に行うだけなのです。 それでは、なぜプロジェクトで問題が続発するのでしょうか？ なぜ思った通りの成果が上がらないのでしょうか？ 今回は、「なぜプロジェクト管理が難しいのか」を考えることで、プロジェクトの本質とは何か、そしてプロジェクトで発生した問題をどのように解決すればいいのかについてお話ししたいと思います。 プロジェクト管理が難しい本当の理由 プロジェクトマネジメントがなぜ難しいか、その理由は2つありま
無料より優れたもの：七左衛門のメモ帳:
著者 ケヴィン・ケリー Kevin Kelly 訳 堺屋七左衛門 この文章は Kevin Kelly による "Better Than Free" の日本語訳である。 無料より優れたもの Better Than Free インターネットはコピー機である。いちばん根底のレベルでは、それを使う間の私たちの行動や文字や考えをすべてコピーしているのだ。インターネットのある場所から他の場所へメッセージを送ろうとすると、通信プロトコルに従って、その途中で何度かメッセージ全体をコピーすることになる。IT企業はこの絶え間ないコピーを促進する機器を売って大金を稼いでいる。コンピュータでひとたび生成されたデータの各ビットは、きっとどこかでコピーされる。デジタル経済はこのようにコピーの川を流れている。機械の時代の大量生産による複製と違って、これらのコピーは安いどころではない、タダなのである。 デジタル通信ネッ
ソフトウェア技術者としての残り時間 - naoyaのはてなダイアリー
年始の NHK でのイチロー特集番組を見ていて一番印象に残ったのは、他の人の道具を絶対に触らないというイチローのこだわりでした。曰く、人の道具を触るとその道具の感覚が体に残ってしまい、自分の道具を利用するときの感覚の妨げになるから、ということでした。全体を通して、イチローは他のプレイヤーとの相対的な競争の中に身を置いているのではなく、絶えず自分を改良し続けるという過程の中にいるのだというのがよくわかる内容でした。良い番組だったと思います。 気づけば自分も 30 歳になりました。まだ若いとは思っていますが、さすがに 20 代の頃に比べると、病気や怪我の治りが少し遅くなったと感じることもあり、少しずつ自分の人生、「死」ということを考えるようにもなりました。時間は有限ということが少しずつ実感できるようになってきました。あるいは実感できるようになってしまった、と言った方が良いかもしれません。 ここ
すばらしいソフトを作るには、カリスマが講演 ― ＠IT
記者という職業柄、これまで非常に多くのプレゼンテーションを見てきたが、プレゼンテーションの1枚目が半裸の女性モデルの写真だったのは初めてだった。 2月13日、14日の予定で東京・目黒で開催中の「デベロッパーズ・サミット2008」で講演したFog Creek Softwareの創業者でCEOのジョエル・スポルスキー（Joel Spolsky）氏のプレゼンテーション「Joel on Developers Summit――素晴らしいソフトウェアを作るということ」は、型破りに楽しく、なおかつソフトウェア開発者にとって示唆に富む内容だった。 スポルスキー氏は米マイクロソフトのExcelチームで、Excel用マクロ言語を、後にVBAと呼ばれることになるモダンなオブジェクト指向言語に置き換える仕事でプログラムマネージャを務めたことがあるなどソフトウェア開発のベテランだが、エッセイの書き手としても名を馳せ
Matzにっき(2008-02-04) - 初心者向けの言語|ソフトウェア開発における初心者
<< 2008/02/ 1 1. [言語] 「ハッカーと画家」の著者が新しいLisp系言語「Arc」を公開 | エンタープライズ | マイコミジャーナル 2. 「セキュリティ、なめんなよ!」 なめねこも一緒に情報セキュリティ強化宣言 | ネット | マイコミジャーナル 3. 「サイオステクノロジーはグルージェントの未来技術に期待し子会社化」：ITpro 2 1. [Ruby] Nimble Method: Garbage Collection is Why Ruby on Rails is Slow: Patches to Improve Performance 5x; Memory Profiling 2. [言語] LuaJIT roadmap 2008 3. [Ruby] What will Matz do? 4. [Ruby] EURUKO 2008 − European Ruby
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
クラウド時代に備えて、プログラマーが理解しておくべき考え方
「実現したいことを計算機の問題に置き換えることが『技術力』」、伊藤CTOが“はてな流”大規模データ処理の極意を語る：CodeZine
怠惰な Linux: 管理者に必須の 10 の秘訣
