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だけ?
  • 紙もある
  • 図書館にある?
  • ある
  • 解説本も良いけど、原文も読もう

デブサミ2016再演『ソフトウェアテストから見たクックパッドのモバイルアプリ開発』参加レポート #devsumi

発表スライド

www.slideshare.net

クックパッド

  • cookpad.com/en とか
  • 全世界で2000万人/月(日本を除く)
  • 日本は5755万人/月
  • アプリユーザーの方がアカウントを持っている人が多い
  • iOS
    • Essentials
      • Apple社が認めるマーク
  • Android
    • 2年前にネイティブアプリ化
    • 1年前に☆4,最近はトップデベロッパーに

2年前

  • 2014年の障害件数の多い部分はほとんどモバイルアプリ
  • 組織の変化
  • 関わり方の変化
  • テストエンジニアの価値の変化

品質

  • Quality is value to some person.
  • テストエンジニアが組織に属していても、人によって変わる
  • Quality is not equal test.
  • 品質活動は手段である

Developerとの関わり

  • 仮設→実行→検証

Userとの関わり

  • ユーザーから挙がってきた声を事業部に結ぶ

2年前にあったこと

  • 定着したWeb開発のスタイル
  • サービス開発と基盤/インフラの人達の区分
  • コンウェイの法則

2014年

組織づくり

  • サービス開発は縦組織に対して、インフラ・デザイナは横串を通していた
  • さらにモバイルファースト室を横串を作った

仕組みづくり

  • プロセス作り
    • リズムを作る
  • リリースマネージャ
  • ブランチ戦略と欠陥管理

振り返りと改善の習慣化

  • 振り返りを2週間ごとに

テスト関係の効率化

  • 手順、期待結果、分類
    • これで十分なのか分からない
  • 普通の設計と同じように、場合によって組み合わせが変わる
  • 実行の自動化
  • 項目の分類
  • 開発時の心的負担の軽減
  • 最後の砦
  • 開発とテストの分離ではなく、統合

Try

  • Tryと失敗を繰り返している

2015年

  • まだクラッシュ数は多いが、モバイルアプリの開発者がとても多くなっていった

組織

  • サービスそれぞれにモバイル基盤チームが関わるように
  • 2,3週間で10人ぐらいがコミットする
  • デザイナを大きく巻き込んだ
    • デザイナが体験の設計と責任を読む
      • ラベルを変更するとBOTが反応するようにした
  • PR毎、masterマージ毎、リリース毎で行うテスト内容に変化をつけた

2016年

  • フィードバック・ループの深化

気をつけていたもの

  • 関係性
    • 疎遠になるものは無くす
      • 飲み、振り返り、雑談の機会を増やすなど
  • 低い意識で続けることができる環境の構築

悩み

  • 経験ベースとルール/知識ベースの知見をどのような比重をかけて障害を予防していくか
    • 経験ベースだと不具合を起こしやすいが、修正はしっかりできる
    • ルール/知識ベースの知見は修正がしっかりできない

テストエンジニアとして聞かれること

  • モチベーション
    • Qualityに対して集中することができる職である
    • テストはオペレーターではなく、ボトルネックを探すために幅広い知識が必要

施策を進める上で大事だったことは

  • 尊敬、すごい、などを集める
    • テストエンジニアなのにコードでかけるとか

コーディングスキルは?

  • システムの構成要素の理解の方が重要

質問

  • 手動テストはどのようなことをやっているか?
  • バイスの互換性はどうやっているのか?
  • マニュアルテストは今もやっている
  • 2014年〜2015年はAndroidは2系
  • 外部起因での不具合は限られる
    • カメラを使っているなど
    • こういうのは外部に委託した
  • 2015年からは4系のみをサポートしたので楽になった

デブサミ2016再演『アジャイル開発(GINZA)』参加レポート #devsumi

発表スライド

http://niconare.nicovideo.jp/watch/kn1140niconare.nicovideo.jp

