わたしが知らないスゴ本は、きっとあなたが読んでいる: ブログでプロジェクトマネジメントする10の方法
マーケティングツールとしてのブログが流行らしいが、開発現場のマネジメントとしてブログを使えないかという提案。イントラネットに閉じたローカルブログ導入のヒントとして自分メモでもある。 1.ステークホルダーのコミュニケーションツールとして 進捗報告やマイルストーン毎のレポートなど、プロジェクトでやりとりする情報はかなりのものだが、それらを全て一斉同報メールで送るのは大変かも～というのであれば、ブログが有効かと。 日報、週報、月報のような定期レポートだけでなく、随時更新されるリスクマネジメントリストや、毎時参照されるトラブルレポートも対象となる。更新するタイミングでステークホルダーにお知らせメールを送るのも簡単だし、RSSリーダで読むようにすれば、それすらも要らぬ。その際、以下のルール決めをして浸透させておく必要がある。 どのタイミングで 誰の責任において どのような情報が 公開されるのか（公開
＠IT：初めてのプロジェクトリーダー（4）開発中、リーダーは何をしている？
1週間単位で、タスクと日付の交差する場所に担当者の名前を書き、完了したタスクには印を付けていきます。また、重要なマイルストーン（イベント）も同時に記入し、いまの作業は何を目的にして行っているのかを明示します。この例ですと、5月12日のデモに向けて各タスクを進めていることがよく見えます。 納期にかかわらず、開発メンバーは目の前のこと、いま作っているプログラムに意識が集中します。このような場合に、タスクの相互関係、タスクの組み合わせが達成する目的をはっきりと見せて、メンバーに期限優先の意識を持ってもらうことが狙いです。これはよくあるスケジュール表（ガントチャート）ですが、印刷して配布するよりも、このようにかんばん化して掲げることの方がより効果的です。 どのようなかんばんを使う場合でも、掲げただけで満足しないことが重要です。上手に機能するまで、時と場合に応じてかんばんと、その運用を改善していく必
わたしが知らないスゴ本は、きっとあなたが読んでいる: Wikiでプロジェクトマネジメントする4つの方法
「ブログでプロジェクトマネジメントする10の方法」への反応を見ていると、独り考え込むのでなくUPしてみるものだな、と思った。実務に適用している例や、Wikiでの試みがあることを知った。言及していただいた皆様、ありがとうございます。賛否ともども大変参考になり、中の人は感謝多謝することしきり。 Wikiを発展させた開発支援コラボレーションツールMrkrgnao（via:marsのメモ） Wikiを使った「Web向けLotus Notes」Jotspot（via:関心空間ラボ） 社内限定の非公開型ブログイントラブログ さらに、「Wiki との優位性が見えない」「ストレージサービスでええやん」というコメントがあったが、そのとおりだと思う。実際、前のプロジェクトでは Wiki+CVSで「設計書+コード管理」してたし。時系列に情報を積み重ねるのがブログなら、Wikiは樹構造的な展開に向いている。各人の
B3 Annex: グーグル、１０の黄金律
Newsweek最新号 (Issues 2006）に、Eric Schmidt（グーグルCEO）とHal Varian（バークレー校教授兼グーグル社コンサルタント）による「グーグル、１０の黄金律」（"Google:Ten Golden Rule"）が掲載されている。 必ずしも目新しくはないが、一応、日本語版をB3 Annex抄訳で。 ・採用は委員会方式で グーグルで採用面接を受ける人はすべて、少なくとも６人以上の管理者あるいは将来の同僚との面接を行う。すべての人々の意見が大切であり、このことで、採用のプロセスがより公平になり、採用基準の向上にもつながる。もちろん、それだけ時間がかかることになるが、その価値はあると思っている。すばらしい人材を雇い、その人を次なる採用のプロセスに集中的に組み込むと、さらにすばらしい人材を雇うことにつながる。 ・必要なものはすべてを供給せよ 私たちは、標準的な（
YAMDAS現更新履歴 - Joel Spolsky選定のマネージメントトレーニング用課題読書リストの邦訳版を作ってみた
Joel on Software の翻訳 Wiki の話は以前にも書いたが、その中に Joel Spolsky の会社である Fog Creek Software におけるマネジメントトレーニングプログラム用の課題読書リストが公開されている。二週間に一冊読んでいっても二年間かかるという長大なリストである。 ちょうど Tech 総研で「この春に読みたい！TOPエンジニア推薦のIT技術書20冊」という記事が公開されているのを見て、件の読書リストで邦訳が出ているものだけ並べてもそれなりのリストになるのではないか、それにサポートページなどの情報を加えれば他の人の参考になるかと思ったのである。実際やってみると、邦訳だけでも50冊を超えるリストになり、正直死んだ（笑） 見やすいように著者や内容で大雑把に分類させてもらった（不適当な分類があったらすいません）。正直言って、この本が入るか？ というようなも
HOW DO YOU LIKE SILICON VALLEY? | Google 本社 ツアー
一定期間更新がないため広告を表示しています
あなたが来たとき、地球は止まっていた - 脇見運転
はてなに入った技術者の皆さんへ 志、という言葉が社会で急速に価値を失いつつある今、それをきちんと言葉にして、後輩に伝えられる人は貴重です。ましてその言葉が外の人を感心させるほど影響力があるひととなるとどれだけいるでしょう。 近藤氏は数少ないその一人です。 ところで「はてな」は開発に重きを置く会社なので当然ですがメッセージは開発技術者向けです。 当たり前ですが、どんな世界も自分が何かを始める前は自分が居ない状態で回っています。しかも、そこそこちゃんと回っているのです。何か新しい事を始める時、「その世界はあなた無しでもちゃんと回っている」状態から出発する事を忘れないでください。極端な話、「自分が生まれなくても地球は問題なく回っていた」のです。 ところがサポート技術者に関してはちょっと状況が異なります。というのは、あなたがサポートの仕事に就くとき、そこにあるのは「動かない世界」です(w。あなたが
技術者として仕事をするということ - panic hagging
今更ですが、id:jkondo氏の技術者社員向けメッセージを読んで感じたことをコメント。自分はこういったバリバリとコードを書いてサービスをどんどん生み出していくような仕事ではないものの、一応IT業界の端くれとして思うところがあった。多分、業界は違えどそれぞれがおかれた立場なりの解釈で読めば、ある種「仕事論」や「プロ論」に通ずる文章になっているのではないだろうか。 アウトプットを出すということ 仕事としてなにかをするからには、適切なアウトプットを出すことが必要だ。そしてそれは自己満足で終わってはいけないと思う。芸術家ではないのだから。 アルファブロガーの小飼弾氏も言っているが、何がアウトプットかは自分で決めればいいのだ。ただし、それを周りの人間が判り、納得するようなカタチで出し、認めさせること、それが重要なのだと思う。 翻って自分の立場に戻れば、アウトプットは高品質なサービスを高い生産性で提
37signals Jason Fried氏の講演 「より少ないシンプルな機能で競争する」：Goodpic
This shop will be powered by Are you the store owner? Log in here
シゴタノ！ - 読み手の負担を最小化するメールの書き方
Tips for Mastering E-mail Overload 受信トレイに山のように届くメールをいかにして効率よくさばくか、という技術的な話はそれこそ山ほどありますが、結局自分一人ががんばっても“山”そのものを動かすことはできません。 そもそも、メールは気安く送ることができるために、コスト負担構造が逆転している、すなわち書き手よりも読み手にとって重荷になっていると、書かれています。 ●メールが登場する以前は、送り手にコストがかかっていた ●連絡文を書く、切手を貼る、投函する、といった手間、 ●送り先の数に応じて嵩む郵送料、 ●それゆえ、おのずと送り先を厳選していた そして、 ●メールの登場とともに、これらの送り手のコストが格段に下がり、 ●ちょっとした思いつきや衝動でメールを送れるようになった ●しかも、一度に数十人の同僚に送り届けることができる ●自分ができる、ということはみんな
POLAR BEAR BLOG アイデアを殺す22の方法
久しぶりに箇条書きネタ。How Blog > Core 77's Design Blog という経由ですが、「アイデアを殺す台詞/態度」というエントリがありました： ■ Idea killers: ways to stop ideas (Berkun Blog) で、内容はというと： 「それはもう試したよ。」 「そんなのうまく行かないよ。」 Would you like a pony? （※すみません、ここ意味分からず。検索すると割とヒットするフレーズなんですが・・・。pony = 子馬、重要でないものということで、「そんなつまらないことしたいのか？」という意味？） 「ばかげているな。」 「君はクビだ。」（※失敗すれば処罰される、という雰囲気では新しいアイデアは表にでない、という意味？） 「君には強く反対する。」 （笑い） 「予算にないな。」 「それは重要な問題じゃないよ。」 「時間がない
小野和俊のブログ:プログラマー風林火山
アプレッソというベンチャー企業の CTO を務めて6年と2ヶ月になる。変化の激しいベンチャーに比較的長い期間身をおいていたので、社内外のいろいろなタイプのエンジニアと仕事をしてきた。 あるエンジニアが参加することで開発チームが短い期間で大きく変わったこともあったし、開発チームのメンバーが15人いた頃よりも、お互い補い合えるエンジニアが5人くらいの頃の方が成果が出たりすることもあった。 そういう経験を重ねていくにつれ、私の中では、スターエンジニアと呼べる人たちの持っているものについての、いくつかの類型ができてきている。今まで一緒に仕事をしていく中で本当に心強かったのは、最近エンジニアのキャリアパスの議論でよく言われるような財務のわかるエンジニアとか営業もできるエンジニアではなく、あるいは人と異なるユニークな能力を身に付けようとしているエンジニアでもなかった。ではどういうエンジニアが、というこ
源泉徴収票って何？ - ［一般事務の仕事］All About
今年最後の給与や賞与の明細の中に紛れこんでる、あるいは年末調整の戻り金と一緒に貰う、小さな紙…これって何？ それは多分、源泉徴収票です。 この書類…一体どうするの？と聞かれる事もあるのですが、ひとつの会社だけで正社員として勤務している方には、その後必要となる機会はあまり無いかもしれません。 とりあえず、「年収と支払った税金の額がわかる書類だし、大事に持っておいたらいいよ」と言う事にしてるのですが、何が書いてあるかよくわからないかも…それもそうです。確かにちょっと不親切な書類なんです。 なので今回は自分が提出した年末調整書類の結果がちゃんと反映されているかチェックするためにも、源泉徴収票の見方をご説明しますね！ 源泉徴収票ってどんな物？ ↓こんなカンジの書類です。見覚えありますか？会社によって書式や大きさは少し違いますが、ハガキサイズより少し小さいくらいの、薄い紙のこと
顧客の機能要求に折れないこと!
Kathy Sierra /青木靖 訳 2006年5月10日 製品やサービスが成功するほど、ユーザの要望を受け入れるようにというプレッシャーは強くなる。ユーザが多くなるほど、要望の範囲は広がっていく。あるユーザにとっての ｢それがないんだったら買わない｣機能が、別のユーザには取引をぶちこわすものになる。そしてあなたの製品やサービスが人気になるほど、そういった要望は、要求と最後通牒へと変わっていき、ついには痛烈な批判になる。 私たちになしえる最悪のことは、それに折れるということだ。しかし要望/要求や批判が強く、怒りを帯びたものになるほど、誘惑に抵抗するのは難しくなる——｢この1個だけ付け加えれば･･･きっとあの連中もおとなしくなってくれる｣ しかしあらゆる色を1つに混ぜ合わせて泥色のしみを作るなら、誰も私たちのすることを嫌わなくなるが、同時に誰も喜びも、興奮も、魅了もされなくなる。そうして私
社会の面白法則一覧 - FIFTH EDITION
色んな面白い社会の法則を集めてみた。 メイヤーの法則 「事態を複雑にするのは単純な仕事だが、単純にするのは複雑な作業である。」 パーキンソンの法則 「仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する」（第一法則） 「支出の額は、収入の額に達するまで膨張する」（第二法則） ブルックスの法則 「遅れているソフトウェアプロジェクトへの要員追加はさらに遅らせるだけだ」 クラークの三法則 「高名だが年配の科学者が可能であると言った場合、その主張はほぼ間違いない。また不可能であると言った場合には、その主張はまず間違っている。」 「可能性の限界を測る唯一の方法は、不可能であるとされることまでやってみることである。」 「充分に発達した科学技術は、魔法と見分けが付かない。」 ゴドウィンの法則 「ネットでの議論が長引けば長引くほど、ヒトラーやナチを引き合いに出すことが多くなる」 ディヘイの公理
パラサイト・プログラミング steps to phantasien t(2007-04-16)
2007-04-16 近況 最近の私はもっぱらサンプルからのコピペが仕事. コピペといっても Ctrl+C, Ctrl+V より少しだけインテリジェントだけれど, ライブラリが強力な上に文書の出来が良いから, 多くはサンプルの改変で済んでしまう. 面白くはないが生産性は高い. コピペ・ハイウェイの渋滞にぶつかり, サンプルのないパターンに出会うこともある. そういう時は自分でコードを書く. でもだいたい動かない. Getting Started や入門書はざっと読んである. それでもわからない. 文書化されていない不具合や common pitfall だったりする. (間抜けな間違いもあるけれど...) こんなとき Google はあまり役にたたない. 使っているライブラリやフレームワークがよほどメジャーでない限り, 解決方法はなかなかみつらない. せいぜい自分と同じところで悩んでいる人
HOW DO YOU LIKE SILICON VALLEY やはり受託からイノベーションは生まれない
一定期間更新がないため広告を表示しています
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Blog - Mikula Beutl - SEO Consulting
米国で進行するROWEという名の労働革命 - 経営者倶楽部
Not Found