2020年7月29日水曜日

ゲームボーイのCPUについて

ゲームボーイのCPUについて、誤った技術情報が検索トップの方に表示されるので、私が把握する限りでZ80との仕様差を書いておきます。

ゲームボーイのCPUとは?
☓ 8080
☓ Z80
○ 8080カスタム or Z80カスタム(正確にはSHARPのLR35902)

Z80との仕様差:
  1. 1マシンサイクルが全て4Hz(なので全ての命令のTサイクルは4で割り切れる)
  2. 一部フラグ(S, P/V, X, Y)が存在しない(※X, Yはundocumented)
  3. レジスタ IX, IY が存在しない
  4. プレフィクスDD(IX命令)、FD(IY命令)が存在しない
  5. 裏レジスタが存在しない(ので、EX/EXX命令も存在しない)
  6. IN/OUT命令が存在しない(I/Oは$FF00〜$FFFFにメモリマップド)
  7. プレフィクスED命令(結構便利な命令群)が存在しない
    1. $ED $4D (RETI命令) については $D9 (EXX命令) へ移動
    2. Rレジスタに実質アクセスできない(Rレジスタ=DRAMへ通電するためのレジスタで命令実行毎に0〜127の範囲でインクリメントされ続けるもの。この特徴を利用してゲームでは乱数ジェネレータとして利用されることがあるが、ED命令削除の影響でゲームボーイでは利用できないので、乱数を使いたい場合は自前の乱数テーブル等を作る必要がある)
  8. プレフィクスCBのSLL命令(undocumented)がSWAP命令に置き換わっている(SWAPはレジスタ上位4bitと下位4bitを入れ替えるLR35902固有機能)
  9. DJNZ命令がSTOP命令に置き換わっている(STOPはHALTよりも省電力な割込待機機能)
  10. LDI/LDD命令をシンプル化(Bレジスタのデクリメントを行わず、HLのインクリメント・デクリメントのみ行う)
    1. LDIR/LDDR(OTIR/OTDR)相当の命令が無いのでBレジスタのデクリメントが要らない(これらの命令は結構便利だが、継続条件時に5Hzの無駄クロックが発生する関係で、性能が求められる箇所では使用せずにOUTI, OUTI, OUTI...などといった形でRじゃない方の命令を並べて書くのが普通...つまり、ゲーム用CPUなら無くても良いよね という判断だと思います)
  11. LDH命令を追加($FF00〜$FFFFへのアクセス命令のサイクル数を少なくしたもの=I/O命令の代替用)
  12. スタックポインタを便利に使えるようにする命令群(LD (addr),SP / ADD SP,d / LDHL SP,d)を追加(※LDHLはADD SP,dの結果をHLに代入する命令)
  13. LD (addr),A と LD A,(addr) の命令コードを変更
  14. LD HL, (addr) と LD (addr), HL を廃止
私の認識はだいたいこんな感じ。

これで本当に正しいか少し自信がないので、自前Z80エミュレータにLR35902コンパチモードを追加して検証してみようと思っているところです。
https://github.com/suzukiplan/z80/pull/17

(以下、余談)
ゲームボーイのCPUが8080派生なのかZ80派生なのかという議論を目にしますが、機能的には8080とZ80のどちらにも近いと思います。レジスタセットは8080に近いし、豊富なシフト命令(CB prefix instruction set)はZ80に近い。また、IN/OUT命令をメモリマップで代用しているから6502っぽさも感じられます。(Z80をよりゲーム用に洗練させた感じなので、GBZ80という通称が一番しっくりくる)
敢えて、8080派生 or Z80派生のどちらが正しいかを「CPUの設計過程でどちらをベースCPUにしていたか」という観点で推測すると、Z80派生が正しいと思います。というのも8080をLR35902化するのと、Z80をLR35902化するのなら後者の方が設計コストが圧倒的に低いので。(8080派生だとするとCBプレフィクス命令の追加設計が物量的に重そうだし、bit/set/res命令辺りは普通にand/orで代用できてand/or比で性能的なメリットも無いから、ゲーム用の機能としてわざわざ新設する意味がないような気がするので)

2020年6月1日月曜日

AWS + Docker + Redmine の簡単な構築手順(pluginを使いたい場合)

