超高速開発とは何か

ここ数年、超高速開発という言葉をよく聞くようになってきた。いくつかの製品が発表されただけではなく、「超高速開発コミニュティ」の設立されたり、日経コンピュータでも「広がる超高速開発」という記事が取り上げられるなど、ひそかにブームが起こりつつある。

とはいえ、そこで紹介される素人でも開発、高い生産性、といった文句をうたった技術・製品というものは、RAD、ビジュアル言語、CASEツールといった名前で1960年代からずっと存在し、人工知能と同じように流行っては廃れてを繰り返してきたのも事実である。

私自身も以前から仕事でEXCEL設計書からのプログラム半自動生成フレームワークを作っていることもあり、とても関心の強い分野だ。

多くのプログラマは超高速開発を色眼鏡で見ているし、その認識の半分は全くその通りではあろうとは思う。開発の実務を知らない経営者や顧客にとっては、21世紀という時代にもかかわらずテキストエディタで意味のわからない呪文を書いてシステムを構築するという考えがとても非生産性的に見えるのもわからなくないのだが、GUIベースのWindowsが世界を制覇しそうに見えても、結局サーバサイドの勝者はテキストベースのWebとUNIX世界だったという事実からもビジュアルなものが常に優位なわけではないことがわかる。

数学者にとっての数式がそうであるように、ある一定レベルを超える複雑なロジックを構築し運用するにはテキスト・インターフェイスが最適なのだし、バージョンや差分の管理、共有性、安定性、いずれをとってもテキストファイルの有用性は否定しがたい。

では、やはり超高速開発はまた時代の徒花として消え去ってしまうのか、というとそうでもないのではないかと思っている。むしろ、長く潜伏していた時期を過ぎ、ようやく花開こうとしている感がある。

先日、ウォータフォール vs アジャイルという話題がまたさかんに議論されていたが、JUAS のソフトウェア・メトリックス調査の結果を見れば、議論すべきは、従来型開発 vs 超高速開発 の方であることははっきりしている。アジャイル導入で生産性が向上したという根拠は不明確な一方、まだサンプルは少ないものの超高速開発の生産性向上は2～3倍と圧倒的だ（ただ、この数値は圧倒的すぎて明らかに何らかのバイアスが発生していることはそのうち考察する）。

超高速開発が見直されている理由はいくつかある。

• 開発技術の複雑さが増している。HTMLだけ知っていればよかった時代と異なり、CSSやJavaScript、そしてその周辺の ES6, jQuery, React, Sass, Less, node.js といった各種Web技術に関する広範な知識が必要となった。超高速開発ツールの多くは、それらの知識に直接触れることなく開発できる。
• クライアント環境の自由度が増している。Windows XP、IE6しかなかった時代が終わり、HTML5の登場で規格の標準化が進んでいるとはいえ、IE, Edge, Chrome, Safari, Firefox といった各種ブラウザに対応する必要があるだけでなく、デスクトップ、タブレット、モバイル、はたまたテレビなど様々なプラットフォームにも対応を求められる時代になった。超高速開発ツールは、各種プラットフォームに自動で対応してくれる。
• 開発技術の自由度が増している。例えば、同じ Java 言語で開発といっても、違うフレームワーク上で開発されたプログラムには全く互換性がなく、知識やプログラムの流用が難しい。新しいフレームワークを導入するのも超高速開発ツールで開発するのも大差ない。

プログラマは超高速開発をビジュアル開発ツールの延長線上に捉えているのではないかと思っているが、おそらく超高速開発の本質はそこにはない（そういう意味では超高速開発という言葉自体が不適切なものである）。超高速開発をうたっているツールがもたらすパラダイムシフトはむしろモデル駆動開発が実現できるという点にある。

たとえば、超高速開発ツールでしばしば提供される機能として、画面ごとの滞留時間の自動計測がある。しかし、この「画面ごと」という単位は、それを考慮して開発を行わないと意外と難しい。MVCを使う場合、最終的に同じViewが表示されるかは、Controllerではわからない。次の画面に遷移しようとしたが、入力チェックにひっかかって前の画面に戻った場合は前の画面の滞留時間にカウントしたいなどの要件があると、簡単には求まらない。超高速開発ツールでは、まず「これは画面である」というモデルを定義し、そこから実際のプログラムを生成するため、どの範囲が画面のプログラムであるかというメタな情報を持つことができる。

