インスペクション特集 第4週のまとめ

あまりお目にかかれない、ソフトウェアレビュー、インスペクションの特集がThinkITで3月いっぱい続く。
第4週目をまとめてみた。

一言ずつ私の感触を書いてみると。。

インスペクション特集 第3週のまとめ

あまりお目にかかれない、ソフトウェアレビュー、インスペクションの特集がThinkITで3月いっぱい続く。
第3週目をまとめてみた。

一言ずつ私の感触を書いてみると。。

インスペクション特集 第2週のまとめ

あまりお目にかかれない、ソフトウェアレビュー、インスペクションの特集がThinkITで3月いっぱい続く。
第2週目をまとめてみた。

一言ずつ私の感触を書いてみると。。

インスペクション／レビューでの指摘例、指摘記録の例を紹介している。アドホックリーディングと呼ばれるベーシックなレビュー、チェックリストを使ったレビューの記録テンプレートをExcelのファイルとして公開している。

レビューのカイゼン方法をデンソークリエイトが語る。いつのまにか「よいレビューをする」ことが「指摘件数の帳尻あわせをしている」につながっているという問題意識からはじまり、レビューの効率化とは何か、なりたい姿をモデル化する方法を紹介している。実際にレビューに携わっている人ならば「あるある」とうなづける内容だ。

測定とインスペクションの関係を紹介している。測定が難しい品質をどうやって計測するか？直接測りにくい品質指標を何をもって計測すべきかを日本IBMのインスペクションチームでの活動をふまえて、紹介している。日本IBMのインスペクションチームでの、目的指向の計測が紹介されている。品質を測定する際のコツやエンピリカルアプローチへの言及もある。

レッドハットのコンサルタントが語る、ソースコードの読み方。コードを読み進めていく上で、どのような点に配慮しながら読めばよいかを紹介している。また、筆者が使っているオープンソースの読解ツール（わかったことをメモしていくツール）の使い方を紹介している。Emacs上で動くオープンソースの読解ツールだ。

東芝でのソフトウェアレビュー教育を踏まえた、レビューを実施する前に気をつけておくべき点を紹介している。「作成者ではなく成果物のレビューである」という基本。レビューミーティング中の発言の例も紹介されており「…のところは〜の理由で方針に従っていないと思います」といった望ましい指摘方法が書かれている。

あまりお目にかかれない、ソフトウェアレビュー、インスペクションの特集がThinkITで3月いっぱい続く。
第2週目をまとめてみた。

一言ずつ私の感触を書いてみると。。

インスペクション／レビューでの指摘例、指摘記録の例を紹介している。アドホックリーディングと呼ばれるベーシックなレビュー、チェックリストを使ったレビューの記録テンプレートをExcelのファイルとして公開している。

レビューのカイゼン方法をデンソークリエイトが語る。いつのまにか「よいレビューをする」ことが「指摘件数の帳尻あわせをしている」につながっているという問題意識からはじまり、レビューの効率化とは何か、なりたい姿をモデル化する方法を紹介している。実際にレビューに携わっている人ならば「あるある」とうなづける内容だ。

測定とインスペクションの関係を紹介している。測定が難しい品質をどうやって計測するか？直接測りにくい品質指標を何をもって計測すべきかを日本IBMのインスペクションチームでの活動をふまえて、紹介している。日本IBMのインスペクションチームでの、目的指向の計測が紹介されている。品質を測定する際のコツやエンピリカルアプローチへの言及もある。

レッドハットのコンサルタントが語る、ソースコードの読み方。コードを読み進めていく上で、どのような点に配慮しながら読めばよいかを紹介している。また、筆者が使っているオープンソースの読解ツール（わかったことをメモしていくツール）の使い方を紹介している。Emacs上で動くオープンソースの読解ツールだ。

東芝でのソフトウェアレビュー教育を踏まえた、レビューを実施する前に気をつけておくべき点を紹介している。「作成者ではなく成果物のレビューである」という基本。レビューミーティング中の発言の例も紹介されており「…のところは〜の理由で方針に従っていないと思います」といった望ましい指摘方法が書かれている。

ソフトウェアレビュー、インスペクションの特集（おそらく日本初、ひょっとすると世界初）

あまりお目にかかれない、ソフトウェアレビュー、インスペクションの特集がThinkITで3月いっぱい続く。

レビュー、インスペクション好きにはたまらない企画だろう。私は月曜日を担当している。かなり基礎的なことから最後は海外事例を紹介するまで、一気に駆け上がっていく感じだ。

