なぜ相対的な人事評価制度は廃止されるべきなのか

先日、「悪いヤツほど出世する」という本を読んでいた時に、なるほど相対的な人事評価制度は廃止すべきという考えはもっともである、という結論に思い至った。*1

悪いヤツほど出世する

 以前、「評価は必要だ。だが、強制ランキングシステムはいらない」というエントリで書いたけれども、過去十数年にわたり流行ってきたスタック・ランキング制度*2は、実際に運用した結果として大きな問題が明らかになりアドビ、マイクロソフト、IBM、ゴールドマン・サックスなどの大企業を筆頭に廃止する動きが進んでいる。

アメリカは成果主義だが日本は違う、あるいは日本も成果主義に移行しなければ、という風潮も過去のものになるかもしれない。とはいえ、スタック・ランキング廃止後の制度が日本型の年功序列終身雇用になるわけではない。それらの企業で変わりに導入された仕組みは概ね次のようなものだ。

• 相対評価を廃止する
• フィードバック頻度を短くする

後者のフィードバック頻度について特に疑問はない。通常の評価制度は昇給や年俸に合わせ年に１回行われるのが普通だ。とはいえ、私自身も経験があるが、年初計画していたプロジェクトと実際に関わったプロジェクトがまるで違う、などということは実際の業務では頻繁に起きる。それに、１年も立ってからこういう理由であなたの評価を最低です、と言うのであればもっと早く言ってよ、と思うのが人情だろう。

問題は前者の相対評価の廃止だ。相対評価は日本においても一般的なものだと思うので、それを廃止するとはいったいどうやって昇進を決めるんだろうと最初思ったのだが、やはり評価すべき人物や改善が必要な人物は上司などでピックアップして報告するようだ。旧来の評価制度との違いは、中間層についてはその能力の上下を評価しないという点にある。

相対評価の問題点はふたつある。ひとつは、社員間での競争が加熱し本来、協力関係こそが必要な組織力構築の障害になるという点。もうひとつは、人には自分は平均より優れているという「優越の錯覚」というバイアスがあるため、相対評価という客観評価をすることで多くの人々のモチベーションを下げてしまう点だ（なんと９割の人が自分は平均より上だと思っている！）。わざわざ、モチベーションを下げるために人事評価を行うというのは馬鹿げた話に思えるが、実際にほとんどの企業で行われれているのはそういうことだ。

評価すべき人物、改善が必要な人物をピックアップする時点で同じ問題は残るのではないか、とも思われるのだが、それについてはGoogleの「ワーク・ルールズ！」が参考となるのではと思う。相対評価を下すならば、誰が見ても歴然とした差がある場合にだけ境界を引けというのがGoogle推奨のやり方である。

「権力」を握る人の法則 (日経ビジネス人文庫)

*1:なお、この本自体はあまりお勧めできない。前著の「「権力」を握る人の法則 」の方がまだいい

*2:社員全員をランキングし上位 n% に高報酬を与え、下位 n %は強制的に退職させる仕組み

続・圧縮アルゴリズム（実測）

以前のエントリでは、文献をベースに圧縮アルゴリズムの違いを一覧化したが、この度、Windows Subsystem for Linux がようやく一般公開されたので、その環境上で実際に各種圧縮プログラムでの圧縮効率を実測してみた。

データとして使ったのは、郵便番号ダウンロードの全国一括データ(約12MB)。容量的にはたいしたことはないけれども、18種類の圧縮プログラムを10回実行し平均を取るとなると結構な時間がかかる。

値は前回と同じく gzip を基準に正規化したものを記載している（ちなみに gzip 圧縮後サイズは、約1.8MB で 15%ほどのサイズに圧縮されている）。

圧縮プログラム	圧縮後 サイズ	圧縮時間	圧縮時 最大メモリ量	伸張時間	伸長時 最大メモリ量
lzip(best)	0.69	31.40	164.17	2.61	17.47
xz	0.69	23.68	106.96	2.45	12.24
lzip	0.71	19.44	102.77	2.58	12.43
brotli	0.72	94.01	72.48	0.63	7.31
bzip2	0.79	4.22	7.97	5.19	5.62
xz(fast)	0.85	1.67	4.05	2.50	1.66
zopfli	0.89	2191.20	75.25	1.00	1.00
gzip(best)	0.95	6.33	0.96	1.02	1.00
lzip(fast)	0.97	3.24	14.47	2.63	2.87
gzip	1.00	1.00	1.00	1.00	1.00
lzfse	1.00	1.70	30.17	0.66	24.88
gzip(fast)	1.18	0.47	1.00	1.14	1.00
lzop(best)	1.21	12.08	1.84	0.36	1.20
lz4(best)	1.29	1.38	6.52	0.34	7.31
snappy	1.49	0.21	1.39	0.41	1.61
lzop	1.50	0.16	1.44	0.44	1.20
lzop(fast)	1.50	0.14	1.59	0.47	1.20
lz4	1.61	0.22	6.37	0.25	7.57

こうしてみると、総合的に gzip のバランスの良さが目立つ。圧縮率も速度もメモリ量もそこそこというのは使い勝手を考えると大きなメリットだ。

圧縮率を重視するなら、LZMA 系の lzip, xz が優勢となる。圧縮速度、メモリ量などを考えると lzip よりも xz の方がよいように見える。

伸張速度を重視するなら、はやりの lz4 がやはり良いようだが、メモリ消費が激しいので、そのような用途では lzop や snappy の方が良いかもしれない。ただ、今回は試していないが、 lz4 もストリーム圧縮に対応したようなので、ライブラリを使えば回避できるかもしれない。

最近の圧縮アルゴリズムのはやりは、Web でのダウンロードを想定し、圧縮率と伸張速度を重視したものが増えている。たしかにその用途では brotli は魅力的に見える。gzip 互換の zopfli も魅力的ではあるが、1割の圧縮率向上のために2000倍の圧縮速度低下を受け入れるのはなかなか厳しい物がある。Apple の新圧縮アルゴリズム lzfse も今回計測対象に入れてみたが、圧縮率は gzip 並、圧縮速度もそう悪くなく、伸張は速いという特徴なので、どちらかと言うとストレージのリアルタイムでの圧縮・伸張が想定されているのかもしれない。

前回も書いたけれども、いずれの圧縮プログラム／アルゴリズムとも特徴があり、きちんと用途に応じたものを選ぶ必要があるのだ、ということを改めて感じた次第。

超高速開発とは何か

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

とはいえ、そこで紹介される素人でも開発、高い生産性、といった文句をうたった技術・製品というものは、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倍の開きともなるとどうにもならない。リスクがあるならばそれに見合った見積りを出し、それが望めないならば断るということをしない限り、プロジェクトの成功はとても望めそうもない。