【読書メモ】システム開発のための見積もりの全てがわかる本

10 見積もりの根幹は「作業量の予測」です
これスクラムでは基準が作業量ですって読んだな

28 （FP法）数えやすい外部接点を通して見積もる方法です
注意すべきは人の動作だけに限定しがちになることです

ドロップダウンの内容をとってくるAPI叩きが100こあります！（固定じゃないから全部考えなきゃ）

42 顧客の希望している納期は~、実際の機能の数や工数とはなんの関係もありません

だそうです

52 じっさいのげんばではExcelが多いので〜

どうしよう、たいふうとかかんけいなく具合悪くなってきた

54 （バッファを盛った）結果、見積もり全体の工数を50%~100%程度押し上げることもままあります
「どんなリスクか」を確認して減らしていきましょう

まぁ実際、頭の中の設計をコードに落とす作業自体はすぐできるのよね（そうなのか？）

70 テストの自動化やプロジェクト管理ツールの影響

でた！！無駄に管理ツールが多いせいで、多重管理になっている上にそれぞれの使い方知らんくて訳わからんなるやつだ！（本質はそことチガウ）

88 （要件一覧の）次はフロー図を作成します

わたしは普段、このへん頭の中でだけやってる訳ですね

90 （アーキテクチャ構成図を作成するさいの）原則は「用件に最適なものを選定」しましょう

Lambdaでよくない？のやつはこのへんなのか

...開発工数にもかかってくるわけだし、ここは順番変えた方がいいのかも要検討

98 新聞を賑わすような訴訟問題になるようケースのおよそ90％がこの（責任分界点の）問題を抱えています

なんかたいへんなはなしになってきた？（実感が湧かないタイプのやつ）

110 1960年代以降、主にIBMや米国の政府機関などがコンピューターソフトウェアの重要性が高まったことで見積もりについての研究を始めています

半世紀以上の歴史があるんだぁ

112 工期の目安は工数の立方根の2.4倍
これの7割を切ると急速に失敗率が上がる

工数合計をS人月とおくと、目安の納期（所要月数）Rはこうらしい
R=2.4\times S^{1/3}

てことは必要な目安人数Pはこうなるわけだね(？)
P=S/(2.4\times S^{1/3})

115 （クライアントサーバー（pcにインストールするソフト）のメリットの文脈）ローカルPCのファイル操作や接続されている機器の制御などを、Webブラウザを通して行うことはあまりにもセキュリティリスクが高い

それはそう（でもWeb NFCとかMidiキーボードとかの制限はもうちと緩和してほしい）

125 ファンクションポイント法では、計測する機能を下表のように定めています

このへん、スクラムではチーム全体でベロシティのポイント決めようってなってるわけで、そこが違いっぽいね（表を使って機械的に計算すると所感が混ざることがなくて...どっちがいいんだろう？わからん）

126 論理の複雑さなどを表現できない（ことがファンクションポイント法のデメリットです）
そうした個別の特性はエンジニアがレビューする中でファンクションポイント法とは別に加味していくしかありません

加味していくしかないんかーい（↑の答えがすぐ下にあったお話）

128 プロジェクトの特性を数値化し評価する

種類と難易度を簡単順に簡単にまとめてみよう

• データ通信（アプリケーション内で完結→組織内の他システムと通信→組織外のシステムと通信）
• 分散処理（ユーザーが1人→複数人だけど同じデータは使わない→複数人で同じデータに触る）
• パフォーマンス（制限なし→自動スケーリングで対応できる→sqlのインデックスとかでオーダーの問題を考える→巨大データすぎてパフォーマンスの達成は困難なシステム）
• 高負荷構成（制限なし→ハードウェアの制限あり（レスポンシブにしたい）→通信環境に制限ありやじ→僻地でのテストが必要）
• トランザクション量（パフォーマンスで考えても良いので割愛）
• オンライン入力（USBメモリとか、バックアップデータの参照といったものが追加であるか？など）
• エンドユーザー効率（要はUXどこまで追求したい？）
• オンライン更新（スタンドアローン→バックアップ復旧には時間をかけられる→ホットデプロイも必要→システムが2重になって冗長性がある→冗長性に加えてデータが同期されている）
• 複雑な処理（難しい処理があるか？）
• 再利用可能性（コンポーネントに分けて開発するかのお話。分けると時間短縮できて嬉しいね）
• インストール容易性（なんかこう、実行環境作るの面倒か？みたいな）
• 運用性（自動化できないことを挙げて以降の巻）
• 複数サイト（ブラウザ違ったらどうなる？みたいな）
• 変更容易性（利用者が色変えたいだったり帳票とか見た目変えたりしたいか？）

...お、多い......

んで、これらの難易度と規模を合わせた数値を機械的に計算して出るのがファンクションポイントってことみたい
いや考えること多いな？

142 （ユースケースポイント法など別のものがあるので、）「時間的に可能なら2つの方法を併用する」

ファンクションポイント法では各工程にバッファを積むので膨らみやすく、難易度ポイントの積み方が難しいので、どうしようかって感じ

つまりわたしがよくやってるベロシティを導入した見積もり法は合理的ってことだな？（随分と都合のいい解釈してるな？おい？）

ここまでがファンクションポイント法。
ここからがユースケースポイント法

154 ユースケース法の難易度はトランザクション数(ユーザーの操作回数)で決まる

ボタン一個づつにユニット作るって思うと結構細かい感じに見積もるみたい

164 コード行数でコストを見積もるのは時代遅れ

コード行数でコストを見積もるのは時代遅れ(なんで2回言ったし)

182 (Web Apiによる対応は)呼び出しはhttpで行いレスポンスはJsonで返すので、MVCに比べて疎結合です

これだぁー、わたしがMVCに妙なコレジャナイ感を感じてた理由

188 (iOSやAndroidといった)対応するOSを選んでも、今度はそれぞれのOSについて、どのバージョンまで対応できるかを決めておく必要があります

あー、Arduinodroidでバージョン高過ぎてもダメって例とかあったなぁ(apkで無理やり入れたけど)

後ろの方はスクラム系のお話なのだけど、RedmineとかBacklogのツールって全員がそのツールを使って何をしたいのかある程度理解しておかないとかなりしんどそうだなぁ(ただの感想)