チームスピリットデベロッパーブログ

チームスピリット開発者のブログ

QAエンジニア養成!社内テスト技法勉強会レポート

こんにちは!
2020年は定期的にブログを書きたいQAチームのリーダーをしている生井(id:riririusei99)です。
寒い日が続いていますね、ちなみに自分の中では20度以下はすべて寒い日です。
さて、最近のQAチームで取り組んでいることについてブログを書きます。

はじめに、JSTQB認定 テスト技術者資格について

みなさんは「JSTQB認定 テスト技術者資格」というのをご存知でしょうか。
この資格はソフトウェアテストに関する有名な資格の一つです。
また、チームスピリットの開発チームにおける品質保証プロセスは多くの場面でJSTQBの知識体系を参考にしています。

www.istqb.org

今月2月8日にFoundation Level および Advanced Level Test Analyst 試験がありました。
QAチームでもAL テストアナリスト資格の取得を目指すメンバーが複数いたので、チームとして何ができるか考えたところ、 社内でテスト技法の勉強会を開催することが良さそうだと考えたので実際に開催してみました。

テスト技法勉強会を開催する

個人が資格取得する際のメリットは、合格するために勉強した内容が団体に認定されることだと思いますが、
QAチームのリーダーとして嬉しいことは、勉強した内容を実務に活かしてもらうことだと考えています。

なので今回は「業務に活かせる」と「合格の助けになる」どちらも満たす内容として、 「テスト技法を手になじませる」ということを主眼に置いた勉強会を開催することにしました。

実際の業務の場合、どのテスト技法を当て込むか考える必要があったり、複数のテスト技法を組み合わせてテストケースに落とし込む場合が多く、初めてのメンバーに覚えてもらう際にはケーススタディが複雑になりがちです。

今回は市販の書籍や、過去問セミナーで取り扱った問題を使うことで、テスト技法自体をシンプルに取り扱ったり、考え方を理解してからテスト技法を当てはめるような構成にしました。
まずは簡単な問題を一緒に解いて考え方を理解し、実際に問題を解くことで理解を深めるようにしました。

実際の様子

机を固めてみんなで問題をときます。
教えるにあたって、リーダーは取り扱う問題を先に解いておきます。
テスト技法の概要を問題を解きながら説明するので、押さえておくべきポイントを考えたりしたので自分自身も知識の棚卸しになりました。

f:id:riririusei99:20200214184248j:plain
勉強会の様子

簡単な問題を解きながら解説した後に、同じ技法の別の問題をメンバーに解いてもらいます。
座学だけにならないように手を動かしてもらう時間を多めに取りました。

f:id:riririusei99:20200214184411j:plain
真剣に問題を解いている様子

問題を解き終わったあとは、解いたメンバーに自分の回答を発表してもらいます。
正解かどうかよりも、どのように考えたかを大事にしました。
その上で、技法を当て込むポイントを付け足してフォローします。

f:id:riririusei99:20200214184500j:plain
解説中。。。

おわりに

写真を付けて説明するとそれっぽくなりますね!
今回の写真はチームのバックエンドエンジニアに撮影いただきました!圧倒的感謝!

実際の業務だとテスト技法を当て込むにも複雑になりがちなので、基本を改めて抑えるには良い機会になったと思います。
他にもQAチームではチーム力をアップするために様々なことに取り組んでいるので、別の機会に紹介できたらなと思います。

受験したメンバーが合格していたら一番嬉しいですが、こういった活動をきっかけに業務に活かしてもらえるだけでもプラスになるのでこういう活動は続けていけたらなと思います。

おわり

Japan Dreamin'2020 参加レポート

こんにちは!サービス開発チームの松田 (id:a-matsuda)です。
今年1月25日、東京・渋谷のAbema Towersにて「Japan Dreamin'2020」が行われましたのでレポートします。 

Japan Dreamin'とは

Japan Dreamin'は、Salesforceのコミュニティカンファレンスで、ビジネスユーザ・システム管理者・開発者・アーキテクト・マーケター・Salesforce 社員・Salesforce に関わる全ての人が組織や役割を超えて繋がることのできるイベントです。国内外の著名スピーカーによるセッションの他、ハンズオンや参加者同士が楽しめるアクティビティが行われます。

今回チームスピリットは、ランチセッションに協賛。スポンサーセッション枠でシニアプロダクトマネージャー の小泉剛が、またその他セッション枠でエンジニアリングチームリーダーの倉谷彰、バックエンドエンジニアの畑本貴史がプレゼンテーションを行いました。

www.japandreamin.com

 

Dreamin'2020 の会場へ Go

渋谷駅から渋谷のディープなエリアを歩いて7〜8分の場所にある Abema Towers がDreamin'2020 の会場です。

