最近タスクがどのくらいで終わるか見積もることが多いんだけど、そのたびにうまく見積もりができてなかったり、思ったより長引いてしまってすごく忙しくなってしまったり、といったことが何度かあった。このままじゃ良くないなーと思って、「アジャイルな見積りと計画づくり」を読んだ。 アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~ 作者:Mike Cohn,マイク コーン毎日コミュニケーションズAmazon 実際読んでみると今の状況に非常にぴったりで良い本だった。この本を読んでいくと、最初から正確な見積りをするのは不可能で、作業をしながら見積りの精度をあげるといったり、変更やリスクに強いスケジュールをうまく作るということをしていく必要があるということが分かる。なんとなく自分がタスク管理をしないといけなくなったけど、なんかうまくいかないと思っている人には非常に参考になると思う。あと

【Web制作などの依頼で「概要」しかわからないのに「とりあえず見積が欲しい」と言われたとき、私はこんなことに気をつけています】 どうもです。いきなりですが、私は毎年この年末から来年の3月末あたりまで、段階的に仕事周りが騒がしくなって来る時期だったりします。決算期の都合もあるんでしょうかねぇ。似たような状況の方も多いのではないかと思います。ほんと、最近依頼が多いです。 ところで、仕事の依頼があるって嬉しいことです。 普段あまり交流のなかった方から突然の依頼や、または、人づてで紹介を受けたりなど。紹介を受けるってことは「仕事ちゃんとしてくれるよ」ってのを認めてもらえた証拠だと思っています。本気でうれしいです。 と、ここで「依頼」についてちょっと掘り下げたいな～と思いました。本題に入る前に、少しだけ前置きにお付き合いくださいますと幸いです。 ・・・「依頼」っていろいろありますね。 「ハマる依頼」

ソフトウエアの規模や開発工数、コストなどを算出する「ソフトウエア見積もり」。思えばこの10年、記者はこのソフトウエア見積もりというテーマを追い続けてきた。 その間、さまざまな変化が現場で表れてきたほか、記者の思いも変わってきた。この週末スペシャルでは、そんなソフトウエア見積もりの10年を振り返ってみたい。 勘や経験に頼る見積もりがほとんど まずは現場のITエンジニアに対して、どのように見積もりをしているかを探り続けた。今から8～10年前のことである。当時は勘や経験に頼った見積もりが大半で、それがプロジェクトの失敗につながることが多かった。 ■あなたはどのように「見積もり」をしていますか？ アンケートに寄せられた回答を見ると、やはり大半は勘や経験に頼る見積もりで、6割を超える回答者が見積もりを巡るトラブルを経験していた。以下がその結果報告である。 ■大半は「勘」や「経験」で見積もり---6割

時間ドロボーは、日常生活のいたるところに隠れています。スケジュール通りにテキパキと予定をこなしたいのに、渋滞に巻き込まれて約束の時間に遅れてしまったり、上司から仕事を突然割り当てられて残業を強いられたり。こうした予想外の出来事に出くわすたび、私たちは「時間ドロボーに時間を奪われた」と感じて憤慨しています。 ただ、私たちの時間は本当に盗まれたのでしょうか。実際は何かに仕事の邪魔をされても、物理的に1日の時間が減るわけではありません。誰にとっても、1日は24時間。時間ドロボーの被害に遭ったからといって、1日が23時間になることはないのです。 時間の「量」は変わらないのに、なぜ時間を奪われたという感覚が生まれるのか。原因は、時間の「質」にあります。たとえば机に1時間向かっていても、目の前の仕事に集中できたケースと、雑音などで気が散って集中できなかったケースがあります。どちらも量的には同じ1時間で