こういった例もどうだろうか。モデル駆動開発系のツールであれば、データモデルを定義し、そこからDB上のテーブルの作成や、画面項目と更新先カラムの紐付けを行ったりできる。そのため、画面項目桁数や型がDB上のテーブルカラムの型と不整合がある場合エラーを検知することができる。通常のプログラム開発でこれを行うことは極めて難しい。

上述のクライアント環境やDBといったミドルウェアの違いに柔軟に対応できるのも、このアプリケーション・モデル駆動によりメタレベルの情報とプログラムの紐付けを行うことができる点に起因する。しかしながら、このモデル駆動であるという特徴は、別にビジュアル言語でしか実現できないわけではない。もしかすると、次の時代のプログラミング言語では、アプリケーションモデルの定義→ロジックの埋め込みが言語機能として組み込まれたものも生まれてくるのかもしれない。

圧縮アルゴリズム（メモ）

ログの圧縮は今まで gzip を使ってたのだが、そのままでいいのだろうかとふと思い最近の圧縮アルゴリズム（あるいはライブラリ）をググってみた。

その結果を gzip を 1.00 としてまとめたのが以下の表となる（小さい方が良い）。

今回の内容は gzip を基準にして各所のドキュメントを元におおまかな傾向をまとめただけのものなので、実際に同じサンプルファイルを使って比較すると違う結果が出る可能性はある。

タイプ	圧縮方法	サイズ	圧縮速度	伸長速度	メモリ量
バランス重視	gzip	1.00	1.00	1.00	1.00
	brotli	0.85	1.05	1.05	-
	zopfli	0.95	81.00	1.00	-
圧縮率重視	bzip2	0.75	7.20	5.00	2.75
	xz	0.65	4.00	1.85	75.00
速度重視	lzop	1.35	0.20	0.45	2.00
	snappy	1.50	0.20	0.30	-
	lz4	1.40	0.15	0.10	30.00

こうやってまとめると、どのアルゴリズムが最強というより、いずれも一長一短あることがわかって面白い。例えば一見、圧縮率、速度の両面で xz の方が bzip2 より優れているように見える。しかし、メモリ効率で考えると圧倒的に bzip2 の方が優れている。

なお、gzip に限らず各種ツールでは、圧縮レベルを指定できるものが多いものの、傾向自体には違いがでないようだ（とはいえ、あるアルゴリズムのレベル9と別のアルゴリズムのレベル1では結果が逆転することはある）。また、メモリ量は見つけられないものもあったので、後日暇があれば調べるかもしれない。

最近の経済について思うこと

経済について書くのが最近気恥ずかしくなってきたのでできるだけ書かないようにしているのだけれど、たまにはということで書いてみることにする。

最近の経済状況は、正直なところよくわからない。いや、元々専門家ではないのだからわからないのも当然ではあるのだが、多少はわかっているつもりではあった。より正直に告白すれば、今にして思えば結局、誰もわかっていなかったのだから、そんなもんだと思う方がよいのかもしれない。ともあれ、このエントリの内容は、ただ思っていることを書いているだけで、根拠のかけらもないと、先に予防線をはっておくことにする。

安倍政権になって以降、リフレ政策と消費税増税というふたつの大きな経済実験が行われた。本来であれば、もう十分に時間が経っているわけだから、その成否くらいはわかるのではないかと思うのだが、専門家である経済学者から納得のいく説明はなされていないように思う。それどころか、賛成派、反対派共に従前の主張を繰り返しているにすぎないようにすら見える。中には結果から見ても首を傾げるような主張を繰り返す人すらいる。

私自身、いまだにリフレ派であるから、基本的にはリフレ政策は（大とは言わない）成功であったし、消費税増税は（予想外に）失敗であったと思っている。が、残念ながら、その根拠は確かなものとは言いがたい。そうであろうと信じる、という表現がせいぜいである。