今日覚えて帰ってほしいこと

  • Practice Slaves kill Development
    • Scrum Slaves
      • スクラムを守ることがプロジェクト成功の全て」というがんじがらめ

ZERO

アジャイルの原点

  • アジャイルソフトウェア開発宣言
  • アジャイルソフトウェア12の原則

    • 開発は短い期間でやりましょう
    • 動くソフトウェアを中心でコミットメントを取っていきましょう
    • 関係者とのコミュニケーション
    • やり方を最適化
  • 「こうしろ!」なんて出てこない!

    • 朝会しましょうとか
    • KPTしましょうとか
  • Do Agile right

    • 正しいAgileってなんなの?
    • 信じることで救われた"気持ち"になる

アジャイルを取り巻く環境

  • 沢山のツール
  • 沢山の手法
  • 高価な認証制度
  • ラクティスの盲信
  • 学術的アプローチをする人が増えたなぁ…
  • 経験論的な話がなくなってきた
  • Agile is Dead

  • 実際、プラクティスを盲信するあまり、うまく行ってないプロダクト群がニコニコにもある

  • GINZAでは新Versionを出さず、直すフェーズになっている

Q

  • ZEROが出た2012/05で不評だったので2012/10に新Versionをすぐに出した

進むために

  • メトリクスをとって現在位置と目的地を知る
  • 目的地に迎えれば、方法が変わっても良い

現在位置を知る

  • これまで何をしてきた?
  • いま何をしている?
    • テストフェーズ
  • これから何をするのか?
  • 今どれくらいのスピードなのか
    • あと3ヶ月なのにタスクがいっぱいある
      • リソースを増やすなどの臨機応変の対応ができるのか

目的地を知る

  • どこに向かっているのか?
    • ロールアウトするまでとか
    • 収益が上げられるまでとか
  • いつ到着するか?
  • リソースは足りているか?
  • 行く途中によるべきところはあるか?
    • 羽田→那覇の旅なのに、経由地が札幌とかだとおかしい
    • よく失敗するところ
      • 「このサービスと一緒にやっていったほうがよいのでは?」とか入って、開発がかさんでしまう
    • できるだけまっすぐ進む

ゆっくり進路を変える

  • 急に変えても上手くいかない
    • いきなり変えても、メンバーのスキルセットは変わらない
  • なぜ変えるのか説明する

自分の立ち位置と技法のマッチ

  • スクラムのタイムボックスが適任だ」とかではない
  • 仕様がしっかり固まっているならウォーターフォームの方が良かったりする
  • ミスマッチなら、新しい技法を探そう
    • エンジニアって基本新しいものを使いたがる
    • 自分達にあっていたかどうか判断しなかったのがドワンゴの失敗
    • 「教条的にスクラムが正しい」→どんなところが正しかったの?→主張できない
    • こう進んでいくしかないよねとなっていた
    • 定期的に振り返りが必要
    • どうやって原点に立ち戻って評価すれば良いのかが難しい
    • コストオーバー、納期オーバーした時にその原因を調べられなかったことが多かった

GINZA

  • 厳密さを捨てる勇気
    • 自分達に必要なところを見つけ出す
  • Practice is "Kata"
    • あくまでも基本形であって全てではない
  • もっと自由にやれば良い

マネージャを縛る鎖

  • クオリティ
  • コスト
  • スケジュール

まとめ

  • "Agility"の高い開発を目指す
    • 要求に素早く対応する
  • 全てを疑って、最善手を考えろ

質問

  • Agileをやっていて上手くいかなかった具体例は?
  • タイムボックスの管理は上手くいかなかった。
    • 出来るものからやる→大きすぎるタスクが入らなかった
    • 2週間で終わるべきではないものは3週間でも良いからタスクを入れるようにすべきだった

特別セミナー「アジャイル品質とソフトウェアパターン」参加レポート

告知ページ

特別セミナー「アジャイル品質とソフトウェアパターン」 2月22日 | Reliable Software Engineering, Washizaki Laboratory

講演1:アジャイル開発へのソフトウェア工学的アプローチ:イテレーション期間と学習ワークショップ

