プランニングポーカー・オブジェクトゲームでアジャイルゲーム！～Agile 2011 Conference
プランニングポーカーでアジャイルな見積もりを！ 今回は、4日目に行われたJames Grenning氏による「Beyond Planning Poker - The Planning Poker Party」の様子を紹介します。アジャイルマニフェスト起草者の一人であるJemes Grenning氏は「プランニングポーカー」という見積もり手法を定義した人物であり、組み込みのC言語におけるアジャイル開発の第一人者としても知られています。セッション概要は次の通り。 世界中の人々がプランニングポーカーから発見を得ているだろう。プランニングポーカーは技術として役立つものだが、ただのゲームではない。ゲームのルールを知っているだけでは、「見積前ストーリーの大群」の前では正しく機能しないことがある。このセッションでは、プランニングポーカーやその原則、別の利用方法などを紹介する。そして、プランニングポーカ
SQUARE ENIX OPEN CONFERENCEゲーム開発プロジェクトマネジメント講座
ゲーム開発 プロジェクトマネジメント講座 ２０１１年１０月８日 株式会社スクウェア・エニックス CTO 橋本 善久 1 ©SQUARE-ENIX 2011 SQUARE ENIX OPEN CONFERENCE なぜプロジェクトは 失敗するのか？ 2 ©SQUARE-ENIX 2011 プロジェクトの失敗ポイント • 見込みより売上が少ない • 計画よりもコストがかかっている • 発売時期が遅れた • 発売に間に合わせるため内容が削られた • ユーザーの評判が悪い • 不具合が発生 • スタッフの満足度が低い、故障者が出た、辞め てしまった • など・・・ 3 ©SQUARE-ENIX 2011 プロジェクトの失敗ポイントの分類 • スコープ（コンテンツの範囲）の問題 • 品質の問題 • コストの問題 • 時間の問題 • リソース（人員・環境）の問題 • ビジネスの問題 4 ©SQUARE
不安とストレスから解放される見積りとスケジュール方法
はじめに 何かはじめてのことをする場合、人はとても「不安」を感じます。人は未来を考えることができる生き物です。その特異な能力ゆえに、未来に起こるかもしれないよくないことを考えると「不安」を感じてしまうのです。 仕事のプロジェクトなどは、「間に合わなかったらどうしよう」とか「この仕事はちゃんと終えられるのだろうか。」など、未来のことを考えてしまうので「不安」に満ちたものになりがちです。 また、不安なものに取り組むというのは大きなエネルギーが必要です。試験勉強をしている時などに、部屋の掃除をしたくなってしまって、気が付いたら時間がなくなっていたという経験を多くの人が体験したことがあるのではないでしょうか。人は、不安なものを直視することを無意識に避けてしまうクセがあるのです。 本稿では、プロジェクトにおける不安とはなんだろうか？を考え、できる限り不安を最小化させるということを主眼に置いたスケジュ
１人月あたり、何ステップ？１画面あたり、何人日でできる？の考え方(2015 Update) - ウィリアムのいたずらの開発日記
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） このブログを4000日以上続けてきて、一番見られているエントリが １人月あたり、何ステップ？１画面あたり、何人日でできる？の考え方 http://blog.goo.ne.jp/xmldtp/e/513c525aa1b41929a7e8c49f66ba35b8 なんだけど、さすがにエントリが古くなってきたので、 書き直してみる。 ■何日で出来る？の変化 昔と違って、何日で出来るというのは、自動生成技術やフレームワークの影響で 変わってきた。昔は、ソースコード量だったが、 ・そもそも、ソースコードが自動生成部分を含むのかどうか分からない ・自動生成で全ていけるのかどうか、わからない ・ソースコード以外の要因が増えてきた ということで、ソースコード量で、実際には決められなくなってきた。
工数と開発期間の関係: ある SE のつぶやき
ソフトウェア開発201の鉄則の原理148「不可能なことはするな」によると、完成したプロジェクトの99%は次の式に従っているとのことです。 この式では、Tが開発期間(要求仕様作成時から製品納入まで)で、PMが所要人月になります。 気をつけなければいけないのは、左辺と右辺をつなぐのは、等号(=)ではなく、不等号(>)だということです。 あくまでも、右辺の計算結果より開発期間(T)は長くなければいけません。 計算式は分かったのですが、３乗根の計算はパソコンではどうやればいいのでしょうか？ 方法が分からなくて少しはまってしまいましたが、Excelで10の３乗根を計算するには次のようにセルに入力します。 =10^(1/3) ちなみに、Googleの検索ボックスに次のように入力して検索しても計算できます。 10^(1/3) Windowsに付属の電卓であれば、関数電卓を表示後、次の順番で入力すればOK
三点見積もり | iseeit.jp 情報通信技術
『情報通信技術』に関するスキルのほかに、『情報セキュリティ』に関するスキルも重点テーマです。また、特に今後の『高速モバイル通信』と『インターネット』に注目していきます。 三点見積もりは、次の３種類の値から算出するものです。 最頻値 実現可能性が最も高いスケジュールアクティビティの所要期間またはコストの見積り値（見込み値）。 楽観値 最良のシナリオで実現されるスケジュールアクティビティの所要期間またはコストの見積り値（見込み値）。 悲観値 最悪のシナリオで実現されるスケジュールアクティビティの所要期間またはコストの見積り値（見込み値）。 三点見積もりについては、PMBOK®第３版では、主に、第６章のプロジェクト・タイム・マネジメントと第１１章のプロジェクト・リスク・マネジメントで取り上げられています。 一般に、次のような計算式が使われます。
エンジニアが知っておきたい工数見積もり術！ " 無理ゲー進行 "から脱するために大切なコト - エンジニアHub｜若手Webエンジニアのキャリアを考える！
エンジニアが知っておきたい工数見積もり術！ 無理ゲー進行 から脱するために大切なコト エンジニアの仕事に欠かすことのできない、工数見積もり。実際の現場でいくどとなく見積もりを行ってきた筆者が、「健全な進行」にするための工数見積もりのテクニックを伝えます。 アプリエンジニアの池田 惇（ @jun_ikd）です。今回は、エンジニアならば避けられない「工数見積もり」について考えてみたいと思います。若手エンジニアでも自分の作業は自分で見積もるようにするべきです。なぜなら、より正確に計画を立てられるようになれば、自分の時間をコントロールして学びや家族・友人との時間を確保できるからです。また、期日内に完了をさせることは周囲の信頼獲得に繋がります。工数の見極めはエンジニアとして、とても重要なスキルなのです。 なお、本稿での「見積もり」とは開発に必要な期間を予測することとし、見積もりが失敗する原因や対策
「総工数(人月)＝0.97×画面数＋0.26×バッチ数」─JUASソフトウェアメトリックス調査から | IT Leaders
IT Leaders トップ ＞ テクノロジー一覧 ＞ システム開発 ＞ 調査・レポート ＞ 「総工数(人月)＝0.97×画面数＋0.26×バッチ数」─JUASソフトウェアメトリックス調査から システム開発 システム開発記事一覧へ [調査・レポート] 「総工数(人月)＝0.97×画面数＋0.26×バッチ数」─JUASソフトウェアメトリックス調査から 数字で見るITガバナンス 2008年12月22日(月)IT Leaders編集部 リスト システム開発プロジェクトが寄せられた時、それがどの程度の工数を必要とするかを見積もることはとても重要だ。開発の「規模感」がイメージできれば、投入すべきリソースも見当がつくし、それはそのままコスト面での計画にも結び付く。 経験則に拠ったり、開発協力ベンダーが提示してきた概算に頼るという方法もあるが、世の中一般の開発プロジェクトから導き出した「指標」を参考にす
最適な工期は「投入人月の立方根の2.4倍」、JUASが調査 ― ＠IT
2007/07/05 日本情報システム・ユーザー協会（JUAS）は7月5日、ユーザー企業102社の357プロジェクトを調査した「ソフトウェアメトリックス調査2007」を発表した。システム開発の企画、開発計画に始まり、保守や運用管理まで実態を調査した内容で、企業情報システムの実態を伝える。調査結果からは“デスマーチ”となるプロジェクトの実態も浮かび上がった。 デスマーチ化するプロジェクトの条件の1つは工期の設定が不適切であることだろう。調査から導き出された標準開発工期は「投入人月の立方根の2.4倍」。調査対象のプロジェクトの全体工数と全体工期をグラフ化し、回帰直線によって求めた。この計算によれば1000人月のプロジェクトの場合は24カ月の工期を設定するのが標準的といえる。事情によってこの標準工期よりも短い工期しか取れない場合は、その短縮率を計算して対策を採るべきとJUASは提言。だが、「（短
フィボナッチ工数見積は「完成させます！（徹夜で）」という無理ゲーによる弊害を最小化するプロジェクトマネージメント手法 - ベルリンのITスタートアップで働くジャバ・ザ・ハットリの日記
今まで数々のプロジェクトマネージャーとそのプロジェクトマネージメント手法に翻弄されてきたが、現在の勤め先であるベルリンのITスタートアップで取り入れている手法が歴代の中でも一番マシ。まず工数見積がとても洗練されている。エンジニアが無理やりに「今週中に完成させます！」と言わされて、結局はその約束が守りきれずに翻弄される、というような弊害が最小化できているな、という話。 プロジェクトマネージメントチームのメンバー達はその見積方法を「フィボナッチ」と表現している。 だいたい工数見積なんてものが正確にできる人に出会ったことが無い。複雑なITプロジェクトの全体像を把握して「これをうちのチームで完了するためには＊＊日を要する」なんてピタッと当てたためしがない。絶対にズレる。 エンジニアに向かって「お前さー『今週中に完成させます』って言ったよな？誰だっけ、それ言ったの？オレじゃねーよ。お前だよ。おめーの
第3回 設計段階で性能を見積もろう
Webアプリケーションの画面を設計するとき、皆さんは性能について意識していますか。機能面の要望を取り込むことに集中するあまり、性能は二の次になっていないでしょうか。 あとになって性能が問題になるプログラムは、設計時に過ちを犯していることが少なくありません。そのような性能トラブルは、チューニングで簡単に解決しないことが多いものです。設計時に性能リスクを明らかにして早めの対策を打っておけば、致命的な性能トラブルの多くを防げます。 今回は設計段階で性能リスクを早期に発見するための性能見積もり手法について紹介します。設計段階で性能を作り込む手法には、多様なものがありますが、今回解説するのはその前段階として必要になるものです。どの機能に対して、工数をかけて性能を作り込むべきかを明らかするのが狙いです。 性能を見積もるメリットは二つ 設計段階では動作するプログラムが存在しないので、性能評価においては、
JUAS、発行後2年が過ぎた調査報告書を無償公開へ
日本情報システム・ユーザー協会（JUAS）は2014年7月29日、「企業IT動向調査」などの調査報告書を無償公開し始めた。同協会の特設サイト「JUASライブラリ」上で提供する。公開するのは発行から2年が経過した調査報告書全文のPDFデータと、関連するプレゼンテーション資料である。 JUASは第一弾として、ユーザー企業のIT投資・活用動向を調査した「企業IT投資動向調査」と、ソフトウエア開発の品質や工期、価格などを調査した「ソフトウェアメトリックス調査」の報告書を提供する。「企業IT動向調査」報告書は2003年版から2012年版までの10年分、「ソフトウェアメトリックス調査」は2007年版から2011年版までの5年分である。 これらの調査報告書を広く公開した理由についてJUASは、「調査報告書には日本におけるIT活用の歴史が詰まっている。今後のIT 活用の方向性を見極めるためにも、発行後一定
調査研究｜JUAS 一般社団法人 日本情報システム・ユーザー協会
JUASライブラリー ：ソフトウェアメトリックス調査 一般社団法人日本情報システム・ユーザー協会では、経済産業省等からの委託事業として様々な調査を実施しております。このたび、発行から一定期間が経った報告書を公開いたしました。幅広い分野の皆様の調査・研究に役立てていただければ幸いです。 ソフトウェアの開発発注作業についての対策にソフトウェアメトリックス（評価基準）調査が有効であるとの観点から、2004年よりユーザー企業から開発・保守・運用プロジェクトの実態を段階的に収集し「ユーザー企業 ソフトウェアメトリックス調査報告書」としてまとめてきました。この調査から得られた様々な知見は、皆様から毎年高い評価をいただいております。自社のＩT活動を見直すために、自社で取り組み可能な指標ひとつからご活用ください。 ■著作権について すべてのコンテンツの著作権および版権等の各種権利は、当協会および関係する
【総まとめ】ソフトウェア技術者の最高の能力は見積もりだ！
【総まとめ】ソフトウェア技術者の最高の能力は見積もりだ！：山浦恒央の“くみこみ”な話（47）（1/2 ページ） 「『見積もり』は、ソフトウェア開発における大きなテーマであり、ソフトウェア工学における最重要課題の1つである」――。見積もり・シリーズついに完結。これまでお届けしてきた重要ポイントをおさらいする！ はじめに 2011年5月から全16回にわたって、ソフトウェア開発におけるスケジュールやコストの“見積もり”について紹介してきました。 これまで何度も繰り返してきた通り、「『見積もり』は、ソフトウェア開発における大きなテーマであり、ソフトウェア工学における最重要課題の1つでもあります」。 この“見積もり・シリーズ”では、「見積もりの目的（正確に見積もるだけでは不十分）」「見積もりの具体的な方法（精度を上げるため、少なくとも、2つ以上の方法で見積もる必要がある）」「見積もりの応用（見積もり
不安とストレスから解放される見積りとスケジュール方法 - Qiita
エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 はじめに 何かはじめてのことをする場合、人はとても「不安」を感じます。人は未来を考えることができる生き物です。その特異な能力ゆえに、未来に起こるかもしれないよくないことを考えると「不安」を感じてしまうのです。 仕事のプロジェクトなどは、「間に合わなかったらどうしよう」とか「この仕事はちゃんと終えられるのだろうか。」など、未来のことを
ソフトウェア見積りを読了
Landscape トップページ | < 前の日 2007-01-15 2007-01-17 次の日 2007-02-27 > Landscape - エンジニアのメモ 2007-01-17 ソフトウェア見積りを読了 当サイト内を Google 検索できます * ソフトウェア見積りを読了この記事の直リンクURL: Permlink | この記事が属するカテゴリ: [本] ソフトウェア見積り―人月の暗黙知を解き明かす スティーブ マコネル / Steve McConnell / 田沢 恵 / 溝口 真理子 / 久手堅 憲之 発売日: 2006/10 amazon で詳しく見る bk1で詳しく見る スティーブ・マコネルの『ソフトウェア見積り』を読了した。 『ソフトウェア見積り』は、ソフトウェア開発における工数や期間を見積もる方法について詳細に解説した本。見積もりについて学んだことのない私に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://www.meti.go.jp/policy/it_policy/softseibi/metrics/process_metrics_appendix.pdf
http://www.meti.go.jp/policy/mono_info_service/joho/softwaremetrics/2010/01.pdf
https://www.meti.go.jp/policy/it_policy/softseibi/metrics/process_metrics.pdf
ソフトウェア開発見積りの 基本的な考え方.pdf