【ゲーム感想】探偵神宮寺三郎 プリズム・オブ・アイズをプレイしました

たまたま寄ったゲームショップで「神宮寺三郎」の文字を見かけて、まさか新作がPS4で出てるなんて知らなかったのでびっくりしましたが、すぐに購入しました。

探偵 神宮寺三郎 プリズム・オブ・アイズ | ARC SYSTEM WORKS

自分と神宮寺三郎との出会いは割と古くて、ファミコンの「横浜港連続殺人事件」が最初でした。アドベンチャーゲーム自体に触れることは多くなかったのですが、神宮寺三郎シリーズを始め、オホーツクに消ゆなどの「現実の世界を舞台にしたゲーム」というのはリアリティがあって妙に興奮したのを覚えています。神宮寺三郎シリーズをきっかけにアドベンチャーゲームって面白いなぁという認識になっていたと思います。

パッケージからしてハードボイルド小説みたいで素晴らしい

しかし、当時のファミコンのアドベンチャーはコマンド総当たりシステム（すべてのコマンドをとりあえず試さないとだめ）かつフラグ立てが難しくて、結局「横浜港～」は未クリアだったんですね。

クリアできなかったものの、「ハードボイルドな神宮寺の雰囲気」「御苑洋子の大人のムード」そして「タバコ」というパーツは子供心に強烈な印象を残していました。その後いくつか神宮寺シリーズは出ましたが、開発元のデータイーストの倒産などあり色々なデベロッパーから発売されることになりました。

「クロス探偵物語」で有名なワークジャム、ワークジャムが倒産したあとは「アークシステムワークス」で、今作の「プリズムオブアイズ」はアークシステムワークスからの発売です。

プリズムオブアイズとは？

今作は実は一本のソフトではないです。買ってから気づいたのですが、過去に発売された携帯アプリゲームから10作と新作3作、次回作「ダイダロス：ジ・アウェイクニング・オブ・ゴールデンジャズ（タイトルなげ～）」の体験版が入ってるのです。

※が新作

1. 時の過ぎゆくままに…
2. 6枚の犯行
3. 亡煙を捜せ!
4. アオイメノリュウ
5. イヌと呼ばれた男
6. ふた色の少女
7. 託された指輪
8. 椿のゆくえ
9. 果断の一手
10. 連鎖する呪い
11. 虚飾ノ夜※
12. 死者に捧げる石※
13. 魔鏡の真実※
14. 新作の体験版※

自分自身では「神宮寺三郎シリーズのファン」を自負していましたが、上記のアプリはひとつもプレイしてなかったです。「時の過ぎゆくままに...」は元々ファミコンで発売されていたようですが、それすら知らなかったです。ははは...

プレイした感想

過去作のリメイク10作、ということですがひとつもプレイしてないので単純に新作13作を遊べるということですごいボリュームです。一つ一つの話はおそらく2～3時間程度で終わるような感じなのですが。難易度自体も非常に低くて、適当に選択していれば解決できてしまう感じです。というのも事件現場を調査するようなシーンでも、自由に調査するような仕組みではなくてオブジェクトを選択するだけなので、「見落とし」となるようなことがないからです。

なので、ゲームと言うよりはノベルにちょっと寄ってる感じでしょうか。あまりプレイヤーが捜査に入り込むようなポイントはない感じです。途中で思考パズル的なものもいくつかありますが、それも回答は選択式なので、考えなくても解けるようになっています。元のアプリゲー自体のボリュームやシステムを知らないのでリメイクに際してどの程度の移植度なのかがわからないのですが、難易度はもうちょっとなんとかならなかったかな？という感じです。

ただ、シナリオ自体は非常に洗練されていて、キャラクター性もまったく損なわれておらず、またBGMも素晴らしくゲームとしての難易度は低いかもしれませんが、全体として「神宮寺三郎シリーズ」を久々にプレイした自分からすると満足できる内容でした。

今のところ4作ほどプレイしましたが、切ない話が多くてとてもいいです。

ちなみに最初は画面カーソルを合わせてもコマンドの色が変わらずに、どこを選択してるのかよくわからなかったのですが、その後のアプデで色が変わるようになったのは良かったです。

今後このような形で過去作をリメイクしてくれるととても嬉しいですね。というのもDSや携帯アプリなどで発売された過去作はまったくプレイできていないので。

