底辺過ぎてちょっとビビる

26歳からIT業界にいるエンジニアが、まったく成長できてないことを確認するブログ。備忘録的に使いたいとも考えています。

【ゲーム感想】ペルソナ5ロイヤル(ペルソナ5R)をプレイしました

今、日本で一番おもしろいRPGシリーズではないか、と個人的に思っているペルソナシリーズのペルソナ5Rをプレイしました。購入したのは3年前くらいで、当時なぜかストーリーの10月頃に途中でやめてしまっていてしばらく放置していたものを、最初から再開した感じです。大体ストーリーの大筋を知っているとプレイしていても驚きがないので作業的になりがちなんですが、細部はほぼ忘れていたのでストーリーは普通に楽しめました。さすがに3年前の内容は記憶にない...

 

最後までクリアしたので(多分ベストエンディング)、レビューというか感想を書いていきたいのですが、例の如く物語の根幹にせまるようなネタバレは無しの方向で記事を書いていきます。

 

今回は「怪盗」がテーマ

 

オープニングのカジノシーンでいきなりテンションが上がる。BGMになっている「Life will change」のノリの良さも手伝って、「あ、これは面白いゲームなんだ」と印象付ける。主人公と謎のメンバーとのやりとりが緊迫感を煽り、「今どういう状況?」と若干混乱しつつも話は進んでいく。主人公の逃走経路を塞ぐように出てくる敵を蹴散らし、どんどん脱出経路を進んでいくのだけど、最後の最後で思ってもみない結末になってしまうので、さらに混乱する。

 

オープニングからなかなかスリリングなストーリーが展開されて、ペルソナ3とも4とも全く違う匂いを感じる。

 

現実世界を舞台にしたRPGはシンプルに楽しい

今回のストーリーの舞台は、東京都が中心となっていて、馴染みのある街を日常パートで駆け回る。三軒茶屋、渋谷、新宿、原宿、代々木、吉祥寺、中野、浅草...。三軒茶屋は四軒茶屋とか微妙に名称をフィクション設定にしてる場所もあるけど、町並みは現実のそれぞれの街を再現しているので、歩き回るだけで楽しい。

 

3は臨海都市(モデルはお台場ぽい)、4は地方都市(モデルは山梨県のとある街ぽい)でゲーム中では特にはっきりわかるような感じではなかったけど、5はそうではない。渋谷の駅前だけじゃなくて、銀座線やJR山手線などの駅構内とかしぶちかなどのショッピングモール、センター街とかの再現度が非常に高くて、驚いた。

 

センター街入口あたり

完全フィクションのファンタジー世界とかSF世界の街を歩き回るのも面白いんだけど、現実世界を再現している場合って見知った街であると余計に興奮しませんか?

 

個人的には夜に訪れたスカイツリーから眺められる夜景が美しくて、特に良かった。よくデートで使わせてもらいました。hahaha

占い師さんと一緒に

 

現実世界を再現してると、「聖地巡礼」なんていう楽しみも出てくるじゃないですか。三軒茶屋の路地を歩き回って、喫茶ルブラン見つけてみたいですよね。P5Rで追加された吉祥寺も、おまけ的な追加ではなく割としっかり街が再現されててよかった。行列のできるお惣菜屋さんも再現されてましたね。

 

ストーリーに関して

ネタバレになるので、あまり言えないんですけど、なんとなく予想してた部分と予想を裏切られる展開とが入り混じってすごく面白かった。

 

怪盗団結成して世直しを始めていってだんだん世間から認知されていく流れと、世間の評価が上がりきったところで一気に落とされるところ、これはなんとなく予想がついてました。名声が欲しいわけじゃないんだけど、熱に浮かされる怪盗団の幼稚な部分(特に竜二)とか見ててハラハラしてました。実際自分が怪盗団のメンバーだったらどうだっただろう?ニュースやネットで話題になってて評価されていれば、天狗になってたかもしれないな。特に高校生くらいの多感な時期には。

 

