読者です 読者をやめる 読者になる 読者になる

Galapagos Engineering Blog

株式会社ガラパゴス エンジニアチームによるブログです。

Cookpad Tech Kitchen #7 参加レポート〜ごちそうさまでした〜

こんにちは!テストチームとのの(@tono2587)です。
今回はクックパッドでおいしいごはんをごちそうになった話を書きます!!!

f:id:glpgsinc:20170424173845p:plain 嘘ですごちそうになりながらテスト現場のお話聞いた参加レポートです(おいしかったのは本当です)(めっちゃおいしかったです)

Cookpad Tech Kitchen #7 〜 理想の開発現場の「ふつう」のお話 〜

日時:2017/04/21 Fri. 19:30〜
場所:クックパッド株式会社 東京都渋谷区恵比寿4-20-3 恵比寿ガーデンプレイスタワー12F 登壇者:秋山 浩一さん、関 将俊さん、深谷 美和さん、松尾 和昭さん

cookpad.connpass.com

公開された資料

どんなお話が聞けたか

  • 「理想の開発現場」について
  • 理想の開発現場の「ふつう」について
      「うまくいったらどうなるの?」
      「なんでやるんだっけ?」
      「やりたくないの?」
      「えー」
  • そのチームで喜ばれるふるまいについて
  • 明日からできそう??

「理想の開発現場」について

タイトルの「理想の開発現場」とはどういうこと? という説明を秋山さんより

  • いままでは、テストと開発それぞれが独立しているほうが理想の形だと思っていた。
     ・技術、お金、管理それぞれが独立(IV&V)
  • しかし、2015年のみわさんの発表を聞いてもう一つの理想の形に気がついた
     ・「人はミスをする」ことが受け入れられていて、テストエンジニアと開発者が一緒に品質をよくしている形
     ・ダイバーシティインクルージョン…多様に集まって、お互いに認め合うこと
  • ソフトウェアの世界では、このようにひとつの世界で情報交換したほうがよいのではないか
     ◯よいところ
     ・何を言っても大丈夫なこと…認めあっている
     ・「人」ではなく「こと」に焦点が当たっていること…品質をよくするために人が動く
     ・見方が違うことが大事
     ・共同作業と当事者意識…一緒にひとつになってやっている

解説にはカンペがあったそうです笑

今回はそんな理想の形=みわさんのチームについてのお話でした。

これから話す内容について関さんより

  • これまでは、できあがったチームの事例を報告していた
     →それを聞いたからといってできるとは限らない!
  • 今回は、チームになっていく過程を報告します
     →問題解決の最中に起こる話からよいチームができていっているのではないか?
     フレーズ→ふるまい→価値観 のようにチームの価値観ができていくのでは。
  • こんな名言があります
    『生きている花をつくろうとすれば、ピンセットで細胞を一つ一つ物理的に組み立てるのではなく、種から育てるであろう。』
         ーーークリストファー・アレクサンダー『時を越えた建設の道』

(種の撒きかたを教えてくれるんですね?!)

理想の開発現場の「ふつう」について

よくつかわれているフレーズがあります。

「うまくいったらどうなるの?」

  • このフレーズのよいところ
     ゴールがわかる、確かめる方法がわかる、ゴールまでのステップがわかる、うまく迷える
    →これをきっかけにしてぼんやりしていることをはっきりさせられる

  • 例:◯◯の調査をします と言われたとき
    ほんとうにやりたいことのための調査なので、そのやることがみんなにわかるようになったらやめようか、とか決めることができる
    Q:調査の区切りは先行投資だと難しいのでは?
    →時間で切る ことが多い

「なんでやるんだっけ?」

  • このフレーズのよいところ
     ・ゴールの意味がわかる、やりすぎを抑えられる
    →その作業自体の意味を考えたり、その作業でつくろうとしてるものがわかってくる。「不足」は不具合とかで見つけやすいが、やりすぎはわかりづらいのでこのフレーズが役に立つ
    →不安に思っていることはバラすほうがよい。
    →1人よりn人で考えたほうがみつけやすい

  • 例:だれかが迷っているとき、話し合いが急に静かになったとき、結論が出ないとき、困っているように見えるとき、熱中し(すぎ)ているとき

