CPU dummy read (MOS6502)

GW中にMOS6502のエミュレータを作ったのですが、
https://github.com/suzukiplan/M6502
そのテストをするためにファミコンエミュレータを開発中です。
https://github.com/suzukiplan/OpenNES

NesDev Wikiで公開されているテストコードを全部通すことが当面の目標。
https://wiki.nesdev.com/w/index.php/Emulator_tests

とりあえず、branch_timing_testsは無事全部通りました。

この勢いで、cpu_dummy_readsも通そうとしたのですが、失敗...

CPU Dummy Readsってそもそも何？と思い、スレッドを確認。
https://forums.nesdev.com/viewtopic.php?p=31629

absolute X、indirect Yでページがクロスオーバーするとpenalty clockが発生するのですが、その時、

ldx #$22 lda $20E0,x ; dummy read from $2002 ldx #$22 lda $20E2,x ; dummy read from $2004 ldx #$22 lda $3FE0,x ; dummy read from $3F02

という感じでdummy readが発生するらしい。

という訳で対策
https://github.com/suzukiplan/M6502/commit/ff19b729a7132554ea4be5a714ca894fade489d2

absolute Yの時についてはスレッドで言及されていなかったのですが、一応absolute Yの時にもdummy readする感じにしてみました。（これが正しいかは不明）

Sign in with Apple対応メモ

サードパーティー製のログイン機能を実装しているiOSアプリが、Sign in with Appleに対応していないと審査でリジェクトされるようになった（リジェクトされた）ので、マッハ（1.5日ほど）で対応した時の要点メモを残しておきます。

【要点】
以下、C = クライアントサイド & S = サーバサイド です。

• C: ASAuthorizationAppleIDButtonでSign in with Appleボタンを設置
• C: ASAuthorizationControllerで認証UIを呼び出す
• C: ASAuthorizationController.delegateで認証結果を受け取る
• C: 認証コード（ASAuthorizationAppleIDCredential.authorizationCode）をサーバへ送信
• S: apple-authへ受け取った認証コードを渡し、Appleのサーバからsub等を取得（こんな感じ）して自サービスのアカウントの紐付けとかをする

【サーバサイド】

• サードパーティー製ライブラリを使うほどのものでもない対応内容ですが、急いでいたし、apple-authの説明が分かりやすかったので採用（感謝）
• ハマり所は特に無し（例によってApple Developerでの諸々の設定が面倒で、provisioning profileの更新周りで小一時間手間取る程度）

【クライアントサイド】

• 特にUI（導線設計）周りは指示通りにやらないとリジェクト・リスクがあるので注意した（なんやかんやでこれが一番対応コストが掛かる。デザイナとSlackで半日程度やりとりしてザックリと決めて即日実装）
• 唯一のハマり所は、ASAuthorizationAppleIDCredential.authorizationCodeがNSData型だったので「Base64にするん？」と勝手に想像して実装したことぐらい。単純にこれはUTF8のconst char*型データなので以下のようにすれば良い。

```objective-c

NSString* codeText = [[NSString alloc] initWithData:code encoding:NSUTF8StringEncoding];

```

【雑感】

• タッチIDで認証できるのは中々快適
• landscape専用のアプリだが、認証画面がportrait専用（iPhoneの場合）
• 多分、フェースID絡みの関係で、縦にせざるを得なかったのではないかと想像（やっぱり、タッチIDこそが至高）

GitLab社によるリモートワーク虎の巻（概略解説）

67か国に1,200人以上もの従業員を抱えるオール・リモートワーク企業のGitLab社が、リモートワーク導入のためのPLAYBOOKを公開していることがIT MediaやGigazineなどで紹介されました。ただし、それらの記事でPLAYBOOKの全体的な内容については、ざっくりとしか説明されていないようです。

PLAYBOOKは以下URLから無料でダウンロードできるので、各々が内容を確認すれば良いとは思いますが、如何せん全部英語で書かれているので、読むのが結構大変ではないかと思います。全部翻訳しても良かったのですが、英語の方がしっかりコンテキストが伝わります。私はこういったテキストを読む時（正確には読んだ後）、全体を俯瞰的な視点で記した要約書みたいなもの（読書感想文を論理的にインデクス化したもの）を作るのですが、その要約書を記しておこうと思います。幸い、3章以降はオリジナルのPLAYBOOKの方にその要約書に相当する解説が載っているので、結構楽に作ることができました。
https://about.gitlab.com/company/culture/all-remote/