AWS/EC2(Amazon Linux 2)でDockerを使ってRedmineの環境構築をした際のメモです。公式のredmineのDockerイメージを使い、尚且プラグインを使いたい場合、多分これが一番簡単だと思います。

(0) スワップ領域確保

EC2の弱いサーバ(t2.micro)で動かす場合、redmineを動かすと割とカジュアルに「メモリ不足」で落ちます。スワップ領域を1GBほど確保すれば、t2.microでも問題なく動きます。(t2.microのお値段は30日あたり$4.176)

dd if=/dev/zero of=/tmp/swap.img bs=1M count=1024

chmod 600 /tmp/swap.img

mkswap /tmp/swap.img

swapon /tmp/swap.img

free


(1) docker / docker-composeをインストール

sudo yum install -y docker
sudo systemctl enable docker
sudo systemctl start docker

sudo curl -L "https://github.com/docker/compose/releases/download/1.23.2/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
sudo chmod +x /usr/local/bin/docker-compose

(2) redmineのDockerfileを作成

sudo mkdir ~/redmine
sudo mkdir ~/redmine/work
sudo mkdir ~/redmine/redmine
sudo vi ~/redmine/redmine/Dockerfile

以下、Dockerfileの内容:
FROM redmine:4.1-passenger
RUN apt-get update && apt-get install build-essential
WORKDIR /home/ec2-user/redmine/work
RUN bundle install
RUN rake redmine:plugins:migrate RAILS_ENV=production

メモ: 当初docker-compose.ymlだけで「image: redmine:4.1-passenger」を指定して構築したのですが、それだとプラグインをビルド(bundle install)時に「make not found」でビルド失敗してしまいます。公式dockerイメージにはbuild-essentialが入っていないので、公式dockerイメージは(そのままでは)pluginを導入することができません。なので、redmine用のDockerfileを個別に作成して、RUNスクリプトでbuild-essentialをインストールしつつ、ついでにbundle install + DBマイグレーションを実行しておくことが必須です...
今どきredmineを使う所も稀かもしれないけど、その中でもpluginを使わない人なんて居るのだろうか?なので、(Dockerポリスからは怒られるかもしれないが)公式のdockerイメージにbuild-essentialを入れておくべきではなかろうか。

(3) docker-compose.ymlを作成

sudo mkdir /var/lib/redmine
sudo mkdir /var/lib/redmine/config
sudo touch /var/lib/redmine/config/configuration.yml
sudo vi ~/redmine/docker-compose.yml

以下、docker-compose.ymlの内容:
version: '3.5'

services:
  redmine:
    build: ./redmine
    container_name: redmine
    ports:
      - 3000:3000
    environment:
      TZ: Asia/Tokyo
      REDMINE_DB_MYSQL: mysql
      REDMINE_DB_DATABASE: redmine
      REDMINE_DB_USERNAME: redmine
      REDMINE_DB_PASSWORD: redmine
      REDMINE_DB_ENCODING: utf8
    depends_on:
      - mysql
    restart: always
    volumes:
      - /var/lib/redmine/files:/usr/src/redmine/files
      - /var/lib/redmine/log:/usr/src/redmine/log
      - /var/lib/redmine/plugins:/usr/src/redmine/plugins
      - /var/lib/redmine/public/themes:/usr/src/redmine/public/themes
      - /var/lib/redmine/config/configuration.yml:/usr/src/redmine/config/configuration.yml

  mysql:
     image: mysql:5.7
     container_name: mysql
     restart: always
     environment:
       TZ: Asia/Tokyo
       MYSQL_ROOT_PASSWORD: devops
       MYSQL_DATABASE: redmine
       MYSQL_USER: redmine
       MYSQL_PASSWORD: redmine
     volumes:
       - mysql-data:/var/lib/redmine/mysql
     command: mysqld --character-set-server=utf8 --collation-server=utf8_unicode_ci

volumes:
  mysql-data:
    name: mysql-redmine

(4) プラグインの追加方法

  1. /var/lib/redmine/plugins以下にgit cloneなりコピーなりして配置
  2. docker-compose restart
起動が上手く行かない場合、ログを見るなりdocker-compose upとかで起動するなりして失敗原因を確認。多分、何かしらのサードパーティーツールが足りていない筈なので、必要なやつをDockerfileのapt-get installに追加してイメージ再作成すればOK。(build-essentialだけあればほぼ問題無いと思いますが念の為)