Q:Cookpadではどうですか?
人に干渉するのはけっこうやります。進捗の確認とか
Slackとか直接でちょくちょくコミュニケーションとる
できるならやったほうがいい

「やりたくないの?」

  • このフレーズのよいところ
     ・1人だけがやりたくない、状態にならなくできる(ヤダ共有)
     ・やる気がないからやらない、とはならなくできる
     ・上手い人がかわりにやってくれたりする
    →「嫌なこと」をなくしていくことができる。モチベートするのではなく、嫌なことを認めてなくしたり、みんなのものにすることができる

  • 例:問題を前に言葉が出ないとき、言い訳をする人が出てきたとき

Q:微妙なところに気づいてあげる工夫は?その人が「やりたくなさそう」という判断基準は?
→顔をみるから気づく。その人の話を聞いていてゴールが明確じゃないときや、明らかに目をそらすとかのとき

「えー」

  • このフレーズのよいところ
     ・瞬時に違和感を伝えることができる
    →「えー」って言うと課題かも、って気付ける
     ・それが何かをみんなが一斉に考えて話し始める
    →たいていの場合課題(問題)がみつかる

  • 例:「あれ?」とかも同じ使い方。ちょっと待って、というかわりだったりする
    →理不尽なこと言われたときには有効

◆スビードを大切にしているチームだからつかいます
 ・「早く」みんなに伝えたい
 ・自分で納得できるまで確かめてから伝えたい

Q:途中から入ったひとにも「えー」が悪く伝わらないコツは?(「えー」って普通否定的なイメージ)
→次の言葉までセットにしてる 「えー◯◯?」
Q:新しい人が「えー」の意味をわかるきっかけは?
→みんなのいる場で言われる/使われることが多いから慣れていく
→自分のことと同じようにその場にいる人が考え始める

そのチームで喜ばれるふるまいについて

  • 変だな?と思ったときにすぐ誰かにいう
  • バグかな?と思ったときにすぐ誰かに言う
     →スピード重視だから。バグじゃなくても怒られたりしない(いままではバグかな?くらいでは報告しなかったし、違うかもしれないことに開発者の工数をとることはよくないことだと思っていたけどいまはそうではない)
  • 仕様がわからないときだれかにきく
     →誰かが知ってるのに、わからない人が調べている時間のほうがもったいない
  • テストのやり方がわからないときだれかにきく
  • テストを思いついたとき、やる前にだれかにいう
     →ここバグ出そうだな〜って思ったときにすぐ言っちゃう
     →実装する前でも言う。考慮できてなかったところに気づいたりする
     →知っているなら先に言いなさいよ、というスタンス。いいものをつくりたいはずなのに、自分のやりたいことが優先されるべきではない。バグでそう→実装で確認は自分がやりたいことじゃないだろうか。
     「わざわざできあがってから言うのは、きみは意地悪だ」
  • こうしたフレーズを繰り返し言っていき、だんだんチームの価値観をつくっていく

明日からできそう?

15年も一緒にやっている長いチームだから、チームとしてできあがっているからこそ成り立つものなのでは?
と思われるかもしれないが、このチームに限った例ではないよ
→ラムダノートという会社と1ヶ月くらい一緒に仕事したらそっくりなチームができたから

まとめ

・テストエンジニアと開発者が一緒につくっていくのもチームの理想の形
・理想の開発現場ではなにが普通なのか
 ・よくつかわれているフレーズがあり、価値観をつくっていってると思う
 ・みんなが当事者
 ・新しく入ったメンバーにも繰り返し言っていき、慣れてもらう

Twitter公式タグも盛り上がってました!

感想