話は戻るんですが、最初の頃の佐倉そうじろうに邪険に扱われるの結構プレイしてて心にくるものがあった。暴行罪なんて冤罪なのに、レッテル貼られたらそれを覆すのは本当に大変。しばらく真面目にしてたって、ちょっと道を外れたことしたら「やっぱりこいつは暴行するようなやつなんだ」って評価が戻ってしまう。操作してるだけなのに、こんな感情になるなんて、ちょっとナーバスすぎるかな。マスターとはだんだん関係性が良くなってきて、コーヒーとかカレーとか作り方を教えてもらうようになったりして絆が深まっていくんですが、ある程度まではドキドキしながら会話してた気がする。

 

モルガナに関して

キャラクターボイス大谷育江さんですごくよかったですね

 

モルガナがいたからP5Rはすごく明るかった。彼がいるといないとじゃ大違いだった気がする。というのも怪盗団のメンバーって癖揃いで、ちょっとしたことですぐに喧嘩し出すので!だいたいリュージから始まるんだけど...

 

かっこよくて可愛いモルガナちゃん

 

P5Rプレイの前にカプコンの大神っていうアクションゲームプレイしてたんですが、そこでもイッスンっていう相棒みたいなキャラが登場するんですね。今までずっと一緒にいたのにある事情からイッスンがプレイヤーの前からいなくなるんですけど、それが想像以上に寂しくて。

 

イッスン。虫サイズの大きさ。態度はでかい。

これまでいつもそばにいて、何かとリアクションを取ってくれたりしてくれた存在がいなくなることの寂しさを強く感じたんですが、モルガナもある場面でいなくなるんですけど、すっごく寂しくて。いつだって主人公のカバンにすっぽりハマっていつでもどこでも一緒だったのに。自室にいるときに「明日に備えてもう寝ようぜ」とか何か主人公がアクションとった時なんかのツッコミだったり何でもかんでもリアクションくれたのがモルガナだったわけですが、それが一切なくなるのはほんと空虚だった。

 

怪盗団メンバーについて

まず、メンバー云々の先にアジトというものの存在がよかった。

 

序盤は学校の屋上がいわゆるアジトとして使われるのですが、場所が渋谷駅の通路に移った後、最終的に主人公の居候先の部屋がアジトになって、怪盗団が集まる様子は非常に良かったです。なんか屋根裏部屋の雰囲気も相まって、本当に秘密基地のような感じで。

狭そうに見えて、高校生が7人いてもゆったりしてるのがすごい

怪盗団のメンバーたちについては本当に現代的な高校生って感じでジェネレーションギャップは感じながら、本質は自分達の世代と大きく変わってないのかな、と思いつつ眺めていました。ペルソナ4のメンバーたちに比べると都会で生活している、という違いがありますが、彼らよりもちょっと特殊な家庭環境にあるメンバーが多かったように思います。特に世相を写している感じがしました。

 

両親が揃ってない家庭を持つキャラクターが割といて、それはもう標準なのか?というレベル。いずれ性自認が身体と異なるキャラクターとか出て来そうですね。あんまりそういった要素まで入れなくていいと思ってますが...声のでかいそっち方面の意見は無視してほしいですね。

 

しかし、ペルソナに出てくるキャラクターって設定というか人間性がリアルだと思うんですよね。不良っぽい子も真面目っぽい子もいかにも役割をふられただけのキャラクターじゃなくて、ちゃんと血が通ってる感じがする。長所も短所も混ぜこぜの一人の人間って感じでその一面だけ見てどうこう言いたくない感じ。これは未プレイのペルソナ1女神異聞録とペルソナ2を除いてプレイしてる3から持ってる印象なんですけど。

 

幼稚さ、という意味では登場人物ほぼ高校生で見た目は大人っぽいですが、子供なので当たり前なんですけどね。むしろその幼さは大人なら躊躇しちゃうことにも勢いよく関わっていける。ただ現実の世界の話なので、無茶をしてしまうと警察が関わって来てしまう。そのへんの難しさは現代の日本を舞台にしていることでの面白さだと思います。

 