まず、リフレ政策だが、労働に関する部分、すなわち、フィリップス曲線で説明されるインフレ率の上昇が失業率を下げ、労働市場を逼迫させるという部分については想定通りのことが起こってるように見える。中高年の失業率も大幅に改善しているだけでなく、ブラック企業問題の勃発や社会的な労働時間削減の動きも強まっており、ここまで変わるものか、と驚くほどだ。それ以外にも、金利低下、円安、債権から株式などリスク資産への転換も予想された結果ではある。

一方で、大きく予想が外れたのが最大の争点となってきたインフレ率だ。インフレ率が多少は上がっていることは否定しようがない。とはいえ、インフレ目標を設定しあれほど大規模に金融緩和を行ったのだから、簡単にインフレになるだろうと思っていた。ある意味、クルーグマンの It's baaaack の通りデフレ期待は根強かったという言い方もできる。そうは言っても、昔からあったインフレ目標でハイパーインフレ、あるいは国債暴落などという意味不明な批判については、論外であることが改めて確認されたということくらいは言えるかもしれない。

なお、インフレ率の上昇がトレンドと区別がつかないという主張もあり、上記のように金融緩和は効果があったという考えには贔屓目があることは否定できない。それでも、良さそうなことは起こっている一方、悪そうなことは起こっていないことを考えれば、金融緩和を縮小するべき必然性はまるで思いつかない。手段の面でも、名目成長率ターゲットや地方債の購入など緩和拡大策はまだまだ残されている。

ただ、日本の低成長率の原因がデフレにあるかは今では疑問に思っている。生産年齢人口で見れば、日本の成長率は他の先進国とほとんど変わらない、という事実を考えると、低成長率の原因はバブル崩壊対応の失敗と少子高齢化の影響の方を主因とする方がしっくりと来る。

消費税に関しては、実は実施前には個人的にはさほど問題だとは思っていなかった。諸外国での実績を見ても、消費税増税それ自体が持続的に悪影響を与えることは考えにくく、「こんな経済が悪い時にあえてリスクを取る必要はない」という意味で反対ではあったもののそれ以上の考えはなかった。

しかし現実は散々たる結果だった。中にはいまだに消費税の悪影響は一時的であったと主張する人もいるにはいるが、おおむね、悪影響は前提とした上で、なぜこんなに悪影響を持ってしまったのか、という点に焦点が移っているように思える。

感覚的には、消費税そのものが問題だったというよりも、控除の廃止など純粋に増税されたこと、そしてその使い道が不適切だったのではないかと思っている。増税を行っても、税金は（公共事業や年金など）何らかの形で国民に還元されるものであるから、適切に使われるのであればその悪影響は最低限に抑えられると考える方が妥当だろう。

アベノミクス前にはまったく予想していなかったことではあるが、バーナンキの背理法で主張された、望ましくない副作用であるはずの「いつかはインフレになる」が否定され、起こるはずのない「無税国家の誕生」というマネタイズ政策が実際に機能する状況が発生してしまっている。経済学者の中には、景気が回復すれば国債は売らねばならず、貨幣発行益は消えると主張していた人もいると記憶しているが、実際に起こりそうなことは、好景気がいつまで経っても起きず、金融緩和策は止めるきっかけを失い、結果的に財政問題が解決してしまう未来である。

この状況は偶然起こってしまったかもしれないが、少子高齢化で国全体の成長率が抑えこまれている日本においては、唯一の正解なのかもしれない。25～60%の消費税率を甘受するよりはよほど現実的なように思える。

ガルム・ウォーズ見てきたよ

私を含むある一定の世代の人々にとって押井守は崇拝される存在である。実際のところ、宮﨑駿の圧倒的な認知度に比べ、押井守の世間的な知名度が低いことは請け合いなのだが、クリエイター系の人々への影響という意味では宮﨑駿を遥かに凌ぐ。映画「攻殻機動隊」の複数のシーンがまんま「マトリックス」にパクられているのは有名な話だが、パトレイバーの影響下で作られた「踊る大捜査線」など、その影響はハリウッドや日本の大ヒット作にも及んでいる。アニメーションにおいても、レイアウトシステムや広角レンズを用いた演出は押井守作品の影響と言っていい。歴史的な側面では、パトレイバー２が地下鉄サリン事件の予言的作品となったことも挙げて良いだろう。