話を聞いて、わたしがすぐできそうなことについて考えました。

  • モヤモヤはすぐに伝える
     なんでも全部すぐ言うのがよいとはまだ思いませんが、悩みすぎたり、考えすぎて止まらないようにしようと思いました。まずは時間で区切ってみます。
  • 朝会をちょっと変えてみる
     いままで:進捗をざっくり確認→今日はAさんここ、Bさんこっちからお願いします。→他は何か(共有事項)ありますか?(終)
     これから:最後の(共有事項)の聞き方を具体的にしてみる。不具合でたかとか、仕様不明点ないかとか…
     →心当たりを見つけやすいし、細かいことも共有しやすくなりそう。
     →逆に無駄話みたいになっちゃうこともあるので、ほどほどでよいとアドバイスもらいました。
  • 「よいものをつくるため」を忘れない
     喜ぶのが自分ひとりだけ、にならないこと。
     →ちょっと面倒だな…ということも、「これを使う何万もの人がこっちのほうがうれしい」と言われたらがんばれる

ほか
ごはん全部おいしかったです。豚肉の角煮みたいなやつとか、生姜焼きとか、炊き込みご飯とか…でも食べながら聞くのは上手くできなかったです…もっと食べたかった…笑
ごちそうさまでした…
…というわけで、おいしいごはんとおいしいお話をいただいた1日でした。今よりもっとよくなるためにすぐできそうなことも見つかったので、早速やってみようと思います。

くいしんぼうとののが明日からもがんばる会社はこちら〜(エンジニア募集中)

www.glpgs.com

Swift's Strings

ガラパゴスのコードヒーヨアン(twitter: @luinily)です。

社内iOS勉強会の発表準備のため、Swift 4でStringの変更の説明を調べているうちに、そもそも現在のSwiftのStringはどうなっているのか、正確に把握していなかったことに気づいて、発表内容を現在のSwiftのStringの説明の方に変えました。

今回はその発表の内容を説明しようと思います。

Swiftの文字列はUnicodeの考え方に従っていますので、Swiftの文字列を理解するには、Unicodeを理解せねばなりません。

Unicode

アメリカで最初文字をパソコンで処理をしようとしたときは、まだメモリーも少なかったし、英語の使う文字だけで十分だったので1文字は1バイトで表現していました。そのあと、表現したい文字数が増えたり、国際化が進んで、各言語の文字を扱うためのエンコードができたりしていました。大学生の時、フランス語のWindows XPで日本語表示のインストールなどをした覚えがあります。ネットになると、複数のエンコードがありうるので、サイトによって全ての文字が化けて、表示に使うエンコードを変えたりしていました。

こういった問題を解決するため、すべての文字を表現できるエンコードUnicode、を作成することになりました。なぜUnicodeができるまでの歴史を簡単に説明したかというと、その歴史がUnicodeに影響を与えているからです。

Unicodeはどういうふうに文字をエンコードしているのか

Unicodeの文字はビットから文字まで複数の様子で定義されています:

  • Character

  • Unicode Scalar

  • Code Unit

一つの文字は一つか複数のUnicode Scalarで定義されています。一つのUnicode Scalarは一つか複数のCode Unitで定義されています。

f:id:glpgsinc:20170417115610p:plain

Code Unit

Code Unitはファイルなどに文字列を書き出すときに書かれる値です。複数のサイズが可能:8ビット(UTF-8)、16ビット(UTF-16)、32ビット(UTF-32)など。 複数のサイズが存在するのは、いろんな構築をしたシステムに対応できるためのと、英文など最初の8ビットで表現できていた文字列を使うと、1個の8ビットのCode Unitでかける文字がほとんど、メモリーの節約にもなります。

Unicode Scalar

Unicode Scalarは「文字」と「文字の変化様子」の2種類に分けられて、16進で表現される番号をふられている。例えば、日本語だと「す」という文字のUnicode Scalarは「3059」、「゙」でのUnicode Scalarは「3099」。二つ合わせれば、「ず」ができます。 つのUnicode ScalarをCode Unitで出力する場合、UTF-8では文字によって1つから4つのCode Unitが必要になります。