ネタバレなし、という宣言をした都合上それぞれのキャラクターについて深掘りして話ができないのですが、好きか嫌いかでいうと嫌いなタイプの人間なんですけども途中から加入する「彼」には救われて欲しかった。というのが感想になります。

 

 

システムについて

今作は久々に悪魔会話が復活して、悪魔との会話も楽しめました。序盤は悪魔会話でスカウトした悪魔を育てつつ進めるんですが、1回の戦闘で手に入る経験値は多くないので、よほど集中的に育てるんじゃないと悪魔ってあまり成長しないんですよね。なので、パレスで仲間にした悪魔と同種の悪魔と戦闘を繰り返して、その悪魔自身への経験値をとにかくたくさん積む、ということをずっとやってました。時間がかかってしょうがない...

 

せめて一回の戦闘で仲魔悪魔の全てに経験値が入るようであれば楽だったんですけど、それはアトラスの「長時間プレイしてもらうための施策」だったのかな、と睨んでいます。短時間でプレイされてすぐに中古市場に流れてしまうことを阻止するために、というか。

 

バトルシステムに関しても大変よく練られていたと思います。メガテン3から導入されたウィークポイントを攻撃した際の既存システムはそのままに、怪盗団のチームワークとか絆を端的によく表した「タッチ」による連携システムは非常に面白かった。コマンドRPGのバトルなのに、どんどん攻撃役が切り替わる踊るようなスピーディーさも表現できていると感じます。

 

パレス再突入時も、セーフルームへの直接移動が可能だったのはユーザーフレンドリーでしたね。予告状送付後はパレスの警戒度が限界まで上がるので、即最終セーフルームに移動した後でボス戦に突入するプレイスタイルでした。

 

 

 

全体的な感想

3をプレイした時は3が、4をプレイした時は4が、それぞれベストRPGに感じたのだけど、5Rをプレイした今は3や4を超えて面白いRPGだったと思う。もちろん3や4でそれぞれ5にはないいいところがあるのだけど、システムやグラフィックなどが徐々にブラッシュアップされた結果、最新作が最も面白く感じる。もちろんプレイした人によって感想は異なるだろうが・・・

 

特に5Rは5に追加エピソードがあるので元々ボリュームのあるゲーム内容がさらに厚みを増している。だらだらプレイしてしまうので総プレイ時間が簡単に100時間を超える。コスパ?という意味では非常に高いのがペルソナ5Rなんである。

 

今回クリア段階では関わりを持てるすべてのキャラクターとの相性はマックスまでいきませんでした。なので、本当の意味での完全なベストエンディングを迎えたわけではないんですが、プレイ時間的に「もうそろそろいい加減クリアしていいだろう」という思いが出てきてクリアしちゃいました(ゲームシステム的に日時制限があり思ったタイミイングで相性を上げられるわけではないけど)。

 

グラフィックに関していうと、ある程度の到達点まできた感じは受ける。これ以上リアリティを追求するのであればUNREALエンジンを導入することになるのだろうけど(今もすでに使われている?)、今でもすでにある程度の圧倒感があるので、新作が出たとしても「グラフィックが向上したなぁ」という驚きは少ないかもしれない。

 

4(PSVita)→5(PS3)だったので明らかなハードによる表現できる差が大きかったってのはあったと思うので。6がもし出るとしたら・・・どのハードになるのか今から気になるところです。

 

また、悪魔一人一人にかかる描画コストが大きくなるにつれ、登場できる悪魔数に限界がきているのは気になるところです。3DSメガテン4では数百体〜千体近くの悪魔が登場できましたが、ペルソナの場合、3Dグラフィックで描画せざるを得ない関係上多くのバリエーションを登場させることがコスト的に難しくなってる。登場悪魔もだいたい同じ悪魔で半分くらい固定されている気もする。

 

このへん、なんとも言えないんですが、一部悪魔に関しては刷新してほしいような気持ちが若干あります。どうでしょう?

 

ペルソナ3リローデッドも楽しみではあります

 

 

リーダーに業務知識はいらないのか?

今のチームに新しいメンバーが入ってきた。中途で3名。

 