近年、インターネットの発達でパクリが顕在化し問題になることが多いが多いが、町山智浩氏の様々な映画の解説を聞くと、映画のパクリは、むしろ和歌の本歌取りに近く、２時間という限られた時間の中で映画に意図を込める重要な役割を果たしていると考えた方が良いのだろうと考えるようになった（押井映画にも古いヨーロッパ映画からの引用が多数あるようだ）。

そういう意味で、多くの映画監督に引用された押井守の映画史における役割は、日本人クリエーターの中でもトップクラス。黒澤、小津に匹敵する人物と言っても過言ではない。

さて、もちろんこの後、ガルム・ウォーズについて語るわけだが、同じ調子で褒めるわけでは当然ない。この作品を見て、押井守という人物を過小評価してほしくないだけだ。私はアサルト・ガールズを基準に見に行ったので、予想外に素晴らしいものが見れたと感じたが、古き良き押井映画を期待したならば残念としか言いようのないものだったと想像するし、普通の映画ファンであればなんじゃこりゃと思っても不思議ではない代物ではあった。

近年の押井映画の評価の難しさは、天野喜孝のイラストのそれと近いものがある。たしかにこの作品は押井守以外の映画監督には決して作れないものである。その意味で凡庸ではない。しかしながら、素晴らしいかと言われれば、否定の言葉しか出てこないだろう。

まず映像。そのビジュアルイメージはやはり圧倒的で、今作でも航空機や巨神兵、ラスボスのデザインなど素晴らしいものがある。もし、これが新作ゲームのOP映像であれば心踊ること請け合いだ。しかしながら、これは映画なのだ。押井映画でのCGの使い方はいつもテカテカでゲームのOPみたいに見えてしまう。さらに問題なのは、どうもインタビューなどを見る限り、映像的には押井守のお眼鏡にかなう代物らしい。この映像が正解ならば、イノセンス以降CG表現が改善されないのも納得ではある。アニメーションの表現においては、あれほどまでにリアリティある作品作りができるにもかかわらず、実写やCGにおいてはなぜそこまで感覚がずれてしまうのか。

次に脚本。とてつもなく凡庸なだけでなく、人物描写も不自然で、80年代OVAを見ている気持ちになってしまった。押井守に言わせれば神話とはそんなものだ、ということかもしれないが、観客は古代の神話の授業を聞きに来ているわけではない。それに加え、自己パロディが散見されるのにも辟易とする。実写版パトレイバーはそういう作品だから良いとしても、まるで攻殻機動隊、まるでレイバー２、まるでスカイ・クロラ、と過去の作品の焼き直しのような要素が多すぎる（巨神兵に至っては押井作品ですらない）。これらの自己パロディ的な要素をもって、ガルム・ウォーズを押井監督の集大成と呼ぶ人もいるようだが、それは「夢」を黒澤明の集大成と呼ぶようなものだ。集大成とは、宮﨑駿における「風たちぬ」のような作品にこそふさわしい。

そして演出。いくら何でも冒頭からあらすじで説明はなかろう。そして犬。私とて押井映画のファンであるから、現実の身体の体現者としてバセットハウンドを出した意図は理解できるにしろ、映像としては違和感しかない。いつもの押井映画要素とはいえ、ここまで重要な役割を持って全面に出されるとさすがに唖然とする。いや、むしろ、これは古くからある、愛人の女優を抜擢する映画監督のそれなのか。

前述のとおり、見る前から期待していなかったため怒りは特に感じていない、川井憲次のすばらしい音楽に合わせかっこいい映像が流れるという意味で、むしろ鑑賞はとても快適だった。ただ、ひとつの時代を作った偉大な映画監督の才能が急激に減衰していくのを見て、とても寂しく思った。そのことを書いておきたかった。

GARM WARS 白銀の審問艦

続・工数見積りの海を彷徨う（ロバスト回帰編）

前回のエントリでは、通常の回帰分析を用いて、機能数から工数を算出したが、その結果を見ると、経験的な工数に比べ、多少高めに出ているのではないという疑念があり、改善の余地があるのではないかと考えていた。