スライド

www.slideshare.net

経緯

  • 水曜日に台湾でソフトウェアパターンの国際会議が開かれる
  • 今週台湾に来るんだったら、日本にもお越しいただいてセミナーを開こう!(2週間前)
  • 非常にHotな品質とアジャイル開発について学んでいく

はじめに

  • アジャイル開発に関連する領域について取り組んでいるので、それについて紹介する

動機付け

  • アジャイルは科学不足
    • 他のプロセスに比べて
  • Cynefinフレームワークより
  • 横軸…解放が既知かどうか
  • 縦軸…問題が複雑か単純か
  • 第1象限…グッドプラクティス
  • 第2象限…突発・創発(Emergent)
  • 第3象限…新規(の研究)
  • 第4象限…ベストプラクティス

  • 本来扱うべきところと実際に扱う場所が異なっているのではないか

  • プラクティスなものに対して科学的裏付けをして、境界条件や本来のアジャイル開発の場所に持っていくプラクティスを探ってみるべき
  • まだそこまで出来ていないので、地道に行っていく

  • 科学的に出来ないのか

    • イテレーション期間を長く取るべきか短く取るべきか
    • ワークショップが有用なのか
  • イテレーション期間について必要ない部分をバッサリ切ってモデル化する

  • 机上の(計算機上の)シミュレーションを行ってきた結果
  • 要求の不確実性大→イテレーション期間を短めに
  • 要求間の依存関係複雑さ→イテレーション期間を眺めに

講演2:ソフトウェア信頼性予測のプロジェクト進行中の動的な活用

ソフトウェア信頼性モデルとアクションを結びつける

  • 信頼性モデルの利用
  • 開発の最後、振り返りが主な利用シーン

  • 状況のモニタリング

  • CIツール
  • R言語

  • 異常の検知

  • 信頼性モデルの解釈とアクション

欠陥と信頼性

  • 欠陥数の予測について
  • 信頼性に対して、欠陥を十分に発見できたかどうかを評価する基準
  • 欠陥数を予測し、取り除くべき欠陥数を定める
  • ソフトウェア信頼性モデル
  • どれだけテストを行えばよいか、リリース時期を測ったりする
  • 発見した欠陥を累積として日毎、週ごとに測定

  • 開発における問題

  • 欠陥を十分に発見できているか
  • 予測される欠陥数に対して今どれだけ欠陥を見つけたか

  • リリースに間に合うか判断できない

  • 開発のスコープ決定を支援
  • テスト工数、計画の支援

CIツールリポジトリシステムを用いた欠陥数予測

  • Jenkinsを用いて自動的に欠陥数を取得する
  • R言語を用いて欠陥数を予測する

リリース時期の分析

予期せぬ状況の発見

動機付け

  • ソフトウェア信頼性モデルが不一致になる場所がある
    • なぜそのようなことが起きるのか?
  • 期待を超える時期が発生する

欠陥をテストフェーズで分類

  • 継続的に問題が発生
  • いくつかの問題が再発生したので、開発者がテストを止めて他のテストを再開させた

まとめと今後

  • 今後は欠陥のデータベースを作りたい

質問

  • 未解決な欠陥については研究の対象にしていないのか?
  • していない
  • 是非とも、対象にして欲しい
  • PMが欠陥の理由を説明できない
  • 比率を見て、どんどん欠陥が減っていっているか
  • 見つかった欠陥をいつ修正されているかも研究の対象にしているところ

  • バグの影響範囲や重要度、優先度は取り入れているのか

  • 今回の研究では対象にしていない
  • バグの重複についてはフィルターをかけている
  • ユースケースで95%修正でリリースとしているが、残っているバグがクリティカルならばリリースできない

講演3:QA to AQ(Agile Quality): Being Agile at Quality

発表スライド

http://www.washi.cs.waseda.ac.jp/wp-content/uploads/2016/02/QA2AQ-Waseda-2016-.pdf

自己紹介

  • Joseph Yoder

トレードオフ

リーン開発

アジャイルとは

