タグ

プロジェクトに関するvivit_jcのブックマーク (27)

  • ニュース|アニメ『ゆるキャン△』ポータルサイト

    2020. 07.20 お知らせ スペシャル TVアニメーション『ゆるキャン△プロジェクトの始まり・プロデュースメモを初公開! 作のプロジェクトはプロデューサーである堀田将市氏の一枚の企画書から立ち上がりました。 作品制作を進めていくにあたって作られたプロデュースメモを初公開いたします。 「ゆるキャン△」が生まれる過程が垣間見えるこちらのメモ。 編と一緒にご覧いただくと、新しい発見があるかもしれません。 ◆堀田将市氏コメント このメモはプリプロダクション…シナリオ開発がある程度進み始めたタイミングで書き、監督はもちろん、宣伝やライセンスに関わってもらうメンバーに展開したものです。プロデュースメモなどと大層な名前をつけていますが、「自分たちがやろうとしていることって、こういうことなんだと思う」というのを純粋に可視化したかったんだと思います。来の意義としては極めて内部資料で、皆様にお見

    ニュース|アニメ『ゆるキャン△』ポータルサイト
  • ゲーム開発における失敗するに決まってるプロジェクト問題 島国大和のド畜生

    俺は開発中プロジェクトの進行具合を見ればその後の成功失敗をわりと当てることができる。(偉そうに出たが、開発者の何割かは息を吸うようにこれをやる) 数日一緒に仕事をすれば確度はもっと高くなる。 美味しんぼにおける、「天ぷらを揚げる前に、上手い天ぷらをあげる職人が分かるか?」という奴だ。これのチーム版。 なぜそれが解る人と解らない人が居るかを説明する。 犬は嗅覚の世界で生きていて、鳥は視覚の世界で生きている。お互いの世界は理解することができない。 ゲームの開発現場には、犬、鳥、トカゲ、深海魚、ナマケモノと各種種族が入り混じっているので、ある属性の人には別の属性の人の重要な事象がまるで見えていない事がある。犬の世界は鳥には分からないのだから。 例えば日人は、昔、青色と緑色は同じと扱っていた。どうでもよかったのだろう。 砂漠の民はラクダを表す言葉が年齢性別によって細かく区別されているという。重要

  • デスマーチが起きる理由 - 3つの指標

    鳥のさえずり声を聞いて、私は悪態を吐いた。今日の早朝に予定されていたミーティングのことをすっかり忘れていたのだ。 まったく、最悪の朝だ。着替えている間に、電話も鳴った。「高い金を払ってコンサルタントを雇った極めて重要なミーティングだ」と念を押されていたというのに。 それもこれも昨日のバグのせいだ。睡眠時間も、開発スキルも、人員も、私の現場には何もかもが足りていない。 それにも関らず、理解の足りない上司は「テスト工程を削ってでも早く納品しろ」とプレッシャーを与えてくる。 あの馬鹿どもめ。一体何を考えているんだ? スーツに着替え終わった私は、冷蔵庫の缶コーヒーで空腹を誤魔化すと、バイクに跨った。通勤時間が5分なのが、せめてもの救いだ。 「遅れてすまない」 そう言って会議室に入ると、奇妙なことに気がついた。教室のように整然と並んでいたはずの机が、即席の半円形に並べ替えられていた。 何より、ホワイ

    デスマーチが起きる理由 - 3つの指標
  • なぜNTT東日本は旭川医科大学に逆転勝訴できたのか。判決文から分かる教訓 | STORIA法律事務所

    ▼ 旭川医科大学による訴訟提起 旭川医科大学は平成23年3月16日に旭川地裁に訴訟を提起しました。 旭川医科大学は、NTT東日に対し、新システム導入失敗に伴う逸失利益として約19億4000万円を請求し、他方、NTT東日は、旭川医科大学に対し、不当な受領拒絶でリース料を受け取れなくなったとして約22億8000万円を請求しました。 ▼ 地裁判決(旭川地判平成28年3月29日) 旭川地裁は、ユーザ・ベンダの過失割合を2:8(ユーザ:ベンダ)としたうえでユーザ・ベンダの両請求とも一部認容し、実質、旭川医科大学からNTT東日へ約1800万円の支払いを命じる判決をしました。 双方ともに控訴をし、舞台は札幌高裁に移りました。 ▼ 高裁判決(札幌高判平成29年8月31日) 札幌高裁は、ユーザ・ベンダの過失割合を10:0(ユーザ:ベンダ)に変更した上で、ベンダの請求を認容、ユーザの請求を棄却し、旭川医

    なぜNTT東日本は旭川医科大学に逆転勝訴できたのか。判決文から分かる教訓 | STORIA法律事務所
  • カンバンの管理に改善を加えたら加速した話 - arihhのブログ

    はじめに これは 【その2】ドリコム Advent Calendar 2015 1日目の記事です 【その1】ドリコム Advent Calendar 2015 - Adventar はこちら 自己紹介 ID: arihhです 主にサーバーサイドのエンジニアをやっており、今は主に雑用をやったりしています 日のお話 今のプロジェクトのカンバンに改善を入れてみたらカンバンの改善が加速した話です 前提 このカンバンの話はいわゆるスマホゲームの運用の話です。 リリース前の開発フェーズや小人数・自動化の運用には向かないかもしれません。 また、写真のカンバンは撮影用に作ったもので実際のカンバンとは異なります 従来のカンバン スペースはストーリー、ToDo、Doing、Doneの4分割です。 ストーリーにはストーリーIDと達成したい目的が書いてあり、朝会で日のタスクをToDo→Doingに移動し、タス

    カンバンの管理に改善を加えたら加速した話 - arihhのブログ
  • 個人アプリ開発中の寂しさをbotで紛らわす - Konifar's WIP

    個人のアプリ開発は楽しいです。けど時々寂しいです。 例えば深夜にアイコン作ってる時とか。 「いつもはデザイナーさんに助けられてるけど自分でやらないとなぁ…」とか考えて、無性に寂しくなったりします。ちょっと前からこの寂しさを何とかしたいなぁと思っていました。 で、今は Slackにhubotを住ませて1人じゃない感を演出することである程度解決しているので、どんな雰囲気で開発しているかまとめておこうと思います。 先に言っておくと、あくまで自分はこうやってるよという話なので 趣味がかなり入っています。以後その点だけ注意をお願いします。 統一された世界観を作る プロジェクトごとにSlackのチャネルを作ってそこに全て集約しています。GitHubのアクティビティ通知、CI結果通知、メール問い合わせ通知などですね。 ここで自分が大事にしてるのは、 統一された世界観を作るというところです。 例えば この

    個人アプリ開発中の寂しさをbotで紛らわす - Konifar's WIP
  • CEDEC2014 「ライブラリを作ってはいけない ~それでも作りたいあなたへのアドバイス~」

    社内ライブラリを8年間に渡って作り、サポートし続けてきた講演者が、1~2年で完成するだろうという当初の想定とは裏腹に、なかなか進まない作業、得られないサポート、バグの押し付け合い、それら数々の修羅場から得られた、技術面およびサポート面でのノウハウをお伝えします。 http://cedec.cesa.or.jp/2014/session/ENG/8073.html ※2014/9/4にCEDEC2014@パシフィコ横浜で行った講演です。Read less

    CEDEC2014 「ライブラリを作ってはいけない ~それでも作りたいあなたへのアドバイス~」
    vivit_jc
    vivit_jc 2015/02/14
    いい話だった(いい話とは言ってない
  • 今まで経験したプロジェクトでありがちな展開と、エンジニアとしてアウトプットしていくパターン - mizchi's blog

    なんか最近、(比較的)アウトプットしてないな、とふと気づいたんだけど、よく考えたらプロジェクトの進捗のフェーズによってアウトプットの分量が偏るのはいつものことだなー、とも思った。 それらのフェーズを前期、中期、後期、運営期で考えみる。 初期段階 おそらくライブラリの選定段階から始まる。この時期のアウトプットは、いわゆる「やってみた系」の記事が増える。ウェブに出る記事だと、これが大多数をしめる。汎用性が高く、技術的に挑戦的なものが多い。(立場的な話をするとQiitaはそういう記事がたくさん共有されると助かる) 選定が終わった段階で、アーキテクト的な役割の人は、たぶんこうあるべきだ、みたいな思想を形成する。それをクラス図やコード規約や役割に応じたドメイン特化基底クラスとして表現したりする。DDD的なアレならこれをユビキタス言語の構築としてプロジェクトを通してやるべきなんだろう。 使う予定のフレ

    今まで経験したプロジェクトでありがちな展開と、エンジニアとしてアウトプットしていくパターン - mizchi's blog
  • エターナらないゲーム開発

    ゲームの仕様書を初めて作成する人のための足掛かりのスライド ゲームの仕様書を書こう1 仕様書作成の分業とリストの作成 https://www.slideshare.net/ChizuruSugimoto/ss-173331109 ゲームの仕様書を書こう2 仕様書に記載する機能内容 https://www.slideshare.net/ChizuruSugimoto/ss-173332578 ゲームの仕様書を書こう3 仕様書に記載するデータと画面 https://www.slideshare.net/ChizuruSugimoto/ss-173333150 ゲームの仕様書を書こう4 仕様書作成で楽をするconfluenceの活用 https://www.slideshare.net/ChizuruSugimoto/confluence-173333413

    エターナらないゲーム開発
  • 世界一わかりやすいプロジェクトマネジメント - 久保清隆のブログ

    世界一わかりやすいプロジェクト・マネジメント 【第2版】 作者: G.マイケルキャンベル,サニーベーカー,中嶋秀隆出版社/メーカー: 総合法令出版発売日: 2010/04/23メディア: 単行(ソフトカバー)購入: 3人 クリック: 45回この商品を含むブログ (4件) を見るプロジェクトマネジメントに興味があったので、を読んでまとめた。 書は、ものすごく分厚く、詳細なところまで書いてあり、とても参考になった。 このブログでは、大枠と重要だと思った点をまとめた。 プロジェクトマネジメントの全体像 プロジェクトマネジメントは、4つのフェーズにわかれる フェーズ1:プロジェクト定義フェーズ フェーズ2:プロジェクト計画フェーズ フェーズ3:プロジェクト実行フェーズ フェーズ4:プロジェクト終結フェーズ フェーズ1:プロジェクト定義フェーズ プロジェクトを立ち上げる プロジェクト・マネジャ

    世界一わかりやすいプロジェクトマネジメント - 久保清隆のブログ
  • プロジェクトは失敗するものである、という英国人の思想 | タイム・コンサルタントの日誌から

    1993年3月、ロンドン証券取引所は、ビッグバンを背景に7年にわたって進めてきた、株式取引決済システム「トーラス」開発プロジェクトの中止を発表した。証券取引所はすでにこの事業に8000万ポンドの費用を投じており、人件費を含むシティ(ロンドン金融街)全体の投下コストは、総額5億ポンドに上っていた。証券取引所のP・ローリンズ理事長は、責任をとって辞任する。 「トーラス」は、株式売買のバックオフィス業務である株式決済処理の電子化・効率化を目的とした、英国金融界の共同事業で、中心的な推進役はロンドン証券取引所であった。トーラスは米国のパッケージソフト「ヴィスタ」をベースに開発されることになっており、来ならば、'91年10月に稼働しているはずだった。それは一度、'92年夏に延期されていた。しかし、中止決定時点では'93年中の稼働すら危ぶまれる状況だった。 ちなみにこのプロジェクトは、ローリンズ理事

    プロジェクトは失敗するものである、という英国人の思想 | タイム・コンサルタントの日誌から
  • 失敗プロジェクトの通夜 - Strategic Choice

    どういうこと?心血を注いだプロジェクトが中断されたときは、「プロジェクトの死」を悼んで、「通夜」を開催します。どうして?仕方のない外的要因のせいであっても、チームにとって、心血を注いできたプロジェクトのキャンセルは、特に士気を下げる原因となります。キャンセルの裏にある事情を、チームが理解しているかどうかは、さほど問題ではありません。とにかく、悲しい気持ちになるのです。無力に感じたり、無気力に陥ったり、時には裏切られたように感じます。チームには、即座に始めなければならない次のプロジェクトがあったとしても、なんらかの休憩は必要です。です。最悪、チームメンバーは辞めてしまうかもしれません。プロジェクトがキャンセルされたのは、自分たちのせいではないにも関わらず、成功したプロジェクトにしか、報酬は与えられません。これは、きわめて強い不公平感を生む可能性があります。どうすれば?失敗したプロジェクトのた

    vivit_jc
    vivit_jc 2014/04/17
    儀式的なものは必要だと思った
  • 技術的負債という(非エンジニアにとっての)隠しパラメータが生産性100倍を起こす - mizchi's blog

    元糞コードマイスターとしては、生産性については思うところある。 技術的到達深度が深い人じゃないとそもそもかけないコードってのももちろん存在して、その前提で10倍とか100倍になりうる話をする。 そもそもマイナスになる人がいるって話。 隠しパラメータをモデル化 エンジニアA:「週に10の成果を出して3の負債を生む人」を考える。この人は開発を止めてリファクタリングをすれば10-3 = 7の技術的負債を返却できるとする。 ここで正確には成果10には* aの係数が掛かっている。これはプロジェクト開始時1.0で、技術的負債が貯まるほど0に近づいて行く 次に、エンジニアB:「週に15の成果を出して10の負債を生む人」を考える(これにも係数aがかかる)。この人は見た目上は上の人の1.5倍速く成果を出しているように観測できるが、負債もたまりやすい。リファクタしても綺麗になりにくい。 これは割とエンジニア

    技術的負債という(非エンジニアにとっての)隠しパラメータが生産性100倍を起こす - mizchi's blog
  • NameBright - Domain Expired

    If this is your domain name you must renew it immediately before it is deleted and permanently removed from your account. To renew this domain name visit NameBright.com

    NameBright - Domain Expired
  • 外注さんに失敗なく仕事をお願いする単純で画期的な方法を考えたった

    株式会社プラムザ 代表取締役社長。システムコンサルタント。1998年に28歳で起業し、現在も現役のシステムエンジニアコンサルトとして、ものづくりの第一線で活躍しつつ、開発現場のチームとそのリーダーのあり方を研究し続けている。 基的にほぼ100%、社内のプログラマだけで開発を行っている弊社ではありますが、時折どうしてもリソース不足を起こすことがあります。 特にここ1年ほどは、消費税増税に伴ってシステムをフルリニューアルしようというようなお話が多く慢性的な製造力不足に悩まされております。 そんな時は外注の開発会社さんにお仕事をお願いするのですが、これがまあなかなか難しく、これまで結構失敗を重ねてきました。 今回、不肖わたくしめが「たぶんこれが正解じゃないか??」という案を考えましたので、ここにご提案します。同業者の方々にとりまして何かヒントになれば幸いにございます。 □外注さんとうまくやる

    外注さんに失敗なく仕事をお願いする単純で画期的な方法を考えたった
  • エンジニアなら知っておきたい障害報告&再発防止策の考え方 - Qiita

    システムには障害がつきものです。どんなにしっかりと作られたサービスであっても思わぬところで、バグやミスが発覚して、トラブルになるものです。大事なのはこういった障害を次への糧にしていくこと。失敗というのは大事な資産なので、管理できるようにしましょうという話。 あわせて読みたい あきらめるにはまだ早い!ソースコードの品質向上に効果的なアプローチ メンタリングの方法について基礎をまとめました。内心でなく行動を変えることが障害報告とも共通します。 新入社員が来てメンターになれって言われたけど、どうすればいいのかという対話テクニック 半年で40kg痩せた!ダイエットでわかるリーンなプロジェクトマネジメント手法 心理的安全性ガイドライン(あるいは権威勾配に関する一考察) 障害の種類と障害報告について 障害には、小さなもの、たとえば画面に表示されているテキストの乱れから、すべての画面で50xエラーが発生

    エンジニアなら知っておきたい障害報告&再発防止策の考え方 - Qiita
  • 臨床改ざん疑惑、厚労省が告発者名を漏洩 研究責任者に:朝日新聞デジタル

    アルツハイマー病の治療法確立を目指す国家プロジェクト「J―ADNI(アドニ)」を巡り、厚生労働省が臨床研究データの改ざんを指摘する実名入りの内部告発メールを無断で告発対象の研究チームの責任者に転送していたことが分かった。内部告発者の人権を著しく損なう行為で、国家公務員法(守秘義務)や内規に触れる可能性もある。 厚労省が国家プロジェクトを守るため疑惑をもみ消そうとしたとの疑念も招いており、厚労省の調査への信頼が揺らぐのは必至だ。 厚労省認知症・虐待防止対策推進室によると、担当専門官に「改ざんが数十例ある」というメールが届いたのは昨年11月18日。J―ADNI事務局側がデータの書き換えを指示した文書と、その通りに書き換えられた検査記録が添付されていた。専門官は翌日、「研究チーム内で対処すること」と判断し、代表研究者の岩坪威東大教授にそのままの文面と添付資料をメールで送ったという。

    臨床改ざん疑惑、厚労省が告発者名を漏洩 研究責任者に:朝日新聞デジタル
    vivit_jc
    vivit_jc 2014/01/18
    あのさあ…
  • 死んでしまったサービスの供養

    この記事は 闇アドベントカレンダー、 22 日目の記事です。何書こうか迷って担当日に書けなかったので三日ほど遅れてしまったけど書きます。 2011 年の 10 月から FANIC という音楽配信サービスの開発に携わっていたのだけど、サービスを成長させることができず、 2013 年の 8 月にサービス終了した。 サービスが死ぬのは技術者がクソだということだけではないと思う。市場とか外部環境に左右されるし、企画とか売り方がダメなことの方が多いと思う。しかし現実に自分はプログラマーとして FANIC というサービスの死に荷担してしまった。弔いになるか分からないけど、 FANIC で何がよくて何が良くなかったのかを書いてみたいと思う。 FANIC とは FANIC は主にアマチュアのミュージシャンをターゲットにしたホームページ作成&音楽販売サービスで、アーティストは自分の公式ホームページを簡単に作

    死んでしまったサービスの供養
  • 発注側から見て、困った開発をどうするか。 島国大和のド畜生

    2023年03月 (1) ・2023年02月 (1) ・2023年01月 (2) ・2022年12月 (1) ・2022年11月 (3) ・2022年10月 (1) ・2022年09月 (1) ・2022年08月 (1) ・2022年07月 (1) ・2022年05月 (2) ・2022年04月 (1) ・2022年03月 (1) ・2022年02月 (1) ・2022年01月 (1) ・2021年10月 (1) ・2021年08月 (1) ・2021年07月 (2) ・2021年05月 (1) ・2021年04月 (1) ・2021年03月 (1) ・2021年02月 (1) ・2021年01月 (1) ・2020年12月 (1) ・2020年11月 (1) ・2020年10月 (1) ・2020年09月 (1) ・2020年08月 (2) ・2020年06月 (2) ・2020年04

  • 人材の流動化か囲い込みか

    最近、日のSI企業と仕事をする機会あった。 久々に衝撃的な体験だった。 とあるシステム案件の下請け的開発依頼だったのだが、 1.アーキテクチャがおかしい ビジネス系の人が直接実装担当のエンジニアに指示を出している。丸投げである。よってアーキテクチャが根的におかしいのだが修正できない。 アーキテクト不在。 2.ドキュメントが無茶苦茶 基なぜかエクセルで書いている。読みにくいことこの上ない。さらにバージョン管理が無茶苦茶である。ほとんど読んでも意味の無い古いドキュメントだらけで解読が非常に難しい。アプリのバージョン、開発環境などもドキュメント毎に違っている。ビルドするとドキュメントが自動生成されるなんてことは一切ない。 ドキュメント担当不在。 3.プロダクトのソース管理が無茶苦茶 ソース管理ソフトはつかっているものの、理解不能なブランチに分かれていて同等製品が複数派生している。修正に手間

    人材の流動化か囲い込みか
    vivit_jc
    vivit_jc 2013/12/17
    プロジェクト運営のアンチパターン