2014年3月 2日 (日)

劇団メトリ ブログ削除

以前“出荷判定寸劇 「劇団メトリ」のブログ”で触れたが、出荷判定に関する寸劇を面白くするために「劇団メトリ」なるもので活動してた。触れたブログもそうだけど、実体的にはS-openでのSIGでの活動。

S-open自体もなくなって、「劇団メトリ」ブログがそのままというのもおかしいかなと思い、削除することにした。ぼかしてはいるものの、発表の写真とががこの後もずっとそのままになるのは芳しくない。Googleグループなども同様に削除した。

先週くらいからメンバーに、削除予定の旨のメールを出したけど、やはり数年経ったせいかメールエラーになるアドレスが発生した。一部の人とは、TwitterやFacebookでの繋がりがあるが、逆にここ数年でコミュニケーション手法が様変わりしたと言うことでもある。

寸劇での発表では札幌に出向き、ついでに観光した想い出なども懐かしい。ブログ削除はちょっと寂しい気もしたけど、仕方ない。

3月 2, 2014 出荷判定 | | コメント (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年3月16日 (金)

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

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

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

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

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

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


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

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