はじめに
セキュリティサービス部新人 IT エンジニアの新宮です。
入社して早 4 ヶ月(記事を書いた時点で)。もうそろそろ右も左も分からないとは言い難くなってきた頃合いです。
私自身も胸を張って「右も左も分かります」と言えたらいいのですが、正直なところ先輩方のやることなすことに全くついて行けていないというのが現状です。
しかしながら、自らこのように主張することは憚られますが、分からないこと自体は決して悪いことではありません。分からないことがあるというのは、それだけ伸びしろがあるということです。素直に「分からない」と言えるひたむきさこそが、日々の成長につながるのです。
翻って私は、少々見栄っ張りなところがあり、分からないことがあっても澄ました顔でそれを隠蔽する癖がありました。当然これは悪いことです。
分からないことが恥ずかしい、というのもありますが、分からないことで失望されたり怒られたりするのが怖くて、中々素直に質問できないという側面があったように思えます。
もちろん自分で調べることは大事ですが、どんなに調べても分からなくて行き詰まってしまった場合、頭を下げて教えを請うことできっと状況は好転します。
そこへ行くと、弊社は会社全体で”声をあげやすい空気”が醸成されているように感じます。
皆さん知的好奇心が旺盛で、分からないことは恥だと思わず、ベテラン若手問わず闊達に意見交換しています。
そういった空気感に助けられ、今では私も積極的に質問することを心がけるようになりました。
弊社には知的で、理路整然として、頼りがいのある方々がたくさんいます。決して媚びてるわけではありません。本心からそう思っています。素直に質問すれば、右も左もきっと優しく教えてくれます。
今回は、特に上記のような空気感が顕著に感じられた品質保証研修での体験談を通して、そのような弊社独特の空気感を紹介していきたいと思います。
本ブログ記事を通して、そんな弊社の社風や雰囲気のようなものを感じ取っていただければ幸いです。
作業環境
OS
- Windows 10
使用ツール
- Excel
- PowerPoint
品質保証研修
品質保証部と聞くと、皆様どのようなものを想像されるでしょうか。
定められたデバッグやテストを延々と実施するだけ？本質的な付加価値の向上には寄与しない？
とんでもない。品質保証部は、プロジェクト全体においてとても重要な役割を担っています。平たく言ってしまえば、品質保証部とは、製品の品質全体についての責任を持つ部署になります。では、そもそも品質とはなんでしょうか。
当研修では、品質の定義として「要求を満たすこと」、「誰かにとっての価値であること」の 2 つの要素をあげています。その上で、「品質の良いソフトウェアとはユーザーの要求を満たし、ユーザーに価値を提供するソフトウェアである」としています。
また、品質 (Quality) の向上のみならず、それにかかるコスト (Cost) や納期 (Delivery) などを考慮して、テスト計画を立てなければなりません。これらの要素をまとめて QCD という概念で取り扱っています。品質保証部では、この QCD を保つために様々な取り組みがなされています。
具体的な業務内容としては、以下の 5 つがあげられます。
具体的な業務内容
- 品質管理・分析: 品質向上と QCD 適正化のための管理・分析
- 定常業務・管理: 品質保証部で取り扱う物品や情報などの運用・管理
- システム開発運用: テスト業務で必要な環境構築やツールの作成
- テスト業務: テスト設計/テスト実施
- 業務プロセス管理: QCD 適正化のためのプロセス改善
このうち、研修で体験したものはテスト業務にあたります。特にテスト設計を重点的に実施し、最終的に作成したテスト設計書をもとに弊社製品に対してテストを行いました。
研修は 5 日間に渡り、全てテレワークで行われました。内容は、様々なワークでテスト設計を体験するというものです。1 日目は、ISO/IEC 9126 や狩野モデルといった品質特性規格を用いて、特定の製品の品質について考察しました。
品質特性の考察
ISO/IEC 9126 とは ISO/IEC の定める品質の国際規格で、品質を以下の 6 つに分類します。
ISO/IEC 9126
- 機能性: 機能とその特性に影響する特性群
- 信頼性: ソフトウェアがどの程度機能するかに影響する特性群
- 使用性: 利用するのにかかる手間、個人の努力などに影響する特性群
- 効率性: ソフトウェアの性能やそれに要するリソース量に影響する特性群
- 保守性: 何らかの変更を加えるのにかかる手間に影響する特性群
- 移植性: 別の環境にソフトウェアを移行させる可能性に影響する特性群
狩野モデルでは、品質特性を以下の 3 つに分類します。
狩野モデル
- 魅力的品質: 不充足でも仕方がない (不満には思わない) が、充足されれば満足
- 一元的品質: 不充足だと不満、充足されると満足
- 当たり前品質: 不充足だと不満、充足されて当たり前
| 魅力的品質 | 一元的品質 | 当たり前品質 |
|---|---|---|
| 機能性 | ||
| 信頼性 | ||
| 使用性 | ||
| 効率性 | ||
| 保守性 | ||
| 移植性 |
これら 2 つの規格をそれぞれ行、列とした表をつくり、ある製品に適合する品質について考察しました。ISO/IEC 9126 の各品質特性に対して、それぞれ狩野モデルの魅力的品質、一元的品質、当たり前品質に当てはまる品質特性を考えていきます。
たとえば、テレビの品質特性について考えていきましょう。機能性であれば、魅力的品質には 4K/8K 画質対応機能、一元的品質にはフル HD 画質対応機能、当たり前品質には色合いが正確などが入るでしょう。このようにして、他の信頼性や使用性などにもどのような品質特性があるかを考えていきます。
この研修は、A チーム、B チームの 2 組に分かれ、グループワークで行われました。私が配属されたのは A チームです。題材として 2 つの製品を示され、上述のように品質特性を考察していきます。
チームの人数は 4 人で、私はグループのリーダーに抜擢され、グループの意見を取りまとめることとなりました。あまりにも荷が重く、緊張からとても拙い進行になってしまいましたが、皆さん積極的に協力してくれて、たくさん意見を出してくれました。
講師も通話に参加してアドバイスをくれたりするなどして、和気あいあいとした雰囲気で議論を進めることができました。講師陣の方々はとてもフレンドリーで、行き詰まっているとそれとなくアドバイスを出してくれたり、雑談で場を和ませたりもしてくれました。
この研修に限らず、弊社は基本的に朗らかな方が多いと感じました。セキュリティサービス部では、雑談用のチャンネルが頻繁に利用され、全てのエンジニアがテレワークでの勤務ではありますが仕事以外のコミュニケーションも日常的に行われています。
閑話休題。会議は順調に進んだように思えましたが、私の至らなさもあり、ひとつ目の製品ではすべてのマスを埋めることができませんでした。 B チームはすべて埋められていたのでとても不甲斐ない気持ちになり、その場で号泣してしまいました。
ふたつ目の製品の品質特性の考察をする前に、講師からアドバイスを頂きました。
「商品の核となるのは当たり前品質なので、まずこれから考える。次に、何がなかったら困るのかを考える。これは一元的品質(品質の維持)に該当する。最後に、何があれば嬉しいのか、つまり魅力的品質(品質の向上)について考えればいい」。
目から鱗とはこのことを言うのでしょう。私にとってその助言は、まさに暗闇に差した一筋の光と言えるものでした。頂いたアドバイスを意識して、次のワークの進行をします。チームの皆さんは、急に進行の方法を変えても何も言わずに協力してくれました。すると今度はすべてのマスを埋めることができました。
テスト観点/テストタイプの考察
雪辱戦を終えて、休む間もなく次のワークです。今度は、考察したひとつ目の製品の各品質特性に対し、それを満たすために必要なテスト観点/テストタイプを考察するというワークです。テスト観点とはテストの切り口や品質のノウハウのようなもので、大まかに大分類、中分類、小分類の 3 つに分けられています。膨大な数があるので全ては紹介しきれませんが、一部を紹介します。例えば、大分類には以下のようなものがあります。
大分類
- 機能: ソフトウェアが指定された条件のもとで動作するとき、要求されている仕様を満たす確認のための観点
- 非機能: 与えられたリソースに対して、適切な性能を発揮する確認のための観点
- ユーザー: ソフトウェアを指定された条件のもとで動作するとき、利用者が理解、習得、利用がスムーズにおこなえる確認のための観点
- テスト: 上記のいずれの観点にも含まれないが、製品としてリリースする際実施するべきか検討することが必要となりうる要素を纏めた観点
大分類のうちの機能は、中分類で以下のように分類されます。
中分類
- 正常系: 仕様通りに動作する確認のための観点
- 異常系: 異常発生時の処理について確認するための観点
- ここでは仕様内 or 仕様外であるかどうかで分類していない
- 組み合わせ: 機能重複や競合について確認するための観点
これらの中分類や機能以外の大分類について、小分類でさらに細分化して分類されていきます。
これとは別にテストタイプというものもあります。テストタイプとは、コンポーネントやシステムを検証するためのテストをまとめたもので、特定のテスト目的に焦点を当てています。抽象度が高く、テストに落とし込む際にテスト観点と組み合わせて使用されます。
上記で考察した製品の各品質について、どのテスト観点、テストタイプが最適かを考え、更にそれらを元として実際のテスト手法を考えます。私達のチームは全てのマスを埋めましたが、テスト観点のマスには大分類を書くのみで妥協しました。その点、B チームは中分類までしっかり考察していたので、やはり敵わないなと思いました。
B チームの考察は抽象化のひとつ先の段階に進んでおり、A チームのものよりもテスト手法の具体化への筋道がしっかりしているように見えました。実際、講師もより深い段階まで考察できていたことを称賛していました。B チームへの対抗心から埋めることを最優先として進行しましたが、埋めることよりもひとつの事柄についてどこまで深く掘り下げられるかのほうが重要だと言うことを痛感しました。巧遅拙速に如かずとは言いますが、完成を急ぎいい加減な仕上がりに甘んじていれば、生涯成長はありません。
総括として、明るい雰囲気で楽しく、全員が全員を尊重して積極的に意見を出しあっていたのが、とても印象的でした。とても充実して楽しい時間を過ごせました。
ここまでが 1 日目の内容となります。
2 日目以降も、同様にグループワークを軸として進行していきます。2 日目からは A、B、C の 3 つのグループに分かれ、私は今回も A チームの所属となりました。A チームの人数は 3 人で、その中には、前日の B チームのリーダーだった S さんの姿もありました。もうひとりは、私達より一足早く入社して既にセキュリティサービス部での業務経験がある M さんです。どちらもとても賢く頼りになる方で、私は足を引っ張ることがないか少し不安でした。
2 日目は前半と後半で内容が分かれています。前半では、ブラックボックステストについてのワークをしました。ブラックボックステストとは、ソフトウェアの内部構造は考慮せず、入力と出力のみに注目してソフトウェアが正常に動作することを確認するテストの総称です。ブラックボックステストには以下のようなものがあります。
ブラックボックステスト
ブラックボックステスト
- 同値分割法
- 境界値分析
- 状態遷移テスト
- デシジョンテーブルテスト
- ペアワイズ法
この内、研修では同値分割法、境界値分析、デシジョンテーブルテストについてのワークを実施しました。
例えば境界値分析であれば、インターネットによる商品販売システムの仕様を元に、販売期間の境界値を見つけます。同値分割法は、パスワード入力システムの仕様をもとに、どのようなパスワードが有効で、どのようなパスワードが無効なのかを洗い出します。デシジョンテーブルであれば、タイマーの各ボタンの仕様を元に、どのような条件下でどのようなボタンが有効なのか、という表を作成します。
これらのワークで得た経験はすぐさま次のワークに活かされることになります。
2 日目後半から 4 日目までは、同じチームで弊社製品の FFRI yarai AMC のテスト仕様書を作成するワークを実施しました。私感ですが、ここからが本研修の本番となります。
テスト仕様書作成
今回の課題では、システムテストを想定するテスト仕様書を作成しました。システムテストとは、機能単位確認が主となるテストで、機能仕様書を元に実施されます。
テスト仕様書の内訳は、デシジョンテーブル、テストデータ、テストケースとなっています。デシジョンテーブルを元に、このデータを入力すれば機能をテストできるというテストデータを考え、テストケースには詳細なテストの手順を記載します。
規模的には、この研修で最大の課題でした。グループで数日をかけてひとつの成果物を作り上げる。いかにもプロジェクト然とした課題に自然と身が入ります。
まずは、デシジョンテーブルを作成しなければなりません。機能仕様書、要件定義書、ポリシーなどを読み、どのような設定状態、入力のパターンがあるのかをすべて洗い出していきます。入力に対するリソース的な制限があるのであれば、それに沿った境界値分析、同値分析をし、表にすべての可能性を書き出していかなければなりません。このデシジョンテーブルの作成にほとんどの時間を費やしました。
最終的に列数は 50 を越え、次はそれらすべてのパターンを網羅するテストデータを考えて記述していきます。それと平行してテストケースも埋めていきましたが、これについては時間が足りず、空欄が目立ってしまいました。
この課題では、基本的にチーム内で通話を繋げっぱなしにして一日中議論していました。個人的に、このワークスタイルはかなり性にあっていると感じました。
通話を繋げた状態にしておくことで突発的な質問ができる、雑談しながら作業ができる、集中して作業しやすいなど、テレワークにも部分的にオフィスの機能をもたせることができます。個人的にとてもオススメです。最近テレワークを始めて気が滅入っている、という方は騙されたと思って導入を検討してみてはいかがでしょうか。通常のオフィスの雰囲気を保つことができるので、メンタルケアとして一役買うことでしょう。オフィスに勤めたことはないので、いい加減なことを言っている可能性も否めませんが。
会議では、私自身も積極的に意見を発信しました。実力で劣る私を蔑ろにせず、きちんと聞き入れて、有用であれば取り入れてくれたので、とても充実した気持ちで作業できました。ときには雑談を交えたりしながら議論を進めていき、この研修を通して同期との交流を深めることができました。1 日目と同様に、講師陣の方々はアドバイスをくれたり、雑談してくれたりするなどして、とても気にかけてくれました。そうした議論の末、チームでひとつの成果物を作りあげるのは、とても達成感があり、楽しかったです。
ここまでが 4 日目までの内容となります。次がいよいよ大詰めです。
振り返り
5 日目は、作成したテスト仕様書をもとに実際にテストを行い、最後に研修の振り返りとしてチームごとに KPT を書きました。
KPT とは「Keep Problem Try」の 3 つからなるフレームワークで、プロジェクト終了後に振り返る際によく用いられます。K・P・T はそれぞれ以下の意味を持ちます。
KPT
- Keep: 良かったこと、今後も続けていくべきこと。
- Problem: 問題点や課題点。
- Try: Problem であがった問題点を改善するために、今後試していくこと。
まず初めに、チームごとに仕様書の概要を発表し、講師がそれを評価します。評価については、とにかく B チームがべた褒めされていた記憶があります。講師をしてこのまま業務で使えるとまで言わしめるだけあり、私から見ても圧倒的に完成度が高く、素直に尊敬の念が湧きました。実際、A チームのテスト仕様書を作成する上で、わずかばかり B チームのそれを参考にすることもありました。しかし、例え B チームに及ばなかったとしても、私としてはチームが全力で走りきった結果なので、とても誇らしく思っています。
評価を終えると、実際に作成した仕様書をもとに、テストを行っていきます。私達は B チームのテスト仕様書をもとにテストを実施し、同様に B チームは C チーム、C チームは私達 A チームの仕様書を元にテストを実施しました。
B チームの仕様書は、あれだけ褒められていたこともあり、ズバ抜けて分かりやすかったです。しかし、やはり実際に使用してみて分かることもたくさんあり、いくら B チームの仕様書と言えども、いくつか指摘するべき点が見つかりました。それらをアウトプットし、B チームにフィードバックを返します。こちらとしては的を射た指摘であると自負しているのですが、心のどこかで何となく申し訳ないという気持ちもありました。
C チームから A チームへの批評は、中々に辛口でした。C チームからは、「仕様書を使用してよかった点はひとつだけで、他の指摘事項はすべて修正すべき点である」というフィードバックが返ってきました。実際に言われて初めて気づくこともあり、自分より頭の良い人を含む数名で会議しても出てこない発想はあるのだなと、当たり前のことですが妙に新鮮な感覚でした。手塩にかけた仕様書が完膚なきまでに否定されたわけですが、これで憤ることはありません。これも明日への糧となります。
指摘事項に対して、なぜそのように実装したのかを考察します。それを終えると、KPT による振り返りを行います。
講師を含めた 4 人で A チームの活動を振り返り、今後試行していくことを見出しました。それらを自らの糧として胸に秘め、本研修はここでお開きとなりました。さようなら A チーム、また会う日まで。
5 日目の内容はここまでとなります。いかがだったでしょうか。少しでも弊社の雰囲気が伝われば幸いと存じます。
研修の感想
チームでの会議を通じて、次々とアイディアが出てきてそれが段々と形になっていく様は、単純に面白く、ワクワクしました。
「自分たちがプロジェクトの核となり、会議を通じて意見をまとめ、各々の努力により成果物の完成を目指す」
これはまさに実際の仕事におけるプロジェクトの様相を呈しています。他の研修でも 2 人制のグループワークはありましたが、3 ～ 4 人の比較的大きな規模・期間でプロジェクトに携わる体験ができるのは、他の研修にない品質保証研修に固有の特徴です。
チームで協力してひとつの成果物を作り上げるのは非常に達成感があります。
学生の皆さんが体験したことのあるもので例えると、文化祭や学祭などが近いでしょうか。クラス一丸となって目標の達成を目指す一体感。ほんの少しの期間ですが、青春が蘇った感覚を覚えました。私は文化祭も学祭も参加したことがないのでなおのこと新鮮で楽しかったです。
新卒が品質保証部に配属されることは基本的にないとのことですが、プロジェクト進行に肌感覚として一番近いのはこの研修なのではないかなと思います。
おそらく他の同期の方々はもう少し技術的な内容の研修の方を好まれると思われますが、私個人としては、一番充実した研修だったと感じました。
さて、名残惜しいですが、そろそろお別れです。この記事を見て少しでも弊社に興味をもってくれる方が増えるのであれば、執筆者冥利につきます。
「就活を始めたばかりで、まだ労働市場の右も左も分からない」。当ブログの読者の中にもそのような方がいらっしゃるかと思います。セキュリティに少しでも興味がある学生の方は、ぜひとも弊社への就職も視野に入れてみてください。悪いようにはいたしません。右も左も分からなかったとしても、闇雲に出した最初の一歩は、きっと前へ進むきっかけになるはずです。
それでは。
FFRIセキュリティの新人研修について
FFRI セキュリティの新人研修にご興味のある方は、こちらの新人研修についての記事一覧もご覧ください。
FFRI セキュリティでは、毎年 4 月から 4 ヶ月間、新入社員を対象に研修を行っており、セキュリティに関して事前知識がなくても、研修中に一通りの知識を身につけられるようになっています。採用に関しては、採用情報を参照ください。