会場に到着すると、たくさんチョコレートがお出迎えしてくれました。カラフルで見ているだけで何故かワクワクするチョコレート達!おひとり2個までです。笑

f:id:teamspiritinc:20200130232955p:plain

Salesforceに関わる人が集結!

今年は、なんと320名近くが参加申込!昨年の2.5倍以上の人数です。セッションルームを覗くと、すでにたくさんの人が集まり、セッションに聞き入っていました。

f:id:teamspiritinc:20200130230157p:plain 

スポンサーブース

スポンサーブースには、プロダクトや採用に関する資料を置かせていだきました。弊社のエンジニアがブースに立って対応してくれました!

f:id:teamspiritinc:20200130233120p:plain

AppExchangeプロダクト開発を続けて見えてきたプラクティス by Akira Kuratani 

エンジニアリングチームのリーダーでSalesforce MVPでもある倉谷より、Salesforceで ISV/OEMアプリケーションを開発する上で気をつけるべきポイント、たどり着いた解決策について紹介しました。

AppExchange開発で大切なのは「アップグレード可能」であること。多くのユーザにAppExchangeアプリケーションを提供し、継続的に機能追加していく場合には、ユーザに最新バージョンを使ってもらうためにアップグレードの手間を最小化する必要がある。成長するプロダクトの基本戦略「アップグレード可能であること」を判断基準に、宣言的開発とコード開発どちらの開発スタイルがいいか、Salesforce標準画面は使うべきか、選択リストをどう実装するか、レポートをどう提供するかについて話しました。

プレゼン最後のメッセージは、基本戦略を判断基準にして、ISVガイドを熟読すれば自ずとどうすればいいかみえてくるとのこと。長きに渡りAppExchange開発に携わってきた倉谷だからこその説得力がある発表になりました。

f:id:teamspiritinc:20200130233413p:plain

www.slideshare.net

プロダクトマネージャーとして成長するのに必要なスキルとマインドセット by Tsuyoshi Koizumi

スポンサーセッションは、弊社の新サービス「TeamSprit WSP」のプロダクトマネージャーである小泉が担当しました。プロダクトマネジメントの中で重要な視点である「限られた情報から課題を発見して、特定した課題をどうやってソリューションに落とすか?」について、AppExchange製品に関する知見をまじえてお話ししました。

発表内容は先日の「Product Management Night Tokyo at TeamSpirit」のプレゼンテーションをブラッシュアップしたもの。詳細はこちらをチェックしてみてください。

プレゼンテーション最後の質問タイムでは「プロダクトマネジメントで大変なところはどこ?」「エンジニアからプロダクトマネージャーになりたい人へのアドバイスは?」「ぶっちゃけ給与って?」など率直な問いが投げられました。なんと質問をしてくださった方全員に、弊社社長である荻島浩司の初著書「サブスクリプションシフト DX時代の最強のビジネス戦略」をプレゼント!

f:id:teamspiritinc:20200130233542p:plain

発表資料はこちら

LEX Mobileから紐解くSalesforceモバイル史 by Takashi Hatamoto

畑本貴史は、Salesforceへの深い知識で社内でも人気者のバックエンドエンジニア。 Lightning Champion*1としても活躍しています。今回は、最近の主要アップデートであるLightning Experience Mobile(以下、LEX Mobile)を題材に、温故知新の精神で開発史を学ぶことで、Lightning Experience(以下、LEX)の意義や方向性を理解しようと試みました。

Salesforceのモバイル対応は、ガラケー主流のモバイル初期の時代、iPhone登場後のChatter時代、環境統合のSalesforce1時代、そしてSPAを主軸としたユーザ体験重視のLEX時代、そしてLEX Mobile時代と変遷していきます。iModeブラウザ対応のアプリの存在など、びっくりするような歴史も!歴史を紐解くことで、なぜいまLEX Mobileなのか理解が深まりました。そして今後モバイル向け機能はどうなっていくのかを畑本の視点で予測。歴史から紐解く未来という見方が面白かったです。

LEXで困ったことがあったら、Trailblazer CommunityやLightning Championに遠慮なく聞いてみましょう!

f:id:teamspiritinc:20200130233924p:plain

www.slideshare.net

 

まとめ

土曜日にも関わらず、たくさんの人が参加した Dreamin'2020。Salesforceに関わる人が増えていることや、Salesforce界隈のトレンドを肌で感じることができました。来年はどれくらいの規模のイベントになるのでしょうか。とても楽しみですね!

開発エンジニア&プロダクトマネージャー募集

チームスピリットでは、100億円のビジネスを共に作る開発エンジニアやプロダクトマネージャーを募集しています。AppExchangeで成長するプロダクトを作ってみたい方、仕事の中で英語を覚えていきたい方、B2B SaaSにご興味のある方、ぜひご連絡くださいね。直接メッセージでも、下記の応募フォームからでも構いません!

