http://se.naist.jp/~morisaki/ ja Copyright 2010 Tue, 19 May 2009 19:09:12 +0900 http://www.sixapart.com/movabletype/ http://blogs.law.harvard.edu/tech/rss こちら そこそこページビューを稼いでいるようだ。レビューへの関心の高さを示しているのかも。]]> http://se.naist.jp/~morisaki/2009/05/itwwwatmarkitcojp.html http://se.naist.jp/~morisaki/2009/05/itwwwatmarkitcojp.html 雑記（ブログ） Tue, 19 May 2009 19:09:12 +0900

インスペクションとは何か？ （森崎 奈良先端科学技術大学院大学）

即活用！「レビューの質チェック票」（ヤマハ 小池氏）

第三者インスペクションとは （細川氏 日本IBM）

RHELを題材にソースが見える環境を作る （大和氏 レッドハット ）

はじめる前に頭に入れておきたいこと！ （小笠原氏 東芝）

]]> http://se.naist.jp/~morisaki/2009/03/thinkit.html http://se.naist.jp/~morisaki/2009/03/thinkit.html 雑記（ブログ） Sat, 07 Mar 2009 01:51:59 +0900 こちらへ ]]> http://se.naist.jp/~morisaki/2008/07/post_33.html http://se.naist.jp/~morisaki/2008/07/post_33.html 雑記（ブログ） Sun, 13 Jul 2008 16:12:42 +0900

「T.B.D(to be determined: 後で決める)」の数
顧客や他の設計部門の決定を待ってから決める部分や現時点では明確でない部分が多く決められていないである。ある程度はしかたがないことではあるが、これが多すぎると何も決まらないままプロジェクトが進んでいるリスクがある。

異常系定義の厳密さや存在有無
一般に、正常系の定義や設計が終了してから異常系処理の定義や設計がはじまるので、異常系処理の厳密さや存在有無は要求や設計の進行度合いをはかる目安となる。

変更による手戻りの度合いや工数
変更によって発生した手戻りの累積。たとえば手戻りの工数がとれて いれば本来計画していた工数に追加の工数がどの程度必要となるかを類推できる場合がある。

レビューでの指摘の種類と指摘数
ここにも書いたことがあるが、要求仕様のレビューや設計レビューでの指摘事項の記録は参考になるものが多い。

]]> http://se.naist.jp/~morisaki/2008/03/post_35.html http://se.naist.jp/~morisaki/2008/03/post_35.html 雑記（ブログ） Sat, 08 Mar 2008 17:04:02 +0900

○ページ数が少なくなる

○2日を同時に見ることができる

×todoが少ない

×スケジュールの開始時刻が遅くと終了時刻が早い

×ことわざとかがない

×残り…日の表示がない

