JaSST東海 参加報告No.1

北の塾長ことおぐちゃんがSIGに誘われたのをきっかけに、自分もおぐちゃんの荷物持ちTEF道として名古屋へ行くことになった。

TEF道とライバル関係にあると言われる名古屋。
キャラの濃さでは完全に負けている気がする(ウソ)
今回は他地方の偵察も込めて・・・

場所は名古屋から20分の刈谷の刈谷市産業振興センター。とてもいい会場でした。
朝から沢山のスタッフが一生懸命に頑張っている。規模が大きいので大変そう。
今回のテーマは「テストの目的を考えよう」でした。

<基調講演>
基調講演は皆さんご存知、ゆもつよメソッドでお馴染みの湯本さん!!
タイトルは「ソフトウェアテスト、一番最初にやるべき大事なこと」。

まずは軽くコメダの小倉トーストの話で会場を暖める湯本さん。
小倉トーストとモーニングセットを頼んだら、さらにパンが半分ついてきて驚いた話。
しかし結局全部平らげて、元気ハツラツらしいです。


1.ソフトウェアテストが直面する課題

最初に現状の問題を分析。
  ・ソフトウェアの大規模化、複雑化によるテスト増大
  ・開発期間短縮化によるテスト工数不足

ソフトウェア開発ではテストが開発のボトルネックになっているとのこと。
IPAのデータよりエンタープライズ系、組み込み系とも~40%くらいとのこと。
1000万のソフトウェア開発であれば、400万がテストになるということかー。
自分が経営者だったら減らしたいと思うだろうなぁ。

ここでテスト工数の増加要因について説明。
気になったのはテストのよくある現状。
心あたりがアリ過ぎて、アリ、アリ、アリアリアリアリアリーヴェデルチだわ ><

 ◇人海戦術
   考える時間を惜しんで人を投入
   時間のある限りひたすらテスト実行

 ◇原始的なテストマネジメント
   エクセルを使ったテストケースドキュメント
   ファイルサーバーでのテストケース管理
   報告書作成が手動転記