文字

一つの文字は一つか複数のUnicode Scalarの組み合わせでできています。Unicode Scalarの数には特に上限がありません。先の例で「す」と「゙」を組み合わせると「ず」になります。

同じ文字で複数の書き方が可能

一つの文字をUnicodeエンコードする場合、複数のやり方が存在することがあります。 例えば、さっきの「ず」は二つの Unicode Scalarを使ってできましたが、「ず」という文字にも一つのUnicode Scalarが定義されていますので、 Unicodeでは二つのUnicode Scalarの組み合わせで書けます:

  • 305A

  • 3059 + 3099

Swift

SwistのStringはこの考え方を反映しています。 Stringのプロパティーを見ると四つのビューが存在しています: String.characters: CharacterView String.unicodeScalars: UnicodeScalarView String.utf16: UTF16View String.utf8: UTF8View

見覚えありますよね?Unicodeの文字の定義を見たときにでた様子です!

  • CharacterViewはUnicodeの文字のコレクション

  • unicodeScalarsはUnicode Scalarのコレクション

  • utf16とutf8はCode Unitの16ビットのコレクションと8ビットのコレクション

Unicode Scalarの入出力

Stringの文字をUnicode Scalarから定義したいときは文字列の中に「\u{番号}」というふうに書きます。 例として「Pokémon」の「é」を使いましょう。「é」は「ず」と同じく、Unicode Scalarで二つの定義方法があります:「00E9」 (é)と「0065+0301」(e + ́)。Swiftで書くと下記のようになります。

f:id:glpgsinc:20170418190846p:plain

文字列から、Unicode Scalarを出力したいときは、String.unicodeScalarsにあるアイテムのvalueを取ります:

f:id:glpgsinc:20170418192346p:plain

char.valueをそのまま使うと、10進で表示されますので、16進でStringとして表します。

UTF-8UTF-16の出力

UTF-8UTF-16の出力はString.utf8、String.utf16プロパティーを使います。

f:id:glpgsinc:20170418193339p:plain

f:id:glpgsinc:20170418193557p:plain

お分かりになったと思いますが、8ビットで表現できるUnicode ScalarはUTF-8UTF-16で一つのCode Unitになります、16ビット表現されるUnicode ScalarはUTF-8で二つのCode Unitになり、UTF-16で一つのCode Unitになります。

従来のStringとの違い

Stringという型は、従来の言語でただの文字の配列です。Androidでよく使われているJavaのStringと比べて見ましょう。

JavaのStringはどういうものかというとStringのUTF-16のCode Unitの配列になります。 SwiftとAndroidのStringの文字数を比べて見ましょう。 例として、先ほどのPokémonを使います。まずは「é」が一つのUnicode Scalarで定義されている場合:

Swift:

f:id:glpgsinc:20170421190308p:plain

Java:

f:id:glpgsinc:20170421190727p:plain

この場合は同じですね。面白くなるのは「é」を二つのUnicode Scalarで定義した時:

Swift:

f:id:glpgsinc:20170421191856p:plain

Java:

f:id:glpgsinc:20170421191917p:plain

Swiftは7つのままですが、Javaの方は8つになりました!

今回Unicode Scalarが8つあって、Javaのcountが8つになりました。JavaUnicode Scalarの配列なのか、確認したいですね。そのために32ビットのUnicode Scalarを使って見ます。

どういうことかというと、JavaのStringは文字の配列ではなく、Unicode Scalarの配列ですので、今回は「e」と「 ́」が一つずつ数えられる。Swiftの方はUnicode Scalarではなく、文字を数えてるので、「é」の両方の定義でも数が変わりません。 SwiftでUnicode Scalarを数えたいときは、unicodeSclarsを使います:

f:id:glpgsinc:20170421201415p:plain

SwiftでUnicode Scalarが一つなのに、utf16の方で二つになります。Javaの方はどう?

f:id:glpgsinc:20170421201450p:plain

