山浦恒央の“くみこみ”な話

ECサイトを題材にソフトウェア開発の全工程を学ぶ新シリーズ「イチから全部作ってみよう」がスタート。シリーズ第15回は、ここまで作成してきた要求仕様書に対するテストの第1段階となる「セルフチェック」について説明する。

ECサイトを題材にソフトウェア開発の全工程を学ぶ新シリーズ「イチから全部作ってみよう」がスタート。シリーズ第14回は、第12回と第13回で検討した異常系を、第11回で作成したたこ焼き屋の模擬店の要求仕様書に組み込んでみる。

ECサイトを題材にソフトウェア開発の全工程を学ぶ新シリーズ「イチから全部作ってみよう」がスタート。シリーズ第13回は、たこ焼き屋模擬店の要求仕様書から洗い出した異常系にどのような対策を行うべきかを考察する。

ECサイトを題材にソフトウェア開発の全工程を学ぶ新シリーズ「イチから全部作ってみよう」がスタート。シリーズ第12回は、これまでに作成したたこ焼き屋模擬店の要求仕様書における異常系の洗い出しを行う。

ECサイトを題材にソフトウェア開発の全工程を学ぶ新シリーズ「イチから全部作ってみよう」がスタート。シリーズ第11回は、前回「機能分割」を用いて作成したたこ焼き屋の模擬店をの要求仕様書を抜け漏れのないようにブラッシュアップする。

ECサイトを題材にソフトウェア開発の全工程を学ぶ新シリーズ「イチから全部作ってみよう」がスタート。シリーズ第10回は、要求仕様書の作成に役立つ「機能分割」について、トヨタの組織と高校のたこ焼き屋の模擬店を例に解説する。

ECサイトを題材にソフトウェア開発の全工程を学ぶ新シリーズ「イチから全部作ってみよう」がスタート。シリーズ第9回は、「ヒアリング」した内容をまとめる「要求仕様書作成」について、情報工学専攻の大学3年生でも悩む「ジャンケンの要求仕様書」を例にその難しさを解説します。

ECサイトを題材にソフトウェア開発の全工程を学ぶ新シリーズ「イチから全部作ってみよう」がスタート。シリーズ第8回は、正しい要求仕様書に向けた第一歩となる「ヒアリング」について具体的な例題を使って解説します。

ECサイトを題材にソフトウェア開発の全工程を学ぶ新シリーズ「イチから全部作ってみよう」がスタート。シリーズ第7回は、要求仕様フェーズで作り上げる正しい要求仕様書に向けた第一歩となる「ヒアリング」について解説します。

ECサイトを題材にソフトウェア開発の全工程を学ぶ新シリーズ「イチから全部作ってみよう」がスタート。シリーズ第6回は、開発方法の整備やスパイラルモデルなど、前回に続きさまざまな問題がある要求仕様フェーズの対処法について解説します。

ECサイトを題材にソフトウェア開発の全工程を学ぶ新シリーズ「イチから全部作ってみよう」がスタート。シリーズ第5回は、さまざまな問題がある要求仕様フェーズの対処法について解説します。

ECサイトを題材にソフトウェア開発の全工程を学ぶ新シリーズ「イチから全部作ってみよう」がスタート。シリーズ第4回は、前回に引き続き、要求仕様フェーズの問題点を解説します。

ECサイトを題材にソフトウェア開発の全工程を学ぶ新シリーズ「イチから全部作ってみよう」がスタート。シリーズ第3回は、ソフトウェア開発における全ての悪を生み出す元凶、要求仕様フェーズの問題点を解説します。

ECサイトを題材にソフトウェア開発の全工程を学ぶシリーズ「イチから全部作ってみよう」。第2回は準備編として、開発対象となるワイン販売用のECサイトのイメージを深める。

ECサイトを題材にソフトウェア開発の全工程を学ぶ新シリーズ「イチから全部作ってみよう」がスタート。シリーズ第1回は、イントロダクションとしてソフトウェア開発の大まかな流れを説明する。

