2つ目の施策の結果：テスト設計テンプレートガイドを作成することで、テンプレートの概要と期待される効果の周知、使い方のバリエーションの周知、ユースケースやマインドマップとの併用方法の周知ができた。 #jasst10tokyo

posted at 11:04:19

テスト観点について、利用者が〃迷わずに〃使えるようになった。←すげー。　 #jasst10tokyo

posted at 11:05:21

効果のまとめ：1. 使いやすくなった（テスト観点には、もう迷わない！）。2. モレ・ばらつきがさらに減った。3. 現場に導入しやすくなった。 #jasst10tokyo

posted at 11:07:57

会場質問（永田さん）：テンプレートは形骸化しやすいが、そうさせない工夫を知りたい。 #jasst10tokyo

posted at 11:11:21

回答：コミュニティにフィードバックを受けて進化させていきたいと考えている。 #jasst10tokyo

posted at 11:11:49

司会質問：ガイドの量が多くなってきていませんか？そうすると今度は読まれなくなったりすることはありませんか？？ #jasst10tokyo

posted at 11:12:53

回答：端的に分かる粗いガイドと、詳細なガイドを分けるとよい。 #jasst10tokyo

posted at 11:13:41

司会質問：教育については。 #jasst10tokyo

posted at 11:14:09

回答：やっていきたいなと。 #jasst10tokyo

posted at 11:14:22

4つ目の発表は、TISの東條さんの「大規模開発プロジェクトにおける性能テストの実践方法」です。 #jasst10tokyo

posted at 11:15:38

今回のプロジェクトの特徴は、某社向け基幹システムの更改（数千人月、ピーク時には数社、数百人が同時作業）。開発はコンポーネント化を推進。ウェブ画面だけで三千画面ある。 #jasst10tokyo

posted at 11:18:08

さらに、「性能要件厳守」要求が高かった。 #jasst10tokyo

posted at 11:18:51

そこで、次の重点対策を実施した。1. 体制、2. 業務分析による重点絞り込み、3. 性能目標の設定、4. 性能問題の早期発見、5. 本番運用を想定した負荷テスト。 #jasst10tokyo

posted at 11:20:47

体制では、性能対策専任チームを作った。 #jasst10tokyo

posted at 11:21:39

業務分析（アクセス頻度の分析と重要ドお分析）した結果では、性能のリスクが高い画面は40に絞れることがわかった。そこに集中した。 #jasst10tokyo

posted at 11:22:52

性能目標の設定では、現行システムを参考に3秒ルールを作ってやった。 #jasst10tokyo

posted at 11:23:40

性能問題の早期発見では、すべての業務ロジックが存在する画面についておこなった（40画面だけというわけにはいかない）。早い段階で、データベース（SQL）に関する情報を集めて、机上で性能を見積もった。0.0x msec単位で見積もった。 #jasst10tokyo

posted at 11:25:39

性能問題の早期発見で、40%位の箇所に問題（性能目標を満たさない）を発見し、対策を施した。開発者に性能問題を認識させることができたのが最大のメリットであった。 #jasst10tokyo

posted at 11:27:26

その結果、アプリロジックの変更（45%）、DB設計の見直し（20%）、性能目標の再設定（5%）、残りの30%はテスト環境依存の問題であった。←単体テストレベルでここまで発見して対策を入れることができ、システムテストに致命傷を持ち越さなかった。 #jasst10tokyo

posted at 11:30:05

本番運用を想定した負荷テストの実施では、アクセス比率が同程度の画面をグループにまとめ画面遷移を決定して実施。また、サーバ上のログを取り込みグラフ化することで、全体的な視点で95%が性能目標に収まっていることが可視化できた。個々の問題は別表で確認した。 #jasst10tokyo

posted at 11:32:44

本番運用を想定した負荷テストの実施では、単体テストレベルでほぼ問題がつぶせていたので実際には、スムーズに進んだ（想定の範囲内に収まった）。←おぉ。理想的な展開ですね。 #jasst10tokyo

posted at 11:34:14

今後は、他のプロジェクトや小型のプロジェクトにも展開したいと考えている。 #jasst10tokyo

posted at 11:34:59

まとめ、1. 開発メンバーへの意識付けが重要。2. システムテストから始める人が多いが準備段階での机上検証、単体テストレベルでの検証が重要である。 #jasst10tokyo

