【ジャストーーーク】転職芸人が語るテスト/QA技術者としてのキャリアパス #JaSST'17 Tokyo

登壇者

  • 大西健児(以下、大西)
  • 柿崎憲(以下、柿崎)
  • 山本くにお(以下、山本)
  • 山本健(以下、番長)
  • 湯本剛(以下、湯本)
  • 吉澤智美(以下、吉澤)
  • 安達賢二(以下、安達)
  • 福田里奈(以下、福田)
  • KENさん
  • 越中谷郁美(以下、越中谷)

キャリアアップで芸人紹介

大西

  • 1人2分ぐらいで話すので早口で。
  • QAエヴァンジェリスト。社内では「エヴァンゲリオン」と言われてる。
  • 英語喋れるとかっこいいかも→外資へ転職。
  • テスト勉強しなきゃ→テスト技術者交流会へ
    • 翻訳を頼まれる
    • JaSSTを始めた1名
  • ASTER作ったり
  • JSTQB作ったり
  • 今日はけんさんが5人いる

柿崎

  • QA始める前に5回転職してる
    • 今回の芸人はみんな5回以上転職してます。
  • 肌色の多いみんながアクセスしていたサイトとか。
  • 市役所の臨時職員とか。
  • 黒い何とかVitaとかからQAの世界へ
  • mixiの業績不振が今の私を作った

山本くにお

  • 転職前の部分は割愛。平成元年に社会人に
  • 転職してSONYに入ってから高品質を求められた
  • TEFとかWACATEとかに参加
  • より早いサイクルの会社に転職
  • 現在はKDDI

番長

  • 僕、怖い人じゃないです
  • 最初は芸術を志して、水道がとまったりしていた
  • 最初はSIでテストして、リーダーへ
  • ベンチャーに転職
  • ソーシャルゲームで波に揉まれて
  • 現在はmixi
  • スライドには収入の変遷も載せた

湯本

  • 1991年に社会人に
  • メーカー系に入社
  • 海外に住みたいので休職しようとしたらダメと言われたので退職した。
  • ソフトウェアベンターに参加
  • TEFに参加
  • 東京に行くためにコンサルに転職
  • そんな感じでばーっとやって、今に至る

吉澤

  • 自分の場合は社内転職芸人ということで出させていただいている
  • 前半戦は基礎的な知識を溜め込む。開発→リーダーへ
  • 子供が生まれて、育休が終わった当たりから社外活動へ。
  • 出向先で色々あった
  • 社内異動を拒否したこともあった
  • 社内異動で研究職へ。標準化を行い始めるように

テーマトーク

  • KEN「15分前倒しで進んでおります」

転職した同機は何か?

山本「パフォーマンスを発揮できる戦場を求めて」

  • 整っていない会社さんのところに言って1,2年で回り始めると、「そろそろかな…」と思って、社外からも誘いがあって転職する
    • 安達「パフォーマンス発揮できると言ってるけど、繰り返していると同じところ回っている感覚はないの?」
    • 福田「これってどっかから声がといってるけど、結構なスパンなので、そんなにこないのでは?」
      • 山本「業務が落ち着いて情報を見ていると、『どう?』と言われたり、コミュニティ活動している中で『手伝って』とか。『飲みに行かない?』とか言われる」

湯本「テストの仕事をもっと価値の高いものにしたい」

  • 自分で何を書いたか確認します。
  • ソフトハウスに転職して、7,8年ぐらい立つと、気に入らないこととして、市場に出た後のバグでテストのせいにされた。
  • 「なんでもテストのせいにするのは良くない」といったら、上司の人が呼び出された。
  • 同時期にTEFで面白く思えた。
  • 清水さんの話を聞いて良いなと思った。テストコンサルの求人にひかれて。
  • あ、価値の高いものにしたいと話が変わっちゃった。
    • 山本「価値が上がった?」
      • 吉澤「湯本さんの給料が?」
      • 上がった。給料とかで愚痴っていたら誘われて次の会社に。
    • 安達「テストの仕事の価値って?」
      • 誰でもではなく、技術力のある人でないとできない仕事に。
    • 安達「上司にテストの価値をどのように伝えるか?」
      • バグが出る・出ないの段階だと難しいが、そもそもテストで何を見つけるかを予め定めておこう。なんでもテストで防ごうとすると、いっぱいチェック項目が増えて収拾がつかなくなる
        • ここで時間切れベルが鳴らされる

番長「ニーズがあるところに」

  • ベンチャーにいると、起業する人が多い。
  • そういう元同僚が企業に成功するとQAが必要になるので。
  • そこをコバンザメのようについていく。

柿崎「スタープレイヤーの仲間入りしたい」

  • mixiからサイバードに転職した時にこの考えを持った
  • mixiの社員は、mixi以外の現場でも活躍する人がいる。そういう人はだいたいエンジニアとかインフラとか。それをQAエンジニアとして成し遂げたい。モデルケースになれれば良いと思う。
  • ソフトウェアテスト業界も恩返ししたい
    • 番長「僕が追い出したわけじゃないよ」
    • KEN「2人は入れ違いでmixiに入ってます」
  • KEN「誤解を招かないように説明しておくと、このセッションは転職を煽るわけではない」

これまで転職して新しい会社に言って、一番驚いたことは何か?

大西「給湯室でおでんを似ているおばさんがいた」

  • 転職の面接時にそうめんゆがいてた
  • そこに入社したら、同じ人がおでんを煮ていた
  • ベンチャー会社だとトイレ当番とかあった