非機能要件

  • 非機能要件をユーザーストーリーでどのように表すか

  • 非機能要件とかも重要なのに、スケーラブルだから大丈夫…?

  • QA→QC

  • プロセス管理

  • 色々なパターンに当てはまるかどうか

  • バリアをいかに壊すか

  • 文化、言語、様々なバリアがある

    • QAが敵と考えられたりする
  • アジャイルチーム

  • QAの60%はユニットテスト

  • Tearing Down the Walls: Embedding QA in a TDD/Pairing and Agile Environment

  • Test early

  • Automate "easy" test

  • Qualify Loadmap

  • Qualify the Backlog
  • Quality Checklists

  • Quality Splints

  • Monitor Qualities

  • Usabilityをどうやって計測する?

  • "Quality Debt related to Technical debt."

  • SteveMcConnell https://kev.inburke.com/kevin/the-best-ways-to-find-bugs-in-your-code/

Agile Quality Benefits

  • Visibility
  • Effectiveness
  • Architectual Risk

Being Pragmatic

  • Do the Agile
  • Be the Agile

  • No Planning No Design...Sometimes calls Agile

  • Lot's of upfribt planning... Transitional Waterfall

  • Ultimate Agile Stories

質問

  • Agileの品質モデルはどのようなものがあるか
    • ウォータモデルならV字モデルがあったりするが…
  • Valueが出るようにすれば良い
  • Being Agileがなれば良い
  • Vモデルでも良いが、改善させていくことが大切

  • Test Baseをどのようにゲットするか

  • Agile Manifestによる
  • ドキュメントはValue
  • Agile StoryがValueになる
  • catalog, method

パターン一覧

  • 障壁の解体
  • アジャイルプロセスへの品質の組み入れ
  • 本質的な品質の発見
  • アジャイル品質シナリオ
  • 品質ストーリー
  • 測定可能な値やシステム品質の特定
  • 折り込み品質
  • アジャイルな着地点
  • 着地点の再調整
  • 品質目標の合意
  • システム品質ダッシュボード
  • システム品質ラジエータ(可視化する仕組みを用意する)
  • ロードマップの品質検討
  • バックログ上の品質検討
  • 品質チャート
  • チーム全体
  • 品質に焦点をあてたスプリント
  • 品質保証プロダクトチャンピオン
  • アジャイル品質の専門家
  • 品質のモニタリング
  • アジャイル品質保証テスター
  • 品質に関する作業負荷の展開
  • 品質熟練者の備考
  • 品質主義者とのペア

『時代の変遷と共に変わるテスト〜IoT世界に求められるテスト〜』参加レポート #jasst

自己紹介

二木

  • セキュリティ屋の立場
  • デベロッパーの方には嫌われる立場
  • 最近はクラウドのセキュリティをやっている

吉澤

  • 日本(にっぽん)電気
  • デバイス経験が多い
  • IoTの下支え中心
  • 最近は品質向上活動
  • IoTは何をテストするのかよくわからなかった

辰巳

  • ソフトウェアの検査
  • SQuBOKに関わっていたり
  • テストの歴史的な話
  • 昔からテストをやっていた人からの意見を言いたい

IoTの定義

  • インターネット上のサービスと接続されたデバイスあるいは相互接続されたデバイスによって実現されるサービス
  • デバイスとサービスは他の組織が提供することを相互接続して利用することがある

keynoteより

  • ハッカーがハンドルから手を話しても自動操作しているのを使うことで事故を起こさせる
    • ジープ
  • ISOでも3層ドメインになっている
  • 入り組んだサービスについてもISOでモデリングされている
  • デバイス側もどういうふうにやり取りするのかはISOやIECでモデリングされている

  • これらからどんな課題があるのか

二木

近未来のIoTワールド

  • Cloudブローカーみたいにサービスブローカーが出てくるかも
  • デバイスとサービスのひも付けの間にデバイス管理をするレイヤーが挟まるだろう