という感じで個人的には結構×が多いのだが、ページ数が少なくなるのがやはり魅力的に思えた。今年1年でどっちがいいか結論が出るだろう。 右側の写真が無印良品のバインダ。安いけどしっかりしているし、フランクリンのコンパクトサイズにぴったり合う。インデックスが若干はみ出てしまうのだが。。 バインダは相変わらず無印良品のバインダで1000円くらいのヤツ。軽いながらもすっぽりはまるので気に入っている。手帳は通勤電車の中で仕事が始まる前と終わった後に必ずみているので、左手で持てて、右手でペンが持てるのが要件。軽いほうがありがたいのでこれがうれしい。 高いとなぜか重くなるように思うが、そんなもんだろうか。 ]]> http://se.naist.jp/~morisaki/2008/01/post_34.html http://se.naist.jp/~morisaki/2008/01/post_34.html 雑記（ブログ） Sat, 05 Jan 2008 19:00:23 +0900 この本のpp. 176-180。自分の写真が出ていたので、急に立ち読みしていることが恥ずかしくなってしまった。]]> http://se.naist.jp/~morisaki/2008/01/post_32.html http://se.naist.jp/~morisaki/2008/01/post_32.html 雑記（ブログ） Fri, 04 Jan 2008 22:43:40 +0900 民間企業に勤めていたときに、先輩から「B2Bは特にだけど、きらいなヤツからはどんなにいいものでも買わないのが顧客が多い。そういう意味では好かれる人をみつけるためにいろんな客にあたるというのも1つの手だ」という話を聞いたのを久々に思い出した。 http://se.naist.jp/~morisaki/2007/12/post_20.html http://se.naist.jp/~morisaki/2007/12/post_20.html 雑記（ブログ） Sun, 16 Dec 2007 02:23:02 +0900 「遅れているソフトウェア開発プロジェクトに開発メンバを追加すると、開発スケジュールがさらに遅れる。」というのが最も有名な法則であり、「The Mythical Man-Month」という本に記述されている。それほど簡単には説明できないだろうが、大まかな説明はこうだ。n人のプログラマで作業を分割すると作業消化についてO(n)の効果が出るが、コミュニケーションパスはn X (n-1)/2 となりO(n&sup2)の複雑さと脆弱性が増え、結果としてメンバ追加によるプラスの効果を得ることができない、というものだ。O(n)は計算量のオーダで使われるているものであり、nの入力に対し、結果がどのくらいの割合で増えていくかを示している。たとえば、O(n)はnに比例して大きくなることを示し、O(n&sup2)はnの2乗に比例して大きくなることを示す。 コミュニケーションパスがn X (n -1) / 2のペースで増えるかどうかという点については議論の余地があるが、メンバ追加時の経験を思い出すと、なんとなく「引継ぎ、（更新されていない）ドキュメントの説明、状況の説明」というコミュニケーションオーバヘッドが思い当たるのではないだろうか。有名な法則ではあるが、これ自身が意識されていなかったり、管理者層への説明の簡便さから「プロジェクトが遅れはじめているから人員増強だ」というのはよくある話だろう。 プロセス定義やドキュメントの整備が当時よりも進んでいると思われる現在においても、このは成り立つのだろうか。エンピリカルソフトウェア工学の研究者として実際に計測することは興味深いことの1つである。もともと1970年代に言われたことである。遅れていないプロジェクトについてはどうか、作業別に人員追加をやってみるとどうか、というあたりがわかれば、計画時に役立つのではないだろうか。 http://se.naist.jp/~morisaki/2007/10/post_30.html http://se.naist.jp/~morisaki/2007/10/post_30.html 雑記（ブログ） Wed, 24 Oct 2007 08:28:31 +0900 字面としてわかることと経験として理解できることにギャップがある事柄がある。たとえば数式による定義は比較的字面としてわかるほうに分類されるだろう。また、自動車の運転のしかたを字面で理解したからといってすぐに車が運転できるわけではないだろう。前者はギャップがない例、後者はギャップがある例としてあげている。特にいろいろと経験を積み上げている方に対して、後者を前者と同様に考えることは大変失礼な行為と考える。そういう失礼のないよう心がけていきたいと思う。 http://se.naist.jp/~morisaki/2007/10/post_29.html http://se.naist.jp/~morisaki/2007/10/post_29.html 雑記（ブログ） Sun, 14 Oct 2007 09:17:16 +0900 IESEのメンバとも話になったが、ソフトウェア開発での意思決定の透明性は重要であり、エンピリカルな手法が意思決定の透明性をあげることに寄与すると考えている。 たとえば、人による見積り値を出した後に見積りモデルでの妥当性確認をしたり（NEEDLE）、類似バグの確認を「うーん」と考えるだけでなく、クローン分析によって対象ソースコードを検索する、というのは「おそらく類似バグはないだろう」という意思決定の透明性をあげているように思う。「いろいろ思い出してみた」というよりは透明性があがっているのではないだろうか。 ここしばらくの私のテーマは透明性をあげる、という方向で考えていきたいと思った。 http://se.naist.jp/~morisaki/2007/09/post_28.html http://se.naist.jp/~morisaki/2007/09/post_28.html 雑記（ブログ） Fri, 28 Sep 2007 01:32:22 +0900 海外に行っていたため、携帯電話の時計を現地時間にセットしておいた。普段は携帯を目覚まし代わりにつかっているので、日本時間に戻すのを忘れていたため、起きれなかった。タクシーと余分なチケット代という対価におわる．．授業料か．． http://se.naist.jp/~morisaki/2007/09/post_26.html http://se.naist.jp/~morisaki/2007/09/post_26.html 雑記（ブログ） Tue, 04 Sep 2007 01:32:08 +0900 熟練PMが見積っても見積り精度が低いプロジェクト（見積りが難しいプロジェクト）は、予測モデルを使っても見積り精度が低いプロジェクトか調べたくなった。PMがコミットした見積りが精度が最も高くなるという現実があったり、見積りモデルの予測精度が低い場合でも、予測モデルの見積り結果をうまく利用できるように思う。 http://se.naist.jp/~morisaki/2007/08/pm.html http://se.naist.jp/~morisaki/2007/08/pm.html 雑記（ブログ） Thu, 23 Aug 2007 00:11:59 +0900 大胆な名前だ。 http://services.google.com/websiteoptimizer/ http://se.naist.jp/~morisaki/2007/08/website_optimizer.html http://se.naist.jp/~morisaki/2007/08/website_optimizer.html 雑記（ブログ） Tue, 21 Aug 2007 01:04:22 +0900 夏休みまっただなかだが、仕事面のミッションステートメントを書いて記録することにした。 ソフトウェア開発に関しては、自身の経験をもとに、社会に還元できるようなものを追及することを最重要視したい。あとは、過度に成果中心型にならないこと（企業でいえば適正利潤か）、問題をきちんと理解することだろうか。研究のブルーオーシャンを追求することはすなわち社会への還元になると考えているのでブルーオーシャン分野での提案もミッションステートメントの中に含めるべきではないかとも思う。 http://se.naist.jp/~morisaki/2007/08/post_25.html http://se.naist.jp/~morisaki/2007/08/post_25.html 雑記（ブログ） Sun, 12 Aug 2007 11:25:21 +0900

現実に起こっている問題を正しく把握する。

問題解決を最優先とし、プロフェッショナルにふさわしい行動をする。

方法の利用者の立場にたった実現性のある提案をする。

常に広い視野をもち、視野が広がるような行動を心がける。

研究成果物を広く社会への還元と位置づけ、適正な品質と量を保つ。

]]> http://se.naist.jp/~morisaki/2007/08/post_24.html http://se.naist.jp/~morisaki/2007/08/post_24.html ミッションステートメント Sun, 12 Aug 2007 10:46:01 +0900