番長「テストチームの立ち上げからやることになった」

  • チームを作っていけばいいやと思ったら、「来週、デグレッシェンドテストやって」と言われたぐらい、テスト文化が無かった。
    • KEN「最初、そういう状況を聞いてた?」
      • 認識はしてなかった。
    • KEN「そこからテストって大事だねと思わせるのにどれくらいかかった?」
      • 1年半ぐらいかかった。ひたむきに、努力した。バグがないと思っているところに指摘した
    • 「番長がいないとダメ?って思われなかった?」
      • 部屋が暑くなるので、
    • KEN「同じように、先陣を切ってテスト文化を育てた人は?」
      • そこそこ出来ていたが、そこからさらに一段上げることはした。フルで立ち上げるときは、JCOMのインターネット部門のときは、テスト部門の外国人の人が退職することになって、社内で1年半ぐらいテストの営業活動をやり続けた
    • 安達「その過程で一番苦労したところは?」
      • やる気のあるメンバーに「テストって楽しいよね?」という話を伝えた。あとは、実際にやる対象について話して、リスクベースドの話をして、具体的にツッコミを入れた。
    • 安達「味方をどんどん増やしていくのは良いね」

湯本「結局みんな似たようなことで悩んでいる」

  • KEN「隣の芝生は青い状態ということだったのでしょうか?」
  • 長野県では出来なくて東京だったらなんとかなるだろうと思っていたが、どこも同じだった。
    • 福田「驚いたけど、慣れるものか?自分も福岡から来ているので、東京って進んでいるというイメージがあるが。」
      • すごいなと思う会社もあるけど。え?東京だといいこと?無いよね。いいこととしては、自分が技術力を磨けばどこでも通用する。

吉澤「同じ言葉が違う意味で使われている」

  • ソフトウェアグループからハードウェアグループに社内移動したが、言葉が違った。
    • 例えば、リターンキーの解釈が違っていた。DOSではないオペレーティングシステムに慣れていた同僚は、リターンキーは確定だけで送信は行わないと思っていた。まずはズレがあるのがどこかを確認する
    • 湯本「転職しなくても、大規模なプロジェクトだとそれぞれの会社で作っていると、統合テストの段階でズレがあったりする」
    • 山本「子会社の単体・結合・総合、親会社の単体・結合・統合があって、何回統合やるんだよ?と思ったことがあった」

転職後に「あー、転職しなきゃよかった、マズった」と思うことがあった?

湯本「誘った2人がいなくなった」

  • ある会社に入社したときの話。その会社の社員2人に「製品を日本で売れるようにしてほしい」と説得されて転職したら、入社した後に色々あってその2人は退職しちゃった。けど、そこからポジティブになって楽しくやっている。
    • 安達「立ち直るのは大変だったのでは?」
      • 大変でした。ただ、社内転職で別の人に誘われて社内転職できた。(その人も辞めちゃったけど)
      • 結果的に色々と携わって社長賞も取った
        • 安達「社長賞の写真は湯本さんがかっこいい格好して飾られてる」
        • 福田「今日の格好は…w」
    • 安達「人で苦労しているけど、技術で打開してきた?」
      • 良い人との出会いがあった
    • 大西「今会場に来ている同僚は良い人ということ?」
      • そうですよ

なぜ同じ職種(テスト/QA)に転職するのか?

大西「定め」

  • なりゆきって書こうとしたら言われそうだったので定めとかいた。
  • 転職時には、これまでやってきたことを続けると給料が下がらないから。
  • yasuharu_nに誘われたり、会社の社長と喧嘩したり…
  • コミュニティに入っていたので、仲間が出来る
  • 結果的に他の職種に就いたことは無かったが、Vモデルの右側が出来るから左側もやってみたりもした
    • 福田「左側にずっといようとは思わなかった?」
      • 「とある会社で売ったら、上手く売れなくて事業を畳まれたので、左側を続けなかった」
  • 要求仕様書を書いている立場のときには、QAの人が指摘したときに、あなたが合っているよと言えた

山本「面白いし、求められているから」

  • 狭く深くも見れるし、広く浅くも見れるので、また相談されることが多くなるので色々出来る
    • 安達「思わぬ収穫になった技術とかはあった?」
      • BTSがあまりなかったときに、BI系のことをやりつつ会計系を学んだ経験が、プロジェクトマネジメントで役立った

番長「学びが付きないから」

  • WEBの領域にいるので、色々な製品・サービスが出来て、ごちゃごちゃ戦っているうちに、色々とタメになっていっているので。

吉澤「入社して間もなく、テストで身を立てると宣言した」

  • テストでやるぞ!といった手前、気になったことをどんどん勉強した。
  • 2回の育休の間にガラッと変わっていく。OSが変わったり。
  • テストを学んでいると、沢山の人に頼られるし
  • 開発よりも応用しやすい。
  • 周りにちゃんといって、自分もやっていく
    • 福田「そういうポジションはいないからやっていたと思うのですが、産休の間、会社は同対応した?」
      • 1回目は後輩に押し付けた。2回目はちょうどプロジェクトの境目だった。マネージャになってからは、フルタイムでない人ばかりのチームになったので、2人体制にした
    • 福田「会社がそういう方針にした?」
      • 私がそういう体制にした

柿崎「理由なんかない」

  • 転職エージェントや面接相手の会社に聞かれたが、「この仕事を愛しているから」と答えている。
  • 自分はテスト好きなので、本当はテストし続けてバグ表を書き続けたいが、マネジメントをやらせてもらうことが多い。
    • 安達「今は?」
      • 今もマネジメントですね
    • 安達「つまらない?」
      • つまらなくはないけど、ウズウズはする。ただし、マネージャの仕事をしないといけない
    • KEN「好きって言ってないとやってられない仕事ですよね?」
      • 一同「えっ?」
    • 湯本「私の場合、転職したいもう一つの動機は、係長とかで部下を持ちたくなかった。一緒に仕事してないのに評価する役職になりたくなかった」
      • 山本「テストをやっている人を正しく評価できる人はテストのマネージャでは?」
        • 湯本「わかった。やるよ」

学生「新卒・転職(一般)はつまらなそう。転職芸人は楽しそう」

