TMMi Version2

TMMi(Testing Maturity Model integlation)の、Version2.0が発行されてた。TMMiは、ソフトウェアテストのプロセスに関する成熟度を表す。

http://www.tmmifoundation.org/html/tmmiorg.html

→　http://www.tmmifoundation.org/html/resources.html　での「TMMi Reference Model」。

Version2では、成熟度でのレベル3が追加されてる。Ｖｅｒｓｉｏｎ1でも、ちょっと触れてたと言えば触れてたけど。それにしても、この調子だと1,2年毎に記述されるレベルが上がるので、レベル5まで揃うのは、まだちょっと先ということかな。（まっ、それはそれで面白い。）

さらっとしか見てないし厳密に比較してないし、そもそも英語得意じゃないので、読み違えてたら悪いけど、Version1との主な違いは以下辺りかな。

・Test strategyは、どっちかというとレベル2からレベル3でへ

・Test automationは、レベル2でも必要に

Test strategyが重要なことは分かるけど、実際に構築できてるところが少ないということかもしれない。あるいは、TMMiではTest strategyに対して色んなプラクティスを書いており、レベルアップには時間かけても良いよとしているのかも知れない。個人的には、後者として納得したけど。

なお本Version2については、JaSST2009東海での電気通信大学西先生の講演資料に、少し記載されている。（参加したわけではなくて、今調べていて発見した次第。）

普通の組織体では、（成熟度は低いか高いかは別として）開発プロセスやソフトウェアのプロセスを持っている。あるいは、それが普通。　なので、悩ましいのは、ソフトウェアテストプロセス構築手法のどれを、あるいはどこを採用すべきかという点。プロセス構築手法を簡単に比較できるのがいい。お勧めは、ISTQB/JSTQBでのAL（Advanced Level）レベルかな。

http://www.jstqb.jp/syllabus.html

日本語版 Version 2007.J01だと、90ページ以降。

自分自身としても、どんなプロセス構築手法が良いか悩んでいることもあるので、今回のVersion2を契機にCTPなどもちょっと読んでみようと思う。

「アジャイル出産」って呼称されて

先だって、「○イテレーション＊日」を書いたら、Twitterで”アジャイル出産”という言葉を使って引用されてた。

さすがーと、感心した。　（自分の環境では、過去検索でもう引っかからないようで、ちょっと残念ではあるけど。）

連想できる言葉として、「アジャイル出荷」や「アジャイルサービスイン」なども考えられる。人によっては真面目すぎる言葉に聞こえるだろうけど、職場で使う言葉としては抵抗ないかも。いずれにしろ、出荷やサービスイン、カットオーバーを意識するのは良いこと。

軍議と犬の帰巣本能

時代劇が好きである。その関連で、ここ4，5日は、表題の”軍議”に考えを巡らせていた。

よく戦国時代のドラマなので、城内や合戦の現場で行われる、大将を中心とした会議である。合戦の現場では、楯を利用してテーブル代わりにするシーンが多い。城内のそれでも合戦現場でのそれでも多いのは、地図を広げ、自軍と相手軍の駒を置いて、趨勢を見極めたり戦略・戦術を議論する様子。あわや格闘という流れになることも少なくない。

現代から見ればだし、ドラマの構成上の絡みもあるが、戦国武士＝粗野な連中。しかし、彼らのそんな軍議が、あのシーンで妙に合理的に思えてしまう。それに引き替え、昨今の会議は合理的なのかと考えた次第である。なんか妙に微細な事項を議論し、軍議での地図や駒のように俯瞰的な情報に乏しい。ポートフォリオ的な視点が無いというか、、、。

戦国時代と比較して、今日では、非常に多くの情報が、しかも瞬時に手に入る。しかし、ちょっと過度な言い方かもしれないが、実質的な機動性は戦国時代にも劣る時が少なくないかと思えてしまう。結局、情報加工の技術や、昨今での言葉だとBIツールの類を使いこなせていないのだろう。

アジャイル系開発での、例えば進捗状況のグラフなどを張り出してメンバー間で打ち合わせする様子などが掲載されることがある。そんなやり方の方が、より俯瞰的な状況把握に役立つと思える。旧態のやり方しかやれない組織体も、多少見習ってちょっと真似てみたりしたらいいのにと思った次第。