---

PLAYBOOKは、以下の6章で構成されています。
そして、3章以降（実践編）では章末に「何をすべき」で「何をすべきでないか」が簡潔に纏められています。

1. 仕事の未来に備える
2. 企業のリモート対応段階
3. リモートワークの基礎
4. 移行を実現する
5. リモートコミュニケーション戦略
6. リモート企業文化の確立

---

1章では、リモートワークを採用した企業の従業員がすべきことを管理職向けと一般職向けで分けて記載しています。

（管理職がすべきこと）

1. リモートリーダーシップチームの設立
2. ハンドブックを確立
3. コミュニケーション計画策定
4. ツールスタックの最小化
5. 変化を促す

（一般職がすべきこと）

1. 集中できる専用のワークスペースを作る
2. 生活と仕事を分離する
3. 孤独を避け人々との関わりを絶たない
4. ルーチンを尊重しつつ変化を試みる
5. 変化に順応する

---

2章ではリモートワーク対応の組織論について解説しています。
GitLabによると、リモートワーク対応の組織には以下の5つの段階があり、自社が現在どの段階にあるのかを把握すべきだとしています。（それぞれの段階の細かい説明は省略しますので、気になったらオリジナルのPLAYBOOKで確認してください）

1. リモート非対応
2. 一時的なリモート許可
3. リモート併用（リモートと非リモートのハイブリッド）
4. ひとつのタイムゾーンを基準としたリモート
5. 複数のタイムゾーンを跨ぐオールリモート

恐らく、今回のCOVID-19関連の騒動でリモートを導入した企業の大半は段階2 or 段階3止まりだと思われます。また、騒動長期化が現時点で懸念されていることから、段階2の企業も段階3へ移行する可能性がありそうです。ただし、特に段階3に関しては多くのデメリットがある点を指摘している点が興味深いので、（やや長くなってしまいますが）そのデメリットをGoogle翻訳で翻訳したものを以下に記します。

（段階3のデメリット）

• ハイブリッドリモートの従業員は、情報へのアクセスが少ない場合があります。 あなたがすべてを文書化する雇用主のために働いていない限り、あなたは、直接の同僚と比較してより少ないか不完全な情報であなたの日常の仕事を処理するように求められるかもしれません。 時間が経つにつれて、これは間違い、混乱、フラストレーション、さらにはパフォーマンスの低下につながる可能性があります。
• キャリアと開発の機会の減少。 視界の外にあるハイブリッドリモートの従業員は、昇給、昇格、および開発の機会のために引き渡される場合があります。 また、組織内で水平に移動する機会が少なくなり、進化するビジネスニーズに対応するための新しい役割を作成するための影響力も少なくなります。
• サテライトオフィスのような感覚。 ハイブリッドリモートの従業員は、会社の他のメンバーから孤立していると感じる場合があります。 面接プロセス中に、リモートの同僚がどのようにオンボーディングされ、含まれ、他の人に知覚されているかを尋ねることは重要です。 一部の従業員はこの治療法に気を取られないかもしれませんが、他の人に精神的および感情的な犠牲を払う可能性があります。
• 罪悪感を管理する。 主に同じ場所に配置されている会社で働いているリモートワーカーが罪悪感を表明するのを聞くことは珍しくありません。 彼らの社会化には、通勤について不平を言うかもしれない、または家族の機能に参加できないために悲しみを表すかもしれない同僚が含まれます。 リモートの従業員は同じ柔軟性に耐える必要がないにもかかわらず、同僚と共感する必要があるため、この取り決めには不平等があります。
• リモートのロビー活動の負担。 従業員が遠隔地で雇われているが、この配置がチームとマネージャー全体で等しくサポートされていない場合、遠隔地の従業員が物理的なオフィスに通勤することを強制されないという認識された特権を絶えず正当化している状況が発生する可能性があります。
• リモートが本当に提供およびサポートされているかどうかを判断します。 多くの大企業はリモートの従業員を容認しますが、リモートとして役割を公に宣伝したり、リモートでの作業をサポートしていることを公に認めたりすることはありません。 これにより、ロールを検索するときに、そのような組織内のリモートフレンドリーなマネージャーやチームを検索することに加えて、かくれんぼという面倒なゲームが作成されます。
• 例にされるリスク。 主に同じ場所に配置された会社の遠隔地の従業員が「では、どうやって遠隔地の手配を手伝ったのですか？」のような質問をされる可能性があります。 これにより、遠隔地の従業員は困難な状況に置かれます。 彼らは、さらに多くの同僚がリモートで作業できるように権限を与え、評判を損なう可能性のある原因を擁護することを選択するか、知覚された特典を自分自身に保つことによって役に立たないように見えます。
• パフォーマンスの向上に対する要求。 毎日長い通勤時間を過ごす同僚と働いているリモートの従業員である場合、対面のチームメンバーが期待する以上の結果を提供するというプレッシャーに直面する場合があります。 これは、同じ場所にいる従業員が柔軟性に欠けて通勤する必要がある場合、離れた同僚が簡単に降りられないように追加の結果を生成する必要があると推測する羨望の有毒な文化に由来します。