ソフトウェア開発にとどまらない、PCを使う全ての人が対象となるシリーズ「業務効率化の道具箱」。第16回は、これまで取り上げてこなかった「働き方を工夫する」をテーマに、困った上司の作業指示にどう対応していくかを考える。

ソフトウェア開発にとどまらない、PCを使う全ての人が対象となるシリーズ「業務効率化の道具箱」。第15回は、10人程度の小さな小売店で行った「自分でツールを作る」による業務効率化のケーススタディーを紹介する。

ソフトウェア開発にとどまらない、PCを使う全ての人が対象となるシリーズ「業務効率化の道具箱」。第14回は、前回に続き、ツールの導入／運用時にありがちな「地雷」をケーススタディー形式で紹介する。

ソフトウェア開発にとどまらない、PCを使う全ての人が対象となるシリーズ「業務効率化の道具箱」。第13回は、ツールの導入／運用時にありがちな「地雷」をケーススタディー形式で紹介する。

ソフトウェア開発にとどまらない、PCを使う全ての人が対象となるシリーズ「業務効率化の道具箱」。第12回は、Windowsであれば面倒な環境構築なしで使えるVBSのプログラム記述方法を紹介する。

ソフトウェア開発にとどまらない、PCを使う全ての人が対象となるシリーズ「業務効率化の道具箱」。第11回は、VBAによる自動集計アプリのさらなる進化版として、データを転記し、グラフ描画を行うツールを作ってみる。

ソフトウェア開発にとどまらない、PCを使う全ての人が対象となるシリーズ「業務効率化の道具箱」。第10回は、第9回で紹介したVBAによる自動集計アプリのバージョンアップ版を作ってみる。

ソフトウェア開発にとどまらない、PCを使う全ての人が対象となるシリーズ「業務効率化の道具箱」。第9回は、VBAによる自作ツール作成の例として自動集計アプリを作ってみる。

ソフトウェア開発にとどまらない、PCを使う全ての人が対象となるシリーズ「業務効率化の道具箱」。第8回は、自作ツール作成の第一歩としてVBAを紹介する。

ソフトウェア開発にとどまらない、PCを使う全ての人が対象となるシリーズ「業務効率化の道具箱」。第7回は、ターミナルソフトである「RLogin」の導入方法や使い方を紹介する。

ソフトウェア開発にとどまらない、PCを使う全ての人が対象となるシリーズ「業務効率化の道具箱」。第6回は、前回導入した「Google Test」の使い方と、「アサーション」「パス・カバレッジ」によるテストの方法を紹介する。

ソフトウェア開発にとどまらない、PCを使う全ての人が対象となるシリーズ「業務効率化の道具箱」。第5回は、単体テストで役立つフリーのツールである「Google Test」と「gcov／lcov」を紹介する。

ソフトウェア開発にとどまらない、PCを使う全ての人が対象となるシリーズ「業務効率化の道具箱」。第4回は、仮想化ソフトウェアの「VirtualBox」を使って、Windows PC上にLinuxのUbuntuの環境を構築する方法を紹介する。

ソフトウェア開発にとどまらない、PCを使う全ての人が対象となるシリーズ「業務効率化の道具箱」。第3回は、第2回に続きショートカットキーを紹介する。塵も積もれば山となる方式で得られる「技術の複利効果」により、急激に作業効率が上がり、同時にミスも減らせるはずだ。

ソフトウェア開発にとどまらない、PCを使う全ての人が対象となるシリーズ「業務効率化の道具箱」。第2回は“塵も積もれば山になる”の効果を実感できるショートカットキーを紹介する。

今回から新シリーズ「業務効率化の道具箱」がスタート。ソフトウェア開発にとどまらない、PCを使う全ての人が対象となる。シリーズ第1回はイントロダクション編として、業務を効率化する方法にどのようなものがあるのかを提示する。