雲の上から見たIoT

  • IoTもサプライチェーンを構成していくだろう
  • IoTは閉じた世界ではなくなるだろう
    • ワイパーを動いているかどうか見てその地域の天気を調べる仕組みとかしている
  • 想定を超えた使われ方をしていくかも
  • セキュリティ屋の心配事

吉澤

  • デバイス側から話す
  • デバイスに求められる機能は3つ
    • センサ
    • アナライズ
    • アクチュエータ
  • 従来は限られた世界でちゃんと動くこと
    • お約束に従ってちゃんと動くことを保証すれば良い
  • IoTになっていくことで、効率化しないと大量のデータを処理できないのではないか
  • それとともにセキュリティも気をつけなければならない
  • 得体のしれないものとつながる脅威
  • 内部の脅威
    • 保証されない
    • 意図しない年数使われる

テスト

  • 今まで以上に一つ一つがきちんと動いていることを保証する(十分性の保証)
  • 今まで以上に行わなくてはならない
    • セキュリティ
    • 大量データや環境などを含めた組み合わせテスト
    • 通信制の確保
    • データをチェックする境界線
      • 自分はどこまでテストすれば良いのか

二木

  • どこまで想定外を排除できるか
  • 自分のところはきちんとテストする
  • 仕様にこういうデータは入ってこないんだからチェックしなくて良い!と言われた
  • セキュリティも製品やサービスの一部だという意識を
  • 脆弱性は基本的にはバグである。
  • パフォーマンスや運用に影響をあたえるものが脆弱性である
  • 設計時にセキュリティ機構を組み込む
  • 実装時のバグ潰し
    • APIに対する異常な取り扱いに対する体制のチェック
  • 500エラーで返されるとしめた!(サーバーエラーになっている可能性あり)と思う
  • リスクの高い使われ方を如何に潰していくか(サーキットブレーカー)
  • APIを使ってごっそり抜かれないように、必要以上のところへのアクセス制限をかける
  • 大量データを抜けないかどうかもテストの観点

辰巳

  • ビジネスの観点からアプローチを披露して欲しい(松岡)
  • つながった上でIoTをどうやってやるのかという観点
  • 使う側/活用する側のシステムのテスト

課題

  • テストの対象の見極め
    • 上位から見て着目すべきところは?
  • ビジネス視点での評価
    • IoTはビジネスチャンスとして考えた時に、テスターとしての役割は?

課題解決のために

  • テスターが持つべきスキル/素養
    • テクノロジーの知識、ビジネスドメインの知識
    • レイヤーの理解、APIの知識
  • テスト技術の研究成果の活用
  • つなぐための標準化、規約化への関与
    • テストのための仕組みも標準の中に取り込む
      • テスターからの積極的な提言が必要
  • 組織的な取り組み
    • テスターの専門分化
      • より深くやるテスターが必要になる
    • デベロッパーとテスターの役割分担の追求
  • テスト環境、標準化検証環境の整備
    • テストラボ
    • 標準検証スイート
  • テストのエコシステム

Jon

  • 二木さんが提案していた脆弱性とかを悪いことする人達はお金になるので一生懸命研究すると思うので、頑張ろうとするでしょう
  • スペースシャトルのような巨大アプローチの中でどういう風にしたら良いと思うか

  • 過去の大型案件を考えると、小さなエリアに分けてそれをだんだん組み合わせてやる

  • テストは何階層もあり、デバイス、メーカー、ドメイン、政府のテストがあると思う
  • 製品レベル(モバイル)、ネットワーク、IT、クラウド、全てを組み合わせてIoTのテストになる
  • プロセスレベル、プロダクトレベルなど、各レベルで標準化しなければならないが、策定までには時間がかかるだろう
  • フェールセーフのためのサーキットブレーカーを入れるのは良いことだと思う
  • IoTの世界においては、大型のシステムでは故障に直面すると思う。
  • ユーザーがデバイスに接続方法が様々あり、全てのレベルでテストベッドが必要
  • IoTと一口で言っても、サイバーと物理的な世界でのものなので、生命にも関わったりすることがある