posted at 11:36:14

会場質問：テストを行う環境について配慮したことはなんですか？ #jasst10tokyo

posted at 11:38:05

答え：単体のベースでは色々な拠点で開発をしていたので、回線が細い場合もあった。クライアントのレスポンス目標に反映しておいた。 #jasst10tokyo

posted at 11:38:51

質問：大規模な場合、本番のハードウェアを整えられないときがあるがどう対応したのか？ #jasst10tokyo

posted at 11:39:35

回答：今回は、ハードも同時納品だったので問題はなかった。シミュレーションを用意している組織もある。 #jasst10tokyo

posted at 11:40:18

質問：残りの20%の中身はなに？ #jasst10tokyo

posted at 11:40:53

回答：月に１回しか叩かれないような画面の性能については、お客様とテストしないことの合意をとっておいた。 #jasst10tokyo

posted at 11:42:06

A5セッション終了。休憩開始。 #jasst10tokyo

posted at 11:42:32

覇道キターッ #jasst10tokyo

posted at 14:22:24

一番重要なことは、ソフトウェアの特徴（きにしなくてはいけないこと）を正しく理解すること。 #jasst10tokyo

posted at 14:23:49

最初は、みなさん目的を見ているがそのうちに手段に置き換わってしまう。「これやっててどうやって最期まで行くの？」と聞いて答えられない人がいる。 #jasst10tokyo

posted at 14:25:01

早くやろうと手抜きをする。「大丈夫」というが大丈夫じゃない。 #jasst10tokyo

posted at 14:25:48

新しくリセットしてやるのはいいことだけど、まずは、先人のノウハウを使うことを考えましょうよ。 #jasst10tokyo

posted at 14:26:42

「品質」とはお客様の満足が最終ゴールであることは共通の定義ではないか。お客様がいること。 #jasst10tokyo

posted at 14:27:52

要求とは明示的物だけでなく暗示的な物も含まれる。「お客様から言われてないからいいんだよ」という人がいるが、そんな言葉を聞くと非常に頭に来る。それで、満足がえられると思っているのか？そんなことをいう人は技術者としてのレベルが低いんですよ。 #jasst10tokyo

posted at 14:29:47

「品質は誰かにとっての価値である」（by ワインバーグ）という言葉がある。立場によってニーズが異なることを理解すべき。 #jasst10tokyo

posted at 14:30:54

時間の経過によってもニーズは変化する。 #jasst10tokyo

posted at 14:31:35

結果（製品）がよければよいと思いがちだが、プロセスが良くないと品質は損なう。 #jasst10tokyo

posted at 14:32:28

「広義の品質（製品だけではなく、仕事・サービス・工程・人、といったすべての品質）を管理していく」（石川）。これが大切。 #jasst10tokyo

posted at 14:33:48

ソフトウェアの特徴は、「1. 人間的要素」の影響が大きいこと。「私はここまでが役割。あとは知らない」って区切って仕事をすると上手くいかない。間に落ちるものがでてしまう。モチベーション、コミュニケーション、リーダーシップ、、、そういう人的なことが大切。 #jasst10tokyo

posted at 14:36:23

「2. 変換を繰り返して作っていく」、全部が書けているものはない（あるとしたらプログラムのみ）。行間があることを理解すべき。行間を伝える努力をする必要がある。 #jasst10tokyo

posted at 14:38:51

「3. 自由度が高い」。素人でもプログラムが書ける。でも「こういうことがプロと違う」ということといっていかないとダメ。 #jasst10tokyo

posted at 14:39:54

「4. 目に見えない」。UMLで同じ技法で作るようにしたら、成果物の違いが見えるようになった。文章だとAさんとBさんのアウトプットの違いが見えない。なぜなら読む方で行間を読んで補間してしまうから。標準化のメリットのひとつ。 #jasst10tokyo

posted at 14:41:41

プロジェクトと組織とは、違うもの。プロジェクトは独自（一回だけ！）の成果物またはサービスを創出するための期限が切られた活動、組織は、継続して繰り返して成功することが期待されている。 #jasst10tokyo

posted at 14:45:31