提示された仕様とプログラム（バグを含む）から、自身の手でテストケースを設計し、バグを実際に見つけ、バグレポートまでを作成する実践的なシリーズ「テストでバグ発見！」。今回は、前回出題した扇風機シミュレーターの機能追加開発におけるバグ検出についての解答編だ。

提示された仕様とプログラム（バグを含む）から、自身の手でテストケースを設計し、バグを実際に見つけ、バグレポートまでを作成する実践的なシリーズ「テストでバグ発見！」。今回は、これまで題材にしてきた扇風機シミュレーターに対して保守開発を本格的に適用した問題の出題編となる。

提示された仕様とプログラム（バグを含む）から、自身の手でテストケースを設計し、バグを実際に見つけ、バグレポートまでを作成する実践的なシリーズ「テストでバグ発見！」。今回は、前回までの題材だった扇風機シミュレーターを使って、状態遷移図への機能追加を行う。その勘所は「混ぜるな、危険！」だ。

提示された仕様とプログラム（バグを含む）から、自身の手でテストケースを設計し、バグを実際に見つけ、バグレポートまでを作成する実践的なシリーズ「テストでバグ発見！」。今回は、扇風機シミュレーターをテーマとする問題の解答編。状態遷移モデルをベースにしたデバッグに取り組もう。

提示された仕様とプログラム（バグを含む）から、自身の手でテストケースを設計し、バグを実際に見つけ、バグレポートまでを作成する実践的なシリーズ「テストでバグ発見！」。今回は、扇風機シミュレーターをテーマとする問題の出題編。状態遷移モデルをベースにしたデバッグに取り組もう。

提示された仕様とプログラム（バグを含む）から、自身の手でテストケースを設計し、バグを実際に見つけ、バグレポートまでを作成する実践的なシリーズ「テストでバグ発見！」。今回は、前回出題した電卓プログラム問題の解答編だ。演習問題としては大規模だが、正面からじっくり向き合い、適切にテスト設計すればバグを検出できるはず！

提示された仕様とプログラム（バグを含む）から、自身の手でテストケースを設計し、バグを実際に見つけ、バグレポートまでを作成する実践的なシリーズ「テストでバグ発見！」。今回は電卓プログラムをテーマとする問題の出題編。かなりのステップ数になる電卓プログラムに潜むバグを見つけ出そう。

提示された仕様とプログラム（バグを含む）から、自身の手でテストケースを設計し、バグを実際に見つけ、バグレポートまでを作成する実践的なシリーズ「テストでバグ発見！」。第4回は、多くの読者が中学校の数学で学んであろう、2次方程式の解を求める「解の公式」のプログラムに潜むバグを見つけ出そう。

提示された仕様とプログラム（バグを含む）から、自身の手でテストケースを設計し、バグを実際に見つけ、バグレポートまでを作成する実践的なシリーズ「テストでバグ発見！」。第3回は、大学の単位取得を判定するプログラムから、ファイル入力に潜むバグを見つけ出しましょう。

提示された仕様とプログラム（バグを含む）から、自身の手でテストケースを設計し、バグを実際に見つけ、バグレポートまでを作成する実践的なシリーズ「テストでバグ発見！」。第2回は、自動販売機シミュレーターのプログラムからバグを見つけ出しましょう。

今回から、提示された仕様とプログラム（バグを含む）から、自身の手でテストケースを設計し、バグを実際に見つけ、バグレポートまでを作成する実践的なシリーズ「テストでバグ発見！」が始まります。第1回は、チュートリアルとして成人判定プログラムからバグを発見してみましょう。

ソフトウェア技術者に向けて、バグに関する基礎知識をまとめていく新シリーズ「バグ百科事典」。第21回は、シリーズの総まとめとして、バグの検出から修正までの「バグ特定手順」の一連の流れを解説します。

ソフトウェア技術者に向けて、バグに関する基礎知識をまとめていく新シリーズ「バグ百科事典」。第20回は、「IT業界のサグラダファミリア」と呼ばれたみずほ銀行の事例に代表されるシステム刷新のバグを紹介します。

