山浦恒央　東海大学 大学院 組込み技術研究科 准教授（工学博士）

統計アレルギーの解消には、身近な分野で考えてみることも大切です。今回は「ワインを飲まずに、ワインの品質を予測する方法」を例に統計に触れてみましょう。

「統計分析」と聞くと面倒な感じですが、何を証明するか明確ならExcelで簡単にこなせます。Excelさえあれば追加費用はかからず、しかもランチタイムに終わるほどカンタンなのです。

「王様の耳はロバの耳」と統計的に判定するには、どうすればいいのでしょうか？ロバの耳かも？という仮説を“検定”するための基本的な考え方を学びます。

「効果がある」と言うためには比較が必要です。新旧開発プロセスの生産性や品質の平均値を比べるためには、「平均値の差の検定」が必要となります。

難しそうな「統計」ですが、データの分析以上に重要なのが「収集」です。今回は、統計分析の前段階に相当する「データを集める」という部分に焦点を当てて解説します。

データ解析の王様ともいえる「平均値」ですが、それが本当に母集団の性質を表現しているかは確認すべき事項です。母集団によっては「最頻値」や「中央値」の採用を考慮すべきです。

思わず身構えてしまう「統計」ですが、手をつけてしまえば何とかなるものです。今回はデータ解析手法の“王様”である「平均」について、解説します。

「統計」と聞くと頭が痛くなる人も多いかと思いますが、「今持っている知識でも何とかなる」ものです。その第一歩として、簡単なデータの可視化手法について紹介します。

「統計」と聞くだけで及び腰になる気持ちも分かりますが、ツールの充実した今、そう難しいものではありません。第一歩として、統計における「数値の種類」について、理解を進めましょう。

ソフトウェア開発においてデータの重要性は言うまでもありませんが、「統計的に分析せよ」と言われると腰の引ける人も多いはずです。ですが、ツールの充実した今、そう難しいものではありません。まずは統計分析の「御利益」を知って、食わず嫌いを克服しましょう。

筆者の研究室で、ゲームに見られるバグの「悪いバグ」をさらに分類したところ、大きく分けて13種に分類できました。上位6種で75％を占めますが、今回は悪いバグの「少数派」について説明していきます。

ゲームのバグには「良いバグ」もあり、仕様となったり名物になったりすることもあります。ただ「悪いバグ」があることも事実で、筆者の研究室ではこれを分類することにしました。「悪いバグ」のケーススタディです。

組み込み系の代表例の1つ、ゲームの世界ではバグが「良いバグ」と評価され、「裏技」と呼べる存在になることもあります。“バグが悪ではない”感覚は品質制御の世界観を広げてくれるはずです。

ソフトウェアのバグは一般に“あってならないもの”ですが、ゲームソフトにおいてはバグが魅力になることもあります。今回は4つのケースを通じて、ユーザー目線での「良いバグ」が何か、考えてみましょう。

ソフトウェア開発において「バグ」は悪者ですが、ゲームにおいては必ずしも言い切れず「魅力のあるバグ」が発生することもあります。全てのバグは悪か？　そんなお話です。

ソフトウェア開発プロジェクトで、リスク管理は大変重要ですが、きちんと実施している組織はほとんどありません。今回は「リスクの発見」を復習し、リスク管理の手順を解説します。

ソフトウェア開発プロジェクトで、リスク管理は大変重要ですが、きちんと実施している組織はほとんどありません。今回は、甲子園での高校野球の好プレーを例にしながら、ソフトウェア開発でのリスク管理について考えます。

「リスク分析」という言葉をよく聞くようになりましたが、実際に行うプロジェクトは少ないのではと思います。リスクの洗い出しと対処策の検討を、身近な例と対比しながら考えます。

あれは米国ボストンに駐在していたときのこと――。ある日、私が管理していたオフィスの入退室セキュリティシステムが動作しなくなった。その当時、大流行がウワサされていたあるウイルスの存在のせいなのか、あるいは……。

