Tokyo Atlassian User Group #27に参加してきた

2018年3月20日に行われた 第27回Tokyo Atlassian User Groupに参加した際の感想です。

当日の様子と登壇資料は、Togetter でまとめられていました。

アジャイルな開発の実現のためにAtlassianができること

発表内容はAgile Japanのサテライト開催で登壇されたものをAtlassianユーザー向けにしたそうです。

ソフトウェア開発を行う際、要件定義や設計等の各工程にふさわしいExcelRedmine、git、Jenkinsなど様々なツールを利用していると思います。

ツールを利用することで開発が効率化されるはずですが、実際は楽にならないことがあります。
なぜなら、これらのツールを一つ一つ理解するのが大変で、ツールによってはスペシャリストになると職に困らないシロモノもあり、さらにそのツール間の連携が必要となればより大変です。

Atlassianはどうなのか?

Jira Softwareを中心とした各種Atlassian製品を利用することで情報の整理と、プロセスとツールの紐づけ、ナビゲートをしてくれるそうです。

例えば、ConfluenceからJiraチケットの作成やJiraでBitbucketのbranchの作成ができます。

また、全Atlassian製品を利用する必要はなく、BitbucketをGitやGithubに、BambooをJenkinsに変更することができます。

Atlassian Community でツールでわからないことを聞くと世界中のユーザーだけではなく、Atlassianのエンジニアも積極的に助けてくれます。

Atlassian製品を使っている会社の実績として、10年間フリーキャッシュフローで企業活動ができているAtlassianという企業(自社じゃん!)があるだけでなく、フォーチューン誌が公開しているFortune 500に連なる企業の58%がAtlassianユーザーで、そのうちFortune 100に連なる企業の80%がAtlassianユーザーだそうです。

つまり、Atlassian製品を使えば企業の成長、成功間違いなし!(うおおすげえ)

JIRA Software + Atlassian製品 + 好きなツール + 人 = 成功が約束...されるのではないだろうか。

という話でした。

つまり、ツールを使うという作業を頑張るのではなく、ツールは楽に業務を頑張ろうよ!ということですね。

異業種に転職したら雲の上の一般ユーザーだった件

あらすじ

オンプレの管理者だったお母さんは、異世界転生(異業種転職)した結果、クラウド一般ユーザーになってしまったため管理者だったころの力がうまく発揮できない。
異世界転生って俺つえーする物語じゃなかったのか?
語彙力がなさ過ぎて小説の裏表紙に書いてあるようなことが書けない

発表資料がとても好きな感じでした。
読みやすい埋め込みフォント、ドラクエっぽいステータス表には小ネタが...rm -fr * うわあああぁぁぁ

発表内容

登壇者の会社は、会社の行動理念として「オープンを当たり前に」という感じだそうで、Confluecneの権限も最低限な制御しかしていないそうです。
正直、カオスになりそうで決断できないと感じましたが、実際はカオスなんて訪れないのでしょうか。

オンプレと違い、システム運用を考える必要性がない!バックアップも安心!しかもリテラシーが高いメンバーばかりなので使い方も大丈夫だ!と感じたそうでうs。

ただ、あまり凝った使い方はしていなかったようなので、転生前に使っていた魔法(Tipマクロやページレイアウト設定等の様々なマクロ)をコツコツと披露し、管理者になったそうです。

ただ、管理者といってもCloud版なのでソフトウェアとしての管理者です。

メンバーがConfluenceでやりたいことだった定期開催ページの自動生成を実現させるなどが主な活動だそうです。

Cloud版は結構アグレッシブで突然のテーマ変更、ロゴ変更は当たり前。しかも、困ったときはサポートに頼るしかありません。
どうやら日本法人への問い合わせよりグローバルサポートへ問い合わせたほうがレスポンスが早いそうです。
私個人は日本法人のサポートしか使ったことはありませんが、それでも1営業日内にレスポンスがあったのでこれ以上の速度を求めても英語が苦手なので享受できないかも。