柿崎「いろんな会社、人、志向、課題をディスカッションしてみるだけでも楽しい」

  • 何らかの課題を解決したいから転職している。転職先の悩みを聞くだけでも楽しい。どういう風に解決しているか想像できるので。どういう悩みがあると調査できると、それってただの面接ではなく、課題を共有・ディスカッションできるから。
    • 湯本「新卒だとそういうことを言えないのでは?」
      • だから新卒の面接官はクソ
    • 安達「私、面接官をやってるんですが」
      • 本当は悩みを打ち明けた方が良い。圧迫面接とかやっているから日本はダメになる
    • KEN「採用の立場に立っている人がいると思うが、どんな場所を重視している?」
      • 番長「ストレス耐性のない人が好き。自分の好きな人を見つけてとことんやる人が欲しい。テストを募集しているのに、「企画もやりたい」と言ってる人はパフォーマンスを出せない」
    • 福田「短時間の面接でどれくらい出せば良い?」
      • 番長「私の場合はどれくらい打ち解けるのかを基準にしている」
    • 福田「採用する方も楽しんでいる感じ?」
      • 番長「そうです」
    • KEN「他には?」
      • 湯本「圧迫面接してないよね?」
        • 柿崎「私が採用時にやったような相談を、面接官の立場になってもやってる。こっちから投げた相談に対して、熱く語れる人が来て欲しい人。もう一つ基準にしているのが、(やばいな、テクニックで取られる…)過去にやった工夫とかを喋っているときに、感情が乗っているかどうかを観る。他の人のをパクった話は感情が乗らないことが多い。心情を吐露することで、暑いディスカッションが出来る。」

転職を薦めない場合はどんなときか?

柿崎「嫌な環境だから転職するとか、有名な所入って箔をつけてやろうとか」

  • 体調に悪影響を起こしている場合はすぐに転職した方が良いです。転職によって課題を解決したいという場合は転職したほうが良い。

転職に関わらず、技術者として意識しておくことは何か?

吉澤「好奇心、向上心、あと人脈を少しでも広げておくと役立つかも」

  • 知らないことはとにかく調べる、聞く
  • セミナーを進められても、「お金もらえなかったら行きません」とは言わないで、自己投資する
  • 人脈を社内・社外で作っていく。転職にも役立つかもしれないし、悩みも解決できるかもしれない

    • 福田「これって難易度が高いのでは?パワー使うと思うが。そういう人にはどうすれば良い?」
      • 無茶してます。それでもやってみることが大事。出ていっても、出続けるのも人次第。ゼロベースで考えると色々と気が楽になる
    • 山本「レポート、稟議…の大変さとか、偏見とかがあるかも」
      • 稟議は書いてあげます。上の方はそれを誘導してあげる
  • KEN「これ、なかなかイベント参加の報告書に書きづらい内容が多いですよね。publickeyさんも手を止めて諦めてる所があったりする」

大西「技術を磨いて、不得意領域の人的ネットワークを構築する」

  • 世界の最前線を知るためには英語が必要だけど、ICSTなどの機会を用いて欲しい。
  • この辺の年になると、自分の苦手な場所を分かっている。しかし、それは恥と思わず、自分の苦手な場所を助けてくれる人を作る
    • 湯本「その代わり、自分の得意なところを作ったほうが良い」

柿崎「スキルや得意なこと、それがビジネス上の価値にどう結びつくかを記録、整理する」

  • 日々のTODO一つ一つをどのようにやってのかを記録する。それをビジネス上の価値を生み出したかを記載しておくと良い。
    • 安達「どこ言っても通用するよとすれば良いよいうこと」
      • いつ転職しても良いように
  • KEN「転職だけでなく、新しいサービスを行うときにも重要になる」

湯本「自分はどうしたいのか?を考えるようにしましょう」

  • 技術者として極められない環境になったら転職を考え始めれば良い
  • やりたいことがやれないときには…(ED音が鳴り始める)

まとめ

  • 福田「皆さん、探究心のある人達だなと分かりました」
  • 安達「自分の好きなことをやって、過ごしている人だと分かりました」
  • 山本「転職芸人ブラックの番長です。人生の棚卸しに転職が良い機会だった。」
  • 柿崎「光のジョブホッパーの柿崎です。あまり話す機会をもらえないと思っていたが、いっぱい喋れて良かったです。私はあまり先のことを事を考えないタイプ。やっていった後にできるだけ。課題が無くなったら取りに行くことも大事。」
  • 番長「コバンザメ芸人の番長です。STAFF募集中です。」
  • 吉澤「社内転職エージェントの吉澤です。テスト設計コンテストもあります。3/13〜ICSTがあります。どちらもチラシが入っています」
  • 大西「よーくかんがえーよー♪おかねもだいじだよー♪ということで、バランスも考えて。」
  • 湯本「このセッションは山本と私でJaSST九州の飲みの場で決まった。技術を磨くには勉強だけでなく実戦も必要。それが出来ないなら会社を変われ。」
  • KEN「どう考えてもネタセッションにお集まりいただきありがとうございます。アンケートで好印象があれば来年もやれるかもしれません。」

楽天トラベルの開発プロセスに関して #JaSST '17 Tokyo

自己紹介

楽天トラベルについて

  • 国内外の旅行を扱っている

開発体制・案件について

  • トラベル事業は楽天の中でもトップの方を位置する規模
  • セールス、マーケティング、開発が同じフロアで行っている。
  • 開発はさらに3つに分かれている
    • PDM
      • 未来を考える人
      • 30人程度
    • 開発
      • 100人程度
    • QA
      • 30人程度
  • 基本的には全て内製

  • 2016年の新規の開発案件が209件。

  • BugFixなどのPDM以外の案件はQAが関与していない

案件の内容比率

  • 2016年の各サービスごとの改善割合。
  • 国内宿泊サービスのBugFixが8割強
  • 改修のプライオリティを5段階に分けている。毎回のプロジェクトで行っている。

QAのプロセス改善について

以前のフロー

  • ウォーターフローに近いかたち
  • PDMの人はアイデア、議論、起票、レビュー、要件定義
  • 開発の人は要件定義レビュー、開発設計、テスト設計、開発・テスト、リリース

以前の問題

  • 旧システムvs新システム
    • 開発スピードについていけない
    • ケースが漏れる
  • プロセスの改善を行った。

現在のフロー

  • 現在は、要件定義、開発設計、テスト設計(シナリオの概要を書かせる)、ケース設計、手動テスト、本番確認