今のチームリーダーが退職したので、その補充として1名がQAリーダー、2名がメンバー(未来のリーダー候補)として入ってきた。全員年数は違えどQA(テストエンジニア)として経験をしてきているので、基本的なテストの仕組みは把握している。ただ同じ業界ではないので基本的な業務からはシステムを把握してもらわねばならない。

 

そして、チームのメンバー構成的には80%がSESのメンバーという状態。そのメンバーも最低でも2年程度は業務に携わっており、業務知識等で新しいメンバーは敵わない。という状況なので、業務的にもシステム的にもおそらく半年程度は色々なプロジェクトのテストに携わり徐々に知識をつけていってもらえれば良いと私は考えていた(SES的な目線)。

 

実際にリーダー候補以外のメンバーは入社後の研修を終え、それぞれプロジェクトにアサインされて、テストを開始しだしている。自分がこの現場に入った頃よりはシステムは複雑化しているが、その分資料も追加されているし、SESメンバーは経験豊富なので何かわからないことがあれば質問できる環境がある。最初は苦労するかもしれないが、業務知識をつけてくれさえすればこれまで培ったテストの知識を活かしてQAとして活躍してくれると想像している。

 

ところが、新しく入ったQAリーダーは最初に1つプロジェクトにアサインされた後はそれ以降プロジェクトに入ってテスト業務を行なっていない。これまでQAチームのリーダーを歴任したメンバーは全てメンバーからの昇格だったので、業務知識ありきのリーダーだった。なので現時点で業務知識ほぼ皆無のリーダーという状態。

 

他の会社では知らないが、今の現場のリーダーの業務として

  • プロジェクトごとの見積もりレビュー
  • プロジェクトごとのテスト観点レビュー
  • プロジェクトごとのメンバーアサイン考慮
  • プロジェクトごとのテスト報告

 

いずれも業務をある程度把握していないとできない業務ばかり。なので、ある程度はテストメンバーとしてプロジェクトに関わりつつ、業務システムを覚えて欲しいと考えてた。チーム内のミーティングでもそのように進言し、本人も了解していて、アサイン表にもリーダーの名前を入力してはずだった。はずだったが、なぜかプロジェクトのアサイン表からその名前がいつの間にか消えて他のメンバーが入力されていた。

 

ちょうどガチガチに忙しいプロジェクトが終了し、メンバーの各プロジェクトへのアサインに余裕が出たタイミングだった、というのもあるかもしれない。新メンバー含めて10名近くいて、スケジュールに空きのあるSESのメンバーを遊ばせておく必要もないし。

 

ここで思うのは、

新しいリーダーはあくまでもQAチーム管理者でありテスト非実施者という職務なのでは?ということ。しかし、そのような職務で入社したわけではないことはわかっている。つまりメンバーに余裕がない場合、リーダーといえどテストも基本的にはこなしてもらう必要があるのだ。それに入社まもないこの時期、優先的にプロジェクトに関わり業務を覚えておく時期なのでは?とも思う。あくまで個人的な感想になるけども。

 

端的に言えば、メンバーの誰よりも業務知識のないリーダーってあり得るの?という感覚がある。最悪、業務知識なくても良い場合もあると思う。

 

プロジェクトごとの見積もりレビュー

→見積もり工数をガチガチに検討した上でレビューを提出し、リーダーはレビューはせず工数の承認するだけ

 

プロジェクトごとのテスト観点レビュー

→本来レビューではレビューイ(PJのテストリーダー)とレビュアー(QAリーダー)+そのプロジェクトの有識メンバーが参加することでレビューを実施するが、QAリーダは参加するだけとして、基本的に有識メンバーがレビュアーの役割を担う。QAリーダーは一応参加してレビュー内容を聞いておき、何かあればコメントする。

 

プロジェクトごとのメンバーアサイン考慮

→プロジェクトにメンバーをアサインするにはそのメンバーのPJ経験などを考慮するが、リーダー独断で判断できないので常に他のメンバーに相談した上でアサインを決定する。

 