これらの知見は、GitLab社は元々オールリモートではなくハイブリッドで運用していた時期があり、その際に得られたものだと思われます。リモートを導入する企業は、段階3は過渡的な処置として、基本的に段階4以降への移行が望ましいと解釈できます。

（補足）
段階4（グローバル企業なら段階5）に移行できればオフィスをバーチャルオフィス（実体の無い登記専用のオフィス）にしても問題無くなるメリットがあります。例えば、従業員を1,000人抱える大企業であれば通常約3,000坪程度のオフィスが必要ですが、現在の東京都の3,000坪規模で借りられるオフィス（Aクラスビル）の賃料は坪単価3〜5万円/月ぐらい掛かるので、年間10.8億〜18億円程度の固定費削減を見込めます。これはやらない手は無いと思います。ただし、東京のオフィスは不足気味（先月段階で空室率1%を割っていた筈）なので、一度決断すると後戻りできなくなるリスクが想定されます。そのため、中々決断に踏み切ることができない企業が多くあるかもしれません。個人的にはこれを機に郊外にオフィスを移してしまうのも手だと思われるので、思い切ってやった者勝ちだと思います。経営者の決断力が問われます。

---

3章（リモートワークの基礎）

この章では、全てを文書化することとそれが適切に共有されることの必要性を指摘しています。これは、リモート対応か否かに限らず、全ての企業に必要なことです。GitLab社の場合、ハンドブックと呼ばれる仕組みで文書を蓄積&共有しているようです。GitLab社のハンドブックについては、日本語の記事であればコチラの記事で分かりやすく紹介されています。

（要点）

1. 信頼を確立するには、非公式のコミュニケーションと社会的つながりを促進することが重要
2. すべてを文書化し、会社のコミュニケーションに「ハンドブックファースト」のアプローチを採用
3. 会議をオプションにして、すべての会議に議題を用意し、勤勉なメモを取り、不在の出席者の会議を記録するように要求
4. 会社の価値観を体系化し、遠隔地の作業環境をサポート

（行うべきこと）

• 社会的相互作用を奨励
• すべてを文書化
• 必要に応じて会議を開く

（行うべきでないこと）

• 相互作用を仕事関連のトピックに制限
• 1：1の情報伝達に依存
• 会議を必須にする

---

４章（移行を実現する）

今回の防疫対応でリモートを導入してみたものの、結構大多数の企業が何かしら上手く行かないケースに直面しているものと思われます。GitLab社によるとリモートへの移行を実現するための鍵は「文書化」と「ワークスペースの確保」にあるとしており、本章ではその具体的な手段について（例えば、リモートのデスクやチェアはどういう風に設置すべきかなど、かなり細々と）言及しています。「リモートでやってみたけど上手くいかない」と感じられたら、この章の内容を実践してみると良いかもしれません。

（要点）

1. 現実には、すべての企業がすでに何らかの形で離れています。 物理的な空間で何らかの相互作用が発生した場合でも、リモートファーストの手法を採用します。
2. 人間工学に基づいた効率的な作業スペースを作成するように注意してください。 最適な作業環境は、人によって異なります。
3. 文書化は全員の責任です。 質問して答えを受け取ったら、それを書き留めてください。

（行うべきこと）

• リモートファーストの考え方を採用
• ワークスペースに集中
• 質問に対する回答を文書化する

（行うべきでないこと）

• 社内環境の再現を試みること
• 答えを得るために仮想の肩を叩く

---

