「レビュー/インスペクション」カテゴリーの投稿 |
汎用的な観点ではなく業務特化の観点でのレビュー実施の効果を予想した研究
2013/03/21
2013/3/12に「業務観点でのレビューを目指した不具合情報の分析」というタイトルで情報処理学会ソフトウェア工学研究会で発表しました。論文PDFはこちら。（本著作物の著作権は情報処理学会に帰属します...
以前のバージョンとの整合性を確認するドキュメントレビューの方法
2013/03/01
既存バージョンのソフトウェアを拡張して新しいバージョンのソフトウェアを開発する際のソフトウェアレビューでは、レビューで確認する場所が大きく2種類あります。一つは、今回のバージョンアップで新しく追加、修...
コードレビューやテストの優先順位付けに統計モデルが役立つか実際に試してみた論文
2013/01/30
プログラムの規模が大きくなるとソースコードレビューやシステムテストをどこからはじめてよいか優先順位が付けにくくなります。優先順位は様々です。たとえば、欠陥を見逃した場合にリスクが大きくなるところからは...
過去にてこずった不具合を将来のレビューで注力して検出する手順を提案した論文
2012/08/27
類似のソフトウェアを開発するときに、過去の不具合や過去の失敗がノウハウとして役立つことがあることを感じたことがあると思います。そのことをソフトウェアレビューにおいて活かすためにシステマチックな方法を検...
本質的でないレビュー指摘を減らすための試行を紹介した日経ITproの記事
2012/08/21
要求ドキュメントや設計ドキュメントをレビューにおいて、誤字脱字の指摘の割合が高く本質的な欠陥の指摘が少ないというのは、どのような組織、プロジェクト、チームにおいても共通の悩みでしょう。 そのようなレビ...
「レビューの価値を考える」という記事をEM West vol. 2というフリーペーパに寄稿しました。2010年7月くらいです。紙の冊子で勉強会やカンファレンス等のイベントで配布されることが多かったので...
業務に特化した観点でのレビューの事例
2012/03/02
ソフトウェアレビューでは検出すべき欠陥をイメージしてから進めたほうが効率的で欠陥の検出もやりやすいと感じています。検出すべき欠陥は「性能(の欠陥・問題)」「セキュリティ」といった多くのソフトウェアにあ...
2011年8月に私の研究グループの論文で確かめた内容です。32人のソフトウェア開発の実務者の方に協力いただきました。5, 6人で1班を作り、全部で6班で目的設定のしかたが異なる3つのグループを作りまし...
「経験があればコードレビューは速くなるか？」を調査した研究結果
2011/12/12
去年の1月にソースコードリーディングワークショップというイベントを開催しました。小規模なソースコードを多くの実務者の方に読んでいただき、時間や傾向を得ようというものです。詳細は@ITの記事や本ブログの...
レビュー改善に関する産学連携の取組みで受賞
2011/12/09
ソフトウェアプロセス改善カンファレンス2011で細谷，吉岡，森崎「産学連携によるデザインレビューの改善事例」が実行委員長賞を受賞しました。発表は細谷氏（三菱電機）。アブストラクト、発表スライド、発表と...
漏れ、誤り、曖昧さを制約とする defect-based reading
2011/09/16
レビューが難しい理由の1つは自由度が高いことだと思っています。何でも自由にやれるから問題ないよねと思ってしまいがちですが、自由度が高いことは必ずしもいいことばかりではありません。本エントリのタイトルは...
Color of the bike shedと呼ばれ、議論できるメンバがたくさんいるという理由で、本質的ではない話題で盛り上がってしまい、本来の議論が十分になされない状況を指します。 元々の定義では、...
情報処理学会第170回ソフトウェア工学研究会で発表した内容。坂東祐司、森崎修司、松本健一「セキュリティ要件のレビューにおけるチェックリストの表記方法の比較」。 チェックリストに収録された質問に答えてい...
コードレビューの記事が半年で10,000回閲覧
2010/09/29
2010年2月に米国のIBM developerWorksに掲載いただいたコードレビュー記事の閲覧数が6ヶ月で10,000を超えた。こちら。現在公開から7ヶ月たって11,000になっている。元々は日本...
凡ミスが多いところに欠陥が多いという研究結果があったとしても・・・
2010/09/15
コーディングルールに従っていないステートメントの多い部分、ドキュメント中の書式に従っていないものが多い部分にはバグが潜んでいる可能性が高いという報告や研究結果がいくつか報告されている。全面的にそれを...
「レビューで一体何が指摘されるか想像もつかない」という不信感
2010/08/23
どのようなタイプの指摘がされるか予測できないレビューは、形骸化しやすく、効果もそれほど高くないことが多い。「たしかに指摘は正しいのだが、ここではそのような指摘は必要なかった」というもので、どのような形...
検出不具合数、欠陥数とうまく付き合えていますか？
2010/08/20
レビュー、テストで指摘欠陥や指摘不具合を計数することで、妥当性を推測することが多い。この指標値については議論が多い。ないと頼りにするものがなくなって困るし、あると数値が一人歩きしてしまう。受託開発で、...
「もっとも厳格なのがインスペクション」って見るけど厳格って何？
2010/08/19
レビューの書籍をみるとだいたいレビューの分類が書いてある。「ウォークスルー、レビュー、インスペクションの順で厳格になっていく」という記述を多くの方がご覧になったことがあるのではないだろうか。 厳格を具...
バグピンポン
2010/08/12
バグピンポンとは、テストエンジニアと開発者の間で発見したバグに同意がとれず、バグを指摘したメールや指摘票がいったりきたりすることを表し、卓球のボールがいったりきたりする様で比喩している。長沢氏（ブログ...
レビューでの1発目の指摘「では、私から」は結構いい結果になる
2010/06/15
ソフトウェアレビュー会議がはじまって1つ目の指摘は結構重要で、1つ目がそれに続く指摘に影響を与えることが多い。具体的な検証は十分にはできていないが、商用開発でのレビュー何件かの観察において感じている。...
レビュー成功のための進行役の6条件を@ITに寄稿した
2010/04/16
@ITに記事を寄稿した。レビューのファシリテーション役ともいえる進行役の6条件を中心に、レビューの役割と分担を紹介している。ご自身のレビューの進行状況との比較によって、よい部分や改善すべき部分等の気づ...
記事「ソフトウェアレビューの国内外の動向」で書けなかったこと
2010/04/07
日本科学技術連盟ニュース（目次のみ）に表題の記事を寄稿した。定型化、優先順位をつけるテーマ、テーラリングのテーマを紹介している。 このブログでも何度か書いているが規模の増大に伴って、網羅的なレビューが...
詰めレビュー
2010/04/02
時間制約がある中でのレビューでは指摘できるエラー数にもおのずと上限ができる。たとえば、30分で1万件の指摘はほぼ不可能だろう。また、次のような状況で、インパクトのないエラー指摘を網羅的に実施すれば、重...
2010年度の日本科学技術連盟のソフトウェア品質管理研究会に「ソフトウェアレビュー」分科会が新設される。主査は日本IBM細川氏、副査はソニー永田氏が担当する。活動のねらいや進め方など、詳細はこちら。 ...
日経SYSTEMS「設計ミスをなくそう」特集でのインタビューで思ったこと
2010/03/12
日経SYSTEMS 3月号「設計ミスをなくそう」特集でインタビューいただいた。事前に大まかな話題をいただき、「俯瞰的な話」として回答差し上げた。ソフトウェアレビューを研究テーマの1つとして進めているの...
記事はこちら。developerWorks（日本版）に寄稿した元記事（コードレビューの道具、使っていますか？）を英訳、一部変更したもの。developerWorks編集長のブログでもご紹介いただいてい...
情報処理学会のウィンターワークショップという恒例のイベントがある。2010年は倉敷で開催された。詳細はこちら。ワークショップは7つのテーマから成り、私は「ソフトウェア開発マネジメント「ソフトウェア計測...
参加者全員で同一のソースコードを読み、読み進め方を議論するワークショップ
2010/01/15
1/30(土)に東京、田町でソースコードリーディングワークショップ2010を開催する。参加者で同一のJavaソースコードを読んでいただき、参加者同士でその読解戦略の意見交換をしていただく。主旨や意義は...
「ソフトウェアレビュー 3つの課題」を寄稿した
2010/01/12
日本科学技術連盟の日科技連ニュースNo. 80（2009年12月）に寄稿した。 3つの課題としたのは以下のとおり。寄稿した記事ではもっと具体的に説明している。 コスト・リソースレビューに必要な工数・時...
レビューの優先順位を決める技法
2010/01/05
修正確認テスト（回帰テスト）の規模が大きくなりそうなところからレビューしていく、という技法の論文が掲載された。レビューで見逃した場合にテストで手こずってしまうエラーを優先的に発見するための技法だ。 我...
インスペクタビリティ - 検証容易性
2009/12/08
ソースコードや設計書等、レビュー（インスペクション）対象の読みやすさを向上する試みがある。On Inspection and Verification of Software with Timing ...
ソフトウェアレビューの読みすすめ方、方針はありますか？ @IT記事から
2009/11/20
@ITにソフトウェアレビューの読み進めかたの記事を寄稿した。型にはまっていただくのではなく、ご自身の普段のレビューを整理、明文化するために役立てていただきたいと思う。 レビューの読み進め方を決めていな...
ソースコードのコメントよりも空白行のほうが理解を助けるという研究結果
2009/11/17
IEEE Transaction on Software Engineeringの論文Raymond P.L. Buse and Westley R. Weimer: Learning a Metri...
Javaで書かれた1500行程度のGUIアプリケーションのバージョンのnを理解し、バージョンn+1との差分19種類を適用してよいかどうかを答えていただき、バージョンnを理解するための所要時間、読み方の...
「レビュー、インスペクション、ウォークスルー、どうしてますか？」と語る場
2009/10/23
講演のたびに「レビュー、インスペクション、ウォークスルー等の静的解析に関する情報共有が不十分」と言っているので、そういうことが語り合える場を作ってみることにした。某所で宮城氏にお声がけいただいたのがき...
設計の完成度をはかる 『見逃し率』 ～ 東証 清田氏の解説記事から
2009/10/16
東京証券取引所での事例を解説する記事の中で紹介されている。出典は、次のとおり。本エントリは、解説記事の一部抜粋だ。 清田 辰巳: 発注者視点からの工程別エラー管理指標の導入，SEC Journal, ...
オンラインでできるJava読解の腕試し - 連休中にいかが？
2009/10/10
スラッシュドット・ジャパン、CodeZine、developerWorksブログ等でも取り上げていただいているが、派生開発、保守開発等が増加し、ソースコード読解力はプログラマだけでなく、プロジェクトリ...
アジャイルインスペクションを体験する勉強会 参加者募集 (9/15 三田)
2009/09/03
レビュー／インスペクションの時間を短縮したいという方向け。7月にソニーの永田氏が実施されています。今回は、普段ソフトウェア設計、プログラミング、プロジェクトリーダ・マネージャをされている方向けに以下の...
What Type of Defects are Really Discovered in Code Reviews?というタイトルの論文がIEEE Transaction on Software E...
インスペクションワークショップ2009のコンテンツをまとめた
2009/08/13
ソフトウェアインスペクションワークショップ2009の事後コンテンツが増えてきているので紹介したい（順不同）。現在、Fraunhoferとともに当日のハンズオンの結果を集計・分析している。 パネルセッシ...
計画と納得
2009/07/27
計画をたててみたが合意が得られず、単なるメモ書きになってしまうことがある。計画をたてることはテクニカルな領域で解決できる場合があるが、合意はテクニカルな領域だけで解決することは難しい。 両者は一体と考...
IBMdeveloperWorksに寄稿した記事「コードレビューの道具、使っていますか？」が6/19～25のランキング1位になった。今週はそのランキングをここからみることができると思う。この記事で時間...
@IT内野氏のニュース記事で紹介いただいているが、7/2に東京田町キャンパスイノベーションセンターでソフトウェアインスペクションワークショップを実施した。日本IBM、ドイツFraunhofer IES...
『コードレビューの道具、使っていますか？』
2009/06/22
IBM developerWorksに記事を寄稿した。本エントリ公開時点で300近い「はてぶ」がついているようだ。ここから全文が読める。 developerWorksの読者層になるべく合うような話を、...
ソフトウェアインスペクションの技術者の交流と先進的技法の評価を目的としたワークショップ
2009/06/19
日本IBM、フラウンホーファ（ドイツ）、奈良先端科学技術大学院大学の共同で、ワークショップ開催のプレスリリースを発表した。文面は、http://www-06.ibm.com/jp/press/2009...
国立情報学研究所の田中先生とともにゲストエディタを務めた。以下の6論文記事から構成される（敬称略）。ここ（情報処理学会）に特集記事のタイトルが公開されている。 0. 編集にあたって （森崎修司 奈良先...
ソフトウェアレビューでは問題点の指摘だけでなくよい点も指摘したい（コストの範囲内で）
2009/05/18
国際会議、国内会議にかかわらず研究論文のレビュー（査読）書式があり、多くの書式に「積極的に評価できる点」という項目がある。査読者はここにレビュー対象の論文の評価できる点を記入する。 査読の主目的は、そ...
困った営業会議と困ったソフトウェアレビューの共通点
2009/05/14
営業さんのやる気を奪うだけで生産性の低い「困った会議」には次の5つのタイプがあるそうだ。 報告会 独演会 尋問会 恫喝会 慰め会 プレジデント3月号の記事（Webからも参照できる）による。 ソフトウェ...
ユーザがシステム開発に積極的に関与して得られることは？
2009/04/30
「ベンダは常にどう実現するかという視点で考えているが、ユーザにとっては次の点が気になる。 作られたシステムを使ってどのような付加価値をつけるか システムが人間系の中でどのように位置づけられるか 」 ユ...
ソフトウェアレビューをカスタマイズする（海外事例）
2009/04/16
今年2月にソフトウェアレビュー研究のための国際連携ワーキンググループを発足した。ワーキンググループの活動の1つ目は、レビューをカスタマイズするTAQtIC（Tailoring Approach for...
顧客に“ワォ！”という体験を提供――ザッポスに学ぶ企業文化の確立
ちょっとした対話が成長を助ける――上司と部下が話すとき互いに学び合う
悩んだときの、自己啓発書の触れ方
考えるべきは得意なものは何かではなく、お客さまが高く評価するものは何か
なんて素敵にフェイスブック
部下を叱る2つのポイント
第6回 幸せの創造こそ、ビジネスの使命