で、タイトル後半の「犬の帰巣本能」の件。戦国時代の軍議とかでは、色んな情報が活用される。早馬や間者の類や手紙、、、、。さらには、戦国時代の情報伝達で結構活躍したのが、狼煙（のろし）である。上での軍議の事を考えながら、雨や夜にはどうしたんだろうがふと疑問になってきた。　ちなみに、自分の持ってる戦国時代の情報伝達の本を読み直したけど、それは手紙主体の類で、狼煙などについては深掘りしてなかった。

ネット上で”狼煙”を調べたら、夜は火を灯したそうだ。雨の時の具体的なことは多く引っかからなかったので、人や動物を使ったのだろうと考えた。ただし、どうも伝書鳩が利用されたのは江戸時代からみたいである。なので、なおさら疑問が。

そこで見つかったのが以下。

軍用犬　

あの「甲陽軍艦」に記載されているとのこと。武州松山城から放った10匹の犬が、岩槻までたどり着いたとのこと。そのうちの1，2匹だったんだろう。調べたら、直線距離で20キロくらい。

犬のある暮らし 帰巣本能の成せるワザ？ 愛犬が約11.2km離れた自宅へ戻る

上では、130キロ離れた場所へ戻ってきた話や、犬の帰巣本能に関して言及している。

戦国時代にどれくらい軍用犬が活躍したかは分からないが、「甲陽軍艦」からしても、情報伝達のリスク管理なりバックアップ手段をいくつか用意してたのは確かだろう。この辺りも、なんか参考にして良いかなと思った。

なんか軍議から発展して色々調べたけど、結構面白かった。

「ソース・コード静的検証によるソフトウェア品質評価の意義」

日経エレクトロニクス（NE）、1月25日号。先週届いたけど積ん読状態で、さっき読んだ。表紙は、マラソンのスタートっぽい写真。

http://www.nikkeibpm.co.jp/cs/mag/ele/ne/saishin.html　ただし、最新号のページなので、時が経てば変わる。

その中での興味深かった記事の一つが、タイトルの「ソース・コード静的検証によるソフトウェア品質評価の意義」。論文だが、端的には、オージス総研での”Adqua”によるソフトウェア品質分析。ただし、もちろん、ISO/IEC 9126での品質モデルやGQM法との関連にも言及している。

静的解析ツールでの各種メトリクスを、段階的な対応付けで評価得点化する。手法的にはGQM法。評価得点種は、ISO/IEC 9126での機能性以外の5項目。

ここでの「信頼性評価得点」とバグ密度、そして「保守性（変更性）品質評価得点」とコーディング＆テスト効率のそれぞれの相関が高いことを示しており、実務的にも役立ちそうなことも少なくない。

なお、このような得点なり点数にすると、良く判ってない人が満点目指すとかして、暴走する/プロジェクトが回らない話も聞く。現場に適用する時は、その辺りの回避もミソかな。　

#上で、9126って書いたけど、もちろん論文では、25000シリーズとの関連を簡単だけど脚注で触れている。ちなみに個人的には全部理解してないけど、25000ってなんであんなに大ボリュームにしたのか分からない。そのせいもあって、むしろ品質特性での議論で大事なのは、継続的改善の方かと思う。

Firefox3.6、Googleノートブックの置き換えの目処

Firefox3.6でのGoogleノートブックの置き換えだけど、少し目処が立った。テキストの保存が主なので、ブックマークへ登録、その後Googleノートブックへ移動するやり方。（他のサービスの利用もあるけど、既に書いたように、スピードなどの点でちょっと難点。）

で、Googleブックマークって、同一URLで1つのメモ保存が原則になっている。それに対して、ノートブックは複数種のメモ保存が可能。Googleノートブック保存の際に、必要部分をペースト追加すれば出来なくはないけど、ちょっと面倒。

どうにかうまく出来ないかと探したら、同一URLで複数種のメモ等を保存できるアドオンが見つかった。「Old Add Bookmark Behavior 2.0」。

https://addons.mozilla.org/ja/firefox/addon/8479

