開発チームがミーティングを嫌う理由 島国大和のド畜生
賢明な皆さんはもうご存知でしょう。 そんなもん『仕事が増えるから』に決まってます。 例にゲーム開発を考えてみましょうか。（俺ゲーム屋だから） 世の中には会議をすると仕事が進む職種と仕事が増える職種があります。 開発は後者です。 ゲームを作っているとして、作りかけのゲームを挟んで会議したとします。 「この辺、操作性悪いよね」 「ここのUIが解り難いよね」 「ここバランス不味いよね」 偉い人は、こういうのを言うだけで、指示になります。 開発は１コ聞く度に仕事が増えます。 ぶっちゃけ現場でいじってる人間は突っ込まれる前に解っていて、今後のスケジュールで対応する予定だったりします。 しかし、『作りかけの物から完成品を想像する能力が足りない人』が、間違ったツッコミをしてソレがエライ人だったりすると、スケジュール的に無理をしてでも突っ込まないといけない（しかも入れることによって他に悪影響が出て余計にス
納期が延びる要因を指標化する － スケジュールのDRAGとはどんな尺度か | タイム・コンサルタントの日誌から
久しぶりにスケジューリングの話を書こう。スケジュールがなぜ長くなってしまうのか、どこを攻めたら短くできるのか、それを数字で指標化できる手法についてである。 いま、あるシステム製品をおさめる仕事を考える。単純化のために、この仕事は以下の６つの作業項目（アクティビティ）のみからなると考える。 1. 基本設計 （推定所要期間＝20日） 2.1 ハード調達 （推定所要期間＝35日） 先行作業：基本設計 2.2 設置調整 （推定所要期間＝ 5日） 先行作業：ハード調達 3.1 詳細設計 （推定所要期間＝10日） 先行作業：基本設計 3.2 ソフト開発 （推定所要期間＝20日） 先行作業：詳細設計 4. 総合テスト （推定所要期間＝15日） 先行作業：設置調整、ソフト開発 さて、このお仕事の納期は何日かかるだろうか。これは、作業項目とその順序関係を図に書いてみると分かりやすい。仕事の全体像をネッ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