発表はCloud版持ち上げで終わると思いきや...まさかの...「エンジニアはesaに飛びついた」END!
エンジニアは様々なご不満があったそうです。資料に載っていたエンジニアの要望は「わかる」「そだねー」と超共感できる内容ですし。

Cloud版もっと良くなるといいな...完

アジリティプロジェクトの紹介

Jiraの新しい機能であるアジリティプロジェクトの紹介でした。

Jiraは強力ですが、とても複雑です。
実際、Atlassianは複雑すぎるというフィードバックを数多く受けているそうです。

デザインの話

新しいJiraはデザインを現代的に、クリーンに変更したそうです。 ワイドスクリーンでも綺麗に表示されるそうです。
ごちゃごちゃしていた要素も関連する要素を近くに配置するなど改善したそうです。

Jiraは素晴らしい!...正しくセットアップできたら

私は聞いたことがなく、実際に作業もしたことがないのですが有名な話だそうです。

当然、分厚いマニュアルとともに製品をリリースしたいエンジニアがいるはずもないので、セットアップを簡単にできるようにしたそうです。

1画面で様々なことを簡単な操作でできるようにしているそうです。
デモで見せていただいたのですが、TodoとBacklogの境界線がBacklogリストで、その境界線を上下することでTodoへの出し入れが簡単、かつ描画が重たくなくスムーズにできていました。

現在進行形な機能追加

前登壇で指摘されたように突然の変化があるかもしれませんが、Feature flagが用意されているのでいつでもON/OFFが可能なので安心して利用できるとのことでした。

新機能は、SHIP IT と呼ばれる活動で様々なアイデアを実現しているそうで、Q&A時間に伝えられた要望も次のSHIP ITで実現してみるとおっしゃっていました。

まだまだ始まったばかりなので試してフィードバックしてね!というお話でした。

所感

今のチームはJiraを使っていないのでさておき、esaかぁ...ちょっと使ってみようかな。今のチームにConfluence勧めたの自分なんですがね。

と、Atlassianのユーザーグループ会に参加して他のツールに興味を持ってしまったのでした。

テストプロセスの改善 JaSST Tokyo 2018

JaSST Tokyo 2018のテストプロセス改善系セッションについての感想です。
受講したセッション

  • B2 はじめてみようテストプロセス改善
  • E4 ボトムアップによるテストプロセス改善 ~TPI NEXTを体験してみよう~

テストプロセス改善モデル概要について

テストプロセス改善技術ガイドがASTERから公開されるそうです。
関東が梅雨入りするまでには公開する予定らしいです。

詳細はガイド待ちです(非会員でも閲覧できるのかな?)

改善モデルは、段階モデルと連続モデルに分類できるそうです。

段階モデル 連続モデル
概要 組織のプロセス成熟度合い毎に改善すべきエリア・ゴールがある 最初から全エリアを対象にしていて、各エリア毎に成熟度合いが設定されている
メリット 着手するエリア・順序が明確 改善対象を柔軟に設定できる
デメリット 改善順序が組織にフィットしているか不明 最適な順序を考える必要がある
プロセス例 TMMi TPI NEXT

ISO33063も連続モデルだったかな?

各テストプロセス改善モデルについて

ざっくり概要解説がありました。

TMMiは、CMMiのテストプロセス版で補完する形になっているそうです。

ISO33063は、ISO33020のプロセス能力水準軸とISO29119-2のプロセス軸をマトリクスにした形式で改善していくため、ISO33063を理解しようと思うと、33020と29119-2を理解する必要があるそうです。

TPI NEXTは改善エリアと成熟度のマトリクス形式で、ボトムアップで改善していくモデルになっているそうです。

各モデルは、共通の改善エリアと固有の改善エリアがあるそうです。
例えば、TMMiとISO33063はレビューも改善対象ですがTPI NEXTにはありません。しかしTPI NEXTはプロセス以外が対象になっているなどの違いがあります。

プロセス改善活動の勘所

セッションの概要は以下の通りです。

なぜ、テストプロセスの改善が必要なのでしょうか?
それはテスト工程での不具合を抑制するため、テスト観点でプロダクトを作る必要があるからです。