５章（リモートコミュニケーション戦略）

リモートワークを導入する上での最大の障壁は、やはりコミュニケーションの壁であることは既に多くの方が痛感されているかもしれません。本章では、リモートでのコミュニケーションを成功させるための戦略について解説していますが、PLAYBOOKの中で最も多くのページを割いて解説しているので、その重要性を窺い知ることができます。要点としては、文書によるコミュニケーションを基本とした上で、文書によるコミュニケーションを成功させるため手段（低コンテキスト化、絵文字の多用、ツール標準化）について解説されています。
（要点）

1. 文書化は日常の仕事です
2. 低コンテキストの文化を実装して、コミュニケーションが簡潔で直接的になるようにします
3. 絵文字を多用して、より包括的な環境を育てます
4. コミュニケーションツールを標準化し、コミュニケーションの分裂を防ぐために使用します

（行うべきこと）

• ディスカッションを記録し、トランスクリプトを取得
• 積極的な意図を想定
• コミュニケーション過剰であることを恒常化
• 統合コミュニケーションツールの標準を設定

（行うべきでないこと）

• 会議などの同期コミュニケーションに依存する
• チームのメンバーがすべての事実を持っていると仮定する
• チームメンバーに対応するよう圧力をかける
• 時間に敏感ではない質問または完了したタスク

---

６章（リモート企業文化の確立）

最後にどのような企業文化にすべきかという点について言及しています。例えば、非リモートの職場環境では、毎日遅刻せず、朝掃除をし、真面目に仕事をし（あるいはしているフリをし）、上司のおべんちゃらに体よく付き合う社員がそこそこ出世するケースがあります。それも一種の企業文化なので否定するつもりはありませんが、そこに合理性を感じることができません。そのような価値の無い価値観に固執していると、大きな環境の変化が起こった時に淘汰されることになります。そういった時流の変化に対応する上で重要なのが柔軟な企業文化の確立だと私は考えています。この章に記されている内容は、GitLab社がどのような企業文化にすることでオールリモートという大きな変化に耐え得る組織となるに至ったかを示す臨床実験の経過報告だと解釈しています。

要点としては、(1)フィードバックの確立、(2)不文律の排除、(3)従業員のBurnout（燃え尽き症候群、鬱）回避の3点で、それを実現する鍵はやはり「文書化の文化」がその根幹にあるようです。

文書化することでアウトプットをベースとしたフィードバック確立と不文律の排除が容易になります。

もう1点留意しなければならないのが「働きすぎ」です。リモートだと始発や終電といった強制的なタイムリミットの成約が無くなることで、真面目な人や優秀な人ほど無制限に働きすぎる恐れがあるため、非リモート以上にその点に気をつける必要がありそうです。

（要点）

1. あなたが報酬を与えるどんな行動もあなたの価値になる（フィードバックを提供する際に一貫してそれらを参照することにより、企業価値に対する信念と尊敬を構築）
2. 遠隔地の文化では、不文律は存在しない
3. メンタルヘルスを優先し、メンタルヘルスのリソースに簡単にアクセスできるようにする
4. 休憩をスケジュールし、仕事以外のトピックについて同僚と交流する時間を毎週作る

（行うべきこと）

• メンタルヘルスの維持に積極的に取り組む
• 必要に応じてストレスを解消したり取り外したりするために実行できるアクションのリストを作成
• ビデオ通話を活用して、仕事に関係のないトピックについて同僚とコミュニケーション
• デスクから離れているときに他の人に警告するステータスを設定するか、離れている間カレンダーをブロック

（行うべきでないこと）

• 1日中オンラインでいなければならない
• 起きたらすぐに仕事をする
• 解釈のために詳細を残す
• 24時間年中無休でコンピューターに接続
• 愛する人との境界を設定することを恐れなければならない

自炊ミスティカ

前回、最後に自炊したのは確かアテネオリンピック（2004年）がやっていた頃の筈だから、かれこれ16年前の話になります。リモートワークに切り替わって最初にやろうと思っていたことが、食事を外食から自炊に切り替えることです。これは、生活サイクル乱れ防止作戦の一環です。この作戦の主な目的は、通勤に往復1時間費やしていた時間的コストを料理時間に代替することですが、もしかすると美味しく健康的なご飯を頂ける可能性もわんちゃんあるかもしれません（※この辺は料理スキル依存）。銀座在住時は自宅調理場が狭すぎたけど、今の住居には無駄に拾いキッチンスペースがあって、そこをカプメンを沸かすだけのデッドスペースにするのは勿体ないという動機もあります。