ソフトウェア開発プロジェクトで致命的な失敗を引き起こす、「仕様の誤解」が発生するメカニズムを詳しく解説します。

オフショア開発の主要な問題点を取り上げるシリーズ。最終回は「『当たり前』は本当に『当たり前』か」をテーマに、オフショア開発を成功に導く3つの秘訣を解説します。

オフショア開発は、海外（外国人）に発注するから難しいのではなく、他人に発注するから難しい――。番外編「技術翻訳」シリーズの最終回。今回は、技術翻訳の神髄「“日本語で”良い文章を書くには？」をお届けする。

オフショア開発は、海外（外国人）に発注するから難しいのではなく、他人に発注するから難しい――。今回もオフショア開発の話題から少し離れて、「技術翻訳」のコツ、テクニック、注意すべき点を紹介する。

オフショア開発は、海外（外国人）に発注するから難しいのではなく、他人に発注するから難しい――。前回に引き続き、オフショア開発の話題から少し離れ、ちょっと一休み。“番外編”として「技術翻訳」のコツ、テクニック、注意すべき点を紹介する。

オフショア開発は、海外（外国人）に発注するから難しいのではなく、他人に発注するから難しい――。今回は、オフショア開発の話題から少し離れ、ちょっと一休み。“番外編”として「技術翻訳」のコツ、テクニック、注意すべき点を紹介する。

オフショア開発は、海外（外国人）に発注するから難しいのではなく、他人に発注するから難しい――。新シリーズでは、「オフショア開発とコミュニケーション問題」を取り上げる。今回は異なる言語間で意思疎通する方法、すなわち「翻訳」について解説する。

オフショア開発は、海外（外国人）に発注するから難しいのではなく、他人に発注するから難しい――。新シリーズでは、「オフショア開発とコミュニケーション問題」を取り上げる。今回は異文化を体得するプロセス、すなわち「異文化受容」について解説する。

オフショア開発は、海外（外国人）に発注するから難しいのではなく、他人に発注するから難しい――。新シリーズでは、「オフショア開発とコミュニケーション問題」を取り上げる。今回は、文化の違いによる“ドキュメント記述の曖昧（あいまい）さ”について解説する。

オフショア開発は、海外（外国人）に発注するから難しいのではなく、他人に発注するから難しい――。新シリーズでは、「オフショア開発とコミュニケーション問題」を取り上げる。まずは、日本と外国との文化の違いを数値で把握してみよう。

今回は「第14回 A.S.I.世界最優秀ソムリエコンクール 東京大会」を観覧して感じたソムリエの世界と、ソフトウェア開発の世界の“共通点”について紹介したい。

プログラマーの永遠の課題「プログラム中の残存バグ数の推定」に迫るシリーズ。第5回では、「サンプリング」による残存バグ数予測について解説する。サンプルとなるテスト項目をどのように選ぶかが“鍵”だ！

プログラマーの永遠の課題「プログラム中の残存バグ数の推定」に迫るシリーズ。第4回では、たったの30秒で推定できる割に、意外と精度も低くない「バグ率による総バグ数予測」を取り上げる。

プログラマーの永遠の課題「プログラム中の残存バグ数の推定」に迫るシリーズ。第3回では、品質エンジニアが眺めているだけで“ご飯を3杯食える”ほど大好きな「Gompertz曲線」による残存バグ数の推定法を紹介する。

プログラマーの永遠の課題「プログラム中の残存バグ数の推定」に迫るシリーズ。第2回では、前回紹介したトンデモ推定法「キャプチャー・リキャプチャー・モデル（別名：ソフトウェア版『池の中の魚』モデル」の改訂版である、「2チーム制」モデルを取り上げる。