Javaも2になりますが、もうちょっと詳しく見ると「\u10000」の最後の「0」の色が違う、Unicode Scalarのコードの一部として認識されるのではなく、「0」という文字として認識されて、「𐀀」が「က0」として認識されてしまった。

結論として、SwiftのStringはUnicodeの文字の配列で、JavaのStringはStringのUTF-16のCode Unitの配列。 ただ、SwiftのStringは本当に配列なのか?配列だったら、Intをインデックスとして、文字にアクセスできますね?テストして見ると、コンパイルが通らない、SwiftのStringはIntをインデックスとして使える配列ではない。

なぜそうなったかというと、もともと配列は中に入れるアイテムのサイズが全部同じという前提で定義されていて、Intを使ってアクセスすとき、メモリーアドレスは単純に「配列のアドレス+インデックスxエレメントのサイズ」で計算されています。ただし、SwiftのStringが使っているUnicodeの文字のサイズはバラバラです。Unicode Scalarによってサイズも違いますし、複数のUnicode Scalarを使った文字もあります。Stringのいくつ目の文字のアドレスを計算するには、単純な掛け算ではなく、一文字目から一個ずと文字のサイズを足して計算します。

その原因でSwiftのStringはただの配列ではないし、Intのインデックスから文字の場所の計算のコストが高いので、Collection扱いもSwift 2でなくなりました。

Pokémonの場合、「é」以外の文字は1バイトですが、「é」は書き方のよって2バイトか3バイトが必要です。 f:id:glpgsinc:20170424180202p:plain

インデックスの扱い

SwiftでStringの文字にアクセスするには他の言語と違ってIntのインデックスが使えないことがわかりましたので、Swiftでどういうインデックスが使えるか紹介します。

Swiftではビューによって専用のインデックスタイプが用意されています:

  • String.characters: String.CharacterView.Index

  • String.unicodeScalars: String.UnicodeScalarView.Index

  • String.utf16: String.Utf16View.Index

  • String.utf8: String.Utf8View.Index

各インデックスの使い方は同じ:

  • startIndex:一つ目の文字のインデックス 例:myString.characters.startIndex

  • endIndex:最後の文字のインデックス+1 例:myString.unicodeScalars.endIndex

  • index(i: Index, offsetBy: Int):一つのインデックスから別のインデックスの計算。 例:myString.utf16.index(myString.utf16.startIndex, offsetBy: 2)

  • index(after: Index):次のインデックス

  • index(of: T):文字、UnicodeScalarなどのインデックス

ビューの間のインデックスの変換が可能です:String.CharacterView.Index(String.UnicodeScalarView.Index, in: String)、String.Utf16View.Index(String.Utf8View.Index, in: String)

Stringに直接インデックスも使えますが、String.CharacterViewのインデックスです。

StringのビューはCollectionになっているため、ループができますが、パーフォマンスの問題がそのまま残っているため、使うときに注意したほうがいいです。

サブストリング

Stringからサブストリングを取るときにSwiftは単純にその文字をメモリーの別のところにコピーしているわけではなく、新しいStringは元のStringへのポインターとサブストリングのインデックスを持っています。そうすることによって、サブストリングで処理を行うときに、Stringはコピーされないので、処理が速い。ただし、サブストリングが残ってる限り、元のStringを消しても、メモリーに残ってしまいます。長い文字列から一つの単語をサブストリングにしてから、元の長いStringを消してもメモリー上、全部残ってしまいます。Swiftのサブストリングの処理はメモリーより速さを優先している。

SwiftのStringの不思議なところ

文字列がUnicode Scalarの変化様子字で始めれば、たのStringと合わせる場合、文字がまーじされることがあります。

f:id:glpgsinc:20170424192657p:plain

絵文字の場合、想定外の文字数になることがあります:

複数の国旗絵文字を並べても文字数が1になります

f:id:glpgsinc:20170424193538p:plain

四人の絵文字の文字数は・・4

f:id:glpgsinc:20170424193609p:plain