それなりに動くんだけど、問題あり。上のページにも書かれているけど、複数のメモとかの場合に、最新のそれしか表示等をしない。Googleブックマークのサイドバー上にブックマークそのものは複数あるし、ツールチップ上ではそれら複数種のメモも表示される。所謂サイトとしてのGoogleブックマークの一覧に表示されない。

[既知の問題]
ロケーションバーからの検索においては,同一のURLで複数ブックマークしてる場合は,そのうち最も最近にブックマークしたもののみ表示されます。(See Bug 451318 – [meta] Unexpected behavior for bookmarks with the same url (duplicate bookmarks) Comment #1-3 および Bug 451587 – Location bar will not match on a bookmark's title/"name" if its url exists in a more recent duplicate bookmark )

したがって、ノートブックへの移行まで含めて、うまく解決しているわけではない。

また、出来れば右クリックでブックマークへの登録が行われればメモの確認になって良いんだが、それらしいアドオンが見つかっていない。こちらは、Cntl-Dで処理しようかなとは思っている。

上に書いた「Old Add Bookmark Behavior 2.0」でのバグ対策が実施されれば、本格的にFirefox3.6を使用して、Googleノートブックのアドオンは諦めるつもり。ただ、まだそのバグの件もあるので、Googleノートブックとしての利用の多いPCはFirefox3.0のままで動かすことにした。つまり、Firefox3.6にしたPCを利用して「Old Add Bookmark Behavior 2.0」でのバグ対策を確認、その後他のPCも3.6にする作戦。

ちなみに、「Old Add Bookmark Behavior 2.0」は、2，3日前にはFirefox3.6で動かないとのことでインストールできなかった気がしたが、勘違いかも知れない。

Googleブックーマーク、そしてノートブックの両方のデータは、サーバー上に置かれている。こんな時は別々のPCで使いやすい環境にしておけるので、ちょっと便利だ。

トヨタカレンダー

トヨタカレンダーって、健保のサイトにある。

http://www.toyotakenpo.jp/category02/cate02_06_kenpokaikan.html

本来は、以下から辿った方が良いだろう。HOME　→　トヨタ健保のご案内　→　組合カレンダー　→　健保会館。

http://www.toyotakenpo.jp/index.html

ちなみに正式名称は、「トヨタ自動車健康保険組合」。健保会館が開館してるかのカレンダーなので、厳密にトヨタカレンダーかとなると断言はできない。でも、まっ、参考に。

○イテレーション＊日

先週だったかTVの健康番組かでちらっと見たけど、妊娠周期の”十月十日”をやってた。ちなみに、それらしい番組検索やってみたけど見あたらなかったので、放送大学の番組だったのか？？　ちらっと見た部分は、計算方法とか28日周期でなくて35日周期ならとかの話。

そこで、ふと思ったのが周期→”イテレーション”。

プロジェクトのリーダーみたいな立場の人から、特に”えせアジャイラー”が期限を明言しない事への不満を聞いたりする。アジャイルでやるのなら、例えば、イテレーションと日にちで表現しても良いのではと。逆に、リーダー側はイテレーション期間を確認して、期日に変換すればいい。

なんか、アジャイルって、従来のプロセスと相容れないとして開発そのものが進まないケースもあるようだ。アジャイル推進側も、出来る部分から実践すればいいと思うんだけど、、、。イテレーションを周期として期日を考えるのも、その一つかな～とふと考えた。

HDリマスターに見る日本的品質

CS放送の「時代劇専門チャンネル」で、最近時々流れているのが”御家人斬九郎”の、ハイビジョンリマスター版制作の様子。

http://www.jidaigeki.com/special/1001_2/など。

斬九郎って、今まで時々見てたけど、実際は直近でもフィルム撮影だったそうだ。なので、ハイビジョンにしやすい。ただ、それだけだと驚かないけど、少し前はワイドでのフィルムじゃなかった。それをワイド化していく。単に上下のカットじゃなくて、当時のカメラマンと一緒に、構図的に上の方を残すとかやったとのこと。

また、デジタル処理で、従来だと目につきにくかった近代建築なども処理を行ったそうだ。従来のSDではほとんど目につかなかったが、ハイビジョンでは判ってしまうのでデジタル処理。（なんか韓国とかでは、時代劇つうか昔のドラマとかで、電線とか出ても余り気にしないみたい。ちょっと聞いただけで調べてないし、まっ国や人で考え方違う。）

時代劇のハイビジョンリマスターに向けたそんな作業の様子を目にすると、やはり日本の細かさというか品質に対する取り組みは、分野違っても同じなのかなと思えてくる。ふと、後は、そんなコンテンツを他の国に出せれば良いだけではないかと。

なお、”御家人斬九郎”の、ハイビジョンリマスター版は、明日25日からの放送。

Firefoxを3.6へ。Googleノートブックの件も踏ん切り。

知り合いの何人かがFirefoxを3.6にしたというので、どうしようか悩んだり関連することを実験して、今朝3.6にした。

急いで3.6にする必要もないし、特に新しい機能に興味があったと言うことでもなかった。ただし、実は、今使っているのが3.0.17。後述する理由もあったんだけど、どっかで新しいのにしないと行けないとは思っていた。大きくバージョンが変わったし、余りに古いのを使い続けていたらいろんなアドオンの整合性が取れなくなるので、潮時かなと。

古いバージョンを使い続けた大きな理由が、Googleノートブック。3.5かでアドオンが使えない。ホームページでの右クリックでノートブックに移すことが出来ない。

3.5の頃でも、zohoやevernoteへの移行を検討した。でも、当時（記憶が正しいか不安だけど）Googleノートブックからのインポートでの文字化けがひどかったり、動作が不安定だったりして断念。今回、再度動作を確認。インポートもそれなりに出来た。ただし実験だったので1ノートブック程度。

しかし、スピードが難点。面白い使い方が出来るのは判ったが、自分の使い方では、テキスト主体、、、、。他に、タグ（ラベル）が使えないみたい。ただし後者はzohoだけかも。

今朝、3.0.17のインストーラーはあるんだしと思って、3.6をインストール。もしかして、ほんとにもしかしてGoogleノートブックのサポートが復活してるかもと期待しながら。でも、案の定そこは駄目。

さっと一通りテスト。その際、若干難問が。3.6で「IE Tab」が使えない。本アドオンは、Firefoxのままで、IEもどきの処理をするというもの。3.6で動くのに「IE View」というのがあったけど、これはIEそのものが起動するというもので、自分には向かない。どうしようか悩んでアドオン検索してみたら「Conral IE Tab」を見つけた。「IE Tab」と似て、そこそこ動いた。

「IE Tab」は、ちょっとしたセキュリティ絡みの場合の挙動で全くIEと同じ動作するとは限らないが、それでも結構Firefoxで見られるサイトが増えたので重宝していた。「Conral IE Tab」になって、どの程度互換性が高いか細部確認する。「IE Tab」が3.6対応したり2つでの互換性の差があれば別だけど、方向的には「Conral IE Tab」を利用するつもり。

もう一つの、Googleノートブックの件。どっかで踏ん切りつけないと行けない。結局3.6をインストールして動作確認しながら、テキスト主体なので、ブックマークの機能を利用することにした。つまり、ブックマークで保存して、その後ノートブックへ移動する作戦。

ただし、ノートブックの画面じゃ、ラベル付きのブックマークしか表示されないので、操作的にちょっと難点。うまいやり方がないか、検討してみる。また、画像を保存したい時も無い訳じゃないので、どうするかは検討。その部分だけ、zohoやevernoteを使うのもあり。FirefoxのアドオンでのSCRAPBOOK(日本の大学製の?)なる物もあるので、検討の一つにするつもり。

これで、Googleノートブックへの対応の件が一段落すると良いんだけど、、、、。

IT Leaders 1月号 ”保守サポート”

タイトルの号が、結構良かった。保守サポートの戦略とか料金とか、、、。

http://it.impressbm.co.jp/e/2010/01/05/1658

上記のネット上でも、結構細部が読める。ただし、個人的に良かったと思うPart5は、ネット上は来週に公開。なおPart5は、保守料金の件で、判っている人にとっては数字の裏付けを得ることになる程度。ただし、それが一般公開された情報になることで、社外を含めたコミュ内で情報共有が楽になるメリットは非常に大きい。

上のページの既に公開済みの中では、Part3が面白い。特にSAPジャパンの保守料金の攻防。17％から22％への攻防。たった5ポイントと言えばそれまでだけど。