ソフトウェア技術者に向けて、バグに関する基礎知識をまとめていく新シリーズ「バグ百科事典」。第19回は、複雑怪奇になりがちな通信系プログラムのバグを紹介します。

ソフトウェア技術者に向けて、バグに関する基礎知識をまとめていく新シリーズ「バグ百科事典」。第18回は、開発工数の半分を占めるテストのバグのケーススタディーを紹介します。

ソフトウェア技術者に向けて、バグに関する基礎知識をまとめていく新シリーズ「バグ百科事典」。第17回は、第14回でテーマにしたコーディングのバグを再び取り上げます。無限ループやbreak抜けなどまだまだあります！

ソフトウェア技術者に向けて、バグに関する基礎知識をまとめていく新シリーズ「バグ百科事典」。第16回は、誰もが経験する「勘違い」に起因するバグを取り上げます。たかが勘違いといっても大事件につながる可能性もあるので要注意！

ソフトウェア技術者に向けて、バグに関する基礎知識をまとめていく新シリーズ「バグ百科事典」。第15回は、ソフトウェア開発で最も大きくて深刻な問題が発生する原因であり、エンジニアには厳しい試練となる、仕様変更で発生するバグを取り上げます。

ソフトウェア技術者に向けて、バグに関する基礎知識をまとめていく新シリーズ「バグ百科事典」。第14回は、プログラマーの花形的なプロセスであるコーディングのバグを取り上げます。

ソフトウェア技術者に向けて、バグに関する基礎知識をまとめていく新シリーズ「バグ百科事典」。第13回は、「デバッガの使用方法」と「ビルド構成に関するバグ」を取り上げます。

ソフトウェア技術者に向けて、バグに関する基礎知識をまとめていく新シリーズ「バグ百科事典」。第12回は、開発のデスマーチを呼び起こしかねない、処理時間のバグを取り上げます。

ソフトウェア技術者に向けて、バグに関する基礎知識をまとめていく新シリーズ「バグ百科事典」。第11回は、意外と奥が深い、数値演算のバグを取り上げます。

ソフトウェア技術者に向けて、バグに関する基礎知識をまとめていく新シリーズ「バグ百科事典」。第10回は、デバッグの強力な手掛かりとなる「ログ」にまつわるバグを取り上げます。

ソフトウェア技術者に向けて、バグに関する基礎知識をまとめていく新シリーズ「バグ百科事典」。第9回は、常連バグの代表格である、境界値に関する仕様の不良や勘違いのバグ「境界値のバグ」を取り上げます。

ソフトウェア技術者に向けて、バグに関する基礎知識をまとめていく新シリーズ「バグ百科事典」。第7回は、プログラムのバグを見つける作業である「テスト」がテーマです。テストの作業次第では逆にバグを作り込むこともあり、「テストのテストのテスト」のように無限ループに陥りかねません。

ソフトウェア技術者に向けて、バグに関する基礎知識をまとめていく新シリーズ「バグ百科事典」。第7回は、ソフトウェアのライフサイクルで最も重要な要求仕様に焦点を当てます。要求仕様書をしっかり作成しないと、その後のフェーズでさまざまな問題が発生し、プロジェクトの進行に大きく影響するのです。

ソフトウェア技術者に向けて、バグに関する基礎知識をまとめていく新シリーズ「バグ百科事典」。第6回は、ソフトウェア開発業務の中で圧倒的に大きな比率を占める「文書作成」における間違い、「文書作成のバグ」を取り上げます。プログラムの動作には影響しませんが、その文書を読んだユーザーに不信感を与えかねない危険なバグなのです。

ソフトウェア技術者に向けて、バグに関する基礎知識をまとめていく新シリーズ「バグ百科事典」。第5回は、学生のプログラミング作成を事例に「実装抜け」のバグを取り上げます。学生の事例ですが、プロも意外とやりがちなので気を付けておきましょう。