プロジェクトごとのテスト報告

→テスト報告を作成するのはテストリーダーが行い、QAリーダーは出来上がった報告書をチェックするのみ

 

こうすることでQAリーダーに必ずしも業務知識が必要ではなくなる。まあそうなるとQAリーダーって存在意義って何?っていう風にもなるけども。問題は、現QAリーダーは別にQAチームの構造改革を担うような役割を与えられているわけでもなく(以前はそういう人が存在した)、管理業務のみをする職務でもないという。上で書いたような形でQAリーダーとしての業務をすすめるとなると、他のメンバーへの負担が激増する。経営側としてどう考えるのか?と思う。

 

これは私の勝手に想像することだけど、QAリーダーは

テストしたくない

という気持ちが強いんじゃないか。

 

これまでQAとして業務に何年も携わってきて(本人の年齢も40代後半〜50代で、QAチームの平均年齢よりも高い)自分より若いメンバーに混じっていちいちテストするのが嫌なのかな?と想像する。テストしたくないのか、メンバーとして実施するのがなんとなく嫌なのかわからないけど、ミーティングでテストアサインを進言した時の反応からなんとなく感じる。「他にいないならしょうがないですね...」という反応。もし自分が同じ立場なら率先してプロジェクトに入って、テストに携わって業務を覚えたい!と感じるけど、そういう感覚ではなさそう。

 

いずれ同じタイミングで中途入社した他の2名より業務知識に遅れをとるのでは?という懸念がある。自分はSESだから別にいいけど、会社的の組織としてどうなんだ?という気持ち。

 

大体業務に疎いリーダーがいる組織、プロジェクトは炎上しがちな経験上、あまり好ましくない状態なのでは?と感じている。

 

 

 

経験は長いのに自分の中に芯とか幹となるものがない

エンジニア経験と今のQAエンジニア経験を合わせれば、およそ20年近くになる。エンジニア経験の方が割合は多いのだけど、まず開発の方は全く出来てない。最初の経歴はC言語からスタートでした。ベーシックな知識は身についたもののどうやってコーディングすれば仕様に沿えるものが出来上がるのか、イメージが全然出来ない上にコーディング能力は向上しないまま。そこからオブジェクト指向言語C#だったり、厳密には違うのかもしれないがC++だったり開発エンジニアとして関わることはあったものの、どの現場に行っても戦力になれないまま短期間で現場退場を繰り返しです。時にはあまりの自分の仕事の出来なさに鬱っぽくなることもありました。

 

経歴年数だけはほどほどにあったけど、自分の中にプログラマーとして芯になるものは全く出来上がってなかったのである...プログラミング的な発想力とか発想できたものをコードとして実現する能力が足りてなかった。仕様書を読み取る能力もなかったと思います。

 

そして現在のQAエンジニアという職業。エンジニアとついてるけど、コーディングは一切ないのでエンジニアと自称していいのかわからない。単にQAと言った方がいいかも。まぁ職業名はこの際あんまり関係ないからあまり触れずに。

 

QAとして本格的に業務をしたのは、今の現場から。それまでプログラマ時代もテストフェーズに関わったことはあったけど、品質保証という立場でテストに関わることは最初だったので、最初は戸惑った。実際にQAとしてやってることはブラックボックスでのシステムテストとシナリオテスト。おそらく会社や組織によって業務内容は異なってくるのかな?と思いますけど、今の現場は基本テストのみです。

 

このQAという仕事は、プログラマに比べたらまだ現場の役に立てているようです。なぜなら3年くらい経ちますが、いまだに「もう結構なので退場してください」という戦力外通告を受けてないからです。ただ、自分自身の中では「QAとはこういうこと」という指針になるものが特にないのが気になっています。テスト手法とかもあまり詳しくないし(ブラックボックステストの代表的なテスト手法である、境界値テストとか同値分割テストくらいしか普段のテスト設計に組み込んでない)。

 