エンジニア募集

 

 

*1:Lightning Experienceの導入やアプリケーション開発における知見を惜しみなく活かした、先駆者(Trailblazer)として活躍しているメンバー

Product Management Night Tokyo at TeamSpirit 参加レポート

こんにちは!サービス開発チームの松田 (id:a-matsuda)です。
今年1月15日、チームスピリットセミナールームにて、Product Management Festival(PMF)主催のMeetupイベント「Product Management Night Tokyo at TeamSpirit」が行われましたのでレポートします!

Product Management Festival(PMF)とは

Product Management Festival(PMF)は、スイスのチューリッヒに本部があり、欧米やアジアを中心にプロダクトマネジメントに関する最新情報やイノベーション、実践を通じた成功や失敗事例の共有を通じて、プロダクトマネジメントの発展を支援する非営利組織です。今回、PMFが日本で初めてMeetupイベントを開催するにあたり、チームスピリットはイベント企画や会場提供等で協力しました。

productmanagementfestival.com

今回の「PM Night Tokyo」は・・・

記念すべき第1回目は、「NewsPicks」のプロダクトオーナーとして活躍する大日田貴司氏と、B2B SaaS「TeamSpirit」のシニアプロダクトマネージャーとして奮闘する小泉剛氏が、日々向き合っているプロダクトマネジメントについて語りました。

募集枠50名に対して100名を超える応募!

connpassで参加募集を行ったのですが、なんと募集枠50名に対して100名を超える応募をいただきました!プロダクトマネジメントや、グローバルトレンドへの興味関心の高さが伺えますね。当日は50名弱のみなさんが、セミナールームに集合しました。

PMF Ambassador Vegaさんよりご挨拶

さあ「PM Night Tokyo」が始まります!

まず最初に、PMF Amvassador Vegaさんより、PMFの成り立ちや取り組みについて紹介がありました。PMFでは、プロダクトマネジメントのトレンドを発信すべく、様々なデータをまとめてレポートされているそうです。日本にいると日本国内のトレンドばかりに目が行きがちですが、グローバルに戦っていくプロダクトを作っているのであれば、プロダクトマネジメントのトレンドもグローバルを追いかけていきたいですね。 

「Build to Think」by Takashi Ohida, Head of Product Design, NewsPicks

大日田さんは、スタートアップから大手企業において様々なプロダクト開発に携わってきた百戦錬磨のプロダクトマネージャー 。これまで、グリー株式会社でSNS事業を率い、株式会社リクルートホールディングスでは複数の新規事業の立ち上げや海外投資案件に従事。株式会社XIMERAにて取締役CTO、株式会社Schooでプロダクトオーナー及び子会社取締役を経て、2018年1月より株式会社ニューズピックスに参画し、プロダクトオーナーとして活躍されています。

f:id:teamspiritinc:20200129161616p:plain

今回は「Build to Think プロダクトデザインの方法論」と題して、プロダクトデザインの重要性と方法論についてお話しされました。

プロダクトデザインの重要性

プロダクトデザインは、何を作るのかを決めること。何を作るのかは未来のどの場所に行きたいかを考えること。何をしても必ずどこかにたどり着くが、いい場所も悪い場所もある。プロダクトマネジメントの有無で、たどり着く場所が全然違ってくるというお話です。

そして、プロダクトデザインがなぜ重要かというと、実装(大きな投資)前に成功可能性を上げるための取り組みだから。成功可能性の高いものに投資するために大事なフェーズがプロダクトデザイン、ということですね。

プロダクトデザインの方法論

正解のないプロダクトデザイン。未知のものを考えるには仮説検証のサイクルが必要で、いかに仮説の精度を上げるかがプロダクトの成功を左右する。

大日田さんは、仮説の精度を高めるために、思考のための具現化(Build to think)を行うことを大切にしているそう。「NewsPicks」のアプリ開発において、設計は「論理設計→体験設計→仕様設計→実装」というプロセスで進めており、特に体験設計のフェーズでは、検証に必要な画面は完成品レベルで作り込み、確度の高い仮説検証を行っているとのこと。

「NewsPicks ACADEMIA」での仮説検証の事例を紹介いただくことで、完成品に近い具現化をして検証していることがよくわかりました。

f:id:teamspiritinc:20200129143123p:plain

プロダクトマネージャーとして成長するのに必要なスキルとマインドセット by Tsuyoshi Koizumi, Senior Product Manager, TeamSpirit