(5) メール配信をしたい場合

  1. /var/lib/redmine/config/configuration.yml に必要な設定を追加
  2. docker-compose restart
SESを使う場合はこんな感じ:
production:
  email_delivery:
    delivery_method: :smtp
    smtp_settings:
      address: "SMTP settingsに書かれているホスト名"
      port: 587
      domain: "ドメイン(※ドメイン認証は無くても大丈夫かも)"
      user_name: "取得したSMTPクレデンシャルのユーザ名"
      password: "取得したSMTPクレデンシャルのパスワード"

(6) Redmineのバージョンを変更したい場合

DockerfileのFROMを修正した後、

docker-compose stop
docker-compose up -d

とかでイケるはず。

(7) クラウド環境で動かしたりとか

ここまでで記載した内容でとりあえずオンプレミスでは正常に動きます。
クラウド環境というかインターネット上で動かす場合に必要な設定を記載しておきます。
  • Route53やお名前.comなどで独自ドメインを確保
  • ACM(Certification Manager)で、確保したドメイン(ex: example.com) or そのサブドメイン(ex: redmine.example.com)の証明書を作成
  • ELB(ロードバランサ)を作成(リスナーはhttps※ポート番号はウェルノウンポートを避ける、ターゲットは作成したインスタンスのhttpポート3000/tcpへオーバロード & ACMで作成した証明を割り当て)
  • Route53の確保したドメインのホストゾーンにCNAMEレコード追加してELBのホスト名に繋ぐようにする(Elastic IPを割り当てているのであればAレコードでもOKだけどElastic IPは有限なのでCNAMEの方が多分都合が良い筈)
  • Redmine自体の設定でユーザ作成は無効化(管理者が対応)、認証を必須、パスワードログインは基本的にせず自社のGsuiteアカウントを使ってGoogleアカウント認証(それができるプラグインがあり自社ドメインに限定等が出来る)でログインして貰うようにする。
  • adminの無効化方法は分からなかった(私はRedmineにはまだ詳しくない)ので、とりあえずクソ長くて解読しにくいパスワードにして対処
上記のような感じで設定すれば、多分、セキュリティレベルとしては普通のクラウド版Redmineサービス(MyRedmineとか)よりも高い筈。

月額コストはだいたい850円〜900円ぐらい。
※とりあえず、EC2はt2.microでEBSに全部載せという雑な構成で動かす場合
※EC2の無料分に収まれば多分月50円(データ転送やSESのコスト分のみ)ぐらいかな(使用頻度による...)
多分、クラウドサービス版RedmineではMyRedmineが一番安い筈ですが、それでも月8,000円掛かります。Redmine自体割と枯れたシステム(※褒め言葉)なので、社内運用とかであれば保守の人員コストもそんなに掛からないことを勘案すると、自社で構築してしまった方が多分コスパが良いです。((1)〜(7)までの構築に掛かる人件費ですが、AWSに慣れた人なら0.5人日以下でサクッとできてしまいます)
自社で何らかのWebサービスを構築する or 運用しているのであれば、その練習台(インフラエンジニアの新人研修ネタ?)としても丁度良いかも。DBをAurora、EBSに乗せているfilesディレクトリ(添付ファイルデータ)をEFSに変えればAutoScalingを用いてスケールアウトさせることも出来るので、スケーラビリティ設計の練習台にもできそう。

リモートワーク(テレワーク)対応で、今までオンプレで使っていたRedmineをクラウドサービスに移行しようとして、MyRedmineを使う予算承認が降りたのですが、MyRedmineを試食してみたところ「これなら自分で作った方が早いし安い」と思い自前構築した時のメモでした。(今更Redmine...と思いつつ、こういうケースって多いかも?)

実のところ、構築するのが面倒だった(0.5人日で済むとはいえ一応工数が掛かる)のでMyRedmineで良いじゃん(安いし)と思っていたのですが、MyRedmineの場合、契約書に決済者(※私は決済者ではない)の手書きサイン or 会社名が入った社印が必要とのことだった(※要するにWeb申し込みで完結しない契約タイプだった)ので、いわゆる「ハンコ打ちに会社行かなければいけないヤツ」だったことが自前構築の決断要因でした。
会社に行くと往復2時間(0.25人日)無駄にするし、決済者を捕まえるためのスケジュール調整にも無駄に工数が掛かるので、0.5人日掛けて自前構築した方がお得な筈。

