2015年1月20日 (火)

第12回クリティカルソフトウェアワークショップ GSNやIV&Vケースなど

今日は「第12回クリティカルソフトウェアワークショップ (12thWOCS2)」へ。ソフトウェアシステムでの信頼性・安全性の確保に関するもの。3日間のうちの1日のみ参加。

http://www.ipa.go.jp/sec/events/20150120.html


・アシュアランスケース入門

アシュアランスケースは、テスト結果や検証結果を利用者に保証したり確信させるためのドキュメント。具体的には、GSN(D-Case)という表記があるが、説明は主としてそれで行われた。その前段として、トゥールミンの三角ロジックが紹介された。自分としてはディベートでの反駁(はんばく)などがすっきり図示化できる~と、ちょっと感心してしまった。また、アシュアランスケースの標準化作業や認証関係も話が出た。


・セーフティとセキュリティ規格の同時認証方法論について

認証にお金がかかる話も行われ、似かよった2つを同時認証した具体例、またその課題が説明された。以前からセーフティとセキュリティに限らず興味のあった範疇なんだけど、一挙に実践へ向えない色んな事情も感じた。


・ソフトウェアIV&Vの基礎

IV&V自体の説明と、GSNをベースとした「IV&Vケース」の説明があった。


・第1回IV&Vコンテスト(電子レンジ仕様編)審査評・表彰

午前中に行われたコンテストの審査評・表彰。電子レンジの要求に対する検証結果などを確信させるコンテスト。うーん分かりにくいかな...。電子レンジの検証をGNS(IV&Vケース)で書いて、それを審査するコンテスト。チーム対抗で、出場したのは5チーム(だったと思う)。なお、コンテストへの参加はチームで応募するもので、コンテスト参加者のみが午前中に受講と作業。

IV&Vケースの実践的な場と思って、個人的に期待してたもの。ただし、電子レンジの検証全てにわたるわけではなくて、2つくらいの課題に対するIV&Vケースで、自分としてはなんで微細的な視点で考えるんだろうと、少し頭の中がもやもや。

後で、IV&Vケースの説明者に聞いたけど、IV&Vケースの使い方にも色々意見はあるそうだ。俯瞰的な利用の方を好む人もいるようで、自分もそのほうが良さそうに思った。(俯瞰的に眺めた上で、今回のコンテストの2つの課題を掘り下げて記述するのは構わないだろうが。)

ちなみに、本コンテストの優勝チームの1人は少し知った人だった。さすが。


GSNは、(複数の)モデリングツールで利用できるようになっているので、徐々に広まっていくと考えられる。呼称がそのまま広まるかは分からないが、IV&Vケースを実践していく事例も出てくるかもしれない。少し頭の隅においておくつもり。


Amazonでの書籍「ソフトウェア 信頼性 安全」


1月 20, 2015 ソフトウェア, ソフトウェアテスト, 品質, 安心・安全 | | コメント (0) | トラックバック (0)

2015年1月 6日 (火)

自己免疫疾患と品証暴走

今日ちらっと見たテレビ「家庭の医学」で登場したのは、SAPHO症候群。症状的には手足の関節痛なんだけど、リウマチ症などと少し違って皮膚系の症状も現れる。SAPHO症候群が”自己免疫疾患”であることが何度か番組で言われた。(ちなみに関節リウマチも自己免疫疾患かと思う。SAPHO症候群は、NHKの「ドクターG」に登場したようだ。)

医療系の番組で時々出てくる”自己免疫疾患”。外部からの異物への反応が過剰になって、症状を引き起こすというもの。しかも厄介な事に、ある病気と思って対処療法的に治療しても良くならずに色々調べたら自己免疫疾患のほうだったというケースが少なくないような気がする。あくまでTV番組などを見ての感想だけど。なお、ふと自律神経失調症なども含まれるのかと思って調べたら、基本的には含まないが、自律神経失調症の中のいくつかを自己免疫疾患に含めるという書き方のサイトもあった。


ソフトウェアに関しては、このような病気との関係では「ソフトウェア病理学」がピンと来る。ただし、この本では”過大な文書化作業”なる項目はあるが、ソフトウェア開発での自己免疫疾患のような事項は書かれていないようだ。

ソフトウェア開発での自己免疫疾患的な現象は、バグゼロを目指す余りにいつまでたってもテスト終了を出せないとか、静的解析でのワーニングゼロを目指すなどが考えられる。市場トラブルなどでバグが見つかってその対応は必要だが、ソフトウェアでのバグゼロが可能かは議論あるところ。むしろソフトウェア工学的には、「バグがないことは証明できない」が通説だ。

単純な論理構造の場合にバグがないことは言えても、どのシステムでもそうだとは言えない。昨今のように他モジュールや他サービスの利用が進むと、全体的なバグのコントロールはもちろん、(意図した時期のリリースのような)管理さえ難しくなる。

ソフトウェア開発以外でも製品企画や製品出荷、製品製造でも似たような事は発生して、いわゆる”過剰品質”。主体が品証とは限らないけど、声高に高品質が叫ばれ、商品化などがなかなか進まない。品証や品証気取り連中の、言わば暴走。

生物が生きてくために免疫は必要だけど、過剰になると弊害が大きくなる。しかも、その弊害が大きくなると直しにくい。(過度の)過剰品質は、その組織体での問題であり、積極的に対処すべきと考える必要があろう。過剰品質の問題は以前から言われてはいるけど、小さな場合(軽い症状)ならまだ良いが、大きい場合(重篤なら)は根本的な治療が必要だし最悪その組織体がなくなることも考えた方が良い。自己免疫疾がそうであるように、外見では自己免疫疾とは気づかない事もあるから要注意。

TVで「自己免疫疾患」が出て、つい考えてしまった。

Amazonでの過剰品質

1月 6, 2015 ソフトウェア, ソフトウェアテスト, 品質 | | コメント (0) | トラックバック (0)

2014年10月19日 (日)

ITプロジェクト成功率 30%→75%にアップ?

日経コンピュータ2014年10月16日号を読んでいて目に飛び込んできたのが、”高い成功率も油断は禁物”、”プロジェクト成功率は75%”。の文字。特集「3069人調査で迫る 情報システムのリアル」での、タイトルや見出しだ。

以前の日経コンピュータでは、成功率が30%程度だった。2008年12月1日号と2003年11月17日号での記事で、それぞれ31.1%と26.7%。以前”日経のプロジェクト成功率”としてブログに書いている。

つまり、ここ数年で成功率が30%→75%にアップしている。喜ばしい事だ。(ただし内心では、以前のブログの行間で述べたつもりだけど、数年前などでは回答側も分析側も失敗の方にバイアスがかかっていた気もする。)

数年前などでの日経の調査は、第1回と第2回の「プロジェクト実態調査」と題するものだった。5年ごとで、次は2013年と気にかけていたが雑誌には掲載されてない。なので今回の10月16日号が、それに代わるものと考えて良いだろう。ちなみにサンプルは全く同じかは不明だが、有効回答数は、2003年が1746、2008年が814、そして今回の2014年が3069なので、回答数自体は増えている。

個人的には、今回の方が実態と合致しているように思える。なお、工程での失敗率の分析や商習慣に対する回答、アジャイル導入比率などの分析も行われていて、参考になると思う。一読をお勧め。


ちなみに日経コンピュータ2014年10月16日号の目次ページは以下、
http://ec.nikkeibp.co.jp/item/backno/NC0871.html

日経コンピュータ2008年12月1日号の目次ページは以下である。
http://ec.nikkeibp.co.jp/item/backno/NC0718.html

10月 19, 2014 ソフトウェア, プロジェクトマネジメント, プロジェクト管理, 書籍・雑誌 | | コメント (0) | トラックバック (0)

2014年9月27日 (土)

SysMLツールベンダー3社揃い踏みセミナー

今日はSysMLのセミナーへ。正式名称は「SysMLツールベンダー3社揃い踏みシステムモデリング事例&ツールセミナー」と、結構長い。オージス総研が主催だけど、ツールベンダ(IBM、チェンジビジョン、スパークスシステムズ)が揃って登壇するし、チェンジビジョンは平鍋さんで、スパークスシステムズは河野さんがしゃべるということで応募した。具体的な事例の話もあることや無料というのも自分としてはメリットに感じた。

http://www.ogis-ri.co.jp/event/1219906_6738.html


ちょうど良さそうな時刻にビルに到着したのに、エレベーターに乗ったら5階止まり。今回のセミナーは上の6階で、そのためのエスカレーターや階段があるかもとうろうろする羽目になり、結局受け付け的には終盤の時間になってしまった。なかなか空席が見つからなかったが結構前の方に空いた席があって、一言声をかけて着席。少し急いで、色々準備した。

講演がスタートして、講演者が、こちらの方を向いて「平鍋さん、そうですよね」みたいに言うからびっくり。なんと、平鍋さんの隣に座ってた。最前列でもなかったし、講演者とか事務局用みたいな紙も張ってなかったので、てっきり聴講者のゾーンだと思ってた。(休憩時に隣が平鍋さんだったと自分でつぶやいたり、平鍋さんに一言挨拶したり、、、。)


講演やパネルディスカッションでの印象などを以下に記す。(聞き違いや勘違いは、ご容赦。)

ツールは、IBMがRhapsody、チェンジビジョンがastah、スパークスシステムズがEnterprise Architect(EA)と、代表的なツール。要求管理など、多少関連するツールの話も出た。

事例では、細部で参考なることはあったが、むしろ使う際にそれぞれ創意工夫しながらやってるという基本的なことが皆さん共通項に思えた。ツールの細部への要望が飛び出したりもして、より一層そのように感じた。モデル設計で仮想的に動くのが面白くなって設計過剰になったり、かえって時間を浪費するなどの話も出て、運用的なことへの工夫も行っているんだと感心した。

ツールの説明時は、各ツールとも特徴的なことがコンパクトにまとまって分かりやすかった。astahの海外使用が増えてきておりその事例では、意外な所での利用の話もあって面白かった。

パネルディスカッションの場でだったと思うけど、関連する事項として「インダストリー4.0」の事がちらっと出た。ヨーロッパ(ドイツ?)における産官学による、言わば工場のIT化への取り組み。直接SysMLとは関係ないけど、モデリング→高速製品化と考えると、無関係でもないというか究極的に目指すものが見えてくる。日本の場合はモデリングというとITとかETロボコンのそれが浮かぶけど、製造業を含めた製品化・サービス化への利用も視野に入れておかないと、ヨーロッパ(ドイツ?)などに負けてしまうということも少し頭の隅に入れていて良いのだろう。

また、受け付け脇に質問パネルがあって、パネルディスカッションではその中からの質問も扱った。単刀直入な「ツール開発にツール自身を使ってますか?」との質問があった。Rhapsodyとastahは、部分部分で使用しているとのこと。EAはEAを使っての開発とのことで、逆に開発のための機能(その場では特にメール機能)まで備えているとの説明があった。人によっては、EAになんでメール機能まであるのかが理解できた人もいた様子。

3つのツールの差別化というか特徴のショート説明では、価格の件や国産製のことなど、皆さん感じている事のいわば復唱みたいな感じ。やはり、それぞれ一長一短だ。

フランクなセミナーだったが、そのお陰もあって有意義な情報を得られたと考える。機会あればまた開催してほしいし、(事例発表者などで難しい側面があるかもしれないけど)他の地方での開催もあってもよさそうとふと思った。


なお、個人的にちょっとした”アハ体験”だったのが、SysMLでの”satisfy(充足)”。satisfyは、SysMLでの要求とブロックの要素間の関係を示すもので、ある要求があるブロックで満たされるということを記述できる。実はここ1,2ヶ月間、システム開発などでのモデリング絡みで考えていた事があった。(新しい)OSでのとある機能を利用して実現したいということは、結構発生する。以前のクライアントサーバーへの移行などでも発生したし、昨今のスマフォでのゲーム開発でも少なくないだろう。結局要求が実装と結構結びついてる。

なので、実装を隠蔽する方にむしろ無理があるのではないかと考えたり、それらの結びつきを上手くモデリングというか図示できるほうが良さそうと思いをめぐらしてた。satisfy(充足)はSysMLでは最初からあったかは覚えてなかったり、そのような疑問時にSysMLを直ぐに調べなかった事を猛反省。さらに言えば、SysMLには要求図というものがあり、要求分析でユースケース図とどちらで検討した方が良いかか考えるべきとも思った。ユースケース図のほうが少し変わったアイコンなどもあって見栄え的にはいいんだろうけど、、、。

9月 27, 2014 ソフトウェア | | コメント (0) | トラックバック (0)

2014年7月22日 (火)

ICSE'14勉強会(東工大)へ

今日は、「ICSE'14勉強会」で大岡山の東工大へ。「ICSE'14勉強会」は、ICSE(イクシーと言う人が多い)2014という国際的な学会での論文を、1日でなるべく多く読むというもの。輪講というよりもラントニングトークスに近いかな。主催は情報処理学会 ソフトウェア工学研究会 国際的研究活動活性化WGで、ここ3年ほど続けている。100近い論文のうち、そのほとんどを網羅。今年は93/99で、網羅率94%と言ってた。

「ICSE'14勉強会」のサイトは以下。
http://qwik.jp/se-reading/10.html

当日などのtogetterがあって、以下。
http://togetter.com/li/696308


情報処理学会主催ではあるが、USTREAMで様子を流したり投票を行ったりしてるし、結構フランクな発表も少なくなかった。ある意味若者寄りの運営で、進行やテンポもいい。逆に結構内容的には濃厚で、昼休みや終わってからは少し頭に疲労感が残った。また、大阪、名古屋、福岡をネットで繋ぎ、東京以外にも発表者が分散している格好。ちなみに発表者は大学生が多かったけど、NTTデータやIBMなども人もいた。

なお、講堂のようなところだろうとか玄関に掲示があるだろうと、建物名はメモしたけど、階や部屋の名前をメモしてなかった。そのため、建物内をうろうろ。再度建物の入口に戻って、それでも掲示無かったら(駄目もとで)守衛所で聞くか諦めようかなと思ってた。そしたら知り合いと遭遇。部屋名も知っててラッキーだった。

また、休憩時に声をかけられ、別の知り合いにも遭遇。一応オニギリなどを事前に購入してたけど、昼食はその知り合いと学食へ向かった。食事しながら色んな話をして、懐かしかったり世の中の動きで参考になる見方なども聞けて、有意義な一時になった。


論文はソフトウェア工学全般に渡ったけど、印象的にはテスト関係が多かった気がする。投票で好評だったのがM2:Unit Test Virtualization with VMVMで、テスト関係。ちなみにM2はテストケースは減らさずに高速テストするアイデア。(ただし初期化で共通的なものはまとめてテストするというもので、結構色んなところでやってると思うのだが。) また、Mutation testingに関する発表もあった。

テーマ的には古来からあるテーマでも、モバイルやクラウドを意識した論文になってるような感じ。また、そもそも(大)昔なら、その大学や企業でのプログラムなどの分析での論文だったと思われるが、今回の多くは、オープンソースのモジュールを解析したり分析したりしていた。ある意味、題材がクラウドにあると言ったイメージ。

なお、省エネ(Webのページの配色を省エネになるように設定)やソフトウェア理解(脳波による分析)では、面白い試みもするもんだな~と思いつつ、論文としての掘り下げが少ない気がするものもあった。


蛇足だけど、東工大の大岡山は久しぶり。20数年ぶりぐらいかな。そもそも入口が開放的になってるし、ビルとかが増えたイメージ。驚いたのは、犬の散歩禁止や、大声出さないでの掲示。結構構内に書かれてあった。声の件は、学生にというよりも、構内で遊ぶ子らに対してのもの。犬も似たようなもんで、(小さな?)庶民悪。また、今回の会場のビルは、研究室に入る時は、上履き着用。エレベーターや階段からの所で仕切られてて、そこで履き替え。研究室フロアそのものがカーペットになってた。(知り合いと話したら、富士通の山本卓眞元会長の考えの影響とか言ってたけど、本当か?)


今回の勉強会は具体的に参考になりそうな考え方もポツリポツリとあって、勉強になった。都合がつけば来年も参加したいと思う。情報処理学会(を含め他の団体も)このようなイベントは実施・継続すべきと考える。やっぱ最近の動向を色んな人の目線で聞けるのは貴重だ。そうしないと(古い)教科書のコピペだけになって、進歩から遠ざかってしまう。ふとそんなことも思った。また、本催しでの網羅率に拘る事への反対意見があったけど、100%必須とかでないのなら、今の形態が良いと思う。やはりスピード感があるように思えるし、駄目そうなものでもアイデア的には面白いものがあったり、難解なら難解である旨が分かるのは良い事だ。


7月 22, 2014 ソフトウェア, ソフトウェアテスト | | コメント (0) | トラックバック (0)

2014年7月18日 (金)

回路図もガラパゴス

2日ほど前に、Twitterでつぶやかれた「無駄な抵抗」。

 https://twitter.com/m9_mukyuu/status/489214129463234560

それ自体は、クスッと笑えるような投稿だったが、知り合いとかと話題にしたのは、そこでの抵抗記号。いわゆるギザギザタイプで書かれていた。自分も1年ほど前に知ったけど、このギザギザ記号は古くて、新しい記号になってる。なので、教室とかの黒板に書かれてたというのは、専門的な学科などでは考えにくいかな~というもの。(そこでの話題は、取り立てて問題視してるわけでもなく、単なる補足的な話題提供レベル。)

以下はたまたま自分が持ってた、「電子機械」(実教出版 平成24年発行)という工業高校用の教科書。その表紙裏の記載。抵抗器は長方形になっている。
P7184830_2

どういうことかというと、これらの電気記号はIEC(国際電気標準会議)で定めてて、JISもそれに則っている。が、JIS-C301(旧JIS記号)とJIS-C0617(新JIS記号:IEC 60617に該当)があり、新JISでもどちらを使っても良いとしている。ただし図面の中では統一しなさいとしている。

新JIS記号では抵抗器が長方形になっており、ここでの教科書は新しいJISに則っているというわけだ。

自分が抵抗などの記号が変わったのを知ったのは、「トランジスタ技術」2013年3月号での回路記号をつらつらと眺めている時だった。

以下はその雑誌での、2つを併記説明している部分。
P7184831

ヨーロッパ等への輸出時は、CEマーク認証の為の図面等の提出は、IEC記号つまり新JIS記号での記載が必要となる。なので、輸出とかが多い企業では、新JIS記号が使われている(はず)。

それでも、新JIS記号が一般に浸透してない大きな理由は、ここで挙げたCQ出版などが旧JIS記号に拘ってるのが大きいと思われる。本屋さんで新JIS記号での記載の書籍を見つけようとしてみたが、電験(電気主任技術者試験)やその対策本と、他は本当に数える程度。そもそも本屋さんでの電気のコーナーにはCQ出版の本や雑誌が多いので、当たり前とも言える。「トランジスタ技術」もそうだし、無線関係もそう。我々ソフトウェア技術者に少し馴染みのある「Interface」もCQ出版である。

グローバル化の中で、旧JIS記号に拘るのは問題じゃないの~とか、日本のガラパゴス携帯のことが言われてるけど、回路図自体がガラパゴスというわけだ。日本の電気屋さんが、世界の潮流に取り残されてるようにも思えた。つまり、欧米と新興国が新JISというかIEC図面でやり取りしてるのを傍らで見てるというか、、、。(ちょっと皮肉りすぎだろうけど。)


だが、話がそれだけでは済まない、、、、。同じ「トランジスタ技術」2013年3月号の別ページに記載されているのが以下。論理回路の記号で、左の方は馴染みのある人は多いと思うが、MILスタンダード。右の方が今まで述べた新JIS記号。
P7184832

MILスタンダード(MIL標準)は正式には「MIL-STD-806」で、MILはアメリカ軍の調達のための規格。MILスタンダードは、論理回路の記号として日本では幅広く定着している/定着していた。

MIL標準も、実際は廃止された規格になってしまっている。(正確には、参照とかもあるしJISでも旧記号を使用してよいとしている。) MIL標準(MIL論理記号)のウィキペディアは以下。
http://ja.wikipedia.org/wiki/MIL%E8%AB%96%E7%90%86%E8%A8%98%E5%8F%B7

論理回路の記号に関しても本屋さんで調べてみたが、教科書的な本で新JIS記号での記述はすぐには見つからなかった。ネットでは、新JIS記号で書いてあるものがあったり旧JIS記号との対比で意見を書いているページもいくつか見つかったが、新JIS記号への反発の意見もちらほらあった。

大学の授業ではどうかがわからないが、論理回路の記号はMIL標準が多いのかもしれない。ちなみに、前述の「電子機械」という工業高校用の教科書の論理回路部分は、MIL標準で書かれている。

また、論理回路に関しては、IECの新しい記号は複雑な回路の記述には適しているとの考えがあるようで、逆に授業程度の簡易回路なら旧JISでも十分だし、敢えて新しい記号のために資料や本を修正する必要も無いとの考えは、そう不自然ではない。

P71948462P71948472左は、昔自分が使っていた情報系とMIL標準の定規。ここ何年、いや何十年、特にMIL定規は使ってない。

そもそも昨今は、ソフトウェア屋さんがハード図面を作成することは皆無だし、論理回路図で議論することは少ないと思われる。さらにはハードウェア屋さんも、海外EMSなどの作成に任せて回路図とかのチェックすら少なくなっている気がする。論理記号を意識する人の絶対数が減っている。なので、論理記号の変更の件は、あまり話題に上ってないのだろう。


さて、抵抗の記号などの時に電験のことを取り上げたけれども、論理回路とかなると情報処理技術者試験の事が気になる。調べたら、以下に、試験で使用する代表的な記号・図などの規定が書かれている。

http://www.jitec.ipa.go.jp/1_02annai/annai_yogo_jis_kyu.html
 情報処理用流れ図など :JIS X 0121
 決定表 :JIS X 0125
 計算機システム構成の図記号 :JIS X 0127
 プログラム構成要素及びその表記法 :JIS X 0128

電気回路や論理回路の記号に関しては、規格を明確には記述してない。


個人的には何でも欧米に合わせるとの考えは好きじゃないけど、電気回路や論理回路の記号に関しては、試験や教科書は順次新JIS記号にした方が良いと考える。特に(入門的なものでは無くて)実務を意識した場合は、どのみち企業内では輸出等の関係で新JIS記号というかIECに則ることになる。そうであれば、新JIS記号で習得していた方がいいだろう。教える側の論理より教わる側の論理で考えたら、明白だと思うのだが。


「回路図」

「論理回路」

「工業高校 教科書」

7月 18, 2014 ソフトウェア, パソコン・インターネット, 技術 | | コメント (0) | トラックバック (1)

2014年3月 5日 (水)

再考 メイヤーズの三角形問題

知り合いのTwitterのつぶやきで、表題の「メイヤーズの三角形問題」が取り上げられた。ある数値の組み合わせが、どんな三角形の種類なのかというもの。つぶやきでの考えが自分の考えとちょっと違ってたので、「メイヤーズの三角形問題」をもう一度考えてみた/再読してみた。

メイヤーズの三角形問題とは、書籍「ソフトウェア・テストの技法」の冒頭で取り上げられている、読者への試験みたいなもの。

Myers_1st上のAmazonのは、日本語訳の第2版。左のが日本語の初版。もう35年以上も前の出版で、言わば古典。

なお、第2版ではXPの事などが追記されてるが、本三角形問題の細部で表現などが異なっている(後述)。また、Amazonでは”マイヤーズ”となっているが、ここでは訳本内でも書かれている”メイヤーズ”の表現を用いる。

問題は、第1版ではカードから/第2版では入力ダイヤグラムから、3つの整数を読み込んで、その数字の組み合わせで不等辺三角形、二等辺三角形、正三角形のどれかを印刷/表示するプログラムに対するテストケースを書きなさいというもの。

メイヤーズが記載しているのは、13個のテストケースと、1つの予想される出力を示したかというもの。13個の中に、1つの辺がゼロになるものをテストケースに含めているかとか、1つの辺が負数のものをテストケースに含めているかというのがある。14点満点だけど、プログラマの平均得点は7.8点であるとのこと。また、「全ての可能なあやまりを見つけられると保証はしないが」と述べてて、細部は自分で考えなさいとのスタンスだ。特に14番目でのエラー時のメッセージ(細部仕様)は、各自で考えなさいと暗に示していると個人的に考える。

さて、ここから細部になるけど、12として非整数の話しがある。第1版では非整数のこととしか書いてないが、第2版では”2,5,3.5,5.5”と例示がなってる。つまり数値が4つ。多分、本当は5.5は無いのだろう。(個数が異なるテストは13にある。ただし、例示は2つ。)

Twitterので知り合いとのやり取りでは、0詰め数値のことが言われていたけど、それをテストに含めるのは良いことかもしれない。0詰め数値は、3を”03”のように表記する方法。

ちなみに、例示されてるのは”3,3,4;3,4,3;4,3,3”のような表現。";"を便宜的なデリミタと考えて、3と3と4が1つのカードに書かれているなどと読めばいいのか、デリミタなども含めて記述されてるかによるけど、それらに関するテストも気になった。つまり、先に述べた4つ書かれているケースとか、デリミタまで含めて記述さていたら、”,”の代わりにスペースだったり別記号だった時のテストなどもあった方が良さそうである。

整数でないものとして例示は少数だけど、アスキー文字なども考えられる。

再度深く読んでみると、こんなテストケースもあった方が良いのとか思い付いたから不思議なものである。そもそも第2版は、GUIによるもので、GUIに絡むテスト項目は無いように思える。疑るような視点で再読してみることをお勧めする。(もしかしたら、検討した人とか検討した発表があるかもしれない。ちょっと探してみる。)

また、ここで示されてる条件でテストを請け負えるかとか、どんなテスト計画にするかとか少し膨らませて考えるのも悪くないかと思う。あるいは示されてることをRFPとして、十分と言えるか、あるいは何が不十分かと考えたりするのも悪くない。

なお、第2版と第3版は、カード→入力ダイヤグラムや印字→表示への変化以外に、有効な数値組み合わせという表現から、意味のあるという表現に変わっている。ただしこれは訳上の変更かもしれないが。久々に版による違いなどが面白いと感じた一時でもあった。


3月 5, 2014 ソフトウェア, ソフトウェアテスト, 書籍・雑誌 | | コメント (0) | トラックバック (0)

2013年8月23日 (金)

三人寄れば文殊の知恵が、、、、、まとまらない

ここ1,2週間、数人での作業が発生した。イメージ的には文章の手直しの作業で、時々意見の相違が発生した。「てにおは」の修正のような(ある意味)微々たる事項から、論理的な文になってないなど様々。ある意味そのための作業であり仕方ないし、話すことで妙案に進展したものもあったが、各自の考え方の相違で多少平行線のものがあった。似たような作業でのここ1年くらいでは、ヒートアップ度やその回数が一番大きかったかもしれない。

で、ふと思い出したのが、開発時の会議や設計ドキュメントのレビュー時の意見対立。直接レビュー会議のような場での意見提示でなくても、トラッキングシステム(大昔なら紙に記載してその紙を回覧しながらコメント記入)でも相反する意見が出ることがある。書いたのがAさんなら、修正案がBさんから出て、別修正案がCさんから出たり、元々のAさん記載が良いとの意見が出たりする。

ものの本ではレビューの必要性などが書かれているけど、レビューの必要性よりもどう収束させるかが悩ましい。その部分は、大昔から良い解法がないように思う。ある意味ではレビュー技法などが発展してないとも言えるし、レビューを実施している人達はレビューに関する記事や論文を余り当てにしてないのかもしれない。より正確な表現を使えば、レビューを実施している人達にとって参考となる記事や論文は少ないのかもしれない。

もちろん、論理的/合理的な説明で収束したり実験検証に委ねたりするケースもあって手法もあるが、リーダー格が「えいやっ」で判断せざる終えない局面もある。平行線になった場合、そのような判断を誰かがしていかないと、効率が悪くてしょうがない。

ここ1,2週間での作業で、意見の相違が多かったのにそれなりにまとまったのは、リーダー格を明示的に決めていたことだったろう。当然と言えば当然だけど、今回は皆さん意見がばらけるかもとの意識があったせいかと思う。

ちなみに、”インスペクション”手法での役割として”モデレーター”があるが、ここで言ってる意見集約での責任者という意味では、個人的にはちょっと違うと認識している。ファシリテーターに近いし兼ねることが出来るかもしれないが、合意形成を素早く行ったり判断が必要な点でも少し異なるように思える。なおここでのリーダー格がちょっと大変なのは、せっかく合意形成が出来たり自分が判断したのに、特に上司や他部門によりひっくり返される時があること。しかし、まっ、こればかりは仕方ないと割り切るしかない。


さて今回の作業などで、つい思い出したことがある。2つのプロジェクト。片方は開発ドキュメントもそうだが、特許明細とか営業やユーザ向けの文書チェック作業も発生。冒頭で書いたような「てにおは」の修正にも神経を使ったそうだ。(大変だったろうが、後述するプロジェクトよりは遙かに精度が高いことになる。)

もう一つは聞きづてのもので、納品物のドキュメントに対して「○○が書かれてないから記載して欲しい」とか誤字脱字の指摘を行った人の話。委託先から一言あってPLも誤字脱字“ばかり”指摘するのもと、修正に消極的。他の件もあって、システム化への意識のもなく横柄なPLとの印象もあって、結構プロジェクトそのものに幻滅したとのこと。本人は、不明な未記載ロジックの記載が主で、誤字脱字はついででの指摘のつもりだったのだが。

結局、納品物はそのままOK。検収とか支払いが絡むからだったのかもしれないが、何のための納品チェックなのか??? 修正などを見越してないやり方だったと言える。案外、請負や丸投げでの根本的な問題なのかもしれない。


つまりレビューをすることの必要性などが記事や論文で書かれているけど、それをそう反映するとか、契約と絡めて議論していかないと/組織体で解決策を持っていないとメリットが生まれない。逆にレビューをやっているところは、反映方法や契約と絡めた対処法をより向上させるべきだろう。

8月 23, 2013 ソフトウェア, プロジェクトマネジメント | | コメント (0) | トラックバック (0)

2013年8月22日 (木)

ソフトウェアのお掃除タイミング

しばらく前から気にしてた事項に、ソフトウェアのメンテナンス時期があった。OSSなどを使っていたらセキュリティパッチの情報により、更新したりが必要である。プロダクトラインでの管理をしていたりそうでない場合でも、他機種での変更情報が自分担当の機種に関係するかが気になったりする。

開発中や直近で出荷したものならまだ開発メンバーもいるが、出荷後に期間を経た場合はメンバーが別部署に異動しているケースもある。あるいは退社したり、委託先の会社が消滅していることもありえる。

組込み機器の開発でない場合でもセキュリティパッチへの意識は同様だし、ITシステムの場合は利用側からの変更要望が発生したりする。

セキュリティパッチの場合は、パッチ発生の度に対応していたら効率が悪いことがある。再テストもそうだし、多少厄介なのがパッチリリース自体にバグが潜んでいるケース。かといって対応を延び延びにしていては、忘れてしまったりして重要なトラブルになってしまうことがある。次機種や次のITシステム開発の場合でも、従来のソースコードを見直さないと潜在的なバグが次機種などで発生することがあったり、リファクタリングのための工数が見極めにくい。

つまり、問題発生時や新機種/新システムの開発に向けてのソースコード見直し以外に、ソースコードを綺麗にしたり問題点を見つけておくことが必要だ。ソフトウェアのメンテナンスをコンスタントに行っておく意識が必要。また、集中的なソースコードレビューは行われるだろうが、どうしても重要な部分に限定されたり、時が経つと修正などが入ることがある。自分の経験則では、リーダーのような直接タッチしてない人が何気にソースコードを眺めた時にバグやコーディングルール逸脱が見つかることがある。そう考えたら、ふと家事の特にお掃除のスケジューリングってどうしてるんだろうとか、どう教えてるのか気になった。


で、自分の卒業した高校には、当時”家政科”なるものがあって、同窓会のちょっとしたイベントの時に聞いてみた。「授業で、家事のスケジューリング方法とか教えた?」と。返事としては、習わなかったし実際の主婦でもスケジューリングまでやってる人は少ないかもとのことだった。ある意味、予想どおり。

そこで、ネットで調べると授業の格好でまとまっているのは見かけなかったけど、個人ブログで各自の工夫として掲載しているのはいくつか見つかった。もっと良いのがあるかもしれないが、見かけたのは以下。

http://kajirakuraku.com/cleaning001.html
月と週でスケジュール表を作ってみようというもの。

http://ameblo.jp/kajino-chie2525/entry-11442422842.html
どちらかというと、年/月レベル主体でのスケジューリング。

http://ameblo.jp/logica/entry-10460566887.html
ファストフード店などの掃除の仕方を参考にして、表に掃除する日をマークして、実施したら名前を書くようにしようとの提案。

皆さん、それぞれ工夫している。


そうこうしているうちに気になったのが、事業所での掃除や害虫駆除。法律での背景があるように聞いたので確認してみることにした。(法律が根拠と思ったけど、実際は法律に直接書かれているわけではなくて、基準での運用だった。)

http://www.sharosisikaku.com/backnumber/anneihou/20060318.html
掃除や害虫駆除に関してフランクにまとめてあった。

http://www.mhlw.go.jp/bunya/kenkou/seikatsu-eisei10/
厚労省の「建築物環境衛生管理基準について」のページ。

半年に1度は大掃除をして、害虫がいないかの調査をしなさいとある。


他を参考にする限りでは、曜日や月を決めてソフトウェアのメンテナンスをするのが良さそうだ。また、それらはソースコードをいじっている人以外も巻き込んでスケジュール案を検討するのがよいと言える。暗黙なり明確に、その組織体でルールを決めて実施したかの確認まで行と良い。

(掃除をしたかしないかが一目瞭然なように)ソースコード上のどこを見直したかが視覚的に分かるように工夫したり、出荷後に期間を経た場合でも定常的な業務項目としてノミネートしておくなどすれば完璧だろう。

追記:2013/12/18のNHK「あさイチ」で、掃除術を放送していた。

http://datazoo.jp/tv/%E3%81%82%E3%81%95%E3%82%A4%E3%83%81%28%E6%B0%B4%E6%9B%9C%E6%97%A5%29/689108

その中で登場したのが”予定掃除表”。冷蔵庫や換気扇の掃除予定に○をつけておき、実施したら塗りつぶすというもの。予定の横軸は、曜日だったように思う。

8月 22, 2013 ソフトウェア, 品質 | | コメント (0) | トラックバック (0)

2013年7月23日 (火)

情報処理学会「デジタルプラクティス」 ”ヘルスケアの現場を支えるIT”

今度の情報処理学会「デジタルプラクティス」の特集は、”ヘルスケアの現場を支えるIT”。さらっと読んだけど、面白い。実践分野の話しがほとんどだし、(デジタルプラクティスでも時々ある)論文のための理論こねくり回しが少ないように思う。

デジタルプラクティス単体でも、Amazonで購入できるそうだ。


実務を踏まえての論文が多いので、分かりやすい。苦労話や今後の課題と感じることも具体的に書かれている論文が多く、(他の分野でも)参考になるだろう。思い付くのは、カルテの閲覧への要望が多くて対応したが、対応したら対応したで分かりにくいとか医者の記載が横柄に思えるとの苦情があったそうだ。ある意味仕方ないと言えるが、その対策として、カルテ部分に内部用の欄を設けたとのこと。海外や地方への展開の際の、法律とか医師会への配慮のことなども書かれていた。

システムの構築と共に事業運営との問題や、虚偽データの扱いなど、結構本質的な問題にも触れている箇所があって考えさせられた。

また知らなかったシステムの紹介もあって、自分の健康維持などに役立ちそうなものがあった。具体的には、全国の血圧の上昇度合いが分かる”にっぽん血圧マップ”。時々アクセスして、自分の血圧データと比較してみたいと思う。(”にっぽん血圧マップ”への要望/切望としては、過去データを見ることができればと思う。せめて1月前程度はクリックか何かで見ることができればありがたい。)


興味あれば、購入して読むのも良いかもしれない。なお、価格が情報処理学会誌と同じような価格で、多少躊躇するかもしれない。今回の号はある程度見合ってるとは思うが、デジタルプラクティスの趣旨などを考えると、もう少し安価にするなども考えて良さそうに思う。

7月 23, 2013 ソフトウェア, テクノロジー, 技術, 書籍・雑誌 | | コメント (1) | トラックバック (0)

2013年7月22日 (月)

「モデルベース開発」 dSPACE Japan(監修)

副題に、―モデリングから、プラント・モデル、コントロール・モデル― と記載されている本。何気に本屋さんで見つけて購入した。帰りの電車の中で斜め読みして、買って良かったとの印象の本。

ちなみに以下での(P~)は、本書でのページ数。

まず監修になってる「dSPACE Japan」だけど、メカトロニクス制御のハードウエアやソフトウエアソリューションを手がけてるドイツ dSPACE社の日本法人。個人的には、コンサル的な活動も少なくないように思う。日本法人は2006年に設立されている。

本書は、dSPACE Japan以外に日産やスマートエナジーという会社の合計4人による共著に近い。結構分野が違ったり、数式的なモデリング主体の話しだったり機能安全を含めたモデル開発の進め方の話しだったりと、千差万別。それらの違いが多少違和感になる時もあるが、幅広く知ることが出来るメリットの方が大きい。ちなみにモデリングでのシミュレーションツールはほぼ、MATLAB/Simulink。また量産コード生成ツールとしては、dSPACEのTargetLinkによる説明になっている。


実務寄りの話しが所々出てきて、モデル開発を行う意味での注意点というか課題などが明確なのがよい。実務者にとっては常識的なことでも、少し違う分野の実務者とか、これからモデルベース開発をやろうかと思っている人にも参考になろう。

具体的には、量産コード生成ツールの高いコード効率への要求として、コントローラの1円コスト増が1億円/年の収益源になる例えの話し。ただし、1000万台/年で平均10台のコントローラでの算出。(P21) 変数のバイト数を固定小数点演算にして2バイトあるいは1バイトにすることでのコスト低減になる話し。(P47)  Simulinkでのブロック線図からCコードへの変換での、遅延処理まで含めた最適化の例の話し。(P47~) 計算負荷=実時間での計算での問題点。(P87) 実装での量子化された値への対応を行うためのアイデア。量子化での具体例として10ビット分解能のA/Dコンバータ。(P120) など。


欠陥生成ユニット(FIU)の話(P57)や、モデルベース開発と機能安全に関しては章を設けて説明している(第5章)。若干ではあるが、コンポーネントベース開発にも言及している(P128)。高信頼性化としても、参考になると考える。


数学モデルが所詮モデルであるし、精度の高い数学モデルを構築しても計算手法での限界があるとの意見も述べられている。(P194)  自動車会社の取り組みも紹介されており、本田技研のシミュレータで全ECU連携(P89)や日産の全てのエンジン制御ソフトウェアにモデルベース開発採用(P130)。 日産の事例は、どの部分/全部のモデリングかなど多少気にはなるが、モデルベース開発が浸透していると言うことだろう。

ソフトウェア技術者に一読を勧めたい一冊。

7月 22, 2013 ソフトウェア, 書籍・雑誌 | | コメント (0) | トラックバック (0)

2013年7月13日 (土)

「コードクローン分析とその応用」

今日は日本技術士会と情報処理学会とのコラボの、表題の催しへ参加した。一般の人が見ることができて、細かいことが書いてあるのは、以下のITコーディネーターのページかもしれない。(技術士の場合は、ここでの料金とは別。)

https://wwu.itc.or.jp/fmi/xsl/seminar_guide_n/seminar_s02.xsl?ID=K13060730

大阪大学の井上先生自らの講義、しかもワークショップがあったので、掘り下げて学ぶことができた。

CCFinderとGeminiの説明があり、ワークショップもその両方を使っての分析だった。というか、今まで自分はGeminiの方を余り詳しく知らなかったが、クローン分析ではGeminiを使っての分析が(も)重要と認識した。(コードクローン分析の、裁判への資料への活用なども紹介もあって、なるほどと納得した。)

我々の班が分析したのは、Python。思った以上にクローンが多かった。どうも、OS毎や型毎の部分をコード生成している。スピード優先しているんだろう。#ifdef などを多用している感じ。で、多少自分の頭の中で、それならソースコードもだけど、プリプロセッサー前のソース“文”を処理できた方が良いのかな~とか、あれそうなると文字列変換とかが絡むとちょっと厄介か~とかが頭を駆け巡った。また、トークン数との表現とコード辺の数との表現の意味的な違いなどが的確に分からずについ色々考えて、分析でのアイデアとかまとめの際の作業が少しおぼつかなかった。

懇親会も開催されて、そちらで修士の方に、トークン数/コード辺の違いを聞いたりして多少は理解できた気がするけど、まだすっきり状態ではないかも。^.^; また、一時期のブーム的な状況と、現在とでは何が違うのか気になった。自分なりの解釈ではなんとなく、利用しているところは利用してるけど、その成果をなかなか発表しにくい感じ。経費的なこともあるし、その企業や製品群の開発方法やソースの“癖”とかに関係するので公にするのを躊躇するのかもしれない。

また、プリプロセッサー前のソース“文”での解析とか、知り合いの大阪大学出身と井上先生が年齢的にも近いから先生が知ってるか聞こうと思った。しかし、前者は自分なりに考えがまとまらないし、後者は卒業年や学部などが同じか考えているうちに、先生のお帰りになる時間になってしまった。(帰って調べたら、どうも同じ卒業年/学部のように思えてきた。学科も同じかも。知り合いに会う機会があれば、そちらで聞いてみようかな。 なお、懇親会なので、他の人との会話などもあってちょっと挨拶のタイミングを失ったのも大きな理由。)


振り返るとある意味、短時間というか少し分析が不十分だったかもしれないが、座学よりも非常に多くのことを学んだ気がする。今回のような学会とのコラボの催しへの参加は何度かあるけど、今回も有意義だった。

7月 13, 2013 ソフトウェア, 技術士 | | コメント (0) | トラックバック (0)

2013年7月 7日 (日)

Feedly iPad版が動かない

「Googleリーダーは、Feedly へ乗り換え」で書いたように、RSSリーダーはFeedly へ乗り換えた。結構気に入ってはいるが、iPad版と、PC版というかクラウド版とで、見栄えや操作方法が結構違う部分は気になっていた。

RSSのグループ名の表示文字数などの関係で、iPad版の利用は皆無だったけど、Googleリーダーのサービス自体が終わったこともあって、iPad版のバージョンアップがあったり操作性の統一が図られたのかなと思って、iPad版を操作してみた。新しいソフトがリリースされていたのでバージョンアップ。

ところが、 'Over Capacity'というエラーが出て動作しない。再度Googleへのアクセス許可をやっても同様。Feedlyを削除して再インストールなどを行っても同様だった。最初は、Feedlyでも、バグである旨は掲示されていなかったような気がする。最近はバグと書いてはあるけど、どうもクラウド版と接続できるように大きく変更しているようだ。(Feedlyの変更だけでは済まないのかもしれないけど、、、。)

iPhone版のFeedlyはサポートされているとか、iPadでも別のアプリ経由でFreedlyへアクセスできるようだけど新しいアプリをインストールするのは躊躇している。今のところ、iPad版のFeedlyのリリースをしばらく待つ予定。

それにしても、向こうのソフトは、サポート不十分だったり急にサービス停止したりするから厄介だ。まっ、恩恵もあるんだから仕方ないんだどうけど、なんかアナウンスの仕方など工夫が欲しいところ。

7月 7, 2013 ソフトウェア, パソコン・インターネット | | コメント (0) | トラックバック (0)

2013年7月 4日 (木)

ロボットコンテスト ルールのモデルは?

今日、たまたま目にしたのが「水中ロボコン」。正式名称は、「'13水中ロボットコンベンションin JAMSTEC」。

http://aquarobo.com/jamstec/

JAMSTEC でやるんだ~とかキヤノン財団が協賛なんだ~とか目について、さらっとルール(公式ガイドブック)とかを見てみた。

水中(のみ)で動作するのは大変だよな~と思ったら、水中のみの動作でなくても良いし、遠隔操作でも良いとのこと。つまり、船からつり下げてさらに人の遠隔操作で船を動かしたり的に当てるようにしても良いことになる。船からつり下げるタイプでも良いことに気が付いたのが、ルールの中盤辺りを読んでからだった。(正確には、自立型と遠隔操作型とでは部門を別にしているようだが、、、。)

そのためふと、「ルールがモデルで記述されてれば、早めに気が付いたのかな~」とか思った。ところが、ETロボコンなどにはモデル化したルールがあるような気がしたが、見つからない。そう言えば、今までルールを読んだことがあったけど、普通の文章だったような気がする。

なんで?と気になった。UMLロボコンの頃を含めると10年以上経過しているし、そもそもモデリングも題材にしているコンテストなのに、ルールがモデリングされてないのも不思議と言えば不思議。ITプロジェクトなどで契約がプロジェクト計画の元ネタなどになったりするけど、ルールという要求事項がモデルになっていれば、それ以降の作業も楽になりそうだ。あるいは、ロボコンの審判をモデル化することで、審判の自動化もできそうな気もしてきた。

逆に、ルールをモデリングできないということは、モデルの限界が明確と言うことか、、、、、。(モデル化する人や手間がないのかもしれないけど、それを出題にしても良いかもしれないし、ルールを考える人達の学生さんなどを授業等の一環で活用するのも良いかもしれない。)

なんか、ついそんなことを考えてしまった。

7月 4, 2013 ソフトウェア | | コメント (0) | トラックバック (0)

2013年5月31日 (金)

ソフトウェアにおける「故障モード」

Facebookで知り合いの書き込みにコメントしたら、どうもソフトウェアにおける「故障モード」って整理されてない/一般的なものが存在しないようだと判明。探せば見つかるのかもしれないが、広まっているものがないように思えた。

ちなみに、CiNiiで「ソフトウェア FMEA」で検索すると19件、「ソフトウェア 故障モード」で検索すると7件ヒットした。未公開などの中に良い情報があるかもしれないが、読める論文だと、故障モードが詳細すぎる気がする。(今回ブログに書いたのは、それも理由。) またCiNiiで「FMEA」で検索すると249件、「ソフトウェア 故障モード」で検索すると119件ヒット。

と言うことで、自分の勉強も兼ねて、ソフトウェアにおける「故障モード」について考えてみた。本来は実機器や実システムでの故障モードを考えるべきとか考えるのが普通だけど、多少一般化できないかとの思いで記述。

ちなみに自分自身の「故障モード」やFMEAでの経験だけど、知識として知ってはいても実践はほとんど無い。実践と言っても、概算を机上で考えて重要そうなものを書き出す程度。装置やシステム全体のFMEAを全部記述して算出まで行うのは自分も経験無いし、ハード屋さんのそれも見たことがないように思う。(ハード屋さんは、MTBF算出の方が結構重要だったと思う。)


Fmea_pdf故障モードを具体的にイメージできそうに思ったものが左の二つ。


それぞれ、左の書籍での記載からである。

構成部品での故障を識別できる文言で記載し、上位構成要素(上位システムとか全体を含む)への影響を記載してある。他に発生頻度や重要度を記述し、その対応の必要性を検討する。例示したものは、分かりやすいと感じた。

ただし最初で述べたアクセスしやすい論文では、ソフトウェアのFMEAではトップダウンでのFTA手法と対比を意識するためか、細部の部品での故障に拘ることがあるようだ。ここで例示したような基板やある程度の機能の括りで考えた方が良い(と考える)。

また、記述する”故障モード”であるが、ソフトウェアの場合でのバグ分類のように分類する時/人がいる。仕様漏れで誤作動といった具合。それもおかしい。むしろユーザーとかサービスマン目線で考えるべきだ。(製造時のFMEAを検討する時があるけど、その件とは別で、あくまで一般的な故障モードでの話し。)

上記を敢えて書くのは、特にシステムの場合は、メカやエレキから構成される機器(サブシステム)や基板などが存在し、システムや機器の故障モードを考える場合は、メカやエレキによる故障モードと構成部品や故障の粒度を似たものにすべきであるためである。そうしないと”ちぐはぐ”になり、FMEAの結果を見るサービスマンなどが混乱してしまったり対応の検討も悪いものになる。

また、昨今ではクラウドを利用したソフトウェア開発が少なくない。その際にHDDやメモリーの故障は避けて通れないし、むしろそれを前提に設計する。それと同次元で、ソフトウェアの故障も考えて検討する意味でも、故障の粒度は似たものがよい。


さて、一般的な”故障モード”について。前述の「FMEA手法と実践事例」などでも記載されているが、「IEC 60812;FMEA」での”一般的な故障モード”は以下の4つ。

速めに動作
規定された時間に動作しない
規定された時間に停止しない
動作中の故障

ちなみにJIS Z 8115では以下のように表現している。

故障モード 故障状態の形式による分類。例えば,断線,短絡,折損,摩耗,特性の劣化など。

「FMEA手法と実践事例」では、IEC 60812;FMEAなどをもとに、それらを少し詳細化したり、電気系の機器ならこのような故障モード、電子部品ならこのような故障モードというのが参考として書かれている。例えば、電気系機器や電子部品での故障モードとしては、開放(断線)、短絡(出力が0)などである。


なお、従来のFMEAの考えは構成部品が上位へどう影響するの目線での検討であった。ところが、ソフトウェアの場合は、自分たちの構成部品でないものの影響で全体がダウンするなどがありえる。PCでの自分たちのソフト以外がメモリーやCPUリソースを喰ってしまい、PC全体がダウンするようなケースである。ある意味では、(自分たちの関与しない)他の構成部品からの”攻撃”で、自分たちの構成部品がダウンしてしまう。ウィルスが端的な例である。

ネットワークが絡むと更に”攻撃”への意識が必要な場合がある。具体的にはDoS攻撃などである。一般回線でない機器内のバス結合に近い状況でも、特定の構成部品の故障が結合路へ思わぬ負荷をかけたり、他の構成部品を故障や不正動作を誘発することがある。

CAN(車載ネットワーク)やフライバイワイヤー(航空機の操縦・飛行制御システム)のように、人命などに関わる機器での構成部品間のネットワーク経由での結合が普及している。特殊な通信経路や形態もあるが、汎用的なネットワークケーブルによるLANでのシステムも少なくない。また、機器内にそれらのネットワークを持つと同時に、サービスマン用やクラウドとの接続でWANと繋がる場合も多い。ネットワークに絡む故障モードは、大きな課題でもあり意識が必要とだろう。

他の構成部品や自分たちと関係しない部品やネットワーク経由の処理が、自システムや自システムに影響を及ぼす故障は、FTAでの検討も一つの方法かもしれない。FTAはトップダウン思考なのでマッチしやすいとの考えであり、FTAとFMEAとのハイブリッド的に考えた方が良いとの考えは組織体によるかと思われる。ただし個人的には、冒頭で述べたように、そう全体を整理することはないので、FMEAで”全体”(あるいは他からの影響)というものを構成部品に加えてボトムアップ的なFMEA前提で考える方がよいと思うのだが、、、。


さて、FMEAの検討の際によく利用されるのが、HAZOP(IEC HAZOP)であろう。以下で、HAZOPでのガイドワードをしめす。ちなみにこの一覧は、名古屋工業研究所の小川氏などによる表の、分類~外れの表現部分の抜粋である。


分類 誘導語外れの表現
存在 (existence)無 (no)質文は量が無い
方向 (direction)逆 (reverse)質文は量が反対方向
他 (other than) その他の方向
量 (quantity)大 (more)量的な増大
小 (less)量的な減少
質 (quality)類 (as well as)質的な増大
部 (part of)質的な減少
時間 (time)早 (early) 時間が早い
遅 (late)時間が遅い
順番 (order)前 (before)順番が前(事前)
後 (after) 順番が後(事後)


それらを踏まえて、ソフトウェアの故障モードの私案を示してみる。冒頭で述べたように本来は具体的な機器やシステムでのソフトウェア構成部品の故障モードで考えるべきだけど、ここでの故障モードはある程度汎用的と思われるものにしている。


故障モード 備考
ソフトウェアが存在しない(本来より少ない) 起動してない、起動後(他とのバージョン不整合などにより)自身でexit、killされた、、、
ソフトウェアが本来より多い (規定以上の)二重起動、終了せず
ソフトウェアが動いていない ハングアップ、(一定時間)応答無し、起動後自身でループなどで停止
リターン値が異なる 正しくない値をリターン
リターン値が異常 範囲外や型異常
リターン個数が異なる 多い、少ない
リターンデータが異なる 浮動小数点の微少部分、画像・音声データの微量部分、、
リターンデータが異常 リターンフォーマット異常
リターンタイミングが異なる 早い、遅い、順番が異なる、タイミングがブレル
アクセス異常 アクセスすべきでないものへアクセス。DBへのアクセス、フラグ/GUIなどデータ領域へのアクセス、他ソフトとの通信、他デバイスとの通信
アクセス方法が異常 物理的/論理的にアクセス方法がマッチしてない
アクセスしてない 物理的/論理的にアクセスしてない
アクセスデータ書き込みの値が正しくない値 間違った値のDBへの書き込み、データ領域への書き込み、他ソフトとの通信、他デバイスとの通信
アクセスデータ書き込みが異常値 異常値のDBへの書き込み、データ領域への書き込み、他ソフトとの通信、他デバイスとの通信
アクセスデータ読み込みの結果が異なる/異常 間違ったデータを取り込む。DBからの読み込み、データ領域からの読み込み、他ソフトとの通信、他デバイスとの通信
アクセスデータへのアクセスタイミングが異なる 早い、遅い、順番が異なる、タイミングがブレル

さほど多くない。逆に、もっと個数を絞っても良いかもしれない。(既に述べた、PCなりシステムがダウンするのは、これとは別に構成部品=全体として故障モードを考えればよい。そちらでの故障モードの個数は、多くても数個だろう。)

Facebookを契機にソフトウェアにおける「故障モード」を考えてみたけど、自分なりに気づきも出てきて勉強になったと言える。故障(モード)の検出を分かりやすくするには、どうしたらいいか。ここで示した故障モードでも、うまく区別しきれない状況もあり故障モードとして統合した方が良いのか、あるいは区別できる方法を考えるべきか、、、、。今回のをたたき台にして、ブラッシュアップすることも頭の隅に入れておきたい。

5月 31, 2013 ソフトウェア, 品質 | | コメント (1) | トラックバック (0)

2013年5月22日 (水)

「テストから見えてくるグーグルのソフトウェア開発」

今日、何気に本屋さんの本棚見たら、表題の「テストから見えてくるグーグルのソフトウェア開発」が1冊置いてあった。

平積みでなかったし、以前(今思えば予約注文だったか)にAmazonとかで見た気がしたので、結構前の出版かなと思った。

ところが巻末見たら、今年の5月23日の発行。パラパラと内容を読んだら結構面白そうで、則購入。

グーグルでの初期の頃のソフトウェア開発やテストの様子、そして現在のことが具体的に書かれてる。GmailやAndroid、インドなどいくつかのグループのテストのマネージャーとのインタビューがあり、話題も多岐に渡っている。

まだ全部読んでないけど、気になった事項をメモ。

・関連する職種として、SWE(ソフトウェアエンジニア)、SET(ソフトウェアエンジニアインテスト)、TE(テストエンジニア)。

TEが開発とは別の外部テストみたいに受け取った。ただし、ドッグフーダー(リリース前の社内利用者)や早期ユーザーとの協力関係もマネジメントするとのこと。

・テストを単体テスト/統合テスト/システムテストと分けずに、Sテスト、Mテスト、Lテストと表現。Sテストは(一般的な)単体テストというか自動テスト化。Lテストはユーザー視点でのシナリオテスト中心。システム全体のテストとして、Eテストなる呼び方のテストが最近出来た/言われるようになった。

・「プロトコルバッファ言語」なるものがある。公開されており、データ構造などの定義に使われる。JavaやPythonなど実際の言語での処理が、予め用意されてる(ひな形はある)感じなのだろう。 SETは、本コードの記述をレビューする。

・Buganizaerなるバグ管理システムがある。バグ票のフィールドで必須なものはごくわずかで、定義を曖昧にし、個々のチームがそれぞれのワークフローに応じて決めることができるようにしている。

・BITE(Browser Integrated Test Environment)と呼ぶ、ブラウザに統合されたテスト環境があり、テストの実践などをブラウザとクラウドで処理する。


インタビューなどの細部を含め、自分たちでも利用できそうな考えや手法などがちりばめられている感じがするので、じっくり読んでみるつもりだ。

5月 22, 2013 ソフトウェア, ソフトウェアテスト, 品質 | | コメント (0) | トラックバック (0)

2013年5月17日 (金)

「共通フレーム 2013」

とある所で「共通フレーム 2013」を見て、早速購入。ソフトウェアライフサイクルプロセスで、SLPC-JCF 2013。

ただし、この数日間で新宿の紀伊國屋と神田の三省堂に行っても、2013版は売ってなかった。2007の2版のみ。結局Amazon経由で、購入した。

理由は後述するけど、共通フレームに興味があれば、2007年の2版よりも2013版を入手すべきだ。

P5172547P5172548良い機会だったので、今までの共通フレームの本を並べて撮影。少し分厚くなった。

P5172549_22007年の2版から色々変更されているけど、自分が一番重要と思うのは左の写真。(スキャンでなくて、敢えてデジカメ撮影とした。)

上が2007年の2版で、下が2013年版。2007年でのピンク部分が、2013年版では大きく2つに分かれている。2013年版でのそのうちの上段がシステム開発での目線、下段がソフトウェア開発の目線(呼称的には「ソフトウェア実装プロセス」)である。

2007年の2版までは、ソフトウェアライフサイクルモデルをISO/IEC 12207に準じていた。ところが、”システム”ライフサイクルを定めたISO/IEC 15288が発行され、12207との整合性は当初から話題となっていた。 ちなみに2008年には整合性のために改訂されたが、整合性の第一ステップであり、共通フレームの改訂にまでには至っていなかった。(ISO/IEC 15288のJIS版で、整合性の件には触れていたはずだが、勘違いなら済みません。)

また、ISO/IEC/IEEE 29148があり、そちらは”要求工学”規格と書かれたりすることもあるが、原題は”Systems and Software Engineering – Life Cycle Processes – Requirements. Engineering”。つまりこちらも、システムまで含めた要求管理やライフサイクルの規格である。

今回の共通フレーム 2013では、ISO/IEC 12207と、ISO/IEC 15288やISO/IEC/IEEE 29148との整合性を図っている。ある意味では、”やっと”出版されたとの感想に近い。

ISO/IEC 12207が非常にまずかったのは、ソフトウェアが大きな1つの固まりのように捉えて、設計や実装、テストが進捗するように考えやすい点だ。少なくとも共通フレームなどの図をそのまま受け取って、そう思う人が少なくない。

今回は、上の写真が示すように、システム内のソフトウェアを実装するとの考えである。また、図ではシンプルに表せないので仕方ないが、ソフトウェアがいくつもあって、それらが並行して進捗するイメージである。ITシステムとか組込みでのシステムでの開発は実際はそうで、規格の方がそれらをうまく表現するようになったとも言える。(並行して進捗するイメージというかいくつかのサブシステムより形成されるという点は、規格での明示としてはISO/IEC 15288のJIS(JIS X 0170)での付属書が、参考になるだろう。)

その意味で、本屋さんに2007年の2版があったとしても、2013版を注文するとかネット経由で購入すべきだろう。特にソフトウェア開発を含めたプロセス構築やプロセス改善では、(2007年版ではなく)2013版を参考にしながら行った方が良い。


なおご存じと思うが、共通フレームワーク上のソフトウェア実装プロセスでのプロセスは(正式名称ではないが)以下であり、単体テスとか受け入れテストなどのプロセスはない。

・準備
・要件定義
・方式設計
・詳細設計
・構築
・結合
・適格性確認テスト
・導入
・受入れ支援

2007年版だと開発プロセスに該当するが、各プロセスは大きくは違わない。(2013版での構築プロセスが、2007版では”コード作成及びテスト”としているなどの違いはあり。)

つまり誰が考えても、開発プロセスに”受入れテスト”があるのはおかしい。受入れテストはユーザー側でのプロセスで、開発側ではユーザーへの出荷がOKかの判定とか、ソフトモジュールならリリース判定のようなものが該当するはずだ。ISO/IEC 12207や共通フレームワークでは、当初から”受入れ支援”とか”受入れテストの支援”という用語であり、あくまで”支援”という文言の付いたプロセスとしている。

”ISO/IEC 12207準拠”とか”12207でのプロセス”の文字の後に、(単体テストや統合テスト、)受入れテストが書いてあるのは、極論すると内容も眉唾と考えても良いことが少なくないのが個人感想だ。


「共通フレーム 2013」は、まださらっとしか読んでないが、随所に参考になりそうなネタも少なくない。じっくり読んだり、プロセス構築やプロセス改善の際には手元に置いて参照しながら作業したいと思う。

5月 17, 2013 ソフトウェア | | コメント (0) | トラックバック (0)

2013年4月26日 (金)

「医療用ソフトウェアを巡る最近の規制動向等について-その現状と課題-」受講

今日は、「医療用ソフトウェアを巡る最近の規制動向等について-その現状と課題-」という講演を受講。医療機器関連の話で、自分の場合は関わりの少ない分野。タイトルにもある、医療用ソフトの規制動向が気になって受講した。

以下は、主催者での開催一覧。(しばらくしたら、今回の講演はなくなってると思われるけど。)

http://www.pmrj.jp/kenshu/html/frm050.php?cate=5


会場に150人位いただろうか。医療用ソフトウェアに関する研究会(経産省、ただし文科省や厚労省とも連携)や日本経済再生本部での話、そして薬事法改正との絡みが大きな柱だった。

なお、技術的な話し以外に、一部健康ネタとして興味のある話も出た。(国立循環器病研究センターでの”かるしおレシピ”。センターでの減塩料理のレシピで、25万部売れたそうだ。)


結構断片的だけど、興味を持った事項。勘違いや聞き違いはご容赦。

・医療機器に関連する3団体(JAHIS、JEITA、JIRA)のことを、3Jと呼ぶ。講演では”トリプルJ”と言ってた。保健医療福祉情報システム工業会 (JAHIS)、電子情報技術産業協会(JEITA)、日本画像医療システム工業会(JIRA)。

・ソフトを組み込みソフトとスタンドアローンソフトに分けているが、後者は汎用ハードを利用したソフト。汎用ハードはPCやスマホで、外付けに専用ハード(医療機器)がつながってもスタンドアローンソフトと呼んでいる。

・さらに単体ソフトという言葉もあり、スタンドアローンソフト+組み込みソフトでインストール等により医療機器と一体となるもの。

・単体ソフトの扱いが、他国と比べ、日本は規制が不明確だった。結果的に、スタンドアローンを含むソフトの開発が遅れている(国際的な競争力にも影響)。なお、電子カルテは、ここでの規制とは別扱い。

・規制との関連を考える意味で、極端な例はスマホでの万歩計など。それらが医療行為と結びつく時に、どう考えるべきかなど。

・今後の日本での規制整備の方向性としては、IEC62304がベースになると考えられる。

・「欧米の医療用ソフトウェア規制の外観」を講演したソニーの鴛田氏は、元は富士フイルム。欧米での審査対象の技術文書のことが話された。FDAでは(リスクにおけるクラス分類に依存するけど)、テストケースを1件単位で文書提出。

・講演での説明やQ&Aで、医療点数とか(医薬品などでの)共済制度との、関連や同じような仕組みが必要かもとの話/意見が出た。

・Q&Aでは、宮城県での震災に関連しての230万人レセプロクラウド化の件が事例として紹介された。

・医療機器ソフトでのアップグレード(での規制)に関しては、製造業とサービス業にまたがる事になるので留意。

・欧州の認証機関制度がしっかりしている(金銭的に回るようになってる)件や、日本でのマイナンバー制度との関連も話題となった。

・Q&Aでは、医療データの蓄積や活用に関して、日本の方が個人情報の関連かデータが集まりにくいとかデータ収集/提出に消極的な側面の話も出た。

・個人的にはQ&A自体は良かったけど、途中から会場からの2人程度か委員会メンバーらしき人の発言が長いし多少内部ネタ(を臭わすような)話だったのは、勿体なく感じた。筋道だった議論にならず断片的すぎたため。


会場では「知っておきたい薬害の知識」などの本が、割引で購入できた。結構食指が動いたけど、そうお金の余裕があるわけでもないので断念。ちらっと内容を見たが、良くまとまってると思った。(可能性は低いけど)薬害などで調査することがあったら、図書館で探すとか購入しようと思う。

なお、講演を聴きながら、日本で規制が曖昧ならソフトを出したらどうなったかと思った。質問しても良かったろうけど、愚問っぽくて止めた。帰って薬事法を調べたら、製造と販売で(それぞれ)罪になる。

さらには、医薬品などでの医療現場での臨床試験自体が結構高いハードルで、少し緩めようとする/したとのことがネット記事などに出ていた。それを考えると、医療用ソフトウェア(正確には、医療用かグレーなソフトウェア)を開発しても病院などでの実験で引っかかってしまっていたのだろう。実験なり臨床時に、病院の先生が「これは医療用ではない」とか「医療用とは言えない」と言いにくい/言いにくかったのだろう。ましてやソフトを使用して「医療用ではない」とは言い切れない。日本でのグレーなソフトウェア開発が二の足を踏んでたのは、その辺りが理由に思える。


結構充実し、勉強になった半日だった。

4月 26, 2013 ソフトウェア, 技術 | | コメント (0) | トラックバック (0)

2013年3月18日 (月)

WBC グリーライトのサインも一長一短

今日の昼。ふとTVの前を通ったら何人か見てて、なんだろうと思ったらWBC(ワールド・ベースボール・クラシック)の準決勝。日本対プエリトリコの試合で、8回裏の日本攻撃だった。1,2塁という場面で盗塁したんだけど、(2塁の選手はすぐに戻り)1塁からの選手がアウトになって、皆さんため息になってしまった。

その時にテレビの解説の人が、サインに関して「グリーンライト」がどうこうと言ってたので、さっき調査。テレビ解説者も少し述べてたけど、盗塁を選手の判断に任せるというものらしい。今回のWBCでの日本のチームは結構多用したようで、少し前の台湾戦でも用いて得点に駒を進めたようだ。

解説を聞いた時に、野球にもそんな指示の方法があるんだとか、自主性に任せるのは悪い事じゃないよな~とか考えた。ただし今回の状況は、1,2塁の出塁時。いくら自主性に任すと言っても、1,2塁の各選手の息が合わないとうまく行かない。なので本当にグリーンライトのサインだったか、個人的には疑問だ。

プロジェクトで、自主性に任せることは時々経験がある。なかなかプロジェクトマネジメントの教科書に出てくるテーマではないが、実践の際には留意している事項。ソフトウェアテストでは「殺虫剤のジレンマ」を回避する意図もあって、テストケースとして”***部分は担当者の考える値でテストすること”として、敢えて値や方法を記載しない事も行われる。

プロジェクトやソフトウェア開発でも、自主性に任せても良さそうな時と、それではまずい時があるので、使い分けが必要だ。今日のWBCのプレイを見て、ふとそう思った。

3月 18, 2013 スポーツ, ソフトウェア, プロジェクトマネジメント | | コメント (0) | トラックバック (0)

2013年3月13日 (水)

軽めの品質のために

先だってのセミナーも含めて、以前からソフトウェアに対して、軽めの品質管理やテストをどう考えたらいいか思いをめぐらしてた。技術的な考えは後日にでも記載するけど、今日は、アナロジーとして的確と思えるのを見つけた/考えついたので紹介する。

自分自身が少し体育会系なので、以下の「陸上競技ルールブック2012」。(年度でタイトル変わってるかもしれない。)

http://www.jaaf.or.jp/athlete/rule/

ここに”第3部 トラック競技”と”第9部 クロスカントリー競走”があり、さらっと対比してみると良い。そもそもページ数が、38ページと4ページ。トラック競技だとmm単位の記述。クロスカントリーはシーズンだって”冬期期間に行われるべき”とか、”魅力的な”や”おおよそ”なんていう非常に曖昧な表現などが目に付く。

自分でも正確に知らなかったけど、トラック競技での風速測定は定められてて、100m競技だとスタートから10秒間。スタート前の計測でもないし、全員ゴールまでの時間でもない。当然だけど、スタートの記載は”スターターの信号器の発射(閃光/煙)”。

クロスカントリー競走は大抵芝生の所で開催されているけど、ルールブック上は”可能な限り草で覆われた”との表現。自分が事前に想定してたよりも、遙かに記載がアバウトだった。


でソフトウェアの世界では、ここでの例の、クロスカントリーの競技のくせにトラック競技のルールブックで話す愚行を行ってるケースがあまりに多い気がする。

そもそも、競技種目に相当するユーザや必要とされる使われ方が異なるのに、つい同じ土壌(例だと陸上競技)で括ってしまう。それなりの素地(元々のメンバーの能力とか今までの信頼性)があった上で厳密な手法などを話すのならいざ知らず、より高度な技法の説明に終始することもある。せっかくクロスカントリー競技で競う/楽しもうとしてるのに、妙にトラック競技のmmの話を持ち出されて興ざめするようなシーンに近いだろうか。

背景としていろんな手法や技法を知っておくのは良い(悪くない)が、組織体内の議論やセミナーでのグループ討議のための情報では、その組織体やグループに応じた手法や技法を元に議論すべきと考える。

3月 13, 2013 ソフトウェア, ソフトウェアテスト, 品質 | | コメント (0) | トラックバック (0)

2013年3月10日 (日)

「アジャイルなテストの見積りと計画づくり」

今日は、「アジャイルなテストの見積りと計画づくり」のワークショップへの参加。イベント案内はZusaarでのイベント案内を参考にして欲しい。また、ハッシュタグは、#NagoyaTesting。ハッシュタグを利用して当日も情報のやり取りをしているので、当日の資料や題材のWebプログラム、我々グループのテスト項目や発見したバグ一覧も辿って見ることができる。

案内を目にして、しばらく経ってから申し込んだせいか、補欠になってしまった。懇親会のビアアッシュに先に申込みする格好になった。結構その時は参加希望が多かった。ところが直前になってキャンセルがあり、繰り上がりで参加できることになった。

ただし、パソコン持参とのことで急遽使用できるように準備。最近ノートPCを使ってないせいか、セキュリティパッチやディスク容量が少なくなっていたので、それらの対応を行った。7日の夜から少しづつ準備しようとしたけど、ディスク容量が少ないことで、不要なアプリを消して少しセキュリティパッチを繰り返すやり方になった。

今朝の出発前でもセキュリティパッチが動いたせいか、シャットダウンに時間がかかってる。強制電源Offしてワークショップで起動しないのは避けたかったので、そのままバッグへ。当初が補欠だったこともあり、ちょっと慌ただしい朝での準備となった。

多少はヒントになるだろうと、「アジャイルな見積りと計画づくり」もカバンに入れた。結論から言えば、この本は今回は電車の中での予習としては役に立たなかったかな。やはりというと変だけど、アジャイルのしかもテストに関する実践主体のワークショップを前にパラパラ見るような本ではない。今回のワークショップがシステムテストなりブラックボックス系のテスト主体の話だろうとのことは分かっていたので、その視点での予習にはあまり役立たなかったという意味。「実践アジャイルテスト」はホワイトボックス系のテストの話だし、自分的に実践とも少しかけ離れている感じがしてるし、、、。皆も手探りのように思える。

ちなみに、電車の中で、お受験風の親子連れが乗り込んできて、なんか問答してる。それなりに大きな声だったので、そっちに気が行ってしまった。社会の工業地帯のお勉強だった。結構暗記してる子だったけど、佐世保で有名なのが“笹かまぼこ”との返答には苦笑。そんなこともあって、予習は実質ゼロ。

少し早めに会場の最寄り駅に着いたし小腹が空いていたので、丼屋へ行ってから会場に向かった。会場はオラクルさん。(オラクルさん、会場提供を含め色々ありがとうございました。)

本来は、Zusaarでのイベントでの自分の番号をメモしておくべきだったんだけど、繰り上がりだったこともあってよく読んでおらず番号の件で少しアタフタ。係の方で調べてくれたけど。ちなみに、プレートにはTwitterアカウント名などを記載。入門証というかQRコード書かれた紙をもらって、そちらでゲートイン。

テーブルについた後は、知った人にちょっと挨拶。それにしても、周りはほとんどMac。自分のPCは、Windowsで表カバーにアップルのカラーシールを貼っているもの。無線LAN使えるとのことだったけど、昨日のうちにイーモバイルを使えるようにしたのでそちらを利用した。(自宅での悪戦苦闘の末にイーモバイルはUSB接続にしたけど。)

11時からのスタート。セッションスタートの最初に、テーブル(グループ)内で自己紹介。自分を含めて、6名。Web系の人が多かったけど、組込みとか企画系が半分という感じ。自分は、この分類ではシステム絡みの組込みかな。全体的にも、テスト系(テストが主)の人は皆無との印象。運営サイドにテスト系の人がチラホラいたけど。 

グループ内のアジャイル実践程度は、微妙にまちまちだったかな。どっちかというと暗中模索しながらやってる人が多いみたいなイメージだった。なお、この類で、趣味の話が出ると和みやすいというか、その後の作業がしやすいと実感した。趣味とその後の作業は直接関係しないけど、思考方法がある程度類推できるというか、、、。

以下、自分の感想を踏まえて様子を記載する。(ワークショップでの講演なども良かったけど、ここでは多少批判めいた記述が多くなって済みません。まっ、自分を含めての今後の参考ということで。)


その後は主催者の説明が2時間ぐらい。13時になって昼食&昼休みだった。タイムテーブルをちゃんと見てなかったし、弁当出るとは出ていたか? 一瞬、それなら丼を食べなくても良かったかなと思ったけど、13時まで続いたから丼食べてて丁度良かった。

スライドは以前30分で講演したのを利用(?)したみたいだけど、2時間でも時間が足りない雰囲気だった。足りないというか、ネタ的に色んな事が含まれてて人によっては消化不良の部分もあったかも。というのも、ソフトウェアテストでのテストレベルやテストタイプ、ISO 9126とかリスクの事にも触れており、非常に幅広い内容。

主催者によるテスト実践の話が出て、具体的で良かったと思う。ソフト開発とは別にソフトウェアテストのタスクボードを用意して進捗管理を行う方法。組み合わせテストを事例としたテスト(タスク)見積りの話も出た。ちなみにテストの複雑度を1~80としてるとかで、個人的には細かすぎるとの印象。また、話にも出たが、プロダクトオーナーの役目や開発とテスト側のやり取りでの見直しなども発生するので、ターゲットとなるソフト種や組織体の雰囲気などによって採用しやすいかが決まるように思う。

(つまり、一般化しやすい/他で利用しやすいとは言えないと感じた。なお、どんなことでも当て嵌まる話として、一般化することよりも、良さそうとの意識があるなら各自が持ち帰ってどう自分の組織体に填め込むか考えれば良い。ただし今回の件は、プロダクトオーナーや開発とテストとがあまりに密でお互いにカバーし合う状況でないと、適応が難しそうだ。そんな組織体が少ないだろうという意味。)


昼食後&昼休み後は、少しおさらいして実習へ。与えられたWebプログラムの仕様書というか概要を元に、グループでテスト計画書/テスト仕様書を作成するというもの。テスト計画書との話だったと思うけど、IEEE 829のような本来の計画書ではなくて、むしろテスト仕様書の作成だったようだ。(テスト仕様書というよりも、テストケースの集団の検討を意識しているようなので、テスト屋さんにはテストスイーツのような言葉の方が通じやすかったかも。もちろん、テスト屋さんは少なかったけど。)

Webプログラムは、作業(タスク)の追加とか変更、項目による並び替えなどが出来るもの。ただし、当初はドキュメントのみを見てテストケースを考え、テストケースを主催者・事務局に見せてOKをもらえたら、WebサービスのURLを教えてもらえるという方法。

我がグループは、最初リーダー的な人と進捗把握の人を決めた。まっ、アジャイル系とかファシリテーションの絡む実習とかでは良く行われるパターン。ただ、一応決めた(と思った)けど、明確なやり取りは無く、誰か(実質2人だったか)が残り時間を時々教えたり、リーダーはダイナミックに変わるようなイメージ。

で、ついグループ作業の最初の方で「テスト観点の説明もあったけど、テスト観点って分かりにくいんだよね~」と口火を切った。まっさらの状態でテスト項目を考えるということでは、かえってテスト観点は邪魔との考えによる。ただし形勢は不利で^.^;、2対4。4人でジャンケンをして、うち1人にこっちのサブグループに入ってもらった。

実習の前に、変更に強い/変更しやすいテスト仕様書とか、(途中からだったか)そのテストでどんなリスクが回避できるかはっきりさせた方が良いとのコメントがあった。帰宅時の電車で思ったことは後述するとして、リスクの検討は当面無視というか、シンプルなWebアプリなのでリスク検討はさほど重要でないと考えて作業した。

変更の事を言われたので、さらっと仕様を復唱して、どんな要望が出そうかを軽く検討。それで変化に強いテスト仕様にとも思ったけど、そもそも変更が具体的でなく検討も含めて我がサブグループは消化不良だったかな。(本件も思うところを後述。)

で、別のサブグループは、テスト項目をGoogleスプレッドに入れてた。こちらはポストイット。決めた時間後に「せぇの~」と見せ合いっこしたら、結構似てた。つい「あれっ、テスト観点を主体に考えると言ってたのに~」と言ってしまった。^.^; 逆に、その後は、こちらのテスト項目を追加したり、考えの相違を検討すれば良かったので作業は楽になった。GoogleスプレッドのURLをTwitterでつぶやいて、ハッシュタグ付けることで、他の人もそのスプレッドへアクセスするという方法。

実は、自分のPCではGoogleスプレッドがうまく見えなかった。ぎりぎり容量でIEは6のままにしてたせい。多少焦ったり、こんな事ならiPadを持ってきても良かったかなと思った。今回はネットサービスの利用だったので、iPadでも作業できたかなと感じた。(ただし、やはり文書作成というか文字入力や編集の手間の件があるから、iPadで実作業できたか不安だけど。)

グループ内で、変更に強くするにはとか、リスク軽減やテスト目的などを少しまとめて判定依頼へ。で判定結果は「検討不十分」。その時にリスク軽減などを言われたのかもしれないが、再検討。他に見積りなどもその時に言われたのだったか?

見積りに関しては、意見色々。そもそも積み上げ式で行くにしても、どんな技法使うかとか、それらの意見を集約させるかなども課題。プランニングポーカーみたいにしたらと(一応)言ってみたけど、反対も無かったし賛同も無し。優先順位の件とか色々用語は飛び交ったけど、うまく収束していかなかった。結局、今回の実習でテストに○○分が与えられるので、それでテストできそうかとか、それに間に合わそうとの話になった(ような、全員賛成でなかったけどその方向だった)ように感じた。

個人的には、アジャイルでのテストの見積りの話をするなら/それが重要とテスト派が言うのなら、そもそも従来のテストの人達の見積り手法を明示すべきと思う。アジャイル系というか開発系からすると、今回の簡易なWebサービス等で、テストに焦点を当てた見積りが必要か?? 開発とテストを一緒に考えて、ストーリー/ストーリーポイントを考えるのが普通だと言える。メンバー全員がそうかは不明だけど、見積りに対して消極的だったのは、テストの(厳密な)見積りの必要性そのものが理解に苦しんだからかもしれない。

それでも、リスクの検討とかテスト目的とか、それっぽい見積り結果の言い方を用意して、2回目の判定へチャレンジ。(これも、グループ内には、まだ不十分との意見もあったり、駄目なら3度目にチャレンジで良いじゃないの意見もあり。)

結果的には、実習の時間のことや、主催者のチェック担当の人の関係も(他に温情も?)あって、Webサービスの実体のURLを教えてもらった。具体的には、ハッシュタグ付きの私宛のつぶやき。(ハッシュタグで他のメンバーもそのURLを知る方法。)

2回目の判定では、ユーザーシナリオが甘いとの指摘もあった。一応テスト一覧に書いてるつもりはあったけど、グループ内で再検討。実URLを教えてもらう前後だったと思うけど、そのあたりを追加/追記や明記する格好になったと思う。

で、実URLを利用してのテスト実施。効率よくするために、グループ内でどう作業するか議論。結局、元我々サブグループの方が機能(いくつかの画面)のテスト、別のサブグループがユーザーシナリオ系をテストすることにした。我々のグループも、画面で分けたり、同一画面のテストならテスト項目の上からの人と下からの人にした。で、バグをポストイットに書いてたけど、ある人がGoogleスプレッドに入力してくれて、そちらに清書をお願いする格好になった。(それも、ハッシュタグ付きでつぶやいて、皆で情報共有。)

なお、テストしようとしたら自分のPCのIEが古いせいか、画面乱れ。ある意味バグレポート1号。^.^; 結局自分自身はテストはできず、別の人と一緒に作業することになった。

先にバグレポートって書いたけど、使用環境が明示されてないので、バグと言えるか疑問ではあった。また色々操作してたら、そもそも仕様がおかしいよなというのもいくつか出てきた。画面遷移が不自然。それらも項目によっては要望と明記したりして、リストアップした。

一応、異常値とか複数人での同時操作などもテストした。変な文字列というか特殊コード、あるいはクロスサイトスクリプティングテスト入門編みたいなテストも行った。具体的には、(手っ取り早くできた)Tabコード入力。案の定というか、おかしな挙動を発見。

最後にGoogleスプレッドでのバグ一覧を元に、皆で議論。KPT(keep, problem, try)の整理も一緒にやったように思う。もしかしたらKPTの議論は、発表後だったかもしれないけど、、、。

なんかグループの2人間で多少意見の隔たりがあって突っ込んだ意見を言い合って、どうしたんだろうと思った時もあったけど余り気にしないことにした。個人的には悪くないグループ作業。個人的な結論(システムテストとしての合否)としては、社内向けならOKと思う旨は言った。もちろん負荷試験とか、ここでできないテストは別扱い。

で、テスト結果の発表は、我々のグループになってしまった。リーダ役の人が説明して、発表の指名時に自分の名前が呼ばれてしまったし、そのせいで前へ出たらコメントを求められたので、グループ内で意見統一できてはいないけど社内利用はOKに近いと述べた。

その後に総括的な話が出て、希望者はビアアッシュへ突入。

個人的には、アジャイルとの目線では、内容が細かすぎる点が多い気もしたが、実プログラムの仕様や挙動でテストする点は非常に良かった。机上で議論してても、得られることは少ない。特に実践で役立つことが少ない。頭でっかちになるだけのことが多い。その点、今回のワークショップは、メンバーとの議論を含めて、教科書に書いてないような次元での気づきがあった。また、今回の題材になかった事項で自分なりに考えがすっきりした事項もあって、ある意味感謝。


ビアアッシュでは、乾杯や歓談の後にLT(ライトニングトークス)とか個別に質問したり質問受けたり、、、。LTでは、プログラミング言語の堅めの話やメイド衣装の超軽めの話題まで多種。まっ、アジャイルなり若い人達のコミュニティ雰囲気ムンムン。面白かった。(コミュニティには、それそれで重宝する居酒屋とか度々登場する話題などがあり、知らないコミュニティのそれらを知ったりやり取りできるとの貴重。つうか、オラクルの人と少し話したけど、コミュニティの居酒屋=実体験があると、対応なり目線が違うというのが今回の実感。まっ、人によってはたいしたこととは思わないだろうけど。)

で、歓談という状況だったので、お礼を軽く述べて、ストレートに以下を述べたりした。

1)やっぱテスト観点は分かりにくかった。

今回のメンバーや開発系の人が多いと、テスト業界的に代表的なテスト観点をいくつか述べて、このどれかで良いので考えてみてください位が良かったかと思う。ISO 9126も一つのテスト観点だろうけど、今回のような実習でほんとに役立つかは別。

さらに言えば、そもそもテスト観点って何?みたいな基本的なことを述べないと理解は難しいかもと。(と言いつつ、自分自身もうまく理解できてないというか、どうも役立つなりツールや手法に思えなかった。あくまで、すんなり自分なりの手法として役立てようという気になってないという意味。そうでないと、他の手法などもそうだけど、応用が効かないというのが持論。ただし、帰りの電車で、テスト観点に関して「そうか~」とのアイデアも出たので、掘り下げて考えるきっかけになったのは良かった。)

2)テストケースを、ばっさり削る話しもしないと、、、。

色んなテスト関連用語が出て”漏れなく”などの用語も飛び出したけど、今回のテーマのアジャイルにテストする/アジャイルなテストをするという感覚と矛盾すると言える。テストケースを削る話しもないと、なんか従来のテストの話と同じになって、聞いててメリットがなんだったか分からなくなると言える。

もちろん反論はあるだろうけど、アジャイラーの人達が本当に”漏れなく”と言われて納得するか疑問。 逆に、”漏れなく”派とそう考えないメンバーとで、(バグ発見率などを)比較するなども面白いと考える。

もちろんテストケース以外に、テストフェーズのどこかなりテストフェーズの作業/負荷分布を見直す意見を言うなどもこれに関する事項である。

他に、他グループがどれくらいバグ発見したか聞いてみたけど、一応我々の発見件数は悪くない感じだった。グループ内の話の際に、ビアアッシュで他のチームのバグ発見件数も聞いてみますねと言って、一部からは否定的な発言もあったけど。ただし、主催者側では、わざとバグを入れてたとのこと。いわゆるエラーシーディング。それは発見できなかったとのことだった。ちょっと残念。やっぱそれなりの準備をしてたんだと内心感心もした。なお、残念って書いたけど、見つからなかったことと”漏れなく”への否定的な意見とは別。どんなバグが仕組まれていたかにも依存すると言える。

(ビアアッシュなので、意見交換すると実は、、、との話もあって、自分も含めて皆さん悩んでること少なくないんだな~とは実感した。これも有意義だった理由。)


なお、LTの最後というか占めに近いところでは、テストクラスの話が出た。テストクラスと表現すべきかは??だけど。 少し酔ってきたこともあって、途中から席に座ってボーッと聞いていたけど、テストクラスの継承みたいなのをどう実装するかの話のように受け取った。そうであればニーズは分からなくはないけど、ツールに実装できても、(特にテスト系メンバーの)誰が使いこなすかも気になるところだった。まっ、本件はこっちの勘違いかもしれないので、深掘りなども当面先/実質やらないかな。


楽しい時間があっと過ぎて、お礼とか述べて解散。いやー良かった。


帰りの電車の中で、ボーッとしながら考えたのが2つ。

1)仕様追加に強いテスト計画/テスト仕様

実習の時は言ってることが理解できなかったけど、イテレーション(スプリント)への対応のことを言ってるとしたら非常に納得がいった。そうであれば、(時間の制約を除けば)演習の際に、例えば全部が3イテレーションで、第2イテレーションと第3イテレーションのテストをするようにすれば良かったかと思う。

で、仕様追加とかの表現ではなく、イテレーション(スプリント)への対応と言ってもらった方がすっきりしたと思う。演習時に仕様追加ではなく機能追加などの表現だったかも?だけど、少なくともイテレーションを意識して欲しいとの話で良かったと思う。例えば、第3イテレーションで実装されるのは、タスク情報の変更(画面追加)とかにすればいい。あくまで、イテレーション対応のことを言おうとしてたのなら。

さらに言えば、自分の中でテスト観点中心でのテスト設計が嫌なのは、これに脆いと思ってるからだろう。誰が考えても、イテレーションで追加されてくのは(ほぼ)機能。であれば、テスト区分のような事項は機能であるべきだ。少なくとも、その方がイテレーションへの対応が楽だ。

2)リスクと説明責任

演習の際に、テストでどんなリスクが低減できるか示した方が良いとの話が出たと思った。また、テストには説明責任が伴うとの話しも。ここも自分的にはすっきりしない。各テストケースでリスクを考えるのはおかしい。むしろIEEE 829の言うテスト計画書で、よりテスト全般とかその関連として明確にすべき事項である。

今回の実習のようなケースだと、「全体的なテスト計画ではリスクの検討とか説明責任に言及しますが、今回はテストケース検討なので、考えなくても良いです。(興味あれば検討してみてください。)」 みたいな表現が良かったように思う。

テスト全体とか計画レベルでリスクや説明責任を考えるのは必要だろうけど、今回の勉強はそっちではないと言える。

テスト計画なども実習での検討範疇との考えもあるだろうけど、今回のようなワークショップだとむしろ上で書いたような複数イテレーションへの対応などに時間を割いた方がメリットあると考える。


なお、上で書いた2つは、自分なりにもっと掘り下げた方が良いし、ちょっとした思いつきも出た。その意味では、実習やそれに対する(上の意見だと少し過剰とも映る)コメントも、考えるヒントになってむしろありがたかった。

色々書いたけど、実習を伴った有意義な1日だった。もし次回に同類のイベントがあるのなら是非参加したいと思う。


追記:後になって、今回のイベントの運営として、ドタキャンが多かった事が書かれたブログを見つけた。こちらは補欠から繰り上がってラッキーだったけど、運営する側からは弁当などのこともあり収支に直結する問題。勉強会のことが雑誌などで取り上げられてるけど、そんな苦労もあるとか、どう改善すべき/してるかの情報共有も必要になってるんだと実感した。

3月 10, 2013 ソフトウェア, ソフトウェアテスト | | コメント (0) | トラックバック (0)

2013年2月15日 (金)

ETロボコンの部門追加 今までの総括も欲しい

昨日・今日のネットニュースで目を引いたのは、ETロボコンのコンテストが2部門制になるというもの。創造性の高いロボットなり、ロボットの動作が見られそうで、楽しみが増えた感じではある。

ただし、個人的には良い機会なので、ETロボコンにおける「組込みでのモデリングって何だったんだろうか」を総括して欲しい気がする。ETロボコンの発祥は、ご存じのように2002年の「UMLロボットコンテスト」。2002年の最初はUML”のみ”がモデリングの規定だったか分からないが、長く走行時間とモデリング能力の2つがコンテスト対象となった。

組込み屋視点では始めの頃から、以下のような項目は気になった事項。

・モデリング(ツール)を利用して、走行スピードが確保できるか
・処理の全てをモデリングするのか、あるいはモデリングする割合はどれくらいか
・どの程度モデリングツールによるコード生成をするものか
・モデルとして採用されるのは何が多いか
  :

以前は走行スピードの上位入賞者とモデリングの上位入賞者が不一致だったが、最近は両方とも上位にランクされるチームが増えてきた。ただ、そのこととモデリングで高速処理が出来ることを示しているかは別。つまり、同じチームに、モデリングを考えるグループと(モデルは参考にせず)走行スピード検討のグループを設ける作戦もある。それは趣旨に反するだろうけど、少なくとも走行スピードと発表されたモデル(の該当部分)との関連が示されたことは無いように思う。

ただ、モデル(の部分)と走行スピードとの関連を示すのは難しい。ETロボコンでのパネルセッションのモデルを眺めたことがあるが、以前はユースケースの掲示が少なくなかったが、最近はシーケンス図である動作部分のロジックを示す展示が増えたように感じる。パネルでのモデルは、ロジックを示すために利用されていると考えて良いだろう。

モデルのその部分は自動コード生成している/していないはあるかもしれないが、実際の組込み開発でも良く目にする事項だ。つまり、走行スピードに関するソースコードの全部分とモデルの全部分が無いと2つの関連を示すことが出来ないが、モデルで100%コード生成してるとは限らないしモデリング100%が唯一無二でもない。

個人的には上で書いたような必要部分のみをモデリングしているのが実際的だろうけど、せっかくロボコンとして大会を開いているのなら、モデリングの割合などの統計を取っても良いと考える。あるいは、モデリングと走行の相関性を掘り下げたり、モデル→ソースや実際の走行状況の追跡を行っても良いと考える。

後の方に書いたのは結構労力が必要かと思われるので、実現は難しいだろう。しかし、せっかくの節目なので、今までのETロボコンを総括するような語論はあって良い。


追記:オージス総研のETロボコンレポートで、関連しそうなことが書かれていたので紹介。

http://www.ogis-ri.co.jp/otc/hiroba/Report/ETRobocon2012/ChampionshipWorkshopReport/index.html

2013年に向けて「キレイなモデルを評価するのはおしまい、手垢にまみれたモデルを期待」とある。

2012年は、完走率が悪かった。原因を照明とする意見が多い。また組込みならそれへの対応は当然だろうとの意見すらある。ただ後者に関しては、モデリングとのバランスで致し方なかったかも、というのが個人的な感想でもある。後追いでは誰でも言える。また、後になっての要求事項追加のように思えてしまう。

蛇足だが完走率が悪かった原因が照明であれば、それに早期に気が付かなかった大会関係者や、その対応が出来なかったことは反省として述べるべきだ。オリンピックなどだと、風速によって”追い風参考”の記録となるが、あんな感覚が欲しい。今まで大会会場では、マイクで何度も、フラッシュや赤外線の距離計測カメラは使うなと述べている。意識はあったはずだ。今後は、大会向けの”標準”マシンでコースや状況の確認を行う検討などに結びつけて欲しい。(その上で、リスク発生度を大会規定に明示されるのがよい。)

本レポートに書かれている審査委員長の弁は、完走率の低下などに絡めたものだが、今まで再試行とか方法の変更など組込みらしいモデルというか対応説明のパネルもあったように思う。その意味では、委員長の弁は一歩踏み込んだ方向性を示していて良いことだと思う。個人的に、さらに今回書いたようなコード自動生成との絡みやモデル利用率などにも、言及/総括して欲しかったというのが感想である。

2月 15, 2013 ETロボコン, ソフトウェア, テクノロジー | | コメント (0) | トラックバック (0)

2013年2月13日 (水)

ソフトウェア肥大化の行く末

昨日・今日のニュースで気になったのが、電気メーカー「パイオニア」の人員削減。メディアによっては”カーナビなどの販売計画を見直し”となっているが、カーナビが儲かっていないのは明らかと思える。

ここ1,2ヶ月少し気にしていたのが、携帯電話のプログラム行数。IPAとかのセミナーなどで、自動車(カーナビ含む)、携帯電話、DVDレコーダーでのソフトウェア行数が対数目盛で増えていく様子が発表されてた。当時は所謂ガラケーだったと思われるが、その後スマフォになってのプログラム行数のデータがなかなか無い。iPhone(iOS)の行数とかAndroidの行数が書かれているサイトなどはあるようだが、ここで気にしているのは各社独自の部分の行数とか、修正などをやったらその行数。しかも、他のDVDレコーダーなども同様で、行数がそのまま増えていったか分からない。

ただ、察するに携帯電話は、iiOSやAndroidの採用で作成や修正行数は減っていると思われる。DVDは新商品がさほど無くて、横ばいに近づいただろう。カーナビも同様。

電機業界の不振を、DVDや携帯電話、カーナビの不振と捉えると、行数の増える例で示された分野は軒並みダウンというわけだ。以前は、半導体の集積度とか(ソフトウェア利用での)機能アップによる行数アップが言われたが、それらも結局日本の場合は不振業種になってしまった。

そう考えると、行数アップの図は、何を目指そうとしたのか分からなくなっている。つまり、議論として対応が必要そうだとは理解できたが、今となってはそれらの品目自体が売れない/利益を生んでいない。つまり、対応は無駄骨。むしろ行数が増えるとコントロールできなくなるから早めに新分野を開拓した方が良いとのメッセージを発していたら、少しは今と違った状況になったのかもしれない。ふと、そんなことすら思えた。

あるいは、利用する側も、ソフトの肥大化なり機能の肥大化を歓迎してないのかもしれない。パソコン離れも、そんなことが背景にありそうに思えてくる。


実は、ソフトウェア行数の増大の図で、他に記載してあったのが”自動車”。資料によっては”カーナビを含む”としているものもあるが、カーナビと別扱いのものもある。自動車の場合は、各ECUが連携して全体を制御するから状況が多少違う。しかし、ソフトウェア行数の肥大が続いていくのか、あるいはECUの数を増やすなどで対応するのか気になるところではある。  (ちなみに研究レベルでは、ECUの数を極端に減らそうとの取り組みもあるようだが。)

2月 13, 2013 ソフトウェア | | コメント (0) | トラックバック (0)

2013年1月22日 (火)

パッチリリースでのバグ(予防保全とバスタブ曲線)

以前「再考 バスタブ曲線」「ソフトウェアバグとバスタブ曲線」で、バスタブ曲線のことを取り上げたけど、今日興味あるサイトを見つけたので紹介。

http://blog.goo.ne.jp/plant-alpha/e/9b248baf1e47d90f75872f0ae03f0c32

プラントのライフサイクルに関する技術コンサルティングの会社の人のブログ。

7e4d0758e4854e0955d2172a7203d37c特に、その中での左の図。

偶発故障期間に、予防保全を行ったことでトラブルが発生していることを示している。また、その先の方の記述で、むやみに予防保全をすることが、逆にトラブルの頻発を招くことが示されている。


で、この現象は、市場トラブルで対策パッチを出したのに、それが更にバグを引き起こす現象に似ている。よく回帰テストが不十分だったために起こることがあるが、パッチ部分での修正にも一定確率でバグが入っているとの統計的な側面で考えても納得できる話である。

最近一定期間ごとにバージョンリリースするソフトウェアが、ポツリポツリと出てきている。本カーブを考えると、本当に市場投入した方が良いかとか、その期間が適切か再考すべきだろう。

1月 22, 2013 ソフトウェア, 品質 | | コメント (0) | トラックバック (0)

2013年1月11日 (金)

シナリオ作成エディタと、ソフトウェアドキュメント作成

今年の大河ドラマは「八重の桜」。鹿児島(薩摩)出身なので会津のことはよく知らないしドラマを見ることに多少抵抗があったが、映像が良いことや会津を余り知らないことでかえって新鮮に思えて、続けて見ようと思っている。

で今日改めて知ったのは、西田敏行さん演じる西郷頼母と八重の兄の山本覚馬とが、実際は2歳違いである点。(西田敏行さんは、大河ドラマ「翔ぶが如く」では”西郷”隆盛役で、当初そちらも混乱した。)

実は、年末にシナリオライター向けのエディタなどを調査した。(ソフトウェア)文書の生産性という点で、参考になる点があるかもと思ってのこと。記者用の端末なども詳しく調べた方が良かったかもしれないが、個人で手に入れるというわけにはいかないし余りにその分野のための機能が多そうで我々の文書作成とはほど遠い感じがして、フリーのエディタを主に調べた。

「執筆用ソフト」とか「 シナリオ専用のライティングソフト」とかで検索すると、フリーのソフトがいくつか出てくる。ゲームでのシナリオ作成を意図したエディタもあるようだ。ドラマや小説向けのそれでは縦書きの記述が大きな機能だが、キャラクターの特徴や性格などを別画面として(常時?)表示することが可能になっているものが目に付いた。

今回だと、歴史上2歳差だけど俳優さんは年が離れていることなどをメモとして見ながらシナリオを書いていくイメージかと思う。

ソフトウェアドキュメント作成でも、重要な機能などを別ウィンドウで開きながら作成すれば、間違いが少なくなると思った。あるいは、変更事項が分かりやすくなっている文書が別ウィンドウで見ることができるのも良い。(ここでの別ウィンドウでの情報とは、コンパクトにまとまっているものであるべきで、分厚い基本設計書とかその変更履歴を意味するものではない。あくまでその概要レベル。)

例えば、基本設計書の概要部分にそれらを箇条書きしたり、その変更が分かるようになってて、概要部分を取り出して表示できるようにしておくだけでも違うだろう。


ちなみに昔の論文や記事を読むと、ソフトウェアドキュメントに対する校正ツールをポツリポツリと見かける。自動チェックも含めて、文書化での生産性向上やいかにに文書種を減らすかの工夫が大事とふと思った。

1月 11, 2013 ソフトウェア, 映画・テレビ | | コメント (0) | トラックバック (0)

2012年12月16日 (日)

ドキュメント作成やレビューでのイライラ

最近、自分の資料作成や他人の文書レビューに参加して、ちょっとイライラ。自分や相手そのものへのイライラではなくて、文書がうまくまとまっていないとか、ロジックがおかしいと感じてのもの。「そういえば」と、とあるプロジェクトでの様子を思い出した。他のプロジェクトでも大なり小なり発生。むしろ、設計書作成や設計ドキュメントではイライラするくらいが正常と思うようになった。

どういう事かというと、ドキュメント作成時には、そもそもどうまとめるかで議論沸騰。章立てを決める前後は、どこに何を書いた方が良いか悩みが発生する。章立て(見出し)の階層レベルをどうするかも、キーポイントになる。しかも章立てしながら、新しい要望や実装に関する制限が頭に浮かんだりする。

実は、要求工学とか要求開発で、その辺りが知識体系(BOK)として明快な答えが得られるかと思ったけど、無理そうだ。要求開発とかでの妥当性確認(validation)とは、整理された要求項目がユーザ要求と合致しているかとか、ソリューションがユーザ要求と合致しているかの確認である。後者では、元々のユーザ要求というよりも、合意されたなり設計上のユーザ要求と考えて良いだろう。

ちなみに、一般的に「実現性確認」という言葉もあり、ユーザ要求に対するシステム設計が実現できるかの確認を行う。通常は、実現するためのコストなども加味した確認を行う。

当初書いたイライラや悩みは、製品開発の初期にどうのような製品にするかも漠然としている状況で、言わば実現性も検討しながら製品仕様をまとめ上げる過程での悩みである。(ITシステムだと、むしろRFP(提案依頼書)をうまくまとめ上げる作業での悩みに近い。)

小説や映画(文書としては台本というべきか)での生原稿で、いくつも朱書きがある状況がイメージしやすいかも知れない。その後、いく度も推敲を重ね、編集や校正の人の手を経る事になる。

上記で章立てと書いたが、設計とか提案依頼書の作成は複数人で行う事も少なくないので、その作業分担も関することも悩むところである。複数人での作業では、記述の詳細化レベルや表現もばらばらなこともあり、読む側にとってはそれらも気になる。(かと言って、それらの整合性のために余り多くの時間を割くわけにも行かないというのが実情だ。)

逆に、ドキュメントを小さなボリュームの文書に分割して、各々を一人程度で作成することが行われる。それぞれの文書を、それぞれレビューする事が多い。個人的な見聞きでは、大枠が決まってない状態でこれをやると、作業は進んでいるように見えても、ほとんど後々うまく行かなくなる。

設計書や提案依頼書のまとめ上げ方は、案外その組織体での大きなプロセス資産だと思うのだが、どうだろう。


蛇足1:後付でドキュメントを書くことがある。特に多いと感じるのは、システムのちょっとした変更だが実装による制限発生とか使い方での注意点の追記記述。良い例か分からないけどタイムリーなのは、2013年3月のIC乗車券の全国相互利用だろう。システム的には微細な変更だろうが、利用者に分かりやすく説明したり制限を正確に記述するには大変な作業と思われる。設計サイドで書くよりも、ライターとか品質部署の目線での記述が良いかもしれない。あるいは、設計含めたそれら複数グループの協業。

蛇足2:仕様の抜けや漏れが無いようにと言うけど、新製品の適用市場や対象ユーザの想定における抜けや漏れへの意識/(ちょっとした)対策も、結構役立つことがある。

12月 16, 2012 ソフトウェア, 品質 | | コメント (0) | トラックバック (0)

2012年12月 7日 (金)

ソフトウェアバグとバスタブ曲線

昨日「再考 バスタブ曲線」を書いたけど、そこで少し触れた、ソフトウェアのトラブルとバスタブ曲線に関して、、、。

ソフトウェアの出荷後/リリース後のトラブル(バグ発覚)は、ソフトウェアの経年変化がないので、終盤の故障率アップは無い。出荷直後やリリース直後は、テストが不十分だったりしてバグが発覚する。そしてバグ対策されて、トラブル件数は減ってくる。

その意味では、初期辺りは、バスタブ曲線に合致する。その後は安定して利用され、故障率ゼロに推移する。それがその商品やシステムの寿命まで続く。それが、一般的と言えるかも知れない。あるいは理想。

ただし、現実は、そうならない。

1)偶発期間でも一定の故障率

某OSを含めてセキュリティパッチのことを考えると、一定の故障率が続くと考えた方がすっきりするように思える。

ただし、ひどいのは、バグが継続するケース。そもそもテスト不十分等のままでリリース。修正バージョンを出すけど、修正ミスがチラホラ、デグレード、、、、。(製品回収やサービス停止も視野に入れた)抜本的な対策が必要なケースだ。

2)スポット的な故障発生

安定して使われても、時々トラブルが発生してしまう。(当時の開発メンバーが移籍したりしていることもあり、対応が厄介なケースになることもある。)

良くあるケースとして思い付くのは、システムでのデータ量の増大、外部記憶装置の容量不足、ログの増大などがある。

バスタブ曲線に関連したものとして、部品や機器の故障へのソフトウェアの対応が不十分で、それがトラブルの引き金になる時がある。結構対応やテストをした場合でも、複合的な故障の発生への対応が不十分だったり、想定される故障順番と異なった場合の対応ができていないことがある。後者では、故障率や部品耐用年数のデータでは、Aが故障してBが故障するという想定だったのに、いきなりBが故障するケースなど。

現用/予備の切り替えでのトラブルも、この範疇かも知れない。ただし、この類のトラブルはニュースレベルで目にすることが多いので、世間一般としては設計やテストが不十分と思われかねないジャンルである。

また、運用部門が(組織変更等で)結果的に不慣れとなり、思わぬ操作をして潜在的なバグが発覚することもある。一時的な対応として操作等で回避していたものが恒常的な対策を行わなかった&回避操作をうまく伝達できていなかった事でのトラブル発生もある。


基本的な確認を行わなかったなどは論外としても、見つけにくい/見つかりにくいケースもある。ある程度のレベルの組織体でも、時々発生する。ソフトウェアやシステムの設計やテスト、そして運用では、ソフトウェアの外部が(長いスパンをかけて)経年的に変化する事への対応を検討しておくべきだ。


追記:「日経 SYSTEMS」の2011年2月号(P52)に関連しそうな図が出ていたので紹介。”ノコゴリ曲線”。

2011___systemsp108_場当たり的な改修でトラブルが継続するし、終盤で保守が困難となることを図示している。

本ブログで述べたことは、ここでのノコギリ状態で、トゲのようなスパイクとして発生すると考えればいいかもしれない。多少地震のように、小さなトラブルが兆候として発生することもあるだろうが。なお、通常ならここでの保守困難期でのトラブルは少なく、システムとしての終焉を迎えるし、それを想定するだろう。

逆に、安定期でトラブルが頻発したり、周期的であれば、改修や元々の設計がまずいかも知れないと考えるべきだろう。また保守困難期が発生するかも知れないとして、新システムへの移行などを含め、その対応を検討すべきだろう。


追記:「ソフトウェアの経年変化がないので、終盤の故障率アップは無い」って書いたけど、そのソフトウェア(あるいはシステムと言うべきか)が使用できなくなる状況は発生する。具体的には利用しているOSのサポート切れ。組み込んだオープンソースを含むモジュールが利用できなくなるケースなども該当するだろう。また特にシステムの場合、一般的にメンテナンス契約があり、ソフトウェアはその期間まで動作することになる。

それらを考えると、ソフトウェアのバスタブ曲線は、稼働率のカーブと言えなくもない。あるポイントを0%としてX軸を稼働率100%とすると、従来のバスタブ曲線のように下に凸のカーブとなる。提起メンテナンスなどがあるのなら、想定時間に対する稼働率とすれば、トラブル無しなら100%稼働を意味することになる。

12月 7, 2012 ソフトウェア, ソフトウェアテスト, 品質 | | コメント (0) | トラックバック (0)

2012年11月 7日 (水)

機能要求と非機能要件って、ソフトウェアは与り知らないはず

今日、ネットで調べ物してたら、「機能要求と非機能要件」に関して最近書かれたページも結構多いのに気が付いた。”非機能要件のテスト”で検索しても、ポツリポツリとページがある。

前から思ってたんだけど、ソフトウェアのテストや作成の作業の中で、機能要求と非機能要件を分けるのが理解できない。ちなみに自分の場合、ソフトウェアの開発やテストの議論の際は、2つを分けることの是非は本質的ではないので話として割り込むことはしない。2つを区分する話題の部分を聞き流している。


そもそも作成するソフトに、例えばクラスを別にするなどして2つを区別することはない。テストも同様だ。良くレスポンスタイムの事を非機能要件とするけど、本来の要求事項の処理なども関係しているので、レスポンスタイムを速くする対応が1,2箇所をいじって調整できるほど簡単ではないことがほとんどだ。

むしろ、機能要求をユーザーからの要求とし、非機能要件を自社の都合などと考える方がすっきりするくらいだ。非機能要件として保守性などが挙げられることが多くて、非機能要件は多少のバグならOKとの考え方もあるかもしれない。例えば、サービスマン用の表示やログにスペルミスがあったからと言って、(昨今は)出荷NGにすることは皆無だろう。

レスポンスタイムも非機能要件とすることが多いようで、その範疇に含めても良いかもしれない。ただし、レスポンスタイムは契約なりRFPに書かれることが多くなってきている。そうなると、性能を出すことは必須。トラブルシートでも重要度は高レベルになるだろう。

なので、特にテストにおいては、機能要求と非機能要件を区別する必要はないと言える。むしろ重要度なり対策優先度において、その要求なり要件がどのステークホルダーからのものかを認識できる方が重要だ。(どのステークホルダーからかが明示的にどっかに書かれているか、暗黙に運用しているかは別として。) 機能要求と非機能要件を区別するのは、メトリクス取得メンバーがバグの分布などで利用する程度に考えていた方が良いとも言える。


ただし、非機能要件について書かれている本やホームページで、どんな要件が書かれているかは知っておいて損はない。機能要求は商品やサービスのドメインやユーザごとに異なることが多いが、非機能要件はドメインなどに依存しない項目が記載されていることが少なくない。それらが仕様書に書かれていなかったりテスト項目にない場合は、バグが多かったりバグの発見が遅くなったりすることが考えられるためだ。

非機能要件を仕様書に書かれてない項目と理解する人もいるようだけど、それはおかしい。作成するソフトウェアには非機能要件を実装しておく必要があるので、そのためにはドキュメント化しておくべきだ。該当する市場や装置で、常識的なこととして仕様書に敢えて明記しないケースはあるだろうけど。ただ、昨今のようにオフショアでソフト作成させたりテストさせたりするのなら、ドキュメントに掲載しておいた方がよい。(ちなみに、ドキュメントでなくてユーザーストリーで処理する場合は、非機能要件のユーザーストーリーで処理することになり、ここでのドキュメント記載はそれを含んでのこと。)


なお、”非機能要件”は”非機能要求”と表記すべきなどの意見もあるだろうけど、ここでは広く使われていると考える”非機能要件”とした。

”非機能要件のテスト”と大括りにせず、パフォーマンステストとか保守性テストと具体的なことで議論した方が良いだろう。その方が、それぞれの分野でのテスト技法の確立や効率化に結びつく。あるいは、”仕様書未記載のテスト”として、仕様書に書かれていない事項のテストをどうすべきかの議論をすべきだろう。個人的には、よほどの常識的なこと以外は仕様書に明記すべきと考えるが。 ちょっと気になったので、記載しておく。

11月 7, 2012 ソフトウェア, ソフトウェアテスト | | コメント (0) | トラックバック (0)

2012年11月 1日 (木)

「僕がアップルで学んだこと」

数年前から、時々品質関連の人と話題としたのが、アップル製品(当時だと代表的なのはiPod)の品質に対する感覚と自社製品を含む日本製品に対する感覚の違いは何?というもの。つまり、iPodを使っていると、(時々)音飛びが起きたりする。ところが日本製品だと、多分出荷NG。この違いはなんだろうかとか、判断基準をどう考えるべきかといった話題。実際アップルの製品を使っている人が少なくなくて、どう考えるか聞いたりした。

なかなか結論は見出せなかったが、アップルでの品質保証/品質判定の方法や基準は、その後も気になっていた。

左は、数日前に購入した本。著者の松井氏は、元・米アップル社品質保証部のシニアマネージャ。

実は、2,3ヶ月前とかに、本屋で手に取って見たことはある本。当時はパラパラ捲った程度だった。ところがiOS6でのアップル地図のゴタゴタをネットニュース等で目にして、色々検索。アップルの品質などの検索で、本著者の松井氏が引っかかってきた。そして、この本に品質保証部在籍当時のことが書かれていそうだったので購入した。内情暴露ではないだろうけど、ヒントになることが分かれば良いな~位の思い。

書評などでは、社内政治への対応やアップル回復のことが書かれている。それらの記載ページが多くて、品質保証絡みは所々。ただし、キーとなりそうなことが書かれていて参考になった。

品質保証部の役割は、品質を保証することではなくて、開発プロジェクトの状態を定点観測を行うということ。[P82] テストを行ってバグ分析をし、その製品がどの程度出荷可能レベルに近づいているかを測る。

バグ修正は重要度の高いものから行い、優先順の議論に時間が費やされることもある。[P79] また意見として、過剰品質を求めていないとの記載もある。[P84]

個人的には納得だし、優先順位の議論とかは知り合いなどの自分の回りで良く聞く話で、理解しやすい/当然と考える。

なお他に、マニュアルを少なくしたり無くしたこと[P69]や収益に対する研究開発費が2.3%と低いこと[P77]、デザインでブレが無いことと細部での変更とが書かれている[P64、P78]。

ちなみに、品質保証部門を担当した時の、メンバーの惨状の様子[P109]や整理整頓に心がけたエピソード[P112]に触れている。


先頭の方で記載したiOS6でのアップル地図問題は、iOSの開発統括のスコット・フォーストール上級副社長が来年退任するとのニュースで落ち着いた感じだ。代償が大きくなった。

実情は分からないが、松井氏が退社したことで、P109に述べてあるような惨状に戻ったのかも知れないとふと思った。また松井氏自身、今回のアップル地図問題をどう考えるか、彼のブログなどを注意しているつもりだけど書かれていない。(今は)書きにくいとか、書くべきではないとの判断かも知れない。 個人的には、アップル地図を出さざる終えない事情があるように思えて、申し送り事項(例えばαバージョン扱いにするとか)として明言などで対応する方法もあったように考えるのだが、、、、。

いずれにしろ、アップルを知る上で、個人的には読んで良かったと感じた本だ。


追記:以下の松井氏とのインタビューで、アップルも出荷判定会議をやってるとか、そのリハーサルの準備をした逸話が書かれている。

http://www.cyzo.com/i/2012/07/post_11040_3.html

11月 1, 2012 ソフトウェア, ソフトウェアテスト, 出荷判定, 品質, 書籍・雑誌 | | コメント (0) | トラックバック (0)

2012年10月26日 (金)

Japan IT Week 2012秋

今日は、「Japan IT Week 2012秋」の展示会見学で、幕張メッセへ。

同じ「Japan IT Week」の春のイメージを重ねすぎていたせいか、会場が狭いし個人的に気になっていた分野の展示が少なく感じた。気になっていた分野は、例えばクラウドインフラ。開発環境とかに関しては、春には「ソフトウェア開発環境展」としてあるけど、秋にはない。気が付いてはいたんだけど、春での招待状と似たような形態だったこともあり、少しは開発環境系の展示があるかもと思ってたがやはり皆無だった。

(コンパクトにまとまり展示内容ががらりと変わるのに、自分の頭が追従できないこともあった。各ブースも少し小さく感じて、見落としたりもしたようだ。特にトヨタマップマスタースの展示があったのに帰ってから気が付いて、少し惜しい事をしたと反省。トヨタマップマスタースは、ナビ絡みで少し気にしていた会社である。)

今回の秋での開催は、「クラウドコンピューティングEXPO 秋」、「情報セキュリティEXPO 秋」、「Web&モバイルマーケティングEXPO 秋」「スマートフォン&モバイルEXPO 秋」、「データセンター構築運用展 秋」「ビッグデータ&データマネジメント 秋」。後の方の2つが、今年の秋から追加された展示だ。

ちょっと面白く感じた展示をいくつか。(聞き違いや勘違いはご容赦。)

・タブレット型POS

いくつか展示があった。特に小型プリンター企業での展示が少なくなかった。クレジットカード読み取りを備えているものが多かった。その読み取りカード種(というかセキュリティレベル)へ対応とか新しいスマフォへの対応など、この分野も技術革新や競争が激しいと実感した。

・M2M関連

スシテナという会社がM2M向けの、モジュールやプラットフォームの展示をしているのが目に止まった。

・iD Lens/lD Broser

ナント・モパイルという会社が展示していたもので、スマフォなどでの物体認識。予め登録したもの(装置名とかバッグ名とか、、、、)と同じと認識したら、その名称をカメラ画像に重ねる。うまく説明できないけど、面白い応用が考えられそう。

・サイボウズのグループウェア kintone

企業間にまたがるコミュニケーションのためのクラウドツールと考えれば良さそう。従来のサイボウズOfficeは社内向け、kintoneは他社とのやり取りとの利用の棲み分けが考えられる。タブレッド端末やスマートフォンでの利用を意識していたり、いくつかアプリが用意されている。

・セキュリティや監視のツール

どちらも色んな種類があったり従来とは違う会社からの出展も少なくなくて、差異などを明確には掴みきれなかった。監視ツールについては、グラフィカルに問題部分を分かりやすく示す工夫などが進んだように感じた。

また当然、スマフォに絡むセキュリティや監視のツールの展示が多くなってきた。

・動的テストツール

ハートランド・データというところの「動的テストツールDT10」の展示があった。製品自体は以前からあった?

・BI関係

想定していたよりも、(新しい?)技術展示は少なかったように思った。


以上。

10月 26, 2012 ソフトウェア | | コメント (0) | トラックバック (0)

2012年10月17日 (水)

趣味の世界の技術革新

技術系会合の後の情報交換会・懇親会で、話題となるのが趣味の世界での”情報”などの技術の浸透。”情報”分野だとIT技術といっても良いだろうけど、ITと言うとエンタープライズ系とも捉えられちょっと違う。

案外というと変だけど、素材関係の進歩もすごい。防寒や防水、軽量化のための素材が進化している。ゴアテックスは結構昔から有名だけど、軽量化や発汗への作用などきめ細かくなっている。登山向けのシューズの紐で使われてるサロモンのQuicklaceもある。Quicklaceは非常に頑丈な糸(?)でペンチとかでないとちぎれない。ストッパーを使って結び位置を調整する。軽量化の最たるものは、カーボン。自転車のフレームなど色んな所で使われている。

ちなみに、技術記事としてネット記事とかの登場が少ないのは、同じ趣味でないと興味をそそられなくて読者数が少ないとの読みかと思う。また、書き手がその趣味でないと書き辛いし、仕事と趣味は別との考えが普通なので仕事に趣味の話を持ってくる抵抗感はあるのかもしれない。さらには、学校の先生などの教える立場となると、さらに扱うのに気が咎める事もありそうに感じる。これは、情報分野もそうだし、素材などもそうだと考える。

さて、情報分野の趣味分野での利用の筆頭は、GPSやランナーチップの利用だろう。

ランナーチップは、マラソン大会などでランナーが靴に装着してレースを行う。特定の箇所にマットを含めた計測装置を置いて、そこでの通過時間を各ランナーごとに測定する。関門での通過チェックや、(号砲からでなくて)スタート位置からゴールまでの実時間(ネットタイム)を計測して、参考として結果に記載することも行われている。計測作業の効率化に繋がっているし、大人数の大会開催にも役立っている。

ランナーチップは、マラソン大会以外でもトライアスロンやオープンウォーターの水泳大会でも利用されている。以下で、ランナーチップの形状や機能などが一覧で表示されている。

http://runnet.jp/runtes/chip/

で、GPS利用の件。以下のNike+は、有名。スマフォなどを一緒に持ち歩いて、走ったコースなどを公開できる。


http://nikeplus.nike.com/plus/products/gps_app/#get_the_software_section

知り合いなどからその人のコースなどを教えてもらって見ることは多いけど、ここで書こうとサンプル的なものを探したけど、すぐに見つからず。身近な人へ公開とのケースが多いからだろう。とりあえず以下辺りを参考のこと。

http://www.yuznak.jp/yodan/blog/2012/07/29/nike-run-club%E3%80%80%EF%BC%94%E5%9B%9E%E7%9B%AE/

他のGPS利用のソフトなりサービスでも同様だけど、コースや高低差、スピードなどを表示してくれる。

Nike+のシューズに付けてiPodやiPhoneで情報を蓄積するもの。

Nike以外の靴でも可能かと思われたが、Nike+の靴は、このチップの取り付け用のくぼみがあるそうだ。他のメーカーにはないし、サードパーティから他のメーカー用のための(靴のベロなどに付ける)グッズも出ているようだがやはり誤差があるようだ。(Nike+の靴でも誤差は多分発生するだろうけど。)

Nikeにあるなら日本のメーカーにもあるかもと調べたら、アシックスのサイトに以下があった。


http://www.asics.co.jp/running/myasics/

こちらもiPhone向けのアプリなどを用意してある。

さらに、アディダスの動向を調べたら、”miCoach”なるものがあり、心拍数や距離などを計測するようだ。

http://adidas.jp/mi/micoach/product/aboutmicoach/

サッカースパイクへの応用が、以下や日経エレクトロニクス 2011年11月14号に書かれている。

http://www.dgfreak.com/blog/2011/10/20111025adizero-f50.html

”miCoach”をユニフォームに付けて、公式試合で利用することになってるという記事が以下。

http://pc.nikkeibp.co.jp/article/news/20120416/1046167/

どんどん進化しているといった感じ。ただし、選手の位置なども分かるのかと思ったが、(勘違いかも知れないが)それは無理みたい。また、そこでのデータが一般に公開されていないのかと調べてみたが見つからなかった。一般の人達でのmiCoach利用のログも同様。一般の人達の利用ログはあっても良さそうだが、そちらも見つからない。位置情報と比較すると、見栄えなどが無いことや相対的に普及していないのかも知れない。


旧来の教科書や情報家電などでの情報分野の利用からは、なかなか発想しづらい分野なのだろう。特に日本人としては。スマートフォンなどで”遊ぶ”みたいな発想がないと、これら趣味での情報化の製品やサービスの提供を思い付かないと言える。何となく、そんな発想の貧弱さが、これらの分野での情報化に立ち遅れた理由かもと思うこの頃だ。

10月 17, 2012 スポーツ, ソフトウェア, テクノロジー | | コメント (0) | トラックバック (0)

2012年6月11日 (月)

要求? 要望/要求/要件?

2月ほど前の会合でのテーマは「BABOK」。そこでの講演者のスライドに、要望、要求、要件の記載があった。3つを少し区別して述べたもの。なお、会場からの質問で、BABOK(あるいは英語圏)では要求も要件も同じ requirement としているとの回答はあった。その回答自体は正しいし不満はなかったけど、懇親会では少し突っ込んだ話をしようと思っていた。でも、懇親会では別の話題で盛り上がってしまい、次回に会ったときでもいいやと考えていた。

ところが最近、自分の写真などの公開方法で少し悩む事が発生した。どんなWebサービスを利用すれば良いかの検討で、四苦八苦。とりあえず形になったのは自分のブログ(「トレランコース 弘法山~大山 GPSログと写真整理」)に書いた。

自分の要望としては、、、、。 

 ・写真/GPSログで一般公開にしたいのもあるが、別の写真は知り合いだけに公開したい
 ・知り合いにはインターネットに疎い人もいるので、その人達もアクセスできる方が良い
 ・写真の説明追記やスライドショー化は、Webサービス上で行いたい
 ・GPSログが再生でき、写真も各々を見るのとスライドショー再生を行いたい
 ・写真のスライドショーでは、バックの音楽をつけたい
 ・写真のスライドショーではスピードを変えることや説明も一緒に表示させたい
 ・写真のスライドショーでは、GPSログ上のスピードに応じて各写真の表示時間が変わるのが良い
 ........

実際のWebサービスを探すけど、なかなかぴったりのがない。そもそも技術的にFLASHを利用している段階で、携帯電話やiPadからの閲覧が不可。(工夫すれば出来るけど、今回のメンバーには酷。また自分としてもそのためにiPadにFLASH再生環境を入れようとは思わない。)

実際に良さそうなWebサービスを試してみると、不満な点も見えてきて、また別のWebサービスで実験、、、、。そんな繰り返しだった。

思うに、自分自分の要望の優先順位が整理されていない。しかもその優先順位が、実際のWebサービスでダイナミックに変わっていく。そのため、つい2ヶ月前の会合のことを思い出した。

やはり、要望は要望、要件は要件、要求は要求として管理した方がよいと言うこと。要求との言葉で統一したとしても、タグやフィールドを設けて、3つのく別が分かるようにすべきという意味。あるいはもっと細分化したり、どのステークホルダーからの要求かを識別できるやり方でも良いかもしれない。(自分の経験や他の人の話でも、大なり小なり実施していた人達が少なくない。BTSで管理するケースが多い。)

いくつかの要望をひとまとめにして要件化するようなこともある。例えばいくつかの要望を設定ファイル化して、複数のユーザへも対応できるようにするなどである。

また、実装の検討に伴い要望が分割され、分割後のそれぞれの優先順位が異なってくる現象もある。あるいは実装の関係で、ユーザ要望が変わっていくことが少なくない。場合によっては、コストで要望を断念、極端には「止~めた」となる可能性もある。従って、要望や要求のトレースや、優先順位などの変化に応じた対応が必要になる。(実際、今回の具現化で非公開の方は断念した。従来行ってた写真共有のみにし、宴会などで必要に応じてiPadでのスライドショー再生を行うとした。)

今回の検討は自分の要望から適切なWebサービスを探すことだったが、一部を自分でとかAPIを利用してシステム化を依頼するとなったら、さらに検討すべき事が出てくる。その中には、WebサービスやAPIの変更もある。Webサービスの中止や、以前と操作性や機能が大きく変更されることが珍しくない。せっかく作っても動かなくなることも想定される。


実際のソフトウェアのシステム設計や実装などでの、要求管理の課題が見え隠れした。自分の要望の具現化で、ふとそんなことを再認識した。

6月 11, 2012 ソフトウェア | | コメント (0) | トラックバック (0)

2012年6月 7日 (木)

東京スカイツリーの成長曲線

東京スカイツリーが営業開始して、しばらく経ったが、自分の属するコミュニティで東京スカイツリーの耐震や建築確認申請の変更などが話題となった。特に工事中の610mから634mへの変更。

で、その関連で調べていたら、公式とも言って良いページに日付とツリーの高さが記載されていた。大林組のページ。

http://www.skytree-obayashi.com/pointview/index.php?point=1

ビルの高さも、ある意味では”成長曲線”。普段ソフトウェアの世界での信頼性曲線のことは気にかけているので、それとの対比してみようと考えた。日付と高さを表形式にしてグラフ化したのが以下。

https://docs.google.com/spreadsheet/ccc?key=0At5_RJyc2TPhdEZlUXB5R21TRE8yMFpsOHQtVzJmVUE

多少意見あるだろうけど、一次曲線に近い。心柱作りや上部のアンテナ鉄塔引き上げでも、高さが急成長していないように思える。高精度が要求され、当初からの想定だったのかもしれない。

また、2010年の6・7月では高さ成長がストップている。これは(多分)、第1展望台に関する工事とさらに上の工事のためのジャッキなどに関する工事が関係したのだろう。


以前、本ブログでバグカーブ 対数曲線や二次曲線での近似のお勧めを書いたけど、高さや信頼性をコンスタントに成長させる意識の方が考え方として適しているような気がする。成長曲線になったりするのは、あくまで結果との割り切りの方がよいだろう。ふとそう思った。

6月 7, 2012 ソフトウェア, テクノロジー, 日記・コラム・つぶやき | | コメント (0) | トラックバック (0)

2012年5月 9日 (水)

Japan IT Week 2012春

今日は、「Japan IT Week 2012春」のショー見学で,、東京ビッグサイトへ。

以下のいくつかの展示が一緒に開催。

・ソフトウェア開発環境展(第21回)
・データウェアハウス&CRM EXPO(第17回)
・組込みシステム開発技術展(第15回)
・データストレージEXPO(第14回)
・情報セキュリティEXPO春(第9回)
・RFIDソリューションEXPO(第7回)
・ダイレクトマーケティングEXPO(第6回)
・Web&モバイル マーケティングEXPO春(第6回)
・データセンター構築運用展(第4回)
・クラウドコンピューティングEXPO(第3回)
・スマートフォン&モバイルEXPO春(第2回)
・ワイヤレスM2M展(第1回)

東館、西館(しかも2階も)を使用しての開催で、規模が大きくなっていく感じ。IT系(Web系やクラウドを含む)の展示が増えて、組込みシステム開発技術やソフトウェア開発環境展が少し異色に思えてきたし、「ソフトウェア開発環境」の展示意図が少し曖昧になってきたように思う。2,3年前までは、開発環境としてプロジェクト管理関係の展示があったが、少なくなったとも感じた。

Salesforceでの展示では、色んな会社がSalesforceを利用しているのが分かり参考になった。コンビニとかで目にするサービスが、実はSalesforceを利用していたなど。

データセンターの展示では、CD等での長期保存の展示が多くなった。

ソフトウェア品質関係では、ISO26262に向けての開発支援サービスがいくつか。スマフォを含めたテスト自動化や複数機種へのテスト対応の展示もいくつか。

M2M展は初めての展示だったし西館の2階で人が少ないかなと思ったけど、それなりの人。NECの展示が目を引いた。地震測定ソリューションの展示を行っていた。(異音検査ソフトウェアなるものの展示もあったけど、今は工場ラインでの異音検出の用途のようだ。)

M2M展でだったと思うけど、微生物燃料電池なるものの展示もあった。


ついついカタログをもらってしまった。やはり重い。宅配便を利用する手段もあるけど、今回は少し勿体なくて利用しなかった。カタログは、帰ってからスキャン。会場で電子ファイルでもらうなどが出来ればいいかと思うんだけど、難しいんだろうか。

こんなものまでクラウドを含めてWebサービスがあるんだ~と思うものがいくつかあり、参考になることが少なくなかった。ただ会場が広いし出展が多いので、来年とかは少し絞って見学したい。

5月 9, 2012 ソフトウェア, 日記・コラム・つぶやき | | コメント (0) | トラックバック (0)

2012年4月21日 (土)

コンビニでA3スキャン

自炊/他炊で少し悩んでいるものはいくつかあるが、A3サイズのスキャンもその一つ。本とかなら他炊でのサービスを行うところも少ないものの存在するが、プリントしたりのシートタイプの扱いが悩みのタネ。手ごろな価格では、自宅のがそうだし、一般的な家庭用向けではA4サイズが最大。なのでスキャンできずに残ってた。折りたたんでスキャンした後に接合する機能があったりするけど、その後の文字認識精度などで使うことは限定的になってる。

ちょっと都内ならスキャンサービス店があるようだけど、近くの横浜のFedなどではやってないようだ。昔みなとみらいのTSUTAYAでやり出したニュースを目にしたけど、最近は案内から無くなっているようだ。また、印刷を意図したサービス店もあるようだけど、ネットも含めて遠い所がほとんどだしそもそも価格がべらぼうに高い。

ドキュメントの整理でA3でスキャンすべきものが溜まってきて、そろそろとの意識で再調査。すると、コンビニでスキャンできるところがあると出てた。サイトによってはファミマでもやってるとの記載も。ちらっとセブンイレブンでのサービス方法を見て、今朝早朝に散歩がてら出向いた。(早朝でなくてても良かったんだけど、最初の利用で操作に手間取ったりしたら悪いと思ってのこと。)

近くのファミマでは、スキャンがメニューに出てない。稀にコピーで利用してメニューで見かけたこと無かったので、案の定との思い。少し離れたファミマでも同様。で、その先にセブンイレブンがあったので、そちらへ。メニューに出ていて、ラッキーとの思いだった。ちなみに、セブンイレブンでの、スキャンサービスに関するページは以下。(「詳しい操作」を事前に読んどけば良かったと後になって感じた。)

http://www.sej.co.jp/services/scan.html

最初どこにUSBを差すのか分からなかったけど、マルチコピー機の隣上にPCのようなのがあり、DVDやUSBの差し込み口群にプラスチックカバー。開始して確認などを操作すると、そのカバーが動いてUSBなどを差せるようになってる。後は画面に従って操作するだけ。最後に縮小的なイメージで画像を確認できるのも良い。完了でコイン投入して、USBを抜いたらまたカバーが動いて差し込み口群に被さった。

ちなみにPDFにしたけど300dpi固定だったと思うし、OCR機能は処理されてなかった。画質とかはまっそんなもんだろうといった感じかな。(自分の今回のは、A3の16ページで27MB。) むしろ個人的には、A3での折り目を元に戻すようにしたり少し厚めの紙などと一緒に押さえとけば良かったかなと反省。

他に思ったことは、、、。
・ADFじゃないので、ちょっと手間。まっ、こればかりは仕方ないかな。

・1ページ読み取った後の画面操作で、読みとりOKで「これで設定」ボタンが表示されて、その次に継続しようとすると同じ位置に同じような色で「これで設定 終了」といったボタンが表示される。連続してスキャンする時に、つい終了をタッチしそう。後者でのボタンの位置などは工夫が欲しいかな。

・画像を確認したら、定位置に霞んだような何かが。ガラスが綺麗になってなかったようだ。USBなどの媒体と一緒に拭くためのものを持って行った方が良いかなと思った。ひどくはなかったけど、その後でのOCRなどの修正の手間などに影響する。


いずれにしろ、A3スキャンは目処が立って一安心。

4月 21, 2012 ソフトウェア, テクノロジー, 技術, 電子ブック | | コメント (0) | トラックバック (0)

2012年3月23日 (金)

単体テスト/コンポーネントテスト、、、、、

ソフトウェアテストでのテストレベルの用語(の統一)は気になっている事項だ。ISTQB/JSTQBでは、コンポーネントテスト、統合テスト、システムテスト、システム統合テストなどがシラバスなどに記載されている。

ところが、自分の最近目にするソフトウェアテストに関する記事や論文では、単体テストや結合テストが増えてきた気がする。(開発系では、以前からほとんど単体テストや結合テスト。)

ソフトウェアのISO化などもあり、ちょっと気になって調べたり、確認してみた。まずソフトウェアテストのISO化に関しては、以下が公式的だし、まとまっていると思う。

ISO/IEC JTC 1/SC 7/WG 26の概要 http://www.itscj.ipsj.or.jp/tutorials/tu87.html

そこでの(2)に書かれている”テストレベルを特定しない”ことから、テストレベル自体の明示も行われないような気がしてきた。あるいは、他のISO程度しかレベル分けしないと思える。

そうなると、ソフトウェアの開発なりテストのプロセスは、ISO/IEC 12207 (JIS X 0160)を踏襲すると思われる。ISO/IEC 12207では、ソフトウェア詳細設計、ソフトウェア結合、システム結合、ソフトウェア適格性確認テスト、システム適格性確認テストという用語が明言されている。他に”コードの検証”という用語もある。ちなみに、”Integration”を”結合”と訳している旨が明記されている。

そうなると、テストレベルとしては、単体テスト、結合テストが、ますます定着するように思える。

ちなみに、Googleで”単体テスト”等での検索結果件数は以下。”ユニットテスト” が多いのは、xUnitの関連だろう。

 ・”ユニットテスト”     415000件
 ・”単体テスト”       323000件
 ・”コンポーネントテスト”  14800件

JIS X 0160の頃でも、ソフトウェア開発でのプロセス用語が各社各様で統一に役立つとの記述もあったが、結局そう統一されたわけでもない。また、規格では細部を決めたり例示することを避けている感がある。組織体では、効率や品質向上にためにプロセスを細分化した呼称を用いたりするが、ISOなどはそれをフォローしていない事になる。むしろISOやJISは、ソフトウェア開発/テストのキーの部分から、より広範囲を含めたライフサイクルやプロジェクトの規格化が進んでいる気がする。

組織体で細分化したプロセス呼称を用いる場合もあろうが、企業間での統一は考えにくいと割り切った方が良さそうだ。ただし逆に、他社との情報交換の際には、用語の確認をした方が無難だろう。


個人的には、JISの規格内で単体テスト、結合テストを用語として明示して欲しい気もする。(ただし、こちらが単に知らないだけかも。) また、自分としてはコンポーネントテスト/統合テストという言い方に少し慣れていたが、今後は単体テスト/結合テストを用いることが増えると思う。

3月 23, 2012 ソフトウェア, ソフトウェアテスト, プロジェクトマネジメント | | コメント (0) | トラックバック (0)

2012年3月17日 (土)

画面変更と仕様変更

早朝のテレビ東京「モーニングサテライト」は、結構見ている番組。そこでの表示方法が、今年になって若干変わった。

20120316_左は昨日(16日の放送)での、ニューヨーク株式の値動きの画面など。

http://www.tv-tokyo.co.jp/mv/nms/market/post_17307/での画像だけど、画像圧縮を高めてる。

青っぽい画面で”ダウ 1日”と書いてあるが、昨年までは日付だった。つまり、以前だと前日のダウなので”ダウ 15日”と表示された。日本株式とか為替なども同様。

今年になって表示を見て、システムのトラブルかと思ってしまった。つまり表示に関する日付更新がされてないと。多少日を置いてからだったけど、Twitterに書いたりモーニングサテライトでの問い合わせから投稿したりしても反応無くて、なおさら不可解に思えた。

2月になっても変わらないので、おかしいな~と思いつつ。どうも日付ではなく、期間(1日分)を示すように変えたのかもしれないと思うようになった。そうだと悪くはないんだけど、日本が祝日で向こうの市場が開いてる時にどちらの日か分かりにくいことはある。それよりも日付/期間の表示部分を固定的に出来るので、手間が少なくて済む方を採用したのかもしれない。(1月放送の冒頭で、表示変更のアナウンスがあったのかもしれない。ただそれでも、投稿等での反応で教えてくれても良いのにとは思ったが。)

これが良い例か分からないけど、システムのテストなどで、画面変更が仕様変更なのかトラブルなのかと悩む事は少なくない。リリース前に、変更部分をアナウンスしないなんていう考えられない事もあるようだし。その度に、再試験とかバグ表の発行とか、仕様確認とか無駄な作業が発生するのに懲りないみたい。

また昨今のWebサービスでの画面変更は珍しくないし、新旧画面の切替をユーザーが行えるようになってるケースも多い。操作性が悪くなることは少なくないし、トラブルかと悩むことも時々発生する。

画面変更に対するアナウンスは、多少手間でも行うべきと再認識した次第。

3月 17, 2012 ソフトウェア, 品質 | | コメント (0) | トラックバック (0)

2012年3月16日 (金)

ソフトウェア開発での進捗の可視化

昨日の「プロジェクトマネジメント学会 2012年度春季」で触れた、ソフトウェア開発でのスケジュール進捗の可視化の件。

プロジェクト管理でのイナズマ線や達成率で進捗を示すことは行われているし、バーンダウン・チャートを用いることも多いだろう。ただし、ここで考えたいのは、ソフトウェア全体でのどの部分が終わってるかの図示化。一昨日の学会での講演だと、配管の3次元表示がスケジュールと一緒に示されたが、ソフトウェアが2次元とか3次元で示されれば言うこと無し。

2次元表現としては、クラス図などが考えられる。ただ、スケジュールでクラスをどう表現するかとか、ツール間の連携が気になった。色々調べたりしたけど、良い考えが思いつかない、、、、。

でふと、スケジュール→チケットと考えると、すっきりしてくるように思えてきた。チケット系のツールと、リバースエンジニアリング系(も機能に持つ)のツールで、連携できるものがある。

なお、全体をプロジェクト管理ツールで行っている場合は、WBSレベルでの情報をチケット情報から引っ張ってくる/作成するやり方が良さそうに思う。つまり主体をチケット系ツールにする。機能実装やテストの進捗とかバグ対策の進捗まで含めた可視化では、チケット情報の方が的確だからだ。(ただし、工数検討などではプロジェクト管理ツールの方がメリットあるだろうから、使い分けを行うだろう。)


結構すっきりして、一人ご満悦状態。

3月 16, 2012 ソフトウェア, プロジェクト管理, 出荷判定 | | コメント (0) | トラックバック (0)

2012年3月11日 (日)

統合テストはフォーメーション練習?

以前から頭の隅にあったのが、統合テストをどうイメージした方が良いかということ。JSTQBでのテストレベルとして、コンポーネントテスト、統合テスト、システムテスト、システム統合テストという用語がある。一般的に使われている単体テストがコンポーネントテストに、結合テストが統合テストに該当するだろう。(ただし、企業やプロジェクトで、そうとも言えないこともある。)

各モジュールのソースに対するテストとしてコンポーネントテストがあり、全体のテストとしてのシステムテストがあることはイメージしやすい。しかし、用語としての統合テストは理解していても、実際のテストでは解決すべき課題が出てくる。

例えば、Aという人なりグループがA1、A2、、、、というモジュールを設計/コーディング。Bという人なりグループがB1、B2、、、、を、Cという人なりグループがC1、C2、、、、を設計/コーディングしているとする。ここでCは、汎用的なモジュールとする。

そんな時、A1とC1やC2との結合テストを行うか? 行うとして全ての組み合わせを行うか。また、AとBに関係し合うモジュールがあったら、それも全組み合わせテストを行うか、、、、。そもそもAとかBの中での統合テストを行うかなどである。(場合によっては、AとかBの中でのテストを、統合テストと呼ぶかも組織体やプロジェクトで異なるかもしれない。)

机上では全組み合わせテストを実施すべきだろうが、実際にそのようなことは行わない。(少なくとも自分の経験では。) そうだとして、統合テストをどうイメージしたらいいかが頭に隅にあった。


で、春になって、野球のキャンプとかを目にして、スポーツに例えるのが分かりやすいような気がしてきた。つまり、コンポーネントテストは、バッティングや守備などのある意味単純な練習。システムテストは、実際の試合。そうすると、統合テストは、フォーメーションの練習かなと。

バスケットやバレーボール、あるいはサッカーなどのチーム競技でも似たようなものだろう。水泳や陸上競技だと、リレーが近いかもしれない。走/泳順に応じた練習が統合テスト。走る順番や、走者/泳者を誰にするかで組み合わせが増えてくる。

フォーメーション練習では、メンバーの組み合わせを含めて、そう全部の練習をする訳じゃない。試合が近づけば、より実践的な練習にしていくだろう。

結局統合テストも、どの組み合わせをテストするかとか、全体テスト(システムテスト)に向けてのテストを意識すべきだろう。日程との調整や、そもそも統合テストの期間見積りが重要なのは言うまでもない。統合テストのためのダミーモジュール/コンポーネント作成の手間が膨大になりすぎては本末転倒でもある。

統合テストの際に、視点として機能に着目するのがよいと考える。ソフトウェアの単純な結合というよりも、機能テストとの視点。システムテストの前段階にもなる。以前、ここのブログの「”スクラム”の原典「ラグビー方式による新製品開発競争」」でフェーズの重なりに触れたが、PMBOK4版(日本語版ではP21)でもプロジェクトマネジメント視点でのフェーズ重なりの図が示されている。コンポーネントテスト→統合テストとフェーズがばっさり区切られるよりも、2つが重なっていたり、機能実現が追加されるイメージがよいだろう。

また、スポーツの場合に基本的な練習も交えながら試合/試合前に臨む事も、対比的に参考にすべきかもしれない。つまり、必要なコンポーネントテストや統合テストを継続していくことへの意識である。(当然ながら、自動化などで効率的に行うべき。)

参考になるか分からないけど、自分では良い見方と思えている。

3月 11, 2012 ソフトウェア, ソフトウェアテスト | | コメント (0) | トラックバック (0)

2012年3月 6日 (火)

路線バスの時刻表とモデリング

モデリングの話は勉強としては必要(必須)なんだけど、実際のシステム化の際に、モデルが段々崩れていったり醜くくなってくことは良くある。なるべくすっきりしたままにするのが、交渉力だったりするけど、、、。で、今日そんなことを強く感じた事例に遭遇。

趣味で、トレラン(トレイルランニング)に行くけど、結構悩ましいのがバスの時刻。電車だと経路検索のソフトなどで判明するけど、路線バスは困ることが時々ある。特に奥多摩方向での西東京バス。携帯電話での検索でも、他と比べたら、結構操作が面倒に感じる。1時間に1本とかはザラなので、帰りのバスの時刻で別ルートのいくつかを検討するからだろうが。

Tominnomori_2今日知ろうとしたのは、武蔵五日市駅から、数馬や都民の森というポイントへのバス。行きと帰り。

http://www.nisitokyobus.co.jp/rosen/tominnomori.htmlでの時刻表を画像化したものが左。ここでは時刻そのものが重要じゃないので、画像的に細部が分かるようにはしてない。

そもそも、日によって運行するものとそうでないものが多い。グレーの所は、都民の森までは行きませんと言う意味。白+黄色部分は、都民の森に行くけど、黄色部分は運休する時がありますという意味。運行する日が、表の上の方に書かれている。

経由地が3種類あって、急行と普通、都民の森に行くのに乗り換えるのと乗り換え不要とがある。当然、平日と土・日のダイヤの別も。

人間だと、予定している日にちを前提として、この表から探し出すのかな。ただし、この表の情報を元に、出発地と到着地、そして利用日を入力して運行時刻を表示するアプリケーションを考えると、データの持ち方や処理がそこそこ複雑に思える。あるいは、すっきりしない。また、そもそも利用日を入力するのは操作的に良いとも言えない。つまり、デフォルトを当日としたり、土日も直近の土日がありがたい。結果の表示でも到着時刻だけじゃなく、急行かどうかは当然として、乗り換えするのかは判明した方がありがたい。実装時には、他の時刻表のデータ(データベース)との整合性とか連携をどうするかも悩ましそうだ。


経路検索のサービスで、路線バスまで含めているのが少ない訳が分かった気がした。なお今回の事例での運行時刻表示するアプリケーションの必要性は微妙だけど、一般的にも単純なデータ構造にならないケースは少なくない。設計としては単純なデータ構造やロジックにしたいけど、実際の運用がそうでないケース。モデリングの勉強と同時に、そう単純にならないケースへの対応の勉強も必要だろうにと考える。


(念のためだけど、奥多摩に行った時には西東京バスにはお世話になってるので、そのこと自体には感謝。)

3月 6, 2012 ソフトウェア | | コメント (0) | トラックバック (0)

2012年2月22日 (水)

ISO 6592(JIS X0126) 廃止

ISO 6592(JIS X0126)って「応用システムの文書化要領」で、以前このブログで悪くないと思う旨を書いた。で、以前から日本語規格での細かい誤字が気になって、正誤表が出たかなと調べたら、、、、、。規格として、廃止とのこと。

http://www.webstore.jsa.or.jp/webstore/Com/FlowControl.jsp?lang=jp&bunsyoId=JIS+X+0126%3A2001&dantaiCd=JIS&status=2&pageNo=1

ISOそのものが廃止らしい。何に置き換わるんだろうかとちょっと検索したけど、日本語検索程度にしたせいか、見当たらず。個人的には、それらしいISO/JIS規格が思い当たらないし、理由なども不明確で合点がいかず。うーーん。

2月 22, 2012 ソフトウェア | | コメント (0) | トラックバック (0)

2012年1月25日 (水)

iPadでのマインドマップツール 続編

iPadでのマインドマップツールを悩んでいる件を既に述べたけど、段々iPadで作業しようとすることが多くなり、解決しようとの思いに至った。以前のブログで書いたように、Mind42で作成できるが修正ができない、→ついつい作業が億劫になる弊害を感じるようになった。

本来Web系のサービスでiPadでもWindowsでも作業できるのが良いが、あまり値段のかかるのは避けたい。Webサービスで「easy step」も悪くないと思ったら、iPadで編集できない。「Mindmeister」は、再度有料会員になるのも抵抗あるし、、、。またiPad向けのマインドマップやアウトラインプロセッサーの無料ソフトをいくつか試したけど、ノード変更(子ノードを別の親ノードの下へなど)などが操作できない/操作が見つからなかった。

結局、iPadでのマインドマップツール「iThoughtsHD」を、App Storeから購入することにした。\850。

そもそも今までMind42条で作成したマップを、「iThoughtsHD」に移動させる必要がある。ネット検索での上位でヒットしなかったけど、Mind42でのエクスポート形式でFreeMind V9(V8も)あり、そちらでエクスポート。そのファイルをDropBoxに置いて、iThoughtsHDでインポートすることで対応できた。インポートの際に同期する指定も可能だったので、効率良い。しかも同期だとファイル形式も引き継いでくれる(当たり前か)。

Windowsでの利用は、Mind42でDropboxのFreeMindファイルをインポートすることで可能ではある。ただしこちらは自動的に同期はしない。したがって、集中的に作業する時などに限定されて、マインドマップの作業の主体はiPadで行うことになっていくだろう。

ちなみに、iThoughtsHDでのマインドマップそのものでの日本語入力や表示は、自分の使った範囲では問題なし。メニューが日本語でないのはちょっと気になるし、その関係か、Dropboxの指定や同期、一括ダウンロードの操作が、少し分かりにくい気がする。慣れの問題かもしれないが。

まずは一安心だし、この関係で少し延び延びになってた作業をリカバーするつもり。


補足:PC上での操作は、FreeMindを利用してDropbox上のファイルを処理する方法を採用。PC上でファイル操作(PC上でもDropbox同期)した後にPadのiThoughtsHDのマップファイル一覧で見ると、雲マークの他に更新されているアイコンが表示されるのでクリック(タップ)してマップを開くとPCで更新されたマップが表示される。

1月 25, 2012 ソフトウェア, パソコン・インターネット | | コメント (0) | トラックバック (0)

2011年11月22日 (火)

ハードウェア受け入れテスト

以前”初期「受け入れテスト」”って書いたけど、ハードウェアの受け入れテストも重要である。以前「受け入れテスト」を書いた時も頭の隅にはあったけど、明記しなかったようで、補足的に今日記載。

ハードウェアの受け入れテストも、開発の初期段階に行われるのは同様。ここでのハードウェアって、社内の新規基板の場合もあるけど、他部署での(先々内販/外販予定の)半導体とか、他社の半導体なども含む。

で結構厄介なのが、ソフトウェアにバグがあるように、ハードウェアも完璧なものが最初からある訳じゃない点。しかも量産を意識している場合、修正ハードウェアを入手できるのに期間を要することが多い。(逆にFPGAのように、変更が容易なケースもある。その場合は、修正確認に付き合わされる頻度が多くなる。)

基板のような場合は、ジャンパー線で修正ということも少なくない。試作機が何台もある場合は、修正済みとそうでないものが混在。ハード屋さんは、出来れば修正台数を少なくしたいと言うし、、、。


ハードウェア受け入れテストを、誰が実施するかも懸念点だろう。ソフトウェア開発メンバーになることが多いが、テストの頻度やボリュームが大きいと、委託などの方法も検討する必要がある。ハードウェアの一般的な知識や組込みの知識があった方が良いので、人捜しが難しくなる。

結局、この辺りを含めた開発初期の作業項目列挙や人員の手配などの立案や実施が重要だ。開発のその後を、大きく左右すると言っても過言ではない。

11月 22, 2011 ソフトウェア, 品質 | | コメント (0) | トラックバック (0)

結局 Goggleノートブック→Evernoteへ

Googleノートブックが終了ということで、結局WebのスクラップはEvernoteを利用することにした。自分なりの終了を聞いての不満はブログで記載済み。

そもそもEvernoteへ移行するのに、Googleノートブックの各ノートをエクスポート。以前はEvernoteでのインポートはhtmlも可能だったように思うけど、Atom形式のみになっていた。一部htmlでのバックアップは取ってて残りもhtmlでバックアップした後にインポートを実験して、Atom形式のみと判明したので、再度Atom形式でバックアップ。ちょっと疲れた。(Evernoteでのhtmlインポートは、勘違いかもしれない。自分のバックアップ確認などでhtmlへのエクスポートを実施していたため?)

Evernoteでのインポートは、(ノートブックのボリュームが大きかったので)それなりの時間。また、後でローカルPCとかiPadの方も同期させようとしたが、そちらも多少の時間が必要だった。

細部は調べてないけど、インポートはOKと思える。(画像を含むノートの確認をちゃんと行ってないけど、駄目なら諦めるしかないかな。また、Googleノートブックでのセッションの考えがEvernoteではタグになって使い勝手に違和感があるけど、そちらは諦め。)

以前はEvernoteの検索や表示がやたらと時間がかかって、Webスクラップとして使うこと自体をやってなかったけど、今回操作した限りでは、少しイライラするときがある程度。結構バンドルされたりしているのを見聞きしているけど、その関連で開発(資金)などがうまく行っているのかもしれない。


なお、少し使い出すと、いくつか不満も。Webの一部選択後の右クリックでメニューにEvernoteへの保存が出てきて、選択部分のみをスクラップするなどを選択する必要がある。ツールバーでのアイコンクリックでも、メニュー操作の必要性は同様。Googleノートブックに対して1アクション追加することになるのが気になった。

Firefoxのアドオンでどうにかならないか調べてみたけど、上手い方法は無さそう。結局”Menu Editor”で右クリック時のメニューの一番上をEvernoteへの保存に変更することにした。

Evernoteを使って良かった事項に、iPadでの利用がある。iPadでも直接Evernoteへ保存が出来ないかな~と思って調べたら、上手い方法を記載してあるサイトを発見。

iPadのSafariから、ツイッターやEvernoteに簡単にポストするブックマークレットまとめ

iPadでの操作自体もEvernoteへの保存処理も、ちょっともたもたした感じにはなるけど、iPadでのWeb閲覧が増えているので個人的には非常に便利だ。

Evernoteを使って良かったもう一つが、Google検索時にもEvernoteの検索を表示する点。Firefoxアドオンの「Evernote Web Clipper」のオプション指定によるもので、Google、Bing、Yahoo、Yandex、Baiduでの検索時に、Evernoteの検索結果も一緒に表示する。

Googleノートブックの中止やそれに伴う移行作業で少しイライラしたけど、EvernoteにしてiPadでもWebスクラップを行えるようになったのは良かった。イライラ自体は収まりつつあるけど、Googleサービスはこれからも少し気をつけながら利用するつもり。

11月 22, 2011 ソフトウェア, パソコン・インターネット | | コメント (0) | トラックバック (0)

2011年11月18日 (金)

ET2011

今日は、ET2011(Embedded Technology 2011 / 組込み総合技術展)見学。開催場所は、パシフィコ横浜。

http://www.jasa.or.jp/et/ET2011/index.html

ショー会場見学の前に、基調講演を拝聴。

「はやぶさ」-地球帰還までの7年間60億kmの運用を支えたものと新たな展開
〜あきらめない心がつかんだ成果〜

JAXAの川口さんの講演。スライド自体は、写真等は少なく文言(若干英語を併記)がほとんどだったが、話し方や内容で1時間があっという間だった。

冒頭の話しは、予算獲得との関連での、地球内部と小惑星の関係。これは本にも記載されてるかと思う。

次が映画「はやぶさ/HAYABUSA」の件。”真実のドラマ”という表現や、川口さん役の佐野史郎さんがヤカンを持ち歩くシーンのことを面白く話された。

個人的に印象深かった逸話は、カプセル回収後にコンビニでジュースを買ったら、店員さんから「砂が入っていると良いですね」と言われた件。「ジュースに砂は、、、」と笑いを誘っていたが、個人的にはウルっとしてしまった。


その後に、ショー会場へ。奥の方から見学したけど、昨年よりは見学者が少ない感じ。震災などの影響かもしれない。海外からの展示は少なくなかったけど、以前との比較では地方からの小さなブースでの展示が増えたかな。後、大きな企業でもテーマ的な展示よりも、サポート企業による展示がほとんどを占めるようになったと感じた。ET2011で初めての展示とか参考出展の類も減ってきたと思えた。

スマートグリッドはコーナーがあったので、いくつかの展示があったが、ブームというほど見学者が多かったり盛り上がっているようには思えなかった。

三洋のプロジェクターなど面白い製品もあったが、製品よりも半導体/半導体関連の展示が多かったと思う。また自分の目線なのか、電気系よりもメカとの連動のような展示が増えたように感じた。メカトロニクス(自分なりのより正確には、メカ+ソフトウェア)って、日本の技術の骨幹とも言えるかもとか、地方の展示が増えてる背景かもとふと思ってしまった。

会場では、知り合いの説明員の人と少し懇談。また、偶然知り合いとも遭遇して少し立ち話した。今年は、講演との関係でETロボコンの決勝も見学しなかったこともあって、技術や製品よりも、講演や知り合いとの遭遇が印象的な展示会になった。

11月 18, 2011 ソフトウェア, 日記・コラム・つぶやき | | コメント (0) | トラックバック (0)

2011年11月 8日 (火)

初期「受け入れテスト」

少し前に、何度か偶然「コンポーネント指向開発」が話題となることがあり、”コンポーネントテスト”と”コンポーネントのテスト”が気になっていた。コンポーネントテストはユニットテストと呼ばれるもので、ソフトウェアモジュールを分離してテストするもの。後者は一般用語にはなっていないが、ここでのイメージは、開発の際の市販を含めた外部のモジュールをテストするものである。

で、ここでの”コンポーネントのテスト”って、一般的な用語では”受け入れテスト”に近い。開発の最初の頃に、テストフェーズでの終盤のテストと同じような事を実施することになる。反面”受け入れテスト”と多少異なるのは、利用する部分のテストでも十分であることや不具合発見が開発全体に影響することが多いことだろう。(開発の中間や終わりに、中心的なモジュールが利用できないと発覚したら、システム設計自体の見直しにもなりかねない。)

ただその観点で、「受け入れテスト」(ただしコンポーネントのテスト)のテスト技法とかの議論を、あまり見かけないように思えてきた。特にテスト効率などの議論。その辺りが気になった。

で、調べてみたら、JSTQB(ISTQB)のFLシラバスでは、2.2.4. 「受け入れテスト」でいくつかのテストを述べている。FL:Foundation Level AL:Advanced Level

・ユーザ受け入れテスト
・運用受け入れテスト
・契約、および規程による受け入れテスト
・アルファ、ベータ(あるいはフィールド)テスト

また、「市販ソフトウェアプロダクト(COTS)は、インストールや統合時点で受け入れテストを実施する。」、「コンポーネントのユーザピリティの受け入れテストは、コンポーネントテストで実施する。」との記載もある。なので、ここで書いた”コンポーネントのテスト”は、受け入れテストと呼んでも良さそうに思う。ただしJSTQB(ISTQB)では、”受け入れテスト”はテストレベルでの1つとしており、テストレベルはテストフェーズの意味でもあるので、用語の概念としてすっきりしない。

ちなみに、JSTQB(ISTQB)のALシラバスの方では、受け入れテスト自体の細部に関してはFLほどには言及していない。

用語をすっきりさせるには、組織体で○○コンポーネント受け入れテストとか○○モジュール受け入れテストと呼んだり、多少一般化するのなら”コンポーネント受け入れテスト”という用語などを使った方が良さそうに個人的には思えた。


なお、懇親会の類では、特に海外製のモジュールに重大バグがあったり窓口対応が悪かったりで、開発スケジュールに大きな影響が出たなどの話は少なくない。そして、同じ社内のモジュールとか装置開発の遅れ起因がある。割合的には後者は少ない気がするが、起きてシステムプロジェクト側が責任を負わされたり犠牲になることも。同じ社内なので、責任追及しにくかったり、元々駄目チームと分かってても利用しないと行けない事情があるのだろう。

ちなみにコンポーネント受け入れテストで話題になるのは、以下辺りが多い。

・テスト効率
・負荷テスト
・非機能要件
・外部を含めたバグ管理
・スタブ作成チーム、テスト作業チーム形成
・テスト環境保存 (自動化でスクリプトを作成したらその保存なども)

最近は外部機器でもネット接続可能なものが増えたり、市販コンポーネントでもサンプルプログラムが付いたものも少なくない。パソコンを利用して、それらの機器やコンポーネントをテストすることは増えている。さらには、GUIやネット系の自動テストツールや画面操作再生ツールなどを利用すると、結構効率良いテスト環境を構築できる。組込みソフトウェア産業実態調査報告書などで自作テストツールの割合が多いが、今後は市販ツールの利用が増えていくと思われる。

用語がすっきりするのは良いことだが、結局この類のテストの重要性を感じているところは以前も含めて実施しており、何らかの呼称を行っているだろう。また、テスト自動化の議論と多少似てて、実施しているところはさらなる効率化を目指していて、一般的な議論は進みにくいようにも思えてきた。


補足:通常の受け入れテストが発注者側が主体であるのに対して、ここでの”コンポーネントのテスト”や”コンポーネント受け入れテスト”は機器やシステムの開発側/受注者側が主体となる。発注者、開発者/受注者の各々の目線でテストのフェーズを考えることが多いので、それも少し違和感が発生するのかもしれない。開発者/受注者目線で考えるなら、テストのフェーズとしては受け入れテストという言葉よりも、出荷テストとかカットオーバーテストの方が良いように思える。

11月 8, 2011 ソフトウェア, ソフトウェアテスト, プロジェクトマネジメント | | コメント (1) | トラックバック (0)

2011年11月 6日 (日)

Googleノートブックが間もなく終了

ネットサービスでの「Googleノートブック」は、使い続けているサービスの一つ。Google自体は開発を止めてるし、Firefoxの新しいバージョンじゃ慣れた操作ができなくなるなど、逆風の中でも使い続けている。

別のサービスでの表示と同じだろうと、よく読んで無くて今日になって気がついたけど、Googleノートブックを終了するとのアナウンス。Googleノートブック起動の際に、上の方に表示される。

「Google ノートブックは間もなく終了し、ノートブックのデータは自動的に Google ドキュメントにエクスポートされます。ご不明な点がある場合は、よくある質問ページをご覧ください。」

予感はしていたけど、実際のアナウンスを目にするとやはりショック。しかも”Google ドキュメントにエクスポート”って書いてるが、手動でGoogle ドキュメントにエクスポートしてもエラーになってエクスポートできない。1,2回はエクスポートできたかもしれないが、今までも失敗。ちなみに、htmlへのエクスポートなら出来たことはあった。

アナウンスでは”よくある質問ページをご覧ください”って書いてるけど、関連する情報としてはGoogle ドキュメントへのエクスポートくらいしか書いてない。そのせいか、Googleの言うエクスポートがほんとに実行されるか非常に不安だ。

また、Googleによる強制的なエクスポートが実行されたとして、今までのブックマークと似たようなノートブックへのメモ追加の操作をどうするかも悩みのタネ。メモをブックマーク登録するのは可能だけど、ブックマークのエクスポートはブックマーク全体で1つ。ラベル単位では出来ない(みたい)だ。先々のメモ作成の操作をどうするかも悩みどころ。

思うにGoogleノートブックって、ホームページの写真なども含めて(選択部分を)ごっそり保存できる。使う側からするとシンプルな操作だし便利。しかしサービス供給側からすると、それに応じた記憶エリアを用意しないと行けないし、検索なども可能なのでそちらの処理も必要だ。つまりデータが爆発的に増えていく。しかも、ノートブックのみでは広告収入のような収益に結びつく方策がない。利用してて言うのもおかしいが、技術的には容易でも、データ量とか収益といった現実的な考えが乏しかったサービスとも言える。日本だと、特にデータ量なども含めて検討するので、なかなか立ち上げにくいサービスのように思えてきた。ネットサービスのこれからを考える意味でも、参考になるのかもしれない。


Googleノートブック。せめて、何月頃に終了する予定とか書かれていれば、エクスポートの準備なり心づもりも可能なので良いのだが、、、、、。

11月 6, 2011 ソフトウェア, パソコン・インターネット | | コメント (0) | トラックバック (0)

2011年11月 2日 (水)

iPadでのマインドマップツール

iPadでのマインドマップツール選びに一苦労。以前、Mind42のことを書いたけど、少し修正などでブラッシュアップする必要が発生した。以前のブログにも書いたように、Mind42だと修正とかが出来ない。そこが難点。ノード部分を選択してダブルクリックしても、文字列修正にならない。

念のためと思って、Bluetoothキーボードをつなげてみたが駄目。iPadのマウス接続のことがネットで書かれているけど、自己責任だしマインドマップのためだけに一苦労するのも大変。またマウス接続で、Mind42の操作がうまく行くとも限らないので断念。

Mind42を少し使ったせいか、PC(Windows)でも操作できるのがよいと考えてWebサービスを調べたら、フリーなら公開モードでしか利用できないとか、FLASHを使っていてiPadでは駄目だとか、Javaの関係なのかWindowsのみの利用とか出て、良いのが見つからない。

また、マインドマップツールでWindowsでもiPadでもと言うのが、なかなか無い。OPML形式などに変換して複数のツールで利用する方法もあるが、ひらめいたことを保存する程度にしては大袈裟過ぎる気がして乗り気にならず。

アウトラインプロセッサーソフトでは、さらにWindowsでもiPadでも動くものは見つからず。ふと、Googleドキュメントでのアウトラインモードの利用を思いついたが、なんとiPadでは携帯と認識するせいか、アウトラインモードそのものを利用できない。Evernoteでは、アウトラインモードもだが、そもそも段落の考えがない。

色々調べても、自分の操作方法にフィットしたものが見つからない。時間も勿体ないので、新しいツールの利用は諦めた。少し時間が経ってから、また考えることにした。


ある意味、ソフトウェアツールが過渡期なのかもしれない。AppStoreで、iPad向けやiPhone向けのソフトがいくつも表示されるのに対して、従来のWindowsなどのツールのニュースが少なくなっているように感じた。マインドマップのようなツールは、iPadやiPhoneに向いており、Windowsでも利用する人が少なくなっているのかもしれない。

結局、先々は自分もiPadでのマインドマップツールになるのかもしれない。でも当面は、iPadでMind42に追記して、修正をパソコンで行う方法になりそうだ。

11月 2, 2011 ソフトウェア | | コメント (0) | トラックバック (0)

2011年10月22日 (土)

スクラムギャザリング 東京 2011

19日と今日は、「スクラムギャザリング 東京 2011」。Scrumに関する講演とワークショップ。2日間だが、日が少し離れていて、会場も別。

http://www.scrumgatheringtokyo.org/sgt2011/index.php?id=2

http://www.scrumgatheringtokyo.org/sgt2011/index.php?id=3

1日目は、野村コンファレンスプラザ日本橋。

綺麗なビル。プロジェクトマネジメント学会で懲りておにぎりなどを持参したけど、ビル内の共有スペースでは食事などは不可と。結局少し離れた公園で食べることにした。寒かったし、なかなか公園が見つからず。(ビル内や近くに安く食事できるところもあったので、そっちが良かったかも。事前案内が欲しかった。また、あの辺りってそれなりの広さの公園とかがない。震災とか考えると、結構不安。)

なお、会場内は、ビデオや写真撮影NG。録音もNG。TwitterつぶやきはOK。

オープニングでは、スクラムの概要の話や、参加者が水曜日180人、土曜日231人との話など。日本ではスクラムマスター231人、プロダクトオーナー48人、プロフェッショナル5人らしい。トレーナーとコーチはゼロ。ただし9月時点での調査で、認定サイトに国として日本を登録している人の数。(認定者自らが編集する必要があり編集してない人も多いだろうから、実数はもっと多いと思われる。個人的には、倍くらいか。)


Henrik Kniberg氏の講演では、冒頭に子供に整理整頓させるにはどうするかの事例で、自発性との関係が話された。タスクカンバンの警察での利用例など具体的で、また幅広い応用が可能であることを改めて示された感じ。ベロシティやペアプロに関する考えもいくつか示されて、参考になった。また、自分の家族との旅行と自分の仕事(講演)の話が、スクラムの手法を交えながら話された。終盤では、参考書籍の紹介。


Jeff Patton氏の講演は、usとthemの違いからスタート。(このテーマは、2日間で何度か出てきた。スクラムで言うところの”ニワトリ”と”ブタ”。)

会場の人達に挙手を依頼して、3つに分類。その後各テーブル(5,6人)に分類した3つの人がバランス良く席について、各自の問題点などを列挙するとかした。一種のワークショップ。3つは、意志決定、管理者(プロジェクトマネージャーくらいの意図)、作製者。会場自体の分類が結構偏っていたり、自分の属するテーブルの人達の中で話がうまくまとまらなかった。人数が同じになるような調整とか、テーブル内で立場変更とかやったんだけど、、、。人数が多かったことや、テーブル間移動がちょっと面倒だったのも災いしたかな。個人的には、ちょっと不完全燃焼。


午後からは国内事例。個人的に楽しみにしていた講演。

冒頭のYahoo! JAPANでの事例では、標準化との関係や社内への浸透での苦労話なども聞けて、どこも同じなのかとかYahoo!ですらそうなのかと感じた次第。ただ、目標業績評価制度とか内部統制との関連などを意識しており、それなりの大きさの企業での課題となる事への取り組みを先行して行おうとしていると受け取った。

エムティーアイの発表では、(終盤で話の出た)スクラムマスター66人との言に、自分もだけど結構驚きの声。発表者が日系ブラジル人というのも興味が出てきた。(社内調整で苦労があっただろうにとか、、、。懇親会で、ちらっと質問したりした。) スライドにいくつか面白ネタもあって、そっちも面白かった。

出雲村田製作・テクノプロジェクトの発表は、発注者と受注者が同時に発表するという、ある意味ユニークなプレゼン。地方での事例と言うことも目を引いた。(懇親会では、Rubyとの関連やコーチの人が四国であることの背景などを聞いて納得。)


懇親会は同じビル内。技術系のパーティ形式懇親会としては、料理が美味しかった。色んな人との会話では、既に述べたようなやり取りなどを行えて、参考になった。Yahoo!の講演者とは直接話せなかったが、会場に社員らしき人がいて従来スキームとの関係などを質問。実践の細部は各社で違うけど、そう急激に変貌させてないのはどこも同じと受け取った。


2日目は、早稲田大学。写真撮影NGなどは、1日目と同じ。

帰りにコリアンタウンにでも寄ってみようと、新大久保の駅から歩きにした。門から会場のビルまでの間に、コンビニタイプのお店があると思っていたら無し。昼ご飯のおにぎりなどのために、一旦外に出ることにした。近くにマクドナルドとかユニクロもあって、大学の周りが様変わりしている感じ。(って、2,3回しか来てないし、ちゃんとした記憶がある訳じゃないけど。)

受講したのは、午前は大きな会場(A/B会場)での講演的な話し。午後は、全部C会場での中級SM(スクラムマスター)向けのワークショップ。

CollabNet副社長の講演は、大企業でのアジャイル化戦略。CollabNetは、分散型ソフトウェア開発環境プラットフォームやツールを提供している。3000ユーザー企業と言っていた。従業員は、100を越える国に31000人。(思ったよりも人数が多いけど、利用者など別な種類も含めて聞き違いかも。)

プラットフォームやツールの話よりも、アジャイル化適応のパターン(確立、展開、拡大)の話や、変革の管理の話が主。AMDOCSなどの、ユーザの声の紹介などもあった。


ソニックガーデンの倉貫氏とアマゾンの玉川氏によるアジャイルとクラウドのトークセッションは、EC2やネットフィックス社やリーンスタートアップと、多少技術的な話しもあったけどビジネス目線が多かったかな。テンポ良く進んだけど、我々のようなタイプ(世代)には、話の分野のジャンプも少なくないしちょっと速すぎだったように感じた。


富士通の人達の話は、東日本大震災での動物医療クラウドの話が主。現地へのソフト供給というかシステム化の後、震災現場での要望などでの変更も大変だったと受け取った。あるいは、震災への対応という点を考えるなら、もっとシンプルな仕組みや機能の方が良かったのかとも。


午後からのは少し本格的なワークショップ。講師陣を囲む格好での挙手などによるグループ分けしながら、参加メンバー間で現状の問題分析などの議論を行うワークショップ。示されたタスクボードの事例に関して、テーブルの各グループでの議論(気づき)を深めるワークショップ。「バトルロイヤル」称したセッションでは、ありそうな問題点に関する意見をグループ間で議論してまとめたり、そのことをコーチ役の人とさらに議論したりした。まとめた人によっては、コーチから少しコテンパタンにやられる人もいて、さすが「バトルロイヤル」だと納得。

午後のワークショップは、なかなか言葉で表現しにくい。参加したメンバーの、気づきを起こさせるプログラムになってたと考える。「バトルロイヤル」は結構面白くて、時間があっという間だった。(サポートで)コスプレの人が2,3人いて盛り上げたし、最後には認定証なるものを手渡す遊び心もあって楽しかった。


ラップアップでは、上海大会の様子の紹介や今回の開催への慰労へ感謝の拍手。また、テーブルの隣の人と、自分の課題やその対応を議論し合って紙に書いておくなど。(2週間後だったかに、実践したか情報のやり取りを行おうねとのことだったが、どれくらい実践するか??) 課題の議論は、多少ワークショップでのネタと被っているようにも感じた。

ワークショップの「バトルロイヤル」では知った人とペアになりそうだったけど替えてもらったり、ラップアップでの隣の人も少しは知った人だった。知った人とのペアは、気が楽になる時もあれば、設問によってはやりにくい時もある。スクラムの集まりでは、それまでの研修や飲み会なども含めて知った顔が多くなる。ワークショップの時はある程度突っ込んだ課題になるかもと思って、知った人の席に近づいとくか離れとくか考えた方が良いのかもしれない。講師による質問想定とか、その日の気分によるのかな。今回は二人とも気さくな人だったり、すんなりペア交代に応じてもらい、気が楽だった。

充実した2日間だった。宴会の類があるかもと思ったけど、明日はマラソン大会に向けての練習をする予定で、帰宅。コリアンタウンは、ちょっと歩いて回る程度にした。健康食品っぽいお店があれば行ってみようと思ってたけど、案内地図などをプリントして無くて、町並みを見学した程度。人は多かった。

スクラムメンバーのTwitterで、焼き肉での宴会になったようだ。勿体ない事をしたと思ったけど、仕方ない。機会あれば、また飲み会の類に参加しようと思う。

10月 22, 2011 ソフトウェア | | コメント (0) | トラックバック (0)

2011年9月 9日 (金)

日経コンピュータなどの電子書籍化

本棚の整理で、ついに(というのもおかしいが)雑誌関係も電子ブック化することにした。いわゆる”自炊”と”他炊”。自炊なのは雑誌の一部分を残しているもので、日経エレクトロニクスとか日経コンピュータなど日経の雑誌が多い。他炊なのは、1冊のままで残していたものでBitなど。ちなみに、そもそも雑誌をスキャンしてくれるサービス会社が少ないし、切り抜きしたものを行ってくれるところは皆無。時々利用していたスキャンサービスの会社は、以前は雑誌OKだったのに最近雑誌などサービスの一部を中止してしまった。

日経エレクトロニクスは結構長く購読してたけど、ハードウェアとの関係が薄れたし、本屋さんでの購入や一部分の記事購入も可能となって年間購読は止めてしまった。そのせいもあって、思い切って電子化しておこうとの気持ちに。そうなると、ついでに日経コンピュータなどの方もとの気持ちになって、そちらも電子化することにした。日経コンピュータなどもファイルにしてると、取り出したり開いたりするのにちょっと体力が必要で、面倒くささを感じてしまうようになったためだ。(少し情けない。^.^;;)

ちなみに、雑誌の自炊での注意点は、表紙部分だろう。膠(にかわ)?の付き方が違うのか、表紙とその後の2,3枚はくっつきやすい。つまりスキャナーで重送になりやすい。思い切って幅を短めにカットすればいいが、表紙での文字まで切れてしまうことになって、実際やりながら改良するしかない。(スキャンサービスで雑誌が敬遠されるのも、その辺りが原因だろう。)

P90905962で、日経コンピュータの自炊前に撮影したのが左の写真。丁度創刊準備号から残していたので、懐かしくてパチリ。

上での一番左が、1981年の準備号(特別版春季号)の表紙、真ん中が1982年の1月11日号、右からはそれ移行の各年の初号表紙である。今から思えば初歩的なCGと言っても良さそうな画像の表紙が、10年ほど続いている。当時はCG自体が珍しかったが、こうして今の目線で表紙を眺めると時代の進歩を感じる。

また自炊しながら内容も眺めたりしたが、当時の記事や寄稿には、ITシステムの手作り感が多かった。ITシステムがプログラミングであり、品質を上げるために静的解析ツールを自社開発したり、ドキュメント作成での工夫点などの寄稿が少なくない。今よりも、システム発表の場になっているイメージ。また、システム化やツール化での割り切りの記載などもあって、個人的には今でも参考になりそうな事項も少なくなくて好感。(何となく、最近はなんでも出来るとか、100%達成みたいな内容が少なくない。)

また、長い期間で眺めると、流行の廃れや人物往来に思いを馳せる時も出てきて興味深い。大々的に取り上げていたものが急に話題から遠ざかったり今となっては不成功の烙印を押されたり、、、。人物に関する事項も、「そう言えばあの人は?」と行方などが気になる人も少なくない。なお、業界の浮き沈みという視点では、日経エレクトロニクスで取り上げられた製品群、技術や会社の落差が大きいような気がする。海外移転や空洞化の話題が増えているからなおさらだ。

今や代表的なスキャナーにはOCR機能がついてるので、自分の設定ではOCR処理済みのPDFファイルにしている。その辺りも、後の検索容易さなどで便利だ。もちろんOCR機能は十分な認識率とは言えないが、しおり(Bookmark)の作成には重宝する。

温故知新じゃないが、自炊しながら昔を振り返るのは悪いことではないと改めて認識した次第。

9月 9, 2011 ソフトウェア, 日記・コラム・つぶやき, 書籍・雑誌, 電子ブック | | コメント (0) | トラックバック (0)

2011年9月 1日 (木)

QCDバランスと三角グラフ

QCD(Quality:品質 Cost:コスト Delivery:納期)のバランスをどうするかは、プロジェクトそのものの方針やプロジェクトマネジメントで大きな課題だ。また、そのバランスの可視化は、以前から少し気にしていた。

「アジャイルサムライ」のP89に”トレードオフ・スライダー”の名前で紹介されているのがあり、調査。アジャイル系コミュで以下のサイトが紹介されていて、ちょっと使ってみた。

http://www.mountaingoatsoftware.com/tools/project-success

Photo_2Web上でできるのが、なかなか良い。ただし、自分の頭のイメージにあるのと少し異なる。

トレードオフ・スライダーを見て、自分の頭に漠然とあるものを具現化できる術がないか、ちょっと考えてみた。グラフ種になかったけ?と思って、(今はあんまり使ってない)DeltaGraphのマニュアルを見たら、すぐに見つかった。”三角グラフ”。もっと早めに気づくべきだったかも。

で、Web上で書けるツールはないか探したけど、すぐには見つからなかった。DeltaGraphなどで書けるのは判ってるけど、、、。ちょっとエクセルのアドオンなどにないか調べたら、そちらですぐに見つかった。「Excelによる統計グラフ表現法」第32回(古田 裕繁 著)を参考にしたマクロのようだ。

http://www.sinfonica.or.jp/kanko/estrela/refer/s16/index.html

マクロをインストールするというよりも、ここでの(マクロを含んだ)エクセルシートを利用してグラフを作成してみる感じ。使い方としても、その方が良いかもしれない。

Qcdそれを利用して、品質50%、コスト40%、納期10%をグラフ化したもの。マクロのためのセルがあるようで、敢えてそれらはそのままにした。

プロジェクトでのQCDバランスを可視化しておくには、このようなグラフを残しておいた方が良いかもしれない。最初は品質重視と言いながら、テスト工数などを見積もる/見積もらせることもなく日程が延びたりコストアップ。プロジェクトのさらなる上位層は、後の方になって”がみがみ”。雑誌の記事などで、そんなことが少なくないように思う。プロジェクトの開始時に、このようなQCDのバランス図を記録に残しておけば、少しはましになるのではないだろうか。

なお、ここでは作図ツールを利用したが、線の入った三角形の図のみをプリントして、マグネットか何かを上に置いてデジカメ撮影したものを残す方式でも良いだろう。あるいは、それを壁に貼っておく方法。

ちなみに、QCDバランスでは、3つの合計が100%になる必要があるが、グラフ上はそれ以外も作成できる。したがって、100%に制限するようなマクロとか操作方法も考えられる。が、余力があればかな。

また、上で書いたマグネットを置く方法では、厳密にはその中心で3つの合計が100%になるとは限らない。ただし三角形の中なら、(多分)誤差の範疇だろう。さらには、QCD以外の要素を含めるケースもあるようで、4軸なら「Jチャート」と呼ぶグラフもあるようで利用できるだろう。(個人的には3つのバランスで十分とか、3角グラフを複数用意する方式でも良さそうに思う。)

9月 1, 2011 ソフトウェア, プロジェクトマネジメント, プロジェクト管理 | | コメント (0) | トラックバック (0)

2011年8月11日 (木)

iPadでの音声認識ソフト

一昨日、iPadにお試し的に音声認識ソフトをインストールしてみた。ひどくないというか、そこそこ使えそう。自分のデスクトップPCだと、音声認識のためにはヘッドセットを取り出して接続が必要で、ちょっと面倒。しかも最近は、閲覧のPDFファイルやメールをiPadで見ることが多いので、メモ的なものはiPad操作の際に多くが発生する。メモを音声認識で残せれば便利と考えて、お試し的にインストール。もう少し早めに気がつけば良かったのだが。

ただし一昨日試したのは、クリックで一挙に変換結果が表示されるタイプ。逐次表示のものとかが自分には合ってそうとのことで、今朝物色。良さそうなのが見つかり、さっきダウンロード。「音声認識メールST(3GS以上専用)」。

http://itunes.apple.com/jp/app/id347250830?mt=8

ソフトウェアのタイトルだとiPad向けに思えないが、条件などに記載してあるようにiPadでも大丈夫。また、以前は115円していたようだが、今は85円。(「音声認識メール クラウド」の方が機能が充実してるようだが、オフラインでの利用もあるし何日かでの利用更新も気になったので、ST版にした。)

音声認識の機能は、思ったよりも素晴らしい。もっぱら連続入力のモードで利用すると思う。文の区切りで認識結果が出るので、それを多少確認しながら次の文を入れるやり方だ。多少、そのための効率落ちるけど、その都度の修正とかができるので自分には合ってる。

また、Evernoteとの連携が可能なのもメリット。デフォルトのノートブックに、認識結果のテキストを置ける。他のアプリもデフォルトノートブックへ置くので、ちょっとEvernoteのデフォルトノートブック名を変更した。 他にTwitterへの投稿なども可能だ。

8月 11, 2011 ソフトウェア, テクノロジー, パソコン・インターネット | | コメント (0) | トラックバック (0)

2011年8月 9日 (火)

Twitterが強制的に新バージョンになって、、、

Twitterの公式Web表示版が、強制的に新バージョンになってしまった。以前から、切り替わりますよとの表示はあったんだけど、、、。

今まで旧バージョン表示にしてた大きな理由は、Twitterの「おすすめユーザ」を消したかったから。こればかりは好みの問題なのかもしれないが。

で、強制的な新バージョン移行で、改めて「おすすめユーザ」(Who to Follow)を消す方法を模索。以前からStylishを使って消すスクリプトをインストールしてたけど、新バージョンで消えない。改めてStylishのサイトを調べたら、更新版(暫定版?)が置いてあった。そちらのインストールで消すことができた。

http://forum.userstyles.org/discussion/27625/x

本来は、スクリプトの意味などをちゃんと分かってやるべき何だろうけど、、、。

8月 9, 2011 ソフトウェア, パソコン・インターネット | | コメント (0) | トラックバック (0)

2011年8月 1日 (月)

イテレーションとトヨタカレンダー

先だっての講習で、イテレーションを全世界共通にして、(各国間の相違を含め)祝日によるベロシティ差異を吸収するにはトヨタカレンダー(方式)が良いよな~と漠然と考えてた。

で、今朝、トヨタの採用情報を確認。

http://toyota-saiyo.com/tech/i_recruit/index.html

「完全週休2日制(土・日)、GW・夏期・年末年始休暇」の文字。つまり休みに祝日がない。

もちろん冒頭で年間休日数を書いてあるし、トヨタ/トヨタグループに就職しようとしたら、ある程度トヨタカレンダーを知ってて混乱は無いのだろう。

ちなみに、似たような会社がないのか「”完全週休2日制(土・日)” -祝日」で検索したけど、”祝祭日”とか”国民の休日”とかの表記もあって、自動的に見つけるのは困難。でも、エンジニアリング会社で採用している会社もあったりした。

また、日産は以下の表記。(祝日が休みというわけじゃないようで、変則的ということか。)

http://recruit.nissan-careers.com/info/index.html

「週休2日制(※当社カレンダーによる、月5~8日)年間121日」


これから、ちょっと気にしておくつもり。

8月 1, 2011 ソフトウェア, プロジェクトマネジメント, 自動車 | | コメント (0) | トラックバック (0)

2011年7月29日 (金)

プロダクトオーナー研修

昨日と今日は、認定スクラムプロダクトオーナー(CSPO)の研修。場所は秋葉原、講師はVernon Stinebaker氏など。ちなみに「プロダクトオーナー」は、ソフトウェア開発手法”スクラム”での役割の一つで、ソフトウェアプロダクトの総責任者。ユーザ要求の管理やビジネス視点での責任を担う。

研修内容細部についてはここでは余り触れないが、勉強になることが多かった。ある程度知っていることでも研修の実作業で気づきも発生したし、研修中のQ&Aや研修後の懇親会で深掘りできた。ちなみに、開催社による”プランニングポーカー”を入手。

4つほど、思いついたことを記載しておく。

・即席チームのファシリテーション

今回の研修では、スクラムを相当実践している人から、ほとんど知らない人まで知識レベルが様々。グループ間のレベル差をなくすために、各グループに色んなレベルの人が混在する編成となった。

講師の問いかけやグループ活動で、スクラムマスターの人達が他のメンバーの発言を促そうとの意図から、発言を控えることが時々あった/あるように感じた。初日の懇親会で少し話題にしたら、余り気にすることなく発言すべきとの意見が。

即席のチーム、しかもレベルの差が大きなチームのファシリテーションの難しさを痛感。あまり知らないメンバーからでも発言があれば、そこからアイデアなどが発展することも少なくないのだが、、、。もしくは、ある程度グループ間競争やその意識を、ゲームなどの格好で取り入れた方が良いのかも知れない。

・実務に近い演習

今回の演習(ゲーム)では、実際のソフトウェア開発を想定してのプロジェクト。タスクカード作成やスプリント見積りもりをチームで行った。タスクカードに対する考え方がメンバー間で大きく異なったのには、ちょっと驚いた。独り言のように、タスクカードに書く内容をつぶやきながら作業すれば、(即席チームのせいもあるけど)ブレは少なくなったかのかもとか考えさせられる点も。

また、見積りはプランニングポーカーで行ったが、時々見積りに大きなばらつきが。チーム内で大きくばらついた理由の多くは、実装方法に依存した。実装に関する基本的な事項を、チームで述べ合うのも悪くない(むしろ良いこと)と感じた。

いずれにしろ普段スクラムを実践している人にとっても、意外な考え方などに遭遇して、ためになったと思う。

・”スクラム”のプレゼン資料が7人制ラグビー

たいしたことでもないかも知れないけど、、、。一般的に、スクラムでのチームサイズは、7プラスマイナス2人程度が良いとされている。もちろんスクラム・オブ・スクラムにより、チームを階層的にしたりして大人数でのスクラムの実践もある。また逆に、3,4人での小さなスクラムチームでの事例の話も少なくない。

ただ7人という人数に拘れば、15人制ラグビーはスクラムだけでも8人であり、少し人数が多い。またスクラム(のみ)の写真では、チームとして得点を獲得するとのイメージとは少し離れてしまう。7人制ラグビーでのスクラムだと、人数少ないし、他のメンバーを含めた7人で得点を重ねるとのイメージが生まれやすい。

講習の際に、そんなこと思いながら、「7人制ラグビーですね」とか言おうか考えたけど、話題はどんどん先に進んでしまった。^.^; 意図しての写真だったか、Q&Aでも聞いても良かったけど、、、、。まっ、頭の隅に入れておき、講習スライドなどを目にすることあったら話題にするかも。 (ちなみに、個人的にはゲームとしての7人制ラグビーは面白味が今ひとつと思えてる。人数の件よりも、15人制と同じフィールドの大きさのためかな。なお、7人制ラグビーは、2016年のリオデジャネイロオリンピックの正式種目で、女子ラグビーはオリンピック初登場。)

・PDU付与

今回の研修は、PDU(Professional Development Unit)が付与されるとなってた。PDUは、プロジェクトマネジメント資格PMPの受験や資格維持のために、必要な単位が決まっている。申込みの際の案内でも判ったのかも知れないが、気がついたのは研修の前日。ある意味個人的にはラッキーだったし、PMIの本部がアジャイル関係資格へ動いていたり、そもそも以前からアジャイルへの取り組みが活発なためだろう。


2日間の研修中のQ&Aで、プロダクトオーナーがスプリントの最初でバックログをレディにする率なども話に出て、考えさせられた。(正確には、レディにしているスクラムチームの割合。) 他にタスクカードの粒度に関しても、工夫の事例の話も出て参考になった。有益な2日間だった。

7月 29, 2011 ソフトウェア, プロジェクトマネジメント | | コメント (0) | トラックバック (0)

2011年6月23日 (木)

IBM100周年ビデオでの「ブルックス」

先週だったか、日本IBMに行った際のロビーで目に付いたのが、ブルックス。IBMのシステム360システムの開発マネージャであるが、「ソフトウェア開発の神話」「人月の神話」の著者との方が馴染みがあるかもしれない。(「人月の神話」は、「ソフトウェア開発の神話」の改訂版。)

その際にちらっと見たのは、上司になるボブ・エバンスが、意見の対立した彼をメンバーに含めるくだり。

今日、もしかしたらYouTubeにアップされてないかと調べたら発見。まださらっとしか見てないが、360システムの次には、飛行機の予約システムSABREに関するインタビューもあるので、いくつかのシステムが取り上げられているのだろう。

プロモーション的なIBM100周年のビデオも見たが、技術屋さんにはこちらの方が面白いような気もする。土日に、じっくりと見てみようと思う。

6月 23, 2011 ソフトウェア, テクノロジー | | コメント (0) | トラックバック (0)

2011年6月21日 (火)

マインドマップツール(Webサービス) Mind42

今日もう一つ見つけたのが、マインドマップツール(Webサービス)。Mind42.com

結構長い期間、WebサービスレベルでのマインドマップツールはMindMeisterを利用してた。一時期は有料コースにしたが、最近は協業でマインドマップを作成することが少なくなり無料コースへ。しかし、Mindmeister自体が無料では最大3つのマップしか作ることができなくなり、少し悩んでいた。PCベースで動かすソフトは持ってるし、協業でマインドマップを作ることは少ない、でも(無料で)3つじゃ少なすぎる。

今日何気に探し当てたのが、Mind42.com。利用のためには、メールアドレスなどでのアカウント取得するタイプ。

http://mind42.com/

細部まで読み切ってはいないが、フリーでも個数に制限は無さそう。実験で5つ作ってみたけど、特にエラーなどにはならなかった。

もしかしたら、以前も検討での1つだったかもしれない。昔は協業が大きなテーマだったので、MindMeisterにしたような気もする。ただそのニーズは一過性で、最近は協業でのマップ作成がめっきり減ったのでMind42で十分と思う。

また、個人的に非常に重宝しそうなのが、iPadでも使えること。なお、子ノードの作成などをPCではTabキーで行えるが、iPadでは(多分)行えない。カーソルというか指でクリックして、子ノード生成を指示することになる。 まっ、iPadでは、ちょっとした修正や他で作成したマップの閲覧ができれば十分なので、あまり苦にはならなさそうだ。

こちらのツール(サービス)も、しばらく使ってみる予定。


追記:iPadで使えるって書いたけど、マップの修正はどうもうまく行かない。新規での操作もiPadだと多少まどろっこしいので、閲覧が可能くらいに考えた方が良さそう。

6月 21, 2011 ソフトウェア, パソコン・インターネット | | コメント (0) | トラックバック (0)

プロジェクト管理ソフト (Webサービス) Gantter

今日見つけたのが、プロジェクト管理のソフトというかWebサービス。無料。Gantter。

https://app.gantter.com/

先行タスクの指定とか達成率の入力などが可能。MS Project形式でのやりとりも可能。テスト的に作ってみたのが以下。

Gantterテストした限りでは、日本語もOK。

iPadでもそれっぽく動いたけど、実際の作成や閲覧は実用的では無さそう。なお、画像ファイルへのエキスポートは可能で、機能的には多少不満もあるがiPadで見ることも可能ではある。

自分の場合は、Googleアカウントを利用してプロジェクトのファイルの作成などを行った。ファイルの保存も(主として)Googleドキュメント経由とした。

以前ここのブログで、Googleドキュメントでガントチャートを作成してみたけど、その方法よりも楽。
http://blog-honda.cocolog-nifty.com/gijyutuya_nikki/2009/11/google-6169.html


複数PCでの簡単なスケジュールの作成や検討の作業で、しばらく使ってみるつもり。


6月 21, 2011 ソフトウェア, プロジェクトマネジメント | | コメント (0) | トラックバック (0)

2011年5月19日 (木)

注意報や警報の情報

今回の震災に関連して色々調べて、利用してはじめたサービスに「横浜市注意報警報情報」がある。横浜市では、同報系防災無線の設置が見送られているのも理由。

最初は、近くの川が気になって水位の警報程度のみを受信するようにしていた。ところが、雷などを含む注意報も受信しようと設定を変更。最近ほとんどの注意報/警報を受信するようにした。結構便利なんだけど、できれば、あと何時間くらいで発生するかとか警報に変わる可能性があるとかが判ると良いな~というのが感想だった。少し調べたので、メモのつもりで書いとく。

まず、今日10時での横浜市からの注意報のメール文。他に情報のURLなどがある。

■気象警報注意報情報 2011年05月19日 10時08分発表 横浜市:  強風注意報(発表)


で、気象庁の方はどうなってるかというと、以下のページにあって、結構詳しい情報が掲載されている。(以下のページは、注意報などの発生や解除で更新される。)

http://www.jma.go.jp/jp/warn/1410000.html

平成23年 5月19日10時08分 横浜地方気象台発表

神奈川県の注意警戒事項
 神奈川県では、19日昼過ぎから20日明け方まで強風に注意して下さい。東部では、19日夕方から20日明け方まで高波に注意して下さい。


===================================
横浜市 [発表]強風注意報 
 風 注意期間 19日昼過ぎから 19日夜遅くまで
   南の風
   海上 最大風速 12メートル

特に、いつくらいからがあるのが、ありがたい。(一昨日だったかの雷注意報には、いつからとはなかったように思うので、気象の種類によるのかもしれない。)

これらの情報は、週間の予報や当日とか明日の予報を知って使うのが良いのだろう。注意報が警報の前触れかは、そのような知識が役立つ。


なお、気象庁のページを見て、それぞれの注意報や警報の判断基準などを読んでみたら、自治体などで異なるなど相当複雑。花粉の情報なども、(当然)予測には気象データや気象モデルなども利用している。単に“気象データ”とか”予測”って言うけど、この辺りのコンピュータによる(有限要素法などを利用した)処理が複雑なり多量データなのはご存じのとおり。精度を高めるにはデータのメッシュを細かくする必要があるし、それは計算負荷に結びつく。

注意報の発令をちょっと考えてみたけど、予測を10分後、20分後、、、、等で行い、各自治体毎の基準に照らして判断することになる。項目も風力だったり水位だったりする。各メッシュでのポイントがどこの自治体に属するか判断して基準との比較を行うのだろう。ただし、単純に全メッシュ毎に全予測を行い、全項目の基準との比較を行うと、無駄な処理が増える気がする。多分アルゴリズムなどは工夫しているのだろう。

今まではTVでの天気予報とか花粉情報を目にしたり気にかける程度だったけど、注意報や警報の発令を調べたり市の注意報警報情報サービスを利用してみると、奥が深いな~という感想。紫外線とか人々の予報への要望への対応?もあるし、逆に桜の開花予報のように止めた対応もある。計算の複雑さやその回避に関しては、懇親会などの何かの折りに、詳しい人がいたら聞いてみるつもり。

5月 19, 2011 ソフトウェア, テクノロジー, 安心・安全 | | コメント (0) | トラックバック (0)

2011年5月12日 (木)

オープンソースの静的解析ソフト

今日の「Japan IT Week 2011」で見かけたもの。以前ブログで「ソース・コード静的検証によるソフトウェア品質評価の意義」というのを書いたけど、それにも関連する。以前でのブログは、オージス総研での”Adqua”による品質評価ツールに関するもの。そのツールのためには、QACやQAC++が必要だった。(ただし、無償利用のためには、1年間に1件以上の測定データ提出が必要。)

今回オージス総研で展示されていたのは、QACの代用に該当するもので、オープンソースの静的解析ソフト。「AdLint」。AdLintの出力を利用してのAdquaの利用が可能とのこと。GPLなので、社内向けの改良なども可能と思われる。

静的解析も、QACなどのような商品ツール、IT企業による解析サービス、Adquaなどのように俯瞰的な調査サービスなどもあって千差万別である。複数のツールやサービスを利用しているところも少なくないようである。逆に、どんなポリシーで利用するかを組織体で明確にしないと、解析結果に振り回されることになるかもしれない。


ちなみにご存じのように、lintはUNIXなどに備わっているCのコードチェッカー。また、AdLint自体は、C++には現時点では未対応のようだ。

5月 12, 2011 ソフトウェア | | コメント (0) | トラックバック (0)

Japan IT Week 2011

今日は、東京ビッグサイトでの展示会見学。「Japan IT Week 2011」で、ソフトウェア開発環境展や組込みシステム開発技術展などの合同展示。

組込みシステム開発技術展のみが西館(ゆりかもめ駅に近い方)で、そのほかの展示は東館。昨年よりもクラウドコンピューティングEXPOの出展社が増えたことや、スマートフォン&モバイルEXPOの第1回も開催されたことで、IT系のクラウドやWeb系の展示が増えたように感じた。また、西館の方が見学者密度が少なかったように思えた。

クラウドやWeb系としては、個人的には複合機のSalesforceやSAMBAとの連携などが印象的だった。プロジェクト管理(勤怠と言うべきか)をSalesforceで行うシステムなどの展示もあり、月利用料金の安さなどが目を引いた。Salesforce Chatterをベースにした「スマートスクラム」と呼ぶサービスの展示がありSCRUMを多少イメージしてるとの説明だったが、SCRUMとの関連性は良くわからなかった。

アマゾンウェブサービス(AWS)の展示もあった。クラウドでのPDF全文検索とかモバイルコンテンツ変換や電子ブック変換が個人的に印象的。またスマートフォン利用システムは数多く展示されてた。

開発関係では、静的解析やオープンソースに関するサービスが増えたように思う。従来もコンピュータメーカーでのサービスはあったが、NRIのような企業のサービスの展示もあって、広がったイメージ。下請けなり関連会社に導入してもらうことで売り上げにもなるし信頼性向上にもなるので、メリットに結びつくのかもしれない。(運用を間違うとおかしな事になる危惧はあるけど。) テストケース生成の展示もあったが、数は少なかったように思う。 なお、オープンソースの静的解析ツールに関しては別掲。

IBMは災害対策支援も展示してた。

個人的には、HOYAの音声合成ソフトウェア「VOICE TEXT」が面白かった。結構声の抑揚への対応が出来てて自然。文字列で”柿と牡蠣”(だったか”箸と橋”だったか)と入力して発声させてみた。逆にそのための音声データの準備が必要。他に「カラービット」も面白く感じたが、個人的には利用は限定的というか各ユーザの用途に応じてシステム化して収めるケースが多いように思えた。


Webやクラウド、スマートフォンの利用が急拡大する/しているのを、肌で感じた1日だった。それにしても人が多く、次回は見学時間帯や回り方などを少し考えたい。

5月 12, 2011 ソフトウェア, 日記・コラム・つぶやき | | コメント (0) | トラックバック (0)

2011年5月11日 (水)

成熟度と競争優位性

Maturity Model での「成熟」って何だろうって考えることがある。”成熟”という言葉そのものには成長のようなイメージがあって前向きだけど、”熟女”とか”熟年”とかなると、少し陰りのあるようなイメージも付きまとう。

個人的に、CMMが弊害が多い(多かった)との印象があるせいか、成熟度は高ければ高いほど良いというわけでもないだろうにと思えてしまう。ちなみに、CMMでの印象が良くないのは、レベル2認定のため”だけ”に構成管理などを一生懸命やる話を聞いたりしているためだ。レビューなどのレベル3などの話には目もくれない。相手先の条件などのための認定取得ではなく、自組織のプロセス改善のために改善。スタッフが盲目的に指導して、現場とかは混乱するケース。端的には、構成管理のツール(のみの)導入や厳格な運用をしようとして、現場はうんざりといった感じ。(しかも予算の関係もあるだろうけど、継続的な改善として次のレベルを目指すとかCMMI認定を意識することがないようだ。)


で、最近ちょっと目にしたのが、ジェイ・B・バーニーの「競争優位の構築と持続」。

持続的競争優位性として、”自社の持つ経営資源は真似されにくいかどうか?”を挙げている。

また、画家の猪熊弦一郎が、尊敬していた師匠アンリ・マティスから「お前の絵は。うますぎる。」と言われてから自分の作風を確立していった逸話も目にした

スポーツ選手やチームが、その特徴を「弱点であり強み」と表現することがあるように、自分やそのチーム自身の特徴が強みであると同時に弱点になることがある。ただし、弱点部分を急に直そうとすると、バランスが非常に悪くなってしまう事が多い。

ある程度の成熟度のために自組織の成熟度を上げることは大事であるが、成熟度向上だけに固守するのもおかしな話である。また、参考とするその指標自体も数年もすれば改訂される。むしろ組織体の目標を明確にすることや継続的な改善をどうするかを検討すべきと言える。(スポーツの世界では、記録やリーグ優勝などの方が目標であり、打率などを成熟度での指標の1つと考えれば分かりやすいだろうか。)。

なお、昨今は企業経営が多岐にわたり、しかもダイナミックになってきた。1つの製品のみを扱うケースは皆無で、複数の事業を抱え、多くのグループ会社をもつ企業が多い。しかも、100%子会社ばかりではなく、資本支配や提携といった形態も少なくない。M&Aをはじめとして、全くの他企業を傘下に収めることも良く行われている。オーナー企業の方が、革新的な商品やサービスを提供しているケースが少なくない。

それらを考えれば、親企業などの特定企業や特定部署の開発プロセスとか管理方法を100%真似るような目標を持たせること自体が、非現実的である。一般的に言われている成熟度での、統一的な把握や制御は、困難とさえ思える。


とある会合で、成熟と”成長”とは相反するのじゃないかとの意見が出て、「なるほど!」と思った。成長を意識しつつ、成熟度の視点と継続的改善の視点の、両方を持つべきだろう。

5月 11, 2011 ソフトウェア, プロジェクトマネジメント | | コメント (0) | トラックバック (0)

2011年5月 8日 (日)

ISO/IEC 6592 (JIS X 0126)も悪くないかも

ISO/IEC 6592(JIS X 0126)は、「応用システムの文書化要領」と題され、ITシステムでの文書のひな形と言える。実は最近目にして、「悪くないな~」との印象。

正確にはJISは2001年に改訂され、そちらが好印象。従来いくつかの文書で構成されているものを、1つの文書(ただしサブ文書より構成される)の表記に変えている。JISの改訂そのものはISOの改訂によるが、そもそも日本は従来のいくつかの文書での構成としたかったらしい。(JIS X 0126の”解説”に詳しい。)

個人的には、設計ドキュメントは少ない方がよいとか少なくすべきとの考えだし、全体把握の文書があるべきとの考えなので、今回の改訂版の方が馴染みやすい。逆に、規格改定などをウォッチしておけば、早めに気がついたのにと少し反省。(以前の版だと、文書種の列挙で閉口したのだと思う。)

1 システム要求
 11 問題の定義
 12 目的
 :
2 システム記述
 21 システムの識別
  211 システム名称

のように書かれている。人的資源や費用/項目、長所/弱点といった項目もある。

個人的には、この規格をもとに、組織体で必要とされる項目を追加したり、対象物によっては未記載にする(削除する項目)などを検討しても良いだろう。また、この規格を文書一覧と考えて各文書を用意するよりも、ここでの項目をなるべく1つの文書にする方が良いと考える。

組込みでもそうだが、1つの製品なりシステムの文書化は、章立てをどうするかとか記載分担をどうするかが悩みの種。組込みでは、特に新規開発とか新分野の開発の場合が顕著である。文書の数を多くして、極端にはエクセルでの断片的な仕様表だらけとか、(やれエクセルが好きとかTexが好きとかで)多くのフォーマットでの文書の乱立ということもあるようだ。文書が増えればメンテナンスが大変だし、そもそも協業での変更管理やCO/CIに関連する弊害も発生する。

まっ、一見をお勧め。

5月 8, 2011 ソフトウェア, プロジェクトマネジメント | | コメント (0) | トラックバック (0)

2011年4月18日 (月)

ニフティ「TimeLine」サービス終了に向けて

ニフティの「TimeLine」は、結構気に入ってたサービスだった。実際自分でも作っているコンテンツがあった。それがサービス終了と。

http://timeline.nifty.com/

ちなみに、「TimeLine」での人気コンテンツは”日本史・合戦タイムライン”。ヤマトタケルの東征~第二次世界大戦までの戦いが、各々開始-終了の帯状に書かれている。戦によっては、攻防の図示もあって分かりやすい。


このサービスでの技術よりの特徴を言えば、以下のようになるだろうか。

・日時の指定が、年は西暦1年~9999年、時分秒も指定できる。

ただし、0年でも日によっては処理してくれるかもしれないし、時分秒を含めた細部の確認はしてない。

・見たい部分へのズームイン/ズームアウトが可能。

1画面内を、10年程度を納めるとか1分程度にする事ができる。もちろん、スライドバーを使って別の期間への表示も楽

・Webサービス。

つまり使用ソフトに依存しない。


サービス終了とのことで仕方ないので、他の方法を探そうとしてるけど見つからない。(というか自分もそうだが、コンテンツ書く時の検討で本TimeLineになったので、そう簡単に見つかるわけがない。)

まず日時は、エクセルなどのように処理の内部を特定日時を開始として数値処理することが多い。エクセルだとシリアル値と呼ぶもの。1900年辺りを開始にしている。ちなみにエクセルでの最大期日は、9999/12/31らしい。

ちなみにUnixの2038年問題というものがあり、2038年1月19日3時14分7秒(UTC)になると処理できなくなるというもの。ただし、C言語の実装で上記内部の数値を signed long int型 で処理している場合。long long int型などにしていれば、問題は発生しない。

できれば、プロジェクト管理ソフトで扱えれば良いんだけど、MS Projectでのプロジェクトの開始/終了は 1984/1/1~2049/12/31と、エクセルなどより制限している。(MS Project Pro 2010 お試しダウンロードでの実験)

念のためと思って GanttProject も再度試してみたけど、そもそも年の桁が2桁。


本音言えば、ニフティが有料化しても良いからサービス継続してくれればいいと思ってる。「TimeLine」はRuby on Railsで構築されており、Rubyの普及という観点では価値あるシステムとも思う。またメンテナンスも容易なのではないだろうか。 ただし、開発ブログなどから推察するに、もう開発メンバーがいないようで、機能アップは望むべくも無く、継続の実施になると思われる。あるいは、外部の団体が引き継いでも良さそうに思う。

そうは言っても、上の要望が通る可能性は薄いので、対応をいくつか考えてみた。

・年表作成ソフトの利用

シェアウェアのものを見つけたけど、難点は専用ソフトということ。コンテンツ公開をどうするかがネック。期間のズームインは貴重で、全部を1つのPDFにする方法も芳しくない。

・年月日を独自数値化

例えば、年部分を整数にして少数以下を1年に対する比率。閏年などを無視しても見かけ上は問題ない。

ただ、大きな課題は、その後の表示方法。そもそも”フローティング棒グラフ”がぴったり来るけど、エクセルでも多少作成が面倒。ズームインなどは横軸の最大値/最小値の操作になってしまう。

なお、Googleスプレッドでも積み上げグラフは作成可能。その利用だと利用ソフトに依存しないけど、”フローティング棒グラフ”が書けない。つまり系列を透明色にできない。またグラフ編集で、最小値などの指定ができないのもネック。

蛇足かもしれないけど、GoogleスプレッドではGoogle Motion chart という、ちょっと面白い機能を利用できる。でも、Motion chartでの”年”は1900年以降(ただし細部は未確認)なので、今回のような用途には利用不可。


色々考えてみたけど、上記対応では満足行くものがない。ほんと困った~。今後も探してみるけど、アイデアやヒントになりそうなものがあったら、コメント記載や直メールください。


4月 18, 2011 ソフトウェア, パソコン・インターネット | | コメント (4) | トラックバック (0)

2011年3月11日 (金)

アジャイルだって偽装請負には留意

少し旧聞の類だが、日経SYSTEM 2010年9月号のアジャイル特集で記載されていた「最近見たRFP(提案依頼書)の中に『開発はアジャイルで』と書かれていたことです」は、気になっていた。

RFPとか契約の類で具体的な表現をせずに、アジャイルと一括りに記載することって無いよな~というのが、率直な感想。ただし、実際のRFPでは具体的なプラクティスが記載されていたけど、紙面上ではぼかして記載したと考えられなくはない。(もしそうでも、アジャイルに興味ある読者を想定すれば、具体的に記載してあった方が良い。そこそこ浸透しだした昨今のことを考えれば。)

で、最近つぶやきの類で目に止まったのは、アジャイルと契約との関係。以前から報告書の類や会合では話題になってるので目新しいとは言えないが、実務で接するケースが増えたということだろう。しかも、ついつぶやきたくなるような事象が発生していると推察する。

アジャイルでやるようにと言われながらも、契約は一括請負とか、、、、、。でも、基本的に注意が必要なのは、「偽装請負」にならないかということ。これは、アジャイルだろうがなんだろうが関係ない。 偽装請負は違法行為で、新聞などで目にすることもある。

偽装請負については、会社で教育されたりもする。例えば、請負契約での担当者を自社構内で作業させてた。ある時、自社内の引っ越しが発生した。その作業担当者の机等も引っ越に関係するので、引っ越しのための作業を作業担当者に指示した。○ですか×ですか? なんていう質問が、新人なり中堅社員向けの教育で行われたりする。実際の教育になくても、基本が判れば回答できる範疇だろう。場合によっては、引っ越し作業をしてもらうには、どうするかなども話されることもあるかもしれない。

アジャイルでのケースだと、一括請負で契約し、ある時から「スタンドアップミーティング」を開催しようと担当者に依頼。○ですか×ですか? といった質問になるかもしれない。

あるいは、偽装請負の範疇じゃないけど、、、、。準委任契約でソフトを作ってもらいました。納入後バグが発覚しました。委託先に無償での修正を依頼しました。○ですか×ですか? こちらも、基本的な質問だろう。

最近のつぶやき読みながら、開発担当側も勉強が必要だろうとか、開発現場に応じて契約関係の社内教育も少し味付けを変えたり補足すべきだろうと、ふとそんなことを思った。

3月 11, 2011 ソフトウェア | | コメント (0) | トラックバック (0)

2011年3月 9日 (水)

PDF しおり(Bookmark)エクスポートツール

自炊のPDFファイルや既成のPDFファイルでの、しおり(Bookmark)の吐き出しソフトは、ずっと頭の隅にあった。最近フリーのものも試してみたけど、ファイル名が英文のみとか、挙動がおかしかった。小さなファイルでも発生したので断念。

で、先週目に止まったのが、以下のソフト。「d-LinkMaker」。

http://www.d-sols.com/product1+index.id+9.htm

購入の決め手は、自分の出身と同じ鹿児島の会社だということ(かな)。happy01 お試しダウンロードもできて実験してOKそう。その後、振り込みなどの処理を行い、正式版に置き換え。(注:Acrobat向けのソフト。Readerでは動かない。)

ちなみに、インストールしたらAcrobatのメニューに、エクスポートなどのアイコンが表示される。個人的には、使い勝手はまあまあ。できれば、フォルダー単位でPDFファイルを指定できれば良いんだけど、、、。今はAcrobatの”キャビネット”の機能を利用してはいる。

いや~、見つかって良かった。

3月 9, 2011 ソフトウェア, パソコン・インターネット, 電子ブック | | コメント (0) | トラックバック (0)

2011年3月 3日 (木)

「The Software Project Manager's Bridge to Agility」

少し急ぎ足だったけど読んだ本。

英語の本で、既存のソフトウェア開発プロセスへのアジャイル手法の組込みを意識したもの。既存プロセスとして、PMBOKでのプロセスを前提としている。

非常に気に入ったのは、PMBOKでの各プロセスの番号(章/項:例えば「プロジェクト憲章作成」 4.1)が、そのまま同じ番号での章/項で使用されているところ。各プロセスで、従来の手法とアジャイルでの手法が対比的に表形式で述べられているところである。ちなみにここで記載した手法とは、PMBOKでの”ツールと技法”に近いといえる。

企業内の開発組織は、それなりの成熟度を持っているところが少なくなく、大なり小なり既に社内プロセスが確立している。そのような場合に、一挙にアジャイル手法を導入するには無理があることがある。製品の開発中とか、派生での開発で従来のプロセスを踏襲する前提の場合が、特にそうである。

そのような場合、小グループで実践するとか、一部のアジャイルプラクティスを導入するなどがよい。後者の場合、今回のような本は参考になるだろう。特に、従来の社内プロセスをPMBOK上のプロセスにマッピングしてある組織体とか、マッピングしやすい状況ならなおさらだ。

この本では、複数プロジェクトやPMOに関しても言及している。その部分も大規模プロジェクトなどには参考になるだろう。ちなみに、著者の女性2名はどちらも、PMPで認定スクラムトレーナー(CST)である。

なお、この本でベースとしているのは、PMBOK 3版。細部では4版でないことを気にする人もいるかもしれないが、3版と4版は大きな違いは少なく、各プロセス内やいくつかのプロセスの変更がほとんどである。そのため、実際に適用してみる場合に、各自でのプロセスに応じて検討すればいいのではないだろうか。

自分の回りには、PMP取得者とかそれなりの社内プロセスを持ってる人が少なくないので、勧めたい一冊である。


なお、関連して少し。

CMMIとアジャイル手法に言及した本も出版されている。書店で見かけたのが、左の本。

また、アジャイル系のTwitterつぶやきで見かけたのが、以下のサイト。スクラムでの手法とCMMIとの関連を述べている。


http://www.scrumalliance.org/articles/334-implementing-scrum-agile-and-cmmi-together

上のサイトでは概要しか書いてないが、それでも結構役立つのかもしれない。(ただし、自分の回りにCMMIを今も中心的にやっている人が皆無なので、感想などを聞くチャンスがないが。)


ちなみに、アジャイルでの手法とPMBOKを中心としたソフトウェア開発プロセスとの関連性は、結構以前から検討されている。

自分の持っている書籍の中では、この「実践アジャイル」がその代表。2005年出版。

2005年出版なので、PMBOKは2000年版をベースにしている。また、プロセスの記載順が、PMBOKでの立ち上げでの各プロセス→計画での各プロセス……となっているので、少し違和感がある。

ただし、今回「The Software Project Manager's Bridge to Agility」の紹介を兼ねて、この「実践アジャイル」を読み直したら、参考になる部分が結構あった。当時読み流していたんだろう。その意味では、今でも参考になる箇所が少なくない。

この「実践アジャイル」でも触れているが、「APMBOK(アジャイル PMBOK)」なるものがある。「実践アジャイル」著者のサイトにある。

その後オリジナルは新版発行されたが、日本語翻訳は行われていないように思っていた。しかし、オリジナル新版を探せていない。探したら、ここの部分に追記等を行う予定。


いずれにしろ、個人的にはアジャイル導入での困難さとかの議論には多少辟易している。困難だったことをどう克服したかならまだしも、弊害が多いとの意見に終始している。ここで述べた書籍などで、生産性や品質の向上を意識しつつ、現行プロセスとアジャイル手法の関連性を考えるのは良いことだといえる。


補足:当初、APMBOK(アジャイル PMBOK)が英国プロジェクトマネジメント協会(APM)によるものの日本語訳と記載していたが、どうも勘違い。APMがアジャイルを絡めている事と、ごっちゃになってたようだ。ちなみに、" APM Body of Knowledge"なるものはAPMから発行されている。

3月 3, 2011 ソフトウェア, プロジェクトマネジメント, プロジェクト管理, 書籍・雑誌 | | コメント (0) | トラックバック (0)

2011年2月28日 (月)

PDFの保護、マウスオーバーで判別できる

PDFファイルを扱うことが少なくなくて、いくつか要望なり課題を持ってるけど、PDFの保護(セキュリティ)の判別もその一つ。

ファイルを開いた後で、しおりや注釈を付けられないのが判明するのは、ちょっと作業効率悪い。自炊のファイルやダウンロードファイル、しかもダウンロードファイルに保護付きとそうでないのが混在しているためだ。フリーソフトに保護付きかも表示するらしいのを見かけたけど、インストールで不満だったか機能が不満だったかで使ってなかった。

今日何気に、Windowsのエクスプローラー上でPDFファイルにマウスオーバーしたら、タイトルやページ数以外に「Encrypted:」の項目があるのを発見。"Encrypted:128-bits RC4"などと表示される。PDFファイルを開く前に判明するので、重宝しそうだ。

ちなみに、エクスプローラーでのファイルクリックで、ステータスバーとか詳細部分にファイルのタイトルなどが表示される。ただし、詳細部分には、保護(セキュリティ)状況は表示されない。また、ステータスバーには保護(セキュリティ)が表示されるが、文字コードによってはタイトル部分が非常に長くなってしまい保護(セキュリティ)は隠れてしまうことがある。

なので、マウスオーバーでのこの方法が、今のところ一番良さそう。ほんとは詳細部分に表示されれば言うことない。あるいは、マウスオーバーでの表示が、もう少し速く表示されれば良いんだけど、、、。

2月 28, 2011 ソフトウェア | | コメント (0) | トラックバック (0)

2011年2月 1日 (火)

FireFoxでAdobe Readerが起動しないと思ったら

最近になって、FireFoxでのPDFビューアーをAcrobatにしようとした。ところがノートPCの方でうまく行かない。PDFファイルをダウンロードして、Adobe Readerから直接開くと読める。しかし、FireFoxでのブラウザ上でReaderが起動しない。今まで他のPCでも発生してて、今回を機に対策しようかと思った。

生成機能のあるAcrobatもインストールしてて、バージョン9を利用。そもそもReaderを再インストールしようとダウンロードしたら、最新版のバージョンX(10)に。バージョン不一致のせいかなとか考えて、Readerもバージョン9へ。そっちも面倒だったけど、それでも解決しない。

Adobeに「Web ブラウザで PDF が表示できない場合のトラブルシューティング」というページもあって参照。Reader側の設定も変更(再確認)したり、レジストリも変更したり、、、、。

http://kb2.adobe.com/jp/cps/235/235116.html

それでも駄目だったけど、ふと、PDFビューアーの方を見てみようと。PDFビューアーとかPDFツール類って色々インストールしてて、直近でよく使ってるのは「PDF-XChange Viewer」。”PDF Viewer”と記載や表示している時もあるようだ

Pdfxchange「PDF-XChange Viewer」の方の環境設定を探してみた。メニューでの、編集→環境設定。

すると、”ファイルの関連付けの削除”ボタン。結局そこをクリックしたら、うまくFireFoxでのブラウザ上でReaderが起動した。なんだ~と拍子抜けしたくらい。(もしかしたら、他の設定も関係してたのかもしれないけど、、、。)

「PDF-XChange Viewer」利用前にも本トラブルは発生してたと思ったけど、そもそも勘違いだったのかもしれない。あるいは、もしそうでも、利用してたPDFビューアーの設定変更などでうまく行ったかもしれない。

多少気分晴れ晴れ。

2月 1, 2011 ソフトウェア, パソコン・インターネット | | コメント (0) | トラックバック (0)

2011年1月24日 (月)

IE Tab PlusやJava Consoleの削除

この所2,3ヶ月、Firefoxの動きで少し気になることが頭の隅にあった。起動に時間かかりスクリプト処理に時間かかっているメッセージ表示以外は、何となく気になるといった程度。

ところが今日、何気に自分のネット上のプライベートデータを表示させたら、superfish.comというサイトにアクセスしてる。「あれっ」って思って調べたら、以下のページが見つかった。

「IE Tab Plus 1.95 にはアドウェアが含まれているようです。ご注意を。 - LAZE SOFTWARE」
http://lazesoftware.com/blog/10/1118/

そこははさほど重要なデータじゃないサイトだけど、他のサイトへのアクセスでもそのような処理が行われていそう。動作で”何となく”気になっていたのに、広告系のポップアップが増えた気もする。あんまり気持ちの良いものでもないので、IE Tab Plus 1.95は削除した。

個人的に、IE TabやIE Tab Plusは、重宝してた。ドメインによっては、そのサイト内のほとんどがFirefoxでうまく見られないということも。また、Firefox経由の印刷がうまく行かない/余計なブランクページが入ったりするサイトがある。そんな時に、IE Tabを利用してた。

ただし、IE Tab/IE Tab Plus経由でもうまく表示が出来ないページもあって、少し悩みの種。しかも今回のことを目にして、思い切って削除することにした。


ついでに起動時間の挙動も気になって調べたら、Java Consoleの関係のようだ。

http://suzaku.sblo.jp/article/39817156.html

ということで、上に書いてあるように、古いバージョンを削除した。しかも実際は、新しいバージョンも、Java Quick Starterと一緒に無効化した。


フリー系のツールは結構便利だけど、色々バージョンアップしてくと、遅くなったり気になることが発生するのが難点。しかも昨今は、自動更新というか更新の必要性が表示されてそれに反応すればいいので、便利な反面安易にバージョンアップすることになる。今回のを機に、アドオン更新は少し留意しとこうかな、、、、。

1月 24, 2011 ソフトウェア, パソコン・インターネット | | コメント (0) | トラックバック (0)

探したいのは○○駅周辺のお店で、○○区のお店じゃないんだけど、、、、

抽象的な記載の方が良いかも知れないけど、それだと判りにくそうなので、今日の体験でのお店名で、、、。

知り合いが上京するとのことで、品川駅辺りで待ち合わせ。都内に行くなら、近くに「ナチュラルローソン」があれば行ってみようと検索した。(以前に、別のナチュラルローソンで見かけた商品を再確認してみようとの意図。)

PhotoGoogleで”ナチュラルローソン 品川”で検索したら、左の図のような結果。品川にない。正確には、上の方の記号付きの部分を見て、品川に無いように思えた。

記号付きの部分のちょっと下の方のページにインターシティのお店があったけど、さっぱりしたページで、閉店したのかな~と思ってしまった。それを考えると、チェーンなりフランチャイズでは、閉店した店舗名って1年程度で良いので、掲載できないんだろうか。新しいテナントとの関係もあるだろうから、店舗名と区名とか市町村名辺りまでで良いと思うんだけど。ネット上にはブログを含め古い情報のままのものがあり、それらは更新する義務のないものがほとんど。なので、検索で引っかかってしまう。期間を指定しての検索が出来るのは知ってるけど、それよりも本家のページに閉店情報がある方が正確になる。

ナチュラルローソンの店舗紹介のページでも品川区には、インターシティの店舗が無かった。実は、Googleの検索結果は、”品川区”のナチュラルローソンで、インターシティの辺りは、”港区”。ナチュラルローソンのページでも、”港区”で探せば出てきた。

再確認したら、品川駅自体が港区。気づいたけど、この類は少なくない。自分の身近で知ってたこととしては、目黒駅は品川区だし、マイクロソフトの新宿本社のある小田急サザンタワーは渋谷区。ただし、宴会サイトの類では、(場所としては)駅名で探すことがほとんどで、そちらに慣れてた。

要は、”ナチュラルローソン 品川”の検索を、”ナチュラルローソン 品川区”と考えるか”ナチュラルローソン 品川駅辺り”と考えるかによる。検索、特に地図検索のロジック。個人的には後者かと思う。区内店舗を探すなら”ナチュラルローソン 品川区”と入力するだろうと。

実はGoogleでさらに面白いことに、、、。Google”ナチュラルローソン 品川”で検索→地図 への移動だと、品川区のナチュラルローソンが表示される。 Google地図に入って、そこで”ナチュラルローソン 品川”で検索すると、品川駅(東京) 付近の ナチュラルローソンを表示する。 場所探しだと、Google地図を使った方が良いということなのかも。 あるいは、Google”ナチュラルローソン 品川”で検索→地図 へ移動して、さらにGoogle地図での検索ボタンを押せばいい。


蛇足:知り合いとは、ちょっと時間があったので、銀座でお店へ行こうとの話になった。数年前に頼まれてバッグを購入して送った。こっちは、数年前での記憶を頼りにこの辺りのはずと。そこになくて、うろうろ。携帯(知り合いはiPhone)で住所調べて色々探したけど、なかなか見つからない。GPSで今いる所を探すのに気がつくのが遅かったし、やっぱ年寄りには携帯のマップは小さすぎて分かりにくい。

20分以上歩いて、少し諦めかけてたら発見。閉店1,2分前。優しい店員さんたちで、買い物もできた。店員さんに聞いたら、やはり移転したそうだ。お店探しには、時期にも注意ということか。


たかが検索、されど検索と感じた半日。

1月 24, 2011 ソフトウェア, パソコン・インターネット | | コメント (0) | トラックバック (0)

2011年1月 4日 (火)

ITシステムインソース回帰と環境再生

今日のニュース。日本IBMが、JALとの合弁会社JALインフォテック(JIT)の株式をJALに譲渡。JITはアウトソーシング契約によるもので、言わばJALがインソースに戻す格好になった。

今回の件はJAL自体の再生も関係しているが、アストソーシングで外部化したものをインソース化する動きもある。典型的なものは、2004年の米JPモルガンチェースのアウトソーシングのキャンセル。以下とかでは、当時での日本の動きへの考察も行われている。(他にもあるかもしれないけど。)

http://cloud.watch.impress.co.jp/epw/cda/ohkawara/2004/09/30/3478.html


http://slashdot.jp/~von_yosukeyan/journal/265686?m=1

本来直接関係しないが、最近聞く金融関係のシステム構築では、発注側が結構突っ込んだ要求分析や管理を行っているように思う。大きな理由は、システムトラブルが大きなニュースになったこともあり、それを回避/少なくするため。これも、インソースへの回帰と言えなくもない。


ただ、インソースの方へ流れが変わりメンバーが元の会社に戻ったとして、うまく行くのかと気になった。言葉としては不適切かもしれないが、一度壊れた環境を元に戻す”環境再生”のための手間や時間と似た部分があるように思える。特に心理的な側面や設計・品質をも含めた考え方のギャップ、そしてIT投資縮小の動きとの兼ね合いが大きいだろう。

結局、一律的なアウトソーシングを行ったら問題で、IT化でどこをインソースのままにするかアウトソースにするかの十分な検討が必要だろう。一度アウトソースしたものは、基本的にアウトソースのままで構わないくらいの覚悟が必要。また、必要な部分はIT投資を行い、効率アップなどを進めないと海外を含めた他社と互して行けない。

1月 4, 2011 ソフトウェア, テクノロジー | | コメント (0) | トラックバック (0)

2010年12月31日 (金)

2010年雑記

大晦日なので、今年2010年に読んだ本や気になったことなどを書いてみる。読んだ後とかにブログに書こうと思いながらも、書くタイミングを失ったものが多い。(一部既に書いてることがあったら、ごめんなさい。)

・プリウスリコール

1月とか2月に話題となった、ブレーキの件。あくまでブレーキの件。個人的には、今でも(本来のリコールの定義で)、当初ブレーキの問題がリコール扱いに該当するか疑問という考え。

良い勉強になったのは、まずはマスコミでの扱い。結構細部まで内容を記載するマスコミもあれば、品質問題とか安心・安全に十把一絡げの所も。同じマスコミの会社や媒体でも、記者によって扱い方が違うのも興味深かった。後は、学者先生とか業界人の意見も色々。**さんは、そんな思考だったのかと人物像なりを考え直すこともあった。なお失敗学の畑村さんなどによる講演(パネルディスカッション)は、個人的には良かったとの印象。

トヨタの「グローバル品質特別委員会」設置や、その様子のビデオ公開など、消費者や世論へのアピールの動きは、当初少し驚いた。特に後者は、そこまでやるのかな~との印象。(くどいけど、あくまでプリウスのブレーキの件。) ただし今後のこの類の対応として、大なり小なり他の製造業の会社でも必要になってくるだろう。その意味では、注目しておこうと思う。


・トラブル対応としてのポイントバック

ソフトウェアトラブルおよびその対応で今年気になったのは、ネットゲームなどネット系アプリのトラブルの対応としてのポイントバック。従来慣れ親しんだ(製造業での)商品の場合は、返品とか返金に該当する対応。

ネット系のアプリケーションの場合は、そもそも”品”が存在しないし、無料の場合が多い。ただし、ゲームの場合は、”ポイント”が溜まったり、実貨幣でポイントを購入できるものもある。その場合のソフトウェアトラブルの損害とその代償をどう考えたらよいかと思っていた。

今年、ちょっと目に付いたのは、ポイントバックとか、ネット上の仮想商品の供給。

あくまでケーススタディとしての例示だけど、3月にmixiでのゲームアプリ「サンシャイン牧場」でゲームアイテムの個人掲示板が使えないトラブルが発生した。その個人掲示板は、ある意味有料のアイテム。不具合の修正も行われたが、無料で購入できるとすると共に、既に有料で購入した人には別アイテムがサービスされた。いくつかのキーワードで検索するとたどりついたり、キャッシュを見ることが出来るはず。

システムなりサービスを設計する際には、トラブル時の対応も考えた方が良い。その対応は、そのシステム/サービス内に入れ込むものもある。予備システムなどは典型例。他に、そのシステム/サービス”外”に設けるものもあるだろう。人手での代用も一つ。個人的には、システム設計の際に、トラブル時にシステム/サービス”外”の対応や必要ならその部分の検討を行うべきだと考える。

ちなみに、危険の大きさと効用の大きさを比較することが良く行われるが、あまりに数値的のみの比較での弊害として「フォード・ピント事件」があるので、留意。(危険の大きさとしては、このサイトでは残存バグの可能性が分かりやすい。ただし、「フォード・ピント事件」での危険は、車での構造欠陥。)


・電子書籍

今年は、iPadの購入を機会に、今までのドキュメントファイルの整理や紙情報→スキャンファイル化を結構行った。本のスキャンに関しては、どっか近くのコピーショップで行えればいいな~と探したり問い合わせしたけど、実際は見つからなかった。先々スキャンサービスの利用や、離れたショップの利用なども検討したい。


P6260019P6270023左側2つの写真は、購入した裁断機と裁断結果の様子。こんなものもAmazonで販売してて、Amazon経由で購入した。

実験兼ねて本や雑誌の裁断を行ってみたけど、2つ折りの雑誌が結構難しい。折ってあるところが三角形に近くて、そのまま裁断しようとするとずれていく。広げて、真ん中で裁断しようとしてみたけど、丁度真ん中だと裁断機の刀とホチキス部分がぶつかるので出来ない。少しずらそうとするにも、位置合わせが少し難しい。結局2つ折りの雑誌は、(今のところ)従来のようにカッターナイフで切断してる。

裁断機を利用しての自炊の経験から言うと、コンビニでコピーサービスとかがあるのなら、スキャンデータ渡しもやってくれても良さそうな気がする。まっ、媒体やネット利用可能とするかなど検討が多いのだろうか。ただ、調べた限りでは、カタログとかちょっとしたプリント物はスキャンサービスで利用不可。スキャナーを購入するほどでもない人達にとって有用だろう。

お試し的に、電子書籍をダウンロードしてiPadで読むこともやってみた。しかし、ダウンロード書籍に対する栞(しおり)やマーキングなどの機能でちょうど良いリーダーがなくて、つい遠ざかってしまった。個人的には、集中して読むなら、まだ紙の書籍の方が馴染む。

多少似ているが、日経新聞電子版も会員になっているが、プリントが制限されることで利用頻度はさほどでもない。会社からの帰りに、携帯で夕刊を読んでおく利用が一番多い。

また、 図書館でコピーが可能なのだから、電子データ渡しも検討して欲しいと思うようになった。デジタルデータなのが問題なら、低解像度にするとか認証などを設けても良いのかもしれない。少なくとも、一般的な書籍ではない例えば郷土史とか古文書とかなら課題は少ないと思うのだが。


・ソフトウェア進化

知り合いと、夏に少し話題となった。「ソフトウェア進化」に関する日本語論文もいくつかあるし、大学では「ソフトウェア進化工学」と称して工学的に研究しているところもある。イメージ的には、ソフトウェアプログラムがプログラム自身を自ら変更して機能を作り出すことや、ソフトウェアの外部変化への適応性がテーマになっている(と思っている)。

ただし夏での知り合いとの議論は、生物の進化と類似するのなら、生物進化そのものよりも、品種改良のような(人間社会にとって)能動的なことを検討した方が良いのかな~というもの。進化論学者さんの話よりも、農林水産試験場の研究員や園芸家のような人達の話を聞いてみたい感じ。有益そうなら、そのネタを仕込んで成長させてみるようなアプローチ。ソフトウェア進化よりも、ソフトウェア改良とかの言葉が良さそうに思えるとの意見も。ただし、「ソフトウェア改良」だと単なるデバッグみたいなので、用語的には一工夫いりそう。

あと知り合いとの議論では、DNAでの不要部分との類似性をどう考えた方が良いかも少し話になった。ソフトウェア進化ではそのようなものは、不要とか該当しそうな部分はなさそうと考えるのかな。あるいは、少しくらいバグがあったり、無駄と思える部分を用意してる方がいいかもとの話も。あくまで、DNAや進化論と類似性があるのではとの前提での話で、合意なり結論めいた話にはならなかった。


・社内伝道師(エバンジェリスト)

今年、ちょっと引っかかったのが「○○さんは、エバンジェリスト、、、、」という言い方。もちろん会社によっては職位として”エバンジェリスト”がある会社があるけど、そんな会社の人達とのやり取りじゃない。各自の会社でのスタッフ部門の人なり専門家の人の説明でのこと。

引っかかるのは、自分の周りでは尊敬の意味でが9割くらいだけど、残りが融通が利かないような意味で使われてる点。後者は一方的な説明だったり、別の考えとの妥協点を探ろうと相談してるのにその専門分野での考えを譲ろうとしない。また、各分野の説明をする時は良いんだけど、(分野間で多少矛盾する時に)その人なりの考えの統一性に欠けることもあるとも。それらにより、ある意味、弊害になることもあるらしい。

そんなことを気にして、伝道師(エバンジェリスト)と呼ぶより、 お坊さんとか小坊主、納所坊主(なっしょぼうず)など呼んだらいいのにと思った。伝道師が一神教系での用語で、他の考えを受け入れないイメージもあるためだ。日本でクリスマスや初詣を行うように、多神教系の言葉の方が良さそうに思えた。ただし、納所坊主って寺の会計とかを取り扱うお坊さんと知って、ちょっと適さないな~と。お地蔵さんも良いんだけど、じっとしているイメージが強い。

ただし、そもそも伝道師って、正教師の資格を持たない人のことと知った。正教師は、牧師さんのこと。また、伝道師って、物事のよさを伝える人の意味もあるようだ。(本来卓越した人を会社でも”牧師”と呼んでも良さそうだけど、用語的に宗教っぽ過ぎるので使ってないのだろうと推察する。)

伝道師(エバンジェリスト)と呼ぶべき専門家なら、現場への普及で余りに強制的に/固定的な考えを押しつけるのは似つかわしくないと思うようになった。


・i○○○は日本で作れるか

今年の受講した講演でスポット的に触れられたり、懇親会で会話になったもの。iPodだったり、iPadだったりしたと思う。日本の競争力低下の原因探りみたいな面もあったのだろう。とある懇親会で、その話題になったので、以下のことを述べた。
 

①日本だって作れる。作れないのはAppStoreなどの方。
ハードは、日本でも作れるだろう。細かいこととしては、アップルと同様に中国などでの製造で、日本での製造じゃ製造価格が割に合わない。また、じゃA4のチップを設計できるかとかがある。しかし、いずれにしろ、日本メーカーは、AppStoreとか緩い著作権管理は、心理的に発想しにくい。さらに言えば、ハードウェアチームとソフトウェア(特にシステム/ITを含めた)チームが、日本企業では協力体制になることが考えにくい。

②作れても商品化に行き着かない。
特に品質部隊や関連部隊とか事業部長とかが、出荷OKと言いそうにない。自分でもiPad買ったときに驚いたけど、電源ボタンが無い、音のボリュームも無い。社内でのレビューで、こんな設計なら色々文句が出るだろう。他には、PCとの接続とかネットワーク接続が前提。PC持ってない人やネットワーク接続できてない人を考慮しないのか!と怒られそう。さらには、同梱の説明書が薄いというか紙切れ。これだってマニュアル部隊から総スカンになりそう。


・「ガラパゴス化する日本の製造業」

2008年発売で、長く積ん読状態だったもの。講演等で日本の特異性を”ガラパゴス”と呼ぶことが増えつつあった頃の出版だったと思うので、タイトルに”ガラパゴス”を題した本としては早いほうだったはず。(ただし当時、”ガラパゴス”の話とAndroidの話とを一緒に聞く機会が多くAndroid採用勧誘のような受け取り方をしたせいか、この本を含め”ガラパゴス”関連本をほとんど読まなかった。)

今年日本でも各社からスマートフォンが商品化された。そこでふと、”ガラパゴス”騒動ってなんだったんだろうかと思い、この本を読むことにした。

当初予想では、日本の特に携帯などの特異性が多く述べてあると思っていた。でも実際は、韓国や台湾の企業に関する事項が結構詳しく述べられている。また、ある意味では必然だが、エレクトロニクス業界を扱っている。第7章「世界で勝ち抜くためのビジネスモデル」では、7つの条件を挙げており参考になるが、エレクトロニクス業界に関してのもの。8章は自動車業界に触れており自動車業界の課題も書かれているが、エレクトロニクス業界との関連が主になっている。

世界で勝ち抜くための7つの条件の冒頭が、”すり合わせ”の技術が活かせる分野としている。実は以前から、”すり合わせ”と”組み合せ”の技術論での2つの違いで悩むことが少なくなかった。この本で、”すり合わせ”技術の業界として自動車や工作機械とのイメージが強まった。自分の中で、”すり合わせ”技術=自動車・機会(業界)、”組み合せ”技術=電気(業界)と捉えてすっきりした。その基本的な気づきができただけでも、結構価値があった。

なお著者は野村證券の主任研究員であり、海外の企業情報が詳しいのも頷けた。ODM売り上げランキングや、実効税率の台湾・韓国メーカーと日本メーカの比較なども記載されている。台湾や韓国を含めたエレクトロニクス業界を考える上で、参考になることが多かった。


・「『失われた十年』は乗り越えられたか」

発売は2006年と、ちょっと前。「ガラパゴス化する日本の製造業」を読むうちに、こちらも面白そうと読んだ本。

”「失われた十年」を乗り切った自動車産業”と”自ら不況を招いた家電・電子産業”とを、章立てレベルで明言している。そこが結構、小気味良い。

海外に進出した中小企業も登場したり、タイやマレーシアの動向などにも書かれている。また、この本でも、”すり合わせ”の技術に触れており、その分野でアメリカ製造業は地位低下したと述べている。

この本では、アングロアメリカン型の考えに批判的な部分も少なくない。株主価値を前提としたコーポレートガバナンスなどである。そんな部分も参考になった。

12月 31, 2010 ソフトウェア, ソフトウェアテスト, プロジェクトマネジメント, プロジェクト管理, 日記・コラム・つぶやき, 書籍・雑誌, 電子ブック | | コメント (0) | トラックバック (0)

2010年12月22日 (水)

スクラムチームのシーズンオフ

冬なので、スポーツでのラグビーの話題や写真をポツポツと目にするようになった。 (ちなみに、社会人ラグビー大会の昨シーズンの決勝「トヨタ自動車 Vs. 三洋電機」戦は、2010年2月28日。)

ソフトウェア開発のプロセス「スクラム」の勉強とか講習のせいか、ラグビーの写真を見るとそちらの方へも頭が行く。で、ちょっと思ったのが、タイトルのように”シーズンオフ”。とにかく「スクラム」では、スピードが命。バグなどの課題が発生したら”即”処理する必要がある。(スクラム講習では、「Now!」とか「Done! Done!」という言葉が飛び交う。) チーム自ら作業量などを見積もりを実施しコミットするから、なおさら自発的な処理が必要。

なのでイメージ的には、そのプロジェクトが完了するまで、結構がんばり続けるイメージ。そうなると、完了後にどうした方が良いかが気になる。すぐに次のプロジェクトに回すのは、試合ばかりのラグビーチームみたいに思えてきた。息抜きなり、勉強に充てる時間も必要だろう。(日々仕事をしながら勉強しろばかりじゃ大変すぎ。)

ということで、ラグビーチームメンバーのオフシーズンの過ごし方をネット検索。すぐに引っかかるのは、夏合宿。菅平などを思い出す。後は自主トレ。

ラグビーチームのチームと「スクラム」のチームがちょっと違うのは、「スクラム」でのその次のチーム編成が同じとは限らないと言うことかも知れない。そのことはチーム編成の際に、そのことへの配慮とか、チーム形成のための時間も確保してやるべきだろう。上位のプログラムマネージャーなり経営層が配慮してあげるべきと思うんだけど、いかが、、、、。

12月 22, 2010 ソフトウェア, プロジェクト管理 | | コメント (0) | トラックバック (0)

2010年12月13日 (月)

フォーラム:NRIのシステム障害削減

今日は、PMI日本支部のフォーラムに参加。テーマ名は「システム障害の削減に向けた弊社の取り組み」、講師はNRI(野村総合研究所)の栗原氏。PMI日本フォーラムでの案内は以下で、”八割減”が印象的。

http://www.pmi-japan.org/event/open_seminar/monthly/2010_11_16_201012.php

ちなみに、参加して頂いたのが、「野村総合研究所のやる気を引き出すチーム改革 (アスキー新書) 」。セミナーでの内容が結構書かれている。セミナーで触れられた”エンハンスの卵”の図は、裏表紙やP49。

システム障害事例の情報共有とか草の根的な改善活動が述べられたが、ある意味大なり小なり行われていること。ただし実践していることに意義があるし、講演や本での細部で参考となるプラクティスが少なくない。特に、パートナー企業まで巻き込んだ活動には頭が下がる。そう簡単に構築できないだろうと思って、懇親会では質問させて貰った。

講演でも述べられたが、オフショアでのパートナー企業とは、品質改善以外に(証券とかの金融系)業務知識の教育なども行ったそうだ。根気の必要な活動。 (もしかしたら、海外で金融系の業務試験が行われていたが、それも関係するのかもしれない。)


野村総合研究所は、旧野村総合研究所と野村コンピュータシステム株式会社(NCC)が1988年に合併している。その辺りは知っていたが、今は売り上げ比率がITの方が高いし社長もIT系だと、その場で知った。その辺りも、品質改善活動を全社的にしたりパートナー企業を巻き込める原動力になったようだ。ちなみに数年前に情報系の大学の人と懇親会の場で人気のある企業はどこかと聞いたら、NTTデータとNRIの名前が出て印象的だった。

NCCの頃は、コンピュータシステムや業務ソフトの運用保守が主体のイメージが強かった。そのために、業務の把握やパートナー企業との息の長い連携が求められていたのだろう。それがかえって、今回の改善活動に結びつけやすかったのかもしれない。また、トラブル削減の次あるいは並行して、運用保守の改善や効率化にも取り組んでいるとのことだった。


ついでに:講演会で多少時間があったこともあり、Q&Aに時間が割かれた。印象的だったのは中国の人とのことだったが、その人らの質問。懇親会の場にも一人(?)いて、講演内容やPMI日本支部活動などを質問してた。聞いたら、NRIはオフショア開発がうまく行ってる企業とのイメージとのことで講演に参加したと。彼らの積極的/前向きな様子を見ると、頭が下がるくらい。

ついでにその2:結構昔に、旧野村総合研究所に出向いたことがあった(と思う)。暑い中に長い坂を登った記憶が、おぼろげながら。今回のを機にちょっと調べたら、旧野村総合研究所は鎌倉の坂の上にあったようで、記憶は正しそう。調べる際に写真などがネットにあり、少し懐かしい気になった。

12月 13, 2010 ソフトウェア, 品質 | | コメント (0) | トラックバック (0)

2010年12月 8日 (水)

「認定スクラムマスター研修」受講

昨日と今日は、秋葉原にて「認定スクラムマスター研修」を受講。 認定スクラムマスター:Certified ScrumMaster(CSM)。

http://scrumtraininginstitute.com/classes/show/280

日本語だと、以下が分かりやすいかな。

http://www.ryuzee.com/contents/blog/3465

James O. Coplien氏によるもの。同時通訳じゃなかったけど、日本語スタッフはいるというし教材も日本語/英語表記が用意されるということで、受講することにした。

それなりのコースなので詳細は記載しないけど、座学もだしゲーム性の高い演習も面白くてためになった。演習は「スクラム」でのキーとなる手法を知った上での、言わば応用。あるいは、チームとかの基本部分を考えさせられるネタが多かった。(例えば、女性のいるチームの方がアイデアが出て、結果的に高得点。講師は、他の研修でも同様で、”ダイバーシティ”という言葉を投げかけていた。)

スクラムポーカー/プランニングポーカーによるゲームも行われた。チームメンバーとのやり取りでは、(輸入)商品でなくて、手作りで実践している話とかも聞いてなるほどと頷いた。他の演習や雑談を含めて、チームメンバーとの日本語でのやり取りとか、外国人のメンバーとの片言英語でのやり取りなども参考になった。

なお、2日目は懇親会にも出席した。講師のCoplien氏の日本に対する興味の背景も聞かせて貰った。”合気道”。他に日本での旅行のことなども。研修でもリーンやカイゼンなどが何度も”叫ばれ”、日本には良いものがあるでしょうと言いたげだった。スクラムの発端が野中先生等の論文であることは理解してても、外国の講師が我々とのやり取りで日本のことを述べており、改めて彼らにとっての日本の位置づけを感じた。そんな点も、良い勉強になった。


ちなみに、以下でスクラムそのものとか、海外を含めたコースの様子が見られる。デンマーク語じゃなくて、一応英語。ただし、(私の場合)セキュリティ例外とかが発生するので、興味ある人だけどうぞ。

http://scrum.dk/

また、以下では認定スクラムマスターの一覧を見ることが出来る。(正確にはスクラムマスターコミュニティメンバー一覧であり、認定スクラムマスターなのか等は各人のプロフィールでの右下に表示される。あるいは、トップページでの検索により引っかけることも可能。)

http://www.scrumalliance.org/profiles

認定スクラムマスターのコミュニティでは色んな催しもあるようなので、今後さらに深めようと思っている。

12月 8, 2010 ソフトウェア | | コメント (0) | トラックバック (0)

2010年11月17日 (水)

富士通見学-続編 「コンピュータサロン」とか社内図書館とか

「富士通テクノロジーホール」見学の後の、懇親会(?)に向かう際に目についたのが図書館。念のために確認したら、富士通社内の図書館で、外部者の利用は不可とのこと。(ちなみに、中原以外に2つあるようだ。)

外部者の利用不可は普通は当然なんだけど、敢えて質問したのは、タイトルに書いた「コンピュータサロン」のことが頭にあったため。ただし説明の人は情報系でもないようだったし、「コンピュータサロン」って知ってる人がさほど多くないようなので突っ込んでは聞かなかった。

「コンピュータサロン」って、五反田にあった小さな(?)情報系の図書館。ちなみに、そのころの話題が、以下でまだ残ってた。

富士通「コンピュータサロン」もうじき閉鎖
http://slashdot.jp/article.pl?sid=03/09/10/1339243

で、そこには、1997年に移転したと。大井町とのことだけど、今も実際運営してるかは?? 機会あれば、行ってみるかな。 (穂井田さんは多分いらっしゃらないだろうけど。 また、個人的には蒲田に引っ越すと聞いたような気がしていて、行き先が大井町だったとは知らなかった。)

http://pr.fujitsu.com/jp/news/1997/May/30.html


なお、”図書館”が社内にあるのか無いのかって気にしてて、時々聞くことがある。企業見学会などで、図書館の中を通ったり、通路に図書館があったりもする。逆に、企業経営の合理化などで、縮小されたり廃止されたりも。

見学などで部署内を通るときに、(雑誌棚とか新聞棚じゃなくて)書籍の棚があると、ちょっと嬉しくなる。ちょっと大げさな言い方だけど、その会社とかその説明の人を一目置くようになる。 ネット系の言語の結構よれよれの書籍を目にすることもあって、妙に感心したりすることも。

最近、全日空だったと思うけど、起業を扱ったドラマで2,3人の社員が自費で買った英語の本で操縦かメンテナンスを勉強しているシーンがあった。そこに社長が来て「すまん。ほんとは会社で買ってあげるべきなんだろうけど、、、。」 そんな台詞があった。

自分の勉強もあり自費で購入するものもあるだろうけど、組織体で知っておくべきものへの投資って必要だと考える。しかも、個人的な身近な例で言えば、ITILとかISO/IEC 25000とか冊数も多くなったし、お金も馬鹿にならない。なので、購入断念(ITILはポケット版だけにした)。 PMI関連で言えば、自分はPMBOK以外も自分で買ってるけど、プログラムやポートフォリオなどまで揃えようとするとそれなりの値段。

ソフトウェア関連でも、ISOのような規格系やBOKの類など、知っておくべき事がどんどん増えてる。管理職の類は、叱咤激励で単語を並べれば済むだろうけど、それなりに系統立って、しかも深掘りするためにはコストがかかる。研修への参加などもあるだろうけど、共有資産という意味での規格書やBOKを含む書籍も重要。自部門に、あるいは会社として必要なものは何かとか、そのための手当を考える必要があるだろう。

11月 17, 2010 ソフトウェア, 書籍・雑誌, 科学技術 | | コメント (0) | トラックバック (0)

リレー計算機見学

今日は見学会。富士通の中原工場。 (ほんとは会合もあったんだけど、、、、。)  ちなみに、見学したのは「富士通テクノロジーホール」で、一般公開じゃないので、注意のこと。

http://jp.fujitsu.com/facilities/kawasaki/exhibition/


Pb170451Pb170449Pb170450情報系の出身なので、どうしても、展示品の中でリレー計算機「FACOM128B」は気にしてた。昭和30年代中頃の機械が実際に動作するとのことで、楽しみだった。 説明の人が二乗とかルートを計算するというのを、(機械の方に目が行き)上の空で聞いてたら結構な音がしだした。リレーの音とプリンターの音。

実は、その音を聞きながら、どんな処理を行っているか頭を巡らそうとしたけど、冒頭で少しパニック。と言うのも、計算とプリントってパラに処理している気がしたため。リレーの音とプリントの音が、並行に鳴っている感じ。勘違い? 

また、リレーの”カチャ”の音で、テイラー展開とかの○段を計算、次の”カチャ”で次の段かとか考えたりした。ただし、それだと少し回数が少ないような気もした。なんか計算の工夫をしているのかも。ちなみに、真ん中の写真で判るけど、ルート2の末尾を4捨5入している。固定小数だと、処理が楽なんだろうなとかも思った。

また、左の写真は、本計算機のメンテナンスの掲示。月に2回ほど沼津から技術者が来るようなことを言ってたが、聞き違いならごめんなさい。また、メンテナンスでのネックは”紙”みたいだ。左の写真での真ん中とかで紙を筒状にしたものがある。紙テープを幅広にした感じのもの。その紙が、手に入りにくくなっているようだ。 それにしても、良い話だし、メンテナンスして動作させる活動は続けて欲しい。 

Pb170452Pb170454この2つの写真は、故”池田敏雄”のコーナーのもの。右の写真のは、ノートの記載のようなんだけど、ほとんどが解読不能というか何を書こうとしてるのか判らない。撮影の時に後で分かるかもと思って撮影したけど、不明。 詳しそうな人に聞いてみようかな。ちなみに、ふと”池田敏雄”さんのことを再調査したら、ウィキペディアなどでも結構ユニークな行動が書かれてた。 

リレー計算機といい、今日はちょっと昔を懐かしむことができた一時だった。

11月 17, 2010 ソフトウェア, テクノロジー | | コメント (0) | トラックバック (0)

2010年11月14日 (日)

テスト報告書を書ける人、そうでない人

週末に知り合いと話した件を、ふと思い出した。「ソフトウェアテスト報告書の作成能力って、レベル差ありすぎ~」

そもそも、”ソフトウェアテスト報告書”って、書く事が少ないかもしれない。まっ、判定書(やそのための資料)などに含まれてるケースを含むけど、テストしてバグレポート発行しても、報告書の類の話は余り聞かない。そのせいか、書ける人自体が少ないのかも。また、テストの依頼したり請け負ってもらっても、報告書を提出させたり、その吟味をできる人が、また少ないのかもしれない。

テスト戦略とかテスト計画は、規格があったり広く議論されてるので、力説する人はいる。でも、そんな力説する人たちって、報告書をどう考えているのか聞いてみるのも良いかもしれない。世の中には”認定機関”なるものがある。それと比較しちゃいけないのかもしれないけど、ソフトウェアのテスト結果レポーティングって、ちょっと気になった。

11月 14, 2010 ソフトウェア, 品質 | | コメント (0) | トラックバック (0)

2010年11月 4日 (木)

メールのスレッド切り離し整備 断念

メール受信して頭に来るのが、「返信」で全く新しい話題を書く輩。メール上、Aの話題(Re:Aとか)でのスレッドになってるのに、急に全然関係ないBの話題のメールを出すといった感じ。本来なら”新規作成”でメールを作成すべきなのに、”返信”とかやってタイトルや内容を記載する。大抵、メールアドレスの入力が嫌だから。自分の参加しているコミュニティの中での2,3の各コミュに、1,2名いる。

Aの話題からちょっとずれて話題が別になるのは元ネタのイメージがあるから良いんだけど、上のようなケースだと急に話が変わるので後でメールを探しにくい。スレッド表示を利用しているケース。

使っているのがThunderbirdなので、どうにかできないかと調べてみた。(Beckyには、操作でスレッドを張り直す機能があるみたい。)

メールヘッダーを書き換える以外に無いかと色々考えてたけど駄目で、ついメールヘッダー書き換えソフトを試してみた。in-reply-toやreferenceなんかを消せば済むと思ったため。

ところがどっこい。どうもX-Mozillaなんたらで、メールの世代数や親子関係状況を覚えているみたい。しかも、referenceって直接の元ネタだけじゃなくて、さらにその元ネタとか何世代も遡って親子関係を覚えてる。(ただし、何によるのか不明だけど、世代数は環境とかに依存するみたい。結構2,3世代前までが多いけど、7世代くらいまで覚えてるのもちらっと見かけた。)

メールヘッダーを強制的に変更して、上の例でのBの話題メールの元ネタとの関係を切っても、そのBへの返信がAでの続きの元ネタ(つまり2世代前)を覚えていて、BはAのスレッドだと判断してるようだ。なので、手動でヘッダー書き換えは面倒というか、実質不可能と考えた。

まっ自分の周りで、返信で新規話題メールを出す人で高頻度は1,2名。頻度が多いと言っても、2月に1回くらい。なので、ちょっと我慢するなり、まっそんな人だと思うことにした。 ただし回数は少ないけど、その親スレッドが重要だったり新しい話題が盛り上がる(逆にスレッド表示で隠れてしまう)こともあるので、その時は一旦自分宛にフォワードして判るように保存するとか工夫するつもり。

11月 4, 2010 ソフトウェア, パソコン・インターネット | | コメント (0) | トラックバック (0)

IPA クラウド構築OSS→バグトラッキングサイト

今日は、ちょっとしたカルチャーショック。IPAによる社内クラウド構築のためのOSS(オープンソースソフトウェア)の資料を読んで、そこでの内容やそこでのOSSの各バグトラッキングシステムをちらっと覗いたため。

IPAによる、社内クラウド構築のためのOSSの発表は以下。

http://www.ipa.go.jp/about/press/20101027.html

そこから「社内向けクラウド構築のために活用できるソフトウェアカタログ」の”レポート”をダウンロード。そのレポートが結構整理されてると思って、感心した。残バグ件数などが書いてある。クリティカルバグ数とかフィックスまでの期間が記載されている。ちなみに、各バグトラッキングシステムでのバグレベルには色々あるので、○○をクリティカルと捉えたなどと断っている。

さらに、そこに書かれている各OSSのバグトラッキングシステムにアクセスしてみた。(実際のアクセスは2つくらい。) 今まで、Mozillaのバグ追跡システム「Bugzilla」とかもちらっと見ているし、最近はネット系のアプリだと掲示板を用意してそこでバグ報告などを行うケースも知っている。ただ、こうも多くのソフトのバグトラッキングシステムのサイトが掲載されていると、驚いてしまう。

良い表現が思いつかないが、ちょっとマラソンチャレンジしようと思ってそれらしい靴とかウェアを用意して競技場に行ってみたら、すさまじいスピードで走り続けるマラソン選手たちを見てしまったといった感じ?? 社内クラウド構築に非常に参考になると思いながらも、向こうのソフトウェアにおける”おおっぴら”の凄まじさを感じた。凄まじいというか、それがオープンソースソフトウェアなんだと改めて感じた次第。

なお、各バグトラッキングシステムを細部まで見てないが、バグトラッキングシステムのインフラも色々。バグトラッキングシステムのインフラとしても参考になるかもしれない。また、バグカーブなども表示できるサイトがあるのかもしれないが、まだそこまで調べ切れていない。

11月 4, 2010 ソフトウェア, パソコン・インターネット | | コメント (0) | トラックバック (0)

2010年10月27日 (水)

Googleノートブックのラベル削除

昨日・今日で困ったのが、表題のようにGoogleノートブックのラベルを削除できなくなった件。数日前は、OKだったと思う。

「Googleノートブックのラベルの削除が突然できなくなりました」で検索すると、ヘルプに行くけど削除されてる。それが、ちょっと気になった。

投稿者自身が削除したとか、Gmail関連じゃないので削除されたのかもしれない。ただ、Googleノートブック自体は開発中止とのことで、薄氷の思いで使っているファンからすると気がかり。

なお、私の場合の現象としては、むしろGoogleブックマークとの関連で作業してたので、ノートブックのラベルというよりもブックマークでのラベル削除がおかしいのかもしれない。ラベルを削除すると、一旦削除されたように表示されるが、再読み込み等を行うと復活する。ブックマーク等を削除してゼロ件にしても残ったままなので、なおさら釈然としない。

あと、Googleブックマークとの関連で言うと、GMarksは1000件超えに対応したようだ。ネットに書かれてるjsでの片方を修正したものをインストールするみたい。(もう片方がそのままでも良いのか?で、実験しようとした矢先にラベル削除の本問題に遭遇。)


ついでに。Gmarksでの1000件超えは、まだちょっと不安だったし、本削除の関係で別ツールを検討した。Xmarksって、以前はメモ的な内容も同期するみたいで嫌だったし、Googleブックマークと同期するのかな~とか思ってた。ただ、今回の問題で、どうするか再調査。そしたら、サービス停止予定で、今年いっぱいとか。

http://journal.mycom.co.jp/news/2010/09/29/046/index.html

結局、振り出しに戻ってしまった。 

いろんな情報を、格好良く言えばクラウド上に置いてるけど、サービスを急に止めるしバグみたいなのは少なくなくて、不安感が増してる今日この頃だ。

10月 27, 2010 ソフトウェア, パソコン・インターネット, 日記・コラム・つぶやき | | コメント (1) | トラックバック (0)

2010年10月22日 (金)

制御プログラムの不具合でのリコール

ちょっと目についたので紹介。制御プログラムが良くなかったとのことで、自動車のリコール。スピードメータの不具合。

http://www.mlit.go.jp/common/000126290.pdf

メータの値や動作自体ではなく、メータの照明がうまく動かないというもの。個人的に、車のリコールで”制御プログラム”と明記したのは珍しいというか初めて目にしたかも。また、改修したら、リコール番号が判るステッカーを付けるらしい。(今まで目にしたのかもしれないけど、記憶になかった。)

10月 22, 2010 ソフトウェア, 品質, 自動車 | | コメント (0) | トラックバック (0)

2010年10月14日 (木)

Scrum Guide 日本語版 (2010)

今日何気にScrum Guide日本語版を見てみようと、ブックマークしてたURLをクリック。すると、見つかりませんエラー。検索で”Scrum Guide日本語版”とやっても、結果の上の方に、旧URL以外でそれらしいURLが出てこない。おかしいな~とか、何か起きたのかな~とか思ったけど、ちょっと危惧だったみたい。結論からすると、2010年版が出ており、従来の2009年版は全部削除された様子。2010年版は以下。

http://www.scrum.org/scrumguides/

既に日本語版もある。前もあったか覚えてないけど、英語は音声ファイルもある。

ちなみに差異は、冒頭で翻訳者が明記されているとか、所々2,3行にわたる変更もあるようだ。ただし、基本的には大きな違いは無いように思った。

10月 14, 2010 ソフトウェア | | コメント (0) | トラックバック (0)

2010年10月13日 (水)

ソフトウェアのADR(裁判外紛争解決手続) 寸劇

ここでのADRは、米国預託証券じゃなくて、裁判外紛争解決手続(Alternative Dispute Resolution)の方。

ふとソフトウェアでのADRのことを久しぶりに検索してたら、経産省のページにADRを劇仕立てにしたものを発見。

http://www.meti.go.jp/policy/it_policy/softseibi/#08

wmvファイル6つに別れてて、冒頭を見て思わず全部見ちゃった。6つで1つの物語だけど、冒頭は少しフランクにADRに関して説明する格好のもの。(そこでの弁護士さんが気さくなタイプで、個人的に嫌いな方じゃない。)

劇での紛争は、第1フェーズは上手くカットオーバーできたのに、追加的な第2フェーズのパフォーマンスが期待に添わなくて金を払わない/払ってくれというもの。第2フェーズでは、外のパッケージ利用もちょっと絡んでる。

ちなみに、以下でシナリオの方見られるけど、まずは冒頭のを見てみるのをお勧め。

http://www.softic.or.jp/seminar/2007-ADR/

個人的には、この寸劇では、ちょっとベンダー側に甘いかな~という印象。

蛇足だけど、結構劇としてもこなれているし、音もそれなりに高品質。それに似合う分、活用されてるのかな~とふと。もちろん、(少し前の日本の感覚だと)ADRを含め紛争や裁判を避けたいという感情があるだろうけど。また、2007年には情報があったようなので、何で前に気がつかなかったかは??

10月 13, 2010 ソフトウェア, 品質 | | コメント (0) | トラックバック (0)

2010年10月12日 (火)

フロー、フローチャートに、start/endを

フローを元に、やり取りしていたら、どうも勘違いが判明。こちらは、状態としてAもしくはBと思ってたら、相手は状態無し(Null状態)もあるし、AかつBもあると。勘違いの発生は、早い話、フローにちゃんとend(終了)が書かれてなかったから。条件分岐の後が、終了なのかはっきりしていなかった次第。

考えたら、フローチャートで、start(開始)/end(終了)を書いてないケースが少なくない。プログラミングじゃないとのことで、業務フローとして表記ルールが曖昧なケースが横行すらしている。ちなみに、業務フローにもいくつか表記例があり、以下のNOMA方式だと、▽が終了。

http://www.internalcontrol-navi.com/impruve/flow_chart/mark.html

これが、業務プロセス開発なら、大問題。AもしくはBと、AかつBがあるのは、GUIから内部のデータ構造からが大きく違う。フローやフローチャートに、end(終了)とかがあるかをチェックするだけでもメリットが大きいかなと思った次第。

開発時は、さすがにチェックするとは思うけど、、、。また、昨今はフローやフローチャートは流行らないかもしれない。しかし、それと同等のロジック面を確認する図示種などは明確にすべきだろう。

10月 12, 2010 ソフトウェア, プロジェクトマネジメント | | コメント (0) | トラックバック (0)

2010年10月 4日 (月)

Twitterの新バージョン 徐々に展開

Twitterが、新バージョン(新画面)のリリースを行っている。

http://support.twitter.com/groups/31-twitter-basics/topics/146-new-twitter/articles/260943-x65b0-x3057-x3044-twitter-x306e-x30c7-x30b6-x30a4-x30f3-x306b-x3064-x3044-x3066-newtwitterjp

上に書いてあるように、一斉に新バージョンになる訳じゃない。人によって、順次新バージョンを利用できる。しかも、新しいバージョンを使っても旧バージョンが良ければ、旧バージョンのままにもできる。私も旧バージョンに戻した方。(若干、戻し方が分かりにくい。)

一斉のバージョンアップを避けたのは、あくまで類推だけど、ユーザの反応を見たかったと事と負荷の関係じゃないかと思われる。後は、バグ対応をスムーズにするのも理由かもしれない。(現に、送信時が「〜月月〜日」と表示されてしまう不具合があり、対策しようとしているようだ。)

負荷の件は細部まで知らないけど、データ(データベース)の移行などもあるのかもしれない。


で、上はユーザ側の立場での感想等だけど、システム構築の場合も結構行われるし、神経使う部分でもある。GUIのバージョンアップでも、新バージョンと旧バージョンを混在させて運用する。問題無ければ、全端末を新バージョンへ移行するなどが行われる。新バージョンのためにデータ形式を変更するのなら、事前にクレンジング。また必要なら、それに関する実験室レベルをテストを行っておく、、、、。

もしかしたら、ネット系サービスで、今回のTwitterのような”徐々展開”って増えていくのかもしれない。

10月 4, 2010 ソフトウェア, パソコン・インターネット | | コメント (1) | トラックバック (0)

来週11日はコンピュータ将棋対局

いよいよ来週11日は、清水女流王将と”あから2010”の将棋対局。情報処理学会とかで中継関連が掲載されてる。

http://www.ipsj.or.jp/50anv/shogi/press2.html

日本将棋連盟のページから、アクセスできるとのこと。ただし、コンピュータ将棋の専用のページではないし、特に11日向けのリンクもないようだ。当日、棋譜が掲示されるんだろう。棋譜のみでも将棋専門の人には判るのだろうけど、将棋に素人のメンバー向けのサイトはないのか??

なお情報処理学会のページで知ったけど、”あから2010”は、4つのプログラムでの結果を(人間が)多数決で判断するみたい。雑誌「情報処理」とかでも、もしかしたら記載されていたのかもしれない。

最初の方での手が、4プログラムでの結果が似たものになるのか、ちょっと気になる。

10月 4, 2010 ソフトウェア | | コメント (0) | トラックバック (0)

2010年10月 1日 (金)

保守(契約)とインシデント

今日は気になって、ソフトウェアの保守とインシデントを調査。インシデントって、障害とかの連絡もだけど、ちょっとした問い合わせなども含む事が多いかな。

で、以下はSalesforce関連の会計ソフトサービスのページで、下の方の料金の部分に”3インシデント含む”との記述がある。あくまでも例で、”保守 インシデント”とかで検索すると、結構出てくる。

http://www.sunbridge-sol.com/service/cloud/salesforce_relation/project/

以下の「アドビ デスクトップ製品向けサポートプログラム サポート規約」とかでも、インシデントのことが書かれている。

http://www.adobe.com/jp/support/programs/policies/terms_customer.html

”IT LEADER”2010年1月号での、ソフトウェア保守サポートの特集を読んだ時もちょっと調べたつもりだったけど、その時よりもインシデントのことを結構明記しているサイトが増えた気がする。勘違いなら、ご容赦。ちなみに、”IT LEADER”2010年1月号は、今は以下でも読める。

http://it.impressbm.co.jp/taxonomy/term/1189

会社やサービスによって料金が違ったり、件数カウントの方法を細部にわたって記載してあるサイトが増えたように思う。保守要員のコストなどを考えると、保守料金、そしてインシデント1件の料金の検討が必要な時代ということ。SLAも、お金が絡んでいる。

メカ系の製品の場合、MTBFなどを算出してサービスパーツの料金とかを計算するけど、ソフトウェアサービスもそのような考えが必要になってきている。また、逆に発注側としては、余りに信頼性の低いソフトやサービスのカットオーバーでの”受け入れ検査”のあり方や、その結果をどう扱うかなども吟味する必要がある。

10月 1, 2010 ソフトウェア, 品質 | | コメント (0) | トラックバック (0)

2010年9月29日 (水)

アップルの使用許諾サイト

この前、「OSSの法務分野に関する基礎知識」を書いて、今日「そういえば、iPadでのOSS関連ってどんな風に書いてたっけ?」と、気になった。

そもそも、iPadでの使用許諾(書)をちゃんと思い出せない。(ご存じのように、iPod/iPadでの付随する説明書は小さな紙切れに近い。) 

http://www2k.biglobe.ne.jp/~t_muto/ipod/howto_addnewipad.htm

上で画面のスナップショットがあるけど、iTuneと接続しての設定時に、同意するかの確認画面が出る。正確には、出たんだとちょっと思い出したような気がした。

で、その使用許諾は多分以下のページ。か、その中でのiPadソフトウェアの部分へのリンク。

http://www.apple.com/legal/sla/

上のページで少し驚いたのは、iPad~iPhoneあるいは他のソフトウェアなどが一覧化されていること。○兆円を売り上げるような会社で、この類のページが用意/整理されてるのは他にあるんだろうか?

”iPad Software License”をクリックするとPDFが開く。92ページもあって、一瞬「アップルにしてはボリュームあるな~」と思うけど、全言語を含めてのドキュメント。日本語だけだと、7ページ。

日本語での3ページ目辺りに、OSS等による制限などが書かれている。個人的には、ちょっと細かすぎるというか書かなくても良さそうに思う部分もあるけど、、、。

他の会社や商品での使用許諾も含めて、ちょっと参考にしたいと思う。

9月 29, 2010 ソフトウェア, パソコン・インターネット | | コメント (0) | トラックバック (1)

2010年9月 8日 (水)

IPA「デジタル複合機の脆弱性に関する調査報告書」

今日、面白く読んだのが、タイトルの「デジタル複合機の脆弱性に関する調査報告書」。 (何故かこの所、IPAネタが多い。)

http://www.ipa.go.jp/security/fy21/reports/mfp/index.html

デジタル複合機(MFP)での脆弱性やその対策(案)を記載したもの。

耐タンパー性などに言及してるのは良いし当たり前かもしれないが、個人的にはバグの類じゃないのとか、この辺りだとユーザ責任でしょうと思えるところも少なくなかった。

ただ、保守の絡みなど、対策してた方が良いのかもしれないと考えさせられる部分もあった。IF種やネットワークサーバー種の記述も少なくなく結構網羅的に書かれているので、MFP以外でも参考になると考える。


ちなみに、「組込みシステムのセキュリティへの取組みガイド」は、改訂版が出ている。

http://www.ipa.go.jp/about/press/20100907.html

9月 8, 2010 ソフトウェア, 品質, 安心・安全 | | コメント (0) | トラックバック (0)

2010年9月 2日 (木)

OSSの法務分野に関する基礎知識

昨日紹介したIPAのOSS(オープンソースソフトウェア)の拡充版。法務関係も、結構追記等がされていた。

http://www.ipa.go.jp/software/open/ossc/seika_1006-2.html

での、1-2の部分。非常に有名な紛争例も引き合いに出されており、分かりやすい。また、日本での「無保証」の難しさにも言及しており、頭に入れてて損でもない。

GPLバージョンに言及して欲しいとの声もあるかもしれない。ただし個人的には、自主的な勉強などでカバーできるし、(事例が出るくらいになれば別だが)余り細部に拘るのも学習ガイダンスにはマッチしないように思える。

9月 2, 2010 ソフトウェア | | コメント (0) | トラックバック (0)

2010年9月 1日 (水)

OSSでの開発プロセスとかコミュニティマネジメント

今日何気に見つけたのが、IPAの「OSSモデルカリキュラムV.1拡充」。

http://www.ipa.go.jp/software/open/ossc/seika_1006-2.html

7月公開だったようだが、知らなかった。カリキュラムの更新版というか拡充版。V1.1ってしても良さそうなのに、なぜか”拡充版”。

で、個人的に良いなと思ったのが、OSS(オープンソースソフトウェア)での開発プロセスとか管理に関して記述してあること。拡充版で、そこが追記されている。OSSコミュニティでのバグの扱いとか、それに対するテスト、その結果の管理などに言及してある。

以前から何か資料があればと懇親会とかでちょっと述べたりしてたので、希望がかなった感じ。まっ、そうやって要望を言ったからでもないだろうが。

ある程度予想していたことが多いけど、やはり参考になった。あるいは、これをネタにして、より詳しい話を聞いたりができる。例えば、メンバー間で意見の相違があった場合の収束方法など。議論するのは分かるけど、どうしても真っ二つということもあると思う。

OSSでもない一般のソフト開発でも、コミュニティのあり方やコード品質を一定以上に保つ活動での参考になるだろう。特に、市場に出してからの保守開発や、複数ユーザでのβテストを何度か行う時などに有効と考える。

あるいは、大学の教育などで、グループによるソフト開発での参考として活用するのも良いかもしれない。PSPなどとも違うと言えるので、グループ間でどんなプロセスにするかも含めて競わせるのも面白いかなと思った。

9月 1, 2010 ソフトウェア | | コメント (0) | トラックバック (0)

2010年8月28日 (土)

Bloglinesよ、さようなら。Googleリーダーよ、こんにちは。

RSSリーダーとして、ずっとBloglinesを使ってた。ただ最近不満になってきたのが、ログイン画面が頻繁に出ること。フィードの登録時もだし、リード時も。特に、パスワード以外にキャプチャ入力も必要で、しかも、そのキャプチャが結構複雑。何度もリロードする羽目になるので、時間が馬鹿にならなくなった。

結構以前もGoogleリーダーにしてみようか検討したけど、以下の理由で断念した。

・BloglinesからOPML形式でフィードを移そうとしたけど、フォルダ名などの文字化けがひどい。

・未読のみを読む機能がない。

・フォルダやフィードの並びが、アルファベット順固定。


Bloglinesのログインの時間の無駄が我慢なら無くなり、意を決してGoogleリーダーへ。上記の制限も含めて、慣れると結構使いやすい。文字化けは手作業で修正し、フォルダ名の先頭に番号を入れて優先順位などの代わりにした。多少、フィードそのものの文字化けもあるけど、数が少なかったし、フィードの一覧があるので作業は楽。

Googleリーダーって、さらっとフィードの一覧を見て重要そうなのを読めばいいし、読むタイミングを失っても気にしない気にしない、みたい発想。「トレンド」→「あまり更新なし」をクリックすると、フィードのあるページが永く更新されてない順に表示される。必要に応じてフィードを削除できる。

Bloglinesだとフィード毎にタイトルのみとか本文/概要も表示する指定が可能だけど、Googleリーダーにはそれは無し。それぞれを本文表示してみるとか、その都度フォルダ単位でのリスト表示タイプと全文表示を切り替える。最初は違和感あったけど、上のようにGoogleリーダーの発想を理解できると便利な面もある。例えば、タイトルだけで気になるのにマーク(☆をつける)にして、マークがついたもの全部を全文表示して読む操作ができる。

なお、Googleリーダーの昔はアルファベット順固定だったけど、今は操作で順番を変更できる。ただしこれもGoogleリーダーの発想を理解できると、むしろアルファベット順固定の方が楽な時もある。アルファベット順固定の方が、フィードのフォルダを変更する時などに参照しやすい。なので、フィードの登録でフォルダの末尾に追加されたり、フォルダ名の変更/追加で末尾になるが、むしろ違和感になってきた。まっ、許容範囲ではあるけど。


Autoaddfeed1ただし、Googleリーダーへ、フィードを登録しようとすると、リーダー側に登録するかブックマーク側に登録するかが表示される。

これも違和感あって、”Auto Add Feed to Google Reader for Greasemonkey”をインストールした。

http://userscripts.org/scripts/show/10729

ただし、うまく動かない。「あれっ」って思って調べたら、スクリプト実行のページが、”google.com”。なので”google.co.jp”を追加。 なお、私の場合はGreasemonkeyを常時Onにしていないことと、”Auto Add Feed to Google Reader”を利用しても2つの登録画面を表示する位の一瞬の時間がかかるので、手動操作でリーダーへ登録してもあまり変わらないかな。


少しGoogleリーダーに慣れたけど、そうなると使いやすい。しかも良かったのが、iPadでも利用できること。当然、既読/未読がPC/iPadで共用なので、非常に便利だ。

8月 28, 2010 ソフトウェア, パソコン・インターネット | | コメント (0) | トラックバック (0)

2010年8月25日 (水)

コンピュータ将棋”不遜な挑戦”は、10月11日

お盆休みの関係もあって、やっと「情報処理」8月号を読む。といっても、さらっと。

特集がエネルギーの情報化で、ミニ特集がコンピュータ将棋。後者が、ちょっと面白いし、女流名人との対戦を”不遜な挑戦”と言いながらも小気味良い文言がちらほら。私自身は将棋は良くわからないけど、分散処理などで参考になる部分も少なくない。誤り訂正機能のないiMacによる動作の記述部分は、少し笑えた。

で、清水市代女流王将との対戦が、タイトルに書いたように10月11日。体育の日。

http://www.ipsj.or.jp/50anv/shogi/press2.html

コンピュータ側の名前は「あから 2010」。”あから”は”阿伽羅”で、10の244乗という数の大きさを表すとのこと。

どうやらTVなどの実況中継の類は無さそう。対局場自体の入室は不可だけど、解説の所などへの入場は可能みたいなので、つぶやく人が出てくるかもしれない。ただ、今のところ、それらしいハッシュタグはないみたいだ。

どんな対戦結果になるか楽しみ。


蛇足:特集のエネルギーの情報化の方だけど、電気以外の他のエネルギーとか、水などの資源の情報化も面白そうとふと思った。(もしかしたら、既にミニ特集などをやった?)

8月 25, 2010 ソフトウェア, テクノロジー, 科学, 科学技術 | | コメント (0) | トラックバック (0)

2010年8月24日 (火)

スピードダウンは、Microsoft Updateのせい?

最近1月くらい、Windows XPの動作が遅くなった。起動時間もかかるようになったが、通常の操作でも。

当初ウィルスチェックソフトのせいかなとか、Thunderbirdの索引作成が関係するのかとか考えて、色々設定変更してみた。しかし、ほとんど変わらないし、動作が遅くなった後にWindows update更新のアイコンが現れることが多いように感じた。

試しに、Microsoft updateを自動起動しないようにしてみた。

 http://www.update.microsoft.com/microsoftupdate/v6/default.aspx?ln=ja

 「設定の変更」

 「Microsoft Update ソフトウェアを無効にし、Windows Update のみを使用する 」のチェックをオン

 「変更を今すぐ適用」をクリック

何となく、それなりのスピードで動くようになっている。

最近、めっきりOfficeを使うことが少なくなったので、余り問題も発生しないだろうと。また、もっと高性能のPCに買い換えるべきなのかもしれないが、新しいPCには新しいOSがついてて個人的には使いにくそう。と言うか、新しい機能に余り魅力感じない。しかし少し経つとパッチなどでスピード低下しそうだし。

Microsoft Update ソフトウェアを無効にして、しばらく様子見。

8月 24, 2010 ソフトウェア, パソコン・インターネット | | コメント (1) | トラックバック (0)

mixiの障害から学ぶもの

知り合いが、mixiの障害に関する細かい原因を記述してあるサイトをつぶやいてくれた。

mixi大規模障害について 解明編

そのサイトの左の方から、説明なども辿れる。”執筆者個人の環境と経験に基づく”とのことで、mixiの正式見解ではないけど、ミクシィ開発部の人なので貴重な記述。

このような(非公式)公表の仕方には意見あるかもしれないけど、個人的には好感。他の人の再発防止になるし、色んな思惑での公式な見解よりも純粋な技術的な話として参考になる。

で、個人的に実務的な実装を行ってないので細部は良くわかってないけど、分散キャッシュの”memcached”に関連した問題で、起動時のパラメータ変更で対応したとのこと。


高負荷状態のテストと同様に、接続限界数での確認を長く行えば事前に見つかったかもしれない。ただ、接続限界数を色々変えて、しかも日レベルでの動作テストすべきだろう。そうなった時に、確認環境をどうするか。一般的にクラウドのような範疇では、開発、テスト、本番の3システムを要することは言われているが、テストが1システムで良いか???

また今回は、”memcached”の問題とのことで、その点だけだとパラメータの組合せはそう多くない。が、システムには多くのソフトが使われている。各ソフトでの起動のパラメータの種類、そして複数のソフトのことを考えると、これらパラメータの組合せが膨大となる。

あと、今回は障害が長く続いた。”memcached”でのパラメータ変更の確認に時間がかかったとも言えるが、利用ユーザーからすると、もう少し早めに原因究明と確認が出来るべきだろう。

今回のトラブル、そしてその原因の記述が、開発とかテストでの課題を教えてくれた気がした。

8月 24, 2010 ソフトウェア, パソコン・インターネット, 品質 | | コメント (0) | トラックバック (0)

2010年8月16日 (月)

MSでの脆弱性”修正不能”

今日何気に目にしたのが、以下のSlashdotの記事。6月中旬の掲載だったようだ。

Office XPに含まれる脆弱性、「訂正不可能」なため放置

脆弱性は分かっているけど、Office XPについては対策を見送りますという宣言。マイクロソフトでの「MS10-036」のページでも、大きくは書いてないが下の方で読めば分かる。なお、本Slashdotのサイトが良いのは、皆さんのコメントで、他の例がいくつか書いてあること。

個人的には、MSなり巨大化したソフトではありがちなことで、「そうなんだ~」位の感想。用途によって、使うソフトなり仕組みは違って当然で、それを踏まえて設計するだろうと。

8月 16, 2010 ソフトウェア, 品質 | | コメント (0) | トラックバック (0)

2010年7月29日 (木)

いまさらUMLが複雑になりすぎたって言われても、、、

IT proで、複雑になったUMLに関する連載がスタートした。

平鍋氏による「イントロダクション:複雑化したUMLを救え

第1回 UMLの価値を検証する

個人的には、今年6月に開催された「第30回ソフトウェア・シンポジウム - SS2010」での議論を掘り下げたイメージ。(実際にはSS2010には参加しなかったが、知り合いのレポートやつぶやき等を読んでそう思う。)

UMLの課題に関して検討していくことは悪いことではないし、今回議論の元ネタは、ヤコブソンの考え、あるいは彼の”エッシンシャルUML”提案を検証することになるのかもしれない。(ちなみに”エッシンシャルUML”は、同じIT proでも2006年に紹介されている。)


「UML2.0の2割で価値の8割を生み出せる」と“UMLの父”ヤコブソン氏


ただし、個人的にはSysMLやMDA等の議論の方が馴染みがあるし、UMLの書式を全部使えって言ってるわけじゃないので、「何でいまさら細分化して実用化されつつあるのに、複雑化の話を持ち出すんだろう」との疑問が沸いてしまう。もちろん”エッシンシャルUML”のようなものが簡易にモデリング出来たり、その後の開発もスピーディになりそうな分野はあるだろう。しかし、演習や利用分野が限定されそう。少なくとも、自分の参加しているコミュニティで話題となる分野では利用はきつそう。

後、気にしているのは、ドキュメントも書かなければソースコード品質に無頓着な連中の”言い訳”に利用されるような場面。例えば、UMLでのユースケース図とシーケンス図と○○図を書こうねと皆で決めても、書きたく無い人がヤコブソンの主張を持ち出すようなイメージ。私の危惧だろうか、、、、、、。

上記IT proの連載では細部で参考となる考えなどもありウォッチは行っていくつもりだけど、上で書いた危惧も頭の隅に置いておくつもり。

7月 29, 2010 ソフトウェア | | コメント (0) | トラックバック (0)

2010年7月27日 (火)

電子書籍化と知力の誇示

前から興味はあったしiPadの関係もあって、電子書籍化や図書館の動向は少し気にしてる。図書館での情報で最近多いのは、蔵書そのものの数を減らす動き。端的な例は、スタンフォード大学の新しい図書館。

図書館の”威厳”が、建物の大きさとか物理的な蔵書の数ではなくなりつつある。それに変わるものが、電子書籍の量とかアクセス数とかサービスメニューなどになっていくのだろう。

それを考えると、よくTVでのニュース等の解説で大学の先生などが図書棚を前にしてしゃべってる風景も、今後どうなっていくのだろうか? 例えば、電子書籍端末を棚に置き、そちらのビューアで本を表示するようになるのかもしれない。

また、各自の勉強ぶりを示すのも、本の数ではなくなっていくのかもしれない。物理的に本を置いてるだけじゃ、他の人も騙されなくなるということだろう。まっ騙す気はないんだろうけど、自分でも本を並べるだけで読んだ気になるとかちょっと虚勢を張ってる気がしない訳じゃない。


ただし自分の場合で電子書籍化を進めてはいるけど、今はデータ化するのに手一杯で、それを閲覧する時間がない。積ん読とかコピーして読んだ気になるのと、余り変わらない。PDFファイルへのマーキングとか注釈のツールなどはインストール済みだけど、本そのものというか電子書籍ファイルの整理方法もちょっと考えないといけない。読書感想文みたいなのも、どっかに置くなども検討するつもり。(書籍でのサービスサイトがあるが、論文とかレポートの類もその中に含めたくて思案中。)

7月 27, 2010 ソフトウェア, テクノロジー, 電子ブック | | コメント (0) | トラックバック (0)

2010年7月24日 (土)

iPadの職場利用とかを考えてみたけど、、、

自宅でのiPad利用が増えてて、ふと会社等で使う場合を想定してみた。ただし、周りの目もだし、ルールとしても実際の利用は駄目だけど。(企業での利用が進んでいる所もあるし、外部からの機器持ち込みに寛大なところもあるとは思う。ついでに言えば、AppStoreにはエンタープライズライセンスというものがあり、限定イントラネットでのみ利用できるアプリ開発が可能となっているとのこと(詳しいことはこれから調べるつもり)。)

そもそもそんなことを考えてみようとしているのは、職場での資料も順次PDF化しているため。個人的には、プリントして書き込んだりさらっと読むことが多かった。ところが最近はAcrobat自体や、フリーでもPDFにコメントを書けるソフトも出回っている。それらを利用することで、プリントしないケースが増えてきた。

また、過去の紙でしか貰ってないものをPDF化を進めている。ファイルなどスペースの省略にもなっている。検索などで探せるのも良い。

思えば○○年くらい前にOA(オフィスオートメーション)が叫ばれた頃、ペーパレスとかの絡みもだし、そもそもファイル棚の販売が盛んになった。若い女性(とは限らないが)にとって、書類やファイルがむき出しの職場は嫌われてる。また、実際めっきり減ってきた。自分の机の中なども、それに近づいたという事になる。


ただし、ちょっとネックが。そもそも、起動の時に(標準では)パスワード設定がない。自宅でしばらく使ってて、さすがに自宅でも芳しくないと思うようになってきた。メールもだし、ドキュメントファイル、ブックマークなどもばれてしまう。あるいは削除や加工されてしまう。

パスワード設定の方法がよく判らなかったけど、探して判明。ただ、4桁の数字のみ。ちょっと不安。桁数長くするとか、文字列でもOKにして欲しい。

あと、フックするような所が無く、ワイヤーロックのような物理的な保護ができない。

次機種の時にでも、その辺りに配慮されてたら良いな~。(次機種のチップは、A3とかA5なのかな。) 


なお、資料化が一段落したら、もしかしたら電車内でのiPad利用も行うようになるかもしれない。ただし、座れる場合の利用で、立ったまま(/片手)ではさすがに利用できそうにない。

後本音言うと、PCの起動とかアップデートの時間って馬鹿にならない。資料読んだりメールでのやり取りがほとんど。そうなると、PC→iPadの置き換えも不自然に感じなくなってきている。何か今のPC主体の行動パターンって実質効率的じゃないような気もしている。機種としてはiPadなのかシンクライアントを含むような格好になるのか判らないけど、その辺りの再検討も行われる気がする。

7月 24, 2010 ソフトウェア, テクノロジー, 科学技術 | | コメント (0) | トラックバック (0)

iPhone4のアンテナトラブル 事例研究

今回のiPhone4のアンテナトラブルとその対応って、事例として結構参考になる。携帯電話以外の分野でも、大なり小なり発生しそう。あるいは、想定として考えておくのは悪い事じゃない。

そもそも発端は、電波受信の感度が悪いようだとネット等で。

最初は、アップル側は問題ないと。そして、表示だけの問題だと。(後で述べるけど、ソフトウェアの立場じゃ、本件が引っかかった。)

そして、ジョブズからの発表があり、ケースを無償で配布すると。全般的には、以下辺りが参考になる。

http://www.itmedia.co.jp/news/articles/1007/17/news005.html

(ただし、その後ネット上じゃ、他メーカーでも起きそう発言が尾を引いている。)


個人的に気にしてるのは、表示上の問題(のみ)とした件。以下での反論もあるけど、ネット上では、表示の問題のみじゃないだろうとの発言は、(自分のよく目にするコミュでは)無かった。

http://wiredvision.jp/news/201007/2010070423.html

ちなみに、アップルは携帯電話の商品化のために、1億ドル以上の施設を用意。

http://www.itmedia.co.jp/news/articles/1007/20/news038.html

また、今回のアンテナ問題の対策コストとして1億7500万ドルと見込んでいるらしい。

http://www.itmedia.co.jp/news/articles/1007/21/news013.html


「iPhone4の感度がおかしい」との市場クレームをトラブルシートと考えると、以下みたいな動きかな。勝手な推測で書いてる。

「iPhone4の感度がおかしい」トラブルシート発行。
 ↓
電気屋(通信屋)は、そんなはずない。
 ↓
ソフト屋に。
 ↓
感度表示がおかしいと判明。対策してバージョンアップの方向へ。発表。

この後(並行して)、アップル内からか市場からか、表示だけの問題じゃないのではとの声が。
 ↓
再調査/再実験。
 ↓
ケース(Bumper)の関係が判明。
 ↓
ケースの無償配布とか、既存Bumper購入者への返金を発表。


iPhone4って、ハード的にiPadと共通化していることもあって、従来のiPhoneチームと若干違うんだろう。そのせいもあってか、最初の分析が(結果的に)甘かったし、表示のみの問題としたその直後の追試も(結果的に)甘くなってしまった。ハード屋、ソフト屋、メカ屋で情報共有なりたらい回し、その過程でそれぞれの問題発覚(今回は感度の計算)。それだけの対策と発表。そんなとこかな。

最初の分析=初動で結構耳にするのは、固有問題か傾向かの判断の難しさ。多少今回の件も関連するけど、ユーザーの使用条件が異なることで、さらに判断しにくいことが少なくない。

また、結構気になってるのは、ジョブズ自らの発表の件。感度表示だけだった件をジョブズが発表してたら、それはそれで収拾が困難になったかもしれない。品質問題系の発表者を誰にするかも悩ましい。

蛇足的に言えば、結構増えてきたのがハード設計の確認をソフト屋がやったり、ある程度の市場向けソフトで行ってる。今回ので言えば、アンテナの機能をソフトでの感度表示を利用するようなシーン。その関係で、問題の切り分けが難しかったり、根本原因の発見が難しい場面もある。あるいは、複合的な原因(ハードもソフトも)の場合もあるので、分析とか検証には念を入れる必要がある。 (ハード屋/メカ屋には、「またソフトか~」みたいな感覚が少なくなく、ソフト問題が発見されたりその対策が判るとシャンシャンとなり、ハード/メカの問題もある・あるかもと考えない。)

7月 24, 2010 ソフトウェア, 品質, 携帯・デジカメ | | コメント (0) | トラックバック (0)

2010年7月22日 (木)

バグが見つかったら、別バグも発見せよ 「1+n施策」

最近めっきり本を買うのが少なくなったり、読むスピードが遅くなってきた。「いかん、いかん」と思いながら、今日は「ソフトウェア品質会計」を超高速・断片的に読んだ。

誉田直美(ほんだなおみ)さんによる、NECでのソフトウェアの品質保証技術の本。全体で200ページ超と、余り厚めでもないので読みやすい。また数値データなどが具体的で、判りやすい。

ちなみに、”品質会計”との意図は、バグを負債として考えるためとのこと。(感想は後述。)


で、気になったのが、タイトルにもしている「1+n施策」。バグが発見されたら、真の原因などを探る意味で、同種バグをn件発見するというもの。これを1994年辺りから、バグ分析と共に検討したとのこと。

気にしたというのは、1980年代前半に本手法を実践しているのを耳にしているため。当時は、「1+n施策」という明確な用語化までには至ってなかったが。ちなみに、耳にした際のnは、1,2とかじゃないけど10とかまで多くはなかった。当時は、ポピュラーとまでは行かなくても、実践している会社は少なくないと思ってた。そのため、時期的な表記が気になった次第。

なお個人的には、バグ件数ゼロが本書での判定基準になっている等も気になった。バグを負債と考えるなら、資産というかバグ非ゼロでの出荷などにも言及してもらった方が有り難かった。コラム的な記載でも仕方ないだろうけど。


”丸投げ”について、いくつかの状況を丸投げ/丸投げでないと記載している部分は、参考になると考える。


Img036Amazonで、なかなか表紙が表示されないので、記載。下の方は帯。


7月 22, 2010 ソフトウェア, 品質 | | コメント (0) | トラックバック (0)

2010年6月16日 (水)

「ソフトウェアかんばん」と「eかんばん」

講演会の案内等で、”ソフトウェアかんばん”を、このところ何度か目にした。目にする頻度が増えた感じ。すると、少し違和感を感じて、その違和感が何なのか気になった。

思いついたのは、2,3年前にトヨタを見学した際に目にした、”eかんばん”との違いかなと。ちなみに、”eかんばん”は、以下のトヨタのページでも画像を見ることができる。

トヨタ自動車:企業情報 > ビジョン/フィロソフィー > ジャスト・イン・タイムについて

つまり、トヨタ自体での”かんばん”の電子化が進んでいるのに、何で”ソフトウェアかんばん”の電子化が進まないのかが少し不思議に思えてきた。もちろん、ToDoを電子管理するツールはあるし、マークなどを面白く工夫しているツールがあるのは知っている。また、ポストイットなどの利用の方が導入しやすくて、皆の理解を得やすいこともあるだろう。

しかし、各作業の関連やその完了チェックを電子化しておくのはメリットが大きいのに、余り発表がないように思う。それらが必要な場合は、ソフトウェアかんばんからの移行よりも、別の管理ツールを使うと割り切ってるのか、、、。あるいは、それらが必要なケースが限られているのか、、、。


個人的には”ソフトウェアかんばん”のようなToDoを壁に貼りだす方法と、プロジェクト管理ソフトなどでの管理方法とを併用するのに違和感を感じないが、そんな実践は余り多くないのかもしれない。

6月 16, 2010 ソフトウェア | | コメント (0) | トラックバック (0)

2010年6月14日 (月)

「アンビエントオーブ」よりも警告灯?

時間かかってるけど、読んでる最中のが左の「継続的インテグレーション入門」。

その中で、目についたのが「アンビエントオーブ」。ビルドでの状況を通知するための利用での例として書かれていた。ビルドで警告メッセージが発生してネット経由で通知すると、その通知内容によってランプが点灯するといったイメージ。通知内容で色が変化する。少し面白そうと思って、調査した。ただし、この本でも日本での使用は、(無線の関係で)難しいと。

他のちょっと類似する商品を含めて、置いたときのイメージが分かりやすいのは以下かな。

http://pingmag.jp/J/2007/01/10/top-5-wi-fi-toys-at-home/

インテリアとしては良い。少しほんのりとした感じ。ただし、ビルド失敗のような状況には、どうも似つかわしくない気がした。ビルド失敗と聞いて、ついついサーバー室などの警告灯をイメージした。で、そちら系を調査。例えば、「警子ちゃんⅡ」。

http://catalog.infocreate.co.jp/?m=show&eid=349

ただし、こちらは無線ネットワークが駄目みたい。また、上のアンビエントオーブよりは値段が高い。 ちなみに、警告灯で旗みたいなのが上がるタイプを見かけた気がするが、ネットではすぐに見つからなかった。旗を揚げるのは、自作だったのかもしれない。

個人的には、警告灯の方が良さそうに思ってしまった。余り無線に拘る必要もないかと。(ただし、そもそもこの類に、お金をかけることを嫌う人たちがいるかもしれないけど。)


6月 14, 2010 ソフトウェア | | コメント (0) | トラックバック (0)

2010年6月 8日 (火)

iPadで「はやぶさ君の冒険日誌」

今日一番嬉しかったのは、iPadで「はやぶさ君の冒険日誌」を読めたこと。

下のように、TVでのiPadのデモのように、ページをめくる感じで読めるようにした。帰還の数日前に目にできたので、なおさら嬉しかった。

P6080001ちょっとしたいきさつがあって、、、、、。

まず、先だって購入したiPadで、色々電子ブックを読んだりしようとか、自分の資料でPDF化したり、PDFになっているものを読もうと検討。それで、見つけたのが、「i文庫HD」。有料。

http://ipn.sakura.ne.jp/ibunkohd/

どうせiPadを使うのなら、既存のPDFもページをめくる感じで読みたい。その観点で探したもののうちの一つ。しかし、有料とのことで、当初、少し躊躇。

詳しく見てみることにして、内蔵の書名をつらつらと目で追った。青空文庫ということもあって、著作権の切れたものが多い。すると PDFの所に「小野瀬直美 はやぶさ君の冒険日誌 2010」の文字。当初、”小野瀬直美”ってネット小説家?とか、”はやぶさ君”って日本の子供の児童文学?とか考えた。 しかし、すぐ近くのアイコンで小惑星探索機の”はやぶさ”と分かって、驚いた。「はやぶさ君の冒険日誌」自体はPCで読んでたし知ってたけど、まさか青空文庫(の純文学の類)のすぐ隣に置いてあるとは思わなかった。

で、即「i文庫HD」を購入して、ダウンロード。「はやぶさ君の冒険日誌」も、そのサイト経由で(再度)ダウンロードした。操作で少し手間取ったところもあったけど、写真のようにうまく動いてる。

P6080002左のは、「i文庫HD」での書庫の一番上に「はやぶさ君の冒険日誌」を置いたもの。


iPadではYouTubeも標準でインストールされてるので、「はやぶさ」で検索すると、いくつかの動画も見ることが出来る。

”はやぶさ”の帰還まで、あと5日になり、JAXA経由で色んなイベントも流れてきている。自宅にいる時は、iPadでの"はやぶさ"コンテンツで結構楽しめそう。

6月 8, 2010 ソフトウェア, テクノロジー, 電子ブック | | コメント (0) | トラックバック (0)

2010年5月11日 (火)

高校で「情報経営」ってあるんだろうか、、、。

昨日は、農業高校向けの教科書を受け取る。「農業経営」など。1週間ほど前に申し込んだもの。以前別の教科書を購入する時は、日ノ出町まで出向いたけど今回は近場で申し込んだ。

昨日と今日、「農業経営」(農文協)をさらっと読んだけど、結構面白い。そもそも、簿記に80ページくらい割いてる。農業関係の法令も一覧になっており、30超の法律が記載されている。制度資金の種類とそれぞれの金利も書いてあって、ちょっと驚き。経営での損益分岐などにも言及している。

言い方が良いか?だけど、農業高校でこれくらいのレベルを教えるということ。少なくとも、”自立”への意識には役立つだろう。で、ふと情報とかはどうなんだろうかと思ってしまった。情報で”飯”を食うための「情報経営」があるのか、、、。

http://www.aomoritosyo.co.jp/kh07_kyokasho/kh0710.html

上記などで高校の教科書の一覧を見ることができるが、やはり無いようである。それはよいとしても、やはり自立のための勉強とか、経営系の勉強もやっていた方が良いと考える。あるいはメカトロニクスの具体的な制御とか、Web系のソフトウェア学習とか、、。

昔ながらのゼロイチのちょっとした延長止まりで十分なのかとか、学生もオフショアなどの名の下に行われていることを知っているはず。それを考えると、既存の情報の学習のやり方で良んだろうか。ふと気になってしまった。

5月 11, 2010 ソフトウェア | | コメント (0) | トラックバック (0)

2010年4月 6日 (火)

アジャイル 十年一昔

昨日、資料の整理をしてて目に止まったのが、IT Proでの以下の記事。

   Part3 手法:超高速開発を実現「アジャイル」の全貌

”日経コンピュータ 2002年10月21日号、56ページより”とあるので、そちらでも参照できるだろう。なお、既に本IT Proのページは無くなっているので、、、、。

XPやクリスタル、スクラムなどが対比的に述べられている。また、その時点で、10年くらいの実績が出来つつあるとしている。

で、今朝、目に付いたのが以下の記事。

第1回 30年前の改善魂を取り戻せ

アジャイル開発でも30年前の開発現場と基本的なことが多く、アジャイル開発の細かい技術面に目が行きすぎているのではないかとの指摘である。自分の周りでも、(実践のための創意工夫を抜きにした)アジャイルのための問題点の話が少なくない。

なお「第1回 30年前の改善魂を取り戻せ」では、IT企業の社内開発プロセスへのアジャイル組込みも表になっていて参考になる。具体的には、IBMのIGSDF、日立製作所のHIPACE、富士通のSDEMといったプロセスへのアジャイルの組込みである。ただし、組込み予定を含む。


ちなみに、海外でのアジャイル系の”つぶやき”でも、多少アジャイルのターニングポイントを匂わす書き込みも目にする。読み違えているかもしれないが、従来の手法をも配慮する考えが入り、「30年前の改善魂を取り戻せ」と基本的な所で共通点が多いと感じた。

「30年前の改善魂」やIT Proの昔の記事を考えると、30年前がウォータフォール手法。20年前にアジャイルがポツポツ。10年前から普及。そして今が(ウォータフォールを含めた)再考といった感じだろうか。ふと、野中郁次郎氏の”SETIモデル”のような、螺旋的な進歩と少し似ているのかなと思いつつある。

4月 6, 2010 ソフトウェア | | コメント (0) | トラックバック (0)

2010年3月31日 (水)

”スクラム”の原典「ラグビー方式による新製品開発競争」

アジャイル開発”スクラム(Scrum)”の発端として有名なのが、「新たな新製品開発競争」という論文。竹内弘高,野中郁次郎. 「DIAMONDハーバード・ビジネス」4-5月号1986。さらに元は、その英語の論文。

ふと、そもそも野中氏や竹内氏が、何を問題視したり参考としたのか気になった。また、スクラムが日本での開発手法を参考にしたとのことで、もしかしたら現在のスクラムよりも参考になることがあるのかも知れないと気になった。

論文以外に、少し探して見つかったのが、左の本。その第9章に「ラグビー方式による新製品開発競争」として掲載されていた。スクラムを組んで開発を行うなどが書かれている。

この論文で分析した企業とその製品は以下。

富士ゼロックス(FX-3500)
キヤノン(PC-10、AE-1、オートボーイ)
ホンダ(シティ1200CC乗用車)
日本電気(PC-8000)


Img0322その論文での図の1つが左。従来は、各フェーズが分断されている。それが、分析したケースの場合はフェーズが重なっていたり、メンバーの一部はいくつかのフェーズに参画していることで競争力を増していると分析している。

ちなみに、フェーズでの重なりを、富士ゼロックスでは”サシミ(刺身)”と表現している。”サシミ(刺身)”は、現在のスクラムの本にも出ている。

ふと、フェーズでの重なりや、メンバーの重なり、あるいは広範囲の部署メンバーを巻き込んだプロジェクト遂行は、現在のスクラムでも参考にしても良いのではないかと感じた。


今となっては、論文そのものも20年位前のものになってしまったし、上で述べた製品群の開発当時を知っている人も少なくなったかも知れない。特に、現在のスクラム等を議論する人達には皆無だろう。しかし、日本の製品開発方法が参考にされたことや、その開発方法を知っておくことは非常に有意義と考える。


なお、示した書籍「製品開発革新」では、延岡氏の”マルチプロジェクト組織への変革”の論文を含め、日本の開発手法がいくつか分析されている。その点でも参考となる事項が少なくない。

3月 31, 2010 ソフトウェア, 書籍・雑誌 | | コメント (0) | トラックバック (0)

2010年3月24日 (水)

予算と決算 監視の有り様

2010年度予算案が成立したそうだ。2,3日前から、「あれっ、決算が成立したってニュースに出るっけ?」と気になってた。

で、ちょっと調べたら、ちゃんと憲法90条に会計検査院が、国会に報告する旨が明記されてる。なお、会計検査院のページ見たけど、個別の細かい無駄遣いはそこそこ分かったが、どの官庁が予算オーバーしてるかなどはすぐに分からなかった。見つけ方が悪いのかもしれないが。

でも、そんな情報の整理も的確じゃないように思うし、中間的な決算情報は無いと思う。蛇足だろうけど、政権交代でその辺りが変わるか気になってが、どうなる事やら。まっ、今度の夏は参議院選挙だからと言われそうだが。


それは良いとして、赤字垂れ流しという視点では、国の財政”管理”のやり方は、真似るべきじゃないんだろう。先進国でワースト○位。ここ何年か続いている。

逆に、国の財政”管理”のやり方と、各自の組織体のそれとを対比するのは、有意義だろう。つまり、予算獲得の時には色々騒ぐけど、決算というかパフォーマンスの向上や低下を監視できているかどうか。パフォーマンスの向上や低下を各組織体で把握できないと、国と同じで赤字垂れ流しになっちゃう。 個人的には、まずは、ちょっとした指標での監視でも良いと思うんだが、どうであろうか、、、。

3月 24, 2010 ソフトウェア, プロジェクトマネジメント, プロジェクト管理, 経済・政治・国際 | | コメント (0) | トラックバック (0)

2010年3月17日 (水)

ペアプログラミングと著作者人格権

一月くらい前の勉強会で、ちょっと触れたのが「著作者人格権」。ソフトウェア開発での契約とかで話題になることは少ないけど、技術者なら概要や用語程度は知ってた方が良い事項。ただし、結構グレーな部分もあるので細部の深入りは禁物かな。

その勉強会の後に、知り合いから教えてもらったのが、経産省による「モデル取引・契約書」。

http://www.meti.go.jp/policy/it_policy/softseibi/index.html#05

納入物について、著作者人格権を行使しない旨の記載になっている。その時は、上の深入りとの関連で、明記した方が良いかはちょっと議論のあるところだろうと思ってた。

その後ちょっと考えたのが、表題のペアプログラミングのケース。開発の発注と受託との関係では、発注側と受託側がペアを組むケースだと、請負契約は難しい。受託側とは、派遣や準委任での契約になるだろう。その場合は、「著作者人格権」をどうするかは、はっきりしていた方が良いと思われる。発注側で、後になって改変する可能性が大のためだ。

ペアプログラミングや先々の仕様変更が多そうなケースを考えると、著作者人格権を行使しない旨の記載を行ったり確認してた方が良さそうと考えるようになった。

3月 17, 2010 ソフトウェア | | コメント (0) | トラックバック (0)

バグカーブ近似 その2

昨日書いた「バグカーブ 対数曲線や二次曲線での近似のお勧め」で、少し補足。

対数曲線や二次曲線は増加関数なので、バグカーブの近似として不適切と感じる人がいるかもしれない。しかし個人的には、テストの終盤になってもバグが発見されるので、増加関数が適切と感じている。

その理由だが、ソフトウェアテストの場合には、操作やパラメータをテスターに一任する場合がある。これは「殺虫剤のパラドックス」の防止策の一つである。「殺虫剤のパラドックス」は、JSTQB(ISTQB)のFoundation Levelシラバス日本語版にも書かれているが、全く同じテストを繰り返すことで欠陥が見つかりにくくなることを指す。「殺虫剤のパラドックス」の防止策のためにパラメータや操作タイミングを変化させることで、新しいバグが見つかるケースがあるというわけだ。

シンプルで小さなソフトウェアなら、あるところからバグの発見がゼロになることもあろうが、大規模なソフトの場合や外部モジュールを利用する場合に、どうしても終盤でもバグの発見がゼロにならないことは実務的に少なくない。

★ただし、重大バグとなると若干話が違ってくる。つまり、バグ件数全体は増加関数でも仕方ないとしても、重大バグが終盤でも発生したら対策が必要である。具体的には、重大バグの解決まで市場リリースを延ばすなどである。そのためには、単なるバグ全体件数のカーブ以外に、重要度でレベル分けしたバグのカーブも情報としては必要となる。

なお、重要度のレベルは3つとか4つなどが普通と考える。また、最重要レベルのバグ曲線近似を少し考えてみたが、うまい曲線は見つからなかった。累積では成長曲線の類が良さそうだが、初期では昨日と同じような立ち上がりの不一致が発生すると思われる。累積ではなく発生件数をY軸とするカーブも考えられるが、うまく減衰する曲線が見つからない。(確率分布でのカイ自乗(χ2)分布みたいな曲線を思い浮かべたが、、、、、。)

ただし、最重要レベルのバグは、リリース直前では何日か発生ゼロでなくてはならないので、余り回帰分析などに拘る必要もないだろう。

3月 17, 2010 ソフトウェア, 品質 | | コメント (0) | トラックバック (0)

バグカーブ 対数曲線や二次曲線での近似のお勧め

バグカーブ/バグ曲線とかソフトウェアの信頼度成長曲線って、ソフトウェア工学での大きなテーマである。ちょっとした会合や講演会の題材、あるいは学術論文でのネタになることも少なくない。

代表的な曲線は、ゴンペルツ曲線とかロジスティック曲線とかだろう。ただし、ソフトウェアテスト(具体的にはシステムテストであるケースが多い)の初期に無理に曲線を当てはめてみて想定と大きく違ったり、 測定値と予想との乖離が気になることがある。前者はある意味仕方ないが、後者はもっといい近似曲線がないだろうかと考えてしまう。(ちなみに、ここでは、バグ発生のモデルではなく、あくまで曲線近似の世界のことを扱う。そのことや、近似が成長曲線でないので、ここでは”バグカーブ”と呼ぶことにする。)

ここ1,2年前くらいから、少し”もやっと”したものがあったが、 Day2の本を読んで納得した。以下の左が、Day2の統合テストでのバグカーブ。

Day2_2Atz431_2

ちなみに、上の右の図は、  http://www.pmalignment.com/web/note/atz/atz43.html で紹介されているもので「ソフトウェア品質ガイドブック 森口繁一編 日本規格協会」に記載されている図とのこと。


1,2年前から少し”もやっと”していたのが、テスト開始初期段階のカーブ。上の2つのように、急に立ち上がるのが旧来と違っていて気になった次第である。自分の見聞きするケースにはそれが多く、ちょうど右での一般的な成長曲線のカーブを重ねた際に気になっていた。

もう○○年前の、ちょっと大きなプロジェクトでバグカーブを作成し、所謂S字カーブになり納得していた。理由付けとしては、テストメンバーが不慣れでバグの発生件数が少ない → 次第に増える → 終盤になるとバグ対策の効果でバグの発見自体が少なくなる。

それが昨今、初期段階に急な立ち上がりのカーブを目にする機会が増えた。最初、自分の見聞きするケースでは横軸を日数ではなくテスト件数にすることが多いからかとも思ったが、そればかりではなさそうと感じていた。ちなみに、昔に横軸を日数にしたのは、(紙ベースの時代でも)トラブルシートでのトラブル発生日を元に集計すれば求まったためである。しばらくしたら、BTS(バグトラッキングシステム)により、それらが自動的に集計できるようになった。しかし、昨今は、テストの進捗管理の実施も普及してきたので、その日のテストの実施件数を把握している事が多い。

Day2の本を読んでもバグ件数の立ち上がりが急だったので、一般的にもそうだろうと考え、ある考えに行き着いた。

つまり、テストチームは事前に仕様書を読んだりテストケースの準備をしている。場合によっては、プレリリース版を入手してバグの多そうなところも分かっているかもしれない。しかもテスト技術が発達したり、テストエンジニアやテストグループのリーダーにスキルや進捗管理能力の高い人を配置するようになっている。そうすると、テスト開始と同時に、多量のバグレポートが発行される。これは、ある意味では必然である。

そうなると、バグ曲線はS字カーブよりも、下のような対数曲線等の近似がぴったりである。あるいは思い切っての近似としては、あるところまでは直前で、あるところからなだらかとか水平になると考えてよい。例えば水平になるのは、市場投入予定の2週間前からと想定するなどである。

下はその前提で、仮想的なテスト件数とバグ件数を近似曲線で示したもの。対数曲線近似と二次多項式近似を示している。対数曲線近似や二次多項式近似のメリットは、近似曲線としてエクセルに標準でついていることだろう。具体的には、エクセルでの近似曲線のオプションで指定する。(OpenOfficeでは対数曲線近似は行えても、自動的に係数表示しない? Rだと、近似曲線を記述する格好になると思われる。)

__3__4


また下は、上記のデータをSPSS(ただし 15.0J)での回帰分析により、2つの曲線を描いたものである。

OutputtableOutput0


(ちなみにDay2でのバグカーブもX軸は件数。しかも2ヶ月程度で30万件強のテストを実施している。これはこれで驚きである。しかもバグ件数の想定が2619件で実績が2008件と、予測とのずれが少ないし、しかも絶対的にバグ率が小さい。)

企業によっては、公の資料としてゴンペルツ曲線などでの予想カーブを描かないと行けないなどがあるかもしれない。しかし、ソフトウェアテストの実務上は、対数曲線や二次多項式近似あるいは直線近似との乖離を監視するので良いと考える。特に、二次多項式近似あるいは直線近似の場合は、発見バグ数の予測によりカーブを求めることが容易である。工夫すれば、対数曲線での予測カーブを求めることも可能となり、実際の発見数との乖離を早期に見つけることが出来、差異に対する対応が行いやすくなる。

興味あれば、お試しあれ。

3月 17, 2010 ソフトウェア, 品質 | | コメント (1) | トラックバック (0)

2010年3月13日 (土)

再読「人月の神話」

ふと、「人月の神話」を、さらっと読み返してみようと考えた。コンピュータ関連書籍では、超有名な古典とも言える本。

Ningetunosinwaまず読み直したのは、左の「ソフトウェア開発の神話」の方。「人月の神話」の原著訳と言って良い。1975年版とも言われる。

実は、ちょっと思い出がある。こちらの原著の方を学生の頃に、先生から「読みなさい」と言われた。2,3度だったかな。結局は、訳が出版されてしばらくして読んだ。

こちらが、今でも書店に並んでいる方。1995年版とも言われる。章としていくつか追加されているし、訳者が違う。ただし、従来の章の内容は、(訳文上の違いがあるが)内容的には同じ。

英語タイトルは1975年版でも"The Mythical Man-Month"であり、訳としては「人月の神話」に違和感はない。そうは言いながらも、個人的にちょっと引っかかったのが”人月の神話”という用語の使われ方。それが、今回再読してみるきっかけになった。

「人月の神話」では、ソフトウェアプログラム作成の作業量として、人月を用いることの危険性を明示している。ちなみに”人月”は、1975年版での訳語としては”延人数”。

ただし、以下のことを述べているし、留意すべきと考える。

・コストは人月に比例する
・ブルックスの法則:「遅れているソフトウェアプロジェクトへの要員追加はさらに遅らせるだけだ」
・人月に互換性がある場合として、コミュニケーション無しで作業できる場合がある

最後は分かりにくいかもしれない。本では麦刈りや綿摘みが該当するとして、プログラミングは該当しないとしている。互換性は、人月で見積り、人数を増やせば期間が短くなる事を指している。念のためだが、ここでのコミュニケーション無しとは、作業の途中でのコミュニケーションがなくても良いとのことで、事前準備や作業方法説明がなくても良い分野と言うことではない。


そもそも「人月の神話」では、見積りを否定してはいない。何かこの辺りが変に伝わり、見積り不要論とか見積もろうとしない連中がいるように思える。あるいは、見積りに対して(倍とかのレベルで)大きく違った場合の言い訳に使うとか、、、。

また、作業中のコミュニケーションを無くす、あるいは少なくできれば、人月の互換性を高めることができる。この辺りを、見積りとの差異を少なくできるポイントと考えればよいだろう。しかし、なかなかその考えに行こうとしない人が多すぎる。

アジャイル(特にスクラム系?)でも、見積りや進捗管理の実践は行われる。遅れている/遅れだした時の対応や、作業中でのコミュニケーションと人月互換性の関係は、当時と変わらないと考えるがどうだろうか、、、。

3月 13, 2010 ソフトウェア, 書籍・雑誌 | | コメント (0) | トラックバック (0)

2010年3月 5日 (金)

エジプトでの分数と固定小数点数

今日、頭を悩ませたきっかけは、電車の広告での中学入試問題。エジプトでは異なる単位分数の和で示したので、それを元に分数を表記してみるというもの。例えば、2/3という大きさの分数を1/2+1/6で示すなど。問題の解答は、さほど難しくなかったが、何でエジプト人はそう考えたかが頭を悩ませた。

ピラミッド作ったりミイラのような化学技術を発達させた人々が、なんでそんな非効率な/非合理的なことをやったんだろうかと。

今日は暖かかったので、昼休みに外に出たら、閃いた。2/3を0.67というか、半分よりも大きいとか考えたんだろうと。つまり、2/3は、1/2よりは大きくて、でも残りは1/3よりは小さい、、、。そうやって、小数というか1よりも小さな数を表現しようとしたのではないかと。それだと、例えば、分母が小さい順から並べると、後の方が文字として欠けたり情報として通じなくても、大きな誤差にはならない。コミュニケーションロスへの対策になるというわけだ。

そう考えると、結構合理的と思えて来た。

さらに、その数列とかを思うと、早い話、固定小数点数の表記と非常に似ている。1/2+1/8、、、、と分母は2のべき乗にして小数を表す方法。まっ、エジプトで使った単位分数の分母が、2のべき乗(つまり固定小数点数)のみだったとまでは考えにくいが、少なくとも現代と通じる部分を発見したように思い嬉しくなった。


なお、数字としてのゼロの発見はもっと先になるので、エジプトの時代は小数というよりも比率みたいな考えだったように思う。例えば、ピラミッドでの幅に対して高さを1.n倍としようとした時に、0.nをどうやって求めるかなどで使ったのではないかと。で、1/2、1/4、、、は紐などを折り返せばすぐに作れるので、結構固定小数点数と同等の考えを使っていたようにも思える。

結構楽しかった一日だった。

3月 5, 2010 ソフトウェア, 歴史, 科学 | | コメント (0) | トラックバック (0)

Day2プロジェクトの本 システム統合の「正攻法」

言わずと知れた、三菱東京UFJ銀行でのDay2プロジェクトの様子を描いた本である。

本の帯での文言は以下。

  将来に残すべき実務マニュアルの完全版!
  ITプロフェッショナルが明かす100の創意工夫

  6000人の技術者、開発期間1000日超
  2500億円が投じられた-
  三菱東京UFJ銀行「Day2」の全記録

買ったのはずっと前で、販売された当日か翌日くらい。急いで買いに行ったら、コンピュータ関連の棚になくて少し焦った。店員さんに聞いたら在庫ありで、金融関係の棚。すぐに読んだが、こちらのブログに感想を書くのが遅くなってしまった。その間には、PMIフォーラムでDay2の講演を聴く機会も得た。また、実は、今月での別の会合でも、Day2プロジェクトの講演を聴くチャンスがある。ちょっと遅くなったが、今月の講演前に、ブログで感想をまとめておこうと思った次第。

まず、総括。この本は、Day2プロジェクトでの技術的な側面も書いてはあるが、どちらかというとプロジェクト管理、しかも品質とか進捗の管理を掘り下げている。しかも、チーム形成とかチーム一体感の維持などにページが割かれており、非常に参考になる。また、銀行頭取や会長による関与の記述もあるかと思えば、システム構築を行った開発会社の取り組みとか創意工夫についても書かれている。開発会社のそれは、開発会社自信が書いたかインタビューによるもののようで、結構ざっくばらんな記述もあって面白いし参考になった。


Day2プロジェクトの前にDay1プロジェクトがあり、Day1プロジェクトの稼働からDay2プロジェクト開始の5ヶ月間に、プロジェクトの組織作り(含む協力体制)を行っている。その際に、当初外部の開発委託のメンバー数を2500人と考えていたのが4500人必要と判明した。それから2000人の確保に奔走することになる。つまり、開発技術者6000人の構成は、銀行本体のシステム部員:600人、銀行システム部門関連会社:900人、外部委託の技術者:4500人。(P26)

6000人は、ピーク時とはいえ、銀行システム開発やそのテストを考えて素人考えでの概算見積もりなどをやってみるのは、良い訓練になるかも知れない。少なくとも、どんな作業がありそうか考えて、本書での確認を行ったりするのは良い勉強になる。(正直に言えば、私は1桁違ってた。)

また、一度決まった要員数を大幅に超える見積もりが発生した場合の対応も、身近の対比を行ってみるのも良いかもしれない。外部の委託先人数は、倍近くに増えることになる。それを責任者に言うか、言っても「元の数字でやれ」とか「何故だ~」とか言われかねない。また、上がその人数確保に奔走してくれるか、、、、。

本書では、開発要員のために海外を含めた人材確保が書かれている。ただし、今回のプロジェクトが素晴らしいのは、「スキルポートフォリオマネジメント」を実施し、必要な技術レベルや開発経験などを一元管理した点であろう。そのマネジメントがプロジェクトの前から恒常的に行われていたことが幸いしたが、むしろスキルポートフォリオを行っていることに感心した。(P28)

グループの責任者を明確にしたり(P31)、ゴール設定(P39)なども明確に行われている。進捗管理なども具体的な事が書かれており、「そこまでやるかな~」と思えるほど細部にわたっている。また、開発ばかりではなく、移行テストのための工夫(P92など)などにも触れており、参考になる。

ページは少ないが、構築での海外製品(P69)やシステム構成(P71)も書かれている。また、データ移行の際のトラブルで、海外の開発本部への連絡と対応で乗り切った話なども紹介されている。(P206)

士気向上のための施策(P95~)が、結構面白い。はちまきを巻いた結束式兼出陣式の写真などがある。スクリーンセーバーやボールペンなども作成したとのこと。ちなみに、大漁旗の”統合丸”は、P149に掲載されている。

士気向上と関連するが、開発メンバーが増えたことでトイレ工事を行った話や弁当への配慮も行ったそうだ。トイレ工事は、床を上げて配管工事をして確保。1つのビルで男子用のトイレの便座45台を設置した。(念のためだが、この類は言うが易し行うは硬し。多少なりともファシリティが絡むことを交渉を経験したら分かる。)

上記も、”Day2では、そこまでやったのか~”の類と言えるが、テストや関連する作業にはさらに多い。旧データのデータ移行が必要となるが、そのための回線として、2社の主と予備の計4本を確保した。(P143) 現場のためのマニュアル作りなども細かく行っている。(P121) またデビットカード関連のテストでは、切り替わりの丁度午前6時を狙ってタクシーを利用してテストするなども行っている。(P141)

ちなみに進捗管理(テスト結果)の類がP58~。文字としてテスト密度やテスト実施率などが読み取れる。また、通常のシステム開発では、接続テストとして”ITb”と表記するが、Day2プロジェクトでは、接続テストを2回行い、ITb1、ITb2のテストを行っている。(P28) 


この本では、開発会社毎の記載が面白い。見積りやプロジェクト管理など技術系を主として記載してある会社もあるが、プロジェクト参加によるチーム形成の話が多い気がする。特に面白かったのは、ある開発会社での話。週2回の飲み会を行い作業の効率化が図れたが、一部のチームは毎日飲み会実施して回覧で”飲み過ぎ注意”が書かれたとの件。(P202)


ソフトウェアそのものの技術的な記載は少ないが、プロジェクト、しかも日本的なプロジェクトマネジメントとして非常に参考となる本である。ソフトウェア工学の観点では、細部のデータまでは識別できないとしても、ソフトウェアプロジェクトでの各種メトリクスや基本的な数値の実例、ドキュメント種なども書かれており好実例である。

思うに、Day2に多少なりとも参画した、日本の情報処理関係者が数千人レベルでいるということ。これは日本にとって、貴重な財産になるとも言える。皆さんの回りにもいるのかも知れない。いたとして、プロジェクトそのものを教えてもらうことは守秘義務などで難しいことが多いだろう。でも、自分のプロジェクトのことを話して「○○と思うけど、どうでしょうかね~」と、自分の考えに対する意見をもらうことは構わないだろう。そんなことのためにも、例えば本書のようなもので情報を仕入れて、よりハイレベルな会話が成り立つのは良いことである。それが日本のプロジェクト遂行能力の向上にも役立つことになる。

3月 5, 2010 ソフトウェア, プロジェクトマネジメント, プロジェクト管理, 書籍・雑誌 | | コメント (0) | トラックバック (0)

2010年2月23日 (火)

「アジャイル開発の本質とスケールアップ」

副題は、"変化に強い大規模開発を成功させる14のベストプラクティス"。

前半部分で、XPなどアジャイルプロセスの概要が述べてある。後半の所々でもXP等の事が書かれているが、中心はスクラム。

個人的に、大規模開発への利用とか、アジャイル開発のパフォーマンス計測に興味があって求めた。それに関する部分を中心として、さらっと読んだ状態。

アジャイルプロセスアセスメント指標と称した3ページの表もあり、パフォーマンス計測への利用なども可能かと思われる。BSC(バランススコアカード)に関連した提起もされており参考にはなった。ただし、アセスメント指標やBSCでの実際的な数値事例があれば、更にありがたかった。書かれている参考文献で見つかるのかも知れないので、調査してみる。(ただし、日本での事例などを比較するのが、より対比になって良いだろうから、自分的にはその辺りをどうするかに知恵を絞った方が良いかな。)

なお、副題に”14のベストプラクティス”とあるが、第2部のタイトルは7つのベストプラクティスになっており、今ひとつ14の意味が不明。どこかを読み違えているのか、深読みしながら考えてみたい。

2月 23, 2010 ソフトウェア, 書籍・雑誌 | | コメント (0) | トラックバック (0)

2010年2月11日 (木)

「ソフトウェア開発 データ白書」 2005 Vs. 2009

IPA/SECによる「ソフトウェア開発 データ白書」は、結構前に読んでて書いておこうと思いながらも、まとめるのが遅くなってしまった。勘違いなどがあるかも知れないけど、自分なりの分析や感想を書いてみる。

この本が良いのは、毎年発行されていること。それなりの品質データが記載されていることや、FP(ファンクションポイント)とSLOC(ソース行数)の両方によるメトリクスが掲載されていることだろう。

ということで、2005年版(最初の版)を探しだし、その対比も含めて書いてみる。ちなみにP***/P***は、前の方が2005年版でのページ、後が2009年版でのページ。特に断ってない場合は、2009年版でのページである。

1)2009年版では、改良開発でのメトリクスが追加されている

これは、非常に良いこと。新規開発との対比もそうだし、今後は改良開発自体の比較も可能になる。

2)計測データ数の伸びが鈍化

このデータ白書は、旧来のデータに新規な調査結果を追加するタイプ。(細部分析すれば、新規追加分での把握な事が少なくないが。)

P13にデータの年別内訳があり、2004年の942件に対して、2008年が271件。比率も2004年 40.5% → 20.5% → 15.3% → 12.2% → 11.6% と、順次減衰している。個人的には、不景気などよりも、計測に対する取り組み意識が少し変化してる気もする。計測意識の低いベンダーとか、ベンダー内グループが少しづつ増えてきたのかも知れない。まさかと思うけど。

計測のメリットなども明らかになっているで、今後の動向を気にかけておくつもり。

3)FP利用が少し衰退

規模尺度の対比がある。 P20/P43

2004年版のFPのみ 51.1% → 2009年版のFPあり36.4%。これは結構実感とも合っている。表現が良いか分からないが、FPブームはちょっと去ったとのイメージ。

ただし、FPの場合は、計画と実績の差が少ない。P264およびP265。その点はFPの有利な点。

4)品質は確実にアップ

稼働後のバグ件数の図。 P55/P79

平均値が2004年版の40.4件 → 2009年版15.4件。標準偏差も2009年が少なくなっているし、そもそもグラフを見れば明らか。バグ件数50件以上のデータも存在するが、2004年度などのデータも含まれるのも理由だろう。個人的には、せめてこのデータ部分は年の累積棒グラフにしてもらいたい位。つまり、最近での稼働後でバグの多いデータ件数は、非常に少ないと考える。

5)ばらつきが減少

ソース行数と工数の関係など。どれが端的か悩ましいが、P67/P160など。

6)改良開発の件

データ対比で、改良開発で端的なのは、P253での新規開発とP255の改良開発の対比。改良開発の方がテストケースが増るが、バグ件数は少ない。つまり、影響部分を確実にテストしていることが伺える。

ちなみに、このデータ白書での改良開発での作成行数は、改良で追加等を行った行数。参照元のシステム(母体)は含まない。P17。

なお、ちょっと気になったのが、言語別のSLOC生産性の対比。新規開発P178と、改良開発P188を対比すると、C言語の場合に改良開発の方が高い。VBも若干高い。

すぐ後のページで業種別のSLOC生産性を示しているが、改良開発での製造業と公務は生産性が対比的に高い。その辺りが、上記C言語での改良開発における生産性の高さに結びついているのかも知れない。つまり、製造業や公務は、C言語で書かれたものを大きく改良(含む部分ペーストなど)するのではないかと。このご時世、そもそもC言語の利用というのも再考が必要と思うんだけど。 まっ、外してたらごめん。


いずれにしろ、今回の改良開発の追加も含め、データ白書は対比などで活用していきたい。

2月 11, 2010 ソフトウェア, 品質, 派生開発、保守開発、改良開発 | | コメント (0) | トラックバック (0)

2010年2月 5日 (金)

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が追加されてる。Version1でも、ちょっと触れてたと言えば触れてたけど。それにしても、この調子だと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などもちょっと読んでみようと思う。

2月 5, 2010 ソフトウェア, 品質 | | コメント (0) | トラックバック (0)

2010年2月 3日 (水)

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

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

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

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

2月 3, 2010 ソフトウェア | | コメント (0) | トラックバック (0)

2010年1月30日 (土)

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

日経エレクトロニクス(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ってなんであんなに大ボリュームにしたのか分からない。そのせいもあって、むしろ品質特性での議論で大事なのは、継続的改善の方かと思う。

1月 30, 2010 ソフトウェア, 品質 | | コメント (0) | トラックバック (0)

2010年1月27日 (水)

○イテレーション*日

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

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

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

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

1月 27, 2010 ソフトウェア | | コメント (0) | トラックバック (0)

2010年1月23日 (土)

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ノートブックのサポートが復活してるかもと期待しながら。でも、案の定そこは駄目wink

さっと一通りテスト。その際、若干難問が。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ノートブックへの対応の件が一段落すると良いんだけど、、、、。

1月 23, 2010 ソフトウェア, パソコン・インターネット | | コメント (2) | トラックバック (0)

2010年1月21日 (木)

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

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

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

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

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

1月 21, 2010 ソフトウェア, 書籍・雑誌 | | コメント (0) | トラックバック (0)

2010年1月19日 (火)

「柱のきずは~ をととしの~」と唄いながら

今日は、何故が童謡”背くらべ”を口ずさんでしまった。

  柱のきずはをととしの
  五月五日の脊(せい)くらべ

先週だったかのソフトウェアのメトリクス関係の話から、思い浮かべたのかも知れない。(言葉のリズムのせいもあるけど)昨年とか去年でなくて、”一昨年”というのが良い。

なんか事例発表とかって、昨年との対比など、どうも短期的なのが多すぎ。せめて、2,3年続けるくらいの気持ちが必要と感じてしまった。

しかし、それよりも厄介なのが、全く計測に無頓着なケース。昨年との対比すら行われないケース。それで信頼性や品質が向上したかとか、適正値に近づいたかが分かるはずがない。

子供達だって、センチやメートルを知らなくても、マーキングすることでの対比が出来る。子供や自分がどれくらい大きくなったかを測ろうとするのが自然と思うけど、ソフト屋さんにはそんなこともせずに精神論ばかりという輩がいるみたい。困ったもんだ。

ちなみに、本童謡の作詞は、海野厚。著作権消滅曲。

1月 19, 2010 ソフトウェア, 品質 | | コメント (0) | トラックバック (0)

2009年12月31日 (木)

2009年雑記

大晦日なので、今年2009年に読んだ本などを書いてみる。読んだ後とかにブログに書こうと思いながらも、書くタイミングを失ったものが多い。(一部既に書いてることがあったら、ごめんなさい。)

・「システムLSI設計のためのリユース・メソドロジ・マニュアル」

半導体に関しては直接関係しないけど、基本的に知っておくべき事もあって、ぽつりぽつり本とかを読んでる。(頭に入り込んでないけど。)

この本は、システムLSIでの再利用に関するガイドラインの本。規格的なものでなくて、業界的にこの本をベースにしているところが多いらしくて読んだ。半導体での、IP(Intellectual Property)に関する本と考えて良いだろう。

ハードウェアよりも、半導体記述ソフトウェアの再利用に関する記載がほとんど。テスト/テストベンチとかプロジェクト管理にも言及してる。

純粋なソフトウェア再利用の本もあるけど、この本の方が全般的に書かれていると感じてしまうし、タイミングのような微妙な部分は”組込みソフトウェア”の再利用検討でも参考になるような気がしている。


・「UMLは手段」

新書版。

とかく設計などのプロジェクトで、手段を目的にはき違えているケースを散見する。設計向けやプロジェクト管理のツールを導入することが目的になってて、製品化などに(極端には)無頓着。

この本は、そんな勘違いを指摘している。またUMLそのものに関してもポイントを押さえて書いてあるので、UMLの全体的な把握のためにも有用と考える。


・「日本絶賛語録」

来日外国人の日本に関する記載を集めたもの。111個。本のタイトルが示すように、日本を絶賛したもの。時代的には、江戸~明治。

懐かしさを覚える事項もあるけど、同じ日本人のことなのにむずむずするくらい気恥ずかしい事項もある。

勤勉さとか高い教育水準。当時に戻ろうとは言わないけど、グローバル化という言葉と一緒に日本の強みを忘れてしまうのもおかしな事。この本読むと、「日本の強みって○○かな~」と思い起こせるだろう。

なお、今まで余り感じなかったけど、この本に記載されている人で、幕末での”攘夷”のもとに殺害された人もいる。逆に下関砲撃などを主張した人も。 幕末と来日外国人を考える意味でも、参考になるかもしれない。


・「劔岳 点の記」(Blu-ray) 

今月発売だったけど、宿題とかのために購入を延ばしていたもの。宿題も一段落したし冬休みになったので、購入。

あらすじは、明治時代の日本での測量で残っていた剣岳へ登頂するというもの。陸軍と山岳会が先を争ったり、案内人(ガイド)探しやその案内人との駆け引きがあって面白い。そして、剣岳そのものの風景が素晴らしい。(ただ個人的には、冬以外の春とか夏などの風景も、もう少しあったら良かったのにとは思ったけど。)

今回はBlu-rayの方を購入したけど、メイキング映像とか映画外の剣岳の風景があって、感激した。木村監督の、撮影じゃなくて修行に行ったという表現もうなずける。

ちなみに、この映画でガイドの宇治長次郎を演じたのが、香川照之さん。TVの「坂の上の雲」や大河ドラマ「龍馬伝」予告を通じて、TV画面上で何度も見ることになってる。しかも、それぞれの演技がうまい。この映画では、最初の方での”歩き方”が妙に気にいった。腰の下の方に手を添えて、すっすっと歩く。 ちなみに調べたら、宇治長次郎は登山道の「長次郎谷」として名を残してる。

プロジェクト管理の視点での映画としては、「八甲田山」と同じように参考になるように思う。明治39年秋に命令が下り、1年くらいで達成。遂行のために、経験者(学識者)に聞いたり協力者の手当てに奔走する。また悲しいかな(あるいは現代でも少なくない?)、命令する方は地図のためじゃなくてメンツに拘る。


・お台場 ガンダム

今年印象的だったのは、お台場の等身大のガンダム。実際に見に行ったのは、2回。

また、CS放送での「立ち上がれ!ガンダム」って、結構面白かった。

プロジェクトマネジメントと考えると、内部では色んなトラブルなり、衝突なども起きていたとのこと。衝突と言うほどでもないだろうが、当初のコンセプト上の皆さんの意見対立とか、ある程度固まってからの富野総監督からの要望(というか仕様変更)に対する折衝とかは生々しかった。個人的には、実物よりも、そのCS放送番組の方がプロジェクトマネジメントの良い教材になると感じたほど。

また、建築物なので、建築許可の申請とか掲示なども行ってる。当然だけど、倒れないような設計とか計算、そしてコンクリートでの強固な土台。等身大ガンダムの肩の所などには、風力計とか避雷針。

さらに言えば、多分コストの関係だろうけど、海外(タイだったはず)でのパーツ製造とかを行ってるシーンが出た。その際のペンキの色の管理や、輸送などでのひずみの件も面白かった。特に後者は、最終的な製造現場で削ったりするシーンもあって驚くと共に、身近で見聞きするプロジェクトと大同小異で親しみを覚えた位。 また、タイで漫画ガンダムそのものを知ってる人が少なくなかったのもちょっと印象的。 (タイでのシーンでは、短い間だったけど、1,2人のぼかしの人がいて、妙に気になった。)

実は、CS番組を見て、自分なりにプロジェクトでのチャートを書いてみようかと思った。しかし断念。CS番組からスポット的は話は理解できたけど、各分野を時系列的に記載するのって実質無理。他の題材を探してみるつもり。ただし見つけるのにちょっと時間はかかりそうだし、皆が知ってるかとか情報が多い方が良いので、頭の隅に入れておく程度になりそう。


来年もいい年でありますように、、、、、。

12月 31, 2009 ソフトウェア, プロジェクトマネジメント, 日記・コラム・つぶやき, 映画・テレビ, 書籍・雑誌 | | コメント (0) | トラックバック (0)

トラブル・告知サイト

休みでの”積んToDo”対応その7。今年ちょっとウォッチすることにした、告知とかトラブルの紹介サイトの件。いくつかサイトがあるけど、自分でもまだ整理できて無くて断片的な情報だけど、書いておく。

製品安全ガイド

検索が可能で、重大製品事故にかかる公表を集めたもの。改正消費生活用製品安全法施行日の2007年5月14日以降のデータ。

NITE 独立行政法人 製品評価技術基盤機構

上との対比では、NITEは消費生活用製品安全法に基づく報告義務のない事故の掲載。

リコールプラス[家電]:家電に関するリコール/自主回収/お詫びの情報 (ソフトジャンル)

ソフトウェア屋の立場としてちょっと重宝している、家電業界のソフトウェア関係のリコールなどを集めたサイト。ただし、DVDのようなコンテンツ関係も含んでいるので注意。運営しているのは、一般の企業みたいである。


もちろん、これ以外に多数あって、自分でも整理できていない。逆に、一般消費者の立場では、どう検索して良いか悩むのでないかと思えてしまう。

製品安全ガイドとNITEが別々なのは、その最たるもの。消費者にとって、報告義務があるかどうかは余りたいしたことではない。○○が重大事故と聞いて、それとは直接関係しない自分の**は問題ないかを調べるのに、両方見る必要があるというのも変である。データベースの共通化までは無理としても、せめて公的機関間の情報やり取りが出来るようなインタフェースは考えるべきと思うんだが。


ソフトウェアのトラブル関係を、うまく一覧化しているサイトがないかは、ずっと宿題だ。上で書いたリコールプラスや失敗事例のサイトなどは参考にしているけど、不十分かなとの認識。と言いつつ、他力本願じゃなくて、自分とかコミュで整理しないと行けないのかな~とも。(一部そんな活動はしてるんだけど。)

12月 31, 2009 ソフトウェア, 品質, 安心・安全 | | コメント (0) | トラックバック (0)

自動車業界でのデザインレビュー

休みでの”積んToDo”対応その6。自動車業界(具体的にはトヨタ)での、DMU(Digital MockUp:デジタルモックアップ)のこと。以下で具体的に見られる。

XVLと呼ぶシステムの言わば宣伝みたいな記事なので、多少さっ引いて読み取った方が良い部分もあるだろうけど、参考にはなる。自動車業界的には、メカとソフトウェアの連携部分のレビューができるシステムも(実験的?)に構築しているようだ。ショーなどで目にした。例えば、メカの径を変えたときに、ソフトを変更して正しく動作するかの検証などを行うなど。ソフトの変更と言うよりも、パラメータ変更。パラメータ変更で対応できない時のみ、ソフトを改良するのが普通だろう。 メカ型の業界には、大なり小なり導入されていると考えても良いのかも。


個人的に昔は、メカトロニクスという言葉を古くさく感じていた。しかし最近は、メカトロニクスのニクスはエレキの事じゃなくてソフトウェアのこと、あるいはメカとソフトウェアとの比重が大半を占めると思うようになった。しかも、それにより、開発効率を向上させる。あるいは、それが可能なインフラが整いつつある。 ソフトウェア屋の立場では、机上でメカとソフトのレビューを十分に行って、後はメカの金型作成や電気設計をやってもらい、ソフト屋は次の開発をやりながらフォローをちょっと行う位になりたい。 何かメカ屋とか電気屋の、具現化しない機能とかその急な変更に悩まされるとの意見が多すぎると思う。また、この類でのシステムでレビューなどを効率的に行うのが、全体的な競争力優位にも結びつくと思うんだが。

#ちなみに「メカトロニクス」って、商標登録してあると目にしたけど、今もそうなのか???

12月 31, 2009 ソフトウェア, テクノロジー | | コメント (0) | トラックバック (0)

2009年12月30日 (水)

プロジェクトの成功/失敗での、コストや期間の誤差

休みでの”積んToDo”対応その5。よく言われる、プロジェクトの成功率3割での、成功の判断基準の件。

成功率3割と書かれているけど、期限が1日でも延びたら失敗というのかとか、その期限の基準は計画の早期なのか終盤なのかを気にしていた。今年10月に開催されたPMIフォーラムで、ちょっと関連する話題が出たので、再確認しよう思っていた。

一番引用されるのは、「日経コンピュータ」の調査かと思われる。直近では、2008年12月1日号。それによると、成功率31.1%。また、本号での指摘は定量管理している方が成功率が高い点で、これはネットニュースなどでも書かれた。(ちなみに、直前の調査は2003年で、2008年は第2回目。)

そこでのコストと納期での成功と考える範囲が書かれており、2割未満とみて良い。(クロス集計とのことなので、ちょっと表現としては不正確だけど。) これは、色んな現場での尺度としても良いと思う。ある意味「2割の誤差はOKとみなそうよ」「1割の誤差は御の字」とか。

なお、品質の成功尺度は、ユーザ側が”計画通りに利用しており満足”を判断基準としているようであるが、満足という部分が主観的なために不正確と感じてしまう。ただし、本件は満足度の方が重要との考えもあって、絶対的な尺度が良いかは色々意見あるところ。また、バグゼロを成功とはしていない点は、肝に銘じておくべきである。


コストと納期の基準とした計画時点がどこがは、気になったまま。いわゆる計画当初かどうかなど。売買契約とかの話しが出るだろうが、昨今は基礎的な仕様検討の段階と実装段階とを別契約にすることも少なくない。そのような場合の基準時期をどう考えた方が良いか、、。

あと一つ気になったのは、本調査での有効回答数の激減。感覚的には3分の1に。例えば、定量化手法を導入しているかの有効回答数は、2003年が1537件に対して、2008年は438件。景気のせいなのか、プロジェクトの成功かどうかの調査や定量化手法の導入を遠ざけようとしているのか?? もし後者とかだと、回答企業も少し考え直してもらった方が良いかと考える。

12月 30, 2009 ソフトウェア, プロジェクトマネジメント, プロジェクト管理 | | コメント (0) | トラックバック (0)

Googleのソースレビューシステム Mondrian オープンソース版

休みの間に調べようと思っていたネタ。結構”積ん読”ならぬ、”積んToDo”少なくないと反省ではあるけど、、、。

まずは、Googleのソースレビューシステム。どっかで「Mondrian」という名前だとか非公開とかを読んだ気がしてたけど、再確認。すると以下のページあり。


GoogleのソースレビューシステムMondrianのオープンソース版「Rietveld」

Rossum氏自らが実現したソフトとのことなので、参考の価値はありかな。インストールして使うというよりも、機能を参考にしてツールに組み込むとか運用でカバーするという作戦もありかなと。


個人的に、時々聞くレビュー結果が表形式なのが、どうも理解できない。ソースへのコメントなりWordでのコメントで良いのに。(それらを掃き出して一覧化しとくのは悪くないんだけど。)

12月 30, 2009 ソフトウェア | | コメント (0) | トラックバック (0)

2009年12月19日 (土)

ベストプラクティス集よりも、ワーストプラクティスから学べ

今日の勉強会運営会議での帰り道の会話。「ベストプラクティスって、全部実施するの大変かも」「へぇ~。その組織体の『ワーストプラクティス』って残ってないの? あるいは、その組織体での限界見本みたいなとこははっきりしてないの?」

本とかに、ベストプラクティスを集めてるのは分かる。しかも、それらでも、各組織体で必要なものを選択すべきと書いてある。問題は、現場に色んな部署のプラクティスをマージしたものが渡るとき。しかもタイトルに”ベストプラクティス”って書いてある。

実は、うまく行ったチームって、必要な項目以外はバッサリ止めてるケースが少なくない。なので、別のチームがそのまま真似てもうまくは行かない事が多い。よほど外の状況や、内部の状況や体制が同じでない限り。

例えば、
Aチーム:a,b,cを実施
Bチーム:b,d,eを実施
”ベストプラクティス”:a,b,c,d,e

a~eはプロセスだったり、ソフトウェアメトリクスの計測種だったり、、、。それを全部やるための勉強、追加的な作業を考えると、全体効率は落ちるばかり。

しかも、運の悪いことに、そのマージを実施した連中が、そのマージしたプラクティスが絶対と思うようになってること。悲劇の発生。なのでベストプラクティスは、生に近いようなデータを、マージすることなく実施部門毎に列挙する程度にしておく方が良い。

あるいは、その組織体にとんでもない部署があれば、そこのプラクティスを紹介する方が良い。つまり、ワーストプラクティス。その組織体での最悪チームはあるだろうから、そこから学ぶ方が早いだろう。

12月 19, 2009 ソフトウェア, プロジェクトマネジメント, プロジェクト管理 | | コメント (0) | トラックバック (0)

2009年12月10日 (木)

「要求工学」と「アクションラーニング」のどっちを先に読む?

今日は、少しフランクなメンバーで馳走になりながら中華。その会合って、うまく表現しにくいけど、今から述べることは、営業獲得できたお祝いの席みたいに読んでもらえると良いかも。

顧客立場のメンバーを含めて打ち合わせして、機能面で削ったり追加したり。今日で概要確定して、合意形成。その後の馳走。知り合いは、どっちかというと構築側。

知り合い:「そう言えば、私『要求工学』の本読んでるんですよ」

私:「ふーん」

知り合い:「......」 

(何か言葉待ってる感じだったので)
私:「勉強するなとは言わないし、基本は知っとくべきだけど、今日のに役に立った?」

知り合い:「......」 

私:「お客さんが言ってる事って、超希望だったり、間違ってることあるんだから。」

知り合い:「そう言えば、お客さんが間違ってるという意識はあまりなかったな~。ちょっと作ってみて、後になって違うと言われることはあるとしても。」

私:「そんなのは、ある意味、最初のお客さん要望が間違っているから。」

「多分だけど、『要求工学』の本読んでも、お客さんを疑えとは書いてないよ。」

「しかも、現代でネックなのは、無料で使えてるシステム多すぎ。自分の所で構築する場合に、コストがかかるという意識がない。」

「なので、最初はお客さんが間違っているとの前提に立った方が良いくらい。」

「結構多いのが、要望として書かれているのが、新しい受注の人の知らない旧システムのこと。お客さんは、ほんとはそのシステムでの、使いたくない部分は少なくない状況。でもシステムを文書にしにくくて、旧システムのコピー&ペーストで渡される。」

知り合い:「じゃ、どうすればいいんですかね~」

私:「心理学系とか、話術や交渉の本かな。でも、深層に描いているものを引き出すには”アクションラーニング”がいいかも。」

知り合い:「”アクションラーニング”っすね。読んでみようかな。」


うん、ネットでも良いから読んでみてと。あっ、ネットでも良いと明言したかは、紹興酒を結構頂いたので記憶が定かじゃない。また、”アクションラーニング”自体は会議などでの使い方なので、対人で使うにはちょっと応用すべきだろう。

要求(分析)→要求工学の本が解決してくれそうに思う人が少なくないような気がする。要求工学も、ある意味ではツール。そのツールを使う前に、考えとくべき事は少なくない。

知り合いさん、頑張ってね。

12月 10, 2009 ソフトウェア, プロジェクトマネジメント, プロジェクト管理 | | コメント (1) | トラックバック (0)

2009年12月 7日 (月)

1984年の日本語TeXの論文

今日は、タイトルの論文を送ってもらった。時代や内容が、ちょっと懐かしいもの。

一昨日、とある人(若い女性wink)から、金曜日に日本で初めてTeXを使ったという知り合いがいたとの話を聞いた。その女性と同年代とか指導の先生かと思って、「ちょっと疑わしいな~」と言ったら、今日論文PDFを送ってくれた。

見たら、なんと私も知った人。年代的にもこちらに近い。合点がいった。

当時は、一部の人達がKnuth先生のシステムを真似たり、ソフトを利用して日本語TeXを構築していた頃。その頃、直接にその人と会った訳じゃないけど、神奈川の西の方なので思い当たることある。その論文も、構築した日本語TeXで書いたもの。 ちなみに、その前後だと、まだ手書きややっとワープロでの論文の時代。

その人とは、ここ2,3ヶ月PM関係でやり取りが多い。今度ちょっと、昔語りしてみるつもり。それにしても、世の中狭いと実感。

12月 7, 2009 ソフトウェア, 科学, 科学技術 | | コメント (0) | トラックバック (0)

2009年12月 2日 (水)

誰かが、仕様書/テスト項目の全体をチェックしないと

今日は、気のおけない人達と飲み会。簡易忘年会といった感じ。

その場で、ちょっと話題となったのが、メンバーの中の一人とで「○○○マジック」と呼ばれているもの。○○○は、私の名前というかニックネーム。2,3時間(とか1,2時間)で万件レベルのテスト項目を読むというもので、その人の仲間の間でも、そう呼ばれているみたい。

多少説明はしたけど、色んな他の話題が出たので、うまく伝わったか? また、その細部の手法よりも、以下の件が重要。

つまり、ソフトウェア開発には色んな文書があるけど、誰かが全体を把握する必要があるということ。文書で大きなのが、設計系だと”システム仕様書”や”製品仕様書”といった、設計上の一番上位としてまとまった文書。またテスト系も、それに対応するテストの仕様書。

まず、これがある所と無い所とでは、雲泥の差。というのも、各ブロックとか各ボード、各サブシステムといった類の文書が揃っていても、全体を理解できない。全体の整合性確認のためには、多量のチェックが必要となる。したがって、個人的には、全体の文書作成が難しかったら、各ブロック等の文書作成を犠牲にすべきとの意見。

次は、その全体的な文書のチェックを、誰がやるかということ。多少、誰が作成するかという問題もあるけど。

実は、ソフトウェア規模が大きくなると、この文書作成自体が相当面倒。初級的なプログラマだらけだと、ちょこっとプログラム作成することが楽しいから、そちらに走りがち。というか、初歩的プログラミングしかしてないと、そもそも文書を書く必要性が理解できない。(そんな連中が、外注とかオフショアに作業やらしても、文書がないのを平然としたり、そのチェックを実施できない。破綻原因の一つ。) 書いたりチェックが、各ブロック等どまりになるケースがほとんどである。

全体チェックの必要性が分かれば、後は、それを誰がやるか。複数人で作成したとしても、できれば別の人のチェックが望ましい。そう考えると、リーダー格が実施する方が効率良い。統一性も確保できる。つまり、全体チェックは誰かがやらなくてはならないし、それはリーダー格がやるべきである。

その必要性が理解できれば、後は、どう実施するかを考えればいいだけ。例えば、小説を含めた書籍は、それなりの情報量だけど、理解できる。良い例は、法律書かな。

人は個別の関連性のないものをたくさん並べられても、理解しにくいとか覚えにくい。章とか見出しは、そのためにある。つまり、仕様書もテスト項目も、章立てなどを明確にしておけばいい。そうすれば、どこに書いてありそうか判断できるし、書いてなければ追記する必要がある。(特にテスト項目で重要なのは、非機能要件に対するテスト項目が書かれているか。)


その次は、如何に迅速に読むかだ。迅速に拘るのは、ドキュメント更新が少なくないから。それはシステムであれば、ユーザからの要望追加とか変更も関係する。ユーザからのそれらがないとしても、内部的な細部仕様は結構変わる。ユーザには余り関係しない、サービス向けの仕様とか、いわゆる非機能要件部分の変更もその類。

なので設計系もそうだが、テスト系もテスト仕様書は誰かが、しかも迅速に読むことが必要である。ちなみに如何に迅速にと言っても、最初は整合性が欠如してる部分が多いので、どうしても時間はかかる、それは仕方ない。ただ、中盤~終盤になれば、差分や仕様記載/テストでのポイントに注力して、時間を短くする必要がある。

そのための具体的な方法は、やはりそれぞれの文書作成のインフラとかツールにも若干関係する。ただ注意は、そのツールの方が重要じゃなくて、それを達成すべきとの意識の方だ。(私の場合、文書とかテスト項目のエクセル記述は大嫌いである。100ページの仕様とか1万件クラスのテスト項目を、一挙に読む場合を想定してもらえればすぐに分かると思う。スクロール一つとかを想定してもらえれば幸い。)

まだ細部では伝わりが悪いところがあるかもしれないけど、それはまたの機会かな。


#補足:念のためだが、各ブロック等の文書が重要で、全体文書がさほどでもないケースはある。”摺り合わせ”などの類。ただ、そのためには、各ブロックでの限界などが明確に規定されていたり、その厳密なチェックが行われるケースに限定される。

12月 2, 2009 ソフトウェア, プロジェクト管理 | | コメント (0) | トラックバック (0)

2009年12月 1日 (火)

東工取のシステム障害での発表や対策

東京工業品取引所で先月27日にシステム障害が発生し、金の先物等の取引が出来なくなった。

東工取のシステム障害、原因はナスダックOMX子会社製ソフトのバグ

原因の記者会見が上記。開発はNTTデータで、問題部分は、OMXテクノロジーという会社のものだった。

で、このシステムの開発発端の記事を見つけた。以下。(他にもいくつかある)

東工取、次期システムの発注をNTTデータに(OMX社のソフトを採用)


言わば、発表をユーザ自らが行い、開発会社や利用しているモジュールやその作成会社が、(表現としては非常に変だけど)白日に曝された。また、東工取とNTTデータが原因究明まで行い、スウェーデンのOMXテクノロジーにソフト修正依頼をして、東工取とNTTデータで動作確認したんだろう。修正までの時間との勝負もあったろうし、動作確認といっても修正部分以外のテストもある。関係者は大変だったと想像できる。

逆に、ふとOMXテクノロジーの迅速な対処とかには感心してしまった。(人によってはバグ発生自体を大きく問題視する人もいるかもしれないが。)

ここでのソフトを、COTS( commercial off-the-shelf:商用オフザシェルフ、商用品)と呼んで良いか分からないが、増えつつある形態である。いわゆる外部モジュール。


その意味では、今回のトラブルは、対応も含めて非常に参考になるケースである。

重要なモジュールとかを公表しておくのは、トラブル発生時のリスク低減になる。逆に、そのためのメカニズムの用意や、テストなどを視野に入れておく必要がある。またCOTS開発側にしても、修正などを含めた迅速な対応を行えるかを十分検討した方が良い。ふと、そんなことを思った。

12月 1, 2009 ソフトウェア, 品質 | | コメント (0) | トラックバック (0)

2009年10月18日 (日)

ソフトウェアテストPRESS Vol.9

昨日入手して、帰りのロマンスカーの中でさらっと読んだ。結構細かい部分もあって、今さっき全般的に再読。

内容で濃いと思ったのが「続 ソフトウェアテストヒストリー 日本編」。”続”っていっても、先号は海外の情報だったので、日本の話としては初めて。また、ソフトウェアテストが多少中心だけど、ソフトウェア全般の話と考えても良い。「ソフトウェア」を”紙もの”/”やわもの”と呼んだ(呼ぼうとした)時期があったけど、その逸話などのエピソードがいくつか書かれている。

「ソフトウェアテストヒストリー 日本編」で良いな~と思ったのは、歴史年表に、大きなシステムとかテスト関係書籍やコミュニティ、企業の技報の類も書かれている点かな。コミュニティや技報って、俯瞰的な記載は余り目にしない。(ただし、技報は、東芝、日立、富士通、NECのみ)

文献一覧は結構細かい。「えっ、○○の本にソフトウェアテストって書かれてたんだ」みたいな驚きも少なくない。こんな時には、雑誌Bitの、ネット上の本文検索があればと思うのは私だけだろうか。


他に、コンテキストを利用した意味ネットワークと称した品質担当者とテスト担当者の違いもあり、参考になった。ただし、こちらは私の理解が足りない。機会あったら、コンテキストを利用した意味ネットワークについて詳しく聞いてみるつもり。(1度短時間で聞いた気もするけど、理解できてない。)

10月 18, 2009 ソフトウェア, 書籍・雑誌 | | コメント (0) | トラックバック (0)

2009年10月16日 (金)

SLCP 2007第2版での保守プロセス関連追記

依頼してた表題の本が、今日届いた。「共通フレーム2007 第2版」。ソフトウェアライフサイクルプロセス。

昼読んだ時に、初版との違いがすぐに分かるかと思ったけど、そうでもなかった。近くに初版の体系の図があったので比較して、「ドメインの設計」辺りの表記の違いが分かった程度。

ただし、巻末の図が増えた気がしたが自信なし。それで自宅で調査。第2版で、巻末の図として”図5-6 保守プロセスを中心とした,問題解決に関係するプロセス連関図”が追加されていた。また本文の方に、それに関するセッションとして、第5部に”4.”が追加されている。保守プロセスに、いろんなパターン(”ルート”と呼ぶ)があり、それと他のプロセスとの関連を示している。パターン(ルート)としては、事業見直しのようなケース、OSパッチによる変更、、、。

#個人的には、連関図が、QC 連関図での深掘りということでは余り似てないので、ちょっと違和感はある。

なお、保守は、情報システム部門での作業との視点での記載である。ベンダー側の保守開発部門担当の人からは、多少意見あるかもしれない。また今回上記で追加されたペース数も、さほどでもない。

そうはいっても、保守プロセスでの実際の状況が、規格に近いレベルで多少なりとも整理されたのは良いことと思うが、いかが?

10月 16, 2009 ソフトウェア | | コメント (0) | トラックバック (0)

2009年10月 4日 (日)

「単体テスト」は、テストチームのメイン作業じゃないだろうに

結構、同意したブログ記事。

単体テストはQAのためのものか

時期的には書かれた頃にすぐに読んで、「そうだよな~」と思っていたもの。ついつい、こちらに書くのが遅くなっちゃった。

念のためだけど、ここでの単体テストって、ISTQB/JSTQBでの”コンポーネントテスト”のこと。

そんなテストは、本来設計がやるべきもの。そこまでテストチームがやるんなら、「設計って何やってるの?」って皆が言いそう。例えば、ソフトウェア技術者になりたい学生とかも、疑問になるだろう。

ペアプログラミングの担当だって、基本は設計者。それとコンポーネントテストとは、ちょっとしか違わない。ソースコードレビューに、テストチームを含めて効率が良いとは思えない。テストして問題あったら直すのが目的と考えれば、コンポーネントテストもペアプログラミングもソースコードレビューも手段としては同類。その中心は設計だろう。

もちろん、”コンポーネントテスト”という用語や手法は知っていた方が良いけど、それをQAなりテストチームがやるべき前提と考える点はおかしい。


そのブログに、「単体テストはQAのためのものではなくなっているのでは」って書いてあるけど、もしQAのためと今まで思っていたら、QAとしてちゃんとコンポーネントテストをするための工数とか、その網羅率とか測っているんだろうか、、、。今まで、そうしてきたんだろうか? (もちろん、結構成熟した組織で設計内のテストというかサポートとしてコンポーネントテストを実施するところがあるのは知ってるけど、それが一般的に所属としてのQAというケースは少ないだろう。)


ちなみに、海外の場合にQAチームが別組織で、そこが結構コンポーネントテストを実施するケースが少なくないのは知ってる。でもその件と、日本の実情なり今まではと違うと言える。

10月 4, 2009 ソフトウェア, 品質 | | コメント (0) | トラックバック (0)

2009年9月19日 (土)

組込み業界 ISO取得の頃が良かったかな

一昨日のPM学会の懇親会とか、他のコミュの懇親会や飲み会などで会話しながら思ったこと、、、。

PM学会って、業種的にはIT系の発表がほとんど。自分がソフトウェア系統に、ついつい目が行くせいかもしれないが。モチベーションなど業界に関係しない話はあったけど、エンジ系の話はめっきり減ってしまった印象。

さらに言えば、組込み系は皆無。もちろん企業名からしたら組込みやってるところも少なくないけど、組込み自体がテーマにはなってない。結構違和感あり。というか、PM手法とかを取り入れないんだろうかとの疑問がわく。


ふと思うに、ISO9000の取得の頃は、結構ハード屋さんと品質系のメンバーでプロセス改善をやっていたように思う。ただし、プロセス改善と言うよりも、ドキュメント作成とか整理に追われ、それが反発になった。また、CMM・CMMIの方はソフト屋オンリー。そっちはそっちで、レベル2などの取得が精一杯で、レベル2に書いてない事項(特にレビュー)なんて無視。そもそも、プロセス改善っていう視点での活動でないから、取得後は元の木阿弥。(正確には、用語としては取得とかじゃないけどね。)

組込みのソフト屋って、プロジェクト遂行という視点では、制限だらけ。全体リーダーじゃないから、お金や人をコントロールできない。ましてや期限なんて、口すら挟めない。なので、問題の解決方法は非常に狭まる。商品化のためにプロセス改善という言葉は出るけど、改善という言葉だけで、お金と人をもらえなければ、商品化への問題対応はできない。

そもそも、マイコンチップが出た頃から、ハード屋さんは考えることを放棄しだした。機能がソフトで実現されるのに、ハード屋さんがその機能を説明したりドキュメント化することを避けてきた。そのくせに、機能要求の列挙というかオウム返しは得意。実現したい機能を、ハード回路で実現するための工数把握とか図面を書く事はない。そのくせ、リーダーは彼ら。スケジュールの遅延が、機能決定が曖昧だったという視点や反省にはならない。ソフト屋のせいにしてた方が、保身になるから。(そこまでは言いすぎのケースもあろうけど、、、。)


PM手法とかが結構浸透している今、組込み系も少し考え直した方が良い。要求分析までハード屋さんがやるべきとまでは言わないとしても、PM手法くらいは知識として備えて欲しい。そしてプロセス改善というか商品化上での改善に対して主体的に動くべきなんじゃないだろうか。また、組込みソフトの人たちも、もう少し全体最適の視点を養ったり交渉すべきだろう。

PM学会の後、ふとそんなこと思った。

9月 19, 2009 ソフトウェア, プロジェクトマネジメント, プロジェクト管理 | | コメント (0) | トラックバック (0)

2009年9月16日 (水)

JSTQBのアドバンストレベルは、開発者も読んで欲しい

正確には、ISTQBのアドバンストレベルの日本語訳のこと。以下のJSTQBのサイトにある。(本来はトップからどうぞ)

JSTQBのシラバス(学習事項)・用語集

ご存じだろうけど、ISTQBは「International Software Testing Qualifications Board」で、JSTQBは日本での加盟組織。ソフトウェアテスト技術者資格認定の運営組織である。

日本語訳として既にファンデーションレベルはあったけど、今回アドバンストレベルの訳が公開された。

結構ソフトウェアテストでの管理関係が書かれていて、参考になる。なお、個人的に非常に良いと思ったのは「15.1 現場への適用のための推奨事項 」。テストの作業効率に悪影響をおよぼす事項を掲示している。30個近い。

例えば、、、。
・機能テストに偏ったテスト計画を策定する
・ドキュメントをテストしない

個人的には、本来ソフトウェアの品質は、そのプロジェクトの長や設計/開発者が保証すべきものと考える。少なくとも、テストチームとの”連携”という意識は必要。上記の例で言えば、開発者などはテスト計画を見て、非機能テスト(非機能要件のテスト)があるかの確認や、ドキュメントのテストをテストチームが行うようになっているかの確認が必要である。テストの工数として、それらも予定に入れておくべきである。

なお、「現場への適用のための推奨事項」の悪影響排除をテストチーム以外(特に設計/開発)の協力の下に行うことや、その製品やプロジェクトでは無視できるとの判断もあろう。しかし大事な点は、それらを計画時に検討したり、作業分担の検討やその合意を取ること。


以下のような項目もある。
・全てのテストを自動化しようとする

他にも類似する項目があるが、ちょっとしたソフトウェアテストの本や講演をかじって全部に適用しようとするケースが少なくないと思える。そのために失敗とか作業のやり直し。あるいは、プロジェクトそのものの再構築になることすら発生しているように聞く。テストチームからの提言が上辺だけのものになっていないかの確認としても、本「現場への適用のための推奨事項」の部分は役立つと思う。


なお、個人的に引っかかるのが「システム統合テスト」。P25で、ファンデーションレベルでの追加のテストレベルとして記載してある。しかし、ファンデーションレベルでのP21に「システム統合テスト」は明記してある。少し細かいかもしれないが、従来での”単体テスト”が、実際はISTQBで言うところの装置のシステムテストに該当したりするケースが多い。そのため、「システム統合テスト」という用語は浸透しておくべきと考える。つまり、「システム統合テスト」は、ファンデーションレベルでの必須用語としておくべきと考える。


ちなみに個人的には、本訳に掲載されているIEEE 1044をちゃんと押さえてないような気がする。持ってたか??? 時間見つけて確認するつもり。

9月 16, 2009 ソフトウェア, 品質 | | コメント (0) | トラックバック (0)

品質と”かわいさ”と、どっちが大事?

先週でのちょっとしたニュースは、ビデオ機能付きのiPod nano。そして脇的になったニュースが、iPhone OSやiTunesの新しいバージョン。

iPod nanoとの対比を色々読んだりしたけど、ハードを比較する時代じゃないと思う。iTunes経由のダウンロードとか、App Storeを含めての比較をしないと。(さらに言えば、iPhonとiPod TouchはMacベース。普通の日本企業なら事業部とかが異なっているのに、ベースを共通にしている状況。他には、「アップル品質認定の整備済製品」なる制度もあるそうな。この辺りの風土も考えないと。)

あと目にしたのが、iPhone 新OSの不具合というか使いにくくなったなどの意見。実は、おいらも(ビデオ付きの方じゃないけど)iPod nano利用者。音楽聴きながらメモ見れるなど、並列的な処理を行える。ゲームも同時にできたような気もする。なので、結構ハングアップ。電源再Onで対応。(なのでは、変かもしれないけど。)


そんなこともあって、今日たまたま“軽~く一杯”でお店に行く途中で質問。もし我々が、アップルの品質部門だったら、「出荷OKにするかな~?」。

おいらも含めて、知り合いにiPodやiPhonユーザは少なくない。ハングアップは、まっ常識。そんな知り合いで、ソフトウェア品質とかソフトウェアプロセス、プロジェクトマネジメントに携わっている人も多い。そのため、ちょっと意地悪い質問が、先ほどのOKにするかとの問い。


道すがらだったから突っ込んだ議論にはならなかったけど、同じ認識だったのは「可愛いから、許せちゃうのかな~」。Macでの爆弾マークの可愛さにも通じるだろう。

でも、ある意味ではOKとするかの答えじゃない。答えにするには、「可愛さ」の尺度を考えたり、それと品質(バグやテスト網羅性)を比較しないといけない。あるいは、ユーザー自身が欲しているものや優先順位なども考える必要がある。


携帯じゃないけど、音楽プレーヤー等も海外製品(iPodやiPhon)が、非ガラパゴスなのかもしれない。「可愛さ」も含めて、品質って何だろうかとか、世界との競争でどうあるべきかを考える必要があるのかな~と思った次第。

9月 16, 2009 ソフトウェア, 品質 | | コメント (0) | トラックバック (0)

2009年9月 8日 (火)

P-CMMって、国によっては人気あるのかな

ネットで調べ物してたら、”P-CMM”(People CMM 人材開発能力成熟度モデル)の文字。余り意識してなかったけど、中国の会社のNeusoftでは、ML3認定者が既に15000名とか。

詳しく調べたら、左のような本も既に出てたみたい。アマゾンのレビューでは好意的な事も書いてある。

でも、どうも個人的には、CMMとかCMMIの具現化というか教育形態は好きになれない。基本的な考えには、共鳴するんだが。そもそも、CMM→CMMIへの手当が皆無というのが、、、。しかも、一時的にCMMを認証取得したのに、改善を(CMM以外でも)継続しないところが多すぎと思える。

#あっ、もちろん、正確には認証とかじゃ無いんだけどね。

P-CMMの取得者数で、その会社の技術レベルの判断材料とするのもどうかと思う。ついつい、日本人の感覚では、情報処理試験のような技術的な知識レベルとか知識分野の方で、判断したいと思える。また、P-CMMのそれなりのレベルの人達の開発プロセスをどうするかは、また別の問題と言える。PSPとかTSPのプロセスにするには、(多分大抵の日本企業には)難しいことが多すぎ。


ただ、12000人というのは、すごい数。全社的に教育を受けさせているところには敬服する。少なくとも、オフショア開発を依頼するとき、会社によってはそんなレベルの所があるという認識は必要そうだ。

9月 8, 2009 ソフトウェア | | コメント (0) | トラックバック (0)

2009年9月 4日 (金)

SPRINGAM関連の話を聞けるとは

今日は、某コミュニティでの勉強会。ソフトウェアでの重大事故の未然防止に関するもの。

で、説明の際に「SPRINGAM」がちらっと出た。実は、2,3ヶ月の間、ちょっと気にしていたもの。というのも、「SPRINGAM」は、ある日本企業での生産標準(開発方法論)で、ISOとかPMBOKも取り込んでいるイメージがあった。また、その会社では、CMMI レベル5達成を認められている部門もある。ISOやCMMI、そしてPMBOKを統合していると思え、気になる点がいくつかあった。また、SLCP(ソフトウェアライフサイクルプロセス)の扱いも気になっていた。

今回の講演でのQ&Aの際に、多少ぶっきらぼうな質問もあり、「えっ~、恐れ多くも、レベル5を認めてもらえるような所なんだから、頭下げて聞くくらいが良いのに~」とか思ったりした。説明の人が、まだまだ改善の余地があると丁寧な話し方だったからかもしれない。(この辺りが優秀な人の所以。レベル5取って高飛車な連中もいる。)

なお念のためだけど、今回のコミュニティにはCMMIのレベルを認めてもらった企業はいくつかあるし、今日もレベル5を認めてもらった会社のメンバーがいた。


今日の講演の題目とか説明者をちゃんと読んどけば、SPRINGAMと関連ありかもと思えたんだけど、ちゃんと読んでおかなかった。逆にそのために、今回の講演が非常にラッキーに思えた。懇親会でも色々話を聞けて良かった。SPRINGAMそのものの話は聞けなかったけど、雰囲気としてはSPRINGAMを統合したプロセスとして構築したというよりも、ISOなどを取り込む格好にしたとの理解が良さそう。意地悪い言い方だけど、部分部分の改良。(逆に、そうできると言うことは、骨幹は結構シンプルなんだと思う。)

レベル5取っても予防活動するところがすごい。もちろん、レベル取得って全部門じゃないから、横展開なども必要なんだけど、、、、。信頼性向上のためには、常に問題意識と改善活動が重要と思った一日だった。

9月 4, 2009 ソフトウェア, 品質 | | コメント (0) | トラックバック (0)

2009年8月26日 (水)

勝手にソフトウェア保守開発 「もはやCMMIは時代遅れ(CISQ)」

ブログ「勝手にソフトウェア保守開発」から。

SEI自体が主張している訳じゃないけど、SEIの動向としては分からなくはない。というのも、CMM出してしばらくしたら、CMMI。PSPやTSPとかも出している。個人的にあまり好きになれないのが、それぞれ教育費用が馬鹿にならないこと。CMMI、PSP、TSPそれぞれに意義があるというんだけど、、、、。

CISQって、少し意識しとこうと思う。ISO/TS16949のような、調達とか管理的な側面もあるのかな~。

8月 26, 2009 ソフトウェア | | コメント (0) | トラックバック (0)

2009年8月19日 (水)

「Smarter Planet」は、IBMの商標

今日何気なく目についた日本IBMのページの下の方に書いてある文言。

”Smarter Planet”。地球がより賢く進化してくことを願うキャッチフレーズみたい。今度のIBMのチャレンジは、人間並みに、クイズにチャレンジするコンピュータ。何年か先だろうけど、ちょっと楽しみ。その意味では、”賢く進化”してると思う。でも、なんか紛争とかを目にすると、そんなに進化してるようにも思えない、、、、。

ただ、気になっているのは、それを商標にしてしまうこと。なんか良いのかな~という気がしないでもない。

8月 19, 2009 ソフトウェア, 経済・政治・国際 | | コメント (0) | トラックバック (0)

2009年8月14日 (金)

「JSTQB」の試験対策用ブログ

ひょんな事で発見。「JSTQB回帰試験」という名前。

http://degrade.seesaa.net/

丁寧な作りです。プロフィールを見つけようとしたけど、無いみたいです。

2009年06月09日の記事に関しては、謙虚に受け止めました。

8月 14, 2009 ソフトウェア, 組み合わせテスト | | コメント (0) | トラックバック (0)

2009年7月31日 (金)

ソフトウェア開発での準委任契約

ソフトウェア開発で知っておくべき法律としては、請負等の外注管理関係と特許関係だろう。で、昨今、前者もちょっと厄介になってきた。偽装請負などがニュースになるのも理由だろう。かといってソフトウェア開発の場合、バグ無しを証明できるかといった学術的な事項、バグ無しの検収、改良の場合の元ソースバグとの関係など、いろんな事が複雑に絡んではいる。

一般的には、請負契約により納品後1年間のバグは無償保証のケースが多そうだ。じゃ1年を超えたら、、、。派遣利用の場合は、1年を超えたらというか納入後をどう考えるか、、、。さらに厄介なのは、仕様変更。基本仕様の変更でなくても、細部の変更は良くある話である。


で、アジャイル開発系の場合は、”準委任契約”のケースが良さそうとの話が多いと思う。その関連で参考になったのが以下。日経コンピュータでも記事になったように思う。(ちなみに以下のページは2ページ目)

要件未定でも納期は厳守 “アジャイル開発”で乗り切る

このページが良いのは、”準委任契約”の明言もだが、アジャイルでの開発での課題とその克服が書かれている点。ITシステム構築としても参考になると言える。


開発サイドが”準委任契約”に踏み切れないのは、自らがソースコードに責任を持つ必要があるため。極端には、”準委任契約”は、バグがあっても委託先にその責はないからだ。

ただ、昨今のように改良開発や派生開発が続く場合は、発注側がソースコードに責任を持つとか、ソースコードの構造やロジックについては理解している方が全体効率は高いはず。セキュリティ対策とか保守開発でも大同小異ではないだろうか。

”準委任契約”の長所と短所などは、押さえておいた方が良いだろう。また、身近で”準委任契約”をやっていなかった場合、お試し的に実施してみるのも価値があるかもしれない。

7月 31, 2009 ソフトウェア | | コメント (0) | トラックバック (0)

2009年7月27日 (月)

Google ノートブック スクロールの動作変更?

結構、Google ノートブックは重宝してるけど、土日に「あれっ」と思うことが。今までだと、バーでスクロールさせようとすると、結構先(最後)の方まで読み込もうとしてた。そのため、処理時間がかかることが少なくなかった。逆に、結構何件もノートブックに記録させても、後の方まで行き着きやすかった。

ところが、土日には、20件ごとしかスクロールしない。そのため、結構件数が多いと何度もクリックが必要となった。Cntl+Endで移動させようとしても、例えば500件もあれば20数回のクリックとか操作が必要。

最初、ノートブックの設定にあるのかとか自分の特定PCだけかと思った。今日もいくつか操作しても同様。つまり、ノートブックそのものが変わったみたい。

iGoogleもタブ形式が変わったりしたけど、なんかどっかに変わった旨があると良いな~。結構面食らう。ノートブックの件は一長一短。でも、iGoogleの新タブ形式は、どうもメリット感じない。

7月 27, 2009 ソフトウェア, パソコン・インターネット | | コメント (0) | トラックバック (0)

2009年7月 2日 (木)

iPhone フリック入力と税務対応サービス

今日は、iPhone関係で、結構勉強になった。

まずは「フリック入力」という入力方法。携帯電話だと、”あ”の所を何度か押して、”い”とか”う”にするけど、iPhoneだと、一度押した後で指を離す際に4方向にずらすことで”い”とか”う”を入力出来るのだという。その様子の動画も、色々アップされている。

また、「フリック入力」での特許性自体も、ネット上で話題となっている。

もう一つは、ITproでのiPhoneショック2の記事。「開発者はアップルにあらかじめ税務上の書類を提出しておけば,製品名や価格などの必要な情報を入力してマウスでボタンをクリックするだけで,すぐさま世界60カ国以上でアプリケーションの販売をすることができる。」というもの。

iPhoneでの、画像とか動画、そして色んなアプリの販売が出始めた。時々、「何これ~」というような奇抜なものも。 App Storeのことは少し知ってはいたが、各国の税務まで考えてのシステムだとは思わなかった。ソフト開発者にとってはグローバルな営業が出来るわけで、願ったりかなったり。


実は、iPodとかは気になって、色々注意はしてた。自分自身の認識としては、iPodの商品化は外部コンサルに依存してたと思ってた。そのコンサルも、アップルを離れたと聞いた気がする。

どうもITproでのそれを読むと、App Storeはアップル自らのシステム開発か、少なくともiPodでの外部コンサルによるシステム開発ではなさそう。つまり、iTuneとかApp Storeのシステム自体が、アップルの強みなのかなと思えてきた。そう考えると、次にアップルは何を指向するか、少し見えてきそう。

7月 2, 2009 ソフトウェア, テクノロジー, パソコン・インターネット | | コメント (0) | トラックバック (0)

2009年7月 1日 (水)

「まつもとゆきひろ」氏と「丸岡孝司」氏による講演

そう言えば、自分のブログに書いてませんでした。今度の11日土曜日に、「まつもとゆきひろ」氏と「丸岡孝司」氏を招いての講演会(ホットセッション)を開催します。若手のソフトウェア技術者を、主な対象としたもの。ライトニングトークスも予定しています。もちろん、非若手の参加もOKですよ。^.^;

S-open(ソフトウェア技術者ネットワーク)の主催。実は私は、今回の本ホットセッションの幹事の一人を担当してます。

http://www.s-open.net/

ちなみに、ブログは以下。ただ、ちょっと内容が少ないかな。

http://hs31-s-open.blogspot.com/

今週と来週は、この準備で少し忙しくなりそうです。しかも来週は、講座の講師とか昔の職場の人達との宴会もあるので、今週準備できる部分は準備しとこうと思います。

7月 1, 2009 ソフトウェア | | コメント (0) | トラックバック (0)

2009年5月27日 (水)

PMBOK 第4版日本語版 うーん色合いが、、、

PMBOK 第4版日本語版がアマゾンで予約可能になった。結構予約注文が入っているみたい。

やっと。それにしても、詳細説明部分の言語は英語になっているなど、アマゾンの方もバタバタしている感じ。


しかし、最初表紙の写真見て、「えっ~」。ちょっと、センスが足りないような。以下のような歴代smilePMBOKを並べると明確だと思う。

http://www.amazon.co.jp/exec/obidos/search-handle-url?_encoding=UTF8&search-type=ss&index=books-us&field-author=Project%20Management%20Institute

単に、見慣れてないせいかな~~。

また少し値段が上がっちゃった。ちなみに、今のところ、アマゾンでの日本語版のページ数記載は無い。

まっ、多分どのみち買うと思うけど、、、、。

5月 27, 2009 ソフトウェア, プロジェクトマネジメント, プロジェクト管理 | | コメント (0) | トラックバック (0)

2009年5月18日 (月)

Google検索ボックスでの意図しない文字列はPCによる???

ここ1月くらい、Googleの検索ボックスに日本語入れた時に、変な文字が出てくることがあった。かな漢字変換の途中のような文字列がいくつか。しかも、Delキーですぐに消せない。Delキーで消そうとしても、また出てきたり、結局1文字位しか消せなかったり、、。いつも起きる訳じゃないけど、起きたら結構イライラ。

かな漢字はATOKで、その関係かなと思いながらも、調べる時間が余りなかったのでそのままにしてた。今日ふとGoogleでのクエリ候補の表示が関係するかもと思い、候補を非表示にした。(Googleの検索ボックス脇の”表示設定”→一番下) 今のところ、それで対策になっている感じ。

よくよく考えたら、一番パフォーマンスの悪い(古い)PCでしか起きていないようだ。クエリ候補を表示しているPCでも、意図しない文字が出ることがない。そのために、現象を絞り込めないと感じて先延ばししてた。

少し安心。しばらくこれで様子見。

5月 18, 2009 ソフトウェア, パソコン・インターネット | | コメント (0) | トラックバック (0)

2009年5月14日 (木)

Day2プロジェクトでの「統合丸」旗

Day2プロジェクト(三菱東京UFJ銀行のシステム統合プロジェクト)遂行のやり方などの話が、ぽつりぽつりと出だした。ご存じのように、11万人月という超巨大規模のプロジェクト。

日経コンピュータでは、記事やセミナーも。なお、本セミナーを含め、今はどちらかというと銀行側の話が多いけど、しばらくするとソフトウェア開発側の話も出てくるだろう。

で、そのセミナーの紹介文を見て結構好感持ったのが、”統合丸”っていう旗。セミナーの案内での下の方。念のためだけど、この写真の旗は、大漁旗と言わないと思う。

こんな旗を作ると値段はいくらくらいか、ネットで調べた。思った以上に業者がヒットした。プリントするタイプから、染めるタイプまで。各自の価値観にもよるだろうけど、メンバーの一体感のためには、安く上がると言える。というか、そもそもこんな旗を作ろうとか、旗のデザインをメンバーでやる様なところは、プロジェクトはうまく行くと思う。

もちろん、”うまく行く”って、100%当初の期間通りとか予算から1円も外れないのを言うと定義すれば別だけど。そもそも、そんな定義はナンセンスとか、ある程度の許容範囲を持たすべき。また、本プロジェクトでは条件が絡んで引き出せないことも発生した。マスコミが書いたけど。欠陥が発生したら”うまく行かなかった”というのも、考え物。

プロジェクトのチーム形成の時に、”旗”作成も検討の一つとしたら良いと思った。

5月 14, 2009 ソフトウェア, プロジェクトマネジメント, プロジェクト管理 | | コメント (0) | トラックバック (0)

2009年3月 9日 (月)

朝鮮日報「ソフトウェア至上主義」

いろんなネットニュース購読とかGoogleアラートでの設定をしてると、意外な”ネタ”が入ってくることがある。今日、勉強になったのが、朝鮮日報「【コラム】ソフトウェア至上主義」。もちろん、このサイトは日本語のもの。

サムスン電子が、赤字。しかも創業以来初、というのは、ちょっと知らなくて驚きだった。しかし、それよりも、本コラムの視点が小気味良い。「黒字を出した企業はソフトウェア企業だったり、ハードウェア製品を生産していながらも、ソフトウェア的な能力が優れている」というくだりなどは特に。

最近、別日記に書いたことと関連するけど、少しハード屋さんを目の敵にするとか、対立的な思考が良いと感じるようになっている。自分がリーダ的なプロジェクトでは、結構能力あったり良い人が多かったので、余り目の敵にすることはなかったんだけど、世の中そんな人ばかりじゃないみたい。しかも、今回の不況。自動車と電気(電機)が抜本的に異なること考えると、トレンドなり考え方を変えないと、赤字を脱却できないかもしれない。

本コラムでは「依然として製造技術の競争力に基盤を置く韓国企業にとっては、致命的といえるだろう。」と結んでいる。韓国→日本と言い換えても同様だ。さらに言えば、日本の新聞で、こんな事を書ける人って、ほんの一握り? 政治のゴシップ探しとか、微細トラブル大騒ぎにエネルギー使い過ぎている。政治のゴシップに荷担すらするんだから呆れる。その辺りも、日本の課題なんだろう。

3月 9, 2009 ソフトウェア, 新聞 | | コメント (0) | トラックバック (0)

2009年2月16日 (月)

ソフトウェア・メインテナンス研究会

今日とあるコミュニティの会合があって、その後に飲み会。で、保守開発に興味持ってる人がいました。自分で、ブログにしているそうです。「勝手にソフトウェア保守開発 」

http://soft-mainte.blogspot.com/

ソフトウェア・メインテナンス研究会(SMSG)なる団体もあるそうです。
http://www.smsg.or.jp/


後者は、参加のための料金が少し高価。あくまで、他の団体の参加もある私としての感覚。でも、SMSGのページには結構情報が整理されており、貴重。今後勉強させてもらおうと思っています。

2月 16, 2009 ソフトウェア, 派生開発、保守開発、改良開発 | | コメント (0) | トラックバック (0)

2009年2月 8日 (日)

ATOK 2009 購入

Office2007を入れて、IME2007になってしまった。遅いとか変換がおかしくて、古いIMEに設定して利用してた。それでも、結構ストレス溜まることが少なくなかった。単語登録すれば済むというレベルじゃないし、とにかくイライラ感が嫌。

と言うことで、ATOKを2,3週間前からお試しダウンロードして利用してた。ATOK2009が6日発売と言うことで、昨日購入。土曜日で用事があったけど、ヨドバシが9時半から開いていたので、利用した。

キーアサインや設定で、デフォルトから変更した方がいいのが結構ある。特にカナキー入力しない点とか、英字や仮名も候補にしておきたい点。

これで、ストレスというか血圧少し下がるだろう。

2月 8, 2009 ソフトウェア | | コメント (0) | トラックバック (0)

2009年1月31日 (土)

Googleさん ノートブックは続けてネ

直近での悩ましいニュースは、Googleのノートブック新規開発中止。しかも先だって、何かの拍子にノートブックの1つをゴミ箱に。復元で、各メモを戻そうとして途中でホームページ移動。すると、ゴミ箱に、残りのメモが残ってない。がーん。そのため、ますますノートブックの代わりを物色。


『Zoho』も『Evernote』も、Googleノートブックからインポート可能に
 みたいな記事もあったので、調査。Zohoのアカウントはあるし、Evernoteは新規登録。

でもどちらも、こっちの使い勝手からしたら今一。簡単にテキストベース主体でいいので記憶させたい。タイトルというかセクションも作りたいし、別のノートブックやセクションへの移動も操作しやすい方がいい。後レスポンスタイムも。

ZohoもEvernoteも面白い機能はあるんだけど、上のような使い方だと、使ってみてピンと来ない。と言うことで、当面ノートブックを利用することに。Googleが、しばらくノートブックサービスを継続することを祈りつつ。(時計ガジェットのことがあるので、ちょっと不安。)

ノートブックサービス廃止を前提に考えてみた。Googleのブックマークのエクスポートがラベル単位に出来れば、そこそこ使えるんだけど、、、。とにかく、自分のノートブックやブックマークの量が多すぎるので一筋縄では行かない。いつか見直さないと行けないとは思うんだけど、情報整理まで考えると時間がないな。

ネットサービス利用するけど、最近は今回のようなことなど含めて、不安になってきている。うーん、、、、。

1月 31, 2009 ソフトウェア, パソコン・インターネット | | コメント (0) | トラックバック (0)

2009年1月 1日 (木)

読売新聞 元旦のスクープ 「生体認証」突破して入国

今日元旦の新聞。特集的な記事が多い中で、読売新聞は異彩。入国審査時の指紋照合で偽装して、不法に再入国していたことが判明したというもの。

テープの利用ということで、本人確認の生体認証(バイオ)の、もろい一面が出たことにもなった。

なんか、今年の情報関連での大きなテーマを与えられた気がしてならない。性悪説とかを前提とした設計とか、いくつかのゲートを用意する必要があるということ。ふ~~。

元旦で、のんびりTV見てて、紙面一覧のようなコーナーだったかで紹介された。気になったので、その後コンビニまで行って新聞購入。他の新聞も買って、改めて元旦の新聞は分厚いなーとも感じた。

1月 1, 2009 ソフトウェア, テクノロジー, 品質, 安心・安全, 新聞, 科学技術 | | コメント (0) | トラックバック (0)

2008年12月24日 (水)

「派生開発」「保守開発」「改良開発」

あるコミュニティで、プロジェクト管理の話が出て、「保守作業は?」との反応。結構微妙だけど、一般論としてプロジェクト管理(の現行体系)では、それらを含めない。ただし、今もだし、特に今後は大きな課題。

ソフトウェアの従事する人の多くは、保守作業。また開発とか設計も、不景気な昨今では、新規開発よりも、一部手直しが増えてくる。また、時代が変わっているので、それに応じて機器やシステムの変更も必要になってくる。反応速度とか処理能力(人数、データサイズ、言語種)、場合によっては入力方法とか見栄えの変更も必要になるかもしれない。

一部手直しって、直すとか修正する部分は小さくても、その影響分析方法とか、テスト工数の見積もりが確定しているとは言い難い。そのため、個人的にも気になっていたテーマ。そこで、いい機会と思って、再勉強とか整理してみた。

1)本屋で見かけて買った本。「~ISO14764による~ ソフトウェア保守開発」。これ良い。分かりやすくて。

2)上の本の規格はJISになっている。そのJISも注文して、今日届いた。X 0161。さほど高くないので、細部を知るには良い。(ISO14764も規格協会で買えるけど、めちゃくちゃ高い。)

3)購読している雑誌「IT Leaders」のコラムに、少し触れられていた。JUASのソフトウェアメトリクス調査2008からの引用。システム保守は、5年間でおよそ開発費用と同じ額がかかる。(実感としても、メンテナンス料金との関係で、妥当に思える。メンテナンス料金ととらずに保守するから話が変。というか、バグ多すぎななのにカットオーバーするから話が厄介かな、、、。)


他では、清水吉男さんの派生開発の本がある。SECの派生開発での見積もりの本も、ある程度参考になると思う。(保守に限定してないところが、興味ある/ないが分かれるかも知れない。)


いずれにしろ、このあたりを議論していかないと、短い工数での派生開発とか保守開発→バグとかトラブルの発生になってしまう。

12月 24, 2008 ソフトウェア, テクノロジー | | コメント (0) | トラックバック (0)

2008年12月20日 (土)

またまた自動車業界 今度はモデル記述規定

またまた自動車業界がやってくれました。モデル記述のガイドライン。

JMAAB (Japan MATLAB Automotive Advisory Board)

MATLAB/Simulink記述ガイドラインのV2.1が出来、しかも日本語版もあるとのことで、アクセス。ダウンロードしてみてみた。

まー、結構面白いとか参考になる規定もある。明確な定数の記述とか、図の書き方のルールとか。

MISRAもそうだけど、なんか羨ましい。そんな規定を決めて、業界として効率のいい開発とか設計を行うという姿勢や、その外部への発信が。 MATLAB/Simulinkレベルでのモデルを、ハード屋さんと議論する組込みソフトウェア技術屋がある分野では本来の姿かと思うんだけど、まだまだなんだろうな。(もちろん自動車業界以外でも、進んでいる会社とかはあるけど。)

12月 20, 2008 ソフトウェア, テクノロジー, 自動車 | | コメント (0) | トラックバック (0)

2008年12月 5日 (金)

iPod 暗記カード機にするには今一

資格取得とかPalm代換えのために色々考えて、結局iPodにすることにした。先週iPod nanoを買って、色々トライ。Palmのメモ帳とか、単語カード(コクヨのメモリボ)の代わりになればとの思い。

Palmは、もう後継機がどこからもでないし、今使っているCLIEも段々調子が悪くなってきた。コクヨのメモリボは、資格取得の勉強のためには、カードでの文字数が少なすぎ。他のモードでの利用も考えたけど、そのモードではデータ整理が大変。

iPod nanoでは、メモが出来るとか音声録音が出来るのが便利と思って買った。

しかし、、、、、。音声録音は良かったとしても、メモが駄目。メニューの文字サイズが3つだったか選択できるし、メモでhtmlが記述できるとのことで、文字サイズを指定できると思っていた。利用できるhtmlは、簡易なリンクとかタイトル程度で、文字サイズの指定不可。しかも、デフォルトの文字サイズが小さく、老眼には非常につらい。

また、どうもメモでのタイトルに長い文字列を設定すると文字化けが発生。類推だけど、ハンドシェークして無いんじゃないかと思うような化け方。

色々トライしたけど、結局暗記するのを録音する使い方が主に。まっ、ホイールでの選択とか音量調整が結構便利で、気にはいった。

何かの折に、iPod nanoのhtmlでの文字サイズ指定が可能になればいいんだけどな~。

12月 5, 2008 ソフトウェア, テクノロジー | | コメント (0) | トラックバック (0)

2008年11月17日 (月)

S-openホットセッション「今問われている非機能要件とは何か」

今日は、S-openのホットセッション「今問われている非機能要件とは何か」へ。 (URLは、最新のイベントなので、更新されてたらごめんなさい。)

実は、裏方としてのお手伝いもあったので、一日中かかりっきり。90名近くの参加だったと思う。裏方作業を省いて内容でのトピックは、、、。

非機能要件は、JUSAの「非機能要求仕様定義ガイドライン」を入手したりして、以前から興味ある事項。特に最近は、そのモデリングはどうしたらいいかが気になっていた。OCLなどで書いても限界あるしとか、従来の表記の延長で解答があるんだろうかとか、、。

今回の講演は、NTTデータの山本さん、SECの塚本さん、北陸先端大学の岸さん。ISO25000とかゴール指向、SECの取り組みなどの話など。岸さんは、組込み系の話が中心だったが、モデリングの話が出た。UMLのステレオタイプを利用した記述が行われているとのこと。どうもOMGにプロファイルがあり、そこが一番進んでいる様子。しばらく勉強してみようかと思う。また、”ミスユースケース”と呼ぶネガティブなシナリオを記載するためのアクターの表記(頭部を黒く塗りつぶす)を行うケースの紹介があった。

ゴール指向の再勉強も含めて、いいネタをもらった感じ。


11月 17, 2008 ソフトウェア | | コメント (0) | トラックバック (0)

2008年11月15日 (土)

技術士会+情報処理学会の「ソフトウェアテスト」

今日は、第2回技術士会情報工学部会と情報処理学会とのCPDのコラボレーションで、機械振興会館。

詳しくは、こちらを。

まずは、有澤誠先生の話で、1時間。実は、このお話を楽しみにしていた次第。有澤先生が、ソフトウェアテストに関して語るというのも珍しいはず。なお有澤誠先生は、今は慶応大学とのこと。

ちなみに案内で、「Roger Pressmanの教科書(第6版)」を元に解説すると書いてあった。前から、買おうかは悩んでいた本。(価値は認めてるんだけど、他の本の購入などもあって財政的な懸念で断念していた。) 今回のイベントが引き金になって購入へ。結構見ている本だったけど、職場の最寄り駅のちょっと大き目の本屋にない。会社の本屋さんに注文したら、13日入荷予定ということでちょっと微妙。キャンセルしてアマゾンに注文。でもそちらでも13日、しかも延びてしまい結局14日前日に届いた。教科書として使われているだろうから在庫はあると思っていたが、品薄? あるいは、こんな本も専門書として流通量が少ないのかも。

開始時刻ちょうどに到着したら、3つ席のテーブル、全テーブルが2つ席が埋まった状態。どこか間に入ろうか、最前列にしようか少し悩んでいたら、情報処理学会技術士委員会の知り合いが手招き。2列目の席で聞けた。

有澤先生の話は、ソフトウェアの包括的な話。時々KnuthのTexでのバグやテスト方法の話が出て、いわゆる一般的なソフトウェアテストの話と違うところと感じた。また、時々飛び出す昔(?)話が面白かった。電総研時代のデバッグというかレビューの体験談など。斉藤(信夫のこと?)さんや、山梨大学の頃の生徒の話。全社は、有澤さんがソースの事を説明するのを上の空のように聞いていたが、急に「そこもう一度」とか言われて見直したらバグがあったというもの。後者は、昔オブジェクトをカセットテープに記録した頃、そのテープを聞いておかしい所を言う人がいたというもの。どちらも、何故だかの明確な理由は分からないようだけど、、、。

Knuthは授業で問題出して、すぐに回答も用意していたとの話。ソースコードを読むのは5000行くらい(本一冊)が限界だろうとの話なども紹介された。


有澤先生の後が、ワークショップ。5つのグループに分かれて、ある仮想的な要求仕様書からテストケースを導くもの。ITSSのプロジェクトスキルマッチングシステムというもの。仕様書は、文、モデル図、インスタンス、シーケンス図など。

そのシステムの1部のテストだけど、サブシステム#1、#2、#3があるが、資料で番号の間違いがあることや、テスト範囲が#1のみである事が的確に伝わらなかったみたいで混乱。(我々の場合は、最初に皆で確認、講師にも確認したけど)

モデル図で、システムがある程度分かるはずなのに、駄目。同じグループに近い年代の人もいたけど、我々の世代だとそこまでモデル図に親しんで無いとのことを意味するので、ちょっと反省。

20081115165345
我々のグループは、技術士2名、ITコーディネータ1名、情報処理学会系(会社員)4名という構成だったはず。皆さんから、結構鋭い指摘がいくつかあった。ただし時間無くて、細部のテストケースにまで落とせなかった。正しくない社員番号などと書いて、具体的な値まで書けなかったというもの。また、本当はポストイットでの記載を整理してペン書きすべきだったけど、ポストイットの貼りなおしとか画面名をペン書きした程度。

ただ、結構全般的な視点での説明やテストの観点を整理したので、発表/講評では、もと慶応(今は帝京)の大岩先生から良い面を指摘された。少し恥ずかしかったけど。

講評で、結構辛らつな意見交換もあった。実は、その理由の1つに「単体テスト」の言葉の意味の取り違えもあったんだけど。総じて、技術士メンバーが多くの学会の人たちと交流する事は、良い事と感じた。新鮮だし、逆に、こちらも刺激を提示できるようにしたいもの。(概述の、モデル図に慣れておくべきは個人的な課題かな~と感じた。)


懇親会は、機械振興会館の地下。当然参加。有澤先生とも少しお話した。自分の出身学校での授業があったか確認したけど、大学院での1年間だったとのこと。先週から授業があったような気がして、同窓会MLに流したけど、勘違いと判明。どうも著者名とか、研究室の先生との共著の関係で間違っていたみたい。

あっ、懇親会での真面目なネタとしては、「組込みでのセンサーはアクターか?」というのがあった。半々かな。個人的には当然アクターになると思っていたら、不確実とか双方向性のやり取りがあるもののみをアクターにすべきとの意見があった。


その後も、(有志で)神谷町駅界隈で飲み会。そっちでの話も有意義。

11月 15, 2008 ソフトウェア, 技術士 | | コメント (0) | トラックバック (0)

2008年10月28日 (火)

本「定量的品質予測のススメ」

2週間ほど前に本屋で見かけて、その日は荷物が多かったので買うのを止めてたもの。会社の本屋に注文していて、今日入手。

ページ数が100ページ強と薄い。断片的には、知っている事が少なくない。また、日頃、○○をソフトウェア品質のメトリクスにしても良いかな~と考えているような事が詳細に記載されている部分もあった。レビューでの指摘件数などにページを割いてあり、結構小気味いい。そのため読みやすいし、実践する時には再度じっくり読めば良いと思える本。

個人的には、”尺度”に関して順序尺度などの説明があったりするので、メトリクスに関して基本的なことに理解度の確認にもなると考える。(てっ、ここのブログ読む人たちには、無用だろうけど。)

管理図での説明が多いのは、少し閉口。

逆に、プロジェクトマネジメントでの効率指数、SPI(スケジュール効率)とCPI(コスト効率)をX軸とY軸にして、時系列にプロットする図は、応用してみたい気がしている。株式などでの逆ウォッチ曲線みたいな感じ。ただし、当たり前だけど、逆ウォッチ曲線のような蛇行での判断では無く、どちらも1を下回ったら危険と判明するというもの。もちろん、実務的には1以下にするよりも、0.9以下とか0.75以下だと警告するような運用だろうけど。

サンプルデータも具体的で、実務とさほどかけ離れていない(と考える)ので、自組織での値との比較も面白いと思う。興味ある人はぜひ読んでみて。

10月 28, 2008 ソフトウェア, プロジェクトマネジメント, プロジェクト管理, 出荷判定, 書籍・雑誌 | | コメント (0) | トラックバック (0)

2008年10月18日 (土)

Googleの時計ガジェット元に戻して欲しいな~

今日の急がないといけない宿題は終わったので、ネット検索のついでにiGoogleの下の方も見てみた。

iGoogle自体は結構な頻度で見ているので、もしかしたら潜在的には気がついていたのかもしれないけど、、、。なんと(というと大袈裟か)、使ってた時計ガジェットが変わってた。以前には一般的な壁時計風。色合いなどが落ち着いていて好きなガジェット。それが、なんか少し幼稚(見方によっては斬新な現代風)な物に変わってた。

最初ブラウザが少し変になったのかとか思って、クリック詳細情報を見てみる。以前の時計の画像が出てて、掲示板に「元に戻して」などの文字。なんか急に変えたみたい。一応その詳細情報だと、25万人くらい使っている様子。

このあたりが、ネットサービスの不都合なところ。勝手に変えるんだもん。しかも、今回のは上書きして変更すべきじゃないと思う。別ガジェットにすべき。

クラウドコンピューティングの時代になったら(なりつつある今)、この類の話題はこれから増えてくるんだろうな。なるべくパッケージ化して、古いのも利用できるような構造にしていた方が良いという事なんだろうな~。

10月 18, 2008 ソフトウェア, パソコン・インターネット | | コメント (0) | トラックバック (0)

2008年10月 5日 (日)

「残す化」「活かす化」

”残す化”ってCMAP21's BEEMさんのブログに出てた。

何か、ここ1、2週間、もやもやしてたものが、言葉として具現化したって感じ。大切なデータが欠損していることがある。ここでのデータって、システムのデータというよりもプロセス資産のようなデータとかノウハウとか、、、。重要な資産データとかプロセスなのに存在しない。分析できない、というか分析が急に精度が悪くなったり、また初歩的な間違いの繰り返し。(例としては、直近のANAのシステムトラブルで、暗号の有効期限確認プロセスが残されていたら回避できたはず。)

端的なのは、ISOだCMMだと騒いで作った”プロセス”そのもの。何か文書作るのが目的になって、認証受けたら元のままに。有効なプロセスが、何も残ってない。そんな話は、結構聞く。

日本にマネジメント能力ないまま、人集めでオフショアを利用しようとしているところは悲惨との話も多そう。ソフトウェアのマネジメントのためのノウハウを、残してないのも要因。

逆に、デッドコード(どこからも呼ばれないソースコード部分)とかリンクされてないページとか、デジタルデータを置いたはいいけど活用されないケースも多い。ドキュメント化で、膨大に膨れ上がったデジタルドキュメントもそう。コピペ主体で、ファイル数だけが増える事すらある。本質的に残してない。見栄え良すぎのコンサルの資料とか、社内PPTも含まれそう。

ちなみに、ここでの「残す化」の残すものは、普通は形式知だろうけど、より発展させて暗黙知になれば言う事ない。(どっかに形式知があって、それは時々アクセスされる程度。でも皆の認識が合致している、そんなイメージ。)

CMAP21's BEEMさんのブログには書かれていないが、”活かす化”も重要だ。営業や工場では、売り上げとか生産台数とか欠陥度などを示している。何かソフトウェア開発とかソフトウェア系にはそれが少ない。(ニコニコカレンダーとかあるけどね)

「見える化、見える化」って言うのは良いけど、見えたものを活用しないと、、、。

考えてみれば、「見える化」なんて見栄えだけの話で、そのためのデータをどう残すかとか、残すためのプロセスやシステム化の確立の方が本当は重要だったはず。そして、その見えるようになったデータの活用方法を考えるべきだ。

BI(Business Intelligence)が多少キーワードになっているので、商品とかシステム化の仕組みも整ってきつつある。「要約」は、ソフトウェアでの新しい技術分野だし、ネットでは結構動き出してる。また、ソフトウェアのトレーサビリティに関する提案も行われようとしている。それらを使って、何を残すのかとか活用方法も十分考えるべきだ。アクセス頻度の情報を元に、不要なページとかファイルを探すのも有効だろう。ふと、そんな事思った。

10月 5, 2008 ソフトウェア, 技術, 残す化・活かす化, 科学技術 | | コメント (0) | トラックバック (0)

2008年8月22日 (金)

北京オリンピック 「ソフト、ソフト、、、」

朝、TVtvのニュース見てたら、北京オリンピックで日本のソフトボールチームが金メダルを取ったとか。そして、表彰式後?のシーンがあって、複数のチームがボールで”2016”の文字を作り、オリンピックでの種目復活へのアピール。

チャンネル回しながら見たシーンだったので、最初は何のことかわからなかった。メンバーのユニフォームの色が幾つかあるし、単にボールをいくつか並べるシーンだったので。ズームアウトして、”2016”の文字と解って、なるほど。事前打ち合わせなんてするわけないだろうから、表彰後の皆の気持ちが体現されたんだろう。

「良いシーンだな~」と思って、急いでEPGで放送見たら、NHK BSでやりそう。予約しておいた。で、さっき見たけど、その表彰後のシーンなし。うーん残念think

ネットニュースとか読むと、日本/アメリカ/オーストラリアのメダルチームでやったそうだ。朝のニュースでは、オーストラリアのユニフォームの色は目立っていたけど、この類ってアメリカのメンバーは参加するのかな~と思っていた程度。でも、皆でやったみたい。

で、「バック・ソフトボール、バック・ソフトボール、バック・ソフトボール、、、」と叫んでたそうだ。ニュースの時は、”ソフト”は聞き取れたけど、その他は曖昧。なので、「ソフト、ソフト、ソフト、、」と叫んでいたように聞き取れてしまった。

(ふと思いだしたのが、カード会社のCMで、国連のような国際会議で各国の通貨を叫ぶシーン。面白いのが、ユーロ。皆で肩を組んで「ユーロ、ユーロ、、」。)


「ソフト、ソフト、ソフト、、」と叫んでいたように聞き取れた事もあって、今日一日”ソフト!”って、何人かで鼓舞する事あるのかな~と思った。というのも、組込みソフトの場合、ハードのしわ寄せがソフトに来ることが少なくない。

例えば、以下のSECでの「プロジェクト責任者向け調査 報告書」のP169で、「ハードウェアの仕様変更によりソフトウェアを修正した」ことがあるとか「ハードウェアの不具合をソフトウェアで回避した」ことがあるのが、50%前後を占めている。(0.5って、50%のことだと思う。)

http://sec.ipa.go.jp/reports/20080715.html

中には軽微なものもあるかもしれないが、少なくないのは事実。で、講演などを聞くと、スケジュールでの月レベルに影響することが少なくないから困った問題。さらには、そもそも、企画とか基本スケジュールがハード設計の都合で決まってしまい、ソフトの実装とかその周辺のこと、そもそも実装実現性が無視されて決められることが多いみたい。

今や人数的には、ソフトの設計やテストの人員の方が多いはず。その割には、イニシアチブをとっていない。イニシアチブなんていうよりも、なんか意見すら無視されているてな感じかな~。もっとアピールすべきじゃないの~。そうしないと、日本のお家芸の組み込みソフトはすたれるばかりだと思う。品質関係もそうだし、若い情報系の学生から見向きされなくなる。

「もっと、アピールしたら~~」。 なんか、今日のシーン見ててそう思った。

ちなみに、個人的には、SECでの本設問に追加して、ソフトへの影響度を測ってもらえればと思う次第。「ハードウェアに起因したソフト実装での影響 人月」みたいな設問。人月とするのに、抵抗ある人がいるかもしれないけど。

8月 22, 2008 スポーツ, ソフトウェア, 品質 | | コメント (0) | トラックバック (0)

2008年8月18日 (月)

組み込み業界の携帯電話から自動車へのシフト

今日受けた技術関係のメルマガで面白かったのが、「組み込み業界が携帯電話から自動車にシフトし始めたのはなぜか?」。

http://techtarget.itmedia.co.jp/tt/news/0808/12/news01.html

結構ハード屋さんというかハード系の記者さんの記事。回路図なんかも書いてある。

JASPARなんかの話を聞けば、自動車の方が結構先覚的に思えてくるから不思議。しばらく前は、携帯電話の方が時代の寵児みたいな所があったけど、なんかモグラ叩きな開発に思えてきた人が多いのかも知れない。

で、この記事で面白いのは、とは言っても自動車はコスト競争。自動車メーカーからのコスト減の要求にどう対応するかという事で結んでいるところ。言われれば当たり前なんだけど、、、、。ということは、自動車関連のソフト開発を如何に効率良くやるかが話題になっていくと思われる。結構別の業界でも、参考になることが出てきそう。

一般的には、ソフトとかプロセス屋さんは、やたらとアジャイルな設計プロセスとかCMM/CMMIとかを言うのかも知れないけど、自動車でのソフト開発がそんな尺度で効率を議論するのかも少し楽しみだ。


8月 18, 2008 ソフトウェア, テクノロジー, 技術, 自動車 | | コメント (0) | トラックバック (0)

2008年8月 3日 (日)

プレキャスト工法 (がっちりマンデー!!)

今日のTBStv「がっちりマンデー!!」は、コンクリート業界。世界で(恐らく)一番硬いコンクリート「ダクタル」なども紹介された。

で、建築現場での「プレキャスト工法」が紹介された。

http://www.tbs.co.jp/gacchiri/oa20080803-mo3.html

現場で生コン注入するんじゃなくて、工場(別の所)で作ったものを現場に運ぶというもの。1フロア2週間かかっていたのが4日で済む。ここのブログ読んでる人は知ってると思うけど、建築での進捗管理として、コンクリートで厄介なのが「養生」。コンクリートが乾くまでは、どんなに頑張っても日数がかかってしまう。そこには、いくら人数かけても解決しない。この工法だと、それを視野に入れなくてもいいんだから、期間短縮になり、発想として自由度が広がる。

建築ではそうやって工法など工夫するのに、ソフトウェアはなかなか進展しない。(進展しているとは思えない、広まっているとは思えない。あるいは工法が大規模建築に適応できるのに対して、なかなか大規模ソフト開発での効率化の決め手が無い。) 逆に、3K,5K,最近は7Kとまで言われる業界になってしまった。 

あっ、蛇足かもしれないけど、個人的には「養生」のメリットはあると考えている。建築だと、一度見回りなどをして確認するのに当てられる。ソフトウェアだと、レビューなどでの後日気づきみたいな感じ。なので、「養生」という期間を全くなくすよりも、代わりの(短くていいから)バッファは設けていた方がいいと思う。

8月 3, 2008 ソフトウェア, テクノロジー, プロジェクトマネジメント, プロジェクト管理 | | コメント (0) | トラックバック (0)

2008年7月29日 (火)

トヨタの生産試作の呼び方は、号試

ソフトウェア関係の人達と話題となるのが、開発プロセス。特に組込みだと、(大まかには)設計の試作の会議、生産の為の試作の会議、出荷判定というプロセスだろうけど、その事を理解できない人とか、理解しようとしない人がいる。

段階を踏む事を理解しようとしない。(もちろん、それに代わるようにプロセス案を議論してる訳じゃない。)

前読んだのは、自動車のホンダ系の本で、DR1、DR2との名称。その事を言っても駄目。で、今日は、じゃっということで、トヨタではどう言うんだろうと調べもの。そしたら、設計試作は設計試作だけど、生産試作は号試(ごうし。正確には号口試作(ごうぐちしさく)と呼ぶと判明。いやー、正式名称は呼びにくい。coldsweats01

ほんとは、設計試作も2段階みたいだけど、短縮化の改善などもあるので、ケースバイケースなのかもしれない。

トヨタの名前を出すと説得性があるようなので、段階を踏む事の説明で次回から多用しようかな、、、。

ちなみに、今日は別件の関係もあって、”ISO 16949”の本を購入。こちらも自動車関係。なぜか、今日は自動車業界のプロセス関係の勉強が少なくなかった。うーん、良いことなのか??? (本来、ソフトウェア開発プロセス自ら、こんなプロセスとか認証メカニズムを確立すべきじゃないのかな~)

7月 29, 2008 ソフトウェア, テクノロジー, プロジェクトマネジメント, プロジェクト管理, 出荷判定 | | コメント (0) | トラックバック (0)

GMarks 階層化できる!!

今日何気なく探し物してたら、以下のページに遭遇。


http://sunone.blog1.fc2.com/blog-entry-366.html

いやーラッキー。というのも、Googleブックマークが階層化できないとのことで、Googleノートブックを使ったりしていた。でも、最近段々とノートブックだと重いし、整理がまた大変と少しいらしていた。

上のページだと、少し分かりにくいけど、ラベルの指定で”>”を利用する事で階層化できる。”階層トップ>第2階層”とラベルを記述すると、、、、。

階層トップ
  第2階層

みたいになる。ただし、GMarks ブックマークの管理だとフォルダ構造が分かるけど、検索履歴のページでは”階層トップ>第2階層”のままで表示されて階層のイメージがつかみにくい。慣れればたいした事無いけど、最初は検索履歴などもそうなっていると固定概念が働くので、階層化していないように感じてしまう。

ちなみに、">"はデフォルトで、GMarks オプション 一般 ラベル ラベルセパレータ の記述で変更できる。ただし、どうも2バイト漢字文字をセパレータには出来ないみたい。

良かったと一安心だけど、今までノートブックに記憶させたものを順次ブックマークに移さないといけない。結構な労力になりそう。どっかで見切って、さほど利用しないURLはノートブックのままにしておくなど工夫する予定。もう少し、せめて半年位早めに知っておけば良かったんだけど。

7月 29, 2008 ソフトウェア, パソコン・インターネット | | コメント (0) | トラックバック (0)

2008年6月25日 (水)

Firefox 3.0でのブックマーク登録

Firefox3.0にして、結構GUIが変わっているので戸惑ってた。(劣悪変更のOffice2007よりは、ましだけど。coldsweats01 ネット系との親和性を向上するのはわかるけど、GUIをあそこまで変えちゃいかんでしょう。)

で、Firefox3.0で、ず~~っと悩んでいたのがブックマークの登録。GMarksをインストールしているせいか、ブックマークのクリックだとGMarksの方への登録となる。以前のような選択タグがない。つまり、PCローカルの方への登録ができない。「おかしいな~」の連発。

今日になって、やっとわかった。ヘルプを見れば良かったんだけど。 以下。

http://support.mozilla.com/ja/kb/%E3%83%96%E3%83%83%E3%82%AF%E3%83%9E%E3%83%BC%E3%82%AF#__5

一番馴染んだのが、URLの記載のところでの☆マークをクリックするやり方。最初あの星マークは、Googleブックマークでの☆なのかな~とか勝手に思ってしまった。理解はできたけど、Googleブックマークでの☆と混乱しそうで、まだ慣れてはいない。

6月 25, 2008 ソフトウェア, パソコン・インターネット | | コメント (1) | トラックバック (0)

2008年5月 3日 (土)

ベトナムのインフレ率 12%強

今日のBS「グローバルナビ」で、目にしたのが各国のインフレ率。まっ、日本もこれから上がるだろうとの話の一環。

で、抜きん出て高い国があった。中国よりも高い。どこだろうと見たら”ベトナム”。一瞬「えっ!」。10%は優に超えていた。数%くらいと思っていたのに。

念のために調べたら、外務省のページでは、昨年の速報で12.6%とある。

http://www.mofa.go.jp/mofaj/area/vietnam/kankei.html

#外務省も、変なお役人が多いと思ってるけど、ちゃんとやってる人たちはいるんだな~。coldsweats01

うーん、オフショアとかオフサイト検討してたら、ちょっと注意。2006年は6.6%なので、何で急に上がったか考える必要もあるし、単に速報での計算ミス(なわけないか)かもしれない。

そもそも、賃金だけでオフショアやオフサイトを捉えるのはまずいとの指摘は、雑誌類などでも書かれているので周知の人が多いだろう。それも考慮し、カントリーリスクも考えないといけない。今回だと、ベトナムのインフレ率 。もちろん、PMBOKでのリスクの視点で考えれば、各国それぞれメリットも色々ある。 難しい~。

5月 3, 2008 ソフトウェア, 日記・コラム・つぶやき, 経済・政治・国際 | | コメント (1) | トラックバック (0)

NE付録 「カーエレクトロニクス テクニカルターム」

今日(昨日遅く?)届いた日経エレクトロニクス、付録が「カーエレクトロニクス テクニカルターム」。自動車carでの技術用語。システム手帳くらいの大きさで、64ページ。

ソフトウェア関係は、FlexRayなどの車載ネットワーク、MOST/IDB-1394のような車載マルチメディアネットワークのようなネットワーク関係。AUTOSAR、JasParといった再利用促進の団体。HILSのようなコンピューターによるメカなどハードのシュミレーション技術などにも触れている。

トヨタ資料でのソフトウェア規模が10年で15倍以上とか、どの分野のソフトの増加倍率が高いかがわかる資料もあり。小さいけど。どっかで見たかな~。

このブログ読む人は、ソフトウェア関連では知ってることが多いと思うけど、本冊子ではメカやレーダーのことなどにも触れているので自動車のことを俯瞰的に知るには参考になる。

5月 3, 2008 ソフトウェア, テクノロジー, 技術, 書籍・雑誌 | | コメント (0) | トラックバック (0)

2008年4月30日 (水)

ソフトウェア単価調査のために月刊「積算資料」

ついさっき、アマゾンに頼んでいた月刊「積算資料」が届いた。5月号。

ソフトウェア開発等の単価が出ているため。ちなみに、プロジェクトマネージャー、SE1、SE2、プログラマでは、東京のプロマネと札幌のプログラマの人件費とで倍くらいの差。ページ数は、人材派遣料金まで含めても10ページ程度。

なお、開発プロセスはSLPC-JCF98に副っている旨が書いてあるから、少し驚き。(まっ、次回には2007になっているんだろう。)

「積算資料」は、何かの折に書籍の方も購入した。建設・土木での見積もりの仕方が、参考になって面白い。建設機器のレンタル料なども書いてある。今回、おさらいもあって最新号を購入しようとした。いつか本屋に行った時にでもと思っていたけど、アマゾンにも置いてあったので注文した次第。他での人件費も含めて、ちょっと情報を整理してみようと思う。

4月 30, 2008 ソフトウェア, プロジェクトマネジメント, プロジェクト管理 | | コメント (0) | トラックバック (0)

2008年4月27日 (日)

統合テスト→コンポーネント統合テスト、システム統合テスト

ひょんなことで、ソフトウェアテストの再勉強。特にJSTQBのシラバス読んでます。

読むと、「統合テスト」って、「コンポーネント統合テスト」と「システム統合テスト」があると書いてある。もちろんシステム統合テストは、システムテストの後のテスト。

以前、プリンタのテスト関係の記事化で、テストフェーズをどう呼ぶかで喧々諤々。最終的には、従来からよく使われている、単体テスト、結合テスト等の用語を使った。JSTQBの用語に合わそうにも、統合テスト(本来はコンポーネント統合テスト)を使うと、テストフェーズの粒度が違うな~とのことで断念したのも理由。

今回読むと、ちゃんと「コンポーネント統合テスト」と「システム統合テスト」と分けてある。なら、この用語を使えばよかった。特に「システム統合テスト」。その後のテストを、全体テストとかで呼べばすっきりする。あるいは、「システム統合テスト」での一環として扱っても良い。

喧々諤々の時に、誰か言ってくれれば良かったのに~coldsweats01。といいつつ、ちゃんと勉強してなかった自分も悪いんだけど。

なので、今からは「コンポーネント統合テスト」と「システム統合テスト」の用語をちゃんと使って、”統合テスト”そのものは使わないようにしたいと思う。(統合テストそのものは、コンポーネント統合テストを指すというのがコンセンサスになればいいんだけど。)

4月 27, 2008 ソフトウェア | | コメント (3) | トラックバック (0)

2008年4月26日 (土)

「ソフトウェアの規模決定,見積り,リスク管理」

少し酔っ払いながら、本屋(有隣堂)へ。今頃と思われるかもしれないけど、J-SOX法関連の本とか、知り合いの人が出版したそうなのでその本の確認とか、、、。他にも携帯電話に記憶させてた気になる本を調査。結局、気になってて見つけられなかった本が1冊。他は見つけられたり購入へ。

で、いろいろ回って目に付いたのが、「ソフトウェアの規模決定,見積り,リスク管理」。富野さんの監訳。酔ってたこともあって、「買ってないはずだよな~」と思いながらも自信なし。中身をパラパラ見て、買ってなさそうと思い購入へ。

アーンドバリューなどプロジェクト管理志向、リスク関係、オブジェクト指向に関するメトリクスなどが書かれていて、整理されていると感じた。(今までの富野さんの本と比べて、紙質が良くなったというかつるつる感が増えたように思う。あっ、そんなことはどうでもいいか。wink



なお、本屋をぶらぶらしてたら、Google Androidの(新しい?)本を発見。結構気にいった表紙。少し買おうか悩んだけど、数冊買い求めたこともあって今回は断念。次回にでもゆっくり見て、買おうか決めようと思う。

4月 26, 2008 ソフトウェア, プロジェクト管理, 品質 | | コメント (1) | トラックバック (0)

コードレビューは日本人向け?

今日の勉強会後の懇親会では、いろいろな話題に飛んだ。

唐突というほどでもないけど、「アングロサクソン系ってコードレビューする/してうまく行ってる?」みたいな会話へ。大抵、「そういえば、やってうまく行ったなんていう話はないかな~」とか、「そもそもやらないんじゃないの」との返事。もちろん、コードレビューの本そのもので、書かれているのはアングロサクソン系がほとんどだけど。(その場で特に話した人はいないけど、その場のアングロサクソン系って、中国も含む感じかなと勝手に解釈してます。)

念のためだけど、ここでのコードレビューって、コードそのものの読み合わせ。組織体によっては、もう20年近くとかそれよりも前に実践しているところが多い。私の場合、大学の演習とかでもその類をやった気がする。ただ多少体系的なり記録に残すというのは、会社へ勤務してから。 なお、なんか最近、違う意味に解釈しているところもあって少しだけど困惑。


で、コードレビューは、日本人では結構実践している。「なぜ?」が話題に。で、言ったのは「田植えなんかで、隣の人の動きとかみながら作業するから?」と言ってみた。つまり、日本人って、結構オープン性が高い。温泉とか銭湯などの共同風呂が最たるもの?

狩猟民族だと、そうでもない。取ってきた獲物が、本当にその人が猟したかわかったもんじゃない。なので、神様には嘘つかないとか、契約社会へ。

なお、最近はGoogleなどのように、全社的にソースを共有する仕組みを実践しているケースはある。

それらを考えると、アングロサクソン系は、オープンにしないか、オープンをやたらと広い範囲とするかのどちらか。日本人は、グループでの共有が前提。そんなに考えてみたけど、いかが。

4月 26, 2008 ソフトウェア | | コメント (1) | トラックバック (0)

2008年4月24日 (木)

ISO 25000(SQuaRE)シリーズ 14冊

CMAP21さんも書かれているけど、ポツリポツリとISO 25000(SQuaRE)シリーズの話が出始めてる。ISO 9126などを発展させたもの。

http://blogs.dion.ne.jp/cmap21/archives/7075562.html

そこのこと自体は良いけど、ISO 25000(SQuaRE)シリーズって全部で14冊なんだそうな。14冊。4冊じゃなくて。

JISの9126を何冊か持ってるけど、個人だと1冊買うのも大変。ISO 25000(SQuaRE)シリーズのJIS版の値段がいくらになるか知らないけど、値段は考えてほしい。そうしないと、敬遠されることだってあるだろう。また、メトリクスのどれが重要だとかも書かれないと、闇雲に測定する連中が出てくるような気がする。そうもせずにやたらと規則だらけに運用すると、形骸化したISO9000の二の舞になりそう。

4月 24, 2008 ソフトウェア, テクノロジー, 品質 | | コメント (0) | トラックバック (0)

2008年4月23日 (水)

「Googleを支える技術」

「Googleを支える技術」を買う。12日だったか、書泉グランデで本を買った時に、会計の時に見かけ買おうかと思ったもの。ただその時は、荷物が多くて後日の購入で仕方ないと断念。その後、そこそこの規模の本屋さんでも売ってなくて、機会があったら買おうと思っていた。

最初、ぱらぱらめくったら、分散ストレージ系の話題が目に付いた。最後の方で自動テスト関連。「あれ、もう少しソフトに突っ込んで書いてないのかな~」、とその時は少し拍子抜け。

実は、ここ2、3週間前から、Googleの検索方法が気になっていた。どうも、英語の単語はもちろんだけど、日本語だと文節で予め区切った単語でハッシュ化してるような気がしたため。

で、ちゃんと目次を読んだら、冒頭に検索関係のことが書かれていた。そこで、即購入。

”本書に寄せて”は、まつもとゆきひろ氏。TeckTalkの様子はビデオで流されるのに、写真撮影厳禁なのが不思議だったなどの話題も書かれていた。

開発方法などに関しては、むしろネットの方で流れているので、新鮮味が少ない人も少なくないかもしれない。ただ、ある程度網羅的に書かれているのがいい。ソースを全社で一元管理している話や、コードレビューを二段階で行っている話。後者は、一般の開発でも流用した方がいいのかもしれない。個人的には、やっぱレビューは人手をかけないと、というのを改めて確信した。

なお、最近はGoogleドキュメントやGoogelカレンダーなどアプリケーションサービスが豊富になっている。これからはSNS系のサービスが出てくるだろう。その意味では、もう少しソフトウェアなりネットサービスの技術に触れるような続編を期待したい。

ちなみに今年の「Google Developer Day 2008 Japan」は、6月10日にパシフィコ横浜において開催されるそうだ。

4月 23, 2008 ソフトウェア, パソコン・インターネット, 書籍・雑誌 | | コメント (0) | トラックバック (0)

2008年4月21日 (月)

AUTOSAR用ツール、FlexRay専用の妨害発生ツール

今日ネットニュース経由で、AUTOSARの動向を調べる。日本発のツールが出たニュースが引き金。

http://gazoo.com/NEWS/NewsDetail.aspx?NewsId=d308ff24-7a01-4762-be61-6ab9b8f22e03

で、調べたら、FlexRay専用の妨害発生ツールも出ているようだ。

http://www.vector-japan.co.jp/vj_ecutest_jp,,6863.html


JasParも含めて、自動車業界のソフトウェアの標準化がどんどん進んでいる。しかも、共通インフラに対する障害発生のツール類まで出るんだから、羨ましいと言うか、、、。


実は最近、ソフトウェアにとって軽薄短小は利が無いように思うようになった。自動車でのコンポーネント化が進んだ大きな理由は、いくつものECU(電子制御ユニット)で構築されている事があろう。おのずと、ECU毎の機能とか、そのインタフェースを厳密に設計する。部品の交換と同じような交換性を重視した感覚でのソフトウェア開発。他に事務機なんかもそう。

軽薄短小を極めようとすると、どうしても交換の概念が薄れてしまう。マルチコアになったらコンポーネント化が進むと思う人もいるだろうけど、どうだろう。セキュリティなど切り離したい部分を別コアにする事があっても、メインの方が構造化されるか????

4月 21, 2008 ソフトウェア, テクノロジー, 自動車 | | コメント (0) | トラックバック (0)

2008年3月19日 (水)

ソフトウェアテスト カバレッジ

「ソフトウェアテストの勉強室」での、コードカバレッジの記事。↓

http://softest.cocolog-nifty.com/blog/2008/03/post_7864.html

モディファイドコンディション/デシジョンカバレッジとかは良く知らなかったので、ちょっと勉強になった。「原因結果グラフやデシジョンテーブルなどを利用したテスト設計は、このカバレッジ基準と同等といえる。」って、網羅度として同値ということにもなるのかもしれないけど、良く考えてみたい。

具体的な例で100%の網羅度の例を示したり、強み/弱みが対比されてて面白い。


実は、月曜日の宴会で、”網羅度”が少し話題となった。こっちは、「網羅度って割合で、分子/分母」とか「コードカバレッジ、要件に対するカバレッジ、組合せテストでのカバレッジは、それぞれ意味が違うよ」っと途中まで言ったけど、何か聞く耳持たない人が多かった。うーん、大事な事なんだけどね。

3月 19, 2008 ソフトウェア, 品質, 組み合わせテスト | | コメント (1) | トラックバック (0)

2008年3月17日 (月)

工事進行基準がらみ? 日経コンピュータ「納得できるITコスト」

届いたのは一昨日とかそれ以前だったけど、ついさっき日経コンピュータ3/15号を読んだ。

特集は「納得できるITコスト」。来年4月以降適用される、会計基準の工事進行基準をも意識したもの。冒頭でもその旨が記載されている。

面白かったのが、リクルートのベンダーの生産性のランク分け。ファンクションポイント(FP)ベース。SSランクという44FP~/人月から、Cランク~6FP/人月。ランク分けは、スキルとかで色々やってる所が多いし、FPでやりそうなのはわかるけど、具体的な数値まで見たのははじめてのような気がする。

もう一つは、ローソンでの案件の評価制度。案件の企画段階で、撤退の判断基準と撤退方法を記載するように決めている事。

実は、後者は先週の某損害賠償のニュースの絡みもあって、撤退方法を収束させるにはどう考えればいいかを思考しつつあったので参考になった。あっ、検討は出荷判定のコミュニティがらみ。

3月 17, 2008 ソフトウェア, プロジェクトマネジメント | | コメント (0) | トラックバック (0)

2008年3月16日 (日)

Googleの社内ツール

「POLAR BEAR BLOG」に、Googleの社内ツールが載っていた。元ネタ(英語)のリンクも記載されている。

http://akihitok.typepad.jp/blog/2008/03/google-4b0f.html

プロジェクトのダッシュボードなども。社内リソース検索エンジン(エンタープライズサーチ)や Google Calendarは、一般公開されているのと少し違うようだ。専門家の検索システムもある。(なお、専門家検索は、マイクロソフトのシステムでの構築例を見た気がする。マイクロソフトのデモだったか、そもそもマイクロソフトの社内ツール説明の時だったか??)

こういうのを見ると、Googleって社内ツールの外販化と言えなくもないと思えてきた。コミュニティでのツール類で、結構Googleは利用している。DocsとかBlogger、グループ、そしてYoutubeのグループも。もちろん、結構不満な部分もあるけど、協業するには非常に便利。(プロジェクト管理ツールが欲しい。Calendar形態ではなくて、アクティビティ間の関係を記述できるツール。)

なお、個人的に以下もお勧め。

http://itpro.nikkeibp.co.jp/article/Watcher/20061223/257663/
IT Proでのシリーズ。多分全部読むには登録が必要。

http://jp.youtube.com/watch?v=pc-IQkVmOdI
Google Developer Day TokyoでのGoogle社員の鵜飼文敏さんの講演。トイレでのバグ(?)の掲示の話が出たはず。

http://japan.cnet.com/blog/umeda/2003/05/12/entry_google_1/
記載が2003年で、今となっては変わっている部分も少なくないだろうけど、基本的な考えを知るにはいいかと思う。(採用のための時間とかは良く知られている? 採用問い合わせ先を、クイズ(数式の解)にしたのもgoogleだったはず。)

3月 16, 2008 ソフトウェア, プロジェクトマネジメント | | コメント (0) | トラックバック (0)

2008年3月15日 (土)

業務プロセスの複雑度

昨日のS-openでの会議で、個人的に少し気になった話があった。ポイントは、ソフトウェアの規模測定は手法がある程度確立されたとして、業務プロセスそのものの複雑度は? そんな意味合いと感じた。会議での主流の議論ではなかったので、その場は主流の議論が継続。

で、個人的に気になって、今日調べた。

業務プロセスそのものの複雑度がわかり、ソフトウェアの規模も測定できたら、プロセスの実装(正確には検討)漏れなどが分かるという寸法。もちろん、そう簡単に物事は進まないけど。

また、業務プロセスの可視化とかは結構やられているので、そこで複雑度を研究している人達がいてもおかしくないとの思いもあった。

明確な答えにはならなかったけど、いくつか面白いのを発見。

・富士通の論文(記事)
http://img.jp.fujitsu.com/downloads/jp/jmag/vol59-1/paper05.pdf

なお特許取得みたい。
http://pr.fujitsu.com/jp/news/2007/04/13-1.html

・効果指標の視点でのNRIの記事
http://www.nri.co.jp/opinion/it_solution/2007/pdf/IT20070906.pdf
なお、記事中のSCORは、今は以下と思われる。
http://www.supply-chain.gr.jp/scor.html

・情報システム学会での「人間の情報活動としての業務プロセスの可視化」研究会
http://issj.nuis.jp/issj/process.html


業務プロセスがあるというか公開されているということは、そこへの投資があるということ。投資があり、そのシステム構築の効率化を考えると、ベースとなるモデルがあるほうが楽なので。(逆に、モデルがないところは、投資がないというか、もししかしたら衰退していく分野かもしれない。気になっているのは、設計とか開発。暴言? ただし、特に車業界などでは共通化したフレームワークを作り出しているので、取組みとしては参考となる。)

3月 15, 2008 ソフトウェア | | コメント (0) | トラックバック (0)

2008年3月10日 (月)

「組込みプレス」形式手法、「プロセス改善ナビゲーションガイド ベストプラクティス編」

今日は朝早かったので早めに切り上げて、ちょっと本屋さんへ。

組込みプレスはVol.10。”祝”のマーク。形式手法の車載シスエムへの応用が目に留まったため購入。なお、帰ってから読んだら、Promelaという構文を利用しているみたい。ちょっと良く調べてみないといけない、、。

巻末にはスキル判定シートなるものがあり、結構面白そう。また、ロボット技術なども。


SEC BOOKSとして、「プロセス改善ナビゲーションガイド ベストプラクティス編」が出ていた。いくつかの事例集と考えた方が良い本。結構具体的で、参考になりそうなメトリクスなども少なくない。

JAXAとか日本電気(CMMIレベル5)もあり。住友電気のJAVAでのu管理図は、以前から気にしていたテーマなので参考になった。(でも、時系列での視点の言及が、少ないような気がするけど、、、。)


どちらも、細かい部分を読むと結構身近なプロジェクトでのヒントとなったり、URLにアクセスして深く調べた方がいいのがある。今週、他の資料も含めて詳しく調べようと思う。

3月 10, 2008 ソフトウェア, 出荷判定, 品質, 書籍・雑誌 | | コメント (0) | トラックバック (0)

2008年3月 7日 (金)

「やわ物の品質管理の考え方」森口繁一さん

ソフトウェアの品質関係をネットサーフィンしてたら、故森口繁一さんのPDFを発見。

http://www.juse.or.jp/software/pdf/tresurebox02.pdf

「やわ物の品質管理の考え方」と題した、7ページの記事(シンポジウム講演)。”やわ物”とか”HIPO”とか、結構懐かしい用語を目にする。当時、ソフトウェア関係の英語表記を日本語で表記する動きがあり、当時が偲ばれた。ただし、”算譜”は結構記憶がはっきりしてるけど、”やわ物”と呼んだかは???

バグを見つけるよりも発生の防止が重要とか、統計(今ならメトリクス)を改善のために活用しなさいとか、基本的なことが書かれている。1981年の記事、20数年前。

森口先生は、当時個人的には数学系との思いがあり、ソフトウェア工学とかソフトウェア品質に関するこの記事は新鮮だった。(ある意味では、当時が不勉強だったのかな。)


当時(その少し前?)だと、コンピュータは花形産業。(多少失礼かもしれないが)キーパンチャーですら、憧れの職業だった。それが今や3Kとか5K?とか。会社や部署、業界によるらしいけど、20数年前よりもひどいと思わせるような非科学的なプロセスがあるように聞く。進歩してないのか、情報系の連中が不勉強なのか、誰でもソフトを作れると思うような組織の問題なのか、、、。勉強テーマになりそう。

ちなみに森口さんの記事は、以下の日科技連のページから辿れる。他にも参考になるのが少なくないので、興味あればどうぞ、。

http://www.juse.or.jp/software/tresurebox.html

3月 7, 2008 ソフトウェア, 品質 | | コメント (0) | トラックバック (0)

2008年2月29日 (金)

「【楽々デブドックを書こう!】開発☆ドキュン」の最終号は、テスト関連

毎週少し楽しみにしているのが、Think ITでのドキュメント作成のシリーズ「【楽々デブドックを書こう!】開発☆ドキュン」。

若い女性二人の、しかもイラストが多いやり取りなので、ちょっと楽しい。シリーズの名前からして、我々にはsign02coldsweats01なんだけど。 でもドキュメント作成の必要性がうたってあり、若い子には是非読んで欲しいと思うような内容。

今回がシリーズの最後で、「第5回:テスト関連も忘れちゃだめドキュ!」。”各フェーズでのドキュメントを作成する際に、同時にテスト用のドキュメントを作っておくと良いわよ”というセリフも。ある意味では、当たり前のことなんだけど、当たり前を実行しない連中が多いんだよな。(あっ、念のためだけど、テストドキュメント関連としてはTDDとかBDDの動きもあるので、より効率的な手法の議論も必要。)

(若い子向けの教育で)なんかの時に活用させてもらおうかなと思っている。

2月 29, 2008 ソフトウェア, プロジェクトマネジメント, プロジェクト管理 | | コメント (0) | トラックバック (0)

2008年2月26日 (火)

拍手 日本IBMよおまえもか エバンジュリストのブログ

日本アイ・ビー・エム公認のソフトウェア・エバンジェリスト、米持幸寿氏のブログを発見。

http://www.ibm.com/developerworks/blogs/page/pandrbox?ca=drs-jp

日本のソフトウェアとかIT企業の、社員ブログ公開が加速するのだろうか? もちろんネット系とかの企業は以前からやってるけど、大手のグローバル企業ではまだ皆無?

2月 26, 2008 ソフトウェア, パソコン・インターネット | | コメント (0) | トラックバック (0)

2008年2月18日 (月)

「情報処理」 ”ソフトウェアテストの最新動向”

情報処理学会の会誌「情報処理」2月号の特集は、”ソフトウェアテストの最新動向”。

http://ssl.ohmsha.co.jp/cgi-bin/menu.cgi?ISBN=4-JS8020-JS-Z

以下が最新号のはずなんだけど、今は1月号。
http://www.bookpark.ne.jp/ipsj/index.asp

以下は購入ページだけど、詳しい目次が分かる。
http://fw8.bookpark.ne.jp/cm/ipsj/search.asp?from=Magazine&flag=-1&keyword=Magazine,YM200802

学会誌なので、少し固めの内容。特に並列プログラムのテストとTDDは、そう感じるかもしれない。ただし、具体的なので、分かりやすいと思うんだけど。

なお、テスト/デバッグ技法の効果と効率は、テスト技法の包括的な話。もう少し突っ込んだ話は、松尾谷さん自身の講演なんかで聞くのが良さそうに感じた。

情報処理って、ソフトウェア開発者でも読んでない人が多いんだよな~。まっ、学会誌だから仕方ないというか、それが日本の実力。会社で話題になればラッキーな方だろう。特にお偉いさんが読んで気が付けば、ちょっとソフトウェア品質上がるというか、ソフトウェアテストの体制や技法の見直しなどに結びつくかもしれない。

2月 18, 2008 ソフトウェア, 品質, 直交表, 組み合わせテスト | | コメント (1) | トラックバック (0)

2008年2月17日 (日)

Bloggerはチーム100人まで

今複数人でブログを作成中。ほぼ、GoogleのBloggerを利用する事にしている。(ただし、タイトルの写真正式への差し替えとかマルシー関連の表記を再確認中。)

で、全く別のプロジェクトで利用できるかなと思って、投稿可能な人数を再確認しようとした。英語サイトとかでも良く分からない。調べたら、日本語というかBlogger自体の投稿者の追加画面に、”最大 100 人まで許可されます”と書かれていた。何ーんだ。

全く別のプロジェクトって、そもそも立ち上げるかもだけど、人数もどれくらいまでになるか不明。でも、協業と考えて投稿するメンバーを絞れば、100人行かないだろうな~。Bloggerを使えるかもしれない。

2月 17, 2008 ソフトウェア, テクノロジー, パソコン・インターネット | | コメント (0) | トラックバック (0)

2008年2月16日 (土)

Googleのブログ 研究・開発者の成果?

ここ1週間、何度か読んでる(見ている)のが、Googleのブログ。

Google Enterprise Japan 公式ブログ

Google Japan Blog

もちろん、他の各国のブログへのリンクもある。アカデミックな記事bookもあるけど、微笑ましいwink記事も少なくない。

なお、どちらのブログでも、日付というか年がおかしいのがいくつかある。「Google Maps API ドキュメントが日本語化されました」も「IT Pro EXPO 2008に参加しました!」も、2008年のはず。それも愛嬌か。

日本だと、サイボウズラボとかmixi技術情報辺りが該当。他にも、ネットワークサービス系では、開発者のブログへのリンクがあるのも少なくない。マイクロソフト米国などでのブログも見た気がするけど、日本語でのブログの方が親しみを持てる。ただこれは、こっちが外国語が不得手なせいかもしれないけど。

サイボウズ・ラボ

mixi Engineers’ Blog


ふと思ったのが、それぞれのアクセスカウントを、研究者・開発者(・営業)の評価ポイントの一つにしてもいいんだろうなという点。即データ取得できる。実際利用しているのかもしれない。また、ユーザー嗜好とか要望分析にも使える。要望といえば、mixiでの「mixiへの機能要望」などはその際たるもの。

メトリクス系の勉強をしている身にとっては、測定する事への抵抗annoyは良く話しに聞く。なんか昔から、全然進歩してない。測定データを、あくまで参考にするとの割り切りが出来ない。ツール類の導入ですら喧々諤々punchannoypunch。そもそも、成果の評価が恣意的というか、ひどいのは何度も赤字プロジェクトにする担当がトントン。そんな記事は、昔から何度も見かける。

なんか、ブログとかSNSの発想をうまく利用したい。(あっ、実例が出だしたのは知ってるよ。)

2月 16, 2008 ソフトウェア, パソコン・インターネット | | コメント (0) | トラックバック (0)

2008年2月14日 (木)

OpenID使う 大文字と小文字を区別するんだ

今日、OpenIDを使うことに。

動画の調査が必要で、Mitterで調べようとした次第。「はてな」のIDは持っていたので、それを利用した。

最初エラーが出るので、???。念のために、「はてな」のIDでの大文字を大文字のまま入力したら、OKだった。理由が分かれば、何だそんな事か~。(大文字/小文字を区別しない入力サイトもあり、普段小文字のみで済んでいるケースがほとんど。正確には、「はてな」で大文字/小文字を区別してるのかな。)

新しい仕組みって、最近は少し待ってから使う事にしている。これもそのために、少し使うのを控えてた。引き継ぐ情報も少ないようなので、OpenIDにはほとんど抵抗なくなった。(再度、確認はするけど。)

2月 14, 2008 ソフトウェア, テクノロジー, パソコン・インターネット | | コメント (0) | トラックバック (0)

2008年2月12日 (火)

情報処理学会 全国大会でのセカンドライフ会場

今日の情報処理学会からのメール、見出しは「第70回全国大会 セカンドライフ会場のご案内」。

3月13日から開催される第70回全国大会で、セカンドライフ会場も用意するとか。以下の第70回全国大会での”セカンドライフ会場入り口”から辿れる。

http://www.ipsj.or.jp/10jigyo/taikai/70kai/index.html

といっても、今環境がなくて、確認できないが。

実は先週、とあるコミュニティで、その成果をセカンドライフでもやろうかと少し話題となった。その時は、(凝れば)予算の件や作成時間の事もあって、断念した。情報処理学会がやるんだったら、少し前向きに考えればよかった。

後日にでも、情報処理学会のセカンドライフ会場は覗いてみようと思う。

2月 12, 2008 ソフトウェア, テクノロジー, パソコン・インターネット | | コメント (0) | トラックバック (0)

2008年2月 9日 (土)

「新派生売買システム」、OpenPNE運用実験、Googleカレンダー、、

今日は、結構バタバタ。

朝、「新派生売買システム」の障害の件を、ほんのちょっとしたレポートへ。とある所で、障害事例を調べているため。(でも、数段詳しく調べる人がいくれて脱帽。)

昨日のトラブルは、前引け後に派生売買システムに障害が発生して、TOPIX先物2008年3月限(JTIH8)の売買を後場から終日停止したというもの。 復旧の見込みが立たず、三日連休返上だそうだ。

http://itpro.nikkeibp.co.jp/article/NEWS/20080208/293321/

http://itpro.nikkeibp.co.jp/article/NEWS/20080208/293371/

で、本システムは以前から危なさそうと言われていたもの。

http://itpro.nikkeibp.co.jp/article/NEWS/20080123/291892/

の、中段などを参考の事。ToSTNeT(立会外取引)システムとの統合なので、接続でのテストや負荷、異常データなど多数の注意すべき事項があったんだと思う。基本的に色んな所に、バグが潜んでいる/いたんだろう。規模でかいし、大変。


その後というか、平行しながら別コミュニティのOpenPNE(SNS)の運用実験。昨日テストしつつあると聞いて、早速テスト。やっぱ個人的には、メールベースでの連絡よりも、SNSなんかの方がいいな。日記の下に自分のブログサイトも記載できる。つまり、そのSNSでの日記とブログの日記の表題が両方出る。mixiだと、mixiの日記→各ブログへのジャンプなので、そのワンクッションが面倒。

テスト運用のための、コミュやトピを作成したりした。若干登録の手順でおかしいところがあったので、蓋してもらった。作業が早くてありがたかった。

早急なテストだったので、全体的な見直しは必要そう。でも、何となく基本的なところは形が見えてきたかな。後は、皆をどう勧誘するかとか、本格運用のお墨付きを貰うにはどうするかなどが課題。

さすがに、頭使いっぱなしだったので、一時期スーパー銭湯へ。

その後は、OpenPNE(SNS)の運用実験とGoogleカレンダーのオフライン操作へのチャレンジを、平行しながら作業。運用実験は、他の人とのネット上の意見交換もあるので、やっぱ時間かかる。

で、Googleカレンダーのオフライン操作だけど、数日前から悪戦苦闘。Googleカレンダーのサーバーが駄目になった時に、どうオフラインデータを表示させるかの検討。同期よりも、オフライン表示を優先させようとしたもの。

そもそもGoogleカレンダーのエクスポート→インポートが、とある場所では、どうもブロックされている。最初それに気がつかず、ソフトそのものが動かないと思って再ダウンロードなどの作業が発生。自宅で実験したとしても、うまく行かないケースが、、。

・Calgooはネットワークをはずして起動すると、ハングアップなのか処理に時間かかっている。結局断念。これはきつかった。どっかに勘違いや設定があるのかもしれないが。

・Google Gearsを組み込む方法は、何となくインストールできるが、肝心のオフライン用の緑のアイコンが表示されない。うーん何故なのか?? 結局こっちも断念。

・ソーシャルカレンダー「c2talk」は、オフライン機能というよりサービス志向で、ユーザー登録などもやるので止める。

で、Lightningなどを使ったThunderbirdでの表示は、同期が主体の様子。

ほとんど八方塞りかなと思ったけど、再度Sunbirdでのインポートにチャレンジ。GoogleカレンダーでiCal(メニュー上はICAL)のファイルを一旦保存。Sunbirdで取り込むようにした。で、どうにか取り込めた。

ポイントは、非公開のICALを一旦選択→ポップアップでリンク先を保存→Sunbirdで取り込み。

非公開のICALじゃないとうまく行かなかった。また、思えば当たり前だけど、リンク先の保存が味噌かな。

ただし、インポートすると上書きしない。例えば、basic.icsでエクスポートしたものをインポート、次の日に再度インポートしたとすると、Sunbird上で2つのbasicのスケジュールが表示されてしまう。まっ、仕方ない。古いのを消してインポートするか、icsファイルの名前をユニークにする方法をとるか。後者の方が安全かな。

Palmのデータ(ToDo)を、順次Googleカレンダーへ移行している。上のオフラインでの表示も出来るようになったので、PalmでのToDoデータは不要になってきた。他のメモ帳データなども順次移行する予定。なんか、結構な作業だけど、ToDoが目処たったので少し安心。

2月 9, 2008 ソフトウェア, パソコン・インターネット, 品質, 技術 | | コメント (0) | トラックバック (0)

2008年2月 8日 (金)

ISO/IEC 9126-2と4購入

今日は、ISO/IEC 9126-2と4を購入(購入申し込み)。邦訳冊子を個人で。金額考えると、ふ~。

"-1"と"-3"は以前から持ってたけど、出荷判定の寸劇というかメトリクスの勉強のために2と4も購入。イヤー何年もソフトウェア関係に携わっているけど、自腹で買う羽目になるとは思わなかった。いろんな意味で、考える/考えさせられる事ある。

次の改訂版が出る前に、今回買った分の成果が出るか。というか、成果出さないといけないな。

2月 8, 2008 ソフトウェア, 品質 | | コメント (0) | トラックバック (0)

2008年2月 6日 (水)

チューリング賞はモデル検証

今年のACMチューリング賞は、モデル検証がらみ。(正確には、2007年チューリング賞)

http://www.acm.org/press-room/news-releases/turing-award-07/

個人的には、”モデル検証と申しましても、いささか広うございまして、、”。ちょっと勉強して、自分にマッチしそうなのが何か、考えないと行けない。

あっ、念のためだけど、いつもACMのレター読んでるわけじゃない。気になってる人のブログに、書いてあった次第。

2月 6, 2008 ソフトウェア | | コメント (0) | トラックバック (0)

2008年2月 3日 (日)

他社の様子(写真) Googleの中国オフィスとかも

他の会社の様子って多少は気になる。就職しようとしている学生さんにとっては、死活問題でもあるだろう。

で、以下のサイト。百式に出てた。左のクリックでそれぞれの会社の様子が読める。


http://www.officesnapshots.com/

つらつら見てたら、けっこう東洋系の人が多い写真が。どこだろうと改めて見たら、Googleの中国オフィス。

うーん、例えば日本語→中国語の作業するにも、Google Translateでの研究に従事するのと日本製品の中国語化に従事するのとで、職場環境としてはどちらに憧れるかな~。オフショアも職場環境まで意識しないといけない時代なのかもしれない。ちなみに、Google Translateには、現時点では日本語←→中国語はない。

あと、日本(系)企業がないみたい。Cybozu Labsとかが出てもいいんだろうけど。

2月 3, 2008 ソフトウェア, 日記・コラム・つぶやき | | コメント (0) | トラックバック (0)

2008年2月 2日 (土)

開発ドキュメントの妖精 とさ

いやー、「何じゃこりゃ」^.^;という画像。

http://www.thinkit.co.jp/images/article/17/1/3.jpg

今日からの連載。
http://www.thinkit.co.jp/article/17/

「開発ドキュメントの妖精は開発プロジェクトの円滑な運営に寄与すべき」とか、基本的な考え方に同意できない所はある。そもそも、開発プロジェクトメンバーが書くべきだから。(もしかしたら、ドキュメント班と分離してうまく行ってる場合が多いのか、エンプラ系の人たちとの飲み会などで聞いてみよう。)

ただし本シリーズは、ドキュメントの必要性や重要性の理解という意味では、非常に役立ちそう。若い子には、受けがいいかもしれない。能書きを垂れる事しかできない子には、「子供っぽくって悪いけど、自分の実践と比較して簡単なレポートくれない?」とか言って宿題にしてみようかな。

ちょっとウォッチするつもり。(でも、さすがに我々世代には、この記事のマンガ主体のノリや会話は辛いけど。)

2月 2, 2008 ソフトウェア, 日記・コラム・つぶやき | | コメント (0) | トラックバック (1)

2008年1月31日 (木)

サイボウズがASPも ただし、10ユーザから

ついに、サイボウズのASP版が登場。

http://groupware.feedpath.co.jp/

でも、10ユーザから。1ユーザから申し込めて低価格になればいいんだけど、、、。

サイボウズは、(会社で)結構長く使っていて、気に入っているソフトというかシステム。以前から、他のPCとかでも使えると、自分個人のスケジュール管理などに使いたいと思っていた。でも10ユーザーからで、個人持ちには結構効果。

ASPになるとの事で、1ユーザからの料金体系を期待したけど、、、、。残念。

協業を、Google SpreadsやSharePointを使って作業したりしている。ブックマークはGoogle、マインドマップはMindMeisterと、他にもネット系のサービスをいくつか利用している。使いやすいネットサービスが増えるのを期待したい。

1月 31, 2008 ソフトウェア, パソコン・インターネット | | コメント (0) | トラックバック (0)

2008年1月30日 (水)

JaSST'08 東京 出荷判定寸劇など

JaSST'08 東京へ参加。ソフトウェアテストのイベント。

http://www.jasst.jp/archives/jasst08e.html

我々は、出荷判定寸劇を演じる。SQiPを含めると2回目。もちろん劇そのものは内容なども大きく違うので別物なんだけど、発想として観客にも判断をしてもらうというコンセプトは同じ。

P1300023P1300024会場の目黒雅叙園の様子。初めてだったので、日本風の所々に驚く。数年前は、プロジェクトの関係で結構近くで作業していたが、入った事はなかった。朝、駅からの下り道では足痛くなった。結構急勾配。しかも人が多くて、「えっ~、こんなに集まるの?」と思っていたが、近くにできたオフィスビルへの人たちだった。数年前は無かったんじゃないかな。

基調講演は、ケーパージョーンズ。

以下が参考になるかな。

http://itpro.nikkeibp.co.jp/article/NEWS/20080130/292517/

品質の高い組織と低い組織の比較など面白かったし参考になった。いくつかの数値は、実際チェックしてみたい。特にBackfiringと呼ぶ各言語とFPとの変換の話をしていた。以前から変換の一覧はあったけど、Backfiringと呼んでいたか??

実は、昨日もとある所で彼の話を聞いた。昨日とは資料は別。両方ともすごいページで、感服というか頭が下がる。あっ、日本では京都、奈良、下田に言ってといっていた。また宮本武蔵や平家物語を読んだとも。

なお、彼も情報交換会(懇親会)に出席していた。実は昨日も講演後彼にサイン貰う人に付き合った。どちらでも、サイン貰うチャンスあったのに、本持っていかなかった。懇談会に参加するとか、しゃべる時間があるとは明記無かったので、、。(しかも、両方とも結構重いものの持ち運びがあったので、彼の本をしのばせるという発想にならなかった。)

P1300026左は、出荷判定講演直前の会場リハーサルの様子。

リハーサルなどを含めると時間が無かったので、メンバーがおにぎりなどを買ってきて、控え室で食べる。事務局への意見で、昼休みを長くというのも頷けはする。駅周辺に店はあるけど、集中すると食事しにくい。駅方向へは上り坂。でも、休憩時間をずらすなどのほうが良い。時間を長くしてもあの近辺で食事しにくいのは同じだし、休みが長いとテンション緩むし、、。

メンバーのうちの一人のブログ。
http://softwaretest.blog87.fc2.com/blog-entry-37.html

出荷OK/NGのどちらになりそうかを、微妙な状態にしたのも以前と同様。残バグがあるのが、特にポイント。

で、観客の判断は、若干NGが多目。会場の質疑応答でNGと判断した人に理由を聞いたら、回避策の提示が不十分との事。言われて気がついたけど、PPTでも口頭でも、その辺りに触れていなかった。SQiPの時には、ちゃんと触れてたんだけど、、、。

OKにしようとの考えでセリフなどを考えていたので、ミスといえばミス。でも、その分皆さんが注意して聞いてたということで、ありがたい。ただし、出荷判定会議の経験者が3割いたか? これは、ちょっとまずいかも。Web開発とかでもイベント化すべきだ。(あるいは、携わっている製品やプロジェクトに、出荷判定会議とかそれに近いイベントがあるかと聞いたほうが良かったかもしれない。)

またIEC 61508の部分は、そもそも目標基準を明確にしてないとかの会場の指摘があった。そちらは補足説明で乗り切る。(ただし、安全評価の表はあくまで仮想で、フィクションとしても非常に甘い記載。間違いと言われても仕方ない部分ではあるが、これは一般製品への適用という意味ではちょっと課題かな。)

反省すべき事項が少なくなかった。劇を演じるメンバーの数や時間の関係もあるので、更に難しい。特に今回は、リハーサルなどで寸劇自体の時間を短くする必要があり、皆の頭がそちらに行ってしまったのも大きな反省点。前段の説明などを短くするなど工夫すればよかったというのも、劇の後の意見。

また、もっと”出荷判定とは”の原点に立ち戻って、ドキュメント化するなどの提示方法もあるなとの意見も。寸劇メンバーで、ネット上のマインドマップツールを利用して、多少リストアップしてるけど充実していく予定。


午後の講演で、まずはWebの性能チェックツールの話を聞く。実務じゃないし、1つのツールの説明だったので、自分にはさほど有益となならなかった。

その後が、「モデル検査ブートキャンプ」。VDM++ VICEなどだと良かったんだけど、関西電力での説明は別の手法。逆に、ちゃんと色んな手法の長所などを知らないといけないと痛感。富士ゼロックスでの説明で質問あったけど、時間の関係でカット。オーエスエー・リミテッドの説明は、ループのモデル検査には有益。ただし、こっちの思っているモデル検証の範疇とはちょっと違う。C0/C1の延長がいいかな。

なお、富士ゼロックスの人には、セッションが終わってから質問。xUMLとModel検証用言語との関係(テストクラスなの?)とか並列処理のモデル検証方法。後者は色々工夫しているとか、まだ不十分? 引き止めるのも悪いと思い、他のモデル検証も含めてウォッチかな。なお、関西電力でのツールのCDを配っていたけど、質問の関係もあってもらえず。ダウンロードして試すか、、。

とにかく、実はJaSSTへの直接参加は初めて。色々有意義だった。次回は2日とも参加しようかなと思う次第。


情報交換会や会場で見知った人たちと会う。顔を合わすのは半年振りの人もいて懐かしかった。交換会や会場で、懇談できなくてすみません。また、酔ったせいとか講演を聞いてなかったせいもあって、失礼な対応となってしまった人もいて超反省。メール来たら謝らないと、、。


なお、寸劇メンバーや知った人等とカラオケカラオケへ。結構メンバー増えて、終盤に来た人を含めると14名。たまたま雅叙園の出口で、別の人の知り合いだった関西からの人も合流。

結局3時間も皆で唄う。

実は、カラオケへは目黒雅叙園の出口で予約して行った。ビックエコー。同じ会社の若い人がたまたまいたので、予約してもらう。昨日の朝に調べた場所に行ったら、予約を受けてないとの事。100メートルくらい駅寄りの別の支店だった。

予約の時は、携帯の情報サービス経由。目黒駅周辺は携帯のサービス上は一店だったみたい。カラオケ屋さんがどんどん増えていくのに、情報が追いついてなかったのか、、、。繁華街の場合は、カラオケ屋さんに予約するとかメンバーと合流する時の連絡の時は、場所を的確に言うなど気を付けないとつい思ってしまった。

1月 30, 2008 ソフトウェア, 品質, 科学技術 | | コメント (3) | トラックバック (1)

2008年1月25日 (金)

デザインウェーブ 2006年12月号

今日、会社の本屋さんでTVガイド誌を買おうとしたら、「ほんださん、本届いていますよ」と店員さん。あれっ、何か頼んでたっけ?と言ったり、店員さんとのやり取りで判明。雑誌のバックナンバーを頼んでいた。デザインウェーブマガジンの2006年12月号。電話も無かったし、最初”本”と言われたり、ちょっと考え事してたこともあって、すぐに思い出さなかった。

受け取って、早速席で読む。

特集1が、”組み込みシステムの信頼性と安全性を高める”。そして特集2が、”冗長設計で事故・故障を防ぐ”。

特集2の方は、ハードウェアの話なのでソフトウェア設計の人にはあまり関係ないかもしれないけど、ハード屋さんと話する時に役立つことがあるかも。事例が15も記載されている。例えば事例4は、”使わない端子や機能も定義しておく”。自分の経験では、まっ優秀でトラブル少ないハード屋さんはやってること。再現性が乏しい現象が発生してて、ハードとソフトのどっちかと揉めて原因探ったらプルアップ/プルダウンしてない端子のため。そんなことは2,3回はある。

で、特集1が面白い。IEC 61508の話はもちろんだけど、アーキテクチャ記述言語の話やMISRA-SAの話なども。分野も、鉄道や宇宙機器、人工呼吸器の話など様々。文も平易。

もう1年以上前の雑誌で、最初バックナンバーがあるか不安だったけど、ラッキーなことに手に入った。

安心・安全のソフトウェアについて考えるのなら、電気電子やメカの雑誌とか本も参考にしたほうが良さそうに感じる次第。


1月 25, 2008 ソフトウェア, 品質, 安心・安全, 技術 | | コメント (0) | トラックバック (0)

2008年1月24日 (木)

Office2007ファイル互換機能をダウンロード

今日は、Office2003ソフトでOffice 2007ファイル(.xlsxなど拡張子が4文字で末尾にx)を開けるパックをダウンロード。

http://office.microsoft.com/ja-jp/products/HA101686761041.aspx

使っているいくつかのPCのうち、1台だけOffice2007にしている。ただし、Office2007には、「Backup to 2003」というソフトを入れて、Office2003の操作性に近いことが出来るようにしている。

とにかく、Office2007は、ある意味最悪ソフト。いろいろ機能が上がっているのは分かるけど、ああも操作性が旧バージョンと違えば頭イライラ。しかも、なんかボタン等の位置に脈絡があるように思えない。思考力が止まってしまう。

しかも、Office2007にしているPCは、WindowsXP Pro。シャットダウンの度に、更新版インストールの旨が出る。以前は1週間に1回くらいと思っていたが、今はほぼ毎日。これがまた、頭にくる。早い話、Office2007の自動パッチ配布なんだろう。なんか、馬鹿にされてるみたいな気にすらなる。(Officeのバグ修正だけじゃないのかもしれないけど。)

で、先ほどのをソフトを、Office2003のPCにインストールしてみた。どんな感じで使うのか、良くわからなかったがまずはインストール。Office2003での操作で、ファイルを開くに.xlsxなどのファイルタイプが表示された。つまり、Office2003での操作で、.xlsxなどのファイルを開ける。保存もOK。

開く際に時間かかるし、今までのファイルを開く時間よりも表示までの時間が長くなったような気がするけど、後者は勘違いかな。

今まで、自分での作業でOffice2007上でOffice2003形式での保存をしたけど、そのまま保存して上のソフトを利用してOffice2003で作業することになると思う。多少気分的に楽になった。

1月 24, 2008 ソフトウェア, パソコン・インターネット | | コメント (0) | トラックバック (0)

2008年1月18日 (金)

情報処理学会集中セミナー「インターネットと放送」

今日は、情報処理学会の短期集中セミナー「インターネットと放送」へ参加。化学会館7F。

狭義のIPTVと一般的なインターネット放送をあつかったもの。3,4年前も似たセミナーがあったと思うが、それよりも少し技術系から離れていると案内の時にも感じてた。でも、内心結構技術系の話に行くだろうと思ったんだけど、、。

実感としては、2/3程度が非技術系と感じた。もちろん、ヨーロッパや南米でのインターネット放送や、韓国ドラマとネット配信の関係など知ってた方が良さそうな事項も多かったが。

限定配信やFullHDへの対応(圧縮とかコンバージョン)の技術的な討論めいたものを期待したが、ちょっと触れられた程度。少し肩すかし状態だった。

隣の席にウェラブルPC?を身につけた人が。「へー、まだそんな人がいるんだ」とか「研究してる人には、学会でのアピールにはいいのかな」程度に思っていたが、落ち着きない様子。ガサゴソガサゴソ。ドンドン。席は結構空いてたのに。終わり近くじゃ、少し誤ってた。

また、講演者が、WOWOWとかCS放送受信している人がどれくらいいるか挙手してもらっていた。それぞれ数人。こんなセミナーに出席する人の割合としては少なすぎと感じた。


蛇足:初めて化学会館に入る。壁に会館建設のための寄付者名が記載されていた。個人名が結構多い。こう言うと変だけど、化学会館に間借りしなくてはいけない情報処理学会って何だろうと感じた。IT,ITって騒ぐけど、電気学会なども間借り?? 「古臭くないんだよ」と言われたらそれまでだけど。

1月 18, 2008 ソフトウェア, テクノロジー, パソコン・インターネット, 科学技術 | | コメント (0) | トラックバック (0)

2007年12月30日 (日)

日経エレクトロニクス 「かっこいいソフトウェア」

日経エレクトロニクス12月31日号の特集は、「かっこいいソフトウェア」。副題は、”人海戦術より「あこがれ」づくりを”。

日経エレクトロニクスって、今までもテスト志向や形式手法とかを特集したりと、結構先覚的?な事も取り上げている。その価値は十分認めた上での感想を。

冒頭は、TVを前に設計したことを誇らしげにする人と、もう片方のページはTVの組込みソフトを作ったという人。前者では、子供が「うわーお父さんスゴーイ!」。後者では「ふーん」。組み込みソフトウェアへのあこがれが、なくなっているとの問題意識。

記事では、上流設計やアーキテクトや教育の重要性に触れている。ソフトウェア技術者にとって参考となる部分も少なくない。

が、この本って、本来はハード屋さん向け。となると、その人たちの意識を変えるのが先じゃないのとふと思った。時々組込みの人と飲んだりすると、それに関する話題も少なくない。本記事でいうと、例えば、P86の問4の「報酬は、やりがいがあればそれほど問わない」に対して、そう思うは3割。7割が、そう思っていない。記事では3割が、報酬よりもやりがいを重視してると書いているが、逆に7割は報酬で報われてないと感じているという事。

ハードのお陰で、かっこいいソフトウェア構造が、めちゃくちゃになっていくのは想像に難くない。その意味で、”かっこいいソフトウェアにするために”、ハード(やメカ)屋としてどうしたらいいかと踏み込んでも良かったんじゃないかな。

といいつつ、バグなどでソフトウェアは、まだまだ分が悪いんだけど。


ちなみに、P62では、リコーの新人教育に触れている。見出しでは入社後1年間にわたってオブジェクト指向分析を教育。

なお、ネットで詳しく知ろうとしたら、以下の関連会社のページを発見、。
http://www.ricoh-soft.co.jp/recruit/graduate/education/index.html

情報処理のプロジェクトマネージャーの方が、PMPより高ランクとしている。プロジェクトマネージャーなどで奨励金100万円。ちなみに技術士(情報工学部門)で50万円。

12月 30, 2007 ソフトウェア, テクノロジー, 技術, 技術士, 書籍・雑誌 | | コメント (0) | トラックバック (0)

2007年12月16日 (日)

コマツの「KOMTRAX」

今日のTBS「がっちりマンデー」は、建設機械・重機械のメーカーのコマツ。登場は、社長の野路氏。

で、車両情報システムの「KOMTRAX」(コムトラックス)も紹介された。各車両の場所とかガソリン消費量とかが世界地図上で分かるというもの。部品の消耗量も分かるので、サービスマンへの情報にもなる。

また、作業員のサボりとか盗難も判明する。(盗難だと、通常の建機車両のスピードと違う。) 遠隔操作で、エンジンかけられなくすることも可能とか。

システムの事を冗談を交えてしゃべっていたが、実際はこのシステムがコマツの回復を支えたのかもしれない。ある意味では、企業でのキーとなる技術。情報システムが企業を支えたり番組に登場するのも見るのは、情報系の技術者としては、ちょっと嬉しい。

なお、「KOMTRAX」での画面で、マンハッタン等での様子は多分実際のデータ。が、なぜか中国は国全体が赤く塗られていた。どれくらいの車両が売れているかを、伏せたかったのかもしれない。台数よりも地域か、、。


ちなみに日経コンピュータ2007/09/03号に、野路氏とのインタビューが掲載されている。「KOMTRAX」にも触れている。”建設機械はソフトの固まり”との見出しもあり、制御ソフトは内製とのこと。制御ソフト=競争力の源泉とまで述べている。

12月 16, 2007 ソフトウェア, テクノロジー, 技術, 映画・テレビ, 科学・技術, 科学技術, 自動車 | | コメント (0) | トラックバック (0)

2007年11月 3日 (土)

プリンタ複合機や車のECU

今日は、勉強会というか打ち合わせというか、ソフトウェアテスト関係の会合。普通のプリンタを題材とした。一度プリンタ複合機が話題となったが、「ちょっと複雑だから」とのことで今回は題材から外した。

プリンタ複合機って、FAX、コピー、そしてプリント機能が一体化している機械。ネットワークでつながれ、皆で共用しているケースが多い。今やちょっとした企業でのオフィスでは、当たり前となった。

駅からの帰りで、ふと次のような事を思った。「あれっ、複合化するということは、ソフトは共有にするということ。開発の組織形態はどうすればいい?」 例えば、FAX開発部、コピー開発部、プリンタ開発部があったら、複合機のための組織はどうしたらいいかの自問自答。(あっ、とても○○部で済むような規模じゃないだろうけど。)

ある部の中の組織とするか、各機器とのインタフェースなり整合性の確認を行う部署を作るかのどちらかだろう。大なり小なりの、派生的な形態はあるにせよ。

また、ご存知のように、アナログのコピーとプリンタの感光ドラムの極性は逆。つまりアナログコピーの時は、光が当たらない所にトナーがくっつく。プリンタは逆で、光が当たった所にトナーがくっつく。コピーがデジタル化する時にはプリンタと同じ極性にする必要がある。きっとその時、喧々諤々があったと思われる。色んな所を逆化しないといけないので。その意味では、大きな技術課題を克服してきた風土があると言える。


更には、車のECU(電子制御ユニット)にも思いをはせた。レクサスのような高級車では100個程度とか。認識として重要なのは、基板(ソフト)の交換とかでは、100個の中の1つや2つが交換されるという事。また、車種ごとに全部を作り変える事はしないだろう。場合によっては、いくつかのシリーズでECUの共有化もありうるのかもしれない。

となると、ECU間のインタフェースを徹底的に規定する事になる。またそのための検証ツールにもパワーを割く。(ハード系の検証ツールなり、ECU向けの検証ツールはネットでちらほら見れる。)

こちらも横断的な組織とか、開発手法の共有化などが行われている事を示す。ソフトの再利用を叫ぶのは簡単かもしれない。が、その上での組織変更とか、共有化のインフラをどうするかの検討が必要だ。それを克服しないと実現は無理となる。プリンタ複合機や車を見たら、あの中のソフトはそれらを克服した証と意識する事にしたい。

11月 3, 2007 ソフトウェア, テクノロジー, 科学技術 | | コメント (0) | トラックバック (0)

2007年10月11日 (木)

情報処理学会 論文誌の印刷物の廃止

今日の情報処理学会からのメール、見出しは「[重要なお知らせ]論文誌のオンライン出版と印刷物の廃止について」。

その部分の内容は、以下で見れる。

http://www.ipsj.or.jp/03somu/kinen_jigyo/50anv/d-library/dl-ronbun-200710kaikoku.html

先覚的とも思える情報処理学会で、”やっとオンライン出版か、遅かったな~」と思うか、「やっぱ紙がいいな~」と思うののどちらだろう。個人的には、身近な出版物だと、後者の感覚が強いかな。

なお、会誌「情報処理」はそのまま紙ベースのようだ。勘違いしてないと思うけど。

論文誌って個人的には斜め読みが多いので支障は少ないだろうけど、やはり歳のせいかな画面で見るのが結構疲れる。

10月 11, 2007 ソフトウェア, 書籍・雑誌, 科学技術 | | コメント (0) | トラックバック (0)

2007年8月 3日 (金)

本「ソフトウェアテスト HAYST法 入門」感想

「ソフトウェアテスト HAYST法 入門」を読んだ。ちょっと時間出来たので、急いで感想を書いとかないと、、、。

この本、ずばり HAYST法の本。この