何が言いたいか、というと現場の作法に慣れすぎていて普遍的なQA的能力は在籍年数の割に上がっていないんじゃないか、ということ。プログラミングであれば、現場ごとにコーディングルールなどのローカルルールはあるだろうけど、基本的にコーディングすること自体はやることは一緒なわけで。プログラムと同様に、QAにおいてもローカルルールはあるけど、基本的なQA指針というか「QAの基本確認点」のようなものがあるはず。

 

書いていて気づいたけど、基本確認点っていわゆるテスト7原則なのかな。

  • 「テストは欠陥があることしか示せない」
  • 「全数テストは不可能」
  • 「初期テストが重要」
  • 「欠陥の偏在」
  • 「殺虫剤のパラドックス
  • 「テストは条件次第」
  • 「バグゼロ」の落とし穴」

 

 

うーん...ちょっと違う。この原則自体は大事で頭の中になきゃダメだけど。こういうものではなく、WEBテストであれば、こういうものを確認するのが鉄則、というようなもの。たとえテストをする環境が変わったとしても、揺るぎないものが自分の中に欲しい。どこに行ったって必ず確認する項目って大きく変わらないと思うので、そういう部分をしっかりとしておきたい。WEBっていっても幅広いからなんとも言えないんですけども...

 

同じ環境でずっと仕事するならその環境に自身が最適化されていれば、良いと思う。でも自分のようにSESでいろんな環境に身を寄せて(この表現でいいのか?)仕事をするなら「これはQAとして基本」みたいな当たり前が欲しい。情けないな。しかし。

 

当たり前がある状態ってどういうことかというと、たとえ空っぽのQAチームに放り込まれたとしてもそこから状態を0から1以上に構築できるような人材。

 

 

コミュニケーション能力を勘違いしている

友人などと会話するときによく喋る自分は、コミュニケーション能力が高い方だと思っていた。いわゆるSES面談でもよほど案件内容と過去実績の乖離がない限り、お断りされたことがなかったのでコミュニケーション能力があると思い込んでいた。技術的な経歴でよほどアンマッチでなければ、あとはコミュニケーション能力に難ありと判断されて面談でお断りされる、とかあると聞いたので。

 

会話は普通に出来る、ユーモアを交えた会話も出来る、老若男女の違いなくスムーズに会話出来る、つまりコミュニケーション能力がある、と思い込んでいたけど、最近自分には「本当の意味」でのコミュニケーション能力は足りてないのでは?と感じる。

 

  • 親しい友人間で普通にユーモアを交えた会話をする
  • 親しくない関係の人と雑談をする

 

これは比較的社会人とかは関係ない一般的にベーシックな能力で、ある程度の社会人経験があれば誰でも持ってるいる能力だということに最近やっと気づいた。自分はこの能力を「コミュニケーション能力」だと思っていたが、それは違うのでは?と感じている。ではコミュニケーション能力って何?ということになるが、以下のようなことだと思っている。

 

  1. 言わなくていいことを言わない
  2. 相手にものごとを正しく伝える
  3. 言い方(言葉のトーン)を適切に行う

 

 

言わなくていいことを言わない

おしゃべりが好きな自分のようなタイプは、発言することそれ自体に価値があると思いがちなので、つい喋り過ぎてしまうことがある。発言の中で本当に必要なことは多くなくて、余計な情報を話してしまうことで会話(情報の伝達)の中の本質がぼやけることが多い気がする。相手が「結局何を伝えたかったのか?」となってしまってはコミュニケーションの失敗だと思う。沈黙は金、雄弁は銀という言葉があるが場合によっては喋らないことも必要だと思う。しかし、ミーティング等で「何か喋らなくては」という強迫観念のようなものがある自分にとっては大変厳しい。

 

 

相手にものごとを正しく伝える

特に自分の場合「相手にものごとを正しく伝える」能力が低い気がする。文章でも口頭でも複雑な内容を正しく相手に伝える能力が足りていないと思う。思ったことをなんとなくで伝えようとすると、情報が不足していたりして正しく情報が伝達されないことが多い気がする。あと、だいたいこういう場合は「自分が伝えようとしていることそれ自体をきちんと理解していない」ことも多いような。

 

 