今週の内容は以下のとおり。特集の名前は「インスペクションの世界」特集の企画段階から声をかけていただいたので、「森崎 修司 プレゼンツ」となっている。こんなところにそんな風に名前をいれてもらえるなんて。。ちょっと恥ずかしいような、うれしいような。

一言ずつ私の感触を書いてみると。。

なぜ、インスペクション／レビューが必要か、まだやったことがないという方むけに準備や実際の指摘方法、実施形態についても書いた。レビュー・ウォークスルー・インスペクション等の名称を若干整理し、今回の特集への意気込みを書いた。

ソフトウェア品質シンポジウム2008のFuture Award受賞者が語る「レビューの質と価値を定量化する」試み。エクセルのシートをダウンロードできる。レビューの価値を予防した修正規模ではかっているのが特徴的。レビューの価値が最後に金額で出てくるのが生々しくてよい。

IBMの第三者インスペクションのトップによる第三者インスペクションの概説。特に従来のインスペクションの問題点とその解決策が述べてある。こまめにインスペクションすることによる欠陥予防効果。

レッドハットのコンサルタントによる「ソースコードをみれば原因がわかる」という大胆なタイトル。ソースコードが閲覧できるかどうかによって変化する「やる気」のグラフ化。ソースコードをダウンロードするためのWebサーバへのリンクがある。

ソフトウェア品質シンポジウム委員長/東芝ソフトウェア技術センターで培った知見から「レビューをやる前にやっておかなければならないこと」認知的不協和、レビューの効果としてのリスク管理、文化伝播、どんなレビューからはじめたらよいか、が書かれている。

アジャイルインスペクション

本エントリはオルタナティブブログの2008/9/8で公開したものを一部改変したものである。

                                                          • -

インスペクション、レビューの大家Tom Gilb氏による基調講演"Agile Inspections: reviews by sampling and measuring defects"を、9/4, 5に東洋大で開催されたソフトウェア品質シンポジウム2008で聞いた。詳細はSQiPコミュニティのWebページの「SQiPシンポジウム」をご覧いただきたい。

通常、インスペクションの目的はドキュメントやソースコード等の（中間）成果物を精査することにより、テストよりも早い段階（プログラムが動きはじめる前）で欠陥や矛盾をみつけることにある。一般には早い段階でみつけられた不具合のほうが修正にかかるコストが低いといわれており、工期の短縮やコスト低減につながる。

アジャイルインスペクションの目的は、インスペクションの目的である欠陥の早期発見とは異なり、サンプリングによる品質推定にあるそうだ。ドキュメントやコードの一部をインスペクションし、その一部に含まれる欠陥を計測することで、全体の品質を推測する。その際、欠陥をいくつかに分類する。計測対象はmajor defectという分類で、プログラムの不具合の原因となり得るものである。単純な誤字脱字などはmajor defectに入らない。

また、出荷時の品質を"exit level"とし、要求仕様1ページあたり1件のmajor defectをexit levelを参考値として説明されていた。また、曖昧な要求仕様を書くことを防ぐためにGilb氏が推進しているplanguageについても言及があり、これによりexit levelを高めることができることを事例を用いて説明されていた。

講演を聞く限りでは、"1ページ"、"1件"、"major defect"とかなり曖昧なので計測方法によっては結果が大きく異なってしまいそうな気がした。また、要求仕様1ページあたりで1件の欠陥は実感としてなんとも大きな値のような気がする。ここでの要求仕様は要求の中でも比較的設計よりのドキュメントではないかと推測している。おそらく外部設計のほうが適切なのではないかと思っている（講演や講演資料には"requirements"とある）。

プロジェクトの早い段階で品質が推測できれば、プロジェクトのスコープ変更やスケジュール変更ができる。早い段階で多くの欠陥をみつけるのと同じくらい価値があるだろう。

他人に指摘されるより自ら省みることを助けてくれるツールが欲しい

本エントリはオルタナティブブログの2008/9/4で公開したものを改変したものである。

                                                          • -

ソフトウェア開発に携わり、周りから職人と称される複数のエンジニア、自身の技術をとても大切にしている複数のエンジニアから聞いた話。それなりにニーズがあるのではないかと思う。「誰かに見せる前に何らかのソフトウェアを使うことにより、誰かに指摘される前に一通り自分でチェックをしておきたい」と思うエンジニアは多いようだ。