2020年5月14日木曜日

電子マネー

政府からの特別給付の手続きで、せっかく電子証明書付きのマイナンバーカードを持っているものの、スマホ(旧型iPhoneSE)がNFC非対応だったので新型iPhoneSEに買い替えました。

申請自体それで滞りなく行えたので良かったのですが(...ただし、現状のマイナンバー制度は色々と不備が多く市区町村の行政サイドが色々混乱しているらしいので、実は郵送申請にした方が良かったのかもしれませんが)、それよりもApplePayが予想以上に便利だったので端末を買い替えて良かったなと。

今まで電子マネーは主にVIEW Suicaを使っていて、チャージ手段はオートチャージでした。ところが、2月末からリモートワークになり改札を通る機会が激減。電車に乗る機会は、月に1回あれば良い方(3月=0回、4月=1回、5月=今の所0回)になり、その結果オートチャージができず、仕方なく券売機で現金チャージをするという「電子マネーとは?」という状態でした。

現金は、調達するのにATM手数料が掛かるので極力使いたくないです。
なので私は、現金しか使えない店は原則使いません。
ついでに今なら、現金(特に硬貨)は衛生面の関係で触ることが憚れますし。

新型iPhoneSEを導入したことでApplePayが使えるようになったので、メイン電子マネーをモバイルSuicaに切り替え、VIEW Suica(クレジットカード)からチャージする運用に変更することにしました。

ApplePayなら、何処で幾ら使ったがひと目で分かるので、支出管理も大分楽になります。
また、スリープ状態でも決済できるのでQR決済(スマホ決済)よりも使い勝手が良いです。

QR決済については、近所のスーパーが電子マネーはPayPay(QR決済)しか利用できない関係でとりあえずPayPayも使ってますが、やはり決済の都度アプリを起動するのは面倒臭い。

多分、QR決済は(Origamiの実質破綻などがありましたが)NFC対応デバイスが普及するまでの過渡的な存在だと思うので、将来的には(NFC対応デバイスが普及しきったら)無くなると思っています。

恐らく、将来的にはPayPayは生き残るためにやむを得ずQRを捨ててNFCなりFeliCaなりになると思いますが、そうなると私ならSuicaに切り替えてPayPayは捨てますね。
Expressカードはひとつしか選べないので。

2020年5月11日月曜日

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する感じにしてみました。(これが正しいかは不明)

2020年4月10日金曜日

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こそが至高)

2020年3月29日日曜日

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

67か国に1,200人以上もの従業員を抱えるオール・リモートワーク企業のGitLab社が、リモートワーク導入のためのPLAYBOOKを公開していることがIT MediaGigazineなどで紹介されました。ただし、それらの記事で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の情報伝達に依存
  • 会議を必須にする