今後の展望

  • 今後は開発と同じ速度でテスト設計を始められるようにする。
  • 要件定義の段階からQAが入るようにする。テスタビリティの観点からレビューに参加する。
  • 開発の設計が始まった段階でテスト設計も行うようにする。

    • 開発の設計では漏れている観点をデベロッパーにフィードバックできるようになった。
    • 開発とQAの意思疎通がうまくいくようになった。
  • 今後は、テストケースをもっとプラグラマチックなケースで書かせて、すぐに自動化できるように行う。

    • 設計にはコストがかかるが、実施コストは下がるので、トータルコストも下がる。
    • 次回以降はデベロッパーに配ることで、デグレードを抑えることができる
  • QAの責任範囲は広がっていった。

まとめ

  • QAはリリース後の全てのバグに権限を持っている
  • QAの実施可否
    • 作ったツールのパス率、ITの結果、UTの結果から判断する。
  • 本番リリース可否

    • 全ての案件において、リリースできるかどうかの決定ができる。
      • 営業がリリースの要望を持っていても、拒否することが出来る。
      • バグが残っている状態で出荷することもある
  • PDM、開発、QAの三権分立を行っており、パワーバランスを保っている。

ソフトウェアの品質保証の本質 〜技法の変遷から学ぶ〜 #JaSST '17 Tokyo

はじめに

  • 今日はディスカッションのネタを提供する

品質保証で思い浮かべることは?

  • あんまり良い思いを持っていないはず
  • めちゃくちゃデータを取ってくることを矯正されている
  • 余計な作業を追加するの?

  • 2007年以降は現場にいないので、正直、知るか!

皆さんの組織の現状は?

  • QMSはありますか?
    • 全社もしくは事業部単位にある
    • 部門単位にある
    • 上記いずれもある
    • もしかすると無い
  • QMSの実態は?

    • ほぼその通りに行われている
    • 参考にはしている
    • ほぼ使われていない
  • SQuaRE(東さん)のは小難しく書かれている。

  • ISOはとんでもないことを書いたりもする

品質保証の定義

  • 石川…品質保証は品質管理の真髄。
  • 飯塚…お客様に安心して使っていただけるような製品を提供するためのすべての活動
  • 西…品質保証活動とは、品質リスク(バグがあるかもしれない)を最小にする活動。

    • 西先生の発言で唯一覚えていることです。
  • 品質保証は体系的活動がポイント。

  • 品質保証はworkではなくアクティビティである

80年代のepoc

  • V字モデル。この発明によりテストのやり方を説明・共有できるようになった
  • 日本の品質保証の大発明: 品質管理図 (テスト管理の代表的手法)

    • 45歳以上の人は品質管理図を若い人に教えて書かせてください。いろいろなことがわかるから
  • 開発が8割のバグを出したら、その人の限界が来る

    • そのための第三者検証があったりする

90年代前半

  • ISO9000の台頭。良いところと悪いところがあった。
    • 良いプロセスは良いプロダクトを生み出すが,プロセス重視も普及してしまった (目的と手段の逆転)
    • CMMIではプラクティスも追加され厚くなり,ますますプロセスは専門家の手の中に
      • 「『プロセス改善』っていう言葉は嫌いでしょ?」
  • PMBOKはPM支援ではなくPM監視のために作られた。

  • 人のデータは全く役に立たない、コンテキストが違うから。

  • 欧米は管理と実行で分かれている。

    • 「俺は言われたことをやってるよ」
  • トラブルの時に真っ先に走るのが出来るQA

    • →走りたくないから出荷しない

質問

Q. 話の中で出てきたテストチームと開発は両輪だと行っていましたが、品質保証のチーム内に開発チームをどのように捉えたら良いのか?

  • 開発者の言うことは全部信じたほうが良いのか?全部疑ったほうが良いよ?なのか
    1. 開発は半分ぐらい嘘ついていると思う。
  • しょっちゅう嘘ついてるでしょ。上司にそのまま報告する訳がない。
    • 例えば、水平展開して10件出ます→9件しか出ない→「1件はコーディング規約違反がありました。」と言って10件出たと報告。
      • そんなので品質が上がったりはしない。

Q. 品質保証部門の組織内のあるべき形、パワーバランスについて聞きたい。

  • 新しい会社を作ってQA部門を作ったが、後発なので力が弱かったりする。
  • 一方で品証が偉くなったり…。
  • 本来の品質保証部門のありかたとは何か?
    1. それは私の考えるべきところではない。経営者がしっかり伝えないといけない
  • 上司に、「あなたはなぜこの組織を作ったのですか?」と聞けば良い
  • QAは作業する部門ではない。
  • テストそのものは目的ではなく、それによって評価することが目的。
  • バグを出すことが目的ではない。

Q. 品質保証活動の仕組みについて。

  • 最近もまあまあ変わってないと思う。
  • 奈良さんはどう思っているか?
    1. お気の毒だと思う。意味の分からない仕事をしているのでは?
  • 「なぜこんな仕事をしているのですか?」と聞かないといけない。
  • しかし、最近の企業は成熟しているので声が届きにくいが、技術で語りましょう

Q. 現状を打破するためには?

Q. どういう方法で学べばよいか?

  • 直接聞け!なのか論文を読め!なのか
    1. 何に困ってますか?
    2. ちょっとよく分かってない
      • 困っていることが分かってないと勉強できないはず

Q. 色々なことで失敗してきたからこその金言を伝えていると思うが、バッドノウハウがあれば教えて欲しい。

    1. こっちの思い込みで進んだ場合は絶対失敗している。データを見て、相手に確認しないで(裏を取らないで)進むと失敗する
  • つまり、開発側に押し付けてしまったので、裏付けを取って進めていくことが大事
  • take and give ではなくgive and take で進めていくべき

Q. 品質保証に対するネガティブなイメージは奈良さんのやっている時は無かった?

    1. ネガティブではないことなんて無い!
    2. 無くなることはない?
      • きちんと理解してもらわない限りはネガティブから解消しない

