本日は2月29日です。つまり2月最終日です。早いな？？？？？
そこのお前、経費精算はさっさとやれ。今すぐやれ。
2月とかいうバランスの悪い月
いや、まじでバランスが悪い。短い。なんでお前だけこんな短いの。歴史的経緯は知ってるけども。だいたいローマが悪い。
どうして2月だけ28日しかなくて、日数が変わるの？ | 国立天文台(NAOJ)
しかも2月は祝日が2回もあって、ただでさえ少ない営業日が大変なことに。陛下なんで2月誕生日なの。今年はうるう年だから例年より1日多いんだけど。それにしても2月じゃなくて6月のほうに1つか2つくらい生やしてもよくない？祝日。
あなたの知らないカレンダー
ああ、祝日の話ついでですが、だいたい新人ちゃんに「プログラムをつくろう！」みたいなお題を渡すと「お休みの日を表示したいです！」とか無邪気に言い出します。すると因習村の老人みたいな連中が「祝日カレンダーには手を出しちゃなんねぇ！大変なことになるぞ・・・！」みたいな話をすることになります。
一般人のみなさんはだいたい知らない話ですが、昔・・昔か？まあいいや、昔のシステムは「カレンダーマスター」というマスタデータを保持していて、定期的なメンテナンスが必須でした。定期保守。ハッピーマンデーとかできる前の話だけど。
祝日のうち、「春分の日」及び「秋分の日」は、法律で具体的に月日が明記されずに、それぞれ「春分日」、「秋分日」と定められています。
「春分の日」及び「秋分の日」については、国立天文台が、毎年2月に翌年の「春分の日」、「秋分の日」を官報で公表しています。
日本における祝日というのは『祝日法（国民の祝日を定める法律）』によって定められており、春分の日と秋分の日は毎年不定です。なんとなくこの辺かな、というのはありますが、前年2月に国立天文台から公表があるまでは確定しません。
ここから先の話は業種業界によりますが、生産工場を抱えているメーカーや自動車系は工場の定期点検や夏場の電力の諸々で独自の休日カレンダーを持っていたり（工場が休みだと本社もグループも全部休みになる）、業界慣習上「締め日は月末締め、月中締め、10日締め、20日締めのいずれかとする」「締め日当日が祝日等であった場合翌翌営業日を締め日とする」みたいな謎設定があるせいで複雑怪奇な締め日カレンダーを持っていたりと色んなカレンダーがあります。国内だけで話が終わるのはまだマシなほうで、海外のどこかが営業日かどうか判定しないといけない場合はめちゃくちゃ話がややこしくなります。しらねえよ、イギリスの祝日とロンドン市場の休業日とか。
2024年の祝日は？知ってそうで知らない「国民の祝日」とその趣旨や経緯 | 政府広報オンライン (gov-online.go.jp)
人月よ神話になれ
ついでなので伝統的SIer単位の話も書いておこう。
皆さんご存じという前提で話をすすめますがIT業界には「人月」という単位があります。古典で有名なやつに「人月の神話」とかあるやつな。主に作業量の見積や評価で使う単位です。
人月は「量」の単位です。「期間」や「長さ」の単位ではありません。お湯をいれて3分で完成するカップラーメンを3つ並べて同時にお湯を注いでも1分で出来上がったりしません。
例の場合、3分後に3個のラーメンができあがり、投入工数は9分、3分間での成果物は3個です。あまりに見た目がわかりやすいので、「3分で3個できるなら、どうにかしたら1分間で1個できるのでは？？」とか言い出すやつが出ます。無理だっつってんだろ。
話がちょっと逸れましたが、「人月」の他に「人日」という単位もあります。「人時」はほとんど言わない、「量の単位」だから。「成果物の出力に必要な作業規模の概算値」に時間レベルの精度が出せるんか、っていう話な。1時間とか会議一回分ですよ。
1カ月20営業日計算で1人月は20人日で計算します。だいたい1人日は8hで計算しますが、ベンダーによっては7.5hで計算するところもあります。あの頃はホワイトぶってんじゃねえよ、と思ってました。
1人月＝20人日＝160h
3人月＝60人日＝480h
10人月＝200人日＝1600h
1週5日、1カ月は4週。単純計算で1人月を12倍すると1920hです。1年分。
毎日チームで15分の朝会夕会やると0.5h、週5日で2.5h、月で10h。1on1は見積にいれると怒られると思いますが、週次定例や報告会はいれておいたほうがいいでしょうね。
ここで前の「2月は営業日が少ない」の話に戻るんですが、期間が長くなればなるほど実際の暦とプロジェクト計画と必要な工数と人月見積との乖離がひどくなっていきます。営業日が足りない。年末年始と夏季休暇でずれる。工事凍結期間って何よ。旧正月がやばい。オフショアが誰もいねえ。進捗はでないが体制は維持しないといけないので、何か頑張ってやってる風な線表にしないといけません。何なんだこのパズル。
この話をすると「作業者のレベルによって成果物の量は変わるのでは」とか「実際の作業時間とかやってみないと分からないのでは」とか変な方向に迷い込んでいく奴が必ず出るのですが、根本的な部分の認識が違います。基本的に、人月は、「想定規模＝お金の請求をするための単位」なの。実際の作業量を評価するために適した単位じゃないの。今でも見積工数：実投入工数で評価やってるところもあるが、本質的にそれに適した単位ではない。客から「これっておいくらですか？」って訊かれて「やってみるまでわかりません」って言うのか？お前正気か？という話です。「こちらのお品でしたらこのお値段でいかがでしょう」っていうやりとりなんですよ。ノッてるときとそうでないときで進捗が全然違いますとか、実際のお前らの作業速度の話は聞いてねーのよ。
ちなみに、予算策定で、規模概算で、プロジェクト計画で、工数算出で、システム開発の各場面で要求される「見積」と呼ばれるモノは、それぞれ目的も実際に算出するロジックもインプットとなる値も（当然に要求されるアウトプットも）全然まったく別物くらいの違いがあって、しかしなぜか同じ「見積」という名前がついています。そして名前が同じだから全部同じ手法と同じ値を使いまわそうとするバカが常に湧きます。目についたら可及的速やかに討伐したほうがいいぞ。あとで必ず面倒事になって揉める。
たぶん（当時の）暗黙の了解なのでどこにも語られてないですが、人月見積には、「システム規模と必要な投入工数は比例する」「システム規模は機能数と要件に比例する」「システム開発の対価は、設備費・ライセンス費＋投入工数によって決定される」「アーキテクチャやインフラが似通った業務システムであれば、システム規模と必要工数も類似する」とかいう前提があります。たぶんFP法もこの前提には縛られてる。あと「進捗は投入工数に比例する」もいれといていいかな。そして、現代のモダンなアーキテクチャや開発手法において、一部の前提は既に崩れています。
発注契約にはお見積りが必要なので、破綻してる部分はわからないようにしてしれっとお出しします。商慣習というのはそうそう変えられるもんではないので。別にぼったくってるわけではないですが、どっかで見直し入るんだろうとは思うけどなぁ。
ついでに
見積本のおすすめも置いとくか。
楽天ブックス: ソフトウェア見積り - 人月の暗黙知を解き明かす - スティーヴ・マコネル - 9784891005221 : 本 (rakuten.co.jp)
原題は「Software Estimation: Demystifying the Black Art」。見積は黒魔術。23章が「政治、交渉、問題解決」。それなofそれな。
楽天ブックス: 本当に使える見積もり技術改訂第3版 - ソフトウエア開発を成功に導く - 初田賢司 - 9784822277048 : 本 (rakuten.co.jp)
見積もりはプロジェクトやプロダクトの「設計」である
この思想はほんと好き。