勘と経験よりもデータから求められた結果の方が正しいと思われるかもしれないが、まったく根拠がないわけではない。例えば、FP値（IFPUG/新規開発）のデータ群を見ると、平均値 1,798 に対し中央値 878 となっており倍近い開きがある。一般に平均値よりも中央値の方がよりデータ全体の実態を表していると考えられている。

前回のエントリの結論は、通常の回帰分析手法を用いている以上、外れ値は除去したとはいえ、まだ平均値的な値に寄っている可能性がある。

というわけで、引き続き調べていたところ、ロバスト回帰という外れ値や誤差に強い分析手法があることを知った。そもそもの話として通常の回帰分析は外れ値に強く影響されるため、誤差が正規分布していると仮定できない場合には適用すること自体が不適切であるようだ。

さすがにロバスト回帰分析を行うとなると、EXCELではつらい。ということで今回は R を使うことにした。

まず、画面数、帳票数、バッチ数と工数[人時]にロバスト回帰を行う。

> lmrob(MH ~ VC + RC + BC - 1, data_all, setting="KS2014")

Call:
lmrob(formula = MH ~ VC + RC + BC - 1, data = data_all, setting = "KS2014")
 \--> method = "SMDM"
Coefficients:
    VC      RC      BC  
 86.36  118.69   56.22

この結果に従えば、次のようになる。

工数[開発5工程／人時]＝86.36×画面数＋118.69×帳票数＋56.22×バッチ数

前回、重回帰分析をした場合同様、帳票の係数の方が画面よりも大きい。しかしこの係数自体は、あまり信用出来ない。例えば、データを500人月以下に絞ると次のようになる。

> lmrob(MH ~ VC + RC + BC - 1, subset(data_all, MH < 80000), setting="KS2014")

Call:
lmrob(formula = MH ~ VC + RC + BC - 1, data = subset(data_all, MH < 80000),     setting = "KS2014")
 \--> method = "SMDM"
Coefficients:
   VC     RC     BC  
89.74  83.71  54.99

たまたま、大きめのプロジェクトに複雑な帳票が多かったのではないかと思われる（あるいは大規模な業務システムほど、複雑な帳票が増える傾向にあるということかもしれない）。

恣意的ではあるが、今回も係数は画面：帳票：バッチ＝1.5：1.0：0.7 を使うことにする（この関係の導出については引き続き課題として残っている）。

> lmrob(MH ~ FC - 1, transform(data_all, FC = 1.5 * VC + RC + 0.7 * BC), setting="KS2014")

Call:
lmrob(formula = MH ~ FC - 1, data = transform(data_all, FC = 1.5 * VC + RC +     0.7 * BC), setting = "KS2014")
 \--> method = "SMDM"
Coefficients:
   FC  
70.63

この結果から式は次のようになる。

工数[開発5工程／人時]＝105.95×画面数＋70.63×帳票数＋49.44×バッチ数

１画面あたり0.66 人月（=105.95/160）。経験的には結構いい線を突いているのではという感じがある。

規模の係数についてはよくわからない（累乗モデルを適用すると累乗が 1 以下になる）。データを眺めてみたが、規模が大きくなるにつれ係数が大きくなる傾向はあるが、分散だけが広がっているようにも見える。

なお、FP(IFPUG/新規開発)⇒工数の関係についてもロバスト回帰にて求めた。

> lmrob(MH ~ FP - 1, data_fp, setting="KS2014")

Call:
lmrob(formula = MH ~ FP - 1, data = data_fp, setting = "KS2014")
 \--> method = "SMDM"
Coefficients:
   FP  
15.12

FP値から工数を求める場合は、次の式で計算できることになる。

工数[開発5工程／人時]＝15.12×FP値

さて、この結果をどのように考えるべきだろうか。おそらく、前回の結果は間違いというよりもリスクを含めた上での平均的な工数見積になっていて、それに対し今回の結果は大半のプロジェクトにとって妥当な工数が見積れていると考えられる。

システム開発プロジェクトは、妥当な見積り工数から見て5倍は上振れする場合があり、妥当な見積りが出せるだけでは十分ではなく、リスク管理がとても重要であるというある意味誰もが知っている話に落ち着く。

