オライリーのブログで英語のリスニングの練習：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
本エントリはいつものソフトウェアに関するブログエントリとは少し異なるエントリですが、海外のカンファレンスの中継や動画を字幕や通訳なしで聞きたいと思っている方は少なくないと感じているので紹介することにしました。 ブログに掲載されているエントリや一部の記事はテキスト、音声の両方が用意されています。テキストも音声も内容は同一で音声を再生すると、ブログや記事はどこを発音しているかがハイライトされたテキストでわかります。全てを調べていませんが音声は肉声ではないものがほとんどだと思います。（肉声の音声を何らかの方法でトラッキングして表示しているように解釈できる表現になっていることを指摘いただき追記しました） その様子は下の画像のような感じです。表示しているブログエントリは"The Web is eating software"で、今読んでいる文が緑色、読んでいる単語が水色で表示されます。画像ではちょう
ソフトウェア開発に対する杓子定規な考え：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
一見同じようにみえるソフトウェア開発も個々に異なっているものがほとんどでまったく同じものはなかなかないという実感をお持ちの方も多いと思います。個々に異なれば同じ方法で開発すれば期待する効果をいつも得られるというわけにはいきません。同じ方法が通用するかどうかを考えた上で方法を活用することが大切であると考えています。また、そのことがうまく伝わるためにはどのように表現すればよいかを考えています。個々に違っていることを「文脈」の意味をあらわす「コンテキスト」と呼んでいます。個々の違いを考えることの大切さを理解してもらうのに少しは寄与したのではないかと思っています。 本エントリのタイトルの「杓子定規」もうまく伝えるための表現の一つだと思っています。「杓子定規に考えず適したやり方になっているか吟味する」は何をすべきかをイメージしやすいのではないでしょうか。SDN(Software Defined Ne
ソフトウェア開発のコンテキストとは：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
ソフトウェア開発のコンテキストとは、ソフトウェア開発の置かれた状況や背景を指します。コンテキストを明確にすることにより、あるソフトウェア開発において効果が得られたことが自身の開発ではうまくいくかもしれない、あるいは、うまくいかないかもしれないといった判断を助けます。他の開発で効果のあった技術、プロセス、プラクティス、手法を取り入れたときに、コンテキストが異なっているために同じような効果が得られないということはよくあります。 講演、セミナー、勉強会でソフトウェア開発の成功事例が公開されるようになって、「お、いいな」と思うような技術、プロセス、プラクティス、手法を見聞きする機会が増えました。しかしながら、見聞きした事例の前提や制約を把握して、自身の開発でも適用可能かどうかを判断しないと期待する効果が出ないことがあります。そういった前提や制約をコンテキストと呼んでいます。たとえば、些細なバグであ
レビューでの欠陥検出シナリオ：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
ソフトウェアレビューにおいて、検出すべき欠陥を明確にした上で、欠陥検出をするとレビューアの責任分担や完了基準が明確になると考えています。これまで拙著「間違いだらけの設計レビュー」や日経SYSTEMSの連載、講演やセミナーにおいてもその話を伝えており、有効性に関して一定の反響をいただいています。また、検出すべき欠陥の見つけ方を検出シナリオとしてまとめておき、レビューの開始前に合意しておくことをお勧めしています。 検出すべき欠陥やシナリオはソフトウェアに求められる機能や提供する価値、開発チームの構成や体制にも依存するため、「どのようなソフトウェア、プロジェクトにおいてもこれを検出すればよい」というものはありません。抽象的ですが、そのソフトウェア、プロジェクトにおいてもっとも検出の価値が高いものになります。価値は得られるメリットのことで、たとえば、ソフトウェアの利用者の利便性が高まる、レビューで
25年以上かけてモデルベース開発を浸透 - マツダのSKYACTIV テクノロジーを支える：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
マツダは1980年代からモデルベースでの開発に取り組んでいるそうです。モデルベースの開発の対象はソフトウェアだけでなく、エンジンやトランスミッションを含むハードウェアです。様々なパラメータをシミュレーションによって組合せ、最適な設計を机上で得て、机上で検証することができるようになり、試作や調整の時間や手間を減らせます。 マツダでの最初のモデルベース開発は1980年代のRX7の加速時の振動を抑える点火アクティブ制御だったそうです。その後、1991年のル・マン24時間耐久レースに使ったそうです。1991年の同レースでマツダは優勝しています。最近では、エンジンでの燃焼をシミュレーションすることにより、これまでにない高圧縮比のエンジンの実用化を支援しています。 モデルベースの開発を主導する原田氏のインタビュー記事（択一の世界を変えた! 「SKYACTIV TECHNOLOGY」を支えるマツダのモデ
ソフトウェアレビューの効果を高める秘訣2つ：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
仕事柄、多くの方に「ソフトウェアレビューがうまくいかない。どうしたものか」という相談をいただきます。多くの場合、レビューの目的設定が不十分、参加者のマインドが醸成されていないことが原因になっています。 レビューの目的設定が明確にされていないことは多く、レビュー会議がはじまっていくつか欠陥が指摘されると「このレビューって結局どんな欠陥を検出すればいいんだっけ？」という状況になることは少なくありません。各々のレビューアが自身の経験に基づいて欠陥を指摘すると、必ずしも開発しているソフトウェアに求められるような（早期検出すべき）欠陥ばかりになるとは限りません。たとえば、ユーザ数が5ユーザ程度しかおらず、同時アクセスの可能性がほとんどないシステムに対して、同時アクセスやそのときの性能問題を指摘することは、必ずしも適切とは限りません。それよりも指摘すべき（優先順位の高い）欠陥があることが多いからです。
ビッグデータ時代のソフトウェアメトリクス - ソフトウェアアナリティクスとは：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
IEEE Softwareという雑誌でsoftware analyticsという分野に関する特集が組まれています。当初は1号分の特集の予定だったそうですが、2号に分けることとなったそうです。2013年7, 8月号の特集記事のタイトルは以下のとおり。ここに7, 8月号全体の目次があります。 T. Menzies, T. Zimmermann: Software Analytics: So What? R. Musson, J. Richards, D. Fisher, C. Bird, B. Bussone, S. Ganguly: Leveraging the Crowd: How 48,000 Users Helped Improve Lync Performance O. Baysal, R. Holmes, M. W. Godfrey: Developer Dashboards: T
コーディングルール違反と不具合数の関係を調べた研究：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
2008年に"Assessing the value of coding standards: An empirical study"というタイトルの論文がIEEE International Conference on Software Maintenance 2008に掲載されています。 論文のPDFはIEEEの電子図書館のページから入手できますが定期購読していたり、IEEE memberのアカウントが必要になります。本論文と同等の内容のテクニカルレポートが著者のサイトからも閲覧できます（こちら）。 MISRA Cで定義されているコーディング規約の逸脱と不具合数との関連の調査結果を報告しています。対象ソースコードは家電製品用の組込みプログラムのもの。開発中に構成管理システムに蓄積されたソースコード編集履歴からコーディング規約準拠と不具合数の関係を調べて報告しています。 MISRA Cは
汎用的な観点ではなく業務特化の観点でのレビュー実施の効果を予想した研究：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
2013/3/12に「業務観点でのレビューを目指した不具合情報の分析」というタイトルで情報処理学会ソフトウェア工学研究会で発表しました。論文PDFはこちら。（本著作物の著作権は情報処理学会に帰属します。本著作物は著作権者である情報処理学会の許可のもとに掲載するものです。ご利用に当たっては「著作権法」ならびに「情報処理学会倫理綱領」に従うことをお願いいたします。） レビューのコスト削減効果は、レビューで検出して欠陥を修正したときのコストとレビューで見逃して（あるいはレビューを実施せず）レビュー以降のフェーズで欠陥を検出し、修正したときのコストの差です。@IT情報システムマネジメントの記事「レビューを「数」だけで管理しているからコストが膨らむ」で解説しています。 レビューで検出することによってコスト削減につながる欠陥をつきつめると、どのようなものになるでしょうか。おそらく対象ソフトウェアにとっ
ソースコード変更波及解析の8カテゴリ - どのくらいご存知ですか？：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
変更波及解析は既存のソフトウェアに変更を加えたら、どの場所に影響を与えるかを調べる方法です。影響は本来の意図であるものや本来意図していない副作用も含みます。変更波及解析が不十分だとデグレードする場合があります。 Steffen Lehnert氏のA Review of Software Change Impact Analysisという文献調査をしたテクニカルレポートがここで公開されています。調査対象の文献が182件ある大きめの調査です。網羅性や調査方法に関しても客観的な基準を与え、洗練した上で論文として公開されるのかもしれません。 このテクニカルレポートで紹介されている影響波及解析のカテゴリの一覧は以下のとおりです。10カテゴリのうち9番目は組合せ、10番目は「その他」なので、実質的には8カテゴリあります。どのくらいのカテゴリをご存知ですか？ いずれも完璧とはいかないまでも、変更波及解析
コードレビューやテストの優先順位付けに統計モデルが役立つか実際に試してみた論文：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
プログラムの規模が大きくなるとソースコードレビューやシステムテストをどこからはじめてよいか優先順位が付けにくくなります。優先順位は様々です。たとえば、欠陥を見逃した場合にリスクが大きくなるところからはじめる、多くのユーザが使う基本機能の正常動作からはじめる、依存関係が多く様々な部分から参照される共通モジュールからはじめる、今後も長期にわたって保守、拡張する部分からはじめるといった方針が考えられます。もちろん、できた部分から順番にという順位付けもあるでしょう。 優先順位のつけ方の一つとして、ソースコードの特徴から不具合がありそうなクラス、モジュール、メソッド、関数を予測する技法としてFault-proneモジュール予測という技法があります。過去の不具合のデータとソースコードの特徴を表わす数値をモデルに与え、不具合が起こりやすいソースコードの特徴を学習させます。数値は関数、メソッド、クラスとい
本質的でないレビュー指摘を減らすための試行を紹介した日経ITproの記事：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
要求ドキュメントや設計ドキュメントをレビューにおいて、誤字脱字の指摘の割合が高く本質的な欠陥の指摘が少ないというのは、どのような組織、プロジェクト、チームにおいても共通の悩みでしょう。 そのようなレビューを改善することを目的として、レビューで検出すべき欠陥の条件を変えて実務者の方にご協力いただいて検出結果を比較する試行をしました。 結果は論文で報告しています（S. Morisaki Y. Kamei K. Matsumoto: Experimental Evaluation of Effect of Specifying a Focused Defect Type in Software Inspection: PDFはこちらから）。ほぼ同じ内容の記事を以前に日経SYSTEMS（雑誌）に寄稿していました。昨日Web記事として日経ITproのサイトにも掲載いただきました。こちらから読めます。
稟議書でアジャイル開発と技術的負債を説明するのに適していそうな講演資料 - IEEE Computer Society, IEEE Software主催のイベントから：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
稟議書でアジャイル開発と技術的負債を説明するのに適していそうな講演資料 - IEEE Computer Society, IEEE Software主催のイベントから IEEE Computer Society, IEEE SoftwareによるSoftware Expert Summit 2012というイベントが2012年6月26日にロンドンで開催されました。基調講演、講演、パネルディスカッションというオーソドックスな構成です。プログラムの詳細は、こちらで公開されています。 当日の資料の一部が最近公開されたようで、興味があったものの参加できなかったので資料を眺めていました。私が気になったのはアジャイル開発と技術的負債を説明する2つの講演資料でした。アジャイル開発のほうは不確定な状況への対応を中心に紹介されています。技術的負債のほうは負債によるコスト増と負債を解消するための対応コストの双方
SKYACTIVにおけるモデルベース開発の講演で感じた「納得」「信用」：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
ET West 2012で登壇の機会をいただいたので同日の基調講演を聴講しました。マツダ原田氏の「超低燃費SKYACTIVテクノロジー誕生を支えたモデルベース開発 ～複雑巨大化するモノづくりへの挑戦～ 」です。IPA ソフトウェアエンジニアリングセンターが刊行しているSEC Journalにも講演内容が掲載されています。PDFでこちら（29号を選んでください）からダウンロードできます。 PDFはET 2011の基調講演の内容だそうですが、ET West 2012の際にもポイントとなる部分は類似していました。PDFをご覧いただければ興味深い内容であることがおわかりいただけると思います。 マツダの自動車の開発ではモデルベースでの開発が浸透しており、そのきっかけは1991年のルマンという24時間耐久自動車レースでモデル、シミュレーションによる車両の設計と最良の運転方法（コース取りや加減速）にある
がんばるだけの品質向上活動からの脱却：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
役割を意識しすぎたり、自分の短期的な仕事を達成することを重視しすぎて本来の目的を見失うということは、どのような活動においても起こり得ます。ソフトウエア開発でも同様で、ユーザのために品質向上しようというきっかけではじまった内容がいつのまにか、～達成率80%を目指すだけの活動にかわっていたりします。 開発プロジェクトで、元々リスクを低減したり、残件を消化することが本来の目的であったのにも関わらず、リスク管理表やtodo管理表を更新することに腐心してしまっていることがあります。そして、ステータスがかわったかどうか、変わった理由、変わっていない理由を記録することばかりに気をとられて、本来の目的を忘れてしまっているリーダを見ることもあります。なぜステータスが期待どおりの状態にかわらないか原因を明らかにして、とれそうであれば対策をとるのが本来の目的です。 他にも、何のためにテストするかを明確にせずに「
ソフトウェアメトリクスでもっとも大事なこと：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
ソフトウェア開発において何らかの定量データを収集して、状況を推測しようとしたり問題を解決しようとしたりすることは一般的になっていると思います。データ収集の対象はコードカバレッジかもしれないですし、工程毎の欠陥除去率かもしれないですし、スプリントのベロシティかもしれません。 現時点では、計測値か計測値による意思決定の基準の両方、またはどちらかが完全には客観的にはなっていないため、計測値や基準は、あくまで目安です。これだけ計測してモニタしてさえおけば十分ということはほとんどないでしょう。 計測と計測値による判断は、何らかの望ましくない状況や望ましい状況とメトリクスをひもづけて、計測値がこうなっていたら望ましくない状況が起き始めている、望ましい状況になっているということを事前合意しようとしていることだと解釈できるでしょう。実際にはお仕着せで合意なんてしていないという話はあると思いますが、根源をた
Fault-proneモジュール予測：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
バグが含まれていそうなソースコードモジュールを予測することをfault-proneモジュール予測と呼びます。予測の単位であるモジュールはソースコードファイルであったり、メソッド、クラスであったりします。過去の傾向に照らし合わせて、予測する方法が一般的です。 たとえば、規模が大きいファイル、メソッド、クラスにバグが含まれているという傾向から予測したり、特定の（一般には複雑なロジックを持つために実現が難しい）機能を実現するソースコードという傾向から予測したりします。ここ（本ブログの過去エントリ）でも紹介しましたが、過去に何度も改変されているとバグを含む可能性が高いという経験則を使っているものもあります。改変担当者による予測もあります。 過去にバグが含まれていたモジュールとソースコードメトリクス等の特徴を統計モデル等を使って学習させ、それ以外のソースコードにバグが含まれているかどうかを学習したモ
だんだん開発作業が重くなっている？：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
ここ最近、細かいエビデンス、コンプライアンスを取っ払ったほうがいいという話やエビデンス、コンプライアンスのために負荷が高まって開発効率に影響を与えているという話を見聞きしたのでエントリにしています。私の主観によるもので全体傾向と言えるほどではないかもしれません。ガバナンス不況という指摘もかなり前からあるように思います。しかし、最近見聞きしたものは私の感触と一致する表現が多いように思いました。これが今回のエントリを書いたきっかけです。 まず見聞きした内容を私が見聞きした順番で紹介します。 1. 講演 （スクウェアエニックス社長 和田氏が中央大学で「ゲーム産業の業態変化」というタイトルで講演された内容） http://www.square-enix.com/jpn/news/speeches/20111125/page18.html 「ヴィジョンがないままに部分部分に中途半端にチャチャをいれた
目的を設定して検出のたびに確認するとレビューの結果が安定することを検証（若干堅苦しくなることも確認）：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
2011年8月に私の研究グループの論文で確かめた内容です。32人のソフトウェア開発の実務者の方に協力いただきました。5, 6人で1班を作り、全部で6班で目的設定のしかたが異なる3つのグループを作りました（1グループあたり2班）。それぞれのグループは以下のとおりです。特定の班に経験年数の高いエンジニアや相対的にスキルの高いエンジニアがかたまらないようにしました。 目的設定をしないグループ（1, 2班） レビュー開始前に目的設定をしてその目的に沿って欠陥を検出するグループ（3, 4班） 開始前に目的設定をし、欠陥を検出するたびに目的に沿っているかを確認しながら検出するグループ（5, 6班） ここでの目的設定は「どのような欠陥を検出すべきか」という欠陥種別の設定です。3～6班の目的設定はレビュー対象に合わせて各班で相談して決めていただきました。レビュー対象はWebブラウザをクライアントとする架空
バグ修正のための変更の40%が新たなバグを混入するという研究結果 - Googleのバグ予測方法との共通点：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
Googleで実施されているというバグ予測の方法がブログで公開され（こちら）、ツールも利用できるようです（こちら）。Publickeyの記事での紹介で端的に紹介されていますので、時間がない方にお勧めします。ソースコードの変更（コミット）履歴から高い頻度でバグ修正されているコードは今後もバグが出る可能性が高いというものです。 類似の研究結果がたくさん報告されているので、この分野の研究者の1人として紹介したいと思いエントリを書きました。興味のある方には本エントリ末尾に示すこの分野の論文も読んでいただきたいです。 一例として2000年にICSMで発表された以下の論文を紹介します。 Mockus A, Votta LG. Identifying reasons for software changes using historic databases. International Conferen
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