松岡

  • 脆弱性はバグなのか、バグでないのか
  • 私は二木さんと吉澤さんの両方の経験を把握している
  • 脆弱性はバグと捉えている
  • バグではなく仕様上の欠陥ということもある
    • 上位から降りてきたもののフォーマットが自分が用意しているフォーマットと全然違ったことが

吉澤

  • 「標準」が今は無いが、標準を使って複数テストすると思うが、標準を使わなくなった世界ではどうするか?
  • 困りますね
  • 標準があれば一つ一つ確認はできる
  • ただし、標準があっても、捉え方が違ってしまうと希望通りの性能が出せるか微妙ではある
    • 現に上の人と下の人で変わってきてしまうと思う

辰巳

  • 標準化はまだまだこれからだと思うが、プロジェクトは進むよね?その上でどうすれば良いのか?ビジネス側では何を見れば良いのか
  • おそらくTry and Errorでやらなければならない
  • お客様に迷惑がかからないように
  • 検証とかで抑えていかなければいけない
    • こういう時にテスターの出番かも
  • OSが安定していない時に、どういう風に回避しつつ運用で安定していくか考える
  • IoTの世界なので、膨大なパターンが有る中では難しいかも

Jon

  • アメリカ政府には沢山のカウボーイがいました
  • フロンティアだよと言いたいんだろう(松岡)

松岡

  • マイクロソフトのOSのVerUpを抑えるようにした回避策とかはある
  • ビジネス面から見れば、確かに回避策のアプローチを取らなければならない
  • 大きな塊の中でどうやってテストをやっていく時に、どういう形で担保するようなテストをシステムレベルでやれば良いのか

Jon

  • 私がおすすめするのは、色々なものを組み合わせてテストする方法
  • アメリカでの面白い取り組みとして、大規模なしくみを自動テストで保証するために多くの組み合わせで保証した
  • まだまだ我々も学習中ですが、それが役に立つと思う

松岡

  • 標準化、規格化について、
  • セキュリティはまだまだ進んでいないのでは?

二木

  • 一部、セキュリティに関しての動きはあるが、一つの形を作るのは難しい
  • 個別の分野ごとにセキュリティの規格が定まってくるのではないか

吉澤

  • 標準が変わったら?
  • やり直し。仕様の中に紛れ込むので難しいところはあるが

Jon

  • やり直しという考え方は正しいと思う
  • Agileという考え方が重要

松岡

  • reworkも含め、テストも進めていかなければならない
  • IoTのテストをするときに、どんなことをrequirementする必要があるか

Jon

  • 時間、場所、コンテキスト、コンテントに関する認識をした上でテスターはやらなければならない

吉澤

  • ソフトウェアの設計でちゃんと対応していれば良い。
  • 標準が次々に変わるとわかっていれば、その部分についてだけテストを変えることは良いことだと思う

まとめ

  • Jonが言ったように、IoTが動く仕組みやそれに伴う制約をきちんと理解し、標準が変わる変わらないも認識した上で、IoTのテストを頑張らないといけない
  • 個別のテストの話として、脆弱性をテストする基本的なテクニックはやっていかないといけない
  • 責任分割点は難しいが、サービスを提供して、満足させるところがどこまでなのかを可視化できるかどうか
    • 可視化されるためのテスト
  • お金に関わる話なので、ここまでは大丈夫という線引をしなければならない
  • 今後のプロジェクトの中で、一つの指針としてここでの話を活用して欲しい

辰巳

  • 自分の思いは問題解決のためにというところ
  • IoTはチャンスではあるので、テスターとしての腕を磨いて欲しい

吉澤

  • 松岡さんから可視化が大事、そのためにテストがあると言っていた。その中でJonのリストが役立つ。

二木

  • どこまでやれば良いか?とよく聞かれるが「リスクベースで考えましょう」と答えている
  • どんなインパクトがあるか
    • 医療系や車では人命に関わる
    • 個人情報に関わる
    • 繋がっているデバイスの数

Jon

  • IoTが訪れる間、発生する変化に楽しんで欲しい

