「本当に間に合うの？」の答えが「何もなければ大丈夫」は“圧縮スケジュール” プロジェクトマネジメントアンチパターンの回避策
ソフトウェア開発において「悪い結果に陥りやすい、避けるべき典型例」を指す、「アンチパターン」。 プロジェクトマネジメントの世界にも存在するアンチパターンは、プロジェクトの遅延や成果物の品質低下を招く原因となります。今回のセミナーでは、プロジェクトマネジメントの現場でよく見かける「プロジェクトマネジメントのアンチパターン」と、その回避方法を紹介しました。全4回。1回目は、アンチパターンその1「圧縮スケジュール」について。 よかれと思ってやっていることに苦しめられているケースがある 西郷智史氏：みなさんはじめまして、株式会社ビーイングコンサルティングでコンサルタントをしている西郷と申します。よろしくお願いします。 本編を始める前に、まず弊社の紹介をします。弊社はビーイングコンサルティングといいまして、事業内容は、制約条件の理論に基づいた生産性向上のコンサルティングサービスの提供です。制約条件の
リモートワークで雑談を生み出す仕組み - JMDC TECH BLOG
こんにちは。ユーザープラットフォーム開発本部(UP部)の原です。 あなたのチームの雑談チャンネルは1日あたり何回ぐらい発言がありますか？ 小さい仲良しチームなら頻繁に発言があるかもしれませんが20人,30人あたりになってくるとだんだん発言が少なくなってきますよね。 チームメンバーのエンゲージメントや生産性を高めるためには少なくともお互いがどんな人なのかを知っているようにしておくべきです。 JMDCは数百人いる組織だし、私の所属するUP部だけでも20名以上の社員が所属しており、しかもほぼ全員リモートで仕事をしている状況なので、いかに "チームメンバーがお互いにどんな人なのかを知っている状態" を作り出すかが課題になっています。 GitLabのリモートワークガイド参考にする 自らを “A world leader in remote work” と呼んでいるGitLabも雑談を重要なものと捉え
DX Criteria (v202104)/企業のデジタル化とソフトウェア活用のためのガイドライン
DX Criteria( DX基準 )は、日本CTO協会が監修・編纂している企業のデジタル化とソフトウェア活用のためのガイドラインです。 本基準は、デジタル技術を企業が活用するために必要な要素を多角的かつ具体的に体系化したものです。ソフトウェアエンジニアリング組織の健全な成長・経営目標の可視化・パートナーとのコミュニケーションなどに使っていただくことを目的に作成されています。 また、本基準は絶対ではありません。誰かを攻撃したり、アセスメント結果の数字のみに注目して本質的な改善をおろそかにするためのものではありません。極めて実践的で具体的な項目で構成されているため、定期的に最新動向に併せてCTO協会のWG内で議論をおこないながら、適宜アップデートをしていくものです。
モバイルアプリ開発チームのスクラムってどんな感じ？ - Chatwork Creator's Note
こんにちは！モバイルアプリケーション開発部でスクラムマスターをしている折田 (@orimomo)です。 私たちの部署ではiOSエンジニア・Androidエンジニアが混在する2つのチームを作り、それぞれでスクラムによる開発をおこなっています。 私自身もともとはiOSエンジニアなのですが、現在は専任のスクラムマスターとして両チームに関わらせてもらっています。 最近では各々の継続的な改善が実を結び、スクラムチームとして少しずつ、しかし確実に成長ができているなと感じられるようになりました。 「スクラムが楽しくなってきた！」「いいチームになってきた気がする！」という話をメンバーから聞くことも増え（嬉しい🙌）、ここまで色々あったなぁ…長かったなぁ…と感慨深く思っています。 今回は、そんな私たちが具体的にどのようにスクラムを回しているのか、また以前と比べてどのように変化してきたのかについてご紹介ができ
テスト工程の可視化や自動化に向けた取り組みのご紹介 - Mirrativ Tech Blog
こんにちは、エンジニアの千吉良（ちぎら）@_naru_jpn です。ここ最近 QA に関して考える機会があり、Systematic Software Testing という本を読んでいたところ、色々と刺激を受けるところがありました。計画書の作成やリスク管理などテストの実施以外の領域についても多く書かれていましたが、まずはミラティブの現状に基づいた改善を行うべきだろうと考えました。今回は特にメトリクスの取得などに関して、GAS（Google Apps Script）を活用してミラティブの業務に応用してみたことについてまとめてみました。 以下では細かいことにも触れているので、3行まとめをおいておきます。 手動テストの進捗を見えるようにしたよ GAS（Google Apps Script）で実装したよ ついでに関連業務を自動化したよ ミラティブにおける QA と解決できそうと感じた課題 ミラティ
なぜ、ソフトウェアプロジェクトは人数を増やしても上手くいかないのか - Qiita
はじめに ソフトウェアプロジェクトには不思議な性質があります。現状のスケジュールに課題を感じて、短くするために人員を投下しても、なかなか思い通りに短くならない。それどころか悪化してしまうことがあります。場合によってはプロジェクト自体が破綻して失敗してしまうことすらあります。 今回は、このようなソフトウェアプロジェクトに潜む直感に反する性質を数理的なモデルを介して理解していく試みです。ある種の思考実験としてお楽しみください。 宣伝 Qiitaさんとコラボ企画でアドベントカレンダーをつくりました。 DXをめちゃくちゃ改善した話を募集しています。 https://qiita.com/advent-calendar/2021/dx-improvement 10人の妊婦がいても1ヶ月で一人の子供は生まれない これは誰かの技術力やプロジェクトマネジメント力に欠陥があるのではなく、「人月の神話」で有名な
リモートアジャイル開発のノウハウ集 第2版を公開しました | Agile Studio
Agile Studio プロデューサーの木下です。2020年の3月に公開した『リモートアジャイル開発のノウハウ集（第1版）』に続き、このたび第2版を公開しました。こちらからダウンロードいただけます。...
新参者だけどバーンアウトしかけているチームを立て直す
ジョインしたばかりの組織に違和感を感じたとき、新鮮な目線で改善すると良いよという発表をしました。
［CEDEC 2021］複数名のシナリオライターがどのように共同作業を進めるべきか。アカツキが考える“至高のシナリオチーム”の作り方
［CEDEC 2021］複数名のシナリオライターがどのように共同作業を進めるべきか。アカツキが考える“至高のシナリオチーム”の作り方 ライター：川崎政一郎 ゲーム開発者向けカンファレンス「CEDEC 2021」の3日めとなる2021年8月26日，「至高のシナリオチームの作り方 〜リモートワークでも導入できる『ライターズルーム』とシナリオ横串チームによるマネージメント〜」と題された講演が行われた。 近年のソーシャルゲームやスマートフォン向けゲームでは，ゲーム内シナリオやテキストのボリュームが次第に大きくなっている。実際の開発現場では，複数名のシナリオライターによる共同作業が行われることになるが，さまざまな理由によってメンバー同士のコンフリクト（衝突）が生じやすいそうだ。 今回の講演を行った水野崇志氏は，2017年よりゲーム開発/運営会社のアカツキにてシナリオマネージャーを担当し，上記の改善に
1年以上かけて生産性倍増＋成長し続けるチームになった施策を全部公開 - Qiita
1. はじめに 本稿は、私が1年以上の期間をかけて、成長し続けるチームに変わることができた施策を紹介します。 本稿は長文なので、忙しい人は太字だけを拾い読みして、興味をもった施策だけを詳しく読んでいただければと思います。 なお、本稿の内容で「Developers Summit 2020 KANSAI」というカンファレンスで発表した結果、ベストスピーカー賞1位をいただきました。発表を視聴してくださった方々に感謝しております。 発表資料と発表動画はコチラ 2. 施策の効果 私の開発チームは当初(1年と数ヶ月前)は、以下の状態でした。 あまり積極的に今のやり方を変えようと思っていないチーム メンバーは、中堅(私)が1名と入社2年目と3年目の3人(後に新人が配属して途中から4名に) 全員、技術記事を書いたことがない 全員、社外の勉強会などのイベントに参加したことがない 全員、開発知識は、業務で教え
海外のゲーム会社であった制度 - じじいのプログラミング
今まで、バンクーバー→バルセロナ→シンガポール→香港で働いてきました。それでいろいろな職場を見てきたので、海外のゲーム会社であった制度について、列挙してみました。 日本の会社でも、既に同様の制度をやっていて、珍しくない場合も多くあると思います。 複数の会社のケースを混ぜて書いています。 ゲーム開発技術に関することは、ほとんど書いていません。 ご指摘がありましたら、修正したり詳細を追加しますので、お気軽にどうぞ（内容が後で変わる可能性があります） 人事（採用） 面接 ビザ リファラル採用 リファレンスチェック（照会） カンファレンス時の招待者限定パーティー 人事（評価） 相互評価制度 OKR（Objectives and Key Results） 人事（解雇） 解雇 PIP（Performance Improvement Plan） スタジオ閉鎖 人事（その他） 若手が海外スタジオで1年間働
いまこそ「良い仕様書」がチームの生産性の鍵となる。ので、仕様書に含めたい 14 のポイントについてまとめました。｜Fritz | Lead Product Manager @ Mercari
いまこそ「良い仕様書」がチームの生産性の鍵となる。ので、仕様書に含めたい 14 のポイントについてまとめました。 こんにちは、フリッツ です。今回はプロダクトマネージャーの日課とも言える「仕様書」について。自分にとっては PM 業の施策実行フェーズにおいて最も重要な仕事のひとつであり、最も心躍り、最も興奮する瞬間です。 PM になってかなりの時間が経ちましたが、「仕様書」への力の入れようは減るどころか、「もっと気合を入れなければ。」と感じる一方。在宅勤務が（たぶん） IT 業界のニュースタンダードとなっていくいま、なおさら「仕様書」の重要性を訴えたい今日この頃です。 ということで、今回は ・ 良い仕様書がもたらす 5 つの効果 ・ 仕様書の重要性が増していく 2 つの理由 ・ 仕様書に含めたい 14 の項目・実戦編 ・ 仕様書作成時に心に留めたい 3 つのこと ・ 具体的な仕様書サンプル（
ソースコードブランチ管理のパターン - Martin Fowler's Bliki (ja)
https://martinfowler.com/articles/branching-patterns.html 最新のソース管理システムには、ソースコードのブランチを簡単に作成できる強力なツールが用意されています。しかし、最終的にはこれらのブランチをマージしなければならず、多くのチームは混み合ったブランチに対処するのに膨大な時間を費やしています。複数の開発者の作業をインテグレーションし、本番リリースまでの道筋を整理することに集中して、チームが効果的にブランチを利用できるようにするためのパターンがいくつかあります。全体的なテーマとしては、ブランチを頻繁にインテグレーションし、最小限の労力で本番環境に展開できる健全なメインラインを作ることに注力すべきだということです。 ベースパターン ソースブランチング ✣ メインライン ✣ 健全なブランチ ✣ インテグレーションパターン メインラインイン
Git / GitHub を使用したチーム開発時のガイドラインを制定しました | DevelopersIO
開発時にはみなさん Git や GitHub を使うと思いますが、使い方についてチームメンバー間で微妙に認識の違いがあると進捗を妨げてしまいます。それを防ぐためにガイドラインを定めてみました。 ちなみにこれは CX 事業本部の Tech Lead のお仕事紹介第 1 弾のポストです。 この記事の英語版も書きました。 前提 CX 事業本部ではクライアントからの開発案件や自社サービスの開発をしていますが、その際に有用な（と考えている）ガイドラインです。 様々な事情でチームメンバーが変更になる可能性があり、新規メンバーの立ち上がりを支援する意味合いも込めています。そのため、開発効率をなるべく落とさずに効果的なスキルトランスファーが実施できることを主眼としています。 ガイドライン 定めたガイドラインの全文を貼ります。 3 つのセクションに分かれています。 commit 時のガイドライン avoid
コード書く以外の仕事上暗黙的に必要とされている様々なスキルについてブレストしてみる - stefafafan の fa は3つです
前提 僕は新卒からいまの会社に入って以来ずっとWeb系アプリケーションエンジニアとして仕事してきました 自分がWeb系のエンジニアとして成長するにあたって必要なスキルについて考えたときに、ただコードが書けるだけでは評価されないだろうなということだけ何となくわかっているつもりだけど、言語化しないとどういうスキルがあるのか何が自分に足りないのかがわからない気がするので一旦ブレストしてみる 出来上がったリストを元に次にどこを集中的に伸ばすべきかというのがわかるのではないか ここでいう暗黙的とは、僕が学生の頃「Web系のアプリケーションエンジニアに必要なスキルはこれだろうな」と考えたときにきっと思い浮かばなかったもののことですが、人によってはこんなこと当たり前だろうと思うかもしれません ブレスト結果 いくつかブレストした結果をグループごとにわけてみた。（ブレストといってもただパソコンに向かって箇条
メンバーに恨まれそうな3つのコードレビュー施策を徹底したら、逆にメンバーが爆速で成長した話 - Qiita
ある程度経験を積んだレビュワーがやりがちな失敗は、 指摘しやすいコーディング規約違反だけ指摘している というもの。 コードレビューで指摘するべき欠陥とは、必ずしも規約違反だけではなく、 仕様考慮もれや機能的なバグ、非機能的なセキュリティやパフォーマンス上の問題点も含まれる。 一つ関数に対して複数の視点でソースチェックをしないといけないが、 人間は同時に複数のことは考えられない。 そこでどうすればいいかと情報をあさっていたところ、 われらがIPAがセキュアプログラミング講座というWEBページで、 四回に分けてレビューすることを提唱していた。 １回目はどこに何があるか、 ２回目は可読性が確保されているか、規約にのっとっているか ３回目は機能性 ４回目はセキュリティ といった具合である。 IPAの講座では４回目はセキュリティに限定しているが、 担当していたプロダクトは、非機能面はセキュリティはも
「Client と Server があるスマフォゲームを 開発するときに人類が考えておくべき、ほとんど全てのこと」をまとめる構想
「Client と Server があるスマフォゲームを 開発するときに人類が考えておくべき、ほとんど全てのこと」をまとめる構想 これは何 「Client と Server があるスマフォゲームを開発するときに人類が考えておくべき、ほとんど全てのこと」 をドキュメントとしてまとめようと思ったときに、何を書けばいいかをリストアップする場所 （構想を練る目的なので、不完全な内容です） のんびり更新予定 モチベーション 1. 仕事上の実利 職業柄、生きていくために Client / Server 実装があるスマフォゲーム を一定期間をかけてチームで開発することが多い ゲームのチーム開発は要素が多く、先立って考慮しておくべきことも多岐に渡る 「考慮しておくべきことリスト」 を用意しておくことで、考慮漏れによるミスや手戻りを減らす 初心者にとっては抜けていた知識の補完になり、中級者以上にとっても思考
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
チームの機能不全を起こす4つの “毒”を発生させないための感情の保ち方、心理的安全性を確保したチーム作りのために考えるべきこと【CEDEC2021】 | GameBusiness.jp
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
創業105年の旅館運営企業が実現した 毎週リリースするチームの作り方
