プロジェクトにおける見積もり方法の種類と比較 - Qiita
例えば要件定義の期待値は、上記の計算式に当てはめると (0.5 + 4×1 + 2) / 6 = 1.17時間になります。 類推見積もり 具体例 「Aという機能を持ったシステムを開発するのに、前回は3ヶ月かかった。今回のシステムも機能が似ているので、今回も3ヶ月程度で開発できるだろう。」 特徴 過去の類似プロジェクトのデータに基づいて見積もるため、迅速に概算を出すことができます。 （これ、実はみなさん日常で何気なくやっているのではないでしょうか？？） 注意点 今回のプロジェクトと過去のプロジェクトが完全に同じであるとは限らないため、誤差が生じる可能性があります。 ボトムアップ見積もり 具体例 システム開発プロジェクトの場合 要件定義：1週間 設計：2週間 プログラミング：4週間 テスト：2週間 総合計：9週間 特徴 プロジェクトを細分化して見積もるため、より詳細で正確な見積もりが可能です。
工数管理というものを理解する - Qiita
エンジニアのみなさま、日々の学習本当にお疲れ様です！ また本記事まで足を運んでいただき本当に感謝です。 約3分程度で読めるので最後まで読んでもらえると幸いです。 はじめに 工数管理はプロジェクトの成功に欠かせない要素です。工数を正確に見積もり、管理することで、プロジェクトの遅延を防ぎ、クライアントやプロジェクトメンバーの信頼を得ることができます。 本記事では、工数見積もりの重要性とその手法、そして失敗しないためのポイントについて書きたいと思います。 「もっとこうした方が良いよ！」 や 「うちの会社ではこの様な考えで取り組んでます！」 があればぜひコメント欄で教えていただけますと幸いです。 工数とは？ プロジェクトや業務を完了するために必要な作業時間のことを指します。 「人日」 や 「人月」 と呼ばれており、1人日は8時間、1人月は160時間（1日8時間、平日20日稼働）で表現するケースが多
スケジュールの立て方について - Qiita
はじめに こんにちは！ 先日、社内の個人カリキュラムでWebアプリケーションを一人で作るという課題がありました。 以前、アプリケーションを作る過程で期限を守りながら開発をする上で大切だと個人的に感じたことをこちらの記事で書かせていただきました。 その中で、大切なことの一つに極力精度の高いスケジュールを作るということをあげました。 今回は僕が社内の個人カリキュラム中に実践していたスケジュールを作成・管理する際の方法について紹介したいと思います。 スケジュール作成・管理に悩む方へ少しでも参考になれば嬉しいです。 読み終えるのに10分くらいかかるかと思います。 ご興味がある方は、お暇な時にご覧いただければと。 記事の内容はあくまで個人的見解になります。 記事の流れ なぜスケジュールを作る必要があるのか プロセスを具体化する 見積もり時間を決める 重い順に並び替える スケジュールに落とし込む 進捗
スクラムでストーリーポイントを時間に紐付けて運用すると何が起きるか - Qiita
はじめに みなさんは、スクラムでストーリーポイントを付けるときどのような基準でつけているでしょうか? ストーリーポイントの基準は時間にすべきではないと言われています。 しかしながら、 スクラムを初めて導入して今まで時間対の工数見積もりに慣れていたチームや請負型の社外パートナーが入ったプロジェクトなど、現実的には時間を基準にしてストーリーポイントを運用しているプロジェクトも多いでしょう。 また、ストーリーポイントの見積もりを付け始める際の最初の基準として「4時間 = 1ストーリーポイント として考えよう！」というように知らず知らずのうちにそのような運用になっているケースもあると思います。 私は経験から、ストーリーポイントの基準を時間にするのは、プロジェクト管理に大きい悪影響をもたらすアンチパターンであり、すべきではないと結論づけています。 私が経験してきたプロジェクトで、ストーリーポイントの
見積もりという概念を「見積もり」「コミットメント」「ターゲット」に分ければもっと楽しく開発できる - Link and Motivation Developers' Blog
（※本記事は去年の弊社のQiita アドベントカレンダーに投稿したものをリライトしたものになります。反響が嬉しすぎたので自社ブログにも載せて擦ります。） はじめに リンクアンドモチベーションで、エンジニアをしています、宮田と申します。 自分は外部の技術顧問の方に月に一回のペースで1on1する機会をもらっています。 今回はその中で話したことを共有します。 公開するにあたって分かりやすさを重視して少し脚色していますが、大筋はリアルなものです。 見積もりに対する課題感 ぼく「約束は開発を遅らせるという記事を最近読んだのですが、その通りだと思ったのですよね。」 さて、チームの外に対して約束するために「この機能1ヶ月で出せるよね？」とプロダクトの人やマネージャーに聞かれたら。これは返事に悩む。「ラフで構わないから」って言われて伝えたら、それがコミットメントになってしまったのを過去に何度も見たことがあ
約束は開発を遅らせる - Mitsuyuki.Shiiba
観測しようとすると、その観測が影響を与えてしまう感じで、おもしろい 自分の頭の中 この機能をチームで開発するのに、だいたい2ヶ月くらいかなぁと自分が頭の中で思っているとする。もし僕らの知ってる範囲ですべてが収まれば1ヶ月くらいで終わるかもなぁと思いつつ、まぁ、知らない範囲のことがあるだろうし2ヶ月くらいに思っておくのがいっか という感じ。6割ぐらいの自信 チームの中 チームメイトに「この機能いつ出せるかな？」って聞かれることはあんまりないと思うけど、もし聞かれたら「んー、2ヶ月くらいじゃない？もしかしたら、もうちょっと早くできるかもだけどね」ってそのまま頭の中を伝えると思う 聞かれることがあんまりないというのは、そもそも、チームでラフに見積もるから。Tシャツサイズとかストーリーポイントとかを使って「Mサイズだから2ヶ月くらいだね」って話をするだけで済む。「2ヶ月くらいだね」って言ったものは
開発のスケジュール遅延には抗うことはできないのか？ “最大16倍”の誤差を小さくする見積もりの考え方
DeNAの多様に展開する事業や、それぞれの個性やライフステージに応じたフレキシブルな働き方、それらを受容するDeNAが根底に持つ考え方などを伝えるDeNA TechCon 2022 Autumn。ここでゲーム事業本部の伊藤氏が登壇。プロジェクトのスケジュール遅延に対して、プロジェクトマネージャーができる対策を紹介します。 伊藤氏の自己紹介 伊藤理恵氏（以下、伊藤）：それでは「スケジュール遅延に対して Project Manager ができること」の発表をします。私は伊藤理恵と申します。2011年にDeNAに入社して、ゲーム事業でサーバーサイドのエンジニアをしていました。2017年ごろにプロジェクトマネージャーに転向して以後、新規タイトルや運用タイトルといった複数のゲームタイトルに携わりました。 ゲーム事業ではチームの規模が大きいことも多く、1チームに複数人のPM（プロジェクトマネージャー）
見積・提案書に書いておくと不幸を減らせる前提条件
はじめに ちょっとつぶやいたら思いのほか需要がありそうだったので、簡単にまとめておきます。 おことわり これを書いておけば、すべての不幸を避けられるというものではありません 提出先との関係性次第では、書かないほうがいいこともあるかも 私自身が普段提案している内容が、すべて記載されているわけでもありません（うろ覚えで書いてたり、大人の事情） これを流用しておこったすべての事項について、何らかの責任をとることはできません 本稿では請負による開発を想定しています でも共有することで、この業界の不幸が減ればいいなということでつらつら書いてみます。 他にもあるようなら、Twitterなりコメントなりで提案してもらえると嬉しいです。 前提条件を書く目的 見積・提案書通りに、実施するために必要な条件を明確にする 条件を逸脱したときに、どうなるのかハッキリさせる 上記は概ねつぎのとおり 実現が不可能になる
ガントチャートを捨てろ(3) バーンダウンチャートとバーンアップチャートを併記する
前回(→こちら)はガントチャートを捨てて、代わりに「バーンダウンチャート」を使うことを提案しました。その具体的メリットと、どんなプロジェクトに向いているかもまとめました。 そこで、バーンダウンチャートの弱点としてグラフの傾きが鈍くなった際に「開発が進んでいない」のか、「開発は進んでいるがタスクの総量が増えてタスク残量が減らなくなった」のかの区別がつかないことを挙げ、それは「バーンアップチャート」を併用することにより克服できると書きました。 ではその「バーンアップチャート」とは何なのか、さっそく以下の図をご覧ください。 これが「バーンアップチャート」です。バーンダウンチャートと同じく横軸に時間を取りますが、縦軸はタスクの量として見積時間合計と完了時間合計の2つのグラフを書きます。 上記の例では赤い線が見積時間合計、すなわち期限までにこなすべきタスク全体の合計量を表しています。青い線は完了時間
ソフトウェア開発の見積もり入門
見積もりとは？ Wikipediaによると見積もりとは、以下のようにあります。 見積（みつもり。見積り、見積もりとも書く）とは、金額・量・期間・行動を前もって概算すること。見積もること。あらましの計算をすること。また、その計算。目算。「所要時間を見積る」、「一日の来客者数をざっと見積もった」など、おおよその感覚で数字の見当をつける場合の口語体表現でも使われる。 Wikipedia このように見積もりとは、なにかを行う前に事前にその結果を予想しておくことを言います。 見積もりを使うケースは、ソフトウェア開発に限った話ではありませんが、製造業であるソフトウェア開発においては『見積もり』というタスクは様々なケースで登場します。 見積もりが苦手な人は多い ソフトウェア開発では、「この機能を開発するときにどのくらいで完成できますか？」といったケースが見積もりのシチュエーションとしては多いかと思います
スケジュールにバッファを設けるのは悪か？ - ユニファ開発者ブログ
こんにちは、プロダクトマネージャーの田嶋です。 はじめにお断りしておきますが、本記事は、2021年7月にリリースした開発プロジェクト（以降「Rプロジェクト」）において、遅延なく開発を進められたことのプチ自慢です🎉 笑 週次で滞りなくバーンダウンが落ちていく様子を、チームで安心して見ることができました。スケジュールのストレスなく開発を進めることができたのは、チームの頑張りのほか、見積もりとスケジュール管理が良かったからだとも思っています！ 開発プロジェクトにスケジュールが求められる理由は様々ですが、キャンペーン施策や営業資料の準備計画を立てるため、あるいは利用顧客へも告知責任があるから、などです。そのいずれの場合も、計画やそのための作業見積もりは欠かせません。 しかし多くの開発プロジェクトにおいて、実績は見積もりよりも上振れし、遅延してしまうことが多いのではないでしょうか。 本記事では、R
どれだけかかるの？ WordPressでウェブサイト制作、お見積の実際
2018年6月2日、WordCamp Osaka 2018にて。架空のWordPressサイト制作案件の詳細な見積とともに、日頃、私が何を考えて見積を組み立てているのかをご紹介しました。
エンジニアが知っておきたい工数見積もり術！ " 無理ゲー進行 "から脱するために大切なコト - エンジニアHub｜若手Webエンジニアのキャリアを考える！
エンジニアが知っておきたい工数見積もり術！ 無理ゲー進行 から脱するために大切なコト エンジニアの仕事に欠かすことのできない、工数見積もり。実際の現場でいくどとなく見積もりを行ってきた筆者が、「健全な進行」にするための工数見積もりのテクニックを伝えます。 アプリエンジニアの池田 惇（ @jun_ikd）です。今回は、エンジニアならば避けられない「工数見積もり」について考えてみたいと思います。若手エンジニアでも自分の作業は自分で見積もるようにするべきです。なぜなら、より正確に計画を立てられるようになれば、自分の時間をコントロールして学びや家族・友人との時間を確保できるからです。また、期日内に完了をさせることは周囲の信頼獲得に繋がります。工数の見極めはエンジニアとして、とても重要なスキルなのです。 なお、本稿での「見積もり」とは開発に必要な期間を予測することとし、見積もりが失敗する原因や対策
「遅れ」なんてない - 日々常々
「頑張って遅れを取り戻す」 綺麗な言葉ですが、私は嫌いです。その中でも次の言葉が特に嫌いです。 頑張る 遅れ 取り戻す 全部。これらが嫌いな理由をそれぞれ説明していきます。順番は「頑張る」→「取り戻す」→「遅れ」です。 なお、「頑張って遅れを取り戻す」に期待される結果は「他に一切の影響を与えず、遅れだけが綺麗になくなる」だと思われます。 頑張る 「頑張ってなかったん？」と言うと「頑張っていましたが、もっと頑張ります。」みたいなのが返ってきます。でもこれって多分「頑張る」と言われることが求められているからそう返してるだけで、もともと手なんて抜いていない。仮に手を抜いていたとしたら「頑張る」は「手を抜いていました」の宣言になるので、それを許容してる状態が問題になるんじゃないかな。 とか言葉遊びは置いておいて、現実の話をします。こういう文脈での「頑張る」は「長時間連続労働」に他なりません。そこで
サブスクリプションモデルでの会員の平均継続期間をどう見積もるか？ - Qiita
サブスクリプションモデルのビジネスをやっている時に気になるのが平均継続期間だと思います。平均で3ヶ月継続しているのか、平均で10ヶ月継続しているのかでサービスの粘着性の指標になるし、広告予算にいくら使っていいかも変わってくる。じゃあ具体的にどう平均継続期間を見積もるかというところで過去のデータを全てとってきて平均するのは大変だし、過去の情報だけからは将来のことがわからないし、数理的に簡単に計算できないかその辺考えてみました。 結論 簡単に結論から先にいうと、1ヶ月サブスクリプションモデルの平均継続期間(月)は以下で定義できる。
工数見積もりのコツ - Qiita
はじめに 本稿では、仕事をする上での作業工数の見積もり方法について説明します。 工数とは何か 工数(こうすう1)というのは、仕事において、あるひとつの作業を完了するまでにかかる総累計時間のことです。情報処理技術者試験に出てくるTAT(ターンアラウンドタイム)とは意味合いが異なります2。 例えば、ある作業に40時間(40H3)かかるとした場合、工数は40時間であるといえます。1日8時間勤務だとした場合、40時間は5人日(にんにち)と表現することができます。さらに、1ヶ月20日勤務だとした場合、0.25人月(にんげつ)と表現することもできます。 一般的に工数の単位は「人日」および「人月」で扱います。 学生時代は工数を気にすることはないですが、ITエンジニアとして会社で働くようになると、かならず工数を意識する必要があります。 なぜ工数を意識する必要があるのか なぜ工数を意識する必要があるのかとい
不安とストレスから解放される見積りとスケジュール方法 - Qiita
エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 はじめに 何かはじめてのことをする場合、人はとても「不安」を感じます。人は未来を考えることができる生き物です。その特異な能力ゆえに、未来に起こるかもしれないよくないことを考えると「不安」を感じてしまうのです。 仕事のプロジェクトなどは、「間に合わなかったらどうしよう」とか「この仕事はちゃんと終えられるのだろうか。」など、未来のことを
ソフトウェアの納期見積もりは、星占いレベルのものであると思う - メソッド屋のブログ
このエントリでは、ソフトウェアの見積もりがどういうものであるかをシェアした上で、今後日本はどのような方向に向かえばよいのでは？という私のアイデアをシェアしたいと思う。 注：このエントリは、某銀行の件とは全く関係ありません。考えるきっかけになっていますが、中の人がどんな状況だったかもわからないのに、勝手なことを想像して、人や企業を叩くのは私の趣味ではないからです。 ソフトウェアの見積もりの正確さ ソフトウェア見積もりのことを知りたければ、下記の本がお勧めだ。 books.rakuten.co.jp この本に「不確実性のコーン」という開発フェーズごとの見積もりの正確性に関する図がある。これを見ると、最初の企画の段階で実施した見積もりは、誤差が何と16倍もあり、概算見積もりのレベルでも4倍の開きがある。画面帳票仕様を「確定」したレベルでやっと1.6倍程度の開きになる。 請負開発を実施するときに、
Scrumはじめるまえの本質的な部分の話 #agile #scrum - @i2key のBlog
チームをスクラムにしたいのですが とあるアプリの責任者に相談を受けた。 彼は自分のチームが改善フェーズにはいり一定のリズムでサービス改善したいためWF型からスクラム化したいらしい。 そこで、いきなり彼は「プランニングポーカーどうやるんですか」と聞いてきた。これは危ないと思った。 PO、SM、エンジニアの相互の信頼が一番大事。 信頼がポイント。それがない状態で始まると意味のない何かになりやすい。 最初にやるべき儀式は、プラクティスの勉強ではなく、 最終責任を取れるビジネス側ポジションの人が、「お互い80%くらいの確度でコミュニケーションしましょう」ということ。 お互いのガードを下げること。一蓮托生になること。 そして、「これの意味は、仮にPOが確度100%の画面ワイヤー等のドキュメントをエンジニアに渡せるのであればエンジニアも確度100%の見積もりを出せるけど、僕（PO）はそんな天才でもない
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ソフトウェア開発の見積もりにおける問題点は何ですか？