質問

標準化について。IoTは新しい技術が出てきてChangeすると思うが。標準化と変化、どちらが速いと感じているか

  • 標準の問題は合意形成に時間が掛かるということ。かなりの遅延が怒ると思う
  • 製品の標準化は自然淘汰が多いので、時間がかかる
  • だから、「変化を楽しめ」というメッセージを言った

変化を楽しんでいる間、よくわからない状態でやるテストとしてユースケースで攻める、組み合わせをオートメーションする手法があると言っているが、ユースケースを元にしたSearch Based Testingということか?

  • 組み合わせテストの背景としては自動化のレベルを上げたい

品質保証部、テストチームの振る舞いが気になっている。IoTだと正解が分からないことになっていくと思う。その場合、開発と一緒のチームとして動くべきか?

  • 開発も品質保証もテストもオペレーション部隊も上位においては統合すべきだと思う
  • 多くの人は慣れ親しんでいないと思うが(Jon)
  • 是非セキュリティの人も入れて欲しい。
  • 開発畑から来たセキュリティの人が適任だと思う(二木)
  • DeveloperとTesterの関係について。開発部門がテストも含めて自信をもってつくる。Testerがそれをさらに確認する。それが最近はAgile Testingになったりする。
  • 新しいことをチャレンジしなければならないが、それで別部門を作って、きっちりやる部門と挑戦する部門で分かれてやっていくことが必要なのではないか(辰巳)

『テストプロセス改善技術から探るテストの"改善"とは』参加レポート #jasst

テストプロセス改善

登壇者の紹介

  • 薮田
    • TPI NEXTの立場から
  • 増田
    • ISO/IEC 33063の立場から
  • 西
    • ノンモデルのプロセス改善の立場から
  • 足立(モデレータ)
    • SaPIDの立場から
  • 池田(モデレータ)
    • TMMIやTPIを導入支援した立場から

テストプロセス改善技術のこれまで

  • まだまだテストプロセス改善は実施されていない
  • ただし、最近発表が増えてきている

TPI NEXT(薮田)

  • 自己評価とそれに基づく自己解決
    • 他人に見せても何も分からない
  • 評価軸はプロセスではない
    • 独自に選定した16個のキーエリア
  • ビジネス主導である

ISO/IEC 33063(増田)

  • 国際標準であること
    • 認証はこれから?
  • アセスメントモデルから…
    • 何のプロセスにあっているの?
      • ISO/IEC/IEEE 29119-2
    • どれくらいあっているの?
      • ISO/IEC 33020

ノンモデルのプロセス改善

  • TQM
  • 品質管理を一生懸命すると頭が良くなる
  • TQMはマニュアルではない
  • 人の数、会社の数だけTQMがある
  • 理解して適用するのではなく、自分の会社なりにTQMを進化させることが大切

ソフトウェアテストの現状(海外の人から言われること)

  • 日本は品質の高い会社があるんだからソフトウェアでもやればいいじゃないか
  • なんで海外のプロセス改善を買ってくるの?

TQMの思想

  • 思想を理解せずにツールボックスとして使っていることが多い
  • 全ての質を上げることがTQMの思想
    • お客様が如何に喜びを感じるか
    • 品質第一
      • 品質をきちんと上げれば、コストが減るはず
      • 最初にコストを下げると、品質が下がるコストが増える
    • 改善
    • 全員参加
    • 「何が嬉しいのか?」を常に問う
    • おかしなことの原因をパターン化して共有する
    • 未然防止
      • まだ出会ったことの無いものを防ぐ
    • 管理は技術である
    • 次工程はお客様
  • 品質管理が「まずはメトリクスを決めよう」という人は信用しなくて良い
  • プロセスを見るな、問題を見ろ

技術を導入する際の注意点や難しさにどう対応して行ったら良い?

