質とスピード / Quality and Speed質とスピード 初演: 2019/10/31 @ EOF2019
いかにしてプロデューサーと手を取り合うのか。PとDの適切な分業関係｜かえるD
プロデューサーの仕事と、どうやって彼らとうまくやっていけばよいのかという質問をもらったので書いてみようと思う。 残念ではあるが、受託開発だと、非常に多いケースではある。 プロデューサーという仕事は何なのだろうか。ゲーム制作側から見るとわかりにくいのでその説明と、制作側から見ての視点を書いてみよう。 その後、どうやって協力していくのか、どうすればプロダクトが売れるのかを理解できるのかを書いていく。 プロデューサーとは何か？アイドルマスターが流行ってから、しきりにプロデューサー（略称P）という立ち位置が、「売れるようにする偉い人」みたいな感じで一般化されるようになった。 ゲームプロデューサーも、売れるようにする偉いひとで大体あってはいる。ここではディレクターとの役割の違いを通じて、プロデューサーの仕事を見てみよう。会社によって微妙に領域が違うが、プロデューサーの仕事の範囲は大まかに以下のとおり
割り勘webサービスを２週間でリリースした手法を紹介する
なぜ週末開発でこの早さを実現できたか 【早さの極意一】 完全分業 開発をしていて、最もスムーズに進むのに役に立ったのが分業でした。 メリット としては、 - それぞれの開発者の得意なことに徹することができる - 作業の重複（コンフリクト）が発生しない デメリット としては、 - 参加していない作業については、担当者に任せきりになり後からメンテができない がありました。今回はリリースまでの速度を重視したため、メリットがデメリットを上回りました。 具体的な作業内容としては、下のイメージのような感じです。 注目すべきは、 両者の作業が疎結合になっていることです。 そして、一番最後の工程の「結合テスト＆リリース」で作業が合流するため、その合流地点に関しては明確に基準を設けました。 今回の場合は、フロントのAPIコールが合流地点になるため、 ソースコードに下記のようなコメントを記載して開発していまし
開発中の機能を小分けにして本番環境にどんどん出すためには - hitode909の日記
ふだんの開発では，稼働中のシステムに影響を与えないように開発中の新機能や新システムを共存させながらちょっとずつデプロイして進めている．どんな事を考えてやっているか記しておきます． フィーチャートグルを使う すべてのコードが本番環境に入っているけど無効化されている状態で開発を進める ブランチをたくさん作るのに対する考え方で，フラグを有効にすると開発中の機能を使える スタッフなら有効にしたり，フィーチャーのオンオフを選べる画面を作ってたこともある フィーチャーブランチを利用した開発はチームを継続的インテグレーションから遠ざける – ゆびてく FeatureToggle 完成したらフィーチャートグルに関係なく全員に有効状態にして完成 フロントエンドの施策で，実際のデータやインフラ構成でどれくらいスピードが出るかわからないときに，ひとまずフラグをオンにすると動く形でデプロイしたりとか レイヤの下の
プログラミング経験がない経営者のためのソフトウェア開発 11の事実 | Social Change!
今やどんなビジネスでもITが関係している。ITを支えているのはソフトウェアだ。あらゆるものがソフトウェアで実現される時代になった。そんな事業や生活に密接に関わるソフトウェアだが、その開発について知られていないことも多い。 とくに経営者がプログラミング経験がないことで、ソフトウェア開発のリーダーシップをとるときに的外れなマネジメントをしてしまうことがある。あまねく経営者がプログラミング経験があれば良いのかもしれないが、それは現実的ではない。 プログラミング経験がなくても、せめてソフトウェア開発の特性について知っておくと良さそうなこともあると思い、なるべく専門用語を使わずに本稿を書いた。 プログラミングは製造ではなく、設計である いまだにソフトウェア開発を、ビルや家屋の建築に喩える人がいるし、工場でモノを製造するようにプログラムが作られると思っている人もいる。 ここが間違いのもとだ。ハードウェ
Android案件を見積もる場合に考えておくことリスト - Qiita
アプリ自体のコーディング見積もりのみに注力してしまうと忘れがちで、たまにつらい目に遭うので、必要に応じて追加していく予定。 アプリ仕様 仕様はそもそも決まっているか 「仕様は決まっている。動かない」「移植なのでこれ以上はありません」と言ったな。 それは嘘だ。 既に仕様がガッチリ確定していることはありえない。要求仕様（必要機能リスト）がある程度固まっているならばまだ良い方で、「今から仕様を一緒に考えていきましょう」「アイディアレベルです」まで様々。 その他にも、GCM/FCM等のアプリ外サービスと連携する場合、遅延コスト等どの程度許容できるかも事前に確定させる。特にプッシュ系サービスでは、ありえないレベル（全端末遅延1秒以内必須、とか）を既定路線に含めないように留意する。 改修か、新規開発か これは見積もりの前提として大きな影響力をもつ。 テクノロジーや設計の自由度・柔軟性をある程度コントロ
「技術的負債だらけのチームで技術マネージメントしてみた」資料が素晴らしい - プログラマの思索
「技術的負債だらけのチームで技術マネージメントしてみた」の公開資料が素晴らしいのでリンクしておく。 【参考】 akipiiさんのツイート: "すごく良い資料。RT @yassan168: #kichijojipm 発表資料upしました。誰かの役にたてば良いのだけど。connpassにもUPしています。＞技術的負債だらけのチームで技術マネージメントしてみた https://t.co/3R25aUnI4S" 前任の仕事を引き継ぎしたら、下記の問題があったらしい。 技術的負債込みで引き継いでしまった、という例は、本当によくある。 (引用開始) １年前の状態 ・すべてがメールベース ・ドキュメントはほぼ無い ・最強の属人化。個人のパワーで乗り切る ・技術に関心が無く誰も行動しない ・暫定スクリプトが今も元気に本番稼働中 ・ソースには、ほぼコメント無し ・hoge.pl.(日付) 形式のソース管理
テストなんか書かなくて良い 僕の考えるサービス開発の肝 - mosa_siru’s blog
世の中は一周まわってエンジニアリングの手法に溢れている。 テストを書け、ドキュメントを書いて冗長化しろ、コミットはわかりやすく、コーディング規約が、安定性が─── でも、それって本質なんだろうか？ 新規サービスを作る際に肝だと思っていることをまとめてみた。 おことわり 以下は少人数で"普通"のアプリやWebサービスを自社で新規開発するときのことを想定しています。大人数で重厚なソシャゲを作るとか、ガチガチの金融系サービスを作るとか、コンシューマーゲーム開発とか、個人で好きなものを作るとか、受託とかは全く想定していません。 基本的に一通り現場をこなした中級以上のエンジニア向けに書いています。 アンチテーゼとして、ややキツめに断定する箇所が多いです、こういう意見もあるんだな程度に受け止めてください。 所属する団体の意見とかは一切関係ありません。 目次 おことわり 目次 ユーザーのことだけ考える
組織にテストを書く文化を根付かせる戦略と戦術
1. The document discusses various social media and video sharing platforms and tools for integrating them, including YouTube, Twitter, Flickr, iTunes, and Facebook. 2. It mentions several services that allow embedding or sharing content between platforms, such as CDTube for YouTube, ZonTube for Amazon, and amz.ly for shortening Amazon URLs for Twitter. 3. Programming languages and APIs mentioned i
プロジェクトが失敗する10の兆候
今年こそは失敗プロジェクトをなくしたいと思っているみなさんこんにちは。ryuzeeです。 先日海外のサイトを見ていたところ、10 Signs When Projects Are Doomed to Failureという面白い記事を見つけたので、10の兆候それぞれをご紹介しつつ私の私見を述べておきたいと思います。 なお、アジャイルなのかウォーターフォールなのかは関係なくあてはまります。 失敗プロジェクトの兆候(1) プロジェクトメンバーが自分たちのタスクをこなすよりもプロジェクトの悪い状況について話し合いをするのに時間を使っている よくあるパターン。 たとえばなかなか仕様が決まらないので見切りで発射してみたら、途中で色々な仕様変更がおこったり考慮漏れが出てきたりして常に対策会議をしなければいけなくなったり、 品質が悪すぎて品質改善のための会議を頻繁におこなうことになったりといった状況。 タス
プロダクトマネージャーとプロジェクトマネージャーはどう違うのか - 小さなごちそう
両方ともPMと略されるため混同する人が多いが、プロダクトマネージャーとプロジェクトマネージャーは明確に役割が異なる。 Quoraに素晴らしく簡潔な回答があったので引用して紹介する。 Product managers own "What" and "Why". Project managers own "How" and "When". (a simplification, but generally holds true) Ian McAllister's answer to What's the difference between a Project Manager and a Product Manager? - Quora プロダクトマネージャーは、「何を作るか」「なぜ作るのか」に責任を持ち、プロジェクトマネージャーは、「いつまでに作るか」「どうやって作るか」に責任を持つ。 別の言
炎上案件に突如ディレクターとして投入されたときにやってみたこと - Qiita
ぼんやり1メンバーとして眺めていたプロジェクトが、リリース1週間前になって「あれも足りない！これも出来てない！どうすんじゃゴラァ」となったときに突如ディレクターとしてぶっこまれ投入されたときにやってみたことのメモ。 一次対応 とにもかくにもPJTに投入されて最初にやったこと。 コミュニケーションルールをみんなで確認して、守ってもらうようにした 誰が何の情報を持ってて、そして誰から誰にどんな指示が出てて、それらがどんなステータスか、、、 もうぐっちゃぐちゃになっていた。 ディレクターは一度死ぬが、一旦全部ディレクターに報告させて、ディレクターから適切な人に指示を出すことにし、メンバー同士でのダイレクトなコミュニケーションをいったん、原則禁止した。 （ディレクターがAさんとBさんで直接やって、と指示を出すときもあるが、それもやりとりの結果をAさんから必ずフィードバックさせるようにした。） ただ
「開発組織のマネジメント」のスライド資料が素晴らしい - プログラマの思索
「開発組織のマネジメント」のスライド資料が素晴らしいのでメモ。 資料の内容を理解したレベルで書く。 【1】問題意識としては、最近15年でWeb開発は従来よりすごく難しくなり、重要度が増している。 付け焼刃で簡単にプロダクトを作れるレベルではなくなった。 その理由はいくつかある。 一つは、開発基盤やシステムがレガシーであるため、ビジネスの変化に追いつけないこと。 2つ目は、企画チーム・開発チーム・運用チームのそれぞれで異なるやり方が根付いており、押し問答の状態になっていること。 サイロ型組織故に、開発組織の行動が局所最適化されてしまい、全体最適になっていない点に問題がある。 本来解決されるべき姿は、レガシー化を防ぐ作業に継続的に取り組むことと、サイロ型組織から自己組織化されたチーム構造へ組織を変化させること。 チームが都合で解散されるようでは、習熟度はいつまで経っても向上しない。 【2】一番
現場のフォーム - steps to phantasien
このごろ仕事の進みが悪く、しかもまったくの自業自得で肩を落としている。 今日はそれをふりかえり明日への糧としたい。反省文。 仕事の進みは「遅い」だけ。動いてはいる。一歩一歩は正しい。 でも一歩を踏み出すまでが遅い。正しい一歩を踏み出せる、正しい姿勢をとるのが遅い。 背中を丸め足を引きずる。たとえばこんなふうに… Bisection ある昼下がりにバグ修正を頼まれた。リグレッション。ここ三ヶ月くらいで壊れたらしい。 リグレッションを直す「正しい」一歩目は、二分探索で原因のリビジョンを探す bisection 作業だ。 でもこのバグ、bisection が面倒そう。なんとなく原因の想像はつくからあたりをつけて直してしまおう・・・ ・・・半日たち、結局あたりはつかない。日が暮れてしょんぼり帰宅。 翌朝気を取り直し bisection をしたら 2 時間でリビジョンの特定がおわる。あらら。 しかも
スライド「 使ってもらえるアプリの考え方」を公開しました | fladdict
SlideShareにスライドを公開しました。「スマホデザイン会議 2012忘年会」でのプレゼンです。 監訳させていただいたTapWorthyの巻末原稿をベースに、より突っ込んだ話を追加しています。 ただし、時間的な問題で扱ってる範囲は、狭く深くしています。 完全版はまたどこか、別の機会に。質問やツッコミは @fladdict まで、よろしくお願いいたします。。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://post.simplie.jp/posts/44
ゲーム開発素人集団がゲーム作り始めて いつのまにか40倍の組織になっていた話
モダンWebシステム開発
DeNA Engineering - DeNAエンジニアのポータルサイト
はてなブログチームの開発フローとGitHub