これでSwiftのStringはちょっとわかりやすくなりましたかな?中を見てみると意外と面白いですね。

SwiftのStringについて調べたときに役に立った記事:

テスト設計コンテスト'17 決勝戦聴講レポート

こんにちは!テストチームとのの(TW:@tono2587)です。
今回は2/23に参加した「テスト設計コンテスト」のことを書きます。
f:id:glpgsinc:20170419180938p:plain

時間は経ってしまいましたが、初めてのテスコンだったので張り切ってレポートします!

・テスト設計コンテストとは?
・決勝戦概要
・U-30クラス
・OPENクラス
・全体講評メモ
・感想など

テスト設計コンテストとは?

名前だけは聞いたことがあったのですが、いったいどんなコンテストなのかは知りませんでした。一緒におさらいしましょう!
簡単に言うと、「テスト設計のスキルを競い合うことで、さらに高めていきましょう!という会」な認識です。
公式サイト:http://aster.or.jp/business/contest.html
「OPENクラス(だれでも)」と「U-30クラス(30歳以下のみ)」の2つのクラスにわかれており、それぞれで予選がおこなわれた上での決勝戦となります。
わたしはチュートリアルは参加せず(知らなかった…)、この決勝戦のみ聴講で参加しました。

今回のテストベース

U-30クラス:「話題沸騰ポット」
OPENクラス:カラオケシステム

テストベース仕様、採点基準についてはコチラから↓
http://aster.or.jp/business/contest/rulebooku30.html http://aster.or.jp/business/contest/rulebook.html

勝戦概要

◇日時
2017年2月23日(木)
10:00 U-30クラス決勝戦開始
12:30~13:30 昼休み
14:40 OPENクラス決勝戦開始
18:10 終了

◇場所:日本大学理工学部 駿河台校舎 7号館

◇参加チーム(発表順)

U-30クラス OPENクラス
OPTiM てすにゃんRev2
いんプレオ 紙印テスト倶楽部
ヤングレッジ STUDIO IBURI
でこパン462 モモテツ
チームT研 わんだーズ
SHINNOSUKE
TBD

☆持ち時間は発表15分→質疑応答5分の計20分

U-30クラス

優勝 でこパン462 準優勝 SHINNOSUKE

総評メモ
井芹洋輝さん(審査委員長)より

入賞チームについて

  • でこぱん462
     テスト要求分析の発散と収束が上手だった(まとめが上手かった)
     3つの目的でビューを分けてやっていたところがよかった
     テストの手法を理解してつかっていた

  • SHINNOSUKE
     わかりやすかった
     よく内容をみるとあれ?ってところがある
     アーキテクチャを2つつくって片方を採用したところがおもしろいが、根拠が少ない

  • TBD(準優勝惜しかった)
     テスト要求分析でいろんな分析をやっている
     新しい技術にチャレンジしているのがよいが、なぜその手法なのか、どうつながっているのか、それがみえず説得力に欠ける
     技法、手法をつかうなら理解していることも証明できるとよい

U-30クラス全体について

  • テスト開発プロセスの基礎ができていない

  • 技術力不足
    チュートリアルで設計について説明があったけど、それを満たしていない
    手法の使い所がおかしい、正しくない

  • 竜頭蛇尾
    分析がテストケースにまで落ちていない
    テスト設計は、「テスト」が成果物であり、本質。
    「テスト」をよくすることが一番で、そのためにやっている。

  • テストの厚みの分析が足りない
    根拠の分析が弱い。
    「なにを」テストするかはできているが「どこまで」テストするかが足りない

上記の改善について

  • 品質 についてよく考えて下さい。理解してください。
    ポットに対してテストが仕様書どおりではそもそもテストが足りない。
    (倒れる危険があったり、子どもがつかう、という前提がある。)

  • 「よいテスト」について考えてください
    保守性の高いテスト、マネジメントが高いテスト、等
    テストの内部品質を工夫しましょう

  • 各「技」はしっかり身につけてください
    技ばかりにこだわってはいけない。それをつかってこそ