小泉は、チームスピリットのシニアプロダクトマネージャー。7年以上の経験を持つ、BtoB SaaS のプロダクトマネージャーで、ソフトウェアエンジニア出身です。アドバンテッジ リスクマネジメント社にて、ユーザー数200万人を超えるプロダクトへ育てることに成功。現在は、チームスピリット社にてシニアプロダクトマネージャーとして、中堅・大規模企業向けの勤怠・就業、工数・プロジェクト管理、経費精算システムの開発を行っています。

f:id:teamspiritinc:20200129212634p:plain


今回はプロダクトマネージャーに必要なマインドとスキルについてお話しました。

必要なマインド

大日田さんの「プロダクトマネジメントの重要性」で話されたことと共通していました。プロダクトマネジメントが存在せず、要望ベースで機能追加すると、いつかどこにも進めなくなる。機能を追加することは限られたリソースを投資することであり、この課題解決に投資する必要があるのか、そして課題をどうやって解決するのか、に全力を使おう!

必要なスキル

「この課題をどうやって解決するのか」を見つけていくプロセスの中で「意思決定」をし続けていくのがプロダクトマネージャー 。「意思決定」が大事なスキルであると強調していました。

そして最後に、プロダクト開発に携わるもの全員が持つべきマインドセットについて。製品開発のアイデアは半分以上がうまくいかない。ロードマップに機能を載せてリリースしたらOKではなく、ある課題を解決することができたかもしれないし、そうでないかもしれない。それくらいに思ってインパクトを見続けようというメッセージが印象的でした。

Drinks/snakes and networking

プレゼンテーション後は、ピザとアルコールを交えた懇親会を実施しました。

参加者同士で、本日の登壇内容について意見を交わしたり、日々のプロダクトマネジメントの困りごとなどをシェアするなど、活発に会話が行われていました!

f:id:teamspiritinc:20200129144454p:plain

まとめ

大日田さんと小泉の発表に共通していた「プロダクトマネジメントの重要性」。何をしても必ずどこかにたどり着くが、その先どこにも進めないような場所ということもある。どこにたどり着きたいかを決め、そこに向かっていくために仮説検証をやり続ける。意思決定をし続ける。プロダクトマネージャーの仕事の重要性を、改めて実感したお二人のお話でした。

次回の「Product Management Night Tokyo」はfreeeさんで実施予定です。プレゼンテーションでは、その会社、その現場のプロダクトマネージャーならではの事例がたくさん出てくると面白くなりそうですね!次回もとても楽しみです。

プロダクトマネージャー募集

チームスピリットでは、100億円のビジネス作るプロダクトマネージャーを募集しています。チームに興味を持っていただいた方、ご連絡くださいね。直接メッセージでも、下記の応募フォームからでも構いません。

エンジニア募集

 

 

サクラエディタからVisual Studio Codeへ乗り換えたくて拡張機能を作った

本記事はエントリーブログを兼ねた、チームスピリット Advent Calendar 2019 の7日目の記事です。 adventar.org

こんにちは!
2019年7月にTeamSpiritにジョインした里石です。

弊社のSDチームでは、サービスの開発にEclipseまたはVisual Studio Code(VS Code)を用いています。
私は前職ではサクラエディタを多用していましたが、その上位互換なVS Codeも注目はしていたものの、カーソルの操作感などに違和感があって乗り換えには至りませんでした。
そこで今回、入社を機にその違和感を乗り越えるべく、勉強も兼ねてVS Code拡張機能を2つ作りました。

カーソル移動の改造(skr Jp Word Handler)

marketplace.visualstudio.com

VSCodeでの日本語圏向け拡張機能としては、Suguru Yamamoto氏の「Japanese Word Handler」という優れた拡張機能がすでにあります。

今回はそれを参考にさせていただきつつ、開発しました。

概要

Windowsのサクラエディタライクなカーソル移動を行います。
実際には、サクラエディタっぽい挙動に加えて、VSCodeのcursolWordPartLeftcursolWordPartRightのカーソル移動の挙動も取り入れています。

下記のように、単語や文字種毎にカーソル移動を行います。

実装機能

  • カーソル移動 および 選択
    f:id:satoishi_ts:20191205232923g:plain

  • 句切り文字毎削除
    f:id:satoishi_ts:20191205232918g:plain f:id:satoishi_ts:20191205232909g:plain

対応句切文字パターン

  • VSCodeのSeparateWordに設定する区切り文字
  • スペース
  • 英字(大文字)
  • 英字(小文字)
  • 数字文字
  • 記号
  • タブ制御コード
  • 日本語のひらがな
  • 日本語のカタカナ
  • 日本語の漢字
  • 日本語の句読点
  • 日本語の全角英字(大文字)
  • 日本語の全角英字(小文字)
  • 日本語の全角数字
  • 日本語の全角記号

既知の制限事項

