タグ

DevelopmentとManagementに関するyuichiro0526のブックマーク (13)

  • 【島国大和】ゲームはこうしてダメになる。横ヤリ刺さって死屍累々。

    【島国大和】ゲームはこうしてダメになる。横ヤリ刺さって死屍累々。 ライター:島国大和 島国大和 / 不景気の波にもがく,正体はそっとしておいて欲しいゲーム開発者 島国大和のド畜生 出張所ブログ:http://dochikushow.blog3.fc2.com/ どうも,島国大和です。 デスマーチ,してますか? 前回,「ゲームを作る立場で,どうやって落とし穴を回避するかを考えるよ。」と題して,ゲームを開発していくうえでハマりやすい罠を,どうやって回避するのかといったことを書きました。 今回はその続き,というか,そこで書き切れなかったことをまとめてみたいと思います。テーマは,「なぜ横ヤリは入るのか」ということ。 ゲームが大失敗する理由の中で,かなり大きいのが,偉い人からの横ヤリです。完成品を見て「ここちょっと,こうすべきじゃない?」みたいな。 ここではなぜ横ヤリが入るのか,それがどうしてダメー

    【島国大和】ゲームはこうしてダメになる。横ヤリ刺さって死屍累々。
  • DevOpsなんてくそくらえ - razokulover publog

    先日こんなことを言われた。 「テストを書いた成果を見せよ」 と。 ショッキングだった。 経緯 わたしはいまレガシーなコードに囲まれている。 もちろんテストもほとんどないピカピカのレガシーちゃんである。 レガシーちゃんは「Ctrl+F5 & tail -f 駆動開発」により開発が進められており、日々進化している。 このまま進化をつづけるといつかモンスターになり(もう軽く怪獣っぽいが)、開発スピードがどんどん遅くなり、メンテナンスやバグつぶしでエンハンスとなるような開発ができなくなる。このままじゃマズい...。 こういった事態を一新すべく、手探りながら私含め数人の先輩たちで「DevOps」に取りかかることになった。 バズワードにもなっているが「DevOps」とは、 従来型のシステム管理や調達(ITILを含む)といった、保守的でプロセスを中心に据えた運用からよ>り戦略的でアジャイルな、そして自動

    DevOpsなんてくそくらえ - razokulover publog
  • ソーシャルゲーム開発の実体験記 #1 ポチポチゲー開発実体験談 : 驚異の趣味人

    6/21追記 ほ、ホッテントリ入りしてしまった…!? ちょっと補足なども書いてみました→ソーシャルゲーム開発体験談のホッテントリ入りを受けて はじめに ソーシャルゲーム開発会社で仕事していた時のアレコレ話 裏側って程でもないけど、まぁこんな感じだよってな具合で ソーシャルゲーム開発の実体験記 #1 ポチポチゲー開発実体験談 ソーシャルゲーム開発の実体験記 #2 全く売れない こんなオシゴトがあった。 ちょうど1年くらい前だが、ソーシャルゲーム開発現場に業務委託として関わっていたので その時あった事でも書き連ねて見ようと思った。 2年くらい前からソーシャルゲー開発には関わっており、現場もいくつか経験してはいるのだけど 所謂「ポチポチゲー」に初めて関わったのがこの時なので、色々と新しく得るものが多かったかな? 良くも悪くも(苦笑) 開発会社・そのメンバー ちなみにこの時居たのは、業務システムや

    ソーシャルゲーム開発の実体験記 #1 ポチポチゲー開発実体験談 : 驚異の趣味人
  • 開発時間短縮のためのプラクティス10選 - give IT a try

    このエントリを書いた背景 先日会社で「開発時間を短縮するためのアイデアやノウハウをみんなでシェアしよう」という課題が出されました。 「カウボーイコーディングとコピペプログラミングで技術的負債たっぷりのシステムを作りましょう。そうすれば開発時間はぐっと短くなりますよ」なんてことは口が裂けても言えないので、真面目に考えてみました。 色々あるとは思うのですが、その中でも特に重要だったり、言語や技術を問わずに使えそうなものを10個選んでみました。 どれもまあ、基中の基だったり、アジャイル開発だと常識的に行われているようなことばっかりかもしれません。 とはいえ、おいらの会社に限定されるような話は載っていないので、ここにもその時に書いた内容をそのまんま載せておきます。 ただし、あなたの仕事とおいらの仕事は少し違うと思うので、読む前に以下の前提条件を確認しておいてください*1。 このエントリを読む前

    開発時間短縮のためのプラクティス10選 - give IT a try
  • チケット駆動開発で作業管理はしないほうがいい - arclamp

    先日、2013/3/23(土)に弊社でチケット駆動と開発環境に関するイベントを開催しました。リンク先には資料も上がっていますので参照ください(※アトラシアン製品関連のイベントです)。 基調講演にはチケット駆動開発を推進されている関西XPUGのあきぴーさんをお招きして「チケット駆動開発をパターン言語で読み解く」という話をしていただき、最終枠ではパネルディスカッションをしました。 チケット駆動開発とウォーターフォール パネルディスカッションでは、僕が「チケット駆動開発を作業計画に使うのは難しく、WBSとの併用が現実的」と話し、あきぴーさんが「作業計画をチケット駆動開発で回していくには」というノウハウを紹介されていました。 この違いは僕がウォーターフォール的な新規案件を、あきぴーさんがアジャイル的な開発/保守運用案件を前提にしているためです。 僕自身はBTS(Bug Tracking Syste

    チケット駆動開発で作業管理はしないほうがいい - arclamp
  • ダメなシステムが無くならない理由はエンジニアを正しく活用できないから - GoTheDistance

    Twitterで流れてきたのでつい見てしまいましたが、この方の連載は全体的にやっつけ感が否めないですね。 なぜ“ダメなシステム”は無くならないのか? - なぜ“ダメなシステム”は無くならないのか?:ITpro この"ダメだしとっつあん"があの手この手で言わんとしてることは「上流工程と下流工程の分断は悪であり、ダメなシステムはそこから生まれている」ということですので、この記事を読んだ人は連載読まなくて大丈夫です。僕が書いたこのエントリ読んでください。もっと突っ込んで書いてあります。 「SIerでのキャリアパスを考える」というイベントに登壇しました - GoTheDistance もうそろそろぶっちゃけてもいいでしょ。ダメなシステムができる理由は簡単だってことに。ウオーターフォールが逆流できないせいだ/丸投げするからダメ/リスクをとらないからダメ/技術力のないやつが舵を取るからダメ・・・ってさ

    ダメなシステムが無くならない理由はエンジニアを正しく活用できないから - GoTheDistance
  • JS 大規模プロジェクトの管理手法 – ロードオブナイツの実例紹介

    どうもこんにちは。 Aiming で東京開発グループのゼネラルマネージャをやっている小林です。 8月に mobage と Yahoo! モバゲー で ロードオブナイツ というシミュレーション RPG をリリースさせて頂きました。 そして、先週、 Yahoo! モバゲー版の PC ブラウザ専用デザインをリリースさせて頂きました。 今回リリースしたものは元々 Unity で作られていた iOS アプリ版 Lord of Knights を HTML5 で書きなおしたものです。 (今は Android 版 もあります) HTML のポチポチゲーをネイティブに移植したというのはよく聞く話ですね。 ですが、逆にリッチなネイティブアプリを HTML5 に移植し、かつスマフォブラウザと PC ブラウザで同じものを動かすなんてのは前例が見当たりませんでした。 技術的ハードルが高かったことに加えて期日がタイ

    JS 大規模プロジェクトの管理手法 – ロードオブナイツの実例紹介
  • ドラクエXはこうして作られた、大規模ゲーム開発におけるマネージメント方法

    ドラゴンクエストXは「世界は一つ」を実現するためにどのようなサーバ構成にしているのか? ということで、CEDEC 2012ではドラゴンクエストXの世界観を支えるサーバシステムはどのように構成されているのか、ということが講演されましたが、さらにドラゴンクエストという人気作品を制作する上でどのようなマネージメントが行われたのか、ということについても、スクウェア・エニックス開発部所属の荒木竜馬さんが大規模開発ならではの問題やそれを解決するための工夫について語ってくれています。 タイトル | CEDEC 2012 | Computer Entertaintment Developers Conference http://cedec.cesa.or.jp/2012/program/BM/C12_P0003.html 荒木竜馬: 今日はドラゴンクエストの話ということで、朝早くからたくさんの人にお集ま

    ドラクエXはこうして作られた、大規模ゲーム開発におけるマネージメント方法
  • ソフトウェア開発プロジェクトを蝕む10の典型的な過ち

    プロジェクト管理は決して精密な科学ではないが、これにソフトウェア開発が持つ予測が難しいという性質と組み合わせられると、大きな悲劇のレシピが生まれる。わたしは、ソフトウェア開発プロジェクトに取り組んでいるプロジェクトマネージャーがよく犯す過ちを数多く見てきた。それらの過ちの一部はソフトウェア開発に限ったことではないが、この文脈では特に頻繁に起こり、ダメージも大きい。 1.「人数を増やせばよい」という誤解 Fred Brooks氏は同氏の有名な言葉の中で、よくあるプロジェクト管理の間違いについて「ある女性が9カ月に1人子どもを産めるからといって、9人の女性がいれば1カ月に1人の子どもを産めるわけではない」と表現している。そして、この間違いは今でも頻繁に見られる。ある問題に多くの人間を割り当てれば、その問題は早く解決するという考え方だ。残念ながら、これは正しくない。 プロジェクトに人を1人投入す

    ソフトウェア開発プロジェクトを蝕む10の典型的な過ち
  • チーム内でやる進捗会議はムダ - 勘と経験と読経

    ソフトウェア開発プロジェクトでは、顧客への定期的な進捗報告を行うために、当然のことだが進捗を管理しなければいけない。中規模以上のプロジェクトではプロジェクトはいくつかのチームに分かれていて、さらにチームごとに担当する会社が異なることもある。ありがちな事だが、チーム別にプロジェクト内の進捗会議を行うようになってくると、これが壮大なムダになっていく。 チームリーダーはソフトウェア開発プロジェクトのボトルネック ソフトウェア開発プロジェクトは、ウォーターフォール形式であれアジャイル開発プロセス型であれ、膨大なコミュニケーションと意思決定を行うことで進んでいく。ソフトウェアの仕様や構成について決定するのは、たいていはチームリーダーの仕事だ。また、各開発担当者の仕事の結果が正しいのかをレビューやインスペクションによって判定するのもチームリーダーの仕事であることが多い。そして、チームリーダーはチームメ

    チーム内でやる進捗会議はムダ - 勘と経験と読経
  • 数千人が利用する楽天Redmineの過去と未来 #47redmine

    第二回 shinagawa.redmine勉強会で「数千人が利用する楽天Redmineの過去と未来」を発表させていただきました。資料はSlideShare、SpeakerDeckで公開しております。QAの時間が取れなかったため、質問などがあればTwitterでもなんでもご連絡ください。 数千人が利用するRedmine 来月、第3回RxTstudyでもRedmine事例の発表させていただくのですが、品川Redmineはシステム視点、RxTstudyではタスクマネジメント視点で資料を作りました。 はじまりは、使われてないサーバ上に作った仮想VMを使っていました。ユーザ数も少なかったので、WEBRickを利用し、ポートを分けることで複数Redmineを構築していました。WEBRickが固まることがあったので、cronで一日一回夜間に再起動して運用していました。 自分のグループで使ってみようという

    数千人が利用する楽天Redmineの過去と未来 #47redmine
  • 最初から締め切り終盤勢いの開発は可能か? - teruyastarはかく語りき

    ※最後に2つ追記しました。 この話面白い。 11の「やめたこと」で実現した1000万ダウンロード突破【スマホ2011冬】 - デジタル - 日経トレンディネット http://trendy.nikkeibp.co.jp/article/column/20111215/1039018/ スマホゲームアプリの開発を命じられたのは、東日大震災直後の今年3月。 出された課題は 「4月から開発に着手し、7月末までに70タイトルそろえる」 「開発スタッフは既に決まっている人間で進める」 「8月にTVCMなど大々的なPRを行うため遅延は許されない」の3点 『11のやめたこと。』 1.「組織の細分化、階層化をやめる」 マネジャーが増えるということは、ゲームの作り手が一人減るということ。 優秀な人間がマネジャーになるほど、アプリの制作力は低下する。 2.「職種別の目標設定をやめる」 プログラマー、企画など

    最初から締め切り終盤勢いの開発は可能か? - teruyastarはかく語りき
  • 詳説!Redmineを使ったスマートな開発プロセス改善(画面キャプチャ付き)

    最近は、課題管理システム、チケット管理システムがメジャーになっており、私もこの種のツールをサービス開発、ソフトウェア開発で利用し、開発プロセス改善を試みています。 今回は、Shibuya.trac第12回勉強会 ~チケット管理システム大決戦 第二弾~で紹介させていただいた、Redmine利用事例の詳細解説を、共有させていただこうと思います。上記、勉強会の資料は、こちらに公開されています。各種ツールの事例が詰まった内容ですので、ぜひご確認ください。 Redmineプロジェクト画面 上記が自社のRedmineプロジェクト画面です。私のチームは「A-Team」といい、すべての作業は「A-Team」プロジェクトで管理しています。トップページには、勤怠の連絡や、Redmineを利用するときのルールなどがまとめてあり、資料を見ていただければわかると思いますが、プロジェクトメニューにはたくさんのモジ

    詳説!Redmineを使ったスマートな開発プロセス改善(画面キャプチャ付き)
  • 1