こんにちは！スパイダープラスでエンジニアリングマネージャーを務めている本田です。
私は入社して3年目、エンジニアリングマネージャーとしては1年目になります。
これまで約10年間ソフトウェアエンジニアとして働いてきましたが、開発リーダー的なポジションの経験はあるものの、マネージャーとして明確に自分のチームを持つのは弊社が初めてでした。
マネージメント職にチャレンジした理由は、エンジニアとして培った「こうすればもっと良くなる」というアイデアを、弊社の持つ環境でなら実現できると確信したからです。
この記事を書くことにした動機は、長い間マネージメント職を敬遠していた私が、今ではとても楽しくマネージャーとして仕事をしていることが挙げられます。
本記事のテーマは私が開発チームの運営をする上で大切にしている価値観や考え方です。
もし、この記事を通じてエンジニアのマネージメント職に対する新たな視点や魅力を感じてもらえたら嬉しいです。
システム運用部の🐧です。
システム運用部は名前の通りサービスの運用に関するインフラ寄りのあれこれを請け負うチームなのですが、部署間の情報の受け渡しや、業務の効率化に伴うツールの作成等を行うこともあり、SRE的なお仕事も行っております。
UIUXチームのデザイナーのKimiです。
Adobe IllustratorやPhotoshopを使わずに、Figmaのみでプロフェッショナルなグラフィックワークを仕上げることができます。
特にUIデザインでは、開発者やクライアントと簡単に制作物を共有でき、効率の良い作業フローが求められる場面が多いかとおもいます。
私自身、長年Adobe製品に慣れ親しんできましたが、最近はFigmaにシフトして、あらゆるデザインを一つのツールで完結させることで大幅な作業効率の向上を実感しています。
今回は、IllustratorやPhotoshopを使わずに、Figmaのみで質の高いグラフィックワークを実現するための具体的なテクニックを紹介します。
みなさん、こんにちは。
プラットフォーム部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へ有効な情報を記録に残すことで、不具合分析もしやすくなります。
その結果、製品の品質向上に繋がっていきます。
過去記事：不具合分析始めました
スパイダープラスでは仲間を募集中です。
スパイダープラスにちょっと興味が出てきたなという方がいらっしゃったらお気軽にご連絡ください。