JapaneseWordHandler拡張機能と同様に一部制限があります。
拡張機能は、単語に関する以下の機能を差し替えることができません。

  • ダブルクリックによる単語選択
  • カーソルポジション上の単語の自動ハイライト
  • テキスト検索時の「単語にヒット」

その他

ライセンスは、Suguru Yamamoto氏のJapanese Word Handler拡張機能を継承して、zlibライセンスです。

全角文字の強調表示(flexibleZenkaku)

marketplace.visualstudio.com

VSCodeでは、サクラエディタのように全角スペースをハイライトすることができません。
これを実現するには、mosapride氏の「zenkaku」というシンプル・イズ・ベストな拡張機能があるのですが、 個人的な不満として、ソースを直接編集しないと見た目のカスタマイズができないというのがありました。

それを「設定」画面上からできるよう改造したのが本拡張機能です。

実装機能

readmeにも記載していますが、「設定」画面から、色や線種・塗りのカスタマイズができます。
f:id:satoishi_ts:20191205233458g:plain

その他

ライセンスは、mosapride氏の「zenkaku」拡張機能を継承して、MITライセンスです。

終わりに

とりあえず、自分の思うようなカーソル移動を実現できたので、無事VSCodeに乗り換えることができました。
あとは、「矩形貼り付け」がまだ違和感があるので、そのあたりの拡張機能が作れないか検討中です。

よろしければ是非ご利用いただき、フィードバックをいただけると幸いです!

また今回の拡張機能の開発を通して、VSCode上におけるTypeScriptのテスト環境構築の方法も学ぶことができました。
引き続き、12/14のアドベントカレンダーではその方法について解説しています!

satoishi-ts.hatenablog.com

プロダクトマネージャーのTrends & Benchmarks Report 2019を読んでみる

この記事はチームスピリット アドベントカレンダー2019の20日目の記事です。 adventar.org

TeamSpirit Singaporeでプロダクトマネージャーとして奮闘しているNinoです。 最近インタビュー記事を書いてもらいました。 それが気づいたらSlackのemojiにされてました。愉快なメンバーと楽しく働いています。

f:id:n-nino:20191219102207p:plain
(誰がやっているか知らんが、最近emoij増やされてる…。)



さて、プロダクトマネージャーとしてまだまだ勉強中の私ですが、今回は先日公開されたプロダクトマネジメントのTrends & Benchmarks Report 2019というレポートを読んでよりPMという職をより深く理解していきたいと思います。


f:id:n-nino:20191219103648p:plain

レポート発行元、Product Management Festivalについて


このレポートの発行元はProduct Management Festivalという、世界的なプロダクトマネージャーを支援している組織で、スイスのチューリッヒに本拠地があります。 GoogleやFacebook、ATLASSIANのPMの方々も所属しており、現在はヨーロッパ中心に活動していますが、最近シンガポールなどのアジアでもカンファレンスを開催して勢いがあります。 日本ではまだ恐らく全くの無名ですが、1月に弊社で日本初のイベントを開催する予定です。 teamspirit.connpass.com ちなみに、この記事を書いてもいいかと問い合わせたところ快諾してくれました!(※無断転載ではないので悪しからず。) 日本にもこれから広めていきたいですね。


レポートについて


このレポートはPM Festivalが今年実施したアンケートをもとに作成されています。

f:id:n-nino:20191219105439p:plain
回答者は世界中で働いてるPMの方々で、1011人、59カ国から回答を得ています。
(私も回答しました。)
本レポートはこちらから無料でゲットできますので興味ある方はぜひ。

それでは中を見ていきましょう!

PM歴


回答者がどれだけのPM歴を持っているか。

f:id:n-nino:20191219114155p:plain
(グラフ左)約4割の人が6年以上のPMを歴を持っているんですね。
先輩たちから学ばないといけませんね。

キャリアパス


PMになる前はどのような職に就いていたか。直前の職は何か。今のジョブタイトル。

f:id:n-nino:20191219115318p:plain
(グラフ左)プロマネ出身の人が一番多いですが、満遍なく色んな職種からPMになっているのが分かりますね。
自分のようなエンジニア出身が10%しかいないのは思ったより少ない。

プロダクトマネジメントの成熟度


回答者の組織でプロダクトマネジメントがどれだけ成熟しているか。

f:id:n-nino:20191219115644p:plain
(円グラフ)8割の組織でプロダクトマネジメントがまだ成長段階にあると回答していますね。

コラボレーション


他の職種とどれだけうまくコラボレーションできているか。

f:id:n-nino:20191219191032p:plain
(グラフ左)やはり、まずは現場のエンジニア、QA、デザイナーとうまくやることが大事ということですね。
BAとうまくやれているという回答が3割しかないのは意外でした。

PMの役割と価値


組織の中でPMという職がどのように認識されているか。