Q. 品質保証部の部長にどのようなアドバイスをするのか?

    1. 組織や自分の仕事がなんのためにあるのか?を伝える。
  • あと、クォリティマネジメントシステムを回すことが重要。

Q. 認証に対しての鍛え方がよく分からない。どのように鍛えれば良いか。認証に対して完全に答えられるようにしたい。

  • A.それは無理じゃないですか。議題に対して質問できることが大事。

Q. 顧客対応を品質保証部門がしてくれるのは、ネガティヴではないと思っている。そういう話をして欲しかった。

    1. 確かにその通り。しかし、それでも酒の場とかで言われることもある。

Q. よく品質のところで話題に出るのがKPI。指標を出せ、決めようとか言われる。しかしコンテキストが違えば意味がない。それによってプロセスを押し付けることにもなっている。これに全く同感であるがどのように組織に理解してもらえばよいか?

    1. 中間管理職の人が若手に教えるしか無い

Q. 奈良さんにとって品質保証とは何か?

    1. 特別な言葉にしたくない。自分の仕事に対して責任を取る。
  • 立ち止まって考える。
  • 振り返る。
  • この癖をつけること。
  • 自分の仕事に対して責任を取る、特別なことではない。
  • 立ち止まるためのメトリクス、振り返るためのメトリクスがある。

基調講演 ICT応用S&S製品の品質不良のリスクとSQuaREシリーズ 国際標準(及び翻訳JIS)-その歴史と概要 #JaSST '17 Tokyo

講演者

  • 東 基樹

標準化について

  • ソフトウェアの標準化には皆さんの生まれる前からやっている。
  • 経営工学の基本は作業の標準化。重要なのは品質

NECでの思い出

  • NECでは、コンピュータの添付品としてお客さんのところへ行ったりした。
  • 私が入った年に倍々ゲーム。
    • 教育なんてできない。
    • ひどいサポートになっていた。
    • 仲間を集めて勝手に作業標準を作った。
  • 色んな様式、紙に埋めていく形式、本にしたらいっぱい売れた。マシンも売れるようになった。
  • PC8000が出てきたら、コンピュータを使うのはみんなになった。
  • 全社的な品質を野放しにすると全社的にひどいことになるよ。
    • →上の人がサポートして、全社的にバックアップしてもらった。
  • 全社会議で品質が大事と訴えた
  • それまでのテストは「動けばいい」という考えだった。
  • 品質展開、品質モデルを通じ、品質研究会を開いて、体験論文発表会を開いたりしていた。
  • 国際的にも論文発表していたら、早稲田大学に呼ばれた。
  • ずっと製品の品質というのは気になっている。

製品の利害関係者について

  • 以前はせいぜい数千ステップだったが、今ではメガ単位
  • 1ページの文章を書いたら1,2個のミスがあるのは当たり前。なので、誤りが無い製品というのはあり得ない。
  • SQueREでは利害関係者を重視していて、直接ユーザーに対する部分だけではない。
  • 直接ユーザーと間接ユーザーがいる。
    • 発表スライドでいえば、スライドを作る人が直接ユーザーに対して、そのスライドを見た人やこのスライドを広める人は間接ユーザーとなる。
  • ユーザーに対する品質も、どれも一緒とは言えない。
    • 中心ラインを踏むとアラームが鳴るのは良い面と悪い面がある
      • 良い面…中心線を超える
      • 悪い面…駐車中の車を抜かす
  • UNIXでプログラムを作るプログラマはカーソルキーが使えなかった。しかし、その状態が良いんです。実際、能率的に作業していた。しかし一般人は同じようにはできない。

SQueREの話

  • 国際的なユーザビリティのコミュニティがあるが、何にでも適用できると言い張る
    • 信頼性の低いものは…応答速度の遅いものは…どれもユーザビリティに直結する。拡大解釈して品質を飲み込もうとする。
  • SQueREは違う。エンドユーザーだけでなく、様々なステークホルダーのことを考えている。
  • SQuaREは「要求を満足する」だけでなく、暗黙的なニーズも範疇にしている。後は「当たり前品質」とか。例えば、寿司・刺し身には醤油が当たり前のように出てくる。サラダを頼むとドレッシングを聞かれる。「とりあえずビール」というと、銘柄を聞かれる。ステーキを頼むと焼き方を聞かれる。(フランスの場合はシェフに失礼。なんでも要求すれば良いわけではない。)

  • 良いものは設計から始まる。機能要求は書いてあることがあるが、品質要求が書いていないことが多い。

  • プルダウンの方が、ポップアップの方が…というのは品質ではあるが、最終的にはソフトウェアの機能要求に返ってくる。

  • 最初の品質モデルはKJ法。会議室の壁一面に「とりあえず品質の用語を張り出せ」「それをグループ化しろ」で出来た。

  • 「メトリクス」という言葉は今では使えない。カナダのオタワが猛反発した。メートル法ではないのでやめて欲しいという要求があった。

質問

なぜセキュリティは出てきたがセーフティは出てこないのか?

  • セキュリティはシステムの特性だが、セーフティは特性ではない。システムの結果として出て来るだけであり、利用時の品質で「リスク回避」にまとめている。

利用時の品質のところで混乱した。テストレベルの受け入れテストの部分と被っている部分がある。どういう段階で誰が使えば良いのか。出荷前の品質に携わっていた自分は使おうと思っていたが、出荷後の話も出ていた。

  • 利用時の品質特性と製品の品質特性の関連図を作っている。
  • 例えば、機能が不十分、使いづらい、保守性が悪い、これらを副特性のどれに関連するかというところから紐付けている。
  • しかし製品によって異なるので、一般的なものとしては出せない。
  • 実際にこれは今回のJaSSTのワークショップで体験してもらう。
  • 最終的には、製品に関わる人が体験してもらわないと難しい。

JaSST'16 Tohokuに参加してVSTePについて体験してきた #JaSSTtohoku #JaSST

告知ページ

JaSSTソフトウェアテストシンポジウム-JaSST'16 Tohoku

当日のツイートまとめ

togetter.com

基調講演「VSTePによるソフトウェアテストの開発」