ソフトウェア技術者に向けて、バグに関する基礎知識をまとめていく新シリーズ「バグ百科事典」。第4回は、前回に続き「データ入力ミスのバグ」について解説します。Excelのように日頃使う開発ツールもバグの原因になり得るのです。

ソフトウェア技術者に向けて、バグに関する基礎知識をまとめていく新シリーズ「バグ百科事典」。第3回は、ある意味プログラマーにとって理不尽で、意外に厄介でもある「データ入力ミスのバグ」について解説します。

ソフトウェア技術者に向けて、バグに関する基礎知識をまとめていく新シリーズ「バグ百科事典」が始まります。第2回は、前回に続き「うるう年バグ」について解説します。

ソフトウェア技術者に向けて、バグに関する基礎知識をまとめていく新シリーズ「バグ百科事典」が始まります。記念すべき第1回は、超常連バグである「うるう年バグ」を取り上げます。

バグは至るところに、しかも堂々と潜んでおり、自信満々なプログラマーほど、目の前のバグに気付かないものです。「バグ検出ドリル」の第20回と第21回は、「三角形を判定」するプログラムのテスト項目設計がテーマです。前回の出題編から、今回は解答編になります。

バグは至るところに、しかも堂々と潜んでおり、自信満々なプログラマーほど、目の前のバグに気付かないものです。「バグ検出ドリル」の第20回と第21回は、「三角形を判定」するプログラムのテスト項目設計がテーマです。まずは今回の出題編を読んで、じっくり問題に取り組んでみてください。

バグは至るところに、しかも堂々と潜んでおり、自信満々なプログラマーほど、目の前のバグに気付かないものです。「バグ検出ドリル」の第19回の問題は、商品と個数から合計金額を求めるプログラムのバグです。なぜか1円だけ合わない、このバグの原因を突き止めよう！

バグは至るところに、しかも堂々と潜んでおり、自信満々なプログラマーほど、目の前のバグに気付かないものです。「バグ検出ドリル」の第18回の問題は、相互に通信する機器のソフトウェアのバグです。IoT時代を迎えて利用場面が増えている、通信系のバグを見つけ出しましょう！

バグは至るところに、しかも堂々と潜んでおり、自信満々なプログラマーほど、目の前のバグに気付かないものです。「バグ検出ドリル」の第17回の問題は、前回と同じ音楽プレーヤーのプログラムから出題します。「よくある単純なバグ」が潜んでいますが、見つけ出せますか？

バグは至るところに、しかも堂々と潜んでおり、自信満々なプログラマーほど、目の前のバグに気付かないものです。「バグ検出ドリル」の第16回の問題は「簡単なバグなのに、なかなか見つからない」バグです。何で見つからないんだ！

バグは至るところに、しかも堂々と潜んでおり、自信満々なプログラマーほど、目の前のバグに気付かないものです。「バグ検出ドリル」の第15回の問題は、「思った通りに動いてくれないプログラム」のバグです。少しはプログラマーに忖度してくれよ！

バグは至るところに、しかも堂々と潜んでおり、自信満々なプログラマーほど、目の前のバグに気付かないものです。「バグ検出ドリル」の第14回の問題は、前回に続いて「煮詰まったバグ」です。煮詰まっているがゆえに、バグの原因が分からなくなる事態に対処してください！

バグは至るところに、しかも堂々と潜んでおり、自信満々なプログラマーほど、目の前のバグに気付かないものです。「バグ検出ドリル」の第13回の問題は、筆者の経験を基にして作った「煮詰まったバグ」です。プログラムが思い通りに動かず「のたうち回る地獄」のような状況に対処してください！

バグは至るところに、しかも堂々と潜んでおり、自信満々なプログラマーほど、目の前のバグに気付かないものです。「バグ検出ドリル」の第12回は、前回に引き続き「コンパイルエラー」がテーマです。コンパイルエラーにはならないのに、うまく動かないプログラムのバグを見つけ出してください！