探偵 神宮寺三郎 プリズム・オブ・アイズ - PS4

探偵 神宮寺三郎 プリズム・オブ・アイズ - Switch

探偵 神宮寺三郎 新宿の亡霊 上

探偵 神宮寺三郎 新宿の亡霊 下

【反省会】はじめてリーダーになって思ったこと

7月から大手電機メーカーのSIer部門でプロジェクトに参画して、はじめてテストチームのリーダーとして業務に携わった。テストチームといっても小規模で、自分の配下には2名のテスターがいるだけ。総勢3名なので大したことないのだけども、経験したことを振り返ろうと思う。

関わったテストというのは「機能の起動状況管理」というもので、全体の結合テストで実施される各フェーズ（例：性能テスト）において、すべての機能（ここでは更に分割されたプログラムと言ってもいい）が実行されているかどうかをチェックする、というもの。

なので、自分のテストチーム単体ではなにかテストをするというわけではなく、他のテストチームから受け取ったテストログをもとに「正常起動している」「起動はしているが、正常かどうか判別つかない」「起動しているが、エラーを吐いている」「起動していない」をチェックする。正直、存在意義がよくわからないが「二重チェック」という意味で必要だったのだろう。他のテストチームも「あそこはなにやってんだ？」という感じだったと思う。

①テスト計画書の読み込みが甘かった

最初はプロジェクト全体の概要を知るために「テスト計画書」を提示された。これを読むことで、どんなテストをいつまでに、どのようにテストをするかを把握できる。テスト計画書を読み、ある程度頭に入っていたものの、細かい部分まで認識出来ていなかった。そのため、手戻りが発生してしまったことがあった。

②管理の抜けや漏れが多く、全体的に甘かった

2名のテスターの日々の進捗を管理表をもとに管理していた。管理表のベースはすでに作成されていたもので、手を入れることはなかった。管理表はテスト仕様書と同じもので、いわゆるWBSは作成していなかった（必要がなかった）。

当初、というかテスト実施から2ヶ月経過した時点までは管理表ベースの管理でも問題なかった。日々の進捗は割と順調で曲線はほぼ右肩上がりを描いており、このまま順調に進むものと考えられた。しかし、ある日を境にまったく消化が進まない事態に陥ってしまった。これの原因はテストチームから受け取るテストログで確認できる機能（プログラム）が既存のものばかりになってきたせいだった。

WBSくらいはせめて作っておくべきだった。

③管理表の数字に対する甘さ

これは日々の進捗報告であまり詰められることがなかったことで、シビアに管理してなかったことも原因だが、複数存在するテスト仕様書の管理上の数字（消化件数など）が一致していなかったり、そもそもの管理上の数字を「どのように算出したか」がフワフワしていたのは、何考えて管理してたのだろう？と自問自答している。

④状況把握がきちんと出来ていなかった

テストの消化状況が鈍化してくるにあたって、どのように解決すべきかの方法がよくわからなかった。あくまでこちらはテストログを受け取って、その内容を評価するだけに過ぎないので「この機能が確認できないので、テストを実施してください」とテストチームに進言していいのかすらわからなかった。そもそもテストチームはシナリオに従ってテストを進めているわけで、全部の機能を網羅できているかどうかこちらでは判断つかなかったわけだが。

問題は、機能がすべて評価対象になるわけではなく、そのうちのある程度の機能が「使われていない機能だった」ということ。つまり何度テストログを評価しても使われていない機能は「ログ」に出てこない。

この件については、うちのテストチームで管理が甘かったせいというわけではないが、テスト消化が鈍化してきた段階で「アラーム」を上げる必要があっただろう。その段階というのは「いつ」だったか。

⑤対象機能に関連性を見出す、もしくは資料の精度を上げることをしてなかった。

テストログを検証していて「いつまでたっても検出できない機能」はなにかしら規則性があったはずだが、近視眼的にテスト消化を管理していたので、まったくそのあたりの意識が薄く、「いつか確認できるだろう」と高をくくっていた。

なにかアクションをする際は、自分からではなくプロパーの社員（自分の上にいて、総合的に管理してくれていた）から「状況を○○さんに確認してみてください」というような指示があった。彼からの指示がなければ何も出来なかった。