薮田

  • TPI NEXTはプロセスだけではない
    • ISO/IEC 33063はプロセスのみだけど
  • TPIは訳がわからなかった
    • ゴルフのキーエリアをやってみたらようやく分かった
  • キーエリアを無手勝流でやってみると、えらく金と工数がかかる
  • 合わない所があったらカスタマイズする
    • カスタマイズした結果、それぞれの会社ごとで別々のプロセスになる
  • プロセス改善モデルと言われると、プロセスを定義して改善するようになっている。プロセスは決められているの?
    • プロセスは定義していない。
      • TPIのPをプロセスと訳しているのは良くないと思う
    • あくまでもテスト改善

増田

  • ISO/IEC 33063はプロセス改善モデル?
    • あくまでもアセスメントモデル(評価モデル)
    • ISO/IEC/IEEE 29119-2を用いている
  • ISO/IEC/IEEE 29119-2以外に追加しているものはあるか?(教育とか)
    • STATIC TEST PROSESSの部分とか…

池田

  • TMMiは?
    • こういったことをやりなさいという話だけはしているが、具体的な進め方は会社ごと
  • ISO/IEC 33063はISO/IEC/IEEE 29119のプロセスを守れと言っている。
    • つまり、ISO/IEC 33063とTPI NEXTは相容れないもの
  • 導入の中はTMMiとTPI NEXTは同じように進んでいく
  • 実際の仕事の進め方は直接的に書かれていない
  • TMMiはISO/IEC 33063よりはTPI NEXTに考え方が近い

アンケート

  • 実際のプロセス改善を行おうとしている
    • 5%ぐらい
  • プロセスに関する業務をしている
    • 半分
  • 自分だけでなんとかしようとしている
    • 少ない

会場内の質問・悩み

難しい

  • 余計なことを考えずに質問に1個1個応えるだけで良い
  • 1時間ぐらいでできる
  • チーム間での違いなどを議論すれば良い
  • それは、俺達困っているかも?と気付きが出るということか?
    • チーム間での違いから議論が湧き上がる。それでも1日ぐらい
    • チェックリストに付けて議論しようよ、と伝えたい

見積もりができない、説得できない

  • 反対派が多い、改善へのモチベーションがない
    • 困ってないんじゃない?ならいいじゃん
    • 押し付けが起きている?
  • 他プロセスへの改善にどう繋げるのか分からない

プロセス改善に至るまでに時間がかかる

  • プロセスを標準化したほうが良いよね?というコンセンサスを取るのが大切
    • それがないと改善のモチベーションが無いことに繋がる
  • 開発のプロセスから考えていって、最後の方にやってテストプロセス改善に繋がる

テストだけ改善しても打開できないことが多い

  • とんがっていてもみんなに同意してもらえない
    • こういうモデルがあるから…というのはだいたい否定される
  • 何に困っているのかまずは出し合ってみるのが大切
    • みんなで話せるようになって初めてモデルや手法の話が出てくる

忙しいし、どーせテストだし、みたいに思っている人にどうやって壇上に上げれば良いのか?

  • 困っていることを見つけてあげる
  • 困っている人だけ?想いが熱い人だけ?熱くない人も入れたほうが良いの?
    • 人格による。
  • 場を作るのがとても大切
  • 人間は環境を与えると勝手に動き始める

テストの改善とは

薮田

  • いつも会場からの質問のようなことに悩まされている
  • 抽象的な話を推進するときに、言葉で説明するのは無理
  • 実物を見せる以外に手は無い
  • まずは自分の頭の中だけでやってみる
  • ふふーんと思った上で、隣の人とかに広げていく

増田

  • 上司への説得の材料をもらいにこのセッションに来たと思う
  • それに答えられたか不安

西

  • 不良品の検査結果から分析して、良いやり方を標準化している
  • ソフトウェアは仕事のやり方さえすれば
  • 役に立たないテストケースの山を見て、どうしてこのテストケースがダメで、ということを分析すべき
  • 本当はテスト漏れを見るべき
  • テストの網羅できる実感が無いよねから始めると良い

  • 現場ではテストを知らない人が多いので、その人達への話をきっかけ

テストプロセス改善技術研究会

  • 現在、設立に向けて準備中