しかし課題対策をいきなり始めても品質はなかなか上がらず、負のスパイラルに陥ります。

プロセス改善にもスキルが必要ということです。

改善のステップは3つ

  1. アセスメント
  2. 計画
  3. 実行(コントロール・フィードバック)

アセスメントの勘所

  • 着手が遅い
    → 導入で悩まずにとりあえず試すことが必要です
  • 認識合わせを怠る
    → 一人で実施せずに周囲の意見を聞くことです
  • 1回きりで終わってしまう
    → 何度も実施しましょう

主導する立場にアサインされたら一人で考えこんだり一度の実施で終わってしまうことなどはよくありがちですね。

プロセス改善計画の勘所

  • 要求・目的・ゴールが誤っている
    → 関係者の要求を確認しましょう
  • 関係者との調整怠る
    ステークホルダーには事前に話を通しておきましょう
  • 実施を意識していない計画
    → 無理のない計画と代替手段の検討も行っておきましょう

当たり前のことですね。

実行の勘所

  • 作業が停滞してしまう
    → 定期的な確認を行いましょう

  • 状況が変わって改善がうまくいかない
    → 見直しを検討しましょう

  • 改善完了で満足してしまう
    → さらなる改善をすべきです

こちらも当たり前のことですね。

所感

勘所はテストプロセスの改善に関係なく業務で必要な部分だと思います。テストプロセス改善としての勘所という感じの内容はなかったと思います。

TPI NEXT

テストプロセス改善研究会の方が翻訳してくださった日本語版アセスメントツールがあるので、実践する方は SOGETI社 よりダウンロードしてください。
使い方は、質問シートにY/Nで回答すると、マトリクス図とグラフが現状を判定してくれます。

成熟度は3段階あり、コントロールレベルが関与しているか、効率化レベルが貢献しているか、最適化レベルが開発活動全体の重要部分になっているかです。 質問が「テスト担当者は~」という感じなのでテスト担当者が関与、貢献、重要ポイントになっているかということだと思います。

ワークショップの内容は、例題をもとに関与度エリアの成熟度を検討するというものでした。

ここで、A2セッションのアセスメントの勘所が生きてきます。

例題が「テストマネージャ」を対象にしていたのに対し、TPI NEXTの質問は「テスト担当者は」となっています。マネージャは担当者か?担当者だという意見とマネジメントの立場だから担当者が別にいるはずでそいつが関与していないなどと割れます。 またプロジェクト計画への関与においても、がっつり関与してこそ「関与している」と評価すべきなのか、ほんの一部分でも関与していれば「関与している」と評価すべきなのか意見が分かれました。

所感

チームを評価する点については、質問に答えるだけでマトリクス図とグラフが判定してくれるので簡単に始められると思います。

また、販売ブースにて本が割引で販売されていたので買いました。自チームで一度やってみたいと思います。

テストの完全自動化だって?JaSST Tokyo 2018 Googleの話を受けて

JaSST Tokyo 2018の基調講演とクロージングパネルでのJohn Miccoさんの話を聞いて感じたことをまとめています。

完全自動化の文化について

2006年(2007年?)に方針を大転換したそうで、トイレでテストのことを考えるようにしたり、私も度々参考にさせていただいている Google Testing Blog を始めたそうです。

Googleのような超大企業でもそのような大転換が可能なのか、と率直に感心しました。
国内にも大企業があるわけですし、別セッションで柴田さんが組み込み系(という分野かな?あれは)でテスト自動化に取り組んでいたというので、大企業だからできるとかWeb系だからできるとかは関係なさそうです。

Agile開発でも似たような話を聞きますが、NASAや戦闘機開発だってAgileらしいけどなにか?っていうやつです。

「やれば出来る、飛べば飛べる」と某アニメのヒロインも言っていますが、ぐだぐだ言ってないでまずはやれよってことですね。

チーム構成について

1チーム当たり8人~10人で、そのうちSETI(Software Engineer, Tools & Infrastructure)が1人~2人いるそうです。