うーん やっぱりIT企業が一番IT化されていないのは本当かも(笑
なんとかしたいなぁ。。。


2. ソフトウェアテストの全体像

10年前は良かった開発の一部としてのテスト。
しかし今現在は大規模かつ複雑になっているので、単なるテスト実行というプロセスでは済まされない。テストを創造的プロセスとして考えていけない企業はこれから生き残れないんだと思う。
多くのソフトウェアマネージャーは10年前の自分の成功体験を元にマネージメントをしている。そういうマネージャーにこそ聞いてほしいと感じた。


3. テストは何故やるのか?

テストは何でやるんでしょ?というスライドでは、沢山の人がテストについて色々なことを言っている。実はこれ今回TEF道でSIG用に用意したスライドとそっくり。
基調講演に沿っているって、とてもいい流れじゃないかい?SIGが楽しみ。

ここではテストの「目的」だけではなく、「想い」という言葉が。
テストと人間が近づいている感じがしてとても良かった。
ソフトウェア作っているのも、確認しているのも最後は人間なので「想い」っていうのは重要なんだろうなぁと考えさせられる話だった。


4. テストの目的とは

テストとテスティングの定義を湯本さんが解説。

テストとテスティングを鏡に見立てて説明。これは分かりやすい!!
  テスト:鏡
  テスティング:鏡を使って知る行為

自分が鏡見るときはどうするかなぁ。。。
髪が跳ねていないかなとか、ひげの剃り残しないかなぁとか。
やっぱり何かに注目して見ているなぁと再認識した。

続いて製造業とソフトウェアとの違い。これは自分もずっと考えていること。
「いつも同じものを作るわけではないし、作る必要もない」
製造業とソフトウェアは違うということを説明してくれた。
しかし、もちろん製造業から学ぶところも多いとのこと。確かにリーン開発とかもTPSから来てるよね。

ここで「想い」に続くキーワード「共有」がでてきた。
ソフトウェア開発はチーム戦であり、勝ち抜いていくためには「共有」が必要ということ。
共有のために大事なことで気になった箇所は・・・
  ◇全体像を提示する
    全体像がないとモレや抜けが分からない。
    テストしきれないところはレビューを組み合わせても良い。
  ◇目的と手段の協奏
    具体的な手段がないと・・・妄想
    向かうべき場所(目的)がないと・・・暴走

協奏、妄想、暴走はウマイ!!
今度歌作るときはこれいれようっと!!

今回の発表を通して考えてみるとやっぱり目的が大事だと感じる。
そのテストって何のため?を常に心がけるようにしないとだね。


最後に湯本さんに質問してみた。
「テストをしっかりやったとすると、最初に話していたテストの割合は40%からどれくらいになりますか?」
答えとしては、湯本さんの会社の例ではテスト工程の20%程度削減できましたとのこと。
すなわち40%*20%~10%くらいということですね。
開発者にとっては10%は少ないように見えるけど、経営者から見ると魅力的なんじゃないかと思う。大きな会社であれば、ツール、教育にお金をかけて開発工数全体の10%削減というのは現実的な目標になるんじゃないかな?
開発費年間で1億とすると10%削減すると1000万。事業として年利約30%の投資と考えると、ツール、教育には3000万までかけれることになる。マネージャーの皆さん、ツールや教育は高いと言っているけど、意外にそうでもないんじゃないかい?手戻り、客クレで少しずつエンジニアの工数と心は削られているよ。

 

No.2へつづく

WF開発とアジャイル開発の品質特性の違い?!

JSTQBの勉強会の調べ物をして気になったこと。

 

WF開発とアジャイル開発で目標としている指標が違うこと。

元ネタ:アジャイル開発が重視する品質特性~保守性と移植性

http://forza.cocolog-nifty.com/blog/2012/07/post-1e49.html

 

従来のWF開発で重要視されていた品質特性は機能と信頼性、

一方アジャイル開発では保守性と移植性であること。

 

この記事を読んだときになるほど!と思った。

そしてなぜこのように変わってきたきたのかを自分なりに考えてみた。

 

従来のソフトウェアは、あくまで、何かをするための"道具"であり、ハードウェアの付属品とういう考え方だった。ソフトウェアを自体を楽しむことは少なく、ゲームセンターのインベーダーゲームなどが数少ない"楽しむための"ソフトウェアだったのではないかと思う。

 

一昔前のある装置に搭載されているソフトウェアを考えてみる。

このときは目的が最優先であり、作業者は、如何に間違いなく操作をするかが要求される。このときは言語やCPU、メモリなどの制限により、ソフトウェアから人に近づくことはできなかった。

 

しかし、近年は様々な言語、ライブラリ、CPU、メモリ、HDDの進化により、ユーザビリティ(使用性)が注目されるようになった。コマンドベースだったものがアイコンになったり、iphoneのような自然に近いソフトウェアの動きとソフトウェアが人に近づいているのは間違いないと思う。近頃のソフトウェアをユーザー視点で見ると、目的を達成するだけではなく、ストレスなく使えて、如何にかっこいいということも重視しているように感じる。何かのアプリ探すときとか数個見比べてしまうのはそのせいだと思う。

 

勉強会で品質特性の話をすることがあるが、どういうテストをすれば担保できるか分からない品質特性もある。(自分の勉強不足もあるが・・・)

品質特性の中でも特に感覚に近いユーザビリティ(使用性)は一意にテストができないと思っているものの一つ。例えば使いやすいと感じるかどうかは、その人の置かれている環境で決まってくる。12歳の少年のユーザビリティと80歳の老人が求めるユーザビリティは明確に違うし、しらふの時に求められるユーザービリティと酔っ払っているときのユーザビリティも違う。すなわち効率的にユーザビリティを高める方法はターゲットとする人に実際に操作してもらい、感覚をフィードバックしていくしかない。

また同様に本当に必要な機能というのも使ってみると良く分ってくる。携帯にプリインストールされているアプリの中で8割以上使っている人なんて稀だよね。

 

そうすると、速く変更ができる効率性、保守性(保守性の中でも変更性、安定性)がソフトウェアに求められてくることになる。だからこその小さく作るアジャイル開発であり、効率性と保守性に重きを置いているんだなぁと思った。でもそこで本当に追っているのは必要な機能(機能性)とユーザビリティだなぁと。

 

結論的には、

 ・ソフトウェアの周りの環境が良くなり、ユーザビリティが求められてきた。

 ・ユーザビリティの良し悪しは一意に定義できない。(=テストできない)

 ・必要な機能やユーザビリティの改良を重ねていくためには保守性が必要。

 

もちろん、他にもビジネスの変化が早くなったなど沢山の要因があると思う。

でも個人的にはWF開発とアジャイル開発で求められる品質が違うってことがなんとなく分った気がしたので書いてみた。

 

 

 

 

 

 

 

県庁おもてなし課読了

県庁おもてなし課

県庁おもてなし課

高知旅行に一緒に行ったアニキからもらった一冊の「県庁おもてなし課」という本。

読んでいくと、タダの小説ではなく、ビジネス書にも負けない面白い本だった。

しかもその中に、恋愛、家族愛、郷土愛などが散りばめられていて、ワクワクしながら読めてしまう。

 

ざっくりいうと県のおもてなし課というところに配属された青年が、高知県を観光立国にするために奮闘していき、憧れだった人に認められていくという小説。

 

ビジネス書としてみたときに興味深かったところを書いておく。

 

・(公務員の)想像力の欠如が一番の問題なのだ

  →サービスでもソフトでも同じで、使う人のことを常に考えないと。

     同じところに留まってしまうとロクなことがないね。

 

・知的労働を買い叩く会社は大成しませんき

  →ですね。。。エンジニアの時間を切り売りする時代は過ぎたかな。

 

・後追いには後追いなりの後知恵がつけられる。

  →特許になっていないようであれば、自分なりの工夫を付け加えていくことで

    色々対応できるようになる。

 

・観光地として成熟しているところはトイレに困らない。

  →他の言い方だと「トイレの偏差値」っていう言い回しをしていた。

  

・不便も商品にしている

  →高知の馬路村の話。実際に行ったのだが、確かに村全体がブランドとなっている。

    誰が音頭を取ったのか分らないが、驚きのブランディング

    いまや馬路村のゆず商品は東京の一流百貨店に並ぶほど。

 

北海道も頑張らないといけないねぇ。

もっともっとポテンシャルがあると思うんだけどなぁ。。。

なぜなぜ分析まとめ

なぜなぜ分析10則(=なぜなぜ本)を読んで、気づいたこともあるので、

実際に実施するときのコツなども含めて書いておく。

ちなみにこのまとめはソフトウェア開発に特化して記述している。

 

【心構え編】

・チームを良くするんだということ

・個人攻撃にならないようにすること

・対策までがなぜなぜ分析ということ

 

【準備編】

・開発に使ったソースコード、ドキュメント、議事録等をリストアップする

   >これを事前にやらないと、分析のときにものすごい時間がかかる・・・

・開発に関わった人(=関係者)をリストアップする

   >上司とか、知見者とか、関係あるモジュールを担当していた人など。

 

準備が終わったら、分析を始める。

【なぜなぜ分析-事実確認編-】

1. 不具合によってどのような不都合がお客さんに発生したのかを確認する

 

2. 不具合の発生箇所を参加者で確認する

   >設計、コーディング、影響範囲考慮漏れなどはソースコードに出てくる。

   >仕様バグは要求仕様書かな。

   >これがなぜなぜ本でいう『事象』にあたる。

 

3. その不具合の原因のドキュメントを特定する。

   そのときにレビューの議事録でどういう指摘がされていたなども確認する。

 

4. 以下の絵を描く。

   ・不具合の発生メカニズム

   ・開発プロセスと関係者の絵を描く。

   >この絵がとても重要。

   >複雑な不具合になってくるとそのとき分ったつもりでも、スグに忘れてしまうので

   >絵として残しておく。手書きで十分いける。

   >なぜなぜ本でいうと『原因追求すべき対象をしっかり把握する』にあたる。

 

皆の共通認識が出来上がったところで分析を行う。

【なぜなぜ分析-分析編-】

1. 以下の視点でどうしたら良いかを考える。

 ・作るときに気づくためには?

 ・テストでひっかけるためには?

 ・ソースコードに問題は無いか?

   >一般的には設計書の不備だったり、テスト観点だったり、

   >レビューが不十分だったりプロセス等に落ち着くことが多いが、

   >ソフトウェアの場合はソースがまずいということも多々ある。

   >直ぐに修正できないこともあるかも知れないが、

   >いつか実施するリファクタのために、情報を残しておく。

   >なぜなぜ本の『第9則 再発防止策を見出せるところまで「なぜ」を繰り替えす』にあたる。

 

2. 考えられた対策について、不具合を作りこんだ担当者に確認し、

   対策の有効性を確認していく。ここで、新たな事実が分れば絵に追記していく。

   >出てきた対策を全部やるには時間が足りないので、有効な対策だけに絞る。

   >ここでも個人攻撃は絶対にしないこと

 

3. なぜなぜに参加していないメンバーに絵を使って不具合と対策を説明する。

   ここで客観的な対策になっているのかを確認する。(できればで構わない)

   >なぜなぜ本の『第10則 現場・現物で「なぜ」を検証する』にあたる

 

4. 対策を実行する。

   >テストの観点に追加だったり、次回起きたときにはこうしましょうと決めたり。

   >大事なことはチームメンバー全員が理解すること。

   >『同じ』不具合だけではなく、『似た』不具合を作らないようにしたい。

 

【確認編】

1. 開発のスタイルに合わせて、月1などで対策が実施されているか確認する。

   >このチェックがないと、対策がされない可能性がある。

 

2. 必要なくなったものは確認項目から外していく。

   >対策が肥大化していくのでやらないことも決めていく。

 

 

というところで、最後まで行くとなぜなぜしてないじゃないかということに気づく。

そう!気づいたあなたは天才っ!!

が、個人的には事実確認のところで、頭の中ではなぜなぜをしていることと同じだと思っている。

前回のエントリでも書いたが、なぜを一般的にすると、何を書けばいいのか分らなくなってしまうので、少しシステマティックにできるように書いてみた。

なぜなぜ分析10則読了

会社の不具合分析でなぜなぜ分析を使っているので、『なぜなぜ分析10則』を購入し読んでみた。なぜなぜ分析がやりにくいという声も聞くので、それについても少し考えてみた。

この本はなぜなぜ分析でやりがちな過ちを例題としてあげているので、書いてあることは理解はしやすいかもしれない。ただ、自分でやってみるとどうしようとなってしまう。

結局は『なぜ』という言葉が抽象的過ぎて、何を書いたら良いのかが分らなくなってしまうのが、なぜなぜ分析を難しくしている一因だと思っている。

 

以下、この本でグッと来たところを書き留める。

 

なぜなぜ分析のねらい(落としどころ)は、再発防止策を導くことである。

真の要因を見つけることではなく、再度起こさないようにするところまでが

なぜなぜ分析ということ。確かに原因がわかったら喜んで終わってしまうもんなぁ。

家に着くまでが遠足というのと似ている。

 

ベテランと若手が一緒になぜなぜ分析をすることで、

ベテランの頭にある間違った経験則が正されるとともに、

ベテランの知識が若手に伝わっていく。

これは確かにそうだね。

長くやっていると伝承されたものがあったり、

しかも現象論だった場合は、おまじないに近いものの可能性もある。

ベテランと若手お互いにメリットがあるっていうのはいいことだ。

 

様々なタイプが発生しており、絞込みにくい場合は、目の前の1個に絞り込む

これを究極の1個絞りという(筆者が名づけた)。

複数の要因がある場合は、なんとなく共通点を見つけようとして微妙な分析を

しがちだが、よく分らないときは目の前の一つに集中せよ!ということ。

 

現象を絵や流れ図に描き出す。

頭の回転が速い人だと、議論が空中戦で結論まで行くことが多い。

が、実は勘違いしていることもあるので、絵に描くことは情報を共有化する上で重要なんだなぁと再認識。WACATEの冬で実施したお隣さんを明確にして絵を描きましょうというワークが使えそうな感じ。

  

決して「責任追及」するために分析するではなく、

あくまで再発防止策を導くために実施することを忘れないで欲しい。

これもなぜなぜの導入を難しくしている要因の一つになっていると思う。

担当者に状況確認をする場合に、やはり詰問調になる。

プロジェクトを良くするんだ!という一緒の意識がないとなぜなぜは本当にキツイ作業になる。そしてキツイ作業というのは人間は続かない。。。

 

根拠も分らずにルールを守ろうとすることほど危険なことは無い。

なぜなら、ルールというものは、時の流れに応じて変えていかなければ

ならないものだからである。

これは本当に多い。。。

意味のないルールや昔のルールに則って仕事している人のなんと多いこと。

ちょっと考えればおかしいの気づくはずなんだが。。。

自分もそうならないように気をつけよう。

基本は常に自分で考えることかな。

 

でもやっぱりなぜなぜが難しいことには変わりないので、

後でソフトウェア開発のなぜなぜをまとめてみようと思う。 

 

 

UFOキャッチャー理論

 

今日は気になるランキング1位に輝いた「UFOキャッチャー理論」を説明しようと思います。
これは最適な投資判断をするために必要な理論になります。
(理論というほどエラそうなモノでもないですが・・・)

f:id:nemorine:20120712123057p:plain
皆さん、UFOキャッチャーは知ってますよね?あのぬいぐるみを取るアレです。

では早速質問。
UFOキャッチャーで1000円使いましたが、まだぬいぐるみは取れていません。
あなたは続けますか??それとも止めますか?


いろいろ意見があると思いますが、
情報が足りないのでジャッジできないという人が大半だと思います。
何が足りないのでしょうか?
そうです!!足りない情報はぬいぐるみの位置です。
 ①元の位置からぴくりとも動いていない。
 ②半分くらいまで来ている。
 ③もう落とし口のそばに来ている。

f:id:nemorine:20120712123205p:plain

 

使った金額と位置から、あとどれくらい使えば取れるのかが分かります。
①だと望みなし、②だとあと1000円くらい、③だとあと200円ってとこでしょうか。

そしてもう一つ大事なことは『使った1000円は返ってこない』ということです。
ここで多いのは1000円使ったから、取るまでやるんだと感情的になってしまうことです。
これがポイントです。
1000円はすでにぬいぐるみの位置(=今の資産価値)というものに変換されているのですが、
継続可否の判断はどうしてもこの投資金額に引っ張られることが多いです。

 

本当に必要なのは
 ・今ある資産価値    :いままでの投資により動いたぬぐるみの位置
 ・今から必要な投資額:あとどれくらいの投資でぬいぐるみがとれるのか
 ・モノの価値        :ぬいぐるみは自分にとってどれくらいの価値があるか

具体的に数字で説明しましょう。
<パターン1>
 ・今ある資産価値    :1/2の位置(1000円使って半分まで来ている)
 ・今から必要な投資額:1000円
 ・モノの価値        :2000円
今、止めると1000円の損。取るまでやるとイーブン。
これだと続けてもいいかなと思います。

<パターン2>
 ・今ある資産価値    :1/4の位置(1000円使って1/4動いた)
 ・今から必要な投資額:3000円
 ・モノの価値        :2000円
この場合は今止めると1000円の損。取るまでやると2000円の損。
これはやらない方がいいんですが、熱くなっているとやってしまいますよね?
4000円も使って、取れたのは不細工なぬいぐるみということもあるでしょう。

 

当たり前でしょとバカにしてはいけません。
当事者で渦中にいると意外とできないものです。

こんな言葉を聞いたことありませんか?
 『このプロジェクトは3000万円つぎこんでいるので絶対にモノにしないと!』

何度も言いますが、3000万円は絶対に返ってきません!!!
それは今の資産価値、例えばドキュメントやソースコードやエンジニアの知識などに変換されてしまっています。
今の資産価値をきちんと見つめて、プロジェクト継続/停止の判断しないといけません。
また感情的にならないためには最初の段階でモノの価値、投資額、そしてどこまでの損失は許されるかを決めておかなければなりません。

 

ということで、会社で何か違うかもと感じたときは、一旦頭を冷やして、
UFOキャッチャー理論を思い出してみてください。
もちろん、奥さんがUFOキャッチャーで熱くなったときにも使えます。


ちなみに一般的にはそれまでの投資を惜しみ、投資をやめられない状態は
コンコルド効果サンク・コスト効果として説明されています。

**********************************************************************
コンコルド効果は、心理現象の一つ。
超音速旅客機コンコルドの商業的失敗を由来とする。
コンコルドの誤り、コンコルドの誤謬、コンコルド錯誤ともいう。

ある対象への金銭的・精神的・時間的投資をしつづけることが損失につながるとわかっているにもかかわらず、それまでの投資を惜しみ、投資をやめられない状態を指す。埋没費用の別名。
世界的には"Concorde fallacy"の名称で研究がなされているが、
日本では"fallacy"の訳語が一定しないため"Concorde effect"の訳語が用いられることが多い。
                                                                           Wikipediaより
**********************************************************************

文明はなぜ崩壊するのか読了

文明はなぜ崩壊するのか

 

 

この本では文明が崩壊するときの特徴を考察している。

実際は会社などにも当てはまるのではないかと思った。

例が多いのでそれを見るだけでも面白い。

 

文化が成熟していくほど、色々なものが複雑になっていき脳の処理が追いつかない。

それを乗り越えるにはひらめきが必要であることが述べられている。

 

複雑になったときはミームという見えないものが行動を支配すると書いてある。

必要なのは文明崩壊の予兆にあたる5つのスーパーミームを意識することらしい。

ミーム:人々の間に広く受け入れらている情報、思考、感情、行動のこと。

 

1.反対と言う名の思考停止

 反対だけはするけど、実際にどうしたらいいかは考えない人。

 これは社会でも会社でも沢山いるね。

 反対意見は言いやすいし、合理的な解決のときでも反対するときもある。

 消費税の問題もそうだし、原発の問題もそうかも。

 

 

2.個人への責任転嫁

 問題が起こったときに、誰かひとりのせいにしてしまう。

 これも会社でもいるし、スーパーで子供に怒鳴っているお母さんでもそうだよね。

 最初から見てればいいじゃんって。子供だけのせいじゃないよって。

 この本だと肥満についても個人の問題じゃなくて、システムの問題だって書いてある。

 デブとしては、気になるところ(笑

 

 

3.関係のこじつけ

 因果関係がはっきりしていないものを、さも因果関係があるように扱ってしまう。

 携帯と睡眠障害の関連とか、実際は関連がない、もしくは原因は別にあるのにそう思いこんでしまうということが書かれていた。

 地球温暖化も本当に二酸化炭素が原因で温暖化がおきたのだろうか?

 温暖化が原因で二酸化炭素が増えたんじゃないだろうか?

 

 

4.サイロ思考

 思考や行動を細分化することで情報の共有や協力をできなくなってしまうこと。

 これは家庭でも、会社でもたくさんあるね。

 役所にいって、あっち行ってください、こっち行って下さい。

 電話変わったらまた一から説明しなおしとか。例を挙げればキリがないわ。

 

 

5.行き過ぎた経済偏重

 お金が一番と言う思想。

 ここで面白かったのはチンパンジーにトークン(お金代わり)を持たせて、

 買い物ができるようにした場合に何が起こるかという実験。

 結論的には強盗、売春、闇市場みたいなものまで生まれたらしい。

 人間の問題はここなのかとなんか凄いショックを受けた。

 野生動物と違って、力が強い、羽が綺麗、鳴き声が美しいという基準ではなく、

 人間の強い基準はやはりお金なんじゃないだろうかと考えてしまった。

 

 経済偏重になると効率優先の世の中になる。その一例が出会い系サイト。

 著者は出会い系サイトっていうのはショッピングと一緒だと言っている。

 これは面白い考え方だなと感心してしまった。

 

 

最終的にはこれらを乗り越えるためには、ひらめきが必要であるということ。

訓練をしたり、ひらめきが起きやすい環境を作るというのも一つの方法であるとのこと。欧陽脩が言っていた三上(鞍上、枕上、厠上)が現代でも重要なんだろうな・・・