品質という王道を行くとは、品質のみを追求するという意味ではない。品質を追求すればコストも納期も改善するということ。品質を追求すると、後戻りが減るのでコストや納期が短縮する。何度も経験してきた。 #jasst10tokyo

posted at 14:52:41

ユニットテストを手抜きするとフィールドバグは確実に増えるというデータがとれた。 #jasst10tokyo

posted at 14:56:55

オフショア開発改善事例の紹介。数値目標として「品質」、「生産性」、「日本語力」、「コスト削減率」をとって活動した。 #jasst10tokyo

posted at 15:01:28

誉田さんの勤務先である府中のやり方をオフショア先に指導して２年後に目標値を達成する計画を立てた。PDCAを回すことも計画した。 #jasst10tokyo

posted at 15:03:38

品質３倍、生産性３倍、日本語力３倍、コスト削減率１４％改善できた。上手くいった。上流工程の改善を指導するとオフショア先マネージャは「そんなことをしていたら生産性が守れない」とずっと言っていた。 #jasst10tokyo

posted at 15:05:45

といっていた、中国人の課長さんだったが、２年後は「上流工程からちゃんとやることが大切だ」と言うように変わった。 #jasst10tokyo

posted at 15:06:35

オフショア先の会社は、さらに２年後に、CMMI Level 5を取っている。 #jasst10tokyo

posted at 15:07:36

次の事例。「データ」は現場を補足するために使う。 #jasst10tokyo

posted at 15:08:19

２つの組織があり、どちらもV字のプロセス。様々なデータ比較。数値データのみから予測することは非常に困難である。数値データだけでなく現場で実際に起きていることを把握した上でデータを使わないと見間違う。 #jasst10tokyo

posted at 15:13:59

レビュー工数を掛けると、品質があがるという相関があることが分かった。テスト工数、テスト項目数も同じく相関があった。 #jasst10tokyo

posted at 15:17:39

レビュー工数、テスト工数、テスト項目、、、基準値を決めて、その基準値に達したら止めてしまうという基準値遵守型組織は、立派ではあるが、「基準値を守ればいいじゃん」って形骸化すると品質が落ちる。 #jasst10tokyo

posted at 15:24:04

「1+n施策」とは、NEC用語で、１件バグがでたらなぜなぜ分析してｎ件問題を発見する。 #jasst10tokyo

posted at 15:24:34

「1+n施策」という同じ施策をしても、組織が違うと結果が違う。やれと言われたからやっている組織では成果がでない。必要性を感じてねちっこくやった組織で効果が上がっている。 #jasst10tokyo

posted at 15:28:26

つまり、「品質中心の組織文化が高品質を継続的に維持向上するための基盤を提供する」ということ。対極にあるのは「丸投げ文化」（ルールだから実施している、基準値を守ることが目的に成っている、QCDの優先順位が場面で変わる）。 #jasst10tokyo

posted at 15:30:46

本質を理解し、決意を持って狙いを達成すべく品質改善の正攻法に則って行動すること。同じ施策をやっても成果がぜんぜん違う。 #jasst10tokyo

posted at 15:32:38

会場質問：群馬高専、須田さん、All-pair法を義務付けたを失敗例としてあげているが、これは王道だと思う。３因子間の問題がでたのはしかたない。 #jasst10tokyo

posted at 15:35:28

回答：おっしゃるとおりだと思うが、レビューする、考えることが足りなかった。 #jasst10tokyo

posted at 15:36:10

会場質問：永田さん。オフショアのところで誉田さんが取られたマネジメントはボトムアップか？トップダウンか？？　価値観が異なる場面でのマネジメントは大変だったと思うがどうやって王道へ向かうリーダシップをとったのか？？ #jasst10tokyo

posted at 15:38:19

回答：役員からの指示として「相手が自分からやっている気にさせろ。彼らの提案を受けるようにせよ」と言われ、守った。また、今まで男性しか行っていなかったのでびっくりされたが目にみえるようにコミュニケーションをとったことが良かった。人間的な信頼関係もとれた。 #jasst10tokyo

posted at 15:41:17

回答：１つ成功事例を作ること。 #jasst10tokyo

posted at 15:41:36

NECの誉田さん、基調講演者のジョハンナ・ロスマンさん、日立ハイテクノロジーズの飯泉さんの３名のパネル。司会は塾長の吉澤智美さん。 #jasst10tokyo

