既存コードにテストコードを書くなら、どこから始めるのが効率的か？：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
"Prioritizing Unit Test Creation for Test-Driven Maintenance of Legacy Systems"というタイトルの論文。10th International Conference on Quality SoftwareでEmad Shihab, Zhen Ming Jiang, Bram Adams, Ahmed E. Hassan , Robert Bowermanにより発表された論文の内容。以前に意見交換したときにShihab氏に教えてもらったのだが、発表が済み、公開されたのでエントリにした。 論文のPDFがここで公開されている。 テストコードがない既存のソースコードにテストコードを追加する際に、どこからテストコードを書いていくのが効率的かを長期にわたってメンテナンスされている商用ソフトウェアを対象としてシミュレーションしてい
「いつでもリリースできることはとても価値があるんだよ」：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
私が学生のころ、現MIT Sloanのマイケルクスマノ教授を駅まで車で送っているときに聞いた内容。最近になって再び強く感じ始めたのでエントリにした。クスマノ氏はソフトウェアと経済について様々な調査研究をしている。 当時の学生の私に「開発を続けながらも、いつでもリリースできる状態にあるソフトウェアは、そうでないソフトウェアと比較してビジネス面で非常に優れているんだよ」と説明してくださった。最近、アジャイル開発の話を耳にするようになって、再びこの説明を思い出した。リリース時期を柔軟にコントロールできれば、必ずしも開発プロセスは限定されないのだが、アジャイル開発のメリットとして触れられたものは少ないように思う。 いつでもリリースできることは、リリースの時期を早める（あるいは遅くする）ことによって何らかの利益を生む市場において価値がある。他社より先に市場投入して、先行メリットを享受したり、投入時期
TDD(テスト駆動開発)の適用評価を紹介した研究論文 - エリクソンはじめ3社：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
ここ（本ブログの過去エントリ）で、IBMとMSでのTDD(Test Driven Development)の適用評価事例を報告する論文を紹介した。TDDの適用評価は他にもあり、ここで紹介するのも、そのうちの1つ。 Boby George, a and Laurie Williams: A structured experiment of test-driven development, Journal of Information and Software Technology Vol. 46, No. 5, p. 337-342(2004) 論文では、24人の実務経験者を対象にテスト駆動開発をした場合としなかった場合（設計→実装→テスト）の比較をしている。報告されている主な知見は以下のとおり。 TDDを実施した場合に機能テスト（ブラックボックス）で不具合を検出するテーストケース数が削減さ
テスト駆動開発（TDD）の事例 - IBMとMS 計4プロジェクトを紹介した論文 -：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
*はbiac氏のご指摘により「TDD採用により増加した工数」から修正した。 欠陥密度はリリースが近いフェーズでのテストで検出された欠陥にもとづいているそうだ。 また、次のような知見が紹介されている。 途中でTDDをやめたり、途中からTDDをはじめてもうまくいかない。プロジェクトの開始時からやるべき（既存のソフトウェアの次バージョンから始める場合には言及がない） テストコードの実行速度に気を配り、速く実行できるようにする。それぞれのテストコードの実行は短くても結合すると膨大な時間になってしまう場合がある。 テストケース数、テストコードの行数、コードの行数、カバレッジ、発見されたバグと修正されたバグの数、を計測し、傾向を把握する。 開発開始、終了時には開発者の意向に耳を傾ける場を作る。今後も継続してTDDしたいかどうか。 どのプロジェクトもTDDを採用されなかったと想定した場合と比較して、工数
会社の垣根を越えて交流できるソフトウェアレビュー技術者の集い（7/2午後）：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
実際に手を動かしながらソフトウェアレビューをし、実感して得られたことを会社の垣根を越えてグループでディスカッションする。グループ毎のディスカッションの内容を受けて、参加者全員でパネルディスカッションを通じて明日に活かせる内容を考える。 そのような交流の場（ソフトウェアインスペクションワークショップ2009）を7/2(木) 13:30～ 東京三田で企画している。日本IBMでクオリティインスペクション活動を進められている細川氏からも講演いただく。 ワークショップの詳細はこちらから。参加は無料だが、人数把握のため事前登録制としている。主催はワーキングループ（Working Group of International Research Cooperation on Software Inspections）、共催はFraunhofer Institute for Experimental Sof
三菱東京UFJのシステム統合での取組みの成功事例を今後も公開してほしい：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
ピーク時6000人、11万人月のプロジェクト。ITmedia エグゼクティブで、三菱東京UFJのシステム統合プロジェクトでの取組みが紹介されている。前半と後半の2回に分かれている。 ここ（本ブログの過去エントリ）でも書いたが、まずは称賛、評価されるべき点を積極的に評価すべきだと思う。また、すぐには難しいだろうが、うまくいった原因やどのあたりがうまくいったかも共有していくべきだと思う。海外への発信も視野にいれていただきたいと思う。失敗をあげつらう記事が多いなか、ITmediaが統合プロジェクトを取り上げていることをうれしく思った。 上述の記事の中で、私が興味をもったのは次の項目。 利用するOS、ミドルウェアの開発者がプロジェクトに参加 プロジェクト推進と検証のPMOを設置し、相互にチェックできるような体制 Risk breakdown structureを用いた、リスクと対策のチーム間での共
甘くない砂糖の研究開発：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
研究開発は投資の1つであり、不況といわれている中でもマイクロソフトの『「不景気でも研究開発に投資」とMicrosoft幹部（ITmediaエンタープライズ）』やジュニパーネットワークスの『研究開発費は不景気でも何としても維持する（@IT記事）』をはじめとして、投資の意欲がアナウンスされている。これらの企業は、景気の状況に合わせて研究開発を縮小することは企業自体の縮小均衡のはじまりと位置づけていると解釈することもできそうだ。 私も普段研究開発を進めていたり、進めようとしている方々を支援する立場にある。研究開発には資金が必要で、資金を途絶えさせないことの重要性は常々感じている。これに加えて、研究開発に対して短期の投資回収の成果を求めすぎないことも重要だと考えている。中間的な成果は確認すべきだと思う。 前にどこかのテレビで紹介されたと思うが化学系の企業の研究開発部門（甘味料も研究開発の対象の1つ
大規模ソースコードを読み進めるときに使うツール：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
レッドハットのコンサルタントが使っている、未知の大規模なソースコードを読み進めるときに使うツールの紹介と読み進め方のコツが紹介された記事（ThinkIT記事）がある。 レビュー時の欠陥の指摘や不具合原因の特定等、既存のソースコードを読んでいかなければならないときに使う。そのような場合には、一般には、ソースコードファイルの1行目から順番に読み進めるのではなく、欠陥や不具合に関係する部分の制御フロー（あるいはデータフロー）に従ってソースコードを読んでいくことになるだろう。 対象ソースコードの規模が大きくなると、読んでいるうちに何をしているのかが不明確になったり、さっきまで読んでいたコードの一部を忘れてしまって再度読み直すことになった経験は誰にでも一度はあるだろう。大規模なソースコードを読み進めていくためには、頭の中での記憶だけでは限界があり、メモをとるなりしながら読み進める必要がある。 記事で
開発プロセスで定義されてないから検証してはいけない？：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
昔の同僚やその友人などの間で意見が割れて、盛り上がった話。あまり使ったことがないサブシステム（ハードウェア、ミドルウェア、DB）を使った開発の場合、限界性能での挙動、エラー処理、ダウンの仕方、復帰方法等がわからなければ、うまく設計ができない場合がある。そういう場合に、早い段階で事前入手の算段を整え、早い段階で検証できるようにするのが普通だと思っていた。ひょっとすると、自分たちが意図する用途では使いものにならないかもしれないのでその確認もできるし、それを踏まえてテストを設計すればよりよいものになるだろう。 検証の際に、必要であれば簡単なプログラムを作ることもある。スタブやドライバと呼ぶようなものもあれば、負荷をかけるためのツールのときもある。その場にいた人たちの間では、このような作業を含めて設計と呼ぶと思っている人が半分ちょっとくらい。私はこっち派だった。しかも、私は誰でもやっていると思って
テクニカルライティングに関する読み物：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
他人の書いたソースコードをみて学べという話はよく聞くが、他人の書いた設計書等をみながら日本語の書き方を学べ、という話はそれほど多くは聞かない。ただ、曖昧な表現をするなという話を聞いたことがない方はいらっしゃらないだろう。 ソフトウェア開発に限定されないが、技術文書を書くことはテクニカルライティングと呼ばれている。テクニカルライティングでは、事実を読者にわかりやすく伝えることに主眼がおかれている。事実を淡々と書くというと一見簡単そうだが、実際には曖昧さ、モレがないドキュメントを書くのは難しい。意図せず、読者を誤解させるような文章を書いた経験は誰にでもあるだろう。 このエントリではテクニカルライティングに参考になる読み物があるので紹介する。昨年の6月からgihyo.jpではじまった松下 健次郎氏の「Webゆえに考える テキスト編集のテクニカルコンセプト」の連載だ。いくつかは、Webサイトの文書
パフォーマンスベース契約の事例は増えるか？：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
去年4月に経産省から「情報システムのパフォーマンスベース契約に関する研究」という報告書が公開された。情報システムが生み出す価値やベンダが提供するサービスに対する価値で値付けする方法や事例が報告されている。開発や運用に必要となるリソースの積上げ（人月単価）による値付けを行う商習慣は情報システム開発、運用分野の成長を阻んでいるものの1つとの指摘を受けてのものだそうだ。 報告書には作成時に既に存在していた事例がいくつか紹介されている。この報告書をベースに実際に契約したという話が出てきてもよいように思う。報告自体は早くても来年度以降になりそうだが。 報告書の事例にあるとおり、SLA(Service Level Agreement)にもとづき、約束が守れなかった場合に払い戻しをする等のペナルティ型の課金を契約に盛り込んでいる事例は多く存在する。このパターンは合意が得やすいことのあらわれなのかもしれな
リファクタリングとは？ - リファクタリングのジレンマ -：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
プログラムの機能やふるまいをかえずに、読みやすくしたり、共通化部分を集約したり、修正が容易になるようにソフトウェアを変更することをリファクタリングと呼びます。拡張、改変に伴う改版（リリース）を多く重ねたソフトウェアには避けて通れない作業です。 リファクタリングには、ソフトウェアを理解しやすくしたり、保守に伴う改変、確認作業が減ったりするメリットがありますが、リファクタリングによる欠陥混入が絶対起きないともいえません。共通化してはいけない部分を誤って共通化してしまったり、改変時に欠陥を混入してしまうからです。これがリファクタリングのジレンマです。 ソースコードのレベルでは、プログラムが意図どおり実行されることを確認するためのテスト用プログラムを書き、リファクタリングの前後でテスト用プログラムの実行結果がかわらないことを確認することでデグレードをある程度防ぐことができます（テスト用プログラムに
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
