他人を巻き込む必要のある新しい施策、試みでちょっとハマってないか？と思ったときに役立ちそうな書籍：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
チェンジマネジメント 3.0 - How to Change the World（Jurgen Appelo（著）、前川哲次、川口恭伸、吉羽龍太郎（訳））は、60ページほどの書籍です。1ヶ月ほど前に献本いただき、やっと読みました。 訳者も著者もアジャイル開発で有名な方々なので、アジャイル開発を浸透させるための方法なのかなと思っていたのですが、新しいアイディアを育てたい多くの人に示唆がある内容だと感じました。アジャイルに限らず、新しい技術、技法、プラクティス、プロセスを取り入れたいと思ったときに、その技術、技法、プラクティス、プロセス自体と同じくらい知っておかなければならない情報といえそうです。ソフトウェア工学分野の産学連携の共同研究にも役立つと思います。エンジニアリングに限定されず、新しい施策や取組みでも活用できるレベルの抽象度で書かれています。 私にとって印象深かったのは以下の部分です。
1990年代に提案された「疑わしいところテスト」：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
D. Hamlet, R. Taylor: "Partition Testing Does not Inspire Confidence", IEEE Transactions on Software Engineering, vol. 16, No. 12, p. 1402-1411(1990)という論文があります。そこでランダムテストと分割テストの不具合発見率を掲載しており、結果の考察において下のような部分（原典では「ルーチン」）をテストすることを"suspicion testing"として提案しています。タイトルにあるとおり「疑わしいところテスト」と訳しておきました。よりよい訳があればコメント欄から送信していただければと思います。 開発プロジェクトの中で最も経験の少ないプログラマが書いた部分 開発や過去のリリースで不具合があった部分 レビューで欠陥が指摘され開発サイクルの終盤で変更の
Scrum Gathering Tokyoで聞く「組織としてのアジャイル」と「顧客のためのアジャイル」：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
アジャイル開発はソフトウェアに求められるものが明確でない状態で開発を開始する際に特に適しています。ウォータフォール型や計画駆動型であっても不確定要素については、先行開発や技術検証といった名目で早めに取りかかっているのではないでしょうか。 アジャイル開発には、いくつかの形態やプラクティスがありますが、大別すると「開発するメンバにとって便利・有利な形態、プラクティス」「ユーザ（ソフトウェアを使ったり、価値を享受するメンバ）にとって便利・有利な形態、プラクティス」に分けることができるでしょう。 2011/10/19（水）に開催されるイベントScrum Gathering Tokyo 2011では、開発するメンバにとってのアジャイルをKniberg氏が顧客のためのアジャイルをPatton氏が講演されるそうです。 実行委員の川口氏から紹介文をいただいたので、以下に掲載します。 スクラムという手法は、
リリース周期の短縮と固定化を耳にするようになった～ FirefoxのWebとIBM Innovate2011の講演から：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
ソフトウェアのリリース周期の短期化のトピックが前よりも増えているように思います。早くリリースすると先行者利益がある、状況の変化に強いという話は前から言われていましたが、技術的な仕組みも揃い現実のものになりつつあるのではないかと思っています。 同じような感触をもたれている方も少なくないと思います。私の場合はSalesforceの年3回のリリースを聞いたくらいから感じ始めました。ここでは詳しく書きませんので、デブサミでのSalesforceの方の講演のレポート（Enterprisezine）等をご参考にお使いください。 もう1つFirefoxのリリース周期の固定化と短縮化の話が印象に残っています。Publickeyの記事（publickey1.jpへ）で知ったのですが、Firefoxの「高速リリースサイクルに関するよくある質問」のページ（mozilla.jp）に、リリースする機能を決めてからリ
「ソフトウェア開発の技法やプラクティスが有効にはたらく前提は明らかになっていますか？」でお話したこと：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
開発技法、プロセス、プラクティスが期待通りの効果を出す場合には、何らかの前提があることがほとんどだ。 その前提と技法、プロセス、プラクティスをセットにして考えると、さらなる改善や横展開につながると考えている。私の専門分野の1つであるエンピリカルソフトウェア工学では、前提をコンテキストと呼び、その記述とともに結果や結論を述べるよう推奨されている。 コンテキストは、ある結論（たとえばある技法が非常によい効果をもたらした）に対して、その原因、前提を考えることにより明らかになる。「組込みだから」「社内システムだから」「40代男性だから」等、思いつくままに定義すると的外れになることが多い。 具体的なコンテキストを抽出するシステマチックな方法は存在しないが、たとえば、他プロジェクトへの展開や次に活かそうとしたときに、前提がそろっているかどうかを考えると、いくつかが浮かんでくるだろう。 私はコンテキスト
使おうとしているプラクティスや技法の前提は明らかになってますか？：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
"Deciding What Kind of Projects are Most Suited for Agile"（どんなプロジェクトがもっともアジャイルに向いているか）というブログエントリがあったので読んでみた。前例や実績がないもの、複雑なもの、厳しい納期があるもの、としている。多くの開発プロジェクトにあてはまるとも書いてある。エントリは@ryuzee氏のtweetで知った。 このエントリには、なぜそれらのプロジェクトが向いているかという理由までは書かれていない。しかし、理由を考えると、プロセス、技法、プラクティスの利用の前提が見えてくる。 たとえば、前例や実績がない開発では試行錯誤なしに進めることが難しい。そのため、事前調査、プロトタイピング、繰り返し型の開発等によって試行錯誤の余地を作る。実際に、はじめてのハードウェア、OS、ミドルウェア等で開発に先立って検証をすることはそれほど珍
チェックリストを使えばレビューの指摘件数増に統計的有意差があったという報告。で、チェックリストをどう使えばよいか？：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
チェックリストを使えばレビューの指摘件数増に統計的有意差があったという報告。で、チェックリストをどう使えばよいか？ 情報処理学会第170回ソフトウェア工学研究会で発表した内容。坂東祐司、森崎修司、松本健一「セキュリティ要件のレビューにおけるチェックリストの表記方法の比較」。 チェックリストに収録された質問に答えていくことにより、レビュー対象の欠陥を検出する。論文では、90名超の協力者による実験を実施し、チェックリストを使わない場合、表記方法だけが異なる2種類のチェックリストの3つのグループで、指摘の正答数、正答率を調べた。チェックリストを使わない場合と比較するとチェックリストを使用したほうが、正答数、正答率ともに向上し、統計的有意差があった、というもの。 チェックリストを使ったほうが欠陥の検出数、正答率も高くなるという結果となった。今回のチェックリストは論文のタイトルのとおり、セキュリティ
日本の事情にあわせながらアジャイルな開発 - AgileTour 2010 Osakaセッションから：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
Agile Tour 2010 Osakaに参加した。Agile Tourは世界の様々な国で開催されているカンファレンスだ。細谷氏が日本で最初のAgile Tourを大阪でやろう、と思い立ったことがきっかけだそうだ。細谷氏、前川氏をはじめスタッフの方々に感謝。XPJUG関西のウェブに会場の様子や資料、ビデオ等へのリンクが掲載されている。 基調講演は長瀬氏。日本向けのアジャイル開発の内容。「日本はウォータフォール開発を極めた。外国人向けにはエクストリーム・ウォータフォールと説明している」というのがおもしろかった。いきなりプロセスをガラッと変えるわけにはいかないので、過渡期として、日本の事情にあわせてプロセスを検討されているそうだ。たとえば、常に要求を出せる人を開発チームにおいておくことは難しいので、要求定義に該当するフェーズを作ってからイテレーションを開始する等。 私も欧米の人から「日本では
「名前の適切さは間接的に品質に影響する」という仮説：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
ソースコードの変数名、メソッド名、設計ドキュメントのサブシステム名として「こだわってつけてるなぁ」という名前は、時間をかけて作成することができた部分であり、その周辺もきちんと作りこまれている。逆に名前が安易につけられていると時間をかけられなかったことを示していて、品質に問題があるかもしれない、という仮説を考えた。 ソースコードの変数名へのこだわりというのはよく聞くが、設計時に「・・・部」というようなサブシステム名にどれくらい時間をかけてらっしゃるだろうか？名前にこだわる理由は自己満足という側面もあるだろうが、メンテナンス性に響く。また、他の開発者への誤解の可能性を少なくするだろう。 「処理部」というような名前は確かに中身を表しているが、理解容易性という点では少し疑問が残る。「処理」がシステム固有の言葉として使われていれば別だが、どのような機能であれ、何らかの処理をするからだ。ソースコードの
「コンテキストなしでソフトウェア開発を話すのは・・・」が共通認識になってほしい：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
コンテキストとは直訳すると文脈。本エントリでは開発の前提や事情を示す。結果や状況は必ず、コンテキストと対にして考える。前提や事情を示すことで、結果や状況の共通認識を得やすくすることを目指している。コンテキストの定義手順は、まだ明確化されてはいないが、何らかの結果や状況に影響を与えうる要因を挙げることからはじまる。 エンピリカルソフトウェア工学での推奨の話だが、カンファレンスや勉強会等をはじめ他組織との交流時には習慣になってほしいなぁと思う。過去のエントリ（「なぜウチではうまくいかないか？」を考える開発コンテキストの解説」）にも書いた。 勉強会等で議論していると「分かり合えるはずなのに、何か通じてない」と感じるときにはコンテキストの違いを意識してみると、うまくいくかもしれない。極端な例を挙げると超高信頼性ソフトウェアと市場投入への早さが重要なソフトウェア。前提を明示せず話を進めるとかなり食い
凡ミスが多いところに欠陥が多いという研究結果があったとしても・・・：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
コーディングルールに従っていないステートメントの多い部分、ドキュメント中の書式に従っていないものが多い部分にはバグが潜んでいる可能性が高いという報告や研究結果がいくつか報告されている。全面的にそれを支持するものではないが、たとえばこの論文では、MISRA Cによるコーディングルール違反と不具合の関係を報告している。 規模の大きいソフトウェアで、複数の担当者がいる場合、長年保守されていて、あるバージョンで特定の担当者が変更した部分がある場合に、欠陥を混入してしまうことがあるためだ。これらの欠陥は時間が足りなかったり、スキルが足りなかったりしたことを示していることが多い。それらを原因とする、より深刻な欠陥が潜んでいる場合が多いことが経験的に示されている。 だからといって、コーディングルールに従っていない部分だけをルールに従うよう書きかえたり、ドキュメントを書式に従って書き直ししたからといって、
エンピリカルとは：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
エンピリカル（empirical）って何ですか？という質問をいただくことが増えてきた。エンピリカルソフトウェア工学に関する質問に対しては「技術や手法を開発するだけでなく、実際の開発にあてはめ、技術や手法の適用効果や限界を検証すること」と回答している。 ソフトウェア工学に関わらず、エンピリカルな検証が必要なものはたくさんある。システム開発をされている方ならば一度は経験があると思うがパフォーマンスチューニングやフィールドテストはそのうちの1つだ。利用状況を想定して、システムやソフトウェアを設計するところが上述の「技術や手法の開発」にあたり、実際の環境におき、実データにあてはめてパラメータチューニングしたり模擬データで検証したりして、設計を変更するのが「実際の開発にあてはめ・・適用効果や限界を検証すること」に対応する。 身近に感じていただけたのではないだろうか。 書籍「ソフトウェア開発におけるエ
制約の設計力：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
ソフトウェア/システム/サービスを何らかの形で提供する場合、他のソフトウェア/システム/サービスとの境界を設ける必要がある。人とシステムの境界であったり、システムと他のシステムとの境界であったりする。境界は様々で、ユーザインタフェースであったり、通信プロトコルで定義されていたり、（人間系）手作業と自動化の切り分けであったり、契約文面や約款だったりする。 抽象度や方法もバラバラだが、境界には何らかの制約が含まれる。一般には制約を減らしたり、自動化部分を増やすと、ソフトウェア/システム/サービスが複雑になる。自動化のコストが高いため一部を人間系にしている、とか、本来であればより親切で直感的なユーザインタフェースにしたいが、開発コストが足りないので、人間がIDを覚えて、テンキーから入力する等だ。 「おぉ」っと唸らされるソフトウェア/システム/サービスには、境界の線引きが絶妙というものがあるように
アジャイルな開発プロセス導入にあたって検討すべきこと - Ryuzee氏の講演資料から -：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
3/19（金）のTech Fieldersセミナー「Agile Day 2 - ペアで参加し、セッションとワークショップを楽しもう！」の講演の1つに表題の講演があったそうだ。講演資料がここで公開されている。全体とりまとめをされている長沢氏のエントリにも紹介がある。IBMエバンジェリスト玉川氏、すくすくスクラムの今村氏の講演とワークショップで構成されたそうだ。 講演資料にはプロセスを変える際に検討すべきこと、準備すべきことが書かれている。これからアジャイルな開発プロセスを導入しようとする方だけでなく、アジャイルに限らず開発プロセスの変更や新しい方法を導入するとき一般にも、通用する内容というのが私の印象。 私が興味深いと思ったことは以下のとおり。 現状がうまくいかないからといって、目的を明確にせず、プロセスを変えたり、技術・技法を導入しようとしない。 導入に際して組織のトップへの働きかけと現場
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を採用されなかったと想定した場合と比較して、工数
Cisco Systemsのコードレビュー：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
通信事業者むけのハイエンド通信機器で大きなシェアを持つシスコ。高信頼、高性能のソフトウェアをどのように作っているのだろうか。"Code Review at Cisco Systems"というタイトルで、ソフトウェア開発（コードレビュー）の文書がPDFとして公開（smartbear社のWeb）されている。（smartbear社はコードレビュー支援ツールをはじめ開発環境ツールのベンダだ） 文書では2006/5から10ヶ月にわたって収集された指摘密度やレビュー速度を統計的に調べた結果が掲載されている。対象は2500回のレビューで総コード行数は320万行だそうだ。このうちの一部を抜き取って分析しているものもある。 本題のシスコでのレビューだが、以下のような手順になっているらしい。本ブログの過去のエントリでも紹介したGoogleのコードレビューとかなり近い。GoogleではMondrianだったが、
「追加開発時にデグレードが気になる」という相談：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
去年1年くらい（2007年）で昔の仕事仲間や大学のときの知人からプライベートな場で何件か相談を受けた。デグレードしないように改変したいという点で、内容はどれも似通っている（デグレードについてはここに書いた）。対象ソフトウェアも以下のようなもので似通っている。改版時に何か役立つものを知らない？という相談だ。 数年前くらいでいったん開発を終えた。 当時の担当者が異動になったりして情報が少ない。 組織として「中規模」以下に位置付けられ、ドキュメンテーションや管理等、若干緩め。ソースコードへの改変のうち、ドキュメントに記録されていないものがある。 ちょっとした機能追加をしたい、あるいは、今後の保守に備えて既知の潜在的な不具合を直しておきたい。 この状況で、抜本的、安全で低コストの手法があればいいのだが、そうそう簡単な方法はない。間接的に以下のような解決策に頼ることになるだろう。 より一層コストを積
「オブジェクト指向は「正しい」のか？」を読んで：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
gihyo.jpの中尾氏の連載記事（こちら）を読んだ。おもしろかったので紹介しつつ私の意見を書いてみようと思う。記事ではオブジェクト指向プログラミング言語がだんだんと主流となりそれを開発するための統合開発環境（IDE）がプログラマの裾野を広げたという前段があり、それがもたらしたものは何だろうと考察しながらその正しさについて述べられている。 「正しい」の客観的定義はなかなか難しいところだが、そのような議論をもとに今後を見つめなおすことは有意義だと思う。このエントリでは、元の記事の一部をエンドユーザコンピューティングの側面から切り出し考えることにする。オブジェクト指向が正しいかどうかについては本エントリには書いていないのでそこに興味のある方は元記事を参照いただきたい。 エンドユーザコンピューティングはエンドユーザが簡単にプログラミングできるようにすることを目指したものだ。システム開発に詳しくか
森崎修司の「どうやってはかるの？」 > Googleのコードレビュー : ITmedia オルタナティブ・ブログ
Googleのコードレビューのプロセス、ツールの紹介がここ（Youtube）にある。55分と長いのでなかなか全部をみる時間がなかったが、休日に時間がとれたので観た。このエントリはそのときのメモだ。 Googleのコードレビューのプロセスはオープンソースのものと似ている。オープンソースのものより若干強制力のあるプロセスとそれをサポートするツール（Mondrian）があるそうだ。ビデオでプレゼンされているのは、Guido van Rossum氏、Pythonの作者でGoogleに就職して最初の仕事がMondrianの開発だったそうだ。定着しているプロセスの実行を支援するツールは非常に頼もしいだろうなぁと思う。 詳細はビデオをみていただきたいが、プレゼンの概要は以下のとおり。 プロセスはオープンソースのレビューのやり方がベースとなっている。 （前のバージョンとの差分をMLに投げるとレビュアがその
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