言い方(言葉のトーン)を適切に行う

比較的自分は相手に対する言葉のトーンは抑えめというか、穏やかに会話しているつもりだけど、人によって「正論なのだから強めに言っても仕方ないよね」と考えてるのか、言われた相手が傷つくことも気にしない人がたまにいる。言われた側は傷つくし不愉快になるのでコミュニケーションとしては良くないと感じる。明らかなミスに対する指摘だとしてもミスを繰り返させないためのアドバイスなら高圧的に言わなくても伝わるので、正しい言葉のトーンを選択していきたい。

 

 

自分自身を振り返ってみるしかない

よくエンジニアは会話下手でコミュニケーション能力がなくても良い、みたいな風潮があるが、むしろエンジニアの方が複雑な仕様把握などでしっかりしたコミュニケーションが必要。ちなみに今の現場で一緒に仕事している優秀なエンジニアの人は、確かに会話下手なのかもしれないが、理路整然としたレンスポンスよく会話してくれることが多いので仕事がしやすい。

 

自分にコミュニケーション能力があると誤解して、実はあまり能力が足りてない人は、実は相手に負担をかけていることを認識した方がよい。会社で仕事をしていると面と向かってコミュニケーション能力についてアドバイスをしてくれる機会はほぼないので、自分で気づくしかない。

 

自分が伝えたいことがきちんと伝わってないように感じることが多いとか、人より妙に無駄な会話をしてしまっているとか、急に相手との関係性がギクシャクし出したとか、何かしらのアラームが鳴った時は、普段の自分のコミュニケーションを振り返ってみては?

 

もしその気づきでコミュニケーション能力が高まるとしたら、より1段階優秀なビジネスマンとして成長できると思うので。

リリースが頻繁に早いペースで行われるプロダクトにおける、テスト設計とテスト実施の考え方

今まで関わってきたプロジェクトはだいたい年単位でスケジュールが組まれているのが普通で、その中でもテストフェーズ(統合テスト・システムテスト)は3ヶ月から6ヶ月程度の期間が取られること多かった。現在のSES先企業ではすでに稼働中のWebサービスがあり、そのサービスの機能追加だったり不要な機能を削除したりと日々何かしら動きがある。

 

過去のプロジェクトと今関わってるプロジェクトの違いはこんな感じである

 

今まで

  • 設計書が豊富に揃っている(画面仕様書やDB設計書など)
  • 期間が長い
  • テスト仕様書/設計に対するレビューがかっちりしている

 

現在

  • 設計書が揃っていない
  • 期間が短い
  • テスト仕様書/設計レビューがゆるい

 

テスト設計をしていてテストケース作成時に特に困るのが「設計書が揃っていない」ことである。揃っていないというか、一応機能仕様書はあるのだけど画面遷移図やステータスの状態遷移図がないので、前提となる状態とその後の期待値がはっきりしないというがある。

 

ではそんな状態でどのようにパフォーマンスを出せばいいのだろうか?優先的に行いたいものは、「仕様の凍結(フリーズ)」と「完成したシステムに対するスモークテストの実施」の2つだと思う。

 

仕様の凍結(フリーズ)

システム改修、システム追加などのプロジェクトにおけるキックオフで概要などの説明があり(キックオフ自体がないかも)、その場で色々と質疑応答があると思うけれど、まずは現段階で仕様の凍結を依頼しておきたい。

 

明らかな仕様の誤り(システム的な矛盾、不要な要素を除く)などは改修対象として良いと思うが(テストの無駄なので)、思いつきで追加されるような機能がないことを前提としてテストの設計をしたいため、仕様の凍結はマストだと思う。ただでさえ設計期間も短いのだから何かあるたびに機能を追加されていたらキリがない。

 

そういった機能追加要望については、リリース後のアップデートでの対応でまかなう方が良い。まずはリリースしてしまおう。

 

ただし、機能改修の中でも「機能の削除」は歓迎したいところだ。しかし単に機能削除と言っても他機能と結合状態が強い場合その点を考慮が必要なので、削除される機能は独立した機能が望ましいと思う。

 

 