プログラマーの永遠の課題「プログラム中の残存バグ数の推定」に迫るシリーズ。今回は、エンジニアの基本姿勢から逸脱した、一種のトンデモ推定法である「キャプチャー・リキャプチャー・モデル（別名、ソフトウェア版『池の中の魚』モデル」を取り上げます。

「『見積もり』は、ソフトウェア開発における大きなテーマであり、ソフトウェア工学における最重要課題の1つである」――。見積もり・シリーズついに完結。これまでお届けしてきた重要ポイントをおさらいする！

前回に引き続き、“契約条件”の面から実践できる見積もりミス対策を検討する。客観性のある見積もり技法を2つ以上学び、その技法の具体的な適用方法を習得し、さらに、契約面からも見積もりミスに対処できるようになれば、あなたは立派な「見積もりの“黒帯”」だ！

今回は少し視点を変えて、“契約条件”の面から、実践できる見積もりミス対策を検討する。ソフトウェア開発で主流の一括請負契約におけるリスク軽減対策とは？

見積もりの知識と技法を駆使した「デスマーチ・プロジェクト」への対処法を検討する。今回は、プロジェクト管理者が1人で実施できる6つのステップについて順を追って詳しく紹介する。

見積もりの知識と技法を駆使した「デスマーチ・プロジェクト」への対処法を検討する。今回は、発注側と開発側の双方が満足できるソフトウェア開発の手順を紹介。この手順に従えば、デスマーチ・プロジェクトに対処できるはずだ！

これまで解説してきた見積もりの知識と技法を駆使した「デスマーチ・プロジェクト」への対処法を検討する。まずは、デスマーチ・プロジェクトで見積もりをきちんと適用できるようになるまでの進化の過程を見ていこう。

「ソフトウェア技術者の最高の能力は、見積もりだ！」――今回は筆者お手製のExcelシートの計算式を使い、“開発エンジニアを何千人・何万人投入したとしても、「この期間」よりも絶対に短く開発することはできない”というSLIMのトレードマーク「最短開発期間」の計算方法を解説する。

「ソフトウェア技術者の最高の能力は、見積もりだ！」――今回は、パラメトリックス法の1つ「SLIM」のトレードマークといえる“最短開発期間”の概要を解説する。

「ソフトウェア技術者の最高の能力は、見積もりだ！」――今回はSLIMのソフトウェア開発関係式を実際に使用し、工数（コスト）、開発期間（月）、機能総量（規模）、（プロセス）生産性の具体的な算出法（Excelによる算出）を解説する。

「ソフトウェア技術者の最高の能力は、見積もりだ！」――今回は、パラメトリックス法の1つ「SLIM」を取り上げます。上司からのムチャな開発期間の短縮要求をはねのける“究極の反撃法”が、このSLIMによる見積もりです。

「ソフトウェア技術者の最高の能力は、見積もりだ！」――今回は、計算手順が30分で理解できて、システムの分析やFP計算も1〜2時間程度で可能な「FP試算法」について説明する。

「ソフトウェア技術者の最高の能力は、見積もりだ！」――今回は、積み上げ法の中でも、少しアカデミックな雰囲気のある「FP（Function Point）」による規模見積もりについて解説。まずは、FPの概要・特長を理解しよう。

「ソフトウェア技術者の最高の能力は、見積もりだ！」――今回から世界のソフトウェア開発プロジェクトで最も頻繁に使われている積み上げ法による見積もりを紹介。まずは、規模見積もりの王様「LOC見積もり」について。

「ソフトウェア技術者の最高の能力は、見積もりだ！」――今回は、見積もりの3つの基本技法のうち「類推法」について取り上げ、その概要とメリット・デメリット、利用時の注意点について詳しく紹介する。

「ソフトウェア技術者の最高の能力は、見積もりだ！」――“見積もり”をテーマにした新シリーズ「見積もり：ソフトウェア技術者の最高の能力」の第3回。今回は、見積もり値の“3つの状態”について解説する。