しかし、機材を揃えるのが億劫で中々スタートに至りませんでした。昨日ようやく最小限の機材（仰々しく言ってますがフライパンと食器）と材料の調達ができたので、今朝の朝食から自炊を始めてみました。

記念すべき1作目はこちら。

題名: 3月21日の朝食
（少量の赤ワインとパンで頂く）

なんか、思っていたのと違う。
もう少し瑞々しい感じになる筈だったのですが、ザ・男飯になりました。

目玉焼きが潰れているのは、ヘラみたいなヤツを持っていないから箸でフライパンから出したため。ヘラみたいなヤツはやっぱり必要です。後で100円ショップで買っておこう。

野菜の焼き加減をかなりミスりました。焦げてはないが美しくもない。目玉焼きを焼いた後のフライパンで、ウィンナーと野菜炒めを作ったのですが、ウィンナーにいい感じの焼き色をつけようとした結果、野菜に火が入りすぎたのが敗因。最初にウィンナーを焼き、良きタイミングで野菜を投入し、いい感じに萎えたらすぐに出すという手順にすると良さそう。

ちなみに野菜を切る道具を持っていないので、野菜はカット済みのヤツです。70〜100円ほどで1袋買えて、1袋で2食分ぐらいの分量が入っています。本当はキャベツが入っているヤツが良かったのですが、昨夜未明に買いに行った所売り切れていたので、今回はニラとモヤシのみのヤツにしました。（それすら無かったらモヤシオンリー）

味は普通に美味しかったでうｓ。

ちなみに、主食は当面パンになります。
日本人なら米という若干ステレオタイプ気味な主張に対しての異論はあまりないのですが、残念ながら米を炊くマシンを持っていません。料理に飽きて外食生活に戻す可能性を勘案すると、設備投資タイミングとしては時期尚早です。何より炊くのと片付けが面倒くさい。長く続けるには、片付けの簡略化がかなり重要です。だから、食器はシングルプレート縛りにするつもり。

レンチンできる米（サトウのごはん）という選択肢ならあり得ますが、レンチン米はコスト面にやや難があります。1食米だけで150円もします。パンなら1食あたり20〜30円ぐらいで十分お腹いっぱいにはならないけど、ワインを混ぜることで血糖値が上がり満腹感らしきものを偽装できます。もちろん、酔うほどの量ではなく、お猪口一杯分ぐらい。

（材料コスト）
・主食（パン+ワイン）: 50円分ぐらい
・野菜: 50円ぐらい
・ウインナー: 50円ぐらい（2袋200円を1Q使用）
・卵: 20円ぐらい
・各種調味料やサラダ油等: 5円以下
合計: 175円ぐらい

（労働コスト）
・調理時間: 10〜15分ぐらい
・後片付け: 5分ぐらい（フライパン、皿、ワイン用ベネチアングラス、箸）
合計: 20分ぐらい（時給1200円換算で400円...久々なのでやや手際が悪い）

野菜は、原材料を自前カットすれば20〜30円ぐらいに落とせるけど、カットする労力（それだけで+10分程度調理コストが掛かる）を考えるとカット済みのヤツを使う方がコスパが確実に優れています。+10分の調理コストが20〜30円で買えるなら十分安いです。自炊を始めた頃は材料コストだけ気にしてしまいがちですが（実際16年前はそうでした）、労働コストを気にすることが重要で、+10分というのは短いようでいて長いというか面倒くさい（片付けの際の洗い物数量が増えるのもダルい）です。+10分で200円の材料コスト圧縮が可能なら一考の余地があります。目安として時給コストを1時間あたり1200円と考えて、その上で「総コスト1食500円以下」などの目標設定をすると良いです。（熟練度が上がればカット+片付けに1分=20円とかにも出来るので、それぐらい熟練度が高ければカット済み素材を使うよりも自前でカットした方が安い）

包丁等のカット器具への設備投資（初期投資）が要らないのもデカイ。ちなみに、調理器具は蓋付きの安い（1500円ぐらいの）フライパンだけイトーヨーカドーで買い、その他の細々したものは全部100円ショップです。過去の経験則ですが、必要だと思うものを全部そろえてしまうと、かなりの分量の不稼働設備が発生するので、設備は最小スペックで始め、必要なモノを都度買い足すのが良いです。