1.5倍程度の開きであれば創意工夫でなんとかなる部分もありそうだが、5倍の開きともなるとどうにもならない。リスクがあるならばそれに見合った見積りを出し、それが望めないならば断るということをしない限り、プロジェクトの成功はとても望めそうもない。

工数見積りの海を彷徨う

[2018/07/01 追記] 過去に話題になったこともあり、このページに辿り着く方が多いようなのだが、係数導出の手法については継続的に改善を行っている。現時点では、「工数見積りの海を彷徨う・征服」というエントリに記載した「分位点回帰」を使うのがベストではと考えている。50%分位点が中央値にあたるため係数も安定しており、現在の見積りが過去のプロジェクトと比較してどのくらいの工数なのかが明確でわかりやすい。合わせて参考にしていただきたい。

---

工数見積りが難しいのはわかっているのだが、そうは言っても根拠は欲しい。この業界に入ってからずっと考え続けているのだが、やはり難しい。

この手の工数、工期という話題の時、役に立つのは次の資料だ。

• IPA ソフトウェア開発データ白書

• JUAS ソフトウェアメトリックス調査

素晴らしいことにどちらも PDF 版は無料で配布されているので、ダウンロードして見ることができる。システム開発サイドだけでなく、エンドユーザ側でも有用な資料だと思う。

特に標準工期や各工程の割合に関しては、データの安定性が高くそのまま使える。例えば、標準工期は、人月工数の三乗根に2.4～2.5をかけた数字となる。JUASによれば、標準工期を30%以上下回るプロジェクトは無謀とのことだが、あなたのプロジェクトはいかがだろうか。 

問題は、工数見積りだ。工数は単価をかければそのまま金額になるわけだし、標準工期のベースともなる。一番重要な指標と言える。しかし工数については、データを見ても分散が大きく、IPAでも、あくまで目安として50%の信頼幅に収まっているかを見るのに使ってください、というスタンスを取っている。

JUASはもう少し踏み込み、毎年データから回帰分析を行い総工数の見積りに使える式を算出しているのだが、各年の結果がかなり異なる。例えば、2007年度版では、総工数＝1.55×画面数だと書かれている一方、2009年度版では、総工数＝1.09×画面数となっている。ここ数年の版に至っては、画面数だけの分析は削除され、画面と帳票での分析のみが掲載されている。同じ機能数なのに工数が50%も違うのでは、見積りチェック用途だとしても使いづらい。

とはいえ以前、システム開発はもっと明朗会計にならなければいけないでも書いたように、FP法と総工数には、分散はあるものの明らかに正の相関が認められる。FP法は「機能」をポイント化しているわけだから、工数は機能を正しく見積ることができればある程度予測できることが想像できる。

このことから考えると、面倒ではあるが、まじめに FP を求めろという話ではあるのだが、実際には FP 法での見積りは次のような理由があって難しい。

• 概算見積りを求められるのは、RFP(Request For Proposal)提示時など要件定義前の早いタイミングでありエンティティと言った詳細な設計まではとても落とせない。
• FP法は、機能ごとの見積りではないため、機能数の削減が工数に与える影響を見積るのが極めて困難である。この機能を削るからいくら安くします、などという交渉が難しくなる。

そのため、JUAS 同様、画面、帳票、バッチなどの機能数から概算見積りに落としこむことはできないかと考えてきた。

今まではベースとなる数値はかなり直感に頼って決めていたのだけれど、昨晩 IPA 公開のデータを見ていたら、画面数⇒総工数、帳票数⇒総工数、バッチ数⇒総工数については個別のデータが取得できる事に気づいた。

IPAでは、（画面数、帳票数、バッチ数、総工数）の組み合わせデータは公開されていないが、総工数はプロジェクトごとに異なるわけだからマッチングすれば概ね元通り復元できる（数件、総工数の重複したデータが存在したため、それらについては機能数が多い方に寄せて対処した）。このデータを元に何らかの計算式を導出できないかと考えてみた。

