コーディングルール違反と不具合数の関係を調べた研究：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
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は
リリース周期の短縮と固定化を耳にするようになった～ FirefoxのWebとIBM Innovate2011の講演から：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
ソフトウェアのリリース周期の短期化のトピックが前よりも増えているように思います。早くリリースすると先行者利益がある、状況の変化に強いという話は前から言われていましたが、技術的な仕組みも揃い現実のものになりつつあるのではないかと思っています。 同じような感触をもたれている方も少なくないと思います。私の場合はSalesforceの年3回のリリースを聞いたくらいから感じ始めました。ここでは詳しく書きませんので、デブサミでのSalesforceの方の講演のレポート（Enterprisezine）等をご参考にお使いください。 もう1つFirefoxのリリース周期の固定化と短縮化の話が印象に残っています。Publickeyの記事（publickey1.jpへ）で知ったのですが、Firefoxの「高速リリースサイクルに関するよくある質問」のページ（mozilla.jp）に、リリースする機能を決めてからリ
ソフトウェアテストで起こる不測の事態への対応を意見交換する場：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
仕様変更、特定モジュールの実装遅延、テスト用の実機が遅れる、サーバが納品されない、外注品がスペックどおりの性能を出さない、機器不足で環境構築できない、要員が長期療養に入る等をはじめとして、テストには様々なタイプの不測の事態が起こり得る。もちろんテスト以外でも起こるがその傾向はテストでの傾向が強い。どのようなタイプの開発であれ、テストはリリース間際に実施されるからだ。 不測の事態が起こった状況で柔軟性のあるテストが実施できる場合がある。柔軟性のあるテストができる理由は、単に運がいいとか手腕があるということではなく、多面的なテスト計画やテスト分析ができているからにほかならない。テストやプロジェクトの計画を立てる段階で、単純に1つの計画を立てて終わりというわけではなく、「XがおきればYという対応」「AとBは同じ項目」「M～Pは実機での実施が前提」等、単一の計画書に記述した以上に、様々な観点での分
「ソフトウェアレビューの国内外の動向」を寄稿した：森崎修司の「どうやってはかるの？」：ITmedia オルタナティブ・ブログ
日本科学技術連盟ニュース（目次のみ）に表題の記事を寄稿した。定型化、優先順位をつけるテーマ、テーラリングのテーマを紹介している。 このブログでも何度か書いているが規模の増大に伴って、網羅的なレビューが難しいという見方は国内外ともに同じ傾向にある。そのために様々な方法が提案されている。また、レビューの形骸化や実施モチベーションの低下も国内に限った話ではない。記事では、その解決に向けた取り組みを紹介している。 記事では主だった動きを紹介したが、本エントリでは、紙面の都合上、記事には書けなかったアプローチを2つ紹介したい。網羅的なレビューが難しいという問題は、第三者レビューによってある程度解決できる。全てのプロジェクト、ソフトウェアにおいて、第三者レビューが実施できるかというと欠陥が出た場合の深刻さと対象ソフトウェア、プロジェクトのコスト吸収力に依存する。セキュリティに関する第三者レビューや第三
テスト駆動開発（TDD）の事例 - IBMとMS 計4プロジェクトを紹介した論文 -：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
*はbiac氏のご指摘により「TDD採用により増加した工数」から修正した。 欠陥密度はリリースが近いフェーズでのテストで検出された欠陥にもとづいているそうだ。 また、次のような知見が紹介されている。 途中でTDDをやめたり、途中からTDDをはじめてもうまくいかない。プロジェクトの開始時からやるべき（既存のソフトウェアの次バージョンから始める場合には言及がない） テストコードの実行速度に気を配り、速く実行できるようにする。それぞれのテストコードの実行は短くても結合すると膨大な時間になってしまう場合がある。 テストケース数、テストコードの行数、コードの行数、カバレッジ、発見されたバグと修正されたバグの数、を計測し、傾向を把握する。 開発開始、終了時には開発者の意向に耳を傾ける場を作る。今後も継続してTDDしたいかどうか。 どのプロジェクトもTDDを採用されなかったと想定した場合と比較して、工数
プログラミング言語Noopのコンセプトに「そうそう。そういうのがあってもいい」と感じる人も多いのでは？：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
プログラミング言語Noopのコンセプトに「そうそう。そういうのがあってもいい」と感じる人も多いのでは？ Alex Eagle氏、Jeremie Lenfant-Engelmann氏（2人ともGoogleの所属だそうだ）がJVM Language Summitで発表されたプログラミング言語Noopの説明をいくつか読んだ。詳細は@ITのニュース記事やpublickey新野氏の記事等を参照いただきたい。 Noopの目指すところとして、メンテナンス容易性（2人以上で開発するための言語）、テスト容易性が挙げられている。この2つをプログラミング言語に求めている開発者の層は厚いのではないかと思うが、この層の人たちがプログラミング言語を作るということはそれほど多くないように思う。通常は既存のソフトウェアの移行を考え、あきらめてしまいそうだ。。 プログラミング言語の目的、コンセプトというと思想的なぼんやりし
バイオ燃料での飛行試験を冗長化の視点で考える：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
冗長化にうるさい、ある友人との雑談で出てきた話。JALのプレスリリース（去年6月）に掲載されているが、計4基のエンジンがある飛行機で、化石燃料のエンジン3基とバイオ燃料のエンジン1基として、飛行試験をしたそうだ。私は素人なので、3基で飛べるのか等については全然わからない。ただ、4基全部をバイオ燃料にして試験するよりはリスクが低そうな気がする（4基のバランスをとるほうが難しい等、私では想像できないリスクもありそうだが。。）。 情報システムにおいても、サブシステムや同一機能の冗長化において、同じインタフェース、入出力を備えつつも、冗長化されている構成要素にヘテロなものを加える方法は取れる。1プロジェクトの設計者としては、構成要素の種類をなるべく統一してシンプルなものにしたいところだ。しかし、長期的な視点に立てば、種類の異なるものを実環境にいれておいて、比較するなどノウハウを得ることも大事だろう
「Google Readerをスピードアップさせるにはオフラインにする」をきっかけにAPIのユーザビリティを考える：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
Gearsをインストールして英語版（英語版というところが大事）のGoogle Readerで画面右上の緑のアイコンをクリックする。すると2000件を上限にローカルキャッシュにフィードの内容をダウンロードしてくれる。フィードの先まではダウンロードしてくれないが、フィードのチェックをするという目的で使えると思う。 フィードをいったんローカルキャッシュにダウンロードするので閲覧速度が速くなる。私の場合フィードは自宅で深夜にチェックするか、自席で昼食をとるときにチェックすることが多い。大学のネットワークがかなり速いので、困ってはいないのだが、ローカルキャッシュにあるほうがやはり速い。自宅だとキャッシュの威力を感じることが多い。 ローカルキャッシュの仕組みは、Gears APIが提供しているそうだ。ローカルにデータベースを持たせたりするなど、オンラインでないときでもWebを通じて提供されるサービス（
ソフトウェアレビューでは問題点の指摘だけでなくよい点も指摘したい（コストの範囲内で）：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
国際会議、国内会議にかかわらず研究論文のレビュー（査読）書式があり、多くの書式に「積極的に評価できる点」という項目がある。査読者はここにレビュー対象の論文の評価できる点を記入する。 査読の主目的は、その論文を採録とするかどうかを決めることにあるが、そうすると問題点の指摘に目が行きがちになってしまう。「積極的に評価できる点」の項目には、これを抑止する機能がある。よいものが公開されなければ、その分野全体が沈んでいってしまうからだ。 通常、著者がいない場で実施される論文の査読であっても「積極的に評価できる点」が存在する。ソフトウェアレビューは、問題点の指摘と修正が主目的の場合が多いが、レビュー対象の作成者がいる場では、できるだけ「積極的に評価できる点」も指摘すべきだと思う。 私の新人時代もレビューとなると気が重かったのだが、その理由は「これはダメ」がリスト化されるからだったように思う。「ここは伸
困った営業会議と困ったソフトウェアレビューの共通点：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
営業さんのやる気を奪うだけで生産性の低い「困った会議」には次の5つのタイプがあるそうだ。 報告会 独演会 尋問会 恫喝会 慰め会 プレジデント3月号の記事（Webからも参照できる）による。 ソフトウェアレビューの会議でも共通する部分が多い。レビューの場合、もっとバリエーションが多く、「参加してほしい者が出てこない」「何も決まっていない」「会議内容の取りこぼしがある」「効果が出ない」等、その理由はもっと幅広い。 ソフトウェアレビューでも、上述の「困った会議」と同様に目的の設定が曖昧か、設定があっても目的とズレていることが多い。目的を明確にし、効果の出るレビューにするためには、それなりの役割分担、ガイドライン、技法が必要になる。 テストとレビューの最も大きな違いは、教科書的にはプログラムが動く前でも実施できるのがレビュー、プログラムを動かしながら実施するのがテスト、ということになるだろう（私が
ワークフローがない状態でツール利用を強制されるとつらい：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
ソフトウェア開発に限らずだが、定着しているワークフローや洗練されているプロセスの実行を支援するツールは非常に便利で、利用しているとスカッとする。ワークフロー支援が無駄なくビシッと決まっている支援ツールを利用したことがあれば、感じたことがあるだろう。 逆にワークフロー、プロセスが存在しない、あるいは今一歩という状態で支援ツールが介在すると当事者はかなり面倒に感じてしまう。結果として支援ツールがいまいちという結論になってしまうことが多いが、現実には、支援ツール自体のまずさの前に支援ツールと既存のワークフロー、プロセスの不整合が原因となっている場合がある。 あるソフトウェア開発プロジェクトでの開発支援ツール導入の際に痛感したのがきっかけだが、共同研究でパイロットプロジェクト導入済の状態からより多くの関係者やプロジェクトに展開していく場合に、注意している。 とにかくツール導入だけを目的にしてしまう
ユーザがシステム開発に積極的に関与して得られることは？：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
「ベンダは常にどう実現するかという視点で考えているが、ユーザにとっては次の点が気になる。 作られたシステムを使ってどのような付加価値をつけるか システムが人間系の中でどのように位置づけられるか 」 ユーザ企業の方が書かれた記事の一部を引用したものだ。この記事の詳細はまた別の機会に紹介したいと思っている。これを読んだときに、具体例を合わせて指摘されると確かにそのとおりだと納得した。よいソフトウェアやシステムを得たいと思うならばユーザが積極的に関与することが求められるのではないだろうか。 ITmedia PlanITの以下の記事でも「全部任せちゃえばいいじゃないか」というタイトルでユーザとして何をすべきかが書かれている。記事には、ベンダの得意な点はベンダに任せることにして、ユーザにしかうまく作れない部分にもっと積極的に関与すべき、その結果、発注額も小さくなるだろうと書かれている。 記事は行政の
再々委託を禁止/許可制にするSIerが増加：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
システム開発の一部や全部を多重請負できないようにするシステムインテグレータが増えてきているそうだ。日経ITproの記事には、再々委託を禁止としている大手の社名が並ぶ。また、一律に禁止はしないものの許可なしでは再委託できないとするインテグレータも多いようだ。 一番の目的は偽装請負の防止だろう。記事にもあるように、再々委託を禁じれば即問題が解決するようなものではないが、解決にむけた第一歩にはなるだろう。 個人的には、明確な責任分解点や役割分担ができれば多重請負や分業はそれほど悪いことだとは思っていない。ただし、役割分担が明確でないために、中間搾取をするためだけの層が存在するようにみえてしまったり、責任分解点が明確でないせいで立場が弱い層だけが損をしたり、ということが起きてしまうと話は別だ。 これも個人的な感触だが、深い請負階層を作ってそれをうまく維持するためには、上位層、下位層への依存と尊敬が
日本IBMの専門家が語る『インスペクションの攻略法』：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
要件定義、設計、ソースコードの各対象でインスペクタ／レビューアは何をすればよいかを日本IBM クオリティインスペクション 部長の細川氏がこの記事で語っている。 私の印象に残った点は以下のとおり。他にも示唆が多い。 要件 『「これは要件か？」「これはプロジェクトの目標達成のために必要か？」「これが実現しなかったらどうなる？」という点を見る』 確かに。自分の経験を振り返っても、言われたとおりだが、自分で作っているとなかなかこの点にまでは目がいかない。 設計 『定量的にあらわされているか？』『"場合"と"時"というキーワードを中心に例外定義をさがしなさい』 たしかに、エラー定義を書いていくと、知らず知らずのうちに、途中で力尽きていることが多いように思う。また、定量的に設計定義をコミットすることは作る側にとってはそれなりに後ろ盾が必要だろう。 ソースコード 『ソースコードファイルの先頭からではなく
本当のことをうまく伝える：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
マスコミに属する記者の方の意見として「本当のことを言う」という記事が日経ITProにある。マスコミへの批判のこと、テレビ番組の質の低下、米国人ジャーナリストが語る本当のことを言えない環境を作ってしまうとダメになってしまうという話等があり、うなづけることが多い。詳細は記事を参照いただきたいが、（マスコミに限らず）本当のことを言い続けなければならないという前向きな話だ。いい話だと思う。 1点気になったことは、本当のことを言うことが、なんとなく辛らつに事実をつきつけることのように読み取れてしまうことだ。真実を伝えるか、そうでないかという二者択一のように読めてしまう。私は真実を伝えながらも、上手な方法でそれを伝えれば、必ずしも批判にはならないと思っている。失敗事例を蓄積して次の成功に活かしたいと思っている企業は多く、そこでは失敗を報告することにペナルティを与えない、失敗を共有できる雰囲気作りことに
ソフトウェア開発の成果物、コスト、進捗を『測る企業は成功率が2倍に』：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
表題は、日経コンピュータの2008/12の記事（最近、Webページ化された）のもの。他にも「成功の決め手は『定量管理』」がある。アンケートで回答が得られた814企業の結果にもとづく結果だそうだ。ここでの成功とは、品質、コスト、納期が計画を遵守できたことを指す。 詳細は記事を参照いただくことにして、以下のような項目が気になった。 プロジェクトの成功率は31.1%（成功の定義は前述のとおり）。5年前に実施したアンケート結果では26.7%。 品質、コスト、進捗のいずれかでも定量管理している企業では、成功率が45.6%、定量管理を一切していない企業では成功率が24.3%。 企業規模別の調査では、大企業よりも中小企業のほうが定量的管理による成功率が高くなる。 ソフトウェア開発の定量管理、計測が、ここ数年で定着しつつあるということだろう。また、定量管理、計測によって成功率がかわるという結果は、その効果
病院でのダメな提案：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
新人SEによくある失敗として、次のような条件を満たす情報を、望まれていないのに話し続けてしまうということがないだろうか。自分（新人SE）が得意とする分野、顧客にとっては（タイミング的に）必要ではなく、あまり詳しくない、興味もそれほどない情報。たとえば、まだ作るかどうかも決まっていないシステムを実装するプログラミング言語の言語仕様やライブラリが提供する機能の話を延々としてしまう等だ。「この例外処理部分やこれをオブジェクトとして扱っているところが美しいんですよ」など。短時間で終わる分にはいろいろとメリットが大きいと思うが、長く続くと困る。 今まで私にはあまり経験がなかったのだが、病院でそれに似た状況に出くわした。これをたとえ話にすると、ひょっとして新人SE向けに説明がやりやすくなるのではないかと思ったことが、エントリにしたきっかけだ。医学系の大学（院）では医療コミュニケーションといったカリキュ
派生、保守開発において 変更規模 ≒ 変更行数 か？：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
現状、多くのソフトウェア開発では母体を流用したり改変したりしている。プロダクトラインを前提とした場合や開発対象を非常に小さく保った場合でも、他プログラム、他システム、他サービスとの連携を考えないといけないだろう。 既存のものをどれくらい流用したかを示すためのメトリクスとして変更率（流用率）が使われることが多い。変更率はソースコード行数で計数されることが多く、単純に既存のソースコードの行数と変更、新規に追加したソースコード行数の比で表していることが多い。変更率によってテスト規模や不具合密度を算出して、品質の参考値にする。 ただ、上述のようなシンプルな方法で変更率をはかると、かなり複雑なソースコードの1行も、ロジックがほとんど含まれない1行も同じ規模になってしまう。実際には、変更によって増えるテストケースや変更による波及範囲なども変更規模として考慮されている必要があるだろう。 単純に行数だけで
テクニカルライティングに関する読み物：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
他人の書いたソースコードをみて学べという話はよく聞くが、他人の書いた設計書等をみながら日本語の書き方を学べ、という話はそれほど多くは聞かない。ただ、曖昧な表現をするなという話を聞いたことがない方はいらっしゃらないだろう。 ソフトウェア開発に限定されないが、技術文書を書くことはテクニカルライティングと呼ばれている。テクニカルライティングでは、事実を読者にわかりやすく伝えることに主眼がおかれている。事実を淡々と書くというと一見簡単そうだが、実際には曖昧さ、モレがないドキュメントを書くのは難しい。意図せず、読者を誤解させるような文章を書いた経験は誰にでもあるだろう。 このエントリではテクニカルライティングに参考になる読み物があるので紹介する。昨年の6月からgihyo.jpではじまった松下 健次郎氏の「Webゆえに考える テキスト編集のテクニカルコンセプト」の連載だ。いくつかは、Webサイトの文書
三菱東京UFJのシステム統合完了の話題は少ないようだが。。：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
日経ITproでいくつか記事になっている（こことかここ）が、もう少し取り上げられてもよいように思う。どの部分が特に成功し、それはなぜだったかという話も含め、今後もっと取り上げてほしい。まずは、成功を褒めるところからだがそれに続いてプロジェクトで実施、検討した方法の効果と限界について業界で共有できるような形で公開していただけないものかと思っている。その情報は、存在自体が強い刺激にもなるし、他のプロジェクトでも効果がでれば大きな発展につながるだろう。 たとえば、ITmediaエグゼクティブの2008年2月時点の記事には三菱東京UFJ銀行執行役員システム部長の根本武彦氏が「不良摘出件数が少ないものは、本当に品質が良いのかどうかは分からないので、追加テストなどで徹底的に不良を見つけ出した」と仰っている内容が掲載されている。日経ITProでも「世界最大のプロジェクトをこう見積った」というタイトルでJ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