バグは至るところに、しかも堂々と潜んでおり、自信満々なプログラマーほど、目の前のバグに気付かないものです。「バグ検出ドリル」の第11回では、初心者が苦労する「コンパイルエラー」がテーマです。コンパイラが指し示すエラーの箇所から、バグを見つけ出してください！

バグは至るところに、しかも堂々と潜んでおり、自信満々なプログラマーほど、目の前のバグに気付かないものです。「バグ検出ドリル」の第10回では、生命力最強という“昔のバグ”がテーマです。前回の第9回で扱った迷路探索プログラムの改造版からバグを見つけ出してください！

バグは至るところに、しかも堂々と潜んでおり、自信満々なプログラマーほど、目の前のバグに気付かないものです。「バグ検出ドリル」の第9回では、比較的大きなソースコードである迷路探索プログラムに潜むバグを見つけ出してください！

学生プログラミングの課題となるような小さいプログラムでもバグが潜んでいます。「バグ検出ドリル」の第8回では、学生が5分で書けるような電卓プログラムに潜むバグを見つけ出してください！

重要顧客の前でデモを行う際にバグが発生すると大変です。顧客だけでなく、自社の社長まで同席していたいたときなどは、さらにものすごく焦るのではないでしょうか。「バグ検出ドリル」の第7回では、そんな状況を想定しつつ、いろんなところに潜むバグを見つけ出してください！

「バグ検出ドリル」の第6回で出題するのは「2分探索法」の問題です。ソフトウェア技術者の誰もが心得ておくべき常識的なアルゴリズムである2分探索法ですが、今回の問題では、いろんなところにバグがあります。問題文から、どこにバグがありそうか見つけ出してみよう！

「バグ検出ドリル」の第5回で出題するのは「思い込み」にまつわるバグの問題です。タイトルの「小さな親切、大きなお世話」とは一体何なのでしょうか。問題文から、どこにバグがありそうか見つけ出してみよう！

「バグ検出ドリル」の第4回で出題するのは、プログラミングの素質を試すのに最適といわれる伝説の「FizzBuzz問題」。問題文から、どこにバグがありそうか見つけ出してみよう！

「バグ検出ドリル」の第3回で出題するのは、前回に引き続き数学に関係する問題。理系とはいえ必ずしも数学が得意ではないプログラマーですが、やはり数学を知るメリットは絶大。これまでと比べてかなり歯ごたえ十分な問題を用意したので、じっくり取り組んで数学に対する免疫力をつけてみよう！

「バグ検出ドリル」の第2回で出題するのは数学に関係する問題。理系なので数学が得意と思われがちなプログラマーですが、実はそれほどでもなかったりするのだとか……。数学的な技術を身に付けて、よりレベルの高いエンジニアを目指そう！

記念すべき連載第100回を突破した「山浦恒央の“くみこみ”な話」。今回の第101回からは、新シリーズ「バグ検出ドリル」が始まります。山浦氏が出題する問題に取り組んで、バグを見つけ出す力を養おう！

ついに連載第100回を迎えた「山浦恒央の“くみこみ”な話」。今回の「タダでソフト開発の生産性と品質を上げる方法」の第10回では、プログラムの実行速度を瞬時に測定する「gprof」を紹介します。

「タダでソフト開発の生産性と品質を上げる方法」の第9回。前回紹介した「Valgrind」を用いた具体的なメモリリークの検出方法について解説します。

「タダでソフト開発の生産性と品質を上げる方法」の第8回。今回は、ソフトウェアエンジニアを悩ませる常習的なバグ「メモリリーク」を簡単に検出できる「Valgrind」を紹介します。

MONOist開設10周年に合わせて、MONOistで記事を執筆していただいている方々からの特別寄稿を掲載していきます。第1弾は、間もなく連載100回を迎える「“くみこみ”な話」を執筆していただいている山浦恒央氏の寄稿です。