VSTePの対象組織

  • 「このままでいいや、とどこかで思っている組織」はVSTePに取り組み価値が無い組織
    • 標準に沿っているから良いやと考えている組織
    • コンサルに全ておまかせしちゃえば大丈夫と考えている組織
    • 既に社内標準がしっかりしていて変えづらい状況の組織
      • しっかりしていること自体は良いことなので、わざわざ変える必要がない
  • 「このままじゃダメだ、と強く思っている組織」はVSTePに取り組み価値がある組織
    • 「仕様が無いので何をテストすれば良いか分からないからヤバい」と思っている組織
    • 「社内標準は既にあるけど、意味が無い」と感じている組織

VSTePとは

  • テスト観点を基盤としたテスト開発のための記法とテスト開発プロセス
  • 参考資料
  • テスト観点図、テストコンテナ図、テストフレームをつくることで、質の高いテストケースやテスト手順を作成する方法
  • 網羅性については考えていない
    • この作業をやって出てこなかった内容は、今の自分(チーム)の限界ということであり、漏れていたと把握できる状況にすることが大事

VSTePの構成

テスト観点図
  • テストケースごとのテストの意図を示したもの
  • テストケースの一部を抽象化したものになる
テストコンテナ図
  • テストレベルやテストタイプ、テストサイクルをまとめたもの
テストフレームとは
  • テストケースの雛形となるもの

VSTePのワークショップ

VSTePの進め方

  1. 仕様書を読む

    • どんな動きなのか把握するだけ
  2. 仕様書を読んだ感想や気になったところを一人ずつ喋ってもらう

    • あくまでもキッカケ作りなので、ここで色々議論する必要はない
  3. 付箋に観点となりそうなものを書き出す

    • これ以降は仕様書を閉じる!
    • 皆に聞こえるように喋りながら付箋に書く
      • 付箋に書いた内容が、別の内容を付箋に書くキッカケになるかもしれないため
    • 付箋に書いたものに対して詳しく聞いたり、ツッコミを入れるようなことはしない
    • 「これはテストする段階で行うものではなく、開発者が気にすべきところだから…」とか考えずに、思ったことはどんどん書く
  4. 書きだした付箋を見て、似たような内容(似たような意図で書かれたもの)をグルーピングする

    • その時、曖昧な言葉で記載していた場合は、「どういう意図で記載したのか」を書いた人に質問する
      • もしも、自分と認識が違った場合は、違う認識の点も付箋に貼る
        • 実際にワークショップ内であった例として、「メモリ」と書いた付箋に対し、「メモリ使用量」というパフォーマンス観点と「メモリ不足」というエラーの原因についての観点が出てきた。これらから、「メモリ」という付箋は捨て、「メモリ使用量」と「メモリ不足」の付箋を加えた。
      • 全員が同じ意図と理解するまで議論する。
        • 全員が理解し共有できていることが大事。
  5. グルーピングした付箋について、それらをまとめた(抽象化した)言葉を付け、ツリーを作成する。(テスト観点図の作成)

    • 例えば、「パスワード付きファイル」や「圧縮形式ではないファイル」については、「解凍するファイルの種類」とまとめた。
      • 先ほどの「メモリ不足」や「メモリ使用量」を「メモリ」とまとめることはしない。なぜならば、それぞれで意図が異なっているからである。
        • これを「メモリ」とまとめてしまうと、文字を見てまとめただけであり、綺麗なものにしようとしているに過ぎない(パット見て綺麗にすることが目的ではない)
    • 当日作成したテスト観点図 f:id:nihonbuson:20160524214341j:plain

      f:id:nihonbuson:20160524214419j:plain

      f:id:nihonbuson:20160524214449j:plain

    • 当日作成したテスト観点図をマインドマップで描き直したもの f:id:nihonbuson:20160523221445p:plain

  6. テスト観点図のトップノード(一番上の抽象化した言葉)を用いて、テストコンテナを作成する。

  7. テストコンテナを時系列で並べる
    • 当日作成したテストコンテナ図 f:id:nihonbuson:20160524214546j:plain

      f:id:nihonbuson:20160524214620j:plain

      f:id:nihonbuson:20160524214640j:plain

      f:id:nihonbuson:20160524214717j:plain

      f:id:nihonbuson:20160524214803j:plain

      f:id:nihonbuson:20160524214834j:plain

      f:id:nihonbuson:20160524214901j:plain

    • 当日作成したテストコンテナ図を描き直したもの f:id:nihonbuson:20160523221513p:plain

追加課題
  • このワークショップの最後に、「もしも圧縮機能を入れたら」という話になった。
  • これについては、「このコンテナの部分は再利用できるよね」「この観点図の部分は付箋が追加されるよね」と、一から作り直す必要もなく、メンテナンスしやすい形になっていることが実感できた。

復習

  • シンポジウムの翌日、復習を兼ねて、当日と違うグループの人と同じ課題(+Lhaca)でVSTePを行った。

成果物

  • 付箋にどんどん記載した時点の画像 f:id:nihonbuson:20160523221534j:plain

  • グルーピングした時点の画像

    • 一部ツリー化しており、この点は失敗している f:id:nihonbuson:20160523221612j:plain
前日との比較
  • 前日と違う観点が出てきた
  • しかしトップノードは似たようなものになることが多かった。
  • 途中で作業を抜ける人がいる場合、書いた意図が分からない付箋が存在することになった。
    • その際は、思い切ってその付箋を無くすことにした。
      • その付箋は抜けた人がいたからこそ出てくる項目であり、抜けたあとのチームの限界を超えているため
  • 復習会では、付箋を動かしやすい人と動かしにくい人が発生していたため、グルーピングがうまく行かなかった

感想

  • 事前の予習では、どのように観点図を作成すれば良いのか考えることが多かったが、実際に参加してみて、深く考えることなく(抽象度を気にすること無く)どんどん書いていけば良いと分かった。
  • 始める前は仕様書を見なくて書けるのかと疑問だったが、実際やってみると仕様書に書かれていないことがどんどん出てきた。