ドワゴンクエストウォークをやってみたメモ

ローンチ日（2019.9.12）からプレイ開始。
プロフはこんな感じです。
※低画質モードでプレイしているのでややボヤけている

約12日間プレイして63799歩しか歩いていないのか...運動不足ですね。

【アバターについて】
見た目が女の子、中身はおっさん。
ストーリー等はオールスキップで読んでないです。ソシャゲのストーリーなんて飾りですよ。他のソシャゲでも、石を貰うために読んでそしてスキップ。要するに感情移入とかそういうのは一切無いので、それならフレンド登録の成約率が高いネカマとしてプレイした方が良いんじゃないかなということで。（だから、装備品も性能よりも見た目重視。ガチの戦闘要員は他ユーザに見られない2人目以降の仲間。）

【課金要素について】
売上が1週間で40億ぐらいらしい。（※ソース無し）
確かピーク時のパズドラでも1週間で30億ぐらいだったと思うので、かなり高い。
なので、「一生遊べる」という謳い文句で登場して、半年でサービス終了したあのゲームと同じ末路をたどることは無さそうです。（カゲロウでも1年生きるので、カゲロウよりも短い一生でしたね...）
課金要素は2つあって、
・ゴールドパス ... 今の所ゴミ（上限が低すぎる割に値段が高いのでコスパが悪い印象）
・そうびガチャ ... 言うまでもなくコレが稼ぎ頭（のハズ）
ゲームバランスが絶妙なので、結構良心的だと思いました。
今の所完全無課金でプレイしてます。
良い感じに集金できた後で良いので、タクトが3000円で買えるデレステのスカチケ的なヤツが実装されたら多分課金する。

【ゲームバランス】
4章序盤までプレイしてみた感じでは中々良いです。
ひかりのタクト（蘇生と全体回復がある現時点で最も壊れ性能の武器）が有ればヌルゲーだったかもしれませんが、無くても策を練れば普通に越せるバランス感。4章までは寧ろ無い方が楽しめそう。実際☆4の武器はやしゃのこんと雷神の槍というやや残念なスペックのヤツだけでなんとかなりました。
メイン職業は、
・戦士×2（メイン火力...なので☆4武器が2本は欲しい）
・僧侶×2（回復とスカラによる補助要員）
※僧侶はときどき（レベリング時に）武道家になる
という構成で、僧侶には適当にmpが回復する棒を与えておけばOK。
レベル20から永続ステータスの項目があるので、1人だけ転職とレベリングを繰り返して全職業20を目指していますが、現時点の職業バリエーションだと労力比で得られる効果がやや残念かもしれないので、メイン職業だけ育てているのが吉かも。

【歩き要素】
プレイ初期の頃はそこそこ歩いていたのですが、ストーリー3章以降は結構手応えがあるというか、腰を据えてプレイしないと死ぬので、外でプレイできません。
なので、
(1) 自宅から喫茶店やレストランに目的地設定
(2) 喫茶店やレストランでプレイ
(3) 攻略後、自宅に目的地設定
(4) 自宅でプレイ
の繰り返しです。
オートで攻略可能な戦闘 or 戦闘なしのイベントなら、そのパターンでなくても大丈夫ですが、ウォークモードを解除する必要があり、解除すると自動スリープで勝手に止まってしまうので、そこそこ操作が必要です。要するに歩きスマホせざるを得ない仕様だから、少し危ないです。（だから、外ではウォークモードで完全放置できるレベリングぐらいしかやらないようにしています...人通りがほぼ無い夜中なら割と安全に外でプレイできますが、それだと別の意味で危ない）

外で必要な操作は「チェックポイントに近づいてタップ」ぐらいにしておき、その他の操作はすべて自宅等で完結するぐらいの仕様であって欲しかった。（ドラクエウォークは恐らくそのレベルの仕様変更は無いと思うので、次の位置ゲーに期待）