4章(移行を実現する

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

(要点)
  1. 現実には、すべての企業がすでに何らかの形で離れています。 物理的な空間で何らかの相互作用が発生した場合でも、リモートファーストの手法を採用します。
  2. 人間工学に基づいた効率的な作業スペースを作成するように注意してください。 最適な作業環境は、人によって異なります。
  3. 文書化は全員の責任です。 質問して答えを受け取ったら、それを書き留めてください。
(行うべきこと)
  • リモートファーストの考え方を採用
  • ワークスペースに集中
  • 質問に対する回答を文書化する
(行うべきでないこと)
  • 社内環境の再現を試みること
  • 答えを得るために仮想の肩を叩く



5章(リモートコミュニケーション戦略)

リモートワークを導入する上での最大の障壁は、やはりコミュニケーションの壁であることは既に多くの方が痛感されているかもしれません。本章では、リモートでのコミュニケーションを成功させるための戦略について解説していますが、PLAYBOOKの中で最も多くのページを割いて解説しているので、その重要性を窺い知ることができます。要点としては、文書によるコミュニケーションを基本とした上で、文書によるコミュニケーションを成功させるため手段(低コンテキスト化、絵文字の多用、ツール標準化)について解説されています。
(要点)
  1. 文書化は日常の仕事です
  2. 低コンテキストの文化を実装して、コミュニケーションが簡潔で直接的になるようにします
  3. 絵文字を多用して、より包括的な環境を育てます
  4. コミュニケーションツールを標準化し、コミュニケーションの分裂を防ぐために使用します
(行うべきこと)
  • ディスカッションを記録し、トランスクリプトを取得
  • 積極的な意図を想定
  • コミュニケーション過剰であることを恒常化
  • 統合コミュニケーションツールの標準を設定
(行うべきでないこと)
  • 会議などの同期コミュニケーションに依存する
  • チームのメンバーがすべての事実を持っていると仮定する
  • チームメンバーに対応するよう圧力をかける
  • 時間に敏感ではない質問または完了したタスク



6章(リモート企業文化の確立)

最後にどのような企業文化にすべきかという点について言及しています。例えば、非リモートの職場環境では、毎日遅刻せず、朝掃除をし、真面目に仕事をし(あるいはしているフリをし)、上司のおべんちゃらに体よく付き合う社員がそこそこ出世するケースがあります。それも一種の企業文化なので否定するつもりはありませんが、そこに合理性を感じることができません。そのような価値の無い価値観に固執していると、大きな環境の変化が起こった時に淘汰されることになります。そういった時流の変化に対応する上で重要なのが柔軟な企業文化の確立だと私は考えています。この章に記されている内容は、GitLab社がどのような企業文化にすることでオールリモートという大きな変化に耐え得る組織となるに至ったかを示す臨床実験の経過報告だと解釈しています。
要点としては、(1)フィードバックの確立(2)不文律の排除、(3)従業員のBurnout(燃え尽き症候群、鬱)回避の3点で、それを実現する鍵はやはり「文書化の文化」がその根幹にあるようです。
文書化することでアウトプットをベースとしたフィードバック確立と不文律の排除が容易になります。
もう1点留意しなければならないのが「働きすぎ」です。リモートだと始発や終電といった強制的なタイムリミットの成約が無くなることで、真面目な人や優秀な人ほど無制限に働きすぎる恐れがあるため、非リモート以上にその点に気をつける必要がありそうです。

(要点)
  1. あなたが報酬を与えるどんな行動もあなたの価値になる(フィードバックを提供する際に一貫してそれらを参照することにより、企業価値に対する信念と尊敬を構築)
  2. 遠隔地の文化では、不文律は存在しない
  3. メンタルヘルスを優先し、メンタルヘルスのリソースに簡単にアクセスできるようにする
  4. 休憩をスケジュールし、仕事以外のトピックについて同僚と交流する時間を毎週作る
(行うべきこと)
  • メンタルヘルスの維持に積極的に取り組む
  • 必要に応じてストレスを解消したり取り外したりするために実行できるアクションのリストを作成
  • ビデオ通話を活用して、仕事に関係のないトピックについて同僚とコミュニケーション
  • デスクから離れているときに他の人に警告するステータスを設定するか、離れている間カレンダーをブロック
(行うべきでないこと)
  • 1日中オンラインでいなければならない
  • 起きたらすぐに仕事をする
  • 解釈のために詳細を残す
  • 24時間年中無休でコンピューターに接続
  • 愛する人との境界を設定することを恐れなければならない

2020年3月21日土曜日

自炊ミスティカ

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

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

記念すべき1作目はこちら。
題名: 3月21日の朝食
(少量の赤ワインとパンで頂く)
なんか、思っていたのと違う。
もう少し瑞々しい感じになる筈だったのですが、ザ・男飯になりました。

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

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

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

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

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

レンチンできる米(サトウのごはん)という選択肢ならあり得ますが、レンチン米はコスト面にやや難があります。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円ショップです。過去の経験則ですが、必要だと思うものを全部そろえてしまうと、かなりの分量の不稼働設備が発生するので、設備は最小スペックで始め、必要なモノを都度買い足すのが良いです。

合理的ではないものを作りたい

ここ最近、実機版の東方VGSの開発が忙しくて、東方VGSの曲追加が滞っています。 東方VGS(実機版)のデザインを作りながら検討中。基本レトロUIベースですがシークバーはモダンに倣おうかな…とか pic.twitter.com/YOYprlDsYD — SUZUKI PLAN (...