posted at 15:55:23

飯泉さんが、ご自身のバックボーンを説明中。医療関係の装置のソフトウェア開発を１５年、オフショア開発９５年から、ソフトウェアの品質改善１０年以上。開発プロセスの改善、国際調達品質向上、品質改善を実施してきた。 #jasst10tokyo

posted at 15:58:39

会場からいただいた質問をお題とします。１つ目の話題は、「テストエンジニアのステータスやキャリアパスについて日本とアメリカとの違い」について。 #jasst10tokyo

posted at 16:00:43

ジョハンナ：アメリカでは正規社員であることが多い。唯一の例外は政府機関（短期的に下請けから採用することはある）。テスターが何をしているのかの透明性が確保されている。キャリアパスも確保されている。 #jasst10tokyo

posted at 16:04:01

誉田さん：テストエンジニアの資格はありますか？ #jasst10tokyo

posted at 16:04:41

ジョハンナ：ISTQBはその立場を確立するまではいたっていない。コンピュータ科学・数学の教育を受けること。あえて、テストスクリプトを走らせる人とテストエンジニアは分けて考えている。開発者と似たトレーニングを受けている。 #jasst10tokyo

posted at 16:06:17

誉田さん：NECには、NCP（NEC Certified Proffesional）というキャリアが定義されている。品質エンジニアの資格はあるが、テストエンジニアの資格は今はまだない。何が出来ていたらプロといえるか定義が難しい。 #jasst10tokyo

posted at 16:08:30

吉澤さん：会場の方に聞きます。みなさんの会社でそういった職種はありますか？　　→　手をあげたひと一桁でした。 #jasst10tokyo

posted at 16:09:52

飯泉さん：ソフトウェア開発者にも無いかもしれない。 #jasst10tokyo

posted at 16:11:07

飯泉さん：会場の方に聞きます。テストエンジニアのキャリアの定義が無いことはわかりましたが、ソフトウェア開発者のキャリア定義はありますか？　　→　会場で２０名以下でした。 #jasst10tokyo

posted at 16:12:40

飯泉さん：テストの組織があるところは、たとえ資格は定義されていなくても、テスト技術者のプライドをお持ちだと思います。 #jasst10tokyo

posted at 16:14:08

ジョハンナ：国防省のシステム開発をしていたときに、将軍がきて、急にテストをすることになって大きなバグが出て恥ずかしかった。開発者とテストを分けた方が良いと思った。 #jasst10tokyo

posted at 16:16:27

飯泉さん：自分の書いたロジックをテストすると思い込みの排除が難しい。ただ、努力すればある程度までは行ける。 #jasst10tokyo

posted at 16:17:38

吉澤さん：誉田さんと飯泉さんは分ける必要が無いと言う意見で、ジョハンナさんは分けろといっているという意見でいいですか？ #jasst10tokyo

posted at 16:18:34

ジョハンナさん：はい。開発者は上手く作動する方に頭が動いてしまう。 #jasst10tokyo

posted at 16:19:35

誉田さん：分けた方がよいかどうかは、ケースバイケースと思うが、キャリアパスについては「出来る人、出来ない人」がはっきり分かるようにした方がいいとおもう。だから、JSTQBも頑張ってほしい。 #jasst10tokyo

posted at 16:20:55

吉澤さん：結論として、日本とアメリカの違いはあると言うことで。　　←　おい。３人の個人的な体験で般化しちゃっていいのかよー？？ #jasst10tokyo

posted at 16:22:18

次の話題。オフショア開発で成功するコツ。 #jasst10tokyo

posted at 16:22:50

誉田さん：相手のことをわかって、ケアするしレビューする日本人は上手くいくが、「ここまで教えたらもういいだろう」ってタイプは上手くいかない。仕組みを回す人が代わっても上手く行くようにする。 #jasst10tokyo

posted at 16:25:03

飯泉さん：オフショアテストに話題を絞ると我々の常識（当たり前）や期待値を伝えることに尽きる。インド相手の経験によると鈴木さんの午前中の発表の通りだと。伝え方は、工夫する。確認して欲しいことをしっかりと言う。自分達の品質が高いことが前提であるが。 #jasst10tokyo

posted at 16:29:15

