PMやディレクターに必要な３つのマネジメント - GoTheDistance
タイトルは僕の造語です。 ビジネス・アーキテクツ代表取締役の森田さんが、下記雑誌の対談でこのような発言をされていました。 Web Site Expert #14 作者: WebSite Expert編集部出版社/メーカー: 技術評論社発売日: 2007/09/27メディア: 大型本 クリック: 5回この商品を含むブログ (6件) を見る 「正しく動いていることを担保してくれれば良いので、プロジェクト自体を開発するのは物事を作る仕事につながることです。PMPの資格を持っていますといっても、プロジェクトの開発、つまり案件化はできないですからね。じゃあ、どうやって僕たちはそれをできるようになったのかと言えば、これはまた別の難しい話ですけれどね｣ Webディレクションの世界でも僕のようなSIの世界でも、似たようなお悩みがあるんだなと思いました。 つまり、｢システムを作る・Webを作るマネジャーとモ
開発抽象化レイヤ - The Joel on Software Translation Project
Joel Spolsky / 青木靖 訳 2006年4月11日 火曜 若い男が町にやってきた。彼は見かけも悪くないし、ちょっとは金も持っていた。 過去のことについてはあまり話したがらないが、血の通ってない大企業に長くいたらしいことは明らかだった。 彼は生まれつき人当たりが良く社交的で、自分に自信を持っていながら傲慢ではない。だから地元のプログラマーズ・カフェにある求職の掲示の中からちょっとした仕事を見つけるのは、彼には簡単なことだった。しかし保険データベースプロジェクトや、主婦向けの飾りだらけのWebページや、会計計算エンジンといったものには、やがて興味をなくしてしまった。 １年もたつと、彼の慎ましい生計を1年支えられるくらいの蓄えができた。それで贔屓にしてくれるアルザス人へのコンサルティング仕事の後、食料品店の上にある自分のアパートの陽の当たる部屋にコンピュータを据え付け、選りすぐったツ
チームリーダー日記 : 「グループ内で締め切りタイミングをずらす」ことの狙いと効用
各開発メンバーの 締め切りタイミングを ピッタリ一致はさせないでおく。 ■全員の締め切りが一致してる場合 全員が同時にピリピリしてきて、 チーム全体でのバッファが急速に無くなっていく。 で、どんな対処案も取れなくなって、ギューっとなっていく。 ┏━┳━┳━┳━┓ ┃空┃２┃14┃３┃ ┣━╋━╋━╋━┫ ┃12┃９┃15┃８┃ ┣━╋━╋━╋━┫ ┃１┃６┃７┃13┃ ┣━╋━╋━╋━┫ ┃11┃10┃５┃４┃ ┗━┻━┻━┻━┛ #空きが２つだと加速度的に楽になる。 こんな風に１箇所空いてて そのスペースを使って各マスを動かして 数字を並べるパズルがあります。 特にチームリーダとかを経験してる人は わかると思うけど、 何かしらの対処策を取ろうと思うなら 常にバッファを用意しますよね。 ☆その１ 一番難しい箇所は２番手の人に担当させ、 １番手の人はそこには投入しないで 含み益にしておく。
オンスケジュール＝崖っぷち - 極北データモデリング
転職して分かった、進捗管理という面白くない作業を楽しくやる方法について。 タイトなスケジュールを組んで、そこからの遅れをチェックするから、楽しくないし、遅れが隠蔽される。 ダルダルにゆるいスケジュールを組んで、1週間以上前倒しにできているかどうかをチェックすれば、みんな遅れていることを隠さないので早めに手が打てる。 タイトなスケジュール＆遅れチェックだと「2日遅れです」と言わなくてはならないところを、だるいスケジュール＆1週間前倒しチェックなら「3日前倒しです」と言えるので気分がいい。 情報量はどっちの言い方でも同じだから、気分のいい言葉を使えばよい。 だいたいオンスケジュールというのは崖っぷちに居るということで、カゼ引いたり障害発生したりしたら即遅れてしまうのだから、「オンスケです」という報告がよいニュースのわけがない。「前倒し」という名前を付けたバッファの減少傾向を見張って、オンスケジ
アジャイルで不幸にした業界、法令工学を応用することで、幸せになれれば。。。 - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） いいけどね！ せっかくコメント無視、匿名で書いているんだから、 もっと、世間から、反発されるけど、大事なことを、たまには、書いてみたいと思う。 最近、IT業界って、暗いとおもいませんか？ 村上企画官のおことばを待つこともなく、７Kとか１０Kとか、まったくもって、暗い、イメージの悪い業界になってしまったと思います。 こうなった原因の多くは、アジャイルという名のもとに行われる、仕様の五月雨式変更にあるとおもいます。 ウォーターフォールだった、８０年代後半、９０年代前半は、後工程で仕様変更が原則できないため、どの仕様変更を（例外的に）あえてするか、それをした場合にどれほどのインパクトがあるかを計算してから、行われました。つまり、要求仕様が管理されていました。 さらに、テストに関しても、
「エンジニアは魔法使い」という幻想 : LINE Corporation ディレクターブログ
こんにちは、ライブドアの櫛井です。今回はディレクターとエンジニアの意思疎通についてお届けしたいと思います。 ■魔法使いはいない？ 一般的な受託案件などの場合、サイトのプログラムやサーバーまわりの調整などはシステム開発会社の担当の人が一手に引き受けてくれます。しかし、 livedoor のように社内に開発部がある会社では、ディレクターが自力でエンジニアに「何をしたいか」「なぜそうしたいのか」「それをすることで何を目指すのか」ということを正確に伝えていく必要が出てきます。 サイトの規模によってはエンジニアがディレクターを兼ねる場合もあるかもしれませんが、ウェブ業界全体を見てみても「ディレクターで元エンジニア」という人は希少で、ほとんどの場合プログラムやサーバーサイドの仕組みを十分理解できているディレクターというのは稀な存在といえます。 システムの知識を十分持っていないディレクターたちが抱く幻想
デスマーチを防ぐスケジューリング : LINE Corporation ディレクターブログ
こんにちは。「livedoor 検索」担当の須田です。 今回はデスマーチを防ぐスケジューリングについて書きます。 以前紹介された、「4つのステップで作る webサイト開発のスケジュール作成」という記事も併せて参考にしてください。 みなさんは周囲で、「このお客様は大事なお客様なので、納期早めでお願いします」または、「大型の案件なので早めに作業してください」という声を聞いたことはありませんか？ 仮に、優先すべき案件だとしても、無理なスケジュールで作業を進行することは好ましくありません。 デスマーチ状態に陥るようなスケジュールを作成してしまった場合、ディレクターとして以下のような原因が考えられます。 1）技術者を魔法使いであるという幻想を持っている。 ※これに関しては、「エンジニアは魔法使いという幻想」という記事にも紹介されています。 2）技術者の作業内容について、「結果」は知っているが、「過程
戦闘機開発もAgileでいこう - masayang's diary
Agile JournalのCASE STUDY: War Stories - Fighter Jets and Agile Development at Lockheed Martinという記事が興味深い。大企業・ハードとソフト両方・飛行機（それもF-35 Lightning II）という品質重視分野・世界各地に分散した開発チームという条件下でのAgile適用事例だ。 長いので全部は訳さないけど、ポイントをいくつか。 規模 企業の規模は、従業員１４万人、４５カ国４５７都市に分散。米国だけで９３９施設。 従来は... いわゆるウォーターフォール式で開発をしてきた。 製品の投入周期は年一度かそれ以下のペースで、製品投入直前の数ヶ月はいわゆるデスマーチに近い状態（原文では「Fire Drill」）だった。 開発チームは作業項目単位で結成された。そして、ある作業がうまくいったという「前提で」次の
眠る開発屋blog｜最新オンラインカジノのニューカジノ情報
もしもこの世から「残業」が完全になくなったら ３年ぐらい前に読んだ本を思い出した。 １９８０−９０年代の話ですが、残業について、 「時間外・休日労働の弾力的運用が我が国の労使慣行の下で雇用維持の機能をはたしている」（１９８５年労働基準法研究会報告）とか、「我が国の労働慣行の実情に合うような上限設定が可能かどうか定かでない」（１９９２年同報告）と、雇用維持の為のコストとして恒常的な長時間労働を是認する考え方が主流でした。 需要の低下に応じて、生産水準を下げなくてはならなくなっても、バッファがあるから解雇せずに大丈夫でしょ、という。。。 まぁ、 ところが、その後、労働法政策が内部労働市場の雇用維持から外部労働市場における移動促進に徐々にシフトしていったにもかかわらず、この長時間労働哲学には疑問が呈されないまま２１世紀に至っているのです。 と著者は問題視しているわけだけど。 話変わって、最近友人
404 Blog Not Found:惰訳 - 建築士がプログラマーのごとく働かねばならぬとしたら
2007年10月26日01:45 カテゴリ翻訳/紹介Art 惰訳 - 建築士がプログラマーのごとく働かねばならぬとしたら 全プログラマーが泣いた。 If architects had to work like programmers... 実は一つだけ「ローカライズ」にあたって変えた前提があります。日本ではこちらの方が実情に沿っているでしょう:) 建築士様、 家を一つ設計施行してくださいな。まだ何が必要か具体的なことはわからないので、そこはよきに計らう方向で。 寝室の数は、2から45までの間。寝室の追加と削除は簡単に出来るようにしといて下さいね。青写真が出来次第あたしが何が気に入ったかを最終判断します。それぞれの青写真について明細書を付けるのをお忘れなく。後で気に入ったのをピックアップできるように。 完成後の家の費用は、今住んでいる家よりも安上がりでないと駄目なことを留意してくださいな。そ
言語が解ることと言語を使いこなすことの違い
Ognacの雑感 木漏れ日々 目次 ホーム 連絡をする RSS Login Blog 利用状況 投稿数 - 1487 記事 - 0 コメント - 45674 トラックバック - 143 書庫 2014年5月 (6) 2014年4月 (13) 2014年3月 (14) 2014年2月 (12) 2014年1月 (12) 2013年12月 (13) 2013年11月 (13) 2013年10月 (11) 2013年9月 (13) 2013年8月 (14) 2013年7月 (13) 2013年6月 (14) 2013年5月 (15) 2013年4月 (13) 2013年3月 (14) 2013年2月 (13) 2013年1月 (15) 2012年12月 (14) 2012年11月 (14) 2012年10月 (15) 2012年9月 (14) 2012年8月 (13) 2012年7月 (13)
チームリーダー日記 : ガントチャートは進捗管理の本質を外している
「お菓子のまちおか」さんが店舗を増やしているのは、コンビニのお菓子のラインナップがつまらなくなってきたから？
Life is beautiful: 会社のカルチャー作りの大切さ
University Washington で Executive MBA のコースを受けることにした理由の一つは、成功する企業とそうでない企業を分ける要因を私なりにちゃんと理解したかったからである。 Microsoft 時代に Bill Gates の下で働くことにより、業界の流れを読んだり、それに基づいた企業戦略を立てることに関しては、それほど不自由を感じなくなった。しかし、いざ自分で起業をしてみて強く感じたのは、企業戦略を立てることは「初めの一歩」でしかなく、その戦略に基づいてちゃんと利益を生み出す組織を作りあげる方がその何倍も何十倍も難しいということ。 色々と反省する点はあるのだが、あえて一番反省している部分を上げるのであれば、会社のカルチャー作りに十分な注意を払って来なかったこと。戦略に関わる mission statement や vision に関しては常にはっきりと語り続け
Ringo's Weblog: 知識の量が質に変化する瞬間
プライバシーポリシー | サイトポリシー | 商標 | フィード | サイトマップ Copyright© 2000-2007 Community Engine Inc. All rights reserved.
失われた２０年－ソフト業界は変わったのか？ その１２：１９９５年ごろ（５） - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） ２０年位前、１９８０年代終わりごろから、最近まで、ソフト業界とかその周辺の変遷について、特にソフト開発の立場を中心に見て行く、土日シリーズ「失われた２０年－ソフト業界は変わったのか？」その第１２回目。 今、１９９５～９９年までについてです。今回は、そのころの開発方法論、その２ 構造化分析やDFDについてです。 ■情報関連図からDFDに １９８０年代から、９０年代のはじめころまで、COBOLベースの開発のころは、要求仕様レベルで、機能を書くとき、情報関連図（FIO図っていうのと同じかな？）で書いてました。機能があって、入力、出力を書くものです。 で、これをもっと、機能とデータをはっきり分け、他人でも検証可能な形にしたDFD（データフローダイアグラム）が盛んにつかわれるようになります
マネジメント改革の工程表 岸良裕司・著 | タイム・コンサルタントの日誌から
機知に溢れた、楽しい本である。正直言うと私は、（「気まぐれ批評集 書評」のページを見てもらえれば分かるとおり）あまりビジネス書のたぐいを読まない。理由の一つは、書評には最初から最後まで全部読み終えた本だけを取り上げることにしているからだ。ビジネス書はしばしば、必要な箇所だけを参照するために買うので、全部を読み通すことがあまりない。さらにもう一つ、たいがいのビジネス書のスタイルが、肌に合わないこともある。理論の説明中心で教科書的になるか、あるいは雑誌記事的な事例と感想の羅列だけで、通るべき芯が通っていないか、どちらかのケースが多い。そしてユーモアが足りない。 さいわいこの本には、軽快なウィットがあふれている。これは著者の資質のあらわれなのだろう。著者の岸良氏夫妻には、昨年秋のシドニーのプロジェクト・マネジメント国際学会ProMAC 2006の席上でお会いしたこともある。察するに岸良氏は、理論
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
So-net blog:港区赤坂四畳半社長:はてなとマッキンゼーとUEIとマイクロソフト、社内コミュニケーションについて
www.ennetforum.org is Expired or Suspended.
http://zerobase.jp/blog/entry-431.html
Ringo's Weblog: イベントドリブンGTD