進捗状況を管理する、という基本的な認識があれば管理のために必要なドキュメントの整理も出来たはず。また、関連部署と人が「どんな部署か」「何をやってる人なのか」をきちんと把握できていれば、少なくとも協力を仰ぐことももっと早く出来たのではないか。いつまでもガキの使いのように言われたことをやるだけではダメだった...

上記のことを振り返ると、リーダーとしてなにか成せたのか？と思うことばかりだ。テスターからの進捗管理は別にリーダーでないと出来ない類の仕事ではない。与えられた立場に浮ついて、やるべきことを認識できていなかった。

一応経歴上、メンバーとかサブリーダーではなく、リーダーとして仕事をしたことにはなるが「もっと早くリーダー、というか管理系の仕事をすべきだった」と思わずにはいられない。何をするにもビビりが最初に入り、できっこないとやる前から失敗ばかり考えていたからな...

体系的にプロジェクトマネジメントを学ぶ必要があると思った次第です。

中間管理録トネガワ（１） (ヤングマガジンコミックス)

マンガでわかる! 幼稚園児でもできた!! タスク管理超入門 impress QuickBooks

オレたちバブル入行組

ユーザー要件を正しく実装へつなぐシステム設計のセオリー

担当になったら知っておきたい「プロジェクトマネジメント」実践講座

まんがでわかるLinux　シス管系女子（日経BP Next ICT選書）

【XAMPP】メール送信に失敗する【mb_send_mail】

XAMPP環境でメール送信を実行するアプリケーションを作成してみた。

現在の参考書籍はこれです。読み物としても面白い...

Head First PHP & MySQL ―頭とからだで覚えるWebアプリケーション開発の基本

そもそも、XAMPP環境（というかPHPで）メール送信をするにはどんな事が必要か？というのをまとめようと思ったけれども、検索すれば死ぬほど出てくるしわざわざ改めて書き出すのも無駄な気がしてきたので、リンク先の力をお借りすることにする。

今回、メールはGmailを利用することにする。他のメール（例えばYahooメールなど）の場合はiniファイルの設定値を同じように変更するだけなので、調べれば出てくるはず。

①php.iniを以下のように編集（元になるiniファイルはバックアップをとっておく）

[mail function]
; 下記の設定はそのままでよい。
SMTP=localhost
smtp_port=25

; sendmail_path を下記の値にする。
; sendmail_path の項目が存在しなければ、
; [mail function] の章内に作成する。
sendmail_path = "\"C:\xampp\sendmail\sendmail.exe\" -t"

②sendmailフォルダ直下のsendmail.iniを以下のように編集

（同様にバックアップをとっておく）

; 下記の値にする
smtp_server=smtp.gmail.com

smtp_port=587

auth_username=(Googleのメールアドレス)
auth_password=(Googleのパスワード)

③また、「セキュリティ」の問題でメールがブロックされることを阻止するため、以下のようにアカウントの設定を変更しておく。

メール送信に使いたいGoogleアカウントでログインし、下記のページを開きます。

https://myaccount.google.com/lesssecureapps

そして、「安全性の低いアプリの許可」を有効に変更しておく。

④送信テスト用のコードを書く

<?php
$from = '(送信元のメールアドレス)';
$to = '(送信先のメールアドレス)';
$subject = '件名: テスト送信';
$message = <<< EOF
{$from}より。

こんにちは。
これはテスト送信です。
EOF;

if (mb_send_mail($to, $subject, $message, "From: {$from}")) {
echo '送信成功。';
} else {
echo '送信失敗。<br>エラーログを確認してください。 (xampp\sendmail\error.log)';
}

⑤これでローカル環境でメール送信するための準備が整ったので、あとはコードを実行すればメールが送信されるはず。

⑥ここで自分の場合、PHPを実行すると以下のようなエラーログが吐かれていた。

18/09/30 22:59:00 : Socket Error # 11001<EOL>Host not found.

調べても何もわからなかったので、非常に困ったがsendmail.iniの以下の箇所へのタイポ（いわゆるタイプミス・誤植）が原因だった...

smtp_server=smtp.gmail.com ←ここをなにか別の文字列で設定していた

しょうもないタイポで何度も色んなサイトで原因を探ってしまい、無駄な時間を消費してしまったというエントリーでした。

PHP5徹底攻略 エキスパート編

PHP5徹底攻略

初めてのPHP5

WordPress プラグイン＆WebAPI 活用ガイドブック [Version 3.x対応]

