見積せえへんねやったらどうやって予算取りするねんという話｜牛尾 剛
私は世界規模のクラウドプラットフォームの開発者で、現在はシアトル付近に住んでいる。 先日書いた自分のポストに対する反応で面白い意見があってそれを読んでそらそう思うやろなぁと思った。ただ、私も別に嘘を言っているわけではないですし、これでビジネスも回っている。面白そうなので、その辺も調べてシェアすることにしてみました。 ウォーターフォールからアジャイルって開発側の話はいいのだが、それだと管理とか経営とか非エンジニアの理解を得られないので、納得できるところをちゃんと言語化してほしいんだよな。アジャイルの人の「見積もりがない」って言葉を使われるのが一番苦手、ストーリーポイントの設計は「計画と見積もり… — えふしん (@fshin2000) August 1, 2024 自分のチームの開発プロセス的なものこちらの方に自分のチームが現在やっている開発プロセスは書いてある。アジャイルとか、DevOps
不確実性コーンの話 - プログラマでありたい
アジャイル界隈では割と知られているのですが、見積もりが何故ずれるかという説明の1つに不確実性コーンというものがあります。ざっくり説明するとプロジェクトの初期段階では不確定要素が多いので見積もりには4倍くらいの誤差があり、プロジェクトの進行とともに不確実な部分が少なくなってきて誤差は収束に向かうという話です。 引用：プロジェクトマネジャーのための「プロセス設計術」 - プロジェクトの本質とはなにか：ITpro この不確実性コーンですが、個人的には次のように解釈しています。 プロジェクト開始時には、全ての情報が揃うことはないので見積もりには誤差が生じる 全ての情報を集めてからプロジェクトを始めるのは現実的ではない。 ブレを小さくするには、出来るだけ対象となる範囲を小さくする。（タスクを細かい単位に分解する） 個々の仕事の処理能力が高いのに、何故か仕事が遅い人というのがたまにいます。そんな人を見
見積もりという概念を「見積もり」「コミットメント」「ターゲット」に分ければもっと楽しく開発できる - Link and Motivation Developers' Blog
（※本記事は去年の弊社のQiita アドベントカレンダーに投稿したものをリライトしたものになります。反響が嬉しすぎたので自社ブログにも載せて擦ります。） はじめに リンクアンドモチベーションで、エンジニアをしています、宮田と申します。 自分は外部の技術顧問の方に月に一回のペースで1on1する機会をもらっています。 今回はその中で話したことを共有します。 公開するにあたって分かりやすさを重視して少し脚色していますが、大筋はリアルなものです。 見積もりに対する課題感 ぼく「約束は開発を遅らせるという記事を最近読んだのですが、その通りだと思ったのですよね。」 さて、チームの外に対して約束するために「この機能1ヶ月で出せるよね？」とプロダクトの人やマネージャーに聞かれたら。これは返事に悩む。「ラフで構わないから」って言われて伝えたら、それがコミットメントになってしまったのを過去に何度も見たことがあ
技術顧問との1on1で見積もりには3種類あることを教えてもらった - Qiita
はじめに 本記事はモチベーションクラウドシリーズ Advent Calendar 2022の17日目になります。 自分は外部の技術顧問の方に月に一回のペースで1on1する機会をもらっています。 今回はその中で話したことを共有します。 ※公開するにあたって分かりやすさを重視して脚色しています。 見積もりに対する課題感 ぼく「約束は開発を遅らせるという記事を最近読んだのですが、その通りだと思ったのですよね。」 さて、チームの外に対して約束するために「この機能1ヶ月で出せるよね？」とプロダクトの人やマネージャーに聞かれたら。これは返事に悩む。「ラフで構わないから」って言われて伝えたら、それがコミットメントになってしまったのを過去に何度も見たことがある 約束してはいけないと言いたいわけではない。約束が必要な場合がほとんどだと思う。ただ、その約束は開発を遅くするんだなぁ。だから、約束せずに気楽に開発
見積・提案書に書いておくと不幸を減らせる前提条件
はじめに ちょっとつぶやいたら思いのほか需要がありそうだったので、簡単にまとめておきます。 おことわり これを書いておけば、すべての不幸を避けられるというものではありません 提出先との関係性次第では、書かないほうがいいこともあるかも 私自身が普段提案している内容が、すべて記載されているわけでもありません（うろ覚えで書いてたり、大人の事情） これを流用しておこったすべての事項について、何らかの責任をとることはできません 本稿では請負による開発を想定しています でも共有することで、この業界の不幸が減ればいいなということでつらつら書いてみます。 他にもあるようなら、Twitterなりコメントなりで提案してもらえると嬉しいです。 前提条件を書く目的 見積・提案書通りに、実施するために必要な条件を明確にする 条件を逸脱したときに、どうなるのかハッキリさせる 上記は概ねつぎのとおり 実現が不可能になる
簡単なiOSアプリの開発費相場の意識調査結果 - Qiita
最近Twitter経由で個人での簡単なiOSアプリの受託開発の打診を受け、費用を伝えると連絡が途絶えました。具体的な内容は書けないのですが、以下のような案件です。 実装期間は2日（かなりシンプルな機能でこれ以上はかかりそうにない） 実装可能か要検証な機能有り アイコン画像等のリソースは発注元が作成 App Store申請作業込み（シンプルな為リジェクト対応が必要になる可能性あり） 見積もりとしては合計20万円と出しました。 そこで以下のようにツイートでアンケートをとってみました。 Twitter経由でちょっと検証は必要だけど2日程度でできそうなiOSアプリの開発を打診されて、申請関係も込みで20万円って返したんだけど、音沙汰がなくなった。20万って高いかな？ — りず (r.izumita) (@rizumita) December 25, 2019 選択肢は 高い 安い 丁度良い です。
請求書作成ソフト・見積書発行・クラウド経営ツール - board
見積書や請求書の作成はもちろん、営業管理、支払管理、売上見込の把握、キャッシュフロー予測など、中小企業・小規模事業者の業務や経営を一元管理し、効率化できるサービスです。 一般的な請求書作成サービスと、中堅向け業務システムやERP等との中間に位置するようなシステムで、「請求書作成サービスでは業務管理や経営管理が不十分だが、中堅向け業務システムやERPだと価格帯が高すぎて手が出しにくい」という中小企業や小規模事業者に最適です。
エンジニアが知っておきたい工数見積もり術！ " 無理ゲー進行 "から脱するために大切なコト - エンジニアHub｜若手Webエンジニアのキャリアを考える！
エンジニアが知っておきたい工数見積もり術！ 無理ゲー進行 から脱するために大切なコト エンジニアの仕事に欠かすことのできない、工数見積もり。実際の現場でいくどとなく見積もりを行ってきた筆者が、「健全な進行」にするための工数見積もりのテクニックを伝えます。 アプリエンジニアの池田 惇（ @jun_ikd）です。今回は、エンジニアならば避けられない「工数見積もり」について考えてみたいと思います。若手エンジニアでも自分の作業は自分で見積もるようにするべきです。なぜなら、より正確に計画を立てられるようになれば、自分の時間をコントロールして学びや家族・友人との時間を確保できるからです。また、期日内に完了をさせることは周囲の信頼獲得に繋がります。工数の見極めはエンジニアとして、とても重要なスキルなのです。 なお、本稿での「見積もり」とは開発に必要な期間を予測することとし、見積もりが失敗する原因や対策
フリーランスと時給、あるいは単価の決め方 | たけろぐ
フリーランスはとりあえず時給3,200円「は」欲しい 「合格ライン」の600万までいくのには、時給3,200円ほどになります。 単価を決めるのはなかなか難しいのですが、目安として工数×時給で考えると、わかりやすくなります。年600万の売上が欲しい人が、8時間かかる作業をする場合は、単純計算で3,200×8=25,600円となります。 ただし、ここから諸経費はじめ住民税、事業税、所得税、Adobe税、国民年金、国民健康保険などが引かれますから、当然600万が手取りというわけではありません。 また忘れてはいけないのは、必ずその作業が当初見積もった工数通りに終わるわけではなく、工数が延びたからといって、必ずしも追加料金がもらえるわけでもないということと、また直接売上を生むわけではない事務作業や打ち合わせ移動時間（当然失注した分も）なども、考えなければいけません。もちろん、仕事がまったくない時期だ
【重要】「さぶみっと！サイト制作マッチング」サービス終了のお知らせ | さぶみっと！JAPAN
いつも さぶみっと！JAPAN をご愛顧いただきありがとうございます。 この度、誠に勝手ながら2017年9月29日(金)を持ちまして、「さぶみっと！サイト制作マッチング」のサービスを終了させていただきます。 日頃よりご利用いただいております皆さまにはご迷惑をおかけすることとなり、誠に申し訳ございません。長らくのご愛顧、厚くお礼を申し上げます。 終了するサービス ・サイト名：さぶみっと！サイト制作マッチング ・URL：http://hp.submit.ne.jp/ ・サービス終了日：2017年9月29日(金)11:00 サービスご利用中の方へ ・案件情報のご登録は2017年8月28日(月)より停止しており、新規でご登録をいただくことはできません。 ・現在掲載中の案件に提案を行うことはできますが、サービス終了日を持ちましてサイトをご利用いただくことはできなくなります。 ・現在サイト内で商談中の
工数見積りの海を彷徨う - hidekatsu-izuno 日々の記録
[2018/07/01 追記] 過去に話題になったこともあり、このページに辿り着く方が多いようなのだが、係数導出の手法については継続的に改善を行っている。現時点では、「工数見積りの海を彷徨う・征服」というエントリに記載した「分位点回帰」を使うのがベストではと考えている。50%分位点が中央値にあたるため係数も安定しており、現在の見積りが過去のプロジェクトと比較してどのくらいの工数なのかが明確でわかりやすい。合わせて参考にしていただきたい。 工数見積りが難しいのはわかっているのだが、そうは言っても根拠は欲しい。この業界に入ってからずっと考え続けているのだが、やはり難しい。 この手の工数、工期という話題の時、役に立つのは次の資料だ。 IPA ソフトウェア開発データ白書 JUAS ソフトウェアメトリックス調査 素晴らしいことにどちらも PDF 版は無料で配布されているので、ダウンロードして見ること
開発の見積もりとスケジュール管理 - クックパッド開発者ブログ
こんにちは。会員事業部の丸山です。 エンジニアが開発を開始する時にはタスクの見積もりとスケジュールを作成行って、実装を進めていくと思います。 しかし1ヶ月を超えるような規模の開発をする場合、なかなか予定通りの期日に終わらなかったりすると思います。 そして大抵の場合、増える方向になりますよね。 今回はそういうことにならないために、私が気をつけていること・実践していることをいくつか紹介したいと思います。 見積もりとは まずは「見積もり」とは何なのかを正しく理解したいと思います。 一般的には「見積もり」＝「全タスクとその工数を洗い出す」というものだと思います。 しかしここで以下のことに気をつける必要があります。 見積もりとスケジュールとコミットメントは違う 見積もりとはあるタスクがどれだけの工数(規模)なのかを算出することです。 対して、スケジュールとはあるタスクがどれだけの工期(期間)なのかを
Android案件を見積もる場合に考えておくことリスト - Qiita
アプリ自体のコーディング見積もりのみに注力してしまうと忘れがちで、たまにつらい目に遭うので、必要に応じて追加していく予定。 アプリ仕様 仕様はそもそも決まっているか 「仕様は決まっている。動かない」「移植なのでこれ以上はありません」と言ったな。 それは嘘だ。 既に仕様がガッチリ確定していることはありえない。要求仕様（必要機能リスト）がある程度固まっているならばまだ良い方で、「今から仕様を一緒に考えていきましょう」「アイディアレベルです」まで様々。 その他にも、GCM/FCM等のアプリ外サービスと連携する場合、遅延コスト等どの程度許容できるかも事前に確定させる。特にプッシュ系サービスでは、ありえないレベル（全端末遅延1秒以内必須、とか）を既定路線に含めないように留意する。 改修か、新規開発か これは見積もりの前提として大きな影響力をもつ。 テクノロジーや設計の自由度・柔軟性をある程度コントロ
スマホアプリの受託開発で気をつけておくべき10のこと - Qiita
スマートフォンアプリの受託開発で、特に見積の時点で気をつけておくべき話です。これらがあいまいだと必ず言った言わないのトラブルになりますので、不毛な時間を費やさないためにも事前に見積書や契約書に明記しておきましょう。 1. 対応OSとバージョン まずは当たり前のところから。OS の対応バージョンです。特に iOS だと iOS6 と iOS7 の境目でビューの構成が変わっていて、バージョン一つの違いで結構な手間がかかる場合もあります。最低動作バージョン、推奨バージョンは事前にハッキリと決めておくべきです。 あとそもそもの要件が、iOS と Android のどちらの OS の話なのかハッキリ明記されていない場合は必ず確認しておきましょう。笑い話のようですが、iOS だと思っていた話が Android だったり、Android だけだと思っていたら両方だったり、ということも少なくはありません。
Web制作やシステム開発で1人日あたり作業量（=画面数）と金額単価の相場・見積もり目安。３倍ルールやランニングコストを考えると増大 - モバイル通信とIT技術をコツコツ勉強するブログ
Web制作やシステム開発で，「一人月」や「一人日」あたりの目安・相場平均はどれぐらいなのか？ 金額に換算しつつ，作業量にも換算してみよう。 作業量としては，ステップ数よりもわかりやすい画面数を引き合いに出す。 （１） 個人が受け取る時給は，経費を考えると「３倍で５千円」にする必要がある （２） 企業のランニングコストを求めるには，正味の作業時間を「半分」にする必要がある （３） 金額の相場から仕事量を逆算すると，「一ヶ月の仕事は100万円の価値を生むべき」「10万円の仕事は２〜３日で仕上げるべき」 （４） Web制作だと，「１ページ２〜３万円を半日で仕上げる」のが目安だが，難易度しだいで大幅に変わる （１）個人が受け取る時給は，経費を考えると「３倍で５千円」にする必要がある 経費を含めると，「個人が得たい時給」の３倍を請求する必要がある。 まず，個人が平均で時給1500円もらうとする（※手
初心者エンジニアにおすすめしたい「進捗どうなった？」と言われないための仕事の進め方 - Qiita
はじめに 初心者エンジニアのあなたは、 **先輩エンジニアに「進捗どうなった？」や「なんでこの作業にこんな時間かかってるの？」**といったことを言われたことはありませんか？ また、 作業見積もりやタスク分解をちゃんと行なわないで、いきなりコードを書き始めているということはありませんか？ 勝手にコードを書き始めて、ほとんど手戻りになって1からコードを書き直しになるという経験もあるかと思います。 僕は徹底的に仕事のやり方を叩きこまれましたが、周りの話を聞いていると、こういったことができていない人もいるのかなと思い書こうと思った次第です。 またエンジニア向けには書いていますが、どんな仕事にも普遍的に使える考え方だと思っているので参考になれば幸いです。 アジェンダ 以下のとおりです。どこから読んでもらっても大丈夫ですが、上から読んでいったほうが流れが分かりやすいと思います。 ツールはGithub,
[IPA] デスマらないために「超上流から攻める IT 化の原理原則17ヶ条」が思った以上に使える件 [要件定義] | oshiire*BLOG
「超上流」という言葉自体はとても気に入らないけれども、IPA 独立行政法人 情報処理推進機構 が作って公開している「超上流から攻める IT 化の原理原則17ヶ条」が、当たり前のことを当たり前に並べてあってとても役に立つ。 原理原則 17箇条 ユーザとベンダの想いは相反する 取り決めは合意と承認によって成り立つ プロジェクトの成否を左右する要件確定の先送りは厳禁である ステークホルダ間の合意を得ないまま、次工程に入らない 多段階の見積りは双方のリスクを低減する システム化実現の費用はソフトウェア開発だけではない ライフサイクルコストを重視する システム化方針・狙いの周知徹底が成功の鍵となる 要件定義は発注者の責任である 要件定義書はバイブルであり、事あらばここへ立ち返るもの 優れた要件定義書とはシステム開発を精緻にあらわしたもの 表現されない要件はシステムとして実現されない 数値化されない要
![[IPA] デスマらないために「超上流から攻める IT 化の原理原則17ヶ条」が思った以上に使える件 [要件定義] | oshiire*BLOG](https://cdn-ak-scissors.b.st-hatena.com/image/square/bfb41ba2bfefb166491d5d3e83380136f2017ab2/height=288;version=1;width=512/http%3A%2F%2Foshiire.to%2Fwp-content%2Fuploads%2F2015%2F01%2F17principles-300x212.png)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Android案件見積りに現れる要素、あるいは丁寧に埋設された地雷たち
請求書.jp
プランニング・ポーカー | コン画ソフト