Git運用のコツについて発表してきた&発表時の補足 #Naite

先週の日曜日(4/24)にGitの運用について発表しました。

  • 告知ページ

nagasaki-it-engineers.connpass.com

  • 発表スライド

speakerdeck.com

はじめに ~この発表を行うきっかけ~

なぜGit運用という発表を行うことにしたか。

それはJJUGナイトセミナーの『Git入門』という回に行ってきたことがきっかけでした。

そこでは、よこなさんが分かりやすいGitの使い方を発表し、しょぼちむさんがGitを運用していくための方法を発表していました。

その時の参加記事はこれ↓

nihonbuson.hatenadiary.jp

これに参加した時に以下のようなことを思いました。

  • そもそものフローを知る機会(発表資料)ってなかなか無いのでは?
  • 運用をどうしてもマンパワーで頑張る感があったので、それをシステム的に何とかしたい!

ということで、これらについて今回発表しました。

特に、GitHubフロー及びGitフローについては時系列できちんとお伝えできたのでは?と感じてます。

スライドの補足

とはいえ、発表では、スライドに載せていないような補足説明が多かったので、それをお伝えしていきます。

5ページ

f:id:nihonbuson:20160502135511p:plain

Gitのコマンド的な話は、今回の発表内容の本筋とは違うので、全てよこなさんのスライドを参考にしてもらうことにしました。

12ページ

f:id:nihonbuson:20160506124737p:plain

当日、質問もあったところですが、ここで主張しているSVNとGitの違いはどちらかと言うとローカル上の話です。

例えば、Jenkinsで対象のブランチを変更したい場合、SVNもGitもどちらともcheckoutを行うと思います。

ただしその際に、SVNでは新たにソースを取りに行く必要があります。

一方Gitは切り替えだけで済みます。

(ここで「リポジトリの複製」という表現を使ったのは完全に間違いでしたね…)

24ページ

f:id:nihonbuson:20160502135529p:plain

ここでの(今回のスライドでの)点線は、リモート上からローカル上にpullしたりpushしたりする部分を表しています。 本当はmasterだって一緒に持ってくるだろうし、正確な図ではないことは百も承知ですが、ここではこのような表記にしています。

28ページ

f:id:nihonbuson:20160502135557p:plain

この図は、「あくまでもローカルとやり取りして、ソースの修正とかが入ってくるのはそれぞれのtopicブランチであり、masterには直接入ることが無いよ」ということを示したかったんです。

43ページ

f:id:nihonbuson:20160502135615p:plain

休憩として、小学校の時に使ったであろう筆洗バケツの話をしました。

ただ、当日の参加者は意外と使っていない(覚えていない)ようで、ピンときてもらえませんでした…。

これは「洗い水やすすぎ水という部分があるから、水を含ませるために使う付け水は、汚れの殆ど無い状態になるよ」と言いたかったんです。

後ほどのスライドに出てくる「topicブランチからのプルリクエストなどの仕組みによって、masterが綺麗な状態に保たれてすぐに適用可能なものになっている」と結びつけるつもりでした。

46ページ

f:id:nihonbuson:20160502135645p:plain

SVNなどのプルリクエストという仕組みが無いところでは、きっとWinMergeやレビューボードを使って頑張っているのだろうなと思っています。

ただし、それらはローカル上で他の人に確認してもらうか、trunk(Gitでいうmaster)にコミットされた後にレビューしてもらうので、非常にコードの状態がよろしくないと思っています。

49ページ

f:id:nihonbuson:20160502135705p:plain

このチケット駆動開発のブランチでの仕組みというのは、以下のようなメリットが生まれます。

  • 本当にその案件の部分しか変更しないようになる
  • 案件に基づいた部分のレビューがしやすい
  • 案件を次サイクルに持ち越した場合に、SVNの時に発生していたような切り戻し作業を行わなくて済む

62ページ

f:id:nihonbuson:20160502135728p:plain

上記でも書いた、チケット駆動開発を確実に行うために、チケット番号が入ったブランチ名にしているかをhookで掴んでチェックするような仕組みを取り入れるべきでしょう。

そうしないと、「ブランチ名をチケット番号にして!」というアナウンスを新しい人が来たり、間違いが発生する度に伝えることになり、教育コストが高くなります。

参考文献

  • slideshareならリンクが貼れて、直接スライドから該当ページに飛べるのですが、speakerdeckではその機能が無いようなので、ここでもリンクを貼っておきます。
    • 本当はslideshareにしたかったけど、フォントの問題でスライドがそのまま反映されないみたいなので、なくなくspeakerdeckへ( ;∀;)

Git-scm

https://git-scm.com

A successful Git branching model

nvie.com

GitHub Flow 図解

qiita.com

git-flow cheatsheet

git-flow cheatsheet

Gitはじめの一歩

www.slideshare.net

一休.comにおけるデプロイフローと自動化

speakerdeck.com

水彩絵の具の使い方

educe-web.craypas.co.jp

"Luca, フォース(force)を使え" - Jenkins開発者が1ヶ月分のGitHubコミットを消失

www.infoq.com

さいごに ~反省内容~

発表時間を余らせてしまったのは反省…。というか、発表終了の時間を間違えてました。

あと、上記でも書きましたが、12ページの「リポジトリの複製」という記載は誤解を招く記述でした。

まあ、あとは概ね発表で伝えたかった内容をほとんど伝えられたので良かったです。

デブサミ2016再演『今日の習慣が明日をつくる~よりよい技術者を目指して~』参加レポート #devsumi

発表スライド

docs.google.com

概要

  • 習慣的に行っている訓練のうち、明文化できるものを伝える
  • 言っても問題が無いもの
  • 技術者の週間を見直すきっかけを
  • 1年で成長することはない。4,5年かけて成長する

良い技術者とは

  • 読む力
  • 書く力
    • コードを書けるのは評価されない
    • ドキュメントを書くのも重要
  • 捨てる力
    • 自分や組織が作ったものを捨てる、再実装する