Googleには、以前SET(Software Engineer in Test)がいたのですが、役割の変化などに伴ってSETIと変更しています。

SETIの活動ついては、Google Testing Blogの SETIの話が載っているこちらSETの話がのっているこちら がとても参考になるかと思います。

現状について

Googleでは、420万ほどのテストが存在して、1日1億5千万テストケース実行されていて(150million test execution/dayだからあってますよね?)、1テストケースあたり35回実行されているらしいです。

そして、これらがすべて自動テストであり、手動テスト率が驚異の0%!ただし、UX系のテストは手動だそうです。
UIのテストなどは自動化できるが、UXはさすがにまだ人手とのことで、人の感覚などが関係するUXテストがAIによってテスト可能で人の仕事が無くなるといった日はまだ到来していません。

自動テストですが、毎テストごとに420万テストケースを実行しているわけではなく、全テストケースを実行するのは一定の間隔で、普段は修正に対して依存があるテストだけを実行しているそうです。

基調講演とは別のセッションで、20分程度テストに時間がかかっているとおっしゃっていましたね。

一定間隔で実施している全テストをMilestone Testと呼ぶそうです。

自分が参加しているプロジェクトでは、毎回全テストケース(UT)を実行しているのでそこそこ時間がかかっています。
フレームワーク作りなども関係する部分なので突然明日から変更します!と取り組めそうにありませんが、徐々に改善していきたいところです。

どうやって全テストの実行を減らしていったのか

至極当たり前の話です。

  1. commitとテストの間隔を縮める
  2. テストとcommitの分析を行う
  3. 分析結果をもとにテストの間隔を広げる

最初は、高い頻度で全テストケースの実行を行っていたのに対し、テスト結果とコード修正の関係を分析してだんだんと減らしていく、ただそれだけの話です。

文字にすると簡単そうですが、実行するには分析力を要しますね。

Flakyなテストとの闘い

自動テストにはつきものな不安定なテストにどう立ち向かうか。

無視することはいけないがある程度許容する必要性があるそうです。
Submit(GitでいうCommitやPushのことかな?)し続けるコストとのバランスが大事なようです。

原因分析を行い、インフラなのかプロダクトコードなのかを切り分けて無駄な時間を過ごさないようにしているようです。
クロージングパネルで、テストのExceptionを適切に出すことでインフラ、コードどちらが起因なのかを判断できるようにするなどと仰っていた気がします。

前談のテスト間隔とも関係しますが、commitというかPull Requestのサイズをかなり小さくする必要がありますね。

完全自動化への道のり

Googleでは、このように完全自動化していったという話が直接あったわけではないのですが、ポイントになるところは話していましたね。

新規サービスも最初から自動テストにするようで、はGoogleのサービス形態が人命にかかわるものじゃないし、イテレーションの高速化に寄与することにもなるから、最初から完全自動化なのだそうです。

テストが書きにくいレガシーコードは、改修時にテストできる状態にして、必ずテストコードも書いているということでした。

あと個人的に一番大事なことと感じた点、小さな変更が大事であり、小さい変更であってもテストコードも含めてsubmitさせること。
この程度の変更ならという甘えは危険ですね。

所感

システムテストも自動化したい!と自分のプロジェクトでも話をしていますがなかなか実現できない自動化。

完全自動化を目指すということではなく、より適切な時期にマーケット投入するためにどうするのか。そのために継続的なテストを自動化して手動テストは効果的なところだけに行いたい。

通過点として、アプローチはいくつかあると思います。開発チームによる単体テストと専門的なテストチームによる結合、総合テストの実施という役割分担もその一つです。
しかし、あくまで通過点で最終的にはGoogleのような一体となったチームで頭から終わりまで立ち向かいたいところです。

自分の活動を考え直す講演だったと感じていて、開発、SET、QA(テスト)が一体となったチーム作りのコーチング(コンサルティング?)ができる人財になりたいところ。
Scrum Master、Product Owner、他、自分の役割が何なのかは関係なく、チーム一丸で取り組むために主導できる立場でありたい...