エンジニアがミーティングを嫌う理由はいい視点だと思う。いわれてみればそのとおり。 それでも個人的な経験でいうと，ミーティングに出るようになってからの方がストレスが軽くなった気がする。 ↓なんでかっていうと，こういうことを後になって言わなくても済むから。
それでもエンジニアがミーティングに出るべき理由 ： nabokov7; rehash - livedoor Blog
エンジニアがミーティングを嫌う理由はいい視点だと思う。いわれてみればそのとおり。 それでも個人的な経験でいうと，ミーティングに出るようになってからの方がストレスが軽くなった気がする。 ↓なんでかっていうと，こういうことを後になって言わなくても済むから。
情報システム関係の人とかこれ見とくといいよ - チョコっとラブ的なにか
こんなの出てたから、見ておくといいかもね。 経済産業省では、情報システムの取引において、現行の「人月方式」以外での価格決定方法を模索するため、情報システムの付加価値に着目して価格を決定する「パフォーマンスベース契約」について検討を行ってまいりました。 今般、「情報システムのパフォーマンスベース契約に関する調査研究」報告書として取りまとめましたので、公表いたします。 「情報システムのパフォーマンスベース契約に関する調査研究」報告書の公表について - 経済産業省 本文のさわりにはこんなことが書いてあったよ。 1 はじめに 1-1 背景と目的 我が国の情報システム市場は、現在、主として「人月ベース」の価格表示を行っており、それに伴う価格の根拠がユーザ側の価格への不信感につながっていることは従来から多数指摘されている※が、残念ながら、この課題は現在まで業界全体として抜本的に解決されるには至っていな
日本的経営が社畜を生んだ理由 - elm200 の日記(旧はてなダイアリー)
社畜とは、会社に強い忠誠心を持ち、私生活を犠牲にして、会社での労働を第一に置くような価値観をもつ従業員を揶揄する言葉だ。「社畜論」については、日本では定職を持たず、その後、オーストラリアで修士号を得て、いまはシンガポールで会社勤めをする海外ニートさんのブログが面白い。（アクセスすると音が出るので気をつけてね） 先日、私は、「異なる文化をもつ人たちと働くということ」、「残業は恥だ」という日本の労働環境を批判するエントリを続けて書いた。私はかつてカナダのローカル企業で２年半くらい働いたし、その後も、韓国・中国・ベトナムなどに住んで、現地の人たちの働きぶりを観察する機会を持った。 とにかく、日本の職場の雰囲気や考え方は、海外の職場とは著しく異なる。しかも、北米（カナダ・アメリカ）の職場と日本以外のアジア（韓国・中国・インド・ベトナム）の職場の雰囲気は当然異なるものの、それでも日本のそれに比べると
RedmineとTracの機能比較 - プログラマの思索
RedmineとTracの両方でチケット駆動開発を運用してみて、色んな気付きがあった。 以下メモ書き。 【比較対象】 ・Redmine0.8.0 ・Trac0.11.1.ja 【元ネタ】 脱Excel！ Redmineでアジャイル開発を楽々管理 － ＠IT自分戦略研究所 【1】複数プロジェクトの扱い RedmineがTracよりも機能が優れている点の一つは、複数プロジェクトに対応していること。 Tracはプロジェクトに親子関係を入れることができないため、特に大規模プロジェクトではチケット駆動開発を実践しにくいだろうと思う。 複数プロジェクトを作りたい状況は、二つある。 【1-1】開発チームが複数のサブチームに分かれていて、それぞれでタスク管理したい場合。 RedmineやTracを運用してみると、一つのプロジェクトでメンバーが5人以上だとチケットが乱発されたり、放置されやすくなるようだ。
脱Excel！ Redmineでアジャイル開発を楽々管理
ソフトウェア開発のタスクをチケットに登録すると、作業を始めるチケット管理をメインに、進ちょく管理、問題管理などができる。 バグ管理システムだけでなく課題管理システム（ITS：Issue Tracking System）で運用する開発プロセスは、チケット駆動開発（TiDD：Ticket Driven Development）と呼ばれ、最近注目されている。 Ruby1.9の開発はRedmineで管理されているように、近ごろは事例も増えている。 Redmine運用前の問題点 筆者がRedmine運用前に持っていたプロジェクト管理の問題点は下記2点だった。 1．Excelでのタスク管理の限界 従来からプロジェクトマネージャやプロジェクトリーダーの多くは、進ちょく管理やタスク管理をExcelで行ってきた。 プロジェクト管理では顧客へ進ちょく報告するために、残工数と残タスク数を計算する必要がある。だが
IT業界の裏話: 組織が150人を超えると仕事の質は劣化する
前回、『世界最大のコンサル会社が最低の仕事をする理由』というエントリーで、小さい規模で機能していた優れたアプローチを大規模な形にスケールさせることで硬直化してしまうという話をしました。 → http://it-ura.seesaa.net/article/114822601.html どんなに優れた人材や組織であっても規模の拡大によって生じる品質の低下（劣化）を生じてしまうということなのですが、10人や20人くらいの組織であれば個々人の連携によってそれなりのパフォーマンスは期待できます。 「我々の間には、チームプレーなどという都合のよい言い訳は存在せん。有るとすればスタンドプレーから生じるチームワークだけだ。」 と言ったのは攻殻機動隊の荒巻さんですが、では、一体何人を超えると組織のチームワークを期待することが難しくなってくるのでしょうか？ これについて、とても興味深い数字を発見しました。そ
優先順位を決める - The Joel on Software Translation Project
Joel Spolsky / 青木靖 訳 2005年10月12日 水曜 FogBugz 4.0をいじり回すのをやめて、5.0に取りかかる時だった。私たちは大きなサービスパックをリリースし、誰も出会うこともないだろう細かいバグを山ほど修正し(そして誰も出会うこともないだろう新しい小さなバグを2つほど新たに作り)、何か本当に新しい機能を付け加え始める時になっていた。 開発に取りかかる準備ができた頃には、改良のためのアイデアはプログラマ1700人で何十年分になるくらいたまっていた。あいにくと私たちの元にいたプログラマは3人だけであり、来年の秋にはリリースしたいと思っていたので、やることの優先順位付けをする必要があった。 私たちが機能のリストを優先順位付けするのに使った方法のことを話す前に、やるべきでない2つの方法について話しておこう。 1番目。誰か1人の顧客に約束しただけのために何かの機能を実装
負けかた上手の時代 - レジデント初期研修用資料
恐らくは「大きく勝つ」のが得意な人と、「なるべく小さく負ける」ことが得意な人とがいて、 それぞれに求められる能力は、根本的に異なっている。 「勝ちの流れ」を引きずって今まで来た業界には、「負けの上手」がいない。 これからしばらくのあいだ、どこかにいる「負けの上手」は、業界の国境をまたいで、 様々な「負け戦」の指揮を求められる、そんな時代が続く気がする。 大学医局のこと 自分が研修期間を終えた頃には、医師というものは、大学に残って「上」を目指すのが 当たり前みたいな空気がまだあって、自分みたいな、最初から民間病院に就職する人間は 珍しかったし、そういう連中ですら、同期のほとんどは、自分も含めて、 やっぱり大学医局の門を叩いた。 医局に入った最初、「今はみんなが大学医局に戻って来たがるから、 ここに居られるのはせいぜい3 ヶ月だよ」なんて、当時の医局長に宣言された。 3ヶ月は結局1 年になり、
リーダーが押さえておくべき１０箇条 - モチベーションは楽しさ創造から
私の上司は「能力」が低すぎます！：NBonline(日経ビジネス オンライン にもありますが、今、上司、リーダーの役割が果たせていない上司が増えているとういコトが問題になっています。 これから更に景気悪化が深刻化してくるようになれば、職場はドンドン元気がなくなっていくでしょう。かといって、カンフル剤などはありませんから、各職場のリーダーの役割が特に重要になってきます。リーダーのモチベーション力、やる気を引き出す力は当然の事かもしれませんが、それ以外にリーダーの役割とは、どのようなものがあるのでしょうか？ 今週読んだ本で、新将命さんが書かれた「伝説の外資トップが説く リーダーの教科書」には、リーダーが果たすべき役割が上手にまとめてありました。リーダー必読の書ではないでしょうか？ 伝説の外資トップが説く リーダーの教科書 作者: 新将命出版社/メーカー: 武田ランダムハウスジャパン発売日: 2
少人数開発と「能力プール」 - 設計者の発言
■少人数プロジェクトが儲かる理由 開発案件の最終利益率とプロジェクトメンバー数には一定の相関がある。開発に関わったメンバーの数が少ないほど、一般に利益率は高い。実際に数字で調べてみたわけではないが、筆者の過去の経験からも確信できるし、そのように思い当たる人も多いだろう。 その理由は単純である。メンバーが多いほど、メンバー間の情報伝達のためのコスト（情報コスト）が飛躍的に増えるためだ。指示やいわゆるホウレンソウのための初期コストだけでなく、訂正や伝達ミスにともなうさまざまな後追いコストが、人数の多いプロジェクトほど大きくなる。メンバーが２人のときに情報コストが１だとすれば、（１人のときなら０）、人数に従って次のようにコストは増えてゆく。 ２人 １ ３人 ３ ４人 ６ ５人 １０ ： ： ｎ人 n(n-1)/2 たとえこの事実が理解されていたとしても、これらのコストを考慮して工数積み上
The Goog Life: how Google keeps employees by treating them like kids 日本語訳
The Goog Life：グーグルが従業員を子供扱いすることでつなぎとめている件 著者： Aaron Swartz 日本語訳： yomoyomo 以下の文章は、Aaron Swartz による The Goog Life: how Google keeps employees by treating them like kids の日本語訳である。 先日友達と、シリコンバレーで絶えず会話のネタになるもの、Google の話をしていた。で最後に、彼女がすべてに筋を通すヒントをくれたんだ。「子供扱いしてるのよ」と彼女は語った。「ただ飯をあてがい、洗濯をしてやり、弾力のある色鮮やかなボールの上に座らせる。彼らが成長し、自力で人生を生きる方法を学ぶ必要がないようにすべてをやってあげるわけ」 そのように見れば、Google がやることすべてに恐ろしくつじつまが合う。 僕が Google を最後に訪
いいアジャイルと悪いアジャイル
スクラムはラグビーにおいて最も危険な段階であり、それというのも、潰れたり不適切なかみ合い方をすると、前列のプレーヤーが怪我をしたり、首の骨を折る危険すらあるからだ。—Wikipedia 私が子供の頃には、コレステロールは体に悪いものだった。これは覚えやすかった。脂肪は悪い。コレステロールは悪い。塩分は悪い。みんな悪い。しかし近頃では、コレステロールが「いい」コレステロールと「悪い」コレステロールに分かれている。私たちがこの2つをどうにかして見分けられるとでもいうように。そしてその切り替わりは奇妙なものだった。FDAが突然プレスリリースを発表して、殺鼠剤には2種類、いい殺鼠剤と悪い殺鼠剤があり、いい方はたくさん摂って悪い方は摂ってはならず、そして決して2つを混ぜたりしてはいけないのだと言ったかのようだった。 一年くらい前まで、私はいわゆる「アジャイル」プログラミングに対して、ごく一次元的な見
CMSとモバイルとフィードと四畳半社長: 責任者は現場で昼行灯が理想
CMSとモバイルとフィードと四畳半社長 東京都文京区本郷でとあるCMS開発会社を営む社長のブログ。さっきまで「越後のCMS問屋」だったのですが、会社が新潟に移転したと勘違いされたようなので変えました。 モバイル、ゲーム、フィード、Ajax、Flash、ハイテクグッズあたりのはやりモノが好きです。 最新作「メルルーの秘宝」がドワンゴから提供中 週刊アスキーで「2045年の週刊アスキーをつくる」連載中 昨年末、体調を崩して入院し、しばらく会社を休むことになってしまったのですが、休んでいる間は大変なことになっていました。 やっぱり社長が休んじゃいけない。 それでも今回は、前回の入院よりはマシでした。 経営経験がある水野くんや、営業の最前線を切り盛りするT女史など優秀な幹部が揃ってきていたし、通常以上に頑張るスタッフ達が居ました。 けれどもやっぱり、決断する人間は現場にいなくてはならない、
はてなブログ | 無料ブログを作成しよう
うまくいかない日に仕込むラペ 「あぁ、今日のわたしダメダメだ…」 そういう日は何かで取り返したくなる。長々と夜更かしして本を読んだり、刺繍をしたり…日中の自分のミスを取り戻すが如く、意味のあることをしたくなるのです。 うまくいかなかった日のわたしの最近のリベンジ方法。美味しいラペを…
recompile.net: サン流だけど一流のバグ管理心得
Java EE 5のStar Spec LeadであるBill ShannonがGlassfishのメーリングリストにバグの考え方の話を投稿してたんで、勢いで翻訳しちゃう。 大規模開発のときのバグ管理の心構えとしても興味深いですね ちがう、ちがう、ちがう。 バグポートフォリオをどうやって使うのかを、また説明しなきゃいけないようだね。もう毎回ずっと、ああもう、8年くらい？ リリースのたびに説明してこなかったっけ？ バグにそもそものプライオリティなんかないんだ。バグはプライオリティとともにうまれるわけじゃない。バグのプライオリティってのは、我々の決定なんだ。単なる技術的な決定じゃない。単なるバグの影響度でもない。単なる重大性でもない。バグは、リソース、ビジネス上の判断なんかによって、決定されるもんなんだ。 バグの優先度は、意思決定プロセスの結果なんだよ。つまり、どれがバグで、どれがバグじゃない
システム開発プロジェクトの標準工期は投入人月の立方根の2.4倍 | スラド
日本情報システム・ユーザー協会が、ユーザー企業102社の357プロジェクトを調査したソフトウェアメトリックス調査2007を発表したことに関する記事が@ITに掲載されています。この記事によれば、調査対象プロジェクトの工数と工期をグラフ化し、回帰直線に出した結果、標準開発工期は「投入人月の立方根の2.4倍」という結論を導き出したらしい。1000人月であれば24ヵ月の工期設定が標準ということだ。他にも、システムの画面数やファイル数も工期設定に使えるということで、調査からは「必要工数＝0.1×ファイル数＋1.3×画面数＋0.3×バッチ数」という数式になるそうだ。画面数だけでは、「必要工数＝画面数×1.55」ともなるらしい。さすがにこれだけで工期設定するのは無謀だが、ある程度の参考にはなるのだろうか?
企画屋さんは自分の仕事はデザインだと認識したほうがいいんだと思うよ：DESIGN IT! w-LOVE
不確実な時代をクネクネ蛇行しながら道を切りひらく非線形型ブログ。人間の思考の形の変遷を探求することをライフワークに。 いわゆる典型的な企画屋さんの仕事ってほんとに手におえないなって、最近つくづく感じます。 僕自身、どちらかというと企画を担当する仕事をしてますけど、そんな僕からみても、いわゆる企画屋さんの仕事って傍からみてても「おいおい、それじゃあ、いつまで経っても形にならないよ」ってくらい、実装のことを無視した仕事の進め方をしてたりします。 制約を知らない人たちそれでいて、そういう人たちに限って「自分はものづくりにかかわってる」みたいな顔したり「ユーザー視点がどうこう」とか言ったりします。客観的にみると、ぜんぜん、ものづくりの視点が欠けてるし、ユーザー視点のかけらもなくて単にあなたの思いつきを並べてるだけですよね、と思うことが多いんですけど。 とにかくアイデアベースだけなので、ものづくりが
Life is beautiful: リーダーに必要とされる感情知性（Emotional In...
MBAプログラムに参加したおかげで、大量の論文を読まされることになったのだが、頭の中を整理する意味で文章にするのは役に立つし、それがブログのちょうど良いネタになる。今日のエントリーは、Daniel Goleman という人の書いた”What Makes a Leader?” という論文の要約。 筆者は（企業などの）リーダーになるためには、ただ高い知性と専門知識を持っているだけでは不十分で、筆者がEmotional Intelligence(感情知能)と呼ぶ能力を持っていることが不可欠だという。 Emotional Intelligenceには５つの要素がある。 Self-Awareness 自分のムードや感情を常に冷静に把握しており、それが他の人に与える影響を十分に認識していること。Self-Awarenessが低い人は、自分の性格の欠点を指摘されたりするとそれを「個人攻撃」と見なして不必
Life is beautiful: 私のとっておきのプログラミングスタイル
404 Blog Not Found の「LiveCoding に学ぶプログラミングの三原則」を読んでいたらどうしても書きたくなったので。あくまで私のスタイルなので、参考にするもしないもご自由に。 1. スタードダッシュでできるだけはやくめどをつける 学生時代から夏休みの宿題は７月中に終わらせていた私とすれば、ラストスパートよりはスタートダッシュで勝負する。どのみち、どこかで思いっきり頑張らなければならないのであれば、締め切り間際ではなく、スタート間際に頑張るべきというのが私のポリシー。十週間のプロジェクトであれば、最初の二週間が勝負。そこで八割がたのめどをつけておき、後は流す。最初の二週間がめどが立てられなければ、十週間で完成できる可能性は低いと考える。常にそういう姿勢でいれば、締め切りぎりぎりになって致命的な欠陥が見つかって痛いめにあったり、本当は大幅な設計変更をすべきなのに応急処置で
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「頭のよさ」をコンビニの現場から考える - G.A.W.