ジョハンナさん：何をオフショアするのか？　テストの経験もない人を当てられてしまう場合があるから、テストだけをオフショアするのではなく、開発の一部（機能単位）でオフショアする。 #jasst10tokyo

posted at 16:31:53

ジョハンナさん：テストを自社でやる価値のない部分と考えてオフショアすると、痛い代償を受けることになる。クロスファンクショナルチームを設けてある塊でだすべき。 #jasst10tokyo

posted at 16:33:33

飯泉さん：アタリマエのことを伝えるのではなく、品質の期待値を伝える。 #jasst10tokyo

posted at 16:33:58

誉田さん：クロスファンクショナルチームってなに？ブリッジSE（間に入って要求をオフショア先に伝える）という職種があるのだけれど、同じ意味ですか？ #jasst10tokyo

posted at 16:35:41

ジョハンナさん：若干異なります。ユーザ企業、オフショアどちらにもすべての職種を持つチームがある。 #jasst10tokyo

posted at 16:37:19

吉澤さん：アメリカにブリッジSE必要ですか？ #jasst10tokyo

posted at 16:37:49

ジョハンナさん：英語を話すオフショア先だけではないので、ブリッジSEは必要。 #jasst10tokyo

posted at 16:39:49

飯泉さん：気づいてしまったのだけれど、テストが付加価値がないという話を聞くと、オフショア先はそう思っていると言うことでしょうか？ #jasst10tokyo

posted at 16:40:58

ジョハンナさん：実は最近ハーバードビジネスレビューかマッキンゼーで読んだのだけれど、オフショア先に出していた仕事がアメリカに戻ってきている。お金がかかるにも関わらず帰ってきた製品の品質が悪いから。ブリッジSEや品質の定義が足りなかったからだと思う。 #jasst10tokyo

posted at 16:43:03

誉田さん：それはオフショアは上手くいかないとわかったといってよいのか？ #jasst10tokyo

posted at 16:44:08

吉澤さん：誉田さん、そんなに興奮するのは誉田さんも同意見と言うことですか？ #jasst10tokyo

posted at 16:44:42

飯泉さん：私もオフショアは甘くないと考えている。誉田さんのところでも２年もかかって、あ、失礼。立派な会社であっても集まったメンバーの質などをケアしながらやっていかないとだめ。ケア＝手のかかる子なんです。 #jasst10tokyo

posted at 16:46:31

誉田さん：そのとおりだと思っていますが、日本で必要な人数が調達出来ない現状で、なんとかしなくてはならない思いでやっている。 #jasst10tokyo

posted at 16:47:30

ジョハンナ：開発と話すと全体のコストを減らしたいの一点張りである。６週間後にリリースが必達のプロジェクトに火消しで入った経験がある。１週間のタイムボックス管理をした。オフショア先での成果は予想していたものの半分以下だった。 #jasst10tokyo

posted at 16:49:33

ジョハンナ：その会社は結局、自社の社員で間に合わせた。イノベーション部分が問題だった。結局１００万ドル、１年間の無駄になった。 #jasst10tokyo

posted at 16:51:51

ジョハンナ：だからこそ、オフショア開発では、機能ごとの仕事分担をすべき。 #jasst10tokyo

posted at 16:52:49

３つ目の話題「プロジェクトあるいは組織の向上って考えていますか？考えているとしたらそのためにどのような事を行っていますか？」 #jasst10tokyo

posted at 16:53:32

飯泉さん：予稿集を拝見したところ、バラエティに富んでいてすばらしい。我々もいくつかやっていることもある。日立の品質文化はあるが、最近、リーマンショック以降、アウトソーシングがあまりできなくなってきている。生産性の向上のテーマが経営から与えられる。 #jasst10tokyo

posted at 16:56:11

飯泉さん：人が少ない時には、ツールを用いて技術を伝承して良く必要がある。 #jasst10tokyo

posted at 16:57:11

ジョハンナさん：各プロジェクトはユニーク。次のプロジェクトはそれを超えて良く必要がある。新しいプロジェクトに於いて、これまでよりなにか一つより良いことができないかと考えることがよい。 #jasst10tokyo

posted at 16:59:08

ジョハンナ：タイムボックスがそのひとつだ。ある期間を区切って成果をレビューしていく。 #jasst10tokyo

posted at 17:00:01