基礎からのMySQL 改訂版 基礎からシリーズ

【みんなどうしているのか】フリーランスの単価交渉

技術（力）もないのにフリーランスでシステムエンジニアやってるわけですが...

技術力がないので、案件紹介で気になるのは「単価」よりも「業務内容」の方なのでタイトルほど単価は気にしない（出来ない）ほうです。過去の言語経験や業務経験から遡って対応できそう、というものを間に入ってる営業会社からチョイスしてもらってそこから案件を選択してます。最近はもうしばらく実装から離れているので、もっぱらテスト設計の案件に入れるようにしてますが、技術力の低下に拍車がかかってる気がしてなりません。

閑話休題、最初に「Nヶ月更新」という条件で案件に入ったあと、「延長依頼」がきてそのプロジェクトを継続するか悩んでる場合に「仕事の内容はまぁいいとして、単価上げてくれないかな～」って思う場面ないでしょうか？

リーマンショックのときに、どこも単価がアホみたいに下がった上に要求経験は天井知らずという状況がありました。その時は「どこも不況だし、この単価でもしょうがないかな～」と納得していましたが、今は状況が違います。当時の日経平均は１万円台で、底では7000円台にもなっていました。今は、日経平均2万円台と回復してます。企業の業績も上がっていて、いい加減企業の言うとおりの単価で納得してる場合じゃない、と思います。

ところが、「エンジニア　単価交渉」などのキーワードで検索してもあまり強気になれなそうなページばかりひっかかります。曰く、「1年は状況をみて、それから初めて単価交渉できる～」「単価交渉はそのプロジェクトでどれだけ貢献出来たか、改善できたかがなければするべきではない～」など。

あくまで技術者は顧客企業の下請け、というのを肝に銘じるべき、というような言説が並びます。たしかに仕事をもらっている立場であることには事実なわけですが、単価交渉するにも1年も時間が必要とは正直ショックです。

というのも今入ってるプロジェクトは6月からなので大体3ヶ月。いいタイミングだと思ったので「5%くらいの単価上昇をお願いしようかな」と考えていたからです。単価50万なら25000円、60万なら30000円、70万なら35000円です。プロジェクト全体で予算は決まっているだろうから、いきなり単価の上昇をお願いするのは難しいかもしれませんが、受け入れ先からすればいつでも切ろうと思えば切れる状況でエンジニアの立場はとても弱いです。なので、稼げるときに稼ぎたいと考えるのは普通に思えるのですが...

そもそも「3ヶ月単位で更新」であればまだいいほうで、「1ヶ月更新」とかけっこうザラなわけです。企業側が「1ヶ月単位で更新」という綱を握っているなら、こっちは「1ヶ月単位で単価交渉するぞ」というほうが健全なのではないでしょうか？

• 1ヶ月毎に単価交渉も大変なので、企業側が「3ヶ月、6ヶ月」と最初から契約期間をある程度定める。
• エンジニア側は「最低3ヶ月、6ヶ月と仕事が確保される安心感を得る（その期間は当然単価交渉はない）」

というWIN-WINな関係が見えてくると思うのですが。

エンジニアの単価は平均1人月100万と言われていますが（あるテスト系でシェアを伸ばしている企業は1人月150万でプロジェクトに入れていました）、実際そこからエンジニア個人に降りてくる金額は考えられないほど低いです。1次請け、2次請けなどが間に入りよくわからない形でお金が搾取されているからです。SIer業界では有名な話ですが。

何もしてない間に入ってる人売りSIerに美味い汁を吸わせてる場合じゃないです。

（ちなみに今回の延長話では、とりあえず現状維持で契約延長ということにしました。ヘタレですね....)

ソフトウェア見積り　人月の暗黙知を解き明かす

従業員50人未満の受託常駐型ソフトハウスの経営者が会社を成長させるために知っておくべきこと The principles of executive.

人月の神話【新装版】

人月の神話―狼人間を撃つ銀の弾はない (Professional computing series (別巻3))

ソフトウェア開発はなぜ難しいのか ~「人月の神話」を超えて (技評SE選書)

初めてチームリーダーになって思ったこと

今あるプロジェクトのテストチームのリーダーとして日々業務をこなしている。