完成したシステムに対するスモークテストの実施

これはテストチームがテスト設計を終えて、いざテスト開始となる前に、「そもそもシステム自体はきちんと動作するか」を確認する作業。システムの頭からお尻までを一回通して動かしてみて、システムの機能がきちんと動いているかどうかをみるためのもの。

 

スモークテストを実施していないときに(ままある)、テストを開始したもののシステムの根本となる機能が正常に動いていないことが判明し、テストストップとなったことがごくたまに起きていた。テストがストップしている期間、一旦スタートしたテストのために確保した人員リソースの解放も難しく、スケジュールがぐちゃぐちゃになってしまう。

 

一度テスト開始前にスモークテストさえしておけば、そこで不具合が見つかった場合に「テスト開始期間を後ろ倒しに」という形で対処ができるため、テストが途中でストップになった場合に比べてスケジュール調整が容易になる。

 

じゃあ、そのスモークテストとやらは「誰がやるのか」という部分がありますが、優先すべきは開発者じゃないでしょうか。他にはPMなどもいると思いますし、場合によってはテスト担当者でもいいと思います。ただ、テスト担当者の場合、テスト実施に工数は確保していると思いますが、テスト前のスモークテストにまで工数は確保していないはずなので、追加の工数が必要になります。

 

 

以上の2つがテスト実施に関して優先すべき事項だと思っています。では、テスト設計に関してはどうでしょうか。テスト設計に関しては1つの記事でぺろっと解説となると範囲が非常に広く、深くなってしまうため既存機能のテストに絞ってみたいと思います。

 

 

過去のテスト資源を再利用しよう

テスト設計に関していうと、既存機能の確認テストはなるべく設計を行わず、過去のテスト資源を再利用するべき、というのがあります。

 

ちなみにちょっと話がズレますが、このエントリーを読まれているテスト担当者の方のテストの現場はどのようなテスト設計環境にありますか?Excelベースのドキュメントを使ったテスト設計の環境でしょうか?それとも何かのテストケース管理ツールを運用している環境でしょうか?

 

私はこれまでExcelベース管理のテスト設計現場も経験ありますし、テスト管理ツールを運用している現場も両方あります。なので、どちらのいい面、悪い面もわかってるつもりですが、比べた時にはやはりテスト管理ツールを運用する方が「楽」と感じます。

 

いつ、誰が、テスト結果をNGにしたか、OKにしたか、そしてテスト全体がどの程度進んでいるのかという情報がすぐにわかるのがテスト管理ツールです。特に「テスト結果がNGだった場合」にいろいろな情報をテスト結果に記述する必要が出てきますが、その点でExcelシートだと記述スペースにも限界があります。(Excelのセルに書こうと思えば書けるがセルの表示範囲を超えるといちいちセルにカーソルを合わせないと全体が読めない)

 

テスト管理ツールであれば、そういった情報を一つのテストケースにわかりやすくまとめることが可能なので、後から見た時に見やすい。

 

また冒頭の話に戻りますが、既存機能を再利用したいとなったときにExcelでシートをコピーして使うというのも案外面倒な部分です。細かくシートが機能単位で整理されていれば良いですが、大体そうはなっておらず「どこからどこまでが再利用対象の機能のテスト?」と判断に迷うこともしばしば。「探すのが大変なので、だったら最初から作り直した方が良い」というふうになってしまうこともあったりします。

 

テスト管理ツールなら(ただの物置のように管理されているのでなければ)、再利用対象機能だけを抽出して再テストすることが容易です。

 

Excelベースからテスト管理ツールへの移行しようとすると、最初は「戸惑い、手間、ツールの機能の理解が必要」などの導入障壁があるのでゼロコストとは言いませんが(実際無料で使えるものも多くはない)、導入後が非常に快適なので、まだExcelでやっているのであればツール導入を強くお勧めします。

 

こんな記事があったので、リンクしておきます

 

以上、頻繁にリリースされるプロダクトの現場でテストする人の参考になればと思います。