こちら そこそこページビューを稼いでいるようだ。レビューへの関心の高さを示しているのかも。
普段あまり共有されていないソフトウェアレビューやインスペクションの事例。
各社のいろんな事例がみれておもしろい。
私のもある。今週は以下のとおり。これから3月いっぱい続く。
環境に配慮しながら開発したソフトウェアはそうでないソフトウェアと比較して、評価されるべきではないかと思う。
環境に配慮したソフトウェアというのはどういうものかをブレークダウンする必要があると思い、スライドにしてみた。
詳細はこちらへ
要求仕様や設計書作成のメトリクスとしては、要求仕様や設計書のページ数とレビューの指摘密度やチェックリスト密度が代表的なようでこれらをみることは多い。
UMLなどの形式的手法に沿って作られていれば、ユースケースポイントやクラス図から定義済みクラス数や定義済みメソッド数を取得することができる。シーケンスダイアグラムやアクティビティダイアグラムからも同様のメトリクスを取得することができる。EPM Pro*での「コーディングからテストへの移行直前にソースコードの行数が増減していれば、そこにリスクの可能性がある」というような観察と同様に、設計がほぼ終了しつつあるときに定義済みクラスの増減があれば、リスクの観察ができるだろう。
要求定義や設計フェーズに計測したほうがよいものがあるかと質問されることがあるが、まずは計測の目的を伺ったり、計測の結果得ようとしていることを聞くようにしている。目的はいくつかのパターンに分類できるが、プロセス変更の結果を定量的に示したかったり、リスク予測をしたかったり、問題点の発見をしたいというのが代表的だ。
追加のメトリクスとして収集したものがよいものはあるか？と聞かれることがあるが、以下の4つ候補として答えることにしている。自動計測が難しいので、もちろん目的が合致していて、コストがみあっていることが前提なのだが。
今年もフランクリンコヴィーの手帳にすることに。去年までは1日見開き2ページだったが、今年は軽量化を目指し1日1ページに。4000円した。。
左側の写真が1日1ページ版。1日2ページ版と比較すると
右側の写真が無印良品のバインダ。安いけどしっかりしているし、フランクリンのコンパクトサイズにぴったり合う。インデックスが若干はみ出てしまうのだが。。
バインダは相変わらず無印良品のバインダで1000円くらいのヤツ。軽いながらもすっぽりはまるので気に入っている。手帳は通勤電車の中で仕事が始まる前と終わった後に必ずみているので、左手で持てて、右手でペンが持てるのが要件。軽いほうがありがたいのでこれがうれしい。
高いとなぜか重くなるように思うが、そんなもんだろうか。
おととい、本屋で発見した。IPAから出ているこの本のpp. 176-180。自分の写真が出ていたので、急に立ち読みしていることが恥ずかしくなってしまった。
民間企業に勤めていたときに、先輩から「B2Bは特にだけど、きらいなヤツからはどんなにいいものでも買わないのが顧客が多い。そういう意味では好かれる人をみつけるためにいろんな客にあたるというのも1つの手だ」という話を聞いたのを久々に思い出した。
「遅れているソフトウェア開発プロジェクトに開発メンバを追加すると、開発スケジュールがさらに遅れる。」というのが最も有名な法則であり、「The Mythical Man-Month」という本に記述されている。それほど簡単には説明できないだろうが、大まかな説明はこうだ。n人のプログラマで作業を分割すると作業消化についてO(n)の効果が出るが、コミュニケーションパスはn X (n-1)/2 となりO(n²)の複雑さと脆弱性が増え、結果としてメンバ追加によるプラスの効果を得ることができない、というものだ。O(n)は計算量のオーダで使われるているものであり、nの入力に対し、結果がどのくらいの割合で増えていくかを示している。たとえば、O(n)はnに比例して大きくなることを示し、O(n²)はnの2乗に比例して大きくなることを示す。
コミュニケーションパスがn X (n -1) / 2のペースで増えるかどうかという点については議論の余地があるが、メンバ追加時の経験を思い出すと、なんとなく「引継ぎ、（更新されていない）ドキュメントの説明、状況の説明」というコミュニケーションオーバヘッドが思い当たるのではないだろうか。有名な法則ではあるが、これ自身が意識されていなかったり、管理者層への説明の簡便さから「プロジェクトが遅れはじめているから人員増強だ」というのはよくある話だろう。
プロセス定義やドキュメントの整備が当時よりも進んでいると思われる現在においても、このは成り立つのだろうか。エンピリカルソフトウェア工学の研究者として実際に計測することは興味深いことの1つである。もともと1970年代に言われたことである。遅れていないプロジェクトについてはどうか、作業別に人員追加をやってみるとどうか、というあたりがわかれば、計画時に役立つのではないだろうか。
字面としてわかることと経験として理解できることにギャップがある事柄がある。たとえば数式による定義は比較的字面としてわかるほうに分類されるだろう。また、自動車の運転のしかたを字面で理解したからといってすぐに車が運転できるわけではないだろう。前者はギャップがない例、後者はギャップがある例としてあげている。特にいろいろと経験を積み上げている方に対して、後者を前者と同様に考えることは大変失礼な行為と考える。そういう失礼のないよう心がけていきたいと思う。
IESEのメンバとも話になったが、ソフトウェア開発での意思決定の透明性は重要であり、エンピリカルな手法が意思決定の透明性をあげることに寄与すると考えている。
たとえば、人による見積り値を出した後に見積りモデルでの妥当性確認をしたり（NEEDLE）、類似バグの確認を「うーん」と考えるだけでなく、クローン分析によって対象ソースコードを検索する、というのは「おそらく類似バグはないだろう」という意思決定の透明性をあげているように思う。「いろいろ思い出してみた」というよりは透明性があがっているのではないだろうか。
ここしばらくの私のテーマは透明性をあげる、という方向で考えていきたいと思った。
海外に行っていたため、携帯電話の時計を現地時間にセットしておいた。普段は携帯を目覚まし代わりにつかっているので、日本時間に戻すのを忘れていたため、起きれなかった。タクシーと余分なチケット代という対価におわる．．授業料か．．
熟練PMが見積っても見積り精度が低いプロジェクト（見積りが難しいプロジェクト）は、予測モデルを使っても見積り精度が低いプロジェクトか調べたくなった。PMがコミットした見積りが精度が最も高くなるという現実があったり、見積りモデルの予測精度が低い場合でも、予測モデルの見積り結果をうまく利用できるように思う。
大胆な名前だ。
http://services.google.com/websiteoptimizer/
夏休みまっただなかだが、仕事面のミッションステートメントを書いて記録することにした。
ソフトウェア開発に関しては、自身の経験をもとに、社会に還元できるようなものを追及することを最重要視したい。あとは、過度に成果中心型にならないこと（企業でいえば適正利潤か）、問題をきちんと理解することだろうか。研究のブルーオーシャンを追求することはすなわち社会への還元になると考えているのでブルーオーシャン分野での提案もミッションステートメントの中に含めるべきではないかとも思う。
某氏と研究テーマのblue oceanについて話をした。すごいすごいと聞いていたが、やはり楽しかった。
かなり意見があっていて、びっくりした。考えてる人は考えているもんだ。
個人的にはred oceanでのテーマとblue oceanでのテーマのバランスは必要だと思う。
コミュニティセッションでコミュニティ紹介とパネルセッションでパネリストとして登壇した。
面と向かってネガティブな話はしないだろうが、よかったという声が聞けてうれしかった。
パネルできちんと話せてるのかなぁと思っているときに、何度もうなずいてくださる方が何人かいらっしゃって勇気づけられた。もう少し準備に時間をとれたらいろいろとおもしろい話ができたんだろうなぁと思う。
発表２つだったので、準備がたいへんだった。発表後の質問をいろいろともらった。実用に近いネタということもあり、興味をもらえたように思う。今回は今までで参加が最も多かったのではないかと思う。20脚ほど椅子を追加したそうだ。
コードクローン分析によって類似バグを発見するという試みをある企業と共同で進めている。比較的よい結果が出てきているようだ。これを使って来週のエンピリカルソフトウェア工学研究会で発表する予定。少し楽しみになってきた。
magi/NEEDLEの説明会を大阪千里中央にあるエンピリカルソフトウェア工学ラボで実施した．NEEDLE担当で話をした．
ソフトウェアシンポジウム2007に参加し，ワークショップ内で招待発表という位置づけでNEEDLEの話をした．時間の都合で全部は参加できなかったがいろいろと有益な話を聞くことができ，いくつかお役に立てるかもしれない話をできたように思う．たとえば，開発で保守や機能拡張を続けていくと一般にはソースコードは複雑になる．いつかは再設計をしなければならないが，そのコストをあらかじめ積んでおかなければ再設計のタイミングは後ろへ後ろへとずらされていく．そこで，減価償却のように新規に作成した時点で再設計までのカウントダウンをはじめ，その期間内でその部分を再設計できるようなコストを蓄積できるようにする，という話である．開発時に収集するメトリクス項目についても定期的に見直しが必要ではないかという話に発展した．
満席で、キャンセル待ちができていた。
展示場（ブース）も借りていたのだが、こちらもかなりの方に足を運んでいただいた。
ありがたい話だと思う。
6/6 10:30～12:00の枠をいただき講演することになった．予約は満席になった様子だけど，当日席が空いていれば入れるらしい．無料講演なので，当日空いているのではないかと思っている．
プログラム
来年の手帳はフランクリンプランナに決定。
今年はそこそこ集中してがんばることができたので、来年は優先度をもっと意識したいと思う。
外部発表等の成果はまだ揃っていないが、エンピリカルソフトウェア工学をよりエンピリカルにできたと思う。
WIDE研究会に参加した。実証的な（リアルフィールドでの適用実験）研究紹介をみて、自分ももっと実証的にがんばらなければと思った。個人的には実証的な研究にはかがやきを感じる。
ここ1年で一緒に仕事をした外部の方で2人すごい人がいる。
細かいお願いをしなくてもよい結果が得られる、40代というのが共通点のように思う。
内部の方は皆優秀なので、ここで1人ずつ言及するのはちょっとたいへんなので、また今度の機会にしたいと思う。
久々にgoogle analyticsをみてみた。同じブログの記事を複数のブログサービスに書いてヒット率をみてみたら、so-net blog > hatena > livedoorという順番だった。記事内容等諸条件があるので、必ずしもいつもあてはまるものではないと思うが、同じものを書いても読んでもらえるものが異なるんだなぁと思った。
ついでにここのアクセスログを少しみてみた。多くはコメントSPAMのPOST，検索エンジンやRSS読取りなどのcrawlerだった。grep -vとかしながら、それらを除くとソフトウェア開発を生業とする企業からのアクセスが多い。大学関係はあまりない．．気を取り直して、企業からのアクセスがあることはうれしいことだなぁとみていると、とあるソフトウェア開発事業を持つ国内大手企業（3社程度）からのアクセスが突出して多い。ありがたい話だがなんだろうかと見てみると、referrerに社内ポータルらしきものがあった。思い切って全てをよい方向に判断すると、ソフトウェア工学の研究者として、ソフトウェア開発のお役に立てているかもしれない、と思うと、研究者冥利に尽きる。
// 「こんなイモな話をしている。」という例としてリンクを張られているだけだったらもっとがんばらねば．．
NEEDLE説明会に多くの会社さんが来てくださった。
早いところからはいくつかフィードバックをいただいている。感謝すべきことだと思う。
こっちにも書いたけど，たいへんそうだ．．
PCのブラウザむけASP開発のときとかも、かなりIEに歩み寄るようなコードをたくさん書いてたなぁ。
結構標準にしたがってなかったりするんだよなぁ。携帯は機種数＝ブラウザ数になるんだろうから、もっとひどいんだろうけど。
10/16に研究会があった。写真をとってもらった。共同開発のユニシスさんにもお越しいただいた。
資料はここの「エンピリカルソフトウェア工学研究会」に置いている。
適用事例報告と同時に発表というパターンにこだわってみた。日立SASの十九川さんに感謝。
アンケート結果によるとこれが好評だったようで、役立つというコメントをいただいた。
このあたりは単なる演出なのかもしれないが、狙い通りという感じだ。
ちょっとカゼをひいてしまったようなのでこのあたりで．．
ここで説明会案内を出している。
申し込みをいただいている。NEEDLEがうまく発展してくれるといいなぁと思う。
ここまで1年ちょっとかかったが、だんだんと共同研究もうまくいってきている。
vodafoneからソフトバンクにかわったせいか新機種がたくさん出ている。
携帯開発をされている会社と何度かミーティングをしたこともあり、開発はかなりたいへんなんだろうなぁ、という感じだ。規模的にはエンプラレベルになっている。
しかしながら、新機種が出ると、携帯むけサービスを提供しているサービス事業者のほうはラッシュということもあり、こっちはこっちでたいへんなんだろうなぁ、と思う。今度こういう端末出すからリリース前にそのサービスでテストしておいてぇ、という話にはなっていなさそうに思う。
こっちのブログのアクセスログをみるとコンサルティング会社やシンクタンク会社からのアクセスがかなり多く、リピート率も高いようだ。彼らが気になるようなことを書いてるということかなぁ。2ヶ月ほど毎週書いているが、常連が増えてきつつあるようだ。
NEEDLEユーザグループというのを作ろうとしている。有名どころ3社ほどが参加表明してくれている。告知したり、会のやり方を決めたりするなど、本質的でないところに結構時間がかかる。
知らなかった。MySQL用の既存のレコードがなかったら追加、というステートメントだ。
あらかじめPrimary KeyやIndex Keyを設定していおいて、それらが重複するエントリを新規追加しようとしたときは、エラーをださずにUpdateする、というステートメント。以下のように書くそうだ。
INSERT INTO hoge SET (foo=bar, ...) ON DUPLICATE KEY UPDATE foo=bar
比較的よくあることのような気がするのだが．．．標準化が意外なところで止まっているんだなぁと知る。
empirical（実証的な）という英単語は日本ではそれほどなじみのない単語であるが、国際会議の発表では比較的よく目にする。よく使われるempirical evaluationは実フィールドもしくはそれに近い状態で評価/検証をすることである。
コンテンツ推薦手法を検討するために実運用が開始されているあるサイトのアクセスログ50万件を貸与いただける算段をした。付随情報を含めるとテキストデータで50MBくらいある。これから半年くらいかけてきっちりと検証をし、外部発表につなげる予定。結果は、研究プロトタイプではなく、実フィールドで体験できるようになる見込みだ。
ソフトウェア開発手法においても、empiricalな土壌を作りつつある。学位論文のテーマである協調フィルタリング/推薦についてもリアルフィールドでの検証を試みたいと思っている。
今頃みつけた．昔のは写真入りだったような．．
http://itpro.nikkeibp.co.jp/free/NCC/INTERVIEW/20031008/135427/?ST=itpro_print
---------------------------
ブロードバンドの普及でストレージ・サービスが開花する
・・・
同サービスを開発した事業推進本部サービス統括部の森崎氏に，開発の狙いを聞いた。（聞き手は蛯谷 敏＝日経コミュニケーション）
・・・
google analyticsを使ってみた。
いくつかのブログサービスでログを収集する方法をみつけたのでメモしておく。
google analyticsまだ不具合が多いような気がする．．
| ブログサービス名 | やり方 |
| livedoor | 編集画面トップから「カスタマイズ/管理」をたどり、左側ペインの「デザインの設定」を選ぶ。デザインのテンプレートの一番右下の「カスタマイズ」というリンクをたどり、「トップページ」、「個別記事ページ」・・・それぞれの |
NASSCOM(http://www.nasscom.in/ : 日本でいうところのJISAにあたると思われる)に参加している企業の人と連絡をとっている。インドのソフトウェア開発企業は主に米国のアウトソース先になっている。
インドのソフトウェア開発企業は米国のアウトソーサとして急成長しているが、飽和状態への懸念が強まっているようだ。現時点で売り上げの数パーセントにとどまっている日本から新たなアウトソースを得ようと活発な活動を実施しているようだ。インドにはCMMIレベル5の企業の数が非常に多い。日本のレベル5と同等なのかは少し検討が必要ではあるが。
勢いがつきつつある。何となくパターンがつかめつつあるようにも思えてきた。
産学連携といえども、やはり基本はバータではないかと。
Next Generation Networkの略。複数の知人から聞くようになった。盛り上がっているらしい。
自分が参加していたようなRFIDの標準化よりも、かなり権益が動きそうな話らしい。
EUはまとまっていてすごいなぁ、という印象を受けるそうだ。国毎に投票権を与えると数もすごいしなぁ。
というのはどうだろうか、とふと思った。
たとえば、Fail overにしているだけでコストがかさむと思う。
移籍して1年たった。ちょっと広報活動もやってみようかと。
ソフトウェア工学において産学で活動を進める難しさについて、いつも考えている。
大学(研究側)では研究を主に新規性や有用性の点で評価する。結果として、論文発表の大小やその発表が他者に与えた影響（具体的には論文への参照）による評価となる。もちろん、研究者として公平性や虚偽のない活動が前提ではあるが。一般に、新規性や有用性にはコストに対する議論はそれほど多くはなされないのが通常である。つまり、コストと新規性、有用性の一方もしくは両方がリンクされていない限りコストについては、十分な議論がなされない。
いっぽう産業はどうかというと、研究成果はもとよりすべての活動は金銭に換算され評価される。企業の規模により売上げの成長性であったり、安定した経常/営業利益をあげられることになるかもしれないが、基本尺度は金銭である。もちろん、企業として不正や法令遵守が前提ではあるが。目玉商品がない、内部統制がうまくいってない、等がメディアにより批判されることがあるが、成果が出ていないとき限定ではないだろうか。
すなわち、コストと新規性や有用性がある程度リンクしていない限りは、大学の研究が直接産業に役立つ、ということは難しい。理由は、企業が新規性や有用性をちゃんと理解したとしても、それを直接ビジネスやコストに結びつけることは難しいからであり、大学側が金銭感覚を身につけて、新規性や有用性以外にコスト面について言及することもまた難しいからである。
EASEではそのギャップを埋めることを常に念頭におき活動を進めており、それは少しずつ実を結び始めている。
ソフトウェア工学の産学連携を難しくしている理由がもう1つあると考えているがそれはまた別の機会に書きたいと思う。