読む力

  • 仕様を理解する
  • 仕様を類推する
    • 「地球上で動作する」なんて前提条件は書かない
    • 今暗黙のものが未来永劫変わらないとは限らない
  • コードを理解する
    • ゴミのようなコードが数十万行ある中で、新機能を探したりとか
    • 3個先の呼び出し状態を暗記した状態とか
  • コードを評価する
    • 設計や品質の妥当性を検証する
    • 沢山読めても、良い物が分からなければ読む力があるとはいえない

書く力

  • 仕様に対して妥当なアルゴリズムを実装できる能力
  • 書いたコードの制約事項を明らかにする
    • CPU heavyなのかメモリheavyなのか
    • 技量が足りないエンジニアは、1種類の書き方しか分からなかったりする
  • 書いたコードの最低限の品質をテストによって保証する納涼
    • QAエンジニアは品質に対して特殊な人達

捨てる力

  • 現在のコードを作りなおす能力
  • 厳密に再定義する能力
  • 様々な方法で表現する能力
    • 多種多様な言語とか
  • 自分のコードは捨てられるはず

良い技術者になる方法

  • 仕様書とコードを大量に書いて読んで捨てる

標準化された仕様書

  • 読んでおけば網羅性が増える
    • ISOとかIEEEとかIETCとか
    • JavaならJEPとかJCPとか
  • 高度に整備された知見から都合の良い部分だけ拾うため
    • 1から作るより簡単
  • 原理原則を理解するため
    • 何となく動かないから頑張るのではなく、仕様を確認する
    • 仕様通りだけど動きが気に入らないというのはあまり良くない
  • アプリケーションやミドルウェアが正しく動いているかを検証するため

まずはHTMLから

  • W3CWHATWGの仕様書を確認する
    • ググった最初のページを参考にするとか止めよう

RFC

  • RFC2119は要求を表す言い回しについて理解する

HTTP1.1

  • RFC7231を開始点にする
  • 最初は流し読みしてボリューム感を掴む
  • 関連のRFCのポインタがいっぱいあるのでオススメ

JSR

IEEE

  • IEEE754-2008
    • 浮動小数点演算に関する仕様
    • 如何に不安定か分かる
    • 仕様書が2万円ぐらいかかる
      • 会社の金で買いましょう

網羅性が気になったらISO

  • ISO12207
    • ソフトウェアのライフサイクル
    • 自分がやったことと全体との違いが分かる
  • ISO90003

仕様書を読もう

  • 仕様書によって決まるべき
  • 誰かのフィーリングではなく

コードを書こう

  • 大量の良いコードがある
    • 個人のやってみたみたいな悪いコードもある
    • Gitみたいな巨大なプロジェクトの悪いコードもある
  • 貢献の機会がある
    • 個人のリポジトリ
    • 小さいライブラリのコミュニティ
    • 大きいライブラリのコミュニティ

まずは毎日ログイン

  • Trending repositoriesを見よう
  • 言語のトレンドとかを見るだけで良い
  • 惰性で見れるように

Github以外の情報源

  • Tech Blog
    • AWS(Security)
      • Linuxのことはだいたい分かる
  • VOXXED

毎日30分コードを眺めよう

  • トレンドに上がっていれば食わず嫌いせずに眺めてみよう
  • ネストが深いけど、Goなので深くなるし、規則性がある

なぜコードを眺めるのか

  • 恐れを減らすため
  • デジャブ感のあるものは挫折しづらい
  • 良い処理構造(ネストが深いとか)はあまり言語に関係ない

  • モチベーション無しにコードを見られるようになろう

  • 集中しないと読めないとか無いように

リポジトリの選び方

  • 得意な言語のリポジトリ
  • リポジトリの説明が分かりやすい
  • READMEがしっかり書かれてる
    • ビルド方法が書いてないものは読むに値しない
  • 基本的な使い方が書いてある
  • 半年以内にコミットがある
  • CI(TravisCI)とかで成功が維持されているもの

コードの読み始め方

  • 依存ライブラリを確認
    • 依存ライブラリで知らないものはそっちを優先した方が良いかも
  • ビルド環境構築
    • Windowsだとビルド環境辛い
    • 色んなことが分かる
      • 如何にWindowsがクソかとか
  • Unitテストを実行する
    • Windowsのみ動かないことも
  • エディタやIDEは慣れたものを
    • コードとエディタ同時に新しいものをするのは良くない

コードの読み方

  • 全部のコードを何度も眺める
    • 20000ステップを30分ぐらいで読めるようになる
  • 外部との境界面となる場所から読む
  • 仮説と検証を繰り返しながら読む
    • 関数名から動く内容を想定する
      • rubyは関数名をガンガン変える
      • Javaは関数名が長くなりがち
      • Hasskellは数学的に完璧な名前を付けたがる
  • 抽象度の高い部分を優先して理解する
    • Javaだったらインタフェースとか
  • 難しい部分は後回し
  • コードが荒れているならgit blameすると良い

    • 色んな人が理由あって沢山触っているはず
  • コードを高速に読もう

コードを書く習慣

  • 規模のある組織においてはミドルマネジメントは重要な仕事
    • 100人ぐらいいて、ミドルマネジメントがいなくて好き勝手書いている企業はブラックになりがち

一人砂場プロジェクト

  • しがらみの無い自由を味わうため
  • 自身の能力を客観的に評価するため
  • 自身の価値観を少しずつ変えるため
    • 企業内では味わえないもの
  • 価値の不明瞭なものを評価するため

一人砂場プロジェクトで何する?

ネタがない?

  • 短縮URLを生成する画面の無いサーバ

    • groovyだったら15行ぐらいで書ける
  • 小さい車輪を再発明しよう

毎日少しずつ書こう

  • 最初は毎日エディタを起動して新しいプラグイン入れるだけで良い

コードを捨てる体験をしよう

  • 捨てることでもっとうまくもっと早くやり直せる
  • 始まりから終わりまでやり直す
  • 良い技術者は同じ仕様で何度もやり直す人が多い

質問

  • ISOはPDFだけ?
  • 紙もある
  • 図書館にある?
  • ある
  • 解説本も良いけど、原文も読もう