「タダでソフト開発の生産性と品質を上げる方法」の第7回。グーグル（Google）製の単体テストフレームワーク「GoogleTest」の高度な機能のうち、今回は「パスカバレッジ」を取り上げます。

「タダでソフト開発の生産性と品質を上げる方法」の第6回。前回紹介したグーグル（Google）製の単体テストフレームワーク「GoogleTest」には高度な機能がありますが、今回は「アサーションマクロ」と「テストフィクスチャの使い方」を取り上げます。

「タダでソフト開発の生産性と品質を上げる方法」の第5回。今回は、IT業界の巨人、グーグル（Google）製の単体テストフレームワーク「GoogleTest」を紹介する。

「タダでソフト開発の生産性と品質を上げる方法」の第4回。今回は、単体テストで威力を発揮する「MinUnit」を紹介する。

「タダでソフト開発の生産性と品質を上げる方法」の第3回。今回は、前回紹介した無料の組合せテスト自動生成ツール「PictMaster」を使いこなす応用編だ。

「タダでソフト開発の生産性と品質を上げる方法」の第2回。今回は、ソースコードを簡単に分析し、計測するフリーの組合せテスト自動生成ツール「SourceMonitor」を紹介します。

「“くみこみ”な話」の新シリーズが開幕。テーマは「タダでソフト開発の生産性と品質を上げる方法」です。第1回は、ソースコードを簡単に分析し、計測するフリーツール「SourceMonitor」を紹介します。

「制御パステスト」をテーマとする「猫でも分かるソフトウェアのテスト網羅」シリーズの第7回（最終回）では、前回に引き続き、パス・カバレッジの王者である「C2カバレッジ」の弱点を解説します。

「制御パステスト」をテーマとする「猫でも分かるソフトウェアのテスト網羅」シリーズの第6回では、前回に引き続き「C2カバレッジ」を取り上げます。パス・カバレッジの王者ともいわれる「C2カバレッジ」ですが弱点がないわけではありません。

「制御パステスト」をテーマとする「猫でも分かるソフトウェアのテスト網羅」シリーズの第5回では「C2カバレッジ」を取り上げます。C1より網羅性が高いので、高信頼性を求めるソフトウェア開発の管理者や発注者に好まれますが、実際にテストを行うプログラマにとってエベレスト登山並みの大変さになる可能性もあるので注意が必要です。

ソフトウェアにおけるホワイトボックス・テストの代表格がパス網羅です。パス網羅にもいろいろありますが、条件文の結果が「真」「偽」になる両方をテストする「C1」が広く利用されます。今回はC1パス・カバレッジの長所と短所を確認します。

組み込み開発の大規模化により、プログラムテストの重要性が高まっています。パス網羅をベースにする単体テストは困難な作業ではありませんが、ツールを導入することで効率化できます。今回はGcovを用いたテスト手法を紹介します。

趣味ならとにかく、ビジネスとしてのプログラミングに「網羅的なテスト」は欠かせません。網羅的なテストの代表的な手法である「制御パス・テスト」の手法について、解説していきます。

ソフトウェアのバグが全て取れたか？は開発における最大の関心事でしょう。網羅的テストはもちろんですが、その前に単体テストが必要です。代表的な手法である「制御パス・テスト」の基礎を紹介していきます。

「回帰分析」は統計分析の有力な手法であり、Excelさえあれば5分で統計的に根拠のある数字を出せます。今回はExcelのツールを使って簡単に残存バグ数を予測する方法を解説します。

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

「統計分析」と聞くと面倒な感じですが、何を証明するか明確なら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つの状態”について解説する。

「ソフトウェア技術者の最高の能力は、見積もりだ！」――“見積もり”をテーマにした新シリーズ「見積もり：ソフトウェア技術者の最高の能力」の第2回。今回は、過去30年以上ほとんど進歩していない、“今でも使える”見積もり技法について紹介。