【レイドバトル】
近所で開催されてはいるのですが、外での操作が必要だろうから億劫になってました。
そこで今日（レベル30超えてる状態で）始めてレイドに参加してみました。
推奨レベルは余裕で超えていますが、安全のため日が落ちてから近所の公園（レイド開催地）へ行き、公園の周辺を只管ぐるぐる回ってプレイ。
これはアカン...
レイド参加者が少なかったというのもありますが、完全に歩きスマホしないとプレイできない。（かといって夜の公園のベンチでプレイするのはちょっとなぁ...という感じ。徘徊するのも結構アレですが）
レイド開催地がドトールやベローチェあたりじゃないと今後の参加はキツい。

【総評】
概ね面白いですが、位置ゲーであることの意義とドラクエブランドが微妙に噛み合っていない感。もうちょっと位置ゲーにウェイトを置いたゲームデザインにしても良かった気がする。

Findyをエンジニアの人事評価に使えないか？という話

テック系の企業では、エンジニアのスキル評価を人事評価に組み入れる必要がありますが、技術面に疎いであろうコーポレート部門でエンジニアのスキル評価をするのは、中々難儀なことだろうと想像できます。

シンプルに、
・携わったサービスがバズったら高く評価
・イマイチなら低く評価
という風に評価してしまうのは、良くないです。（経営者やマネジメント的なポジションの人ならそれで良いのですが）

例えば、技術力が無茶苦茶高いエンジニアが、社長命令で企画面がイマイチなプロジェクトに配属され、サービスの顧客評価＆売上がイマイチだった時、その原因が「エンジニアの技術力が低いため」と評価して良い筈がありません。

エンジニアの評価は、
・業績面での評価
・スキル面での評価
で分けて考えるべきだと思います。

業績面での評価は、売上やプロジェクトの進捗結果（納期未達があったか？とか）などである程度は定量的に測ることができます。

しかし、スキル面での評価はすごく難しい。

スキル面に疎いであろうコーポレート部門ではなく、エンジニア部門内で評価する事すら難しいと思っています。

ふわっとした感覚値として「Aさんはスキルが高い」「Bさんのスキルは微妙」みたいな評価ならできますが、「彼らが前期と比べてスキルが向上したか？」といった評価ができるかというと、多分（エンジニア部門でも）できる人は殆ど居ないと思われます。

そうなると、マネージャがエンジニアにヒアリングして、自己申告ベースでの証言に頼ってスキル評価をするしかない訳ですが、そうなると何かしら恣意的な操作をされて評価が正当に行われない可能性が生じます。（私はその事象のことを「評価がふわつく」と呼んでいる）

独立行政法人IPAでは、そういったエンジニアのスキル評価がふわふわしている課題を解決すべく、スキル評価基準の標準化（ITSS）を多分10数年ぐらい前から進めていましたが、恐らく上手くいっていません。以前、ITSSを取り入れた職場（某大企業）で働いていたことがあるのですが、ITSSのレベル進行は各人で勝手に決めてはいけなくて、上司に「鈴木くん、来期からレベル4に上げといて」と言われたら、言われるがままレベル4になるように各種パラメタ調整をする感じのものでした。（やるだけ時間の無駄だったし、明らかに私よりスキルレベルが低い上司が私よりハイレベルな設定になっていたりすると、物凄くモヤッとした気分になる）

要するに、スキル評価の仕組みをシステムとして成り立たせることは実質不可能ではないか？と以前から思っていました。

しかし、以下のFindyというサービスを使えば、定量的なスキル評価ができるかもしれません。
https://findy-code.io/

（参考記事）

GitHubをAIで解析して“スキル偏差値”算出、エンジニアのキャリア選びを支援するFindyが2億円調達

https://jp.techcrunch.com/2019/06/05/findy-fundraising/

要するに、エンジニアの成果物（GitHubの作業履歴）を元にAIが良い感じにスキルを偏差値として採点してくれるもののようです。

試しに私のスキル偏差値も判定してみました。

ん？スキル偏差値85って...高すぎないか？（自分がそこまでレベルが高いと思っていないので、自己評価だったら絶対につけない点数ですが、AIによる公平な判定だから仕方がない）

スキル偏差値の年収分布は以下のような感じらしいです。

参考までに、私の前職（ドワンゴ）の年収はだいたい700万円だったので、偏差値65あたりが妥当ライン or 会社からの評価査定結果が微妙だった（市場価値より低く評価された）と考えられますが、業績評価込みなら（担当サービスがまだサービスインしてなかった & 全社的な状況を鑑みて）概ね妥当なラインだったかもしれません。現職の年収は色々と特殊な事情があって若干低い（400万円ぐらい）ですが。

