みなさん、こんにちは。
プラットフォーム部MobileチームのEMをやっていますオダギリです。
突然ですが、みなさん、UnitTestは書いていますか？
我々スパイダープラスのプロダクトでもUnitTestは行っています。
今回、プロダクトの品質向上のために、改めてUnitTestについて調べましたので、皆様にも共有できればと思います。
UnitTestは、アプリケーションやプログラムの個々の要素（今回はメソッド）を独立してテストし、その動作が正しいかを確認するテスト手法です。
続きを読む
皆様こんにちは。
秋も深まり、紅葉がきれいな季節がやってきました。
スパイダープラスでは、日々エンジニアたちが技術を研鑽しながら業務に取り組んでいます。
今回は、そんな弊社エンジニアたちのSlack上での会話をブログとしてお届けします。
この記事を通して、スパイダープラスの雰囲気を感じ取っていただけるよう、できるだけSlackの会話をそのままお伝えしたいと思います。
ほぼブログとは言えない形式かもしれませんが、初めての試みですので、楽しんでいただければ幸いです。
なお、この会話はY・Kさんからのクイズが会話の起点になっています。
皆さんも解けるかどうか、ぜひチャレンジしてみてください。
続きを読む
スパイダープラスでVPoE 兼開発部とシステム運用部の部長を兼務している紙岡です。
本日はカジュアル面談や採用面接などでもよく聞かれる開発組織の構成について、掘り下げてご紹介できればと思います。
（2024年10月時点の組織のため今後変更する可能性がありますことご容赦ください）
こんにちは。プロダクト品質部の後藤です。
システムの開発や運用時に切っても切り離せないのがバグです。
スパイダープラスでも開発・検証・リリース後で多種多様なバグの報告があがってきています。
今日は、日々不具合と格闘しているQAチームにおいて、「バグを活かす方法」について紹介したいと思います。
バグの発覚は避けるべき問題である一方で、発覚したバグの管理は、ソフトウェアの品質向上をさせるためにとても重要なプロセスといえます。
スパイダープラスではBTS（Bug Tracking System）にBacklogを使用しており、開発や検証時に不具合が発覚した時は以下のような流れで管理を進めています。
検出されたバグをBTSに起票しただけで終わりにせずに、記載内容次第で多様な場面で活かしていけます。
具体的にどの場面でどのように活用できるのかを紹介したいと思います。
不具合の事象を起票する際に発生していた事象だけではなく、再現手順の記載・不具合が発生した時に使用した環境の記載・キャプチャ・再現時の動画を添付する等をすることで、不具合の調査をする際に原因を特定しやすくなります。
また、再現した時の状況を画像や動画で視覚的に見せることで、調査者と起票者のやり取りが減り、作業の効率化につながる事も期待できます。
私自身も不具合発見時に起票したり他メンバーの記載内容をレビューした時に、上記に記載した内容を気にかけて後工程に携わる人が効率よく作業できるように心掛けています。
不具合を調査する際に開発者がBTSに発生原因・流出原因・修正方針を記載しますが、修正前後の該当コードのみを記載するだけではなく、発生原因や修正方針などを詳細に記載することで、不具合修正後に実施するコードレビューや試験観点のレビューで、レビューアに対し不具合の概要を伝える以外にも、レビューでの仕様の認識齟齬による修正内容の矛盾や試験観点の漏れがないこと等を指摘しやすくなることが期待できます。
私自身も不具合修正後の結合試験の試験観点レビューをしたり、不具合修正後の試験項目の作成時に、上記が詳細に書いてあると実際起きた事象の解像度が上がりレビューや試験項目の作成がやりやすかったです。
調査や修正の段階で開発者が流出原因・処置内容・影響範囲をBTSへ詳細に記載することで、テスターがテストを行う際にテスト仕様書に記載の項目以外にアドホックの観点で試験を行う際にも役立てることが期待できます。
BTS（Bug Tracking System）への記載内容が充実していることで、今後の仕様変更が発生した場合や試験項目を作成する際に不具合を流出させないために気を付けるべき点が明確になってきます。
また、各工程でBTSへ詳細に記載することで、今後市場で不具合を流出させないために役立てることができます。
私自身もテスト仕様書作成時に過去にBTSへ記載されていた不具合と似たような確認項目を作成したところ、検証時に不具合が発生したという経験があるので、BTSへの記載は後工程や不具合解消後の検証で似たような不具合を防ぐために有効な手段の一つであると考えています。
私の経験を例に各工程での活用例を紹介しました。
BTS（Bug Tracking System）への記載内容が増えるとそれだけ手間が増えますが、開発プロセスの一環としてBTSへ有効な情報を記録に残すことで、不具合分析もしやすくなります。
その結果、製品の品質向上に繋がっていきます。
過去記事：不具合分析始めました
スパイダープラスでは仲間を募集中です。
スパイダープラスにちょっと興味が出てきたなという方がいらっしゃったらお気軽にご連絡ください。
こんにちは、DevOpsチームの宮囿です。
唐突ですが、私はfzfが好きです。fzfはCUIで使えるファジーファインダーツールで、大量の項目の中からあいまいな指定で任意の項目を選択することができます。fzfは最高です。
私の業務はCLI上の作業が多いので、効率化の為にfzfをいろんな場面で使い倒していきたいと思っています。
そんなにfzfが好きだったんですが、Ctrl+rでめちゃくちゃ便利なコマンド履歴検索ができることを社内Slackで知ってしまい、改めてfzfの利用方法を学習しなおしました。
この記事ではその際見つけたTipsをいくつか紹介できればと思います。
こんにちは、iOSエンジニアの澤田です。
今回は、私が主催として定期的に開催している「顧客理解勉強会」についてご紹介します。
開発業務に集中していると、実装する機能がどのような課題を解決し、どのような価値を提供するのかを見失いやすくなります。
そこでこの勉強会は、エンジニアが顧客視点を常に意識できるよう、それぞれが集まって顧客課題やその解決策について議論する場として位置づけています。
この記事では、勉強会の目的や進め方、また実際に行って実感したことについてお伝えします。
なお、実務での活用事例については取り上げておりませんが、顧客視点を意識した開発を目指している方にとって、少しでも参考になれば幸いです。
日々の開発業務では、顧客がどのような課題に直面しているのかを把握するのが難しく、結果として「誰のどんな問題を解決するために開発しているのか」が見えにくいと感じることがありました。
続きを読む
どうも7月入社してほどほど慣れてきた舘です！
普段は、iOSチームで開発しています！！
今回は社内向けにObjective-Cキャッチアップ勉強会を開催したのでその経緯を紹介したいと思います！
SPIDERPLUSには、2011年9月から提供している社内ではクラシック版と呼ぶものと、2022年に開発したリニューアル版と呼ぶものとがあります。
Swiftを使っているリニューアル版とは異なり、クラシック版ではObjective-Cを使っています。
そこで、リニューアルチームからクラシックチームに移ってくるメンバーを対象に、勉強会を開催することで技術的背景のキャッチアップをはかることを目的にしました。
