マネーフォワードでBug bashをやってみた
これは🎄Money Forward Advent Calendar 2019🎄15日目の記事です。
みなさん、こんにちは😀木村 直樹と申します。マネーフォワードでセキュリティエンジニアとしてプロダクト・セキュリティ🔐を担当しています。普段は、セキュアソフトウェア開発ライフサイクルの改善を主に行っています。これに興味がある方は、こちらも後ほどご覧ください。
そんなボクですが、その傍らで社内でBug bashを企画・主催して、半年で3回開催しました🎉マネーフォワードで行われたことがなかったBug bashを開催するため、イベントの企画・運営をしたことがなかったボクが何をやったか書いてみました。
Bug bashとは
一言で言えば「みんなで一斉に製品(プロダクト)の不具合(バグ)を叩き出そう」といった取り組みです。エンジニア職だけでなくデザイナー職やビジネス職も、さらには製品に直接関係しない人も一緒になって、普段の業務から離れて各々の観点でプロダクトを操作してバグを探します。
いわゆるアルファテストやドッグフーディングに近く、テスト手法としては主に探索的テストを使います。短期集中で行って効率よくバグを炙り出したいときに適していると思います。その反面、属人性が高く網羅性はありません。
Bug bashしようと思った背景
サイボウズ バグハンター合宿2019の模様をレポートした記事をたまたま目にし、「これはマネーフォワードでも見習って何らかの形で取り入れたほうが絶対にイイ。ってか、やってみたい!!🤩」と思ったことがきっかけです。
このサイボウズが行ったバグハンター合宿は、脆弱性を報告してくれる「バグハンター」の方々を招き、宿を借りて2日間の合宿形式で、脆弱性(セキュリティに関するバグ)をひたすら探すことに集中するというイベントでした。
セキュリティエンジニアとして「これはやりたい🔥」と思い、『思い立ったが吉日』とばかりにそれをSlackでつぶやいたところ、即座にCTOから「やりましょう！」という声があり、その勢いでイベントを検討することになりました😆
しかし、まったく同じイベントをマネーフォワードでやろうとしても、運営の知見もバグハンターとのコネクションもない現状では、うまく行かないと感じていました。
はたしてどういう形であれば実現できるか🤔を考えました。
まず、脆弱性に限らずとも良いのではと思いました。見つけたバグは製品の品質改善につながる貴重な情報になります。脆弱性だけにこだわらず、様々なバグを探すイベントにしたいと考えました。そして、プロダクト開発に携わらない従業員から「自社製品のことをそれほど知らない」という声を時折聞くことがありましたので、折角なら専門性の高いエンジニアに限らず多くの人が参加できるイベントにしたいとも思いました。
そうした考えから社内イベントとして従業員を集ってバグを探す企画を思いつきました。ググってみると、それは『Bug bash』と一般的には呼ばれ、いくつかの事例も見つかり、これはイケそう😎と感じました。
こうした流れを経て、他のメンバーとも議論を重ねて、Money Forward Bug bashと銘打ってイベントを企画することになりました🎉
「まずは実際にやってみないと、想定だけではいろいろわからないね」ということで、1ヶ月後にプレ開催し、それを踏まえて本格開催することにしました。
Bug bashの目的を考える
まずは、目的を明確にしました。
みんなで集まって楽しみながらワイワイ🥳とバグ探しに集中することで、『セキュリティやテストへの興味・関心を掘り起こす』『自社製品の理解を深める』『色々な役割の人がそれぞれの観点で探ることで未知のバグを発見する』などの機会とし、それを通じて、自社製品に関わる誰もがセキュリティを含めた品質を意識する文化を醸成する。
これはすんなり決まりました😄
まあ、それらしいことを色々と挙げていますが、何より楽しむこと(Fun)を重視したいと思いました。Funは、マネーフォワードのCultureのひとつです。
Bug bashのルールを決める
それまでボク自身もBug bashをやったことがありませんでしたが、事例などを拝見👀して、なんとなくどんなものなのかすぐにイメージ💭ができたので、ボクの独断でほぼ決めました😁
ルールとして、こんなことを定めました:
● 目的と目的ではないこと
● 参加資格
● バグの報告フロー
● 禁止事項
● 秘密情報の取り扱い
● バグの評価
● バグと認定しないもの
ルールに目的を含めると同時に、目的ではないこと、つまりやらないことを定めました。例えば、スループットやレイテンシーなどの処理性能の指摘です。処理性能は負荷テストでちゃんと検証すべきですので。
バグの評価については、イベントを盛り上げるために競技性を持たせたいと思いました。単純に報告数を競うだけではつまらないし、曖昧な採点では参加者が不満を感じてしまうし、どう評価すれば納得感が得られるか、いろいろと考えました。
最終的には、こんな感じで指標を設けて数値化して評価値を算出することにしました。
報告されたバグを運営委員が以下の各指標で評価し、各評価値を掛け合わせてバグの評価値を算出します。
バグの評価値 = a × b × c × d × e
a: 既知か未知か (既知: 0.0; 未知: 1.0)
b: 仕様かバグか (仕様: 0.0; バグ: 1.0)
c: 再現するか (再現しない: 0.0; 再現する: 1.0)
d: 影響する品質副特性 (セキュリティ: 1.2; その他機能性: 1.0)
e: 深刻度 0.0~10.0
バグ報告書のフォーマットを作る
参加者がバグを見つけたとしても、それについて何を報告するれば良いかが明確になっていないと報告が難しくなります。また、バグ報告に含まれる情報にばらつきがあると、報告内容を理解するのに時間がかかり、限られた時間で評価することが難しくなります。そこで、バグ報告の精度を保ち、報告されたバグを評価しやすくするためにバグ報告書のフォーマットを作りました。
バグ報告書には、次の項目を設けました。
● タイトル
● 要約
● 期待する挙動
● 影響
● 再現する環境 (OS / Webブラウザー)
● 再現手順
● 証跡
● 発生箇所 (ページタイトルやURL)
証跡は、スクリーンショットよりも動画で撮ることを推奨しました。そのほうがわかりやすいことが多いので。
参加登録・バグ報告の仕組みを作る
Bug bashをスムーズに運営するためにはシステム化は欠かせません。かと言って、その仕組みづくりに労力を掛けすぎたり複雑なシステムだったりしては、開催までに時間がかかり運営も手間がかかってしまします。
そこで採用したのが、GoogleフォームとZapierです。
参加登録とバグ報告、それと参加者アンケートは、Googleフォームで作って回答をGoogleスプレッドシートに連動させました。
さらに第2回からはZapierを使ってGoogleフォームおよびGoogleスプレッドシートで発生するイベントをトリガーに次のようなことを自動化しました。
● Googleカレンダーの予定に参加者を追加
● Slackのチャンネルに参加者を招待
● バグ報告と評価をSlackチャンネルに通知
Bug bashするプロダクトを決める
肝心のBug bashするプロダクトが決まらなければ、この企画は成立しません。
ただ、ここが苦労しました😅各プロダクトには取り組まなければならない優先するべきタスクがある中で、この企画に賛同してもらい、時間を割いてもらわなければならないからです。
そこで、各プロダクトの開発状況などをヒアリングし、それをもとにプロダクトの目星をつけて交渉していきます。最初は「Bug bash? 何それ?」とか「取り組みの良さは理解できるけど...」とかという反応を示すプロダクトの担当に対して、Bug bashのメリットを丁寧に伝えて口説き落としていきました😎
第1回『Bug bash Hour #0』の開催
プレ開催は『Bug bash Hour #0』と題して「ランチを食べながら2時間くらいポチポチしてバグを探してみよう」と有志を募り、エンジニア中心にデザイナー1名を含めた計12名の参加者と運営はバグ判定員のプロダクト担当1名と参加者サポート1名を含めた3名で行いました。
結果は:
● 報告されたバグ: 21件 🎉
● 新たなバグとして認定された報告: 10件 🎊
初めての取り組みでいろいろ不安はありましたが、課題も明らかになり、まずまずの結果でした🙂ちょっと残念だったのは、思っていたよりもワイワイと盛り上がりらずに終わった感じがありました。
プレ開催からの改善
実際にBug bashしてわかったことや参加者からのフィードバックから、もっと盛り上がるように次のようなことを改善しました。
● 事前にレクチャーする
● 賞品を用意する
● バグ報告・評価の状況をわかりやすくする
● 振り返りの時間を設ける
事前にレクチャーする
ソフトウェアテストの経験のない人にとっては、「さあバグを見つけて🤓」と言われても何をしたら良いのか皆目検討が付かず😶、Bug bashを楽しむことができなかったようでした😵
そこで、参加希望者にバグの見つけ方を教える👨🏫機会を開催前に設けるようにしました。「Bug bashって何?」という人にもどんなイベントなのかを参加する前に知ってもらいう良い機会にもなりました👍
事前レクチャーについては🎄Money Forward Advent Calendar 2019🎄17日目でも取り上げるので、そちらもぜひご覧ください。
賞品を用意する
プレ開催でも賞を設けて表彰したのですが、やはり賞品🏆があったほうが盛り上がります。金券やステッカーなど色々と検討した結果、名誉の証として形に残るものを贈りたいと考え、最終的にはマネーフォワードらしいオリジナルの賞状カードを作成することにしました。作成にあたっては、デザイナーに協力してもらい、とても素敵なものが出来上がりました✨
バグ報告・評価の状況をわかりやすくする
バグの報告とその評価はGoogleスプレッドシートで誰でも閲覧できるようにしていましたが、もっとわかりやすくするためにバグ報告と評価結果をSlackのチャンネルに通知するようにしました。
バグの評価結果は、こんな感じでSlackで通知されます✌️
振り返りの時間を設ける
プレ開催では時間の都合上割愛しましたが、参加者みんなで報告したバグを振り返って知見を共有することも大事です。「このバグはどうやって見つけたか」とか色々なテスト観点を知る良い機会になります。
さらに盛り上がるように『Bug bash🐛の後はBeer bash🍻』として、軽食を用意して参加者同士で交流できる時間も設けました。
...っと、ここまででかなり話が長くなりました🙇♂️が、もう少し続きますのでお付き合いください🙏
第2回『Bug bash Day 2019 Summer』の開催
プレ開催を経て、その1ヶ月半後、満を持しての本格開催は『Bug bash Day 2019 Summer』と題して、この日はBug bashに没頭しよう😆と半日の長丁場にしました。
タイムスケジュールは、こんな感じです。
13:00~13:30 | オープニング (運営からの説明)
13:30~15:00 | バグバッシュ🐛 session 1
15:00~15:30 | 中間結果発表 & 小休止
15:30~17:00 | バグバッシュ🐛 session 2
17:00~17:30 | 結果集計 & ビアバッシュ準備
17:30~17:40 | ビアバッシュ🍻スタート
17:45~18:00 | 最終結果発表 🏆表彰式
18:30~19:00 | バグ報告を肴に振り返り
19:30~19:40 | クロージング
19:40~20:00 | 撤収作業 & 解散
ただ、半日拘束となると敷居が高くなってしまうので、途中参加も途中離脱もOK🙆♂️としました。
この回は、バグを評価するプロダクト担当が福岡拠点にいたため、GoogleハングアウトMeetを使って遠隔で参加してもらいました。うまくコミュニケーションできるか不安でしたが、あまり支障なく運営できました。
参加者は、アプリケーションエンジニアを始め、本業とするQAエンジニアもいれば、カスタマーサポート担当もいたり、さらに人事担当なども参加したりと、バラエティに富んでいました。そのおかげで様々な観点からのバグが報告されました。
結果は:
● 参加者の総勢: 16名
● 報告されたバグ: 72件
● 新たなバグとして認定された報告: 35件
途中、検証環境が不安定になるなど多々トラブルがありました💦が、多くのバグが報告され、改善の甲斐もあり前回を上回る盛り上がりを見せました🙌参加アンケートの回答をみても「とても有意義だった」「また参加したい」「同僚にも勧めたい」など、とても高評価でした。
ちなみに、Beer bash🍻で軽食として用意したとんかつ まい泉のミニバーガー🍔は、美味しい、食べやすい、持ち帰りやすい(=残飯が出ない)、と大好評でした😋
第3回『Bug bash Day 2019 Fall』の開催
『Bug bash Day 2019 Summer』の成功に味を占めて、その開催終了直後から第3回の企画が持ち上がりました。
ただ、やはり苦労したのがプロダクト選定と参加者集めで、特に参加者集めが大変でした。開催告知しても前回の反響とは裏腹になかなか応募がこず、色々な方法で参加を募った結果、最終的には前回と同じぐらいの人数が集まってくれました。この点はまだまだ課題があるところです。
この回は京都拠点が開発を担当するプロダクトでしたが、東京に駆けつけてくれました。一堂に会したほうがやはり盛り上がります🥳
結果は:
● 参加者総勢: 18名
● 報告されたバグ: 88件
● 新たなバグと認定された報告: 21件
前回の反省を活かし、検証環境が不安定になるなどのトラブルもなく、バグ報告は前回を上回り、会場の盛り上がりも前回以上でした😁
Bug bashをやってみて思うこと
思い付きから始まったBug bashを実際にやってみて思うことは、思いに耳を傾けて目的に賛同してくれる多くの人がいて、こういった取り組みに寛容な企業文化があってこそ成立するのだなということです。
引き受けてくれるプロダクト担当と参加者がいることも当然ですが、企画する上で、色々なアイデアを一緒に考えてくれたり、イベント運営のノウハウを教えてくれたり、賞品をデザインして具現化してくれたり、社内報を書いてくれたり、色々な人の協力があってできたことで、ボク一人では到底無理でした。
Bug bashはまだ終わらない
目標は「すべてのプロダクトをBug bashする🤘」ことです。なので、まだまだ終わりません。それに『自社製品に関わる誰もがセキュリティを含めた品質を意識する文化を醸成する』ため、企画当初からBug bashは継続して定期的に開催することを前提に考えてきました。イベントのタイトルを「Money Forward Bug bash Day 2019 Summer」などとしているのもその意志の表れです💪
もうすでに次回開催に向けて動き出しています。回数を重ねて少しずつ認知度が高まり「Bug bashしてほしい」と名乗りを上げるプロダクトも出てきました😆良い流れができてきています。
これを読んで「Bug bashしたい」と思ってもらえれば嬉しいです😃
------------
マネーフォワードでは、セキュリティエンジニアを募集しています!!
/assets/images/4395430/original/17168106-0bef-4ba8-8d31-ff384fa553ea?1576664149)
この記事が気に入ったらサポートをしてみませんか？