タグ

pmに関するxmx3のブックマーク (23)

  • 尊敬するゲームディレクターの話 - FANTA-G:楽天ブログ

    2010.05.20 尊敬するゲームディレクターの話 (6) カテゴリ:カテゴリ未分類 私の尊敬するゲームディレクターの話。 彼はとにかく「コスト管理と対価効果」の見極めが非常に上手い人でした。 例えば、ゲーム内の背景モデルの見積もりをデザイナーが当然のように検討しているところにひょいと表れて「なあ、このゲーム、背景モデルいらなくねえ?」と(W.何を言い出すんだこの人は!と一瞬思いましたが「このゲームでは視点がぐるぐる変わらなきゃいけないようなシチュエーションはほとんどない。だったら、そのためにモデラーを半年以上、5人も拘束するのは馬鹿馬鹿しい。だから、必要な場所以外はアニメーションの背景スタジオに2Dでお願いした方が早いし、いいものが出来る これが見事に正解。おまけに2D独特の味わいも出て、しかもアクセスも早いという、イイコト尽くめの結果でした。 これ以外にも、デザイナーが端役キャラクタ

    尊敬するゲームディレクターの話 - FANTA-G:楽天ブログ
  • 未来から道筋を探す - レジデント初期研修用資料

    チームで何かを生み出すときには、「こんなものを作りたい」という目的と、もう一つ、「それが達成された未来」のビジョンを、なるべく具体的に語れるように思い描いておくと、意思統一がしやすい。 方向要素と距離要素 「こうしたい」と、「それでさらにどうなってほしい」とを想定して、それを共有することで、リーダーがどういう思考に基づいて「こう」を目指したのか、点が2つ作れると、方向と、飛躍の距離を測定することができるから、議論が収斂しやすくなる。 「こうしたい」という目的だけだと、恐らくは「その先」が拡散する。そこに至るまでの道筋も、方向が共有できないから、議論が拡散してしまう。 「こうしたい」と「その先」とが決定できると、今度は恐らく、「その先の未来」から、まだ何も始まっていない現時点に至るまでのロードマップが描ける。道筋が、叩き台として議論の場に登場するから、何が実現可能で、自分たちに何が不足してい

    xmx3
    xmx3 2010/05/19
  • Bungie流プロダクション管理の、中心にある考え方 - ゲームの花園

    この前のエントリーで書いた、BungieがGDC2009で講演したプレゼンテーション資料を読み終えましたが、新鮮な内容で面白かったです。 Bungie流のプロダクションの作り方に関するPPT Building Your Airplane While Flying: Production at Bungie ※下から2つ目。Download articleで、PPTファイルが落とせます。 内容は、HALO 1 〜 HALO 3を制作していく過程で、開発スタイルがどのように進化してきたのか、Bungie流のプロダクションの作り方を解説したものとなっています。ゲームのクオリティも譲れないけど、開発者の生活も大切。その時、Bungieでは、どういう取り組みを行ってきたのか。といったものになっています。 ちょうど今、地球の反対側ではGDC2010が開催されているので、ものすごく旬を過ぎた感が否めない

    Bungie流プロダクション管理の、中心にある考え方 - ゲームの花園
    xmx3
    xmx3 2010/03/14
    "ゲームの品質"と"開発者の生活"を両立させる手法。* 品質優先 早い段階での選択と集中  ゲームをブラッシュアップする作業を削らない 事前に計画された追い込み期間 * 開発者優先  * 状況に適応する
  • Geekなぺーじ : オーム社開発部での開発体制

    オーム社開発部さんでのの作り方を取材させて頂きました。 社内で自作ツールをバリバリ作って、出版作業の効率化を行っているのが凄いと思いました。 ただし、今回取材をした内容が行われているのは、オーム社開発部のうちの1グループ(グループは約3名)です。 全体的にこの体制で行われているわけではないそうなので、ご注意下さい。 取材実現の経緯は「オーム社開発部の方とのやり取り」をご覧下さい。 Subversionでバージョン管理 著書の原稿は、XML管理されており、そのXMLはSubversionで全ての著者(監訳者)と共有されているそうです。 Subversionのサーバはインターネット上にあり、各自がリモートで作業を行える環境が整い始めているため、最近では著者と一度も会わずにが完成するという案件もあるそうです。 フォントなどの問題から、番環境でのPDF作成はオーム社開発部で毎日行っており、毎

    xmx3
    xmx3 2010/01/23
  • ほぼ日刊イトイ新聞 - 社長に学べ! (10)面談はこんなに大事なのか!

    社会にでてからの勉強には、 答案用紙もないし、満点の答えもありえない……。 大きな生きた組織を動かしている経営者たちは、 そういう、誰も答えを知らないことや、 学校で教えてくれないことを、たくさん知っている! よし、おとなの勉強をしてみよう。 いまの社会で指揮をとっている人たちから、 じかに学ばせてもらう連載の第2弾に登場するのは、 任天堂の社長、岩田聡さん(いわたさとるさん)です。 おそらくこの「社長に学べ!」の会話は、 若い女性とかが読んでいるのでしょうし、 「なんで社長に学ぶ必要があるんだ?」 という気分も、あるとは思うんですけど、 やっぱり、学べるんですよね。 たとえば男女がつきあっている状態で、 「明日ふられるかもしれない」 ということについて 心配しつづけてつきあっていたら、 もうなにもできなくなりますよね?

    xmx3
    xmx3 2009/11/26
    最初に全員に話をきいてみて 「面談してはじめてわかったこと」が ものすごく多かったんです。 「人は逆さにして振らないと  こんなにもモノをいえないのか」 とあらためて思いました。
  • ほぼ日刊イトイ新聞 - 社長に学べ! - 任天堂社長 岩田聡

    <body bgcolor="#ffffff"> <noscript><iframe src='https://www.googletagmanager.com/ns.html?id=GTM-MPV974L' height='0' width='0' style='display:none;visibility:hidden'></iframe></noscript> <script charset='UTF-8' src='/home/js/global.js?20200619'></script> </body>

    xmx3
    xmx3 2009/11/26
    岩田さん、いまも、任天堂で、 HAL研究所でやっていた面談を 復活したというおウワサをききますよ?(笑) 百五十人ほどです。 最近は、全部長四十人ぐらいとも 面談しました。
  • 【TGS2009】『Gears of War』のEpic Gamesが語る、Unreal Engine、開発手法、そして日本 | インサイド

    『Gears of War』(GoW)シリーズで一躍、世界中のハードコア・ゲーマーを虜にしたエピック・ゲームズ。 同社はまた「Unreal Engine」シリーズを擁するゲームエンジンベンダーとしても有名で、スクウェア・エニックスの大作RPG「ラストレムナント」でも採用されるなど、現世代機で一人勝ちの状態です。しかし技術情報に比べて企業の実態は、あまり知られていませんでした。 東京ゲームショウで開催されるビジネスフォーラム「TGSフォーラム」で24日、エピック・ゲームズ社長のマイケル・カップス氏は「『Gears of War』フランチャイズを世界の舞台へ」と題して講演し、「GoW」の成功を支えた同社の企業理念について説明しました。また「Unreal Engine」サポートのため日に事務所を構えること、さらには日語版の発売が遅れた理由についても明かしました。 エピック・ゲームズは米ノース

    【TGS2009】『Gears of War』のEpic Gamesが語る、Unreal Engine、開発手法、そして日本 | インサイド
  • 「どうして日本企業がiPhoneを生み出せないか」という設問について - FutureInsight.info

    以下のエントリーを読んでいろいろ感じたことがあったのでまとめてみます。 日の家電メーカーが出す商品はなぜ”もっさい”のか - キャズムを超えろ! iPhoneは権限委譲やデザイン重視とかで到達できる領域のプロダクトではないですよね 皆様ご存じの通り、日の大企業がデザイン重視とか権限委譲をしてもiPhoneはできません。iTunesも結局ジョブスの力が無ければ、iTunes Music Storeのような最強のプラットフォームに育つことはなかったことは以下のに書かれている通り。以下のエントリーにもまとめているのでどうぞ。 「iPodは何を変えたのか?」の読みどころはジョブスが音楽レーベルをどのように説得したか - FutureInsight.info iPodは何を変えたのか?上浦 倫人 おすすめ平均 ジョブスと長い付き合いの著者ならでは迫真の記述 ★「ニューヨークを盗んだのは、あの機

    「どうして日本企業がiPhoneを生み出せないか」という設問について - FutureInsight.info
    xmx3
    xmx3 2009/09/17
  • 優秀な独裁者がいることがプロダクト作成の組織体制において最強 - FutureInsight.info

    以下のエントリーに補足して「日企業がどうしてiPhoneを生み出せなかったのか」について考えた時、考えれば考えるほど「プロダクト作成の組織体制において優秀な独裁者がいることが最強なのだ」という結論に至ってしまいます。 「どうして日企業がiPhoneを生み出せないか」という設問について - FutureInsight.info この「優秀」という言葉の意味がポイントでこの優秀さというのは、「時代にフィットした優秀さ」のことを意味します。考えてみれば、iPhoneの時に引き合いに出されるウォークマン、プレイステーションなども産まれた背景には、その時代に即した独裁者が企業のトップに存在していた訳です。 逆に、このような優秀な独裁者が居ないときには、製品ロードマップを緻密に描き、さまざまな問題点をテクノロジーマネージメント部門がしっかりと把握、解決し、さらに組織が一体となって開発や運用、マーケ

    優秀な独裁者がいることがプロダクト作成の組織体制において最強 - FutureInsight.info
    xmx3
    xmx3 2009/09/17
  • BonusRound 308:リリース日というジレンマ:Part 1 - LYEのブログ

    GameTrailers.com Bonus Round 308 Part 1 Release Date Dilemmas http://www.gametrailers.com/episode/bonusround/308?ch=1 司会 Geoff Keighley パネル Randy Pitchford (プレジデント / Gearbox Software) Brian Jarrard (コミュニティディレクタ / Bungie) N'Gai Croal (ビデオゲームコンサルタント/ Hit Detection) Jeff: リリースってのは何で遅れるんだろう? Brian: わかんない。パブリッシャにはパブリッシュに関連するマーケティングとかそういう点を気にしなくちゃいけないし、開発チームはゲームを作るというクリエイティブな面の仕事を担当している。だから結構別々のものなんだよね。

    BonusRound 308:リリース日というジレンマ:Part 1 - LYEのブログ
  • 見積もり・発注 - 技術情報Wiki

    発注/調達 † 値切ってはいけない 2009.3.6 確かに,プロジェクトには予算が決められており,その予算の枠内でやり遂げる必要がある。どうしても予算と見積もり金額が合わない場合には,入念に価格交渉を行い,発注者と受注者の双方が金額の妥当性について合意した上で確定させるべきなのだ。 そのためには,PMは出てきた見積もりを査定する能力が必要であり,かつ高い折衝能力が必要である。 はじめてのRFP 2008.2.4 調達用語 RFP,SLCP,SPAとか RFP(Request For Proposal:提案依頼書) SLCP−JCP98:Software Life Cycle Process - Japan Common Frame 1998 SPA(Software Process Assessment)

    xmx3
    xmx3 2009/08/27
  • デッドライン ソフト開発を成功に導く101の法則

    正しい管理の四つの質・適切な人材を雇用する。 ・その人材を適所にあてはめる。 ・人々の士気を保つ。 ・チームの結束を強め、維持する。 (それ以外のことは全部管理ごっこ) 安全と変更・変更は、あらゆるプロジェクトの成功のために(ほかの大抵の物事についても)必要不可欠である。 ・人は安全だとわからないと変更を受け入れない。安全が保証されていないと、リスクを避けようとする。 ・リスクを避けることは、それに伴う利益をも逃すことになるため、致命的である。 ・人は、面と向かって脅されたときはもちろん、自分に対して不当に権力が行使されるかもしれないと思ったときにも、安全ではないと感じるようになる。 負の強化・脅迫は、結果を上げさせる手段としては不完全である。 ・どれほど強い脅しをかけても、最初に割り当てた時間が足りなければ、やはり仕事は完成しない。 ・さらに悪いことに、目標を達成できなければ、脅迫の内

    デッドライン ソフト開発を成功に導く101の法則
    xmx3
    xmx3 2009/07/28
    この本おもしろかったな。
  • プロダクションの価値: プロジェクトマネージメントの価値 - LYEのブログ

    今回からは同僚 (後輩♂) Pierre (←日人です) と共同で翻訳しました。 下記のものは Google Doc で上書き翻訳した文書を整形したものです。 http://docs.google.com/View?id=ddrk8bqq_149cg2d8qfw 翻訳記事のご意見ご感想などありましたら、是非コメントとかブコメに記入をお願いいたします。今後のモチベーションの燃料とさせていただきます! なお、次回は Project Horseshoe 2008 - Group Report: Multiplayer Game Atoms http://www.projecthorseshoe.com/ph08/ph08r5.htm を翻訳する予定です。 著作権とか 注1: 記事の内容に関する一切の著作権は原典を公開しているGamasutraおよび著者に帰属します。下記翻訳は LYE およ

    プロダクションの価値: プロジェクトマネージメントの価値 - LYEのブログ
  • システム開発に欠かせない契約の基礎知識まとめ - GoTheDistance

    先日識者の方に色々教わったのでメモっておきます。知ってそうで知らない、元々よくわからない、そういう方に向けてまとめてみました。 僕がSIにいた頃は大抵「基契約」と「個別覚書」ってのがありました。納期とかお金とかそういうのは個別覚書に書かれたりしていました。 開発の契約体系 「仕様策定〜開発まで」と「保守運用」で別契約にすることが多い。 「仕様策定フェーズ」で1つの契約にして、別に新しく契約を締結しなおせるほうが望ましい。リスクが低減できる。 仕様策定までは準委任、開発は請負、保守運用は準委任という契約が多い。 ちなみに準委任は「事務作業の代行」という意味合い。委任は「法的効力がある作業」の代行。サムライビジネスは後者が多い。 別に運用が事務作業とイコールじゃないけど、成果を問わないタイプの契約の場合は役務提供という位置づけになる。 かといって契約で「僕らのコンサル案を僕らが実施し成果が出

    システム開発に欠かせない契約の基礎知識まとめ - GoTheDistance
    xmx3
    xmx3 2009/06/09
  • どの会社でも通用する仕事術(3)「緩い」マネジメントを防ぐ8の習慣

    前回は,どの会社でも通用する仕事術を構成する7つの力のうち,「教える」をテーマに9の重要項目を説明した。7つの力は以下の通りである。 「教える」力は,どの職場でも必要であり,身につけると非常に有利になる。ぜひ,実際に試していただきたい。 今回は,2つめの「マネジメント」を取り上げる。これも,どの会社でも使える重要な仕事術である。ここでは,マネジメントを「チームでの協業作業や関係者に依頼した作業などの仕事を進めるために行う管理作業」と定義する。例えば,仕事の目標設定,作業の定義と責任分担,進捗確認などが該当する。以下,この前提で説明を進めていく。 仕事がうまく行かない人は「ネガティブ特性」を持つ 筆者は,会社で教育担当を長く務めている。10年前からは教育コンサルタントの仕事もしている。このため,以前から仕事上の悩み相談を受ける機会が多かった。 筆者に相談を持ちかける人のほとんどは,仕事がうま

    どの会社でも通用する仕事術(3)「緩い」マネジメントを防ぐ8の習慣
    xmx3
    xmx3 2009/05/27
    (1)教える (2)マネジメント (3)仕事を頼む (4)交渉する (5)文章を書く (6)褒める (7)叱る
  • 辞めたくなる会社: mediologic.com/weblog

    Disclaimer このブログは高広伯彦の個人的なものです。ここで述べられていることは私の個人的な意見に基づくものであり、私の雇用者には一切の関係はありません。 Powered by Movable Type 3.17-ja 以前にいた会社の、自分がいた組織の離職者率が増えているのを聞いていると、それまで「働きたい会社」だったのが「辞めたくなる会社」になってきているということなのだろう、ということに悲しくなる。 ベンチャー的な気質をもった会社だと、「この会社、このプロダクトを使って何かをしてやろう」というチャレンジャーが集まり、その“志”がエンジンとなって前進していくものだが、あるタイミングからその会社がメジャーになってしまうと「入りたい会社」となってしまい、学歴だけよかったり、対して仕事ができないのに過去の会社での経歴を“華麗に言う”人間が増えてしまう。つまり実力者が入ってこない。ま

    xmx3
    xmx3 2009/04/25
  • 脱Excel! Redmineでアジャイル開発を楽々管理

    ソフトウェア開発のタスクをチケットに登録すると、作業を始めるチケット管理をメインに、進ちょく管理、問題管理などができる。 バグ管理システムだけでなく課題管理システム(ITS:Issue Tracking System)で運用する開発プロセスは、チケット駆動開発(TiDD:Ticket Driven Development)と呼ばれ、最近注目されている。 Ruby1.9の開発はRedmineで管理されているように、近ごろは事例も増えている。 Redmine運用前の問題点 筆者がRedmine運用前に持っていたプロジェクト管理の問題点は下記2点だった。 1.Excelでのタスク管理の限界 従来からプロジェクトマネージャやプロジェクトリーダーの多くは、進ちょく管理やタスク管理Excelで行ってきた。 プロジェクト管理では顧客へ進ちょく報告するために、残工数と残タスク数を計算する必要がある。だが

    脱Excel! Redmineでアジャイル開発を楽々管理
  • ソフトウェアのマニュアル管理に適したツール? — ありえるえりあ

    Recent entries Apache2.4のリリース予定は来年(2011年)初め(あくまで予定) inoue 2010-12-23 Herokuの発音 inoue 2010-12-20 雑誌記事「ソフトウェア・テストPRESS Vol.9」の原稿公開 inoue 2010-12-18 IPA未踏のニュース inoue 2010-12-15 労基法とチキンゲーム inoue 2010-12-06 フロントエンドエンジニア inoue 2010-12-03 ASCII.technologies誌にMapReduceの記事を書きました inoue 2010-11-25 技術評論社パーフェクトシリーズ絶賛発売中 inoue 2010-11-24 雑誌連載「Emacsのトラノマキ」の原稿(part8)公開 inoue 2010-11-22 RESTの当惑 inoue 2010-11-22 「プ

    xmx3
    xmx3 2009/04/20
  • 尊敬され、好かれるリーダーになる方法。 島国大和のド畜生

    チームメンバーが全て優秀であるならば、リーダーはチームのモチベーションに全ての労力を注いで良いとは思う。 プロジェクトが順風満帆ならば、リーダーは誰にも嫌われない振る舞いが出来るかもしれない。 でも。 そうは問屋がおろさない。 人にこちらが望むように仕事をしてもらうのは難しい。 欲しい結果が得られない時、リテイクを出すだけでも、嫌われる時は嫌われる。 妥当な締め切りに遅れる人だっている。彼はノルマが厳しすぎると思うだろう。 彼の失態をカバーする為に投入される人はその采配を嫌うだろう。 そしてプロジェクトが上手く回らなければリーダーに能力がないと思うだろう。 プロジェクト単品を見ても。 誰がやっても失敗するプロジェクトというのは存在する。 そんなのに関わってたらロクな目に合わないが、でも投げ捨てることも叶わない。 そういうのは、とにかくダメージコントロールが必要で、一番痛い失敗をなんとか回避

  • Microsoft Projectの代替ソフトウェアとしてプロジェクト管理が可能でガントチャート表示もできるフリーソフト「OpenProj」

    WindowsMacLinuxのいずれでも動作が可能で、JRE1.5以上がインストールされていれば問題なく利用できるのがこの「OpenProj」。ガントチャート、ネットワークダイアグラム、WBSとRBSチャート、レポートの印刷とPDFによる出力、コスト計算などなど、プロジェクト管理に必要なほとんどの機能が備わっています。 また、Microsoft Projectのファイルを開いたり保存することも可能です。ただのビューワーではなく、実際に編集できるのでかなり便利。メニューなどはほとんど日語化されており、抵抗なく使うことができます。 ダウンロードとインストール、実際の表示などは以下から。 Home | Serena Open Source and Hosted Project Management Software http://openproj.org/ 今回はWindows用を使うの

    Microsoft Projectの代替ソフトウェアとしてプロジェクト管理が可能でガントチャート表示もできるフリーソフト「OpenProj」