OPENクラス

優勝 STUDIO IBURI 準優勝 わんだーズ

総評メモ
鈴木三紀夫さん、湯本剛さんより

  • 成果物をみて
    とんでもない成果物の量で圧倒しているチームもあったが、それは本当によいかどうか
  • アーキテクチャはいろんなビューでみなければいけない。
    どう組み合わせたら品質がよくなるのか
    いくつかのアーキテクチャのビューのなかで、順番のやつが簡単です 
    アーキテクチャ設計」とは…をよく考える
  • アジャイル開発にチャレンジするなら中途半端ではなく、それについてもしっかり勉強しておかないといけない
  • 「用語」をしっかりつかうこと。
    一般的な使い方をしたほうがよい。発表にそれぞれ違う定義でつかわれている。この発表ではこうです、という定義がされていてもいつもと違う使い方だと誤解しそうになる

全体講評メモ

西康晴さん(審査委員長)より

  • テスコンはじめの4年は主に「テスト観点」で勝負がついていた。
    そこからテスト要求分析の技術がついてきて、2年くらい前からテストアーキテクチャ設計の質で勝負が決まるようになってきた。
  • 設計方針とはなんなのか をしっかり考える
    ものの設計とは何か?
    車輪で走るような自転車の設計、とかはわかりやすいが、じゃあ「テスト」の設計は???
    テストの設計は何が動くのかよくわからないからソフトウェア設計よりも難しい。  
    参加者みんなで技術力をアップさせていっている。

  • テストレベル、テストタイプ などの定義は世界にもある。
    それをどういう順番で並べるかを検討する方法はまだ世界にはない。
    UMLテスト 2.0とかに入ってくるかもしれない
    世界最先端です!

  • 今回はテストベースが「派生製品」だった
    じゃあ次回は?自動化を考えたら設計の中身も変わってきたりするでしょう

  • 要求分析→アーキテクチャ設計
    この流れが、過程が踏まれてない

  • 成果物がただの日記で、「理由」「意図」がない
    やることが決まっていて、何も考えずにやったことを出せばOKがもらえる仕事になっている

  • つかう用語、技術は理解してつかわなければならない
    自分たちの技術にする、アイデアにする、現場の工夫をコンテストの機会で整理してください
    それをフィードバックにして、自分たちの強みにする

感想など

  • 同じテストベースを与えられているのに、成果物も発表も同じものはひとつもない
    逆に、自分たちの立ち位置の説明→設計の流れ説明→要求分析→テスト設計の流れはだいたい共通していたので、基本的なテスト設計の流れを知ることができました。
  • プレゼン(発表)も得点に入っている
    設計した成果物だけではなくて、プレゼン内容が得点に影響するところがおもしろかったです。自分たちの設計したことを相手にわかるように説明することも、ときには必要なスキルなのだ思いました。
  • すぐできそうなこと
    「用語」や「手法」を正しく理解すること。スキルアップには基本知識を増やすことが一番はやそう
  • 「世界の最先端です」
    総評のこの話が一番わくわくしました!最先端技術のすぐそばにいる!

学んだこと

  • テスト設計の基本の流れを理解しました
  • テストの成果物も設計により様々なのだと知りました
  • 十分な設計をするためにテスト設計の基本知識を身につけることが近道だと教えてもらいました
  • 技術を高める機会が社外にもあることを知りました

さいごに

参加者には発表者や関係者が多い印象でしたが、聴講のみでも参加できてよかったです。
参加前にもう少しテストベースについて読んでいったり、予習していけばよかったなと思いました。(そのほうがもっと話が入りやすかったかも)
総評で「世界の最先端にいるから、本とかに自分の名前のついた手法が載ったりするかもよ(意訳)」と言われたときはすごくテンションがあがりました!
勉強のし甲斐がありますよね。これからもがんばりましょうー!!!

「最先端」が大好きなぼくのはたらく会社がこちら
www.glpgs.com