スクエニが公開したPM講座。 著者は2011年当時CTOだった橋本善久氏。 氏はこの後、酷い初代FF14の立て直しに貢献し成功に導いている。 10年経っても色褪せておらず、プロジェクト管理に携わる方は必読。 画像は抜粋したも… https://t.co/qGRAg2n5q6
はじめに ソフトウェアプロジェクトには不思議な性質があります。現状のスケジュールに課題を感じて、短くするために人員を投下しても、なかなか思い通りに短くならない。それどころか悪化してしまうことがあります。場合によってはプロジェクト自体が破綻して失敗してしまうことすらあります。 今回は、このようなソフトウェアプロジェクトに潜む直感に反する性質を数理的なモデルを介して理解していく試みです。ある種の思考実験としてお楽しみください。 宣伝 Qiitaさんとコラボ企画でアドベントカレンダーをつくりました。 DXをめちゃくちゃ改善した話を募集しています。 https://qiita.com/advent-calendar/2021/dx-improvement 10人の妊婦がいても1ヶ月で一人の子供は生まれない これは誰かの技術力やプロジェクトマネジメント力に欠陥があるのではなく、「人月の神話」で有名な
ベイジは2010年の創業以来、ウェブ制作事業を中心に事業を展開してきました。この事業では、サービスの質を統一するために2014年頃からワークフローの整備に取り組んできました。 一方ウェブアプリデザイン事業については、事業拡大したのがここ数年で、まだワークフローが整備されておらず、各人の裁量に委ねた進め方になっていました。そこで今後の事業拡大とメンバー増員を想定し作成したのが、業務システムやSaaSのUIデザインに特化した「ベイジの業務システムUIデザインワークフロー」です。 基本的な進め方は国際規格(ISO 9241-210※)の人間中心設計プロセスに基づいて組み立てていますが、細かいタスクの順序や内容は、今までベイジで培ってきたノウハウをふんだんに盛り込み、組み換えています。 そして、様々なプロジェクトでこのワークフローを実用しながら、今もアップデートを続けています。 また今回のワークフ
イーロン・マスクが YouTube チャネルでスペース X のテキサス工場スターベースの中を歩き回りながらロケット製造や電気自動車について説明しているのを観た。ツイートしたこの件。 これがめちゃくちゃに示唆に富んでいて面白かった。この日のイーロン・マスクは饒舌で楽しそうなので、かなり魅入ってしまった。きっと彼はカンファレンスや会議室の中でインタビューを受けるよりも、工場でみんながロケット作ったり作業している場で語った方が情熱を込めていろいろ説明してくれるんだと思う。 この中で製造工程の話があって、これはロケット製造などの特定分野だけでなく、IT やその他の分野にでも当てはまる普遍的な知見だと思ったので意訳してみた。ざっとビデオを観て印象に残った部分だけを意訳した。あくまで大枠で言ってることをまとめただけなので、もし詳細に興味があればぜひビデオを観てイーロン・マスクの話を直接聞いて確認してく
ソフトウェアの開発プロジェクトにはさまざまな経歴や役職を持つ人が関与するので、我が強い人や性格に難がある人が問題になることもしばしば発生します。ソフトウェア業界のよもやま話を語るブロガーのニール・グリーン氏が、ソフトウェア開発プロジェクトの中で問題になりがちな人をタイプごとにまとめつつ、それぞれのタイプの特徴と管理職向けの解決策を解説しました。 How to Deal with Difficult People on Software Projects https://www.howtodeal.dev/ 上記のサイトにアクセスしたのが以下。上から「プロダクトマネージャー」「デザイナー」「プロジェクトマネージャー」「開発マネージャー」「開発者」「品質保証(QA)」の6カテゴリに分かれていて、それぞれの役職の中によくいる「問題のある人」のタイプが動物のアイコンで示されています。例えば、「プロ
これまで僕は締切がかなり厳しいプロジェクトを数回経験してきた。その経験から、締切が厳しいという特性を持ったプロジェクトの初期にまずこれだけはやったほうが良いということがいくつか見つかったので、今回はそれらを紹介していこうと思う。 前提となるプロジェクト 今回紹介する方法は、次のような特性を持ったプロジェクトを前提とする。 細かい仕様は決まっていないが、作るものの要件はある程度明確である アジャイルの定義におけるスコープ・コスト・品質・スケジュールの中で、スケジュールを特に優先したい(スケジュールを変えられないなど) 数ヶ月以上のプロジェクトである 短いスパンでリリースしてユーザーの様子を見てその後のプロダクトバックログの優先度を変えるような性質のプロジェクトでは、別のやり方を取る必要があると思う。そこは注意してほしい。 プロジェクト初期にやっておきたいことは何か 上記のようなプロジェクトの
序章駒場「最近、うちのおかんがシステム開発に興味を持っててなぁ、名前は忘れたらしいんやけど、迅速に開発できて、仕様変更にも対応できる、素晴らしい開発手法を取り入れてるところがあるらしいんやわ〜。」 内海「そんなもんアジャイルに決まってるがなぁ〜! 今やシステム開発と言えば、アジャイル。素早く変化に対応できるってゆーのが特徴なんよ。そもそも名前が “迅速” を意味する英語やねんから、アジャイルに決まってるがなぁ〜。」 チームの人数駒場「最初、オレもそう思たんやけどな、なんでも 40 人ぐらいで開発してるらしいんやわぁ〜。」 内海「ほなぁ、アジャイルちゃうかぁ…。アジャイルでは 5〜9 人ぐらいが推奨されてるからなぁ〜。40 人もおったら、とてもやないけど、コミュニケーションが成立するとは思われへんなぁ〜。効率の悪い伝言ゲームになるのは目に見えてるからなぁ〜。おかん、他にもなんか言うてなかった
はじめに プログラミングの仕事を効率的に行うためには、プログラミングの知識だけでなく、仕事の進め方も大事と思います。 10年近く前、私のプロジェクト(C#での開発業務)は自分も含めて若手が多く、次のような「仕事の進め方」の問題が多々有りました。 1つの不具合の修正に対して、10時間以上かけて実装したが、そもそも修正方針が間違っていたため、最初からやり直しとなった。 レビュー指摘の修正時に、類似の問題が他にないか横展開調査をしないため、何度も差し戻しが発生した。 そこで、当時の私はプロジェクトメンバーの仕事の進め方を改善する方法を考えました。一般的には「問題を見える化」することで問題が改善されると言われています。逆に言うと、問題は見えないままでは改善されません。 つまり、各自の仕事の進め方の良し悪しを見える化が必要でした。従って、仕事の進め方の良し悪しを測るチェックシートを作成し、その評価結
はじめに 株式会社デジサク がお送りするプログラミング記事、 今回は要件定義・システム設計について扱っていこうと思います。 プログラミングを勉強していて、こんな事を感じた経験はないでしょうか。 「勉強してもプロダクトが作れない」 「そもそも開発ってどうやるの?」 「要件定義ってなに?」 その悩みを解決するために、まずは開発の全体感を理解しましょう。 下図『ソフトウェア開発プロセス』をご覧ください いつも勉強しているプログラミングは 『実装』 の部分に該当します。 つまり、プログラミングの実力を発揮する前に4つも壁が存在するのです。 そのため、本記事では実装(プログラミング)を開始する前に必要となる、 『企画~設計』 について順を追って説明して行きます。 特に、エンジニアが理解しておくべき 『要件定義』『設計』 にフォーカスします。 なお、開発全体において実装(プログラミング)に使用する時間
去年に引き続きクリスマスイブになんか作ったシリーズです。 下記のような感じで、ガントチャートを雑に作れるVSCodeの拡張機能を作りました。 テキストを編集してもいいし、プレビューを操作してもいいというのがこのツールの売りです。 変更内容は相互に同期します。 VSCodeなので、当然ながらコピペやマルチカーソル、置換なんかも普通に使えます。 VSCodeの編集機能で、GUI部分の貧弱さを補おうというコンセプトです。 実用性や自由度は低めですが、文法や操作方法を覚える必要も最低限になっているんじゃないかなと思います。 あと、ただのテキストなんで、Git管理もできますね。 2週間程度の短期予定を立てる用途を想定しています(自分はその程度の予定しか立てません)。 要望に答える可能性は低いですが、プルリクを頂ければ割と軽率にマージすると思います。 かんたんな導入方法 まずVSCodeを開き、おもむ
Kimはベストセラー『Designing for the Digital Age』の著者です。かつてはCooperの副社長でしたが、現在では様々な業界のコンサルタントをしています。 UXデザインにおけるインタビューといえばエンドユーザーに近い方へのものを連想しがちですが、本記事のインタビュー対象はユーザーではなく、プロジェクトの進行などのカギを握る「ステークホルダー」、つまり会社の上層部やクライアントなどの立場の方です。 彼らとの内々のコミュニケーションがより良いプロジェクトの意思決定に繋がります。では、実際プロジェクトが始まったときに、ステークホルダーとどのような対話をすればよいのでしょうか? この記事はKim Goodwin氏の『Designing for the Digital Age』の中の「一般的なステークホルダーに対するインタビュー」からの抜粋です。(編集部) ステークホルダー
令和ですね。こんにちは。バックエンドエンジニアのまさくにです。ゴールデンウィークで休んでいたら、シュワシュワと筋組織が融解し、「自然に帰ろう……自然に帰ろう……」と遺伝子に刻み込まれた内なる声が僕を光射す方へ誘いました。もはや社会復帰は難しいかもしれない。 さて。さてさて。 皆さま、いかがお過ごしですか。新しい期に入り、心機一転したい気持ちでしょうか。何ならアレですか。お持ちのWebサイトをリニューアルしたい、そんな気持ちをそろそろお持ちでしょうか。 失礼ながら、そのお気持ち、 たぶん5ヶ月、遅いです! 仕事としてWebサイトの制作に携わってから、5年くらいが過ぎました。現在はバックエンドの作業を行いながら、TD(テクニカルディレクション)やPM(プロジェクトマネージャー)として、プロジェクトに関わることも増えてきています。その観点から言って、お客様と我々の間には「Web制作」の考え方にお
はじめに 有名なプログラマージョーク プログラマの夫に「買い物にいって牛乳を1つ買ってきて。卵があったら6つお願い」と言ったら、夫は牛乳を6パック買ってきた。 プログラマーを笑う自虐ジョークとして使われがちですが、 良い題材なのでこれを元に要望 と 要件定義 と 設計 と 実装 の違いを纏めてみましょう。 下記、それぞれのフェーズの原理原則論を記載します。 各フェーズの原理原則 1. 要望 顧客(妻)の要望 を書き出す:顧客の仕事 買い物に行って牛乳を1つ買ってきて、卵があったら6つお願い。 2. 要件定義1(ダイジェスト) 顧客の要望から曖昧な点を除いて復唱する:PMの仕事 上記だとプログラマーの夫は牛乳を6本買ってきました。夫は妻に、要望をより具体的な形で復唱する必要があります。 ここでは、卵を6つ買ってくるという事を確認することで事故を防ぐことができます。 牛乳を1本買ってくる 卵が
スマホゲーム運営のコンサルティングをやっております、あかおぎ(@akahiro0211)です。 今回はみなさん大好きな「炎上」をテーマにnoteを書いてみようと思います。 といっても「ネット上の炎上」ではなく笑、 「炎上しているプロジェクトに自分がアサインされた時、それをどうやって鎮火させるか」 という、もっと身近なやつです。笑 ネット上で炎上したことはないけど、炎上プロジェクトにアサインされて辛い経験をしたことのある人は、なかなか多いんじゃないでしょうか。 これを書こうと思ったのは、ぼくが今までの経歴上、炎上プロジェクトに途中からアサインされて火消しをするということが多く、 ・炎上しているPJの共通点がだいたい見えてきて ・火消しの際、やることが毎回一緒だと思ったので これを共有したら、日本のどこかで炎上プロジェクトに疲弊している人の助けになるかな、と思ったためです。 ※炎上プロジェクト
VimConf 2018 パンフレット イベントのレポートというのは生ものであり、鮮度がある。 イベントの当日は、疲れ切ってしまっていて、とても帰宅してから文章を書こうという気持ちにはならずすぐに寝てしまう。次の日は仕事がある。そんな風にレポートを書くことをしぶっているうちに、Twitterではいろんな参加レポートが出回る。これ以上俺が書く必要もないんじゃないか・・・という気持ちが大きくなり、「書かない」という決断をするわけでもなく、レポートは永久に書かれない。 イベントの報告をする上で、では自分が書くもの、自分にしか書けないものは何だろうか。それはパーソナルな体験であり、今回のVimConfであれば、やはりスタッフ業に関することを書くべきだろう。 スタッフは何をするのか ノベルティを詰める作業の様子 残っている記録を見ると、VimConfスタッフが最初に打ち合わせを行ったのは2018年5
こんにちは。プロダクトグループのshoito(しょいと)です。 9/26(水)に開催された レガシーコードにドメイン駆動設計で立ち向かった5年間の軌跡 に参加してきたのでレポートします。 当日のtwitterのハッシュタグ#DDDAllianceのツイートがTogetterでまとめられています。 BIGLOBEにおける、5年間のDDDへの取り組みと今後について ビッグローブ株式会社 西 秀和さんより 30年間、事業を支えてきた業務システムをDDDで刷新する。 そのためには、組織的、エンジニアのレベルなど多くの問題があります。 その壁をどう乗り越えたのか? そして、壁の向こうで得た恩恵とは何のか? 5年という期間を経て、得ることのできた気づきや組織的な変化をお伝えしたいです。 アジェンダ DDD導入に至るまで 導入時の苦労 導入による効果 今後の目標 BIGLOBE販売システムについて、DD
Backlog開発チームの藤田です。皆さんは子どもの頃、夏休みの宿題にどんなふうに取り組んでいたでしょうか? 夏休みの初めに一気に終わらせてしまう 毎日こつこつ進める 夏休みの終わり近くになって必死でやる 終わらせない などいろんなタイプがありますね。 私は「初めに一気に終わらせる」タイプでした。毎日こつこつ進めるとかは無理と自分でわかっていたので、先にやってしまって安心したかったのだと思います。「終わらせない」を選択できるほど肝が据わってもいませんでした。 本記事は、普段私たちが業務で使っているプロジェクト管理の手法を夏休みの宿題に応用したお話です。小学2年生になった娘と一緒に「夏休みの宿題完遂」を目的に、バーンダウンチャートなどを活用して、プロジェクトをどのように進めたのかお届けします。 夏休みの宿題をマネジメントする事の発端 うちの子にかぎって 私には小学校6年生と2年生の娘がいます
君は無料の最強プロジェクト管理ツール「ClickUp」を知っているか! 2018年8月30日投稿 2020年11月6日更新 カテゴリ:タスク・スケジュール管理 著者: jMatsuzaki 私の愛しいアップルパイへ 呼びましたか?私を?よろしい、あなたの悩みはよく分かっています。 私のようにフリーランスや自営業をやっており、少人数のチームに複数所属する者にとってプロジェクト管理やチームのタスク管理を行うソフトの選択は悩みの種です。痛みの止まない虫歯くらい悩みの種です。 7年前、私が最初に使っていたのはサイボウズLiveでした。その後より高機能で使い勝手のいいproducteevへと乗り換えました。しかし、なんとも嘆かわしいことに、このどちらのサービスも終了が決まってしまいました。 今日はこれらの代替となり、その上これら2つよりも高機能かつ高性能なサービスとして私があなたに自信を持ってオスス
エンジニアが知っておきたい工数見積もり術! 無理ゲー進行 から脱するために大切なコト エンジニアの仕事に欠かすことのできない、工数見積もり。実際の現場でいくどとなく見積もりを行ってきた筆者が、「健全な進行」にするための工数見積もりのテクニックを伝えます。 アプリエンジニアの池田 惇( @jun_ikd)です。今回は、エンジニアならば避けられない「工数見積もり」について考えてみたいと思います。若手エンジニアでも自分の作業は自分で見積もるようにするべきです。なぜなら、より正確に計画を立てられるようになれば、自分の時間をコントロールして学びや家族・友人との時間を確保できるからです。また、期日内に完了をさせることは周囲の信頼獲得に繋がります。工数の見極めはエンジニアとして、とても重要なスキルなのです。 なお、本稿での「見積もり」とは開発に必要な期間を予測することとし、見積もりが失敗する原因や対策
ゲーム開発 プロジェクトマネジメント講座 2011年10月8日 株式会社スクウェア・エニックス CTO 橋本 善久 1 ©SQUARE-ENIX 2011 SQUARE ENIX OPEN CONFERENCE なぜプロジェクトは 失敗するのか? 2 ©SQUARE-ENIX 2011 プロジェクトの失敗ポイント • 見込みより売上が少ない • 計画よりもコストがかかっている • 発売時期が遅れた • 発売に間に合わせるため内容が削られた • ユーザーの評判が悪い • 不具合が発生 • スタッフの満足度が低い、故障者が出た、辞め てしまった • など・・・ 3 ©SQUARE-ENIX 2011 プロジェクトの失敗ポイントの分類 • スコープ(コンテンツの範囲)の問題 • 品質の問題 • コストの問題 • 時間の問題 • リソース(人員・環境)の問題 • ビジネスの問題 4 ©SQUARE
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く