スキル偏差値の判定はAIの学習が進むなり、サンプリング対象の拡大が進んでいけば（＝利用者が増えれば）更に良い感じになるかもしれません。
その上で偏差値85だったら、何処か年収1200万円で良いので雇ってくれないですかねｗ

今の所、Public Repository（OSS）で活動している人限定ですが、Private RepositoryやGitHub Enterpriseとかで連携できれば、普通に人事評価ツールとして使えると思います。
ただ、個人的には今のまま（Public Repository限定）の方が良いと思っていたりします。Privateな評価だと社内の人事評価でしか役立たないけど、Publicなら就職、転職、作業外注の受け入れ審査などのシーンでも使える事に加え、社外のエンジニアとの比較調査にもなると思うので。（評価のオープン化みたいな...そういう言い方をすると少し抵抗がある人が居るかもしれませんが、例えば英語ができる作業外注を探す時、「TOEIC900点以上の人」みたいな感じで探すと思いますが、それと同じようなノリで「Androidの仕事ができる人が欲しいから、Kotlin偏差値70以上の人」みたいな探し方ができるようになるというイメージで考えれば、ごく自然なことではないでしょうか）
もちろん、OSS活動にかまけて社内業務が疎かになってはいけませんが。
ただ、OSS活動にウェイトを置いた方が、世界が面白いことになる可能性が高い気がする。

追記: 最初、職歴入力しない状態でどれぐらいのオファーが来るものかと思ったけど、あまり来なくて、職歴を入力してみたらおおよそ年収700〜1200万円前後のオファーがチラホラ来るようになったので、転職用途としてはスキル偏差値は飽くまで目安で、基本職歴の方が重視される感じらしい。（東大を出てても職歴10年過ぎればその辺がほぼほぼ評価の対象にならないのと同じかなと）

Z80エミュレータを作り始めた件

8bit時代のマイコンCPUには、大きく３つの源流がありました。

(1) MC6800
(2) MOS6502
(3) Intel 8080

MOS6502はかなりシンプルで、個人的には上記の中で一番気に入っています。
MC6800はMOS6502よりも更にシンプルですが、インデックスレジスタが1つしかないので、プログラムのを組むのにやや不便だと考えられます。
6502の良いところは、6800ほどシンプル過ぎず、8080ほど不雑過ぎない絶妙なバランス加減です。

個人的に8080はフルアセ（特にハンドアセンブル）でプログラムを組むのがやや大変（命令を2進数で覚える必要があるので覚えにくい）です。まぁ、ハンドアセンブルなんかせずアセンブラを使えば良い訳ですが。

Intel8080（808xシリーズ）は、レジスタが沢山あり、さらにペアレジスタという概念のお陰で16bit演算が割と簡単にできます（他の8bit CPUでの16bit演算はキャリーを使って計算する必要があるのでやや面倒です）。演算といっても足し算、引き算だけ（掛け算と割り算はない）ですが。なお、論理演算は8080でも8bitです。

そんな優れた8080ですが、8bitマイコンで主に使われたのは8080上位互換CPUのZilog Z80です。Z80（※互換製品を含む）を採用したコンピュータとして、有名どころとしては以下のものがあります。

【PC】
・MSX
・Sharp X1
・NEC PC-6001〜PC-8801（※88VAは除く）
【ゲーム機】
・任天堂 ゲームボーイ
・SEGA SG-1000〜マスターシステム
・SEGA メガドライブ（※サブCPU）
・SEGA ゲームギア
・SNK ネオジオ（※サブCPU）
【その他】
・パチンコの抽選制御部分（現在でもZ80らしい）
・TI73シリーズ（日本では知名度が低いが）

上記は、パッと調べて出てきたもので、調べればまだまだあるでしょう。
これだけ沢山使われている（現代でも使われている）CPUだから、さぞかし扱いやすいエミュレータが沢山あるんだろうと思っていたのですが、仕事の関係で少し必要になって調べてみた限り、中々「コレだ」と思える実装に出会えませんでした。

という訳で、私が「コレだ」と思えるZ80エミュレータがほしかったので、作り始めてみました。
https://github.com/suzukiplan/z80

とりあえず動くエミュレータが既にある（仕事では困らない）ので、実のところあまり開発のモチベーションは高くないのですが、Z80の勉強を兼ねてとりあえず完成させたいと思っています。