ソースコードを例に挙げると、gccでもコンパイルオプションを与えれば使っていない変数や初期化を忘れている可能性のある変数、条件分岐で通ることのないパスの指摘ができる。コードレビューを実施する前や単体テストに入る前などに実行して、自身のソースコードの不備を把握し必要であれば修正することができる。FindBugsのように典型的なパターンをもとに、不具合の可能性のある箇所を指摘するソフトウェアもある。

これらのツールは、他人に見せる前に自分でチェックするという以外にも多くの人の手間を省いたり、事前合意につながるという意味で非常にメリットが大きい。ソフトウェアに限らず、職人と言われる人の製品、成果物、作品は細部に至るまでかなりのこだわりがみえることが多いように思う。他の人の力を借りながらだと過度のこだわりは難しいが、ツールの力を借りている分には、（コストが許す範囲で）こだわることができる。そのこだわりは職人を育てているものの1つだと思う。

ツールが自分を育ててくれると考えるならば、ツールをこれまでとは違う視点でみることができるように思う。

Agile contract(アジャイル　コントラクト)に関する2件の講演のまとめ

本エントリはオルタナティブブログの2007/6/13, 2008/3/13で公開したものである。

                                                          • -

□ ICSE2007での講演 by Mary Poppendieck

ICSE2007のセッションの1つで、agile contractsの例としてトヨタとサプライヤの良好な関係について語られていた。トヨタがbest contractorとして挙げられ、サプライヤとのwin-winの関係を築いていること、信頼を基本とした共通のゴールをサプライヤと作れているところ、契約を必要以上に細かく作りこんだり、責任を必要以上に細かく分類していくことは所詮ゲームに過ぎないということを認識しているところ、において優れていると述べられていた。スピーカはMary Poppendieck氏。

セッションの内容は、国際会議にしてはちょっとローカル（米国）色が濃い感じが否めなかったが、母国である日本のもの（トヨタ）が褒められるのは気持ちがよかった。

業界の方の講演を聞き比べるとわかるが、トヨタに限らず自動車関連の組込みソフトウェアの開発は、製造業の組込みソフトウェア開発やエンタープライズ系ソフトウェア開発とは大きく異なる。たとえば、ソースコードの著作権の扱いやサプライヤがグローバルな市場に向いている点にも現れており、win-winの関係はここでもうまく醸成されているように思う。

□ 発注側にコミットメントを持たせよう by 鶴保氏

第16回エンピリカルソフトウェア工学研究会でIPAソフトウェアエンジニアリングセンタの鶴保所長の講演を聴いた。トピックの1つは、ソフトウェア開発の契約方式やプロセスとしてアジャイルコントラクト、アジャイル開発を導入すべきという話だった。イテレーション開発やアジャイル開発のように発注側がコミットメントをもって開発に参加していくことが重要というものだった。ソフトウェアエンジニアリングセンタのメルマガの第20号に書かれたそうなので、詳細は参照いただければと思う。

アジャイルコントラクト自体はソフトウェア開発用に特化した契約方式ではなく、開発プロセスとしてアジャイル開発を強制するものでもない。アジャイルコントラクトは、一般的な請負契約のように発注時に要件、条件、成果物のすべてを決定してから開始するのではなく、受注者、発注者の両者が信頼感をもって臨み、一部を開発中に決めていく契約方式の呼称である。

鶴保氏の講演を拝聴して思ったのだがアジャイルコントラクトに何らかの（比較的計測がラクで客観性のある）メトリクスを導入することでアジャイルコントラクトの問題の一部を解決できるのではないかと思った。ちょうど、ここに書いた、AppExchangeがアプリケーションプログラム自体と単体テストコードを預ける際に単体テストコードのテストカバレッジに条件を持たせるようなイメージだ。カバレッジだけではテストの妥当性ははかれないが、妥当性の一部をはかることはできる。同様にソフトウェア開発のアジャイルコントラクトにも何らかのメトリクスを導入することにより、導入が進むのではないだろうか。

スコープや成果物を決めないイテレーション開発やアジャイル開発が持つ問題点は、発注、請負の両方の立場に、高いモチベーションと高いモラルが必要になることだと私は考える。「これを作っている」「ここで働ける」というような特別な気持ちを維持できる理由が必要な場合が多いように思う。また、双方に信頼感がなければ、そもそもアジャイルコントラクト自体が成立しない可能性が高い。高い生産性を維持するために、信頼感を持つことやモチベーションを高く保つ努力をしていることが多いように感じるが、私は必ずしもすべてのソフトウェア開発においてそのようなモチベーション、モラル、信頼感を期待できるわけではないと思っている。それを補完するためのある程度の取り決めとして、メトリクスが貢献できるのではないかと思う。