まず、正攻法で重回帰でパラメータを導出してみたのだけれど、帳票の工数が画面より大きかったり、外れ値にかなり影響されていたりとおよそ使える式にはならない。

世の中には様々なシステムが存在しているわけで、とても簡単な画面を大量に作るプロジェクトもあれば、1画面が20人月を越えるような複雑なシステムもあるだろう。また、アンケート形式であるので、データ自体どこまで信頼できるかわからない。画面数がわからないのでメニュー数を使っているケースや数十シートを持つEXCELを1帳票として数えていることも十分に考えられる。

目的としては、一般的で標準的な機能群を持つシステムのために見積の基準を決めたいというところにある。そこで、考え方を変え、次の基準に従って制約を加えることにした。

• 機能⇒工数ではなく、機能⇒FP⇒工数という過程を通して見積る
• 画面数、帳票数、バッチ数の標準工数に重みを付ける
• 機能あたりのFPが離れたものを外れ値として除外する
• 工数の範囲を一般的なプロジェクトと考えられる10～1000人月の間に制限する

まず、FP⇒工数については、IPA の資料から工数[開発5工程／人時]＝4.85×FP^1.13をそのまま使う。

次に画面数、帳票数、バッチ数の重みであるが、以下のような仮定を置いてみる。

• 標準的な画面の工数は、標準的な帳票の工数の 1.5 倍程度だろう（JUAS の資料でもどこかで、この仮定を置いていたのを見た気がするが、感覚的にはそんなものだろう）
•  標準的なバッチとしてCSV出力するようなものが考えられる。そのような処理は帳票で言えば簡単なものに括られる。すなわち、標準的なバッチと簡易な帳票の工数は同等だろう。
• 機能の難易度はIFPUGでは高、中、低の三段階となっており、概ね高＝中×1.5、低＝中×0.7となっている。

このような仮定を置くと、標準的な画面、帳票、バッチの工数比が 1.5:1.0:0.7 となることが導出できる。

この二つが決まれば、工数から想定FPを逆算した上で、工数比をかけた画面、帳票、バッチ数から単位FPを求め、箱ひげ図を使って外れ値を除外することができる。通常、箱ひげ図を使う場合は、内境界点の外にあるデータを外れ値とするが、画面辺り3人月のようなデータも残ってしまう。そこで25～75パーセンタイルに収まらないデータを外れ値として扱うことにした。

そうやって、ようやくたどり着いたのが次の式となる。

工数[開発5工程／人時]＝4.85×(13.77×画面数＋9.18×帳票数＋6.42×バッチ数)^1.13

難易度を考慮するなら、機能数＝1.5×難易度高＋難易度中＋0.7×難易度低とすればよいかもしれない。なお、括弧の中の数字はそのままIFPUGのFP値となっているはずなので、実測のFP値と比較してみることもできる。

さて、実際のところこの数式は使い物になるのだろうか。もし、使ってみて高く出すぎる、低く出すぎるなどあれば、感想を教えてもらえるとありがたい。

【2016/4/26追記】

FP⇒工数の算出式はIPAのものをそのまま用いていたがデータセットは合わせた方がよいだろうという気になり、工数範囲を10～1000人月、FPあたりの工数で外れ値の除外を行った結果、FP⇒工数はほぼ直線となった。規模による工数増が消えてしまったわけだが、規模が増えるにつれて分散が大きく上振れしがちという事情が影響しているということなのかもしれない（単に外れ値除去の結果、平均化されてしまっただけかも）。

結果としては式はシンプルになった。

工数[開発5工程／人時]＝12.13×(14.68×画面数＋9.79×帳票数＋6.85×バッチ数)

前回の式より数値は10%ほど上振れしている。ただ、こちらの方が単純な掛け算なのでわかりやすいかもしれない。１画面あたり 1.11 人月というのは意外と大きいなという印象なのだが、そんなものだろうか。

睡眠を科学する

たまに布団に潜り込んでも目が冴えてまったく眠れないことがあった。心配事があって眠れない、ということも時にはないわけではないけれど、どちらかと言うと、理由もわからずただ眠れない、ということの方が多かった気がする。