f:id:n-nino:20191219191753p:plain
(グラフ下)PMの役割が完全に定義されていて、周りに理解されているという回答が2割しかないですね。
自分もPMの責務は広くて境界もあいまいな部分が多いなと感じています。
これはあるあるの悩みっぽいですね。

PMのスキルと価値


どのようなスキルが大事と思うか。一番の責務は。

f:id:n-nino:20191220093823p:plain
(グラフ左)重要なスキルにコミュニケーションとチームワークが来てますね。PMはステークホルダーが多いので納得ですね。
(グラフ右)PMが感じている責務は次の3つが群を抜いてますね。1,プロダクトのビジョンとストラテジー、2,プロダクトの要件管理、3,ロードマップとリリース管理。

プロダクトビジョン


f:id:n-nino:20191220095035p:plain
(グラフ右上)半数以上がプロダクトのストラテジーやビジョンを月に1回以上レビューしていると回答していますね。
固めるのではなく、常に状況に合わせてアップデートしていくのが重要ということですね。

プロダクトの成功とPMの評価


プロダクトの成功をどう計測するか。成功は誰に帰属するか。PMの人事評価。

f:id:n-nino:20191220095405p:plain
(グラフ左上)プロダクトの成功を測るメトリクスは次の4つがメジャー。1,財務的な数値(売上/利益)、2,顧客数、3,エンゲージメント、4,顧客満足度/NPS。
(円グラフ)一方で、それらの指標はPMの個人的な評価にも使われるかは半々のようです。

フレームワークと手法


プロダクト開発に利用している手法。それらの満足度。

f:id:n-nino:20191220100346p:plain
(グラフ左)9割以上がスクラム/アジャイル/カンバンを利用していることが分かります。我々もそうです。
(グラフ右)しかしながら、それらを満足に運用できているのは45%に留まっているが分かります。スクラム運営の難しさが表れているのかなと思います。

PMにとってのチャレンジ


PMにとってのチャレンジTop3。プロダクトに影響のある課題。

f:id:n-nino:20191220101617p:plain
組織の目標を達成しなくてはいけない一方で、意思決定や責務が不明確、そもそも時間がない等の課題をPMは抱えていることが、この2つのグラフから読み取れますね。

業務


メインで取り組んでいてる仕事。主な成果。優先順位の付け方。

f:id:n-nino:20191220102258p:plain
(グラフ左上)PMが日々何に一番時間を使っているかというと、実はデイリーの業務や突発的な依頼、トラブル対応なんですね。
PMでありながら、実作業としてはプロダクトに関する仕事に一番多くの時間を割けていないというのが現状のようです。
(グラフ右下)優先順位の付け方の結果も非常に面白く、大半の人が「経験と直感」でやっていると回答しています。

仕事の満足度


PM職に必要だと思う要素。満足度(レート)。満足度(ステータス)。転職志望度。

f:id:n-nino:20191220103935p:plain
(グラフ左下)5割以上の人が、仕事の満足度に対して、10点中7点以上を付けていますね。これは平均的に高い数値と言えるのではないでしょうか。
(円グラフ右上)45%の人が「ワードワークだが楽しい」と回答しています。これはPMになるための一つの資質かもしれませんね。

PMの採用


直近6ヶ月のPMの採用予定。PMの採用方法。PMの採用難易度。

f:id:n-nino:20191220105505p:plain
(グラフ左上)直近6ヶ月で半数以上の会社がPMを1人以上採用しようとしていることが分かります。去年に比べて需要が高くなっているのも見て取れますね。
(グラフ右上)驚くことに、採用の一番の手法はリファラルで60%となっています。これは日本に比べるとかなり高い割合ではないでしょうか。



おわりに

といわけで、ざっと2019年のPM Trends & Benchmarksを見てみました。
まだまだ勉強中の私ですが、共感できるところ、興味深いところが多くありました。
みなさんも、少しはPMに興味が湧いたり、理解が深まったりしましたでしょうか?
英語のレポートですが、全然難しくないのですべて見たい方はこちらからどうぞ。

ちなみに、2020年もこのアンケートは実施されます!PMの方はぜひ参加してみてください!
(この件で連絡した際に、Product Management Festivalから「日本語に訳すの手伝ってくれないか?」と言われたのでもしかしたら日本語Ver.もできるかもしれません。がんばります。)

スクラムチームで探索的テストをやったお話。

この記事はチームスピリット アドベントカレンダー2019の15日目の記事です。

adventar.org

Frohe Weihnachten!! …まであと9日。
こんにちは、チームスピリットのQAエンジニアのSumiです。