最初の業務面談では「テスター」の業務内容を説明されて、まったくやる気が出なかったので一通り説明を聞いて断ろうと思っていたが、先方が「自分の経歴から鑑みてテスターではなく、テストチームのリーダーとして参画して欲しい」とのことだったので悩んだすえ参画することを決めた。なんで悩んだかといえばリーダーとして業務に関わったことがなかったからだ。ただ、業界経験年数もある程度重ねた中で今後もずっと「いちメンバー」としてしかやったことがないというのもヤバイと常々思っていたし、いわゆる開発（実装）ではないし、そこまでハードルが高い事ではないと考え、決断した。

↓　こんな感じで悩んでた

starscream.hatenablog.com

テストチームメンバーはおそらく自分より少し上のおじさんと10歳位下っぽい男性の二人ということがわかった。彼らは自分より少し先にプロジェクトに参画しており、先にテスト業務を進めていた。そして自分の上にプロパーの社員が一人おり彼がある程度自分の業務を見てくれている。そういうわけで、完全に独立したチームのリーダーではない。プロパー社員になにかあれば聞きに行くスタンスなので、甘えまくっている。

リーダーとしての仕事

テスト業務の進捗管理が主な仕事。テスト、といってもなにかデータを用意して画面操作した結果のエビデンスを取るとかバッチを起動してDBのログを確認するとかそういうのではなく、他のテストチームで実行した結果のログを検証するテストだ。

今のプロジェクトでは大体50個前後のテストが走っていて（まだ環境整備などで走っていないところもあるが）、それらのテストで実行される処理群がすべて実行されているかを検証するテストといった感じ。なので、特別なスキルは不要で日々実行された結果のテストログを確認できていれば良い。

そして自分はそのテストログの確認作業がどれだけ日々進んだかをExcelで積み上げて報告する。ログの確認なので、テストの実施状況に左右されるため日々のログは実は必ず格納されるとは限らず思ったように積み上げが進まないのが難点で、すでにテスト終了予定日は1ヶ月も遅れることが確定している。

それと進捗とは別に報告書というのを作成する。だいたいメインとなるその2つがテストチームリーダーとしての仕事である！薄い！本来ならログ確認用のツールなんかも作るのだろうが、すでに作られていてやることがなかった。

リーダーとメンバーの関係

テストチームのメンバーの二人とはメンバーとリーダーということで立場が違うが、業務的な立ち位置が違うだけで実はほぼ同じレベルにあると思っている。これがプロパーと非プロパーなら会社的な客と発注側ということで上下関係も出来るのだろうが、今回のテストチーム内の人間関係でいえば完全にフラットな状態だ。ただ、そう思ってるのは自分だけで、メンバーの二人からすれば「もっとリーダーらしいことしてくれよ」と思っているのかも知れない。

一応毎日何かしら業務の進め方や思ったことなどを会話できていて、関係性は良好だと思っている。テスト業務の難度がもう少し高ければ「どうやってテストをするか」などの話し合いも出来ただろうが、易しすぎる（ひたすら機械のようにログを確認するだけ）のでその辺のやりとりはない。毎日同じ作業の繰り返しなので、モチベーションの維持のほうが心配だ。

リーダーとして

初めてリーダーとして業務をして思ったのはスケジュール管理だけなら本当に簡単だな、ということ。日々上がってくる進捗に対して「進んでる、遅れてる」と判断して、遅れてるならどうやってリカバリするかを考えるだけで良い。そのリカバリ方法も「もうちょっとペース上げて」くらいの事をいうだけ。質問されて答えられないことがあればプロパーに質問をあげるだけなので、プロパーのほうがリーダーとしてふさわしいのでは？という気持ちがいっぱいである。（おそらくプロパーの業務が手一杯なので、進捗管理を外部委託するという役割で自分がいるのだろうと思う）

本当のリーダー業務とは違うなぁと思っている。本来ならどのように業務をするか、どの業務を割り振るかを考えたり、何かあれば相談にのるのがリーダーだろうと思う。今やってるのは名ばかりリーダーだ。ただ、まぁ業務的に出来ることがこの辺なので今後の糧としたい。

マンガでわかる! 幼稚園児でもできた!! タスク管理超入門 impress QuickBooks

中間管理録トネガワ（７） (ヤングマガジンコミックス)

最高のリーダーは、チームの仕事をシンプルにする (単行本)

イラストでパッとわかる チームリーダー1年目の仕事のルール

マンガでよくわかる 教える技術2 <チームリーダー編>