完璧にスケジューリングしたつもりなのに、なぜいつも時間が足りなくなるのか。それは時間リスクの見積もりが甘いからです。 仕事の計画を立てるとき、万が一に備えて手は打ってあると胸を張る人は少なくありません。しかし、その多くは危機（ハザード）管理であって、リスク管理でないことに気づいていない。 ハザードとは、災害や事故といった事態のことであり、危機管理ではハザード発生時のリカバリーに主眼が置かれます。一方、リスクはハザードと違い、日常の中で予定どおりに進まない可能性があるものすべてを指します。たとえば「仕事中に突然、顧客が来訪する」というイベントは、けっして災害や事故ではありませんが、日常的で不確実という点では立派なリスクです。時間のリスク管理とは、こうしたイベントを事前に把握してマネジメントすることをいいます。 普通に仕事をしていれば、さまざまな時間リスクに出合います。「いざ外で仕事をしようと

スマホサイト案件の見積もりについて 「Android案件の見積り」や「スマホ案件の見積もりについて」を受けて、アプリではなくHTML+CSSでつくるスマホサイト制作の見積もりではまりやすいポイントをまとめています。 HTML+CSS構築ではPCの0.７倍くらいの単価 スマホサイトはPCより小さいのでHTML+CSSの構築コストも安くみます。ただ、CSS3で作ったほうが良いところで画象の切り出しより手間がかかることもあります。ならすとページ単価はPCの0.７倍くらいの感じじゃないでしょうか？ 検証コストは増大 対応端末が多く検証コストはPCと比較して増大します。iPhone3G、iPhone3GS、iPhone4、iPhone4Sの中から2端末ぐらい(iOS4.x系とiOS5系)。Android2.2、Android2.3から売れてる端末で2端末ぐらい検証するのがよいでしょう。(場合によって

Android案件の見積り ｜ クラスメソッド開発ブログ　を読んで、業界人らしき人のブコメが、「この程度でホッテントリか」という感じで、僕もややそっちよりの意見だったので、ざっくり補足できそうな点について書いて見ました。もう転職して受託の立場ではなくなったので。やや発注側の視点も含まれています。 責任のないリスクについてコスト負担範囲を決める すべてにおいて最重要項目です。変化の激しいスマホ業界においては、互いのリスクテイクについての認識をあわせておく必要があります。例としてはこんなものがあります。 開発期間中に突如OSのメジャーバージョンアップがあった。 顧客「あ、新しいのでましたね。対応できますよね＾＾」 世論に応じて機能の根幹部分が突然リジェクト対象になる。 りんご「今日から電話番号認証禁止ね＾＾直さないと削除しちゃうよ＾＾」 過去を顧みない方針転換がなされる ぐぐる「メニューボタン

原文(投稿日：2011/10/01)へのリンク 最新のアジャイルチームは、時間ベースの見積もりから、ストーリーポイントを使った相対的な見積もりに推移してきているが、我々はこれからも見積もりが必要なのだろうか？ Michael Dubakov氏は、 以下の理由から、なぜ我々がユーザーストーリーの見積もりを辞めるべきなのかを述べている。 見積もりに時間を浪費しないでください なぜ長～くかかったかを上位のマネージャーに説明するべきではありません 守ることが難しい約束をしないでください さらなるプレッシャーを開発チームに与えないでください 本当に重要なことに注力してください Stephen Schwab氏は、見積もりがサイロでの結果とチームベースソリューションを阻害することを心配している。 プロジェクトのコストを決定するために、完全に見積もられたバックログを持つことを期待しているチームである組織を

Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

「ソフトウェア見積り」を読んだ後に「アジャイルな見積りと計画づくり」を読み直したら、とても理解しやすかった。 理解できたことをメモ。 間違っていたら後で直す。 ※追記：一部修正した。 ※追記：Velocityの計算方法を「塹壕よりScrumとXP」から参照するようにした。 【元ネタ】 Twitter / @akipii: 見積について色々考えている。1.0MD(人日)という単位は規模・出来高・工数という複数の意味を持ち混乱しやすいから、ソフトウェア開発の計画づくりに支障をきたしているのではないかという仮説を考えている。その考えを深めるとScrumのストーリーポイントはよく考えられた概念だと思う。 アジャイルサムライで一番難しくて面白い概念～Velocity: プログラマの思索 ソフトウェア開発に特有な技術～ソフトウェア見積り: プログラマの思索 チームは加速するのか～Velocityの使い

「ソフトウェア技術者の最高の能力は、見積もりだ！」――今回から世界のソフトウェア開発プロジェクトで最も頻繁に使われている積み上げ法による見積もりを紹介。まずは、規模見積もりの王様「LOC見積もり」について。 「見積もり」は、ソフトウェア開発における大きなテーマであり、ソフトウェア工学における最重要課題の1つでもあります。 今回お届けしている“見積もり・シリーズ”では、「見積もりの目的（正確に見積もるだけでは不十分）」「見積もりの具体的な方法（精度を上げるため、少なくとも、2つ以上の方法で見積もる必要がある）」「見積もりの応用（見積もり値に合わせる制御と再見積もり）」「見積もりの調整（状況に応じて開発量とスケジュールを再見積もりしなければならない）」について、具体的に解説していきます。 見積もり技法は「類推法」「積み上げ法」「パラメトリックス法」の3つに分類することができます。前回、“勘・経

Dr.ユースケースの “ユースケース人生相談” ファンクションポイントとユースケースには どんな関係があるんですか？：The Rational Edge Dear Dr.ユースケース 先日、ある顧客から「もしユースケースの機能面の複雑性を予測できるなら（例：困難、普通、容易）、そのユースケースが持つファンクションポイントの数を予測する方法はあるか？ 」という質問を受けました。 私はこの質問への回答に多少苦慮しました。私の直感では、ユースケースとファンクションポイントは同じ土俵に乗せて考えるものではありません（少なくとも、これらは「別々の使い方を持っている」のです）。いままでこの問題について考えたことがありますか？ ラショナルソフトウェアにはファンクションポイントとユースケースの使用に関する資料はありますか？ どうか適切なご指導をお願いいたします。 ユースケースで迷える子羊より Dr.ユース

1960 年生まれ，独身フリー・プログラマの生態とは？　日経ソフトウエアの人気連載「フリー・プログラマの華麗な生活」からより抜きの記事をお送りします。2001年上旬の連載開始当初から，現在に至るまでの生活を振り返って，順次公開していく予定です。プログラミングに興味がある人もない人も，フリー・プログラマを目指している人もそうでない人も，“華麗”とはほど遠い，フリー・プログラマの生活をちょっと覗いてみませんか。 ※　記事は執筆時の情報に基づいており，現在では異なる場合があります。 私の知人に，風俗店で働く女性がいる。私は彼女の店に行ったことがないのだが，1時間で5万円からするような店なのだそうである。彼女は酒を飲むたびにこの話をする。「私は時給5万以上だから」と自慢するのである。それを聞いて，そういえば私の単価はどのぐらいだろう，と考えたことがある。 顧客から急ぎの作業依頼が来ることがある。ど

「コードの読まれ方が分かった」、工数見積もり精度向上に寄与：奈良先端科学技術大学院大学 森崎修司氏らが発表 「ソースコードの読まれ方の傾向がまた1つ明らかになった。これで派生開発、保守開発の工数見積もりの精度が向上する」――奈良先端科学技術大学院大学 森崎修司助教らの研究グループは、2009年9月～11月にかけて行ったソースコードリーディングのオンライン・ハンズオン、2010年1月、2月に行ったイベント「ソースコードリーディングワークショップ」、ほか3回におけるハンズオンの分析結果を発表した。 総計126人に、保守／派生開発プロジェクトを模した形式で複数のソースコードを読んでもらい、それぞれにかかった時間を計測、分析したところ、「ソースコードの読解時間はソースコードの行数だけで予測することは難しい」「大規模な変更の場合、コードレビューの経験があるとソースコードの読解時間を短縮できる」ことな