去年はドイツのクリスマスマーケットを紹介するという1ミリも仕事に関係ない話だったので、今年は仕事に関する話を書いてみようと思います(ドキドキ)。内容は、私がスクラムチームやほかのQAメンバーとともに行った品質保証の取り組みについてです。なお、弊社の品質保証の方法についてはQAリーダーの生井がJaSST’19北海道で登壇した資料がありますので、そちらをご覧ください。

speakerdeck.com

弊社の開発スタイルについて

弊社のプロダクトはSalesforceのPlatform上で動くサービスで、開発手法は2週間スプリントのスクラムを採用しています。これ自体はわりと一般的かと思いますが、他社と大きく違うのはリリースのタイミングです。通常スクラムの原則としては各スプリント終了時にリリースできるように開発などを進めていくとなっていますが、弊社はSalesforceの4か月に1度実施されるバージョンアップに合わせる形でスクラムを回しパッケージをリリースしています。*1
開発(テスト)体制については、勤怠・工数・経費などのモジュールごとにスクラムチームがあり、QAエンジニアが各スクラムチームの一員として日々ユーザーストーリーの機能テスト(手動)などを実施しています。1バージョンなので、開発、テスト、プロダクトマネージャーのレビュー工程が終わった後にコードをmaster branchにマージするという流れです。

課題

まだチームが勤怠・工数しかなく、日本にしかオフィスがない時代は特に問題はなかったのですが、去年夏にシンガポールの開発拠点ができ、また経費など新たなモジュールのチームが立ち上がったことで、徐々にmasterの品質を保証することが困難になってきました。
具体的には新機能開発や不具合修正の影響範囲の調査が不十分で、他機能や他モジュールに影響がでてしまうというような問題が起き始めていました。masterにマージする前のテストフェーズでできる限りの確認はしていましたし、レビューでも影響範囲の確認はしていますが、それでも…*2
そして、masterにマージしてからリリース作業まで時間がある場合はどこかで偶然的に発見されることがあったものの、リリース間隔が短くなったことでそのチャンスも減っていました。その結果、製品をリリースした後に不具合が見つかりパッチを出してしまうということが発生し始めていたため、いかにこのような不具合をリリース前に見つけつぶすかという対策が求められていました。

対策

この時求められていた"パッケージリリース前にmasterの品質をあげる"ということを実現するために、
①時間をかけず
②効率的に
③不具合(主にリグレッション課題)を見つける
という条件をクリアするアプローチが必要でした。それでかつ、リリースを遅らせないという…
そこで私たちQAが提案した方法は、リリース予定の開発物がすべてmasterブランチにマージされた後に開発チーム全員で探索的テストを実施するというものです。
具体的には、エンジニア1人当たり最低半日分の工数を探索的テストに使ってもらい、それぞれチャータに従いテストをするという感じです。ただのモンキーテストにならず効率的に不具合を発見できるようテスト分担、環境、テスト観点などのチャータを事前にQAが準備しました。またQAだけでなくエンジニアにもテストをしてもらった理由は、時間(期間)はかけられないという制約の中で工数を集中投下することで最大限の手厚いテストができるようにするためです。なお、探索的テストを通じてエンジニアにより品質への意識を高めてもらいつつ、他モジュールの製品についても理解してもらう狙いなども実はありました。

結果

エンジニアが発見した不具合をJIRAに起票してもらいQAが集計・分析を行ったあと、テスト計画に記載したリリース判定条件に照らし合わせながら、リリース可能な品質に達しているかどうかプロダクトマネージャーと議論しました。このときは残念ながら一度のテストでは十分な品質でないという判断になり、発見された不具合を修正しつつ手が空いたメンバーで追加テストを実施することになりましたが、当初の目的であった"パッケージリリース前にmasterの品質をあげる"ということは達成できたといえると思います。もし探索的テストをせずにそのままリリースしていれば、パッチにつながりかねない不具合も発見されていたからです。
ただ、もしかしたら一番の収穫は、テストを実施したことに対するプラスの意見がエンジニアから出てきたことかもしれません。このテストがエンジニアにとって、プロダクトの品質をどう高めていくかを考えるひとつのきっかけになったのであればQAとしてはとても嬉しいことです。

今後について

しかしながらこのリリース前の探索的テストはあくまで一時的な対策でしかないと考えています。
本来品質はもっと前から作りこむべきで、今この対策でギリギリのラインで品質を保証せざるを得ないということはどこかで打つべきアクションができていないということだと思われるためです。それはコードレビューの質の向上かもしれませんし、自動テストの拡充かもしれませんし、さらに適切な技法を用いた各ストーリーチケットベースのテストかもしれません。
QAとして引き続きプロダクトの品質向上と安定的な品質の保証ができるよう、そしてお客様に私達の製品を使うメリットをより享受していただけるよう、さらにいろいろ取り組んでいきたいと思っています。*3

メンバー募集中!