誉田さん：試行はプロジェクト、汎用化は組織。ここだけは、トップダウンでないとだめ。パワーと頭が必要。素晴らしい仕組みを作っても使われないと言う話がある。作った人が普及まで責任を持つのが成功のコツだと思っている。 #jasst10tokyo

posted at 17:01:47

誉田さん：仕組み化するときに気を付けるのは、誰かだけがいい思いをしないこと。 #jasst10tokyo

posted at 17:02:44

飯泉さん：やっているし、継続しているし、これからもやるつもりだけれど、これを継承し続ける人が少なくなって、また、波が来て多くなったときに同じ価値観を持った人を多く作らないといけなくなったときにどうするか。 #jasst10tokyo

posted at 17:04:24

飯泉さん：トップダウンと言う誉田さんの話はどきっとした。私のアプローチは着手はボトムアップ（プロジェクト）だけど、継続（組織）させるためにはトップダウンが必要なのかなと思った。 #jasst10tokyo

posted at 17:05:50

誉田さん：私の理解では、「XXXの向上」というタスクがでたら担当者が雇われる（またはトップがアサインする）のではないかと思っている。日本の場合は「日々改善だよね」というやり方が多いのかと思っている。裏から動いてトップからの動きに見せているところもある。 #jasst10tokyo

posted at 17:07:39

ジョハンナさん：私の経験では、「君たち改善せよ」と言うレベルのトップの指示しかこない。 #jasst10tokyo

posted at 17:08:19

誉田さん：日本と同じじゃないですか。本当ですか？ #jasst10tokyo

posted at 17:08:41

ジョハンナさん：全体の改善ではなく、２週間という短い期間の改善を積み上げていく。役員からもプロセス改善と捉えられている。 #jasst10tokyo

posted at 17:10:02

吉澤さん：パネリストの皆さん本日の気付きがあればお話ください。 #jasst10tokyo

posted at 17:10:51

飯泉さん：テスト工程を重視しないところがテストをアウトソースする。そして失敗するということ。もうひとつは、カイゼンの考え方日本は長期的、アメリカは短期的。 #jasst10tokyo

posted at 17:13:55

誉田さん：意外と違いがないことと、オフショアはもう終わりだぜということ。 #jasst10tokyo

posted at 17:14:58

ジョハンナさん：日米間で色々と違いはあるが、共通項の方が多いのではないかと思った。また、確証があるわけではないが、日本の方が長期的なビジョンを持っていると思った。女性だけのパネルに参加出来て光栄でした。 #jasst10tokyo

posted at 17:17:16

吉澤さん：ビジョンの長さについて、私はそうは思わなかったのだけれど。品質についてですが？ #jasst10tokyo

posted at 17:18:20

ジョハンナ：品質ではなく商品。 #jasst10tokyo

posted at 17:18:38

誉田さん、飯泉さん：私たちもそう思った。 #jasst10tokyo

posted at 17:18:59

クロージングパネル終了しました。 #jasst10tokyo

posted at 17:19:21

クロージング開始。善吾賞の発表とベストスピーカー賞の発表。 #jasst10tokyo

posted at 17:20:50

それでは、善吾賞を発表します。デロデロデロデロデロデロデロデロ～。 #jasst10tokyo

posted at 17:27:26

電子通信学会で発表された「設計モデルを用いた…」でした。 #jasst10tokyo

posted at 17:29:59

受賞者の声：UMLモデルからテストモデルを自動生成する研究で、始まったばかり。この賞を励みにしたい。また、これからみなさんと議論させていただいてよりよいものにさせていきたい。 #jasst10tokyo

posted at 17:32:20

つづいてベストスピーカー賞の発表（会場の方の投票できます）。「なぜなぜ５回」でした。おめでとうございます！ #jasst10tokyo

posted at 17:33:30

受賞者のコメント：光栄ある賞をいただきありがとうございます。今日は、トヨタの「なぜなぜ５回」を発表しました。会社全体で改善するためのツールの位置づけ。これからも価値を共有することを大切にしていきたい。 #jasst10tokyo

posted at 17:37:43

大西さんからご挨拶。JaSSTは多くのみなさんで作られています。ありがとうございます。各地のJaSSTにも足を運んでくださいね。ご来場ありがとうございました。 #jasst10tokyo

posted at 17:41:16