最近は、朝日が入るマンションに引っ越して通勤時間が減ったこともあるのか、まったく眠れない、という機会も減ってはいるのだけれど、快眠はQOL的に重要なわけで、うまく実現する方法があれば知りたかった。

先日、Twitter でたまたま紹介されていた本の評判が結構良かったので買ってみたところ、予想外にまともな本だったので内容を紹介したい。

朝型勤務がダメな理由 あなたの睡眠を改善する最新知識

 ダイエットにしても、睡眠にしても、この手の本で困るのは、根拠の怪しい言説をやたらと持ち上げるオカルト本が多いことだ。この本もその類かもしれないけどとりあえずむ程度の気持ちで手にとったのだけど、追試が行われていな研究であることを注意していたり、学術的にわかっていないことはきちんとわかっていないと明記されているなど、記述も大変良心的で問題はなさそうだ。

さて、本書は良い本ではあるものの連載をまとめたものであることもあり、要点がわかりにくい。そこで箇条書きで書き出してみると、こんな感じになる。

• 睡眠傾向には、その人が本来持つ朝型/夜型の体質や必要睡眠量と環境・習慣による変動からなる
• 朝型/夜型の体質や必要睡眠量は遺伝的影響が大きく変えられない。睡眠量の個人差は必要睡眠量と環境で2:1の割合
• 目覚めてから16時間以上が経過すると酒気帯び運転を遥かに越えるレベルで注意力やパフォーマンスが低下する。睡眠不足は蓄積し、4時間睡眠を一週間続けると一晩の徹夜と同じレベルの眠気を二周目には三晩徹夜と同じレベルの眠気を感じる。6時間睡眠でも10日を超えると徹夜明けと同じレベルで認知機能が低下する。眠気は一定程度強くなると頭打ちになるが、認知機能は睡眠不足の累積に応じてドンドン低下する（眠たくはなくてもアホになってなるかもしない！）
• 高校生～大学生の思春期に最も夜型になる。登校時間を遅らせるだけで集中力が上がり、抑うつ感や倦怠感が改善し、健康に対する不安が減り、学習や課題活動へのモチベーションが高まる。成績上位者の割合が34%から50%に急増したとする研究もある
• 夜勤には生活習慣病やがんに罹患するリスクが増大するなどの健康上のリスクがある。体内時計の調整にはかなり時間がかかり、夜勤に体内時計を合わせるには３週間程度を要する。そのため、夜勤は避けるに越したことはないが、どうしても夜勤に従事する場合は、夜勤の真ん中でカフェインを取り、30分程度の仮眠を取ることが望ましい
• 覚醒直後の認知機能は徹夜明け以上に低下する
• 20～22時前後は一日で一番「眠くならない」時間帯。この時間に早寝してもすぐに起きてしまう
• 就寝前1.5～3時間前にお風呂に入るとよく眠れる。一方でいわゆる快眠グッズはほとんどプラシーボ。ただし、睡眠においてプラシーボ効果はとても大きいので、利用できるならそれに越したことはない。運動によって基礎代謝を高めることで快眠効果を得ることもできるが、３～６ヶ月以上かかる。ただし、一旦達成した場合、安定した睡眠が得られるため地道にチャレンジする価値はある
• 不眠症は実際に睡眠時間が減るというよりも、睡眠時間が減って感じられる現象。そのため、睡眠薬を飲んでも状況が改善しないことがある。しかし、そのメカニズムはいまだ不明である

個人的には、もっと快眠についての知見を得たかったが、この本を読む限り、快眠についてはまだまだわかっていないことが多いようなのが残念だ。

一方で、この本のタイトルにもある「朝型勤務」の問題はセンセーショナルだ。私の所属する会社も昨今「朝型勤務」を奨励しており、一時期私自身試してみた時期もあるのだが、どうにも眠くなってむしろパフォーマンスが落ちたように感じられ止めてしまった。この本で紹介されている「朝型/夜型のアンケート」によれば私は夜型に近い中間型とのことで、やはり向いてなかったのだろう。

このことに限った話ではないけれども、政府や企業に関わらず、制度設計を行う上でしばしば学術的な知見が無視されるのは残念に思う。科学は万能ではないけれども、わかっていることもあるのだから出来る限り有効に使うべきだろう。