そんな私たちと一緒にプロダクトの品質向上を担ってくださるQAエンジニアを大絶賛募集中です!テスト設計や実施だけでなく品質保証全体に携わることができるので、興味がある方はぜひこちらから応募をお待ちしております!
https://www.teamspirit.com/ja-jp/recruit/r_d.html

*1:私が携わっている新製品の開発チームは現在、リリース頻度を高めお客様に早く価値をお届けできるよう2か月ごとのリリースを頑張っています。

*2:回帰テストとして必要最低限の自動テストは実施していましたが、リソース不足で自動テストの拡充ができていなかったという事情もあります。

*3:そのための1歩としてJSTQBのAL-TAを受検予定!

TeamSpirit Inc.の社内IT施策

こんにちは、ブログ初執筆の社内IT担当、小林です。
初登場ということで、社内IT部門でやっている&やっていくことを紹介します。

adventar.org

Self Introduction

事業会社で開発系のエンジニア、コンサル会社で官公庁/企業向けプロジェクトでコンサルタントとしてのキャリアを経て、TSI情シス部門の立ち上げ部隊(といってもまだ1人)として参画させていただきました。

なんちゃってだけど出身がエンジニアということもあり、LTとかテック系のイベントがけっこう好きです。
短期間だけどコンサルだったこともあり、プロジェクト進めたりドキュメント作ったりするのも好きです。
経歴関係ないけど、お酒とランニングも好きです笑

Mission

社内のITインフラの運用・保守だけでなく、ITのあらゆる側面から自社の成長をさらにドライブしていきます。
各業務ディビジョンには営業、導入サポート、カスタマーサポート、開発と各分野のキスパートの方々が日々活躍されていますが、社内を俯瞰して見られる立場だからこそ、全体最適の施策を提案して進めていきたいと思います!

What we do

ざっと3つの領域で活動してます。いくつか最近の例を紹介します。


1. IT企画関連

特に全社横断的な業務・システムの課題への対策を検討し、システム側で対処する場合は解決に向けプロジェクトの管理・ファシリテーション、関係各所との調整、サービス選定等をカバーします。

例えば、基幹システムのリプレースに向けて、業務側のヒアリングやベンダー選定をしたり(どちらかというと社内SE,PMO的な動き)、CRMの設定・活用を見直したりしようとしてます。

FYの施策として挙がっているものやメンバー個人からの問題提起ときっかけは様々ですが、解決につながればそれだけ会社全体へのインパクトが大きいので、いろんな人を巻き込んで着実に実行できるよう頑張っていきます。

2. ツール活用関連

業務効率化のため、主に各業務ディビジョンで利用予定のサービス・ツールの事前検証や、利用中のサービス・ツールの機能をさらに活用して作業時間を短縮する検証、現場展開のお手伝いをしています。

例えば、契約・会計業務で利用しているSaaSのサービスに、APIツールを使って会計データを流し込む方法を確立する、という具合です。直近では、受付システムの追加導入をしたり、電子署名ツールの導入に向けて運用・作業手順の整理を進めようとしてます。

SaaS企業として、流行りだったり遊び心のあるサービスを使っていることは対外的にも"イケてる"イメージにつながると考えているので、有効なものをどんどん導入していければと。

3. 情シスロジ関連

だいたい定期的に発生する、システムのハード/ソフト面での各種メンテナンスをやります。

例えば月に2回、新入社員向けのPC設定や各種アカウントの発行、初出社日のオリエンをやっています。PCの操作とかオリエン時にハンズオンでやるので、人数が多かったりすると内心ドキドキしますが…IT系出身の方が多いのでサクサクキャッチアップしていただき助かってます。

最近では、組織変更や業務実態に合わせて、勤怠システムのマスタや電子稟議の承認フローを変更しました。変更内容や事前検証の設計(一部を担当)から始まり、検証や設定変更と手を動かすところもやります。

特に設計面の、権限回りや承認ステップの条件分けがポイントで、承認者や組織階層などが変わってもシステムの変更が最小限ですむよう保守性の向上にはまだ改善の余地があると感じています。

Message

これまでは社内IT施策に割くリソース余裕がなかったという背景がある(とのこと)ので、まずは各ディビジョンの業務上マストな施策中心に取り組みつつ、「こんなこともやってみよう」と提案して各コア業務をより効果的に進められるようサポートしていければと思っています。

あとは…仲間が欲しい。特にでっかめの基幹システムやインフラの知見・経験を持った人、募集してます。社内IT関連のイベントに顔を出して発信したり、情報交換したり、地道にやっていきます。

>To TSI members

こんなかんじでまだまだ始動したばかりですが、PCトラブル起こった時でなくてもやりたいこと、困っていることあればぜひお声がけください!

よろしくお願いします!