ガレージのシャッターのリモコン操作をスマホで出来るようにした話

2014/07のガレージの様子

何度か書いている気もするのですが、我が家には地下車庫であるガレージがございまして、雨風から愛車を守るためにシャッターを取り付けています。

で、そのシャッターを操作するリモコンが2つあるのですが、夫婦で共用していると、、、

  • ある日、リモコンを持ってお出かけする
  • 帰宅後に、リモコンを所定の置き場に戻すことを忘れる(カバンに入れっぱなし等)
  • 翌日、↑をすっかり忘れていて、もう1つのリモコンを持って出かけてしまう
  • 家にリモコンがなくなってシャッターが開けられない
    • 厳密には、物理スイッチがあるので、鍵を持っていれば開けられるが、普段使わないので仕舞ってあり、なかなか面倒くさい

という事案が、たまに発生したりとか、普段リモコンを持たずに出かけちゃったりすることもあるのですが、そういう際は、車やバイクから降りて、一度家に入ったりすることもあり、もっとインテリジェンスにスマホから操作できればなー、と考えていました。

家の鍵とかだと Qrio Lock という製品があって、スマホを持っているだけで近づいたら家の鍵が開くとかできているので、GPSとか使って、ガレージのシャッターも同様のことができればなと思ったり。

というわけで、やってみました。

SwitchBot と Hub を購入

最初は電子工作でもしようかと思ったのですが、そんなに詳しいわけではないし、大元を壊してしまってはすごく高くつきそうなので、シンプルに解決するべく、ならば物理スイッチを押せる装置を調達してみよう、ということで、まずは SwitchBot という製品を購入してみることにしました。


これは、物理スイッチを押せるようになる IoT 製品で、スマホのアプリからタップすると、本体についているアームが動いて、スイッチを指で押すようにオン・オフできるようになるという代物です。

最初、まず1つ↑を買ってみて、ガレージのシャッターの物理スイッチに対して動かしてみようとしたところ、物理スイッチが格納されているケース内に、この SwitchBot が納まらず・・・w

それならばと、リモコンに仮付して(手で押さえて)動かしてみると、問題なくスイッチを押せそうであることを確認できたので、リモコンに SwitchBot を取り付ける方針にしました。

リモコンには、"Open" と "Close" のボタンがあるので、もう1つ SwitchBot を購入して、計2つ準備しました。


あとは、屋外というか外からガレージのシャッターを操作したいのですが、この SwitchBot 自体は、Bluetooth で通信しているようなので、あわせて上記のハブ製品 (SwitchBot Hub Mini) を購入しました。

SwitchBot Hub が、文字通りハブとなって、色々と制御できるようになるみたいなのと、この製品自体が赤外線リモコンの学習機能が付いているので、赤外線リモコンで操作できる家電製品を、ネットワーク経由で制御できるようになります。

仕組み作り

SwitchBot x2 + SwitchBot Hub Mini

使ったものは、この3つ。

SwitchBot は、アプリをダウンロードして、説明書に従ってペアリングするだけです。Hub Mini の方は、ペアリングしてから、家の Wi-Fi と接続して、インターネットに接続しておく感じ。
こんな感じで、SwitchBot のアプリを使って、セットアップを済ませておきます。


文化シャッター セレカードIII 送信機

ガレージのシャッターのリモコンですが、我が家は文化シャッターの「セレカードIII」を使っていますので、こちらも用意。(うちは新しく追加で1つ購入しました。)


文化シャッターリモコン + SwitchBot x2

SwitchBot には両面テープが付属しているので、くっつけていきます。

まずは仮置きして、手で動かないようにしながら、実際に SwitchBot のアームを動かし、問題なく押下できるか確認します。

問題なければ、両面テープでくっつけます。
私は、両面テープを貼りやすい位置として、↑のような感じで貼り付けました。

・・・が、しかし、貼り付けた後に動かしてみると、"Open" の方だけ、2回に1回程度の成功確率です・・・泣


文化シャッターリモコン + SwitchBot x2

というわけで、貼り直そうかと思ったのですが、貼り直しても上手くいく保証はないので、それならばとスイッチ側に厚みをつける作戦にします。
小さい紙を何度か折って、マスキングテープでスイッチ上に固定。

これで、問題なく SwitchBot のアームでリモコンのスイッチが押せることを確認しました。

ちなみに、マスキングテープは↑の長さだとすぐ剥がれてしまったので、もう少し長い感じで貼り直しました・・・。


次に、このリモコンを設置したい場所付近において、動作テストしてみます。
ガレージは外なので、窓付近にある棚に置くことにしました。よって、そこに SwitchBot 搭載リモコンを設置してみて、実際にガレージのシャッターが開け閉めできるか確認してみます。

こちらも問題なくOKでした。良い良い。

動画で紹介

こんな感じです。何度かやりましたが、スイッチの押下に失敗することはありませんでした。

ちょっとお化粧してみる

文化シャッターリモコン + SwitchBot x2

さて、、、では、このリモコンをそのまま棚に置いたままにするのか、、、というと、見栄えがイマイチです。埃とかも気になりそうだし。

というわけで、何かの箱の中に入れてみようかなと思い立ちました。
そこで、先日のバレンタインデーで妻から頂いたお菓子の空箱が、程よい大きさであることを思い出したので、これを細工してみることにしました。


文化シャッターリモコン + SwitchBot x2

細工し終わったあとの図。箱は少し大きかったのですが、まあ程よい大きさです。
リモコンが中で動かないように、箱の余りの部材で、余りのスペースに配置します。


文化シャッターリモコン + SwitchBot x2

意味があるか微妙ですが、リモコンの信号が外に出ていきやすいように、送信部の先部分の紙をくり抜いています。


文化シャッターリモコン + SwitchBot x2

で、元蓋を閉めれば完成。
設置場所が濃いめのブラウンの棚なので、リモコンをそのまま置いておくよりも、ナチュラルにとけこむ感じで、適当に作った割にはまあ良しという感じになりました。

さいごに

文化シャッターリモコン + SwitchBot x2

見返してみると、マスキングテープが "Stop" ボタンにかぶっているのが気になったので、一応紙をはさみこんでみました。

これで一旦完成とします。
SwitchBot の動きについては、さきほど動画の通りで、やりたいことができるようになったので満足です。

SwitchBot 自体は、Google Home や Amazon Echo 、IFTTT なんかと連携することができます。
うちも Alexa さん(Amazon Echo)に、音声でガレージシャッターのオープンやクローズができるようになることは確認できたのですが、よくよく考えると、外から大声で開け閉めできる可能性も否定できない・・・ので、音声での制御は念の為やめておきましたw

今日はこの辺まで。
それでは! =͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́


Google Cloud のインタビューを受けた (GCP事例紹介)

昨年終わり頃に、タイトル通り、会社でどのように Google Cloud Platform を活用しているかというインタビューを受けまして、一昨日公開されていました。

事例紹介という形で、ざっくりとした内容にはなっていますが、会社の事業に対して、どう Google のクラウドサービスを活用しているのかを、テックリードの @yukung と一緒に話した内容を、端的にまとめていただていますので、一事例として参考にしていただければ幸いです。
( PDFファイル: https://lp.cloudplatformonline.com/rs/808-GJW-314/images/Google_GCP_astamuse.pdf )

尚、取材の中で話していた、膨大なデータの翻訳処理に、GPUサーバを100台並べて並列処理しているという話ですが、結論から言うと、色々ありまして理論上の見積もりであった2週間で終わらず反省しています・・・(苦笑)

それでは! =͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́


HP Microserver N54L セットアップ日記 その2 - Modified BIOS アップデート

久しぶりに家の NAS をリプレースしていますシリーズその1の続きです。

その1にて、一通り物理作業をしたので、線を繋いで電源を入れてみます。

すると、、、ODD 用の SATA ポートにつないだハードディスクが認識していません。
BIOS でも見えていないように見えるし、CentOS 8 のインストーラーからデバイス(ディスク)のリストにも表示されていません。はて。
試しに切り分けのために SATA ケーブルを変えてみても同じ。はて。

事前に1つわかっていたこととしては、この HP Microserver N54L は、ODD 用の SATA ポートや eSATA のポートは AHCI が無効化されていて、遅いよという情報です。
ただ、認識もしないんだっけ・・・?どうなんだっけ?と。

一応、ドライバまわりとかもあるかなぁ、と手元にあった CentOS 7 や CentOS 6 の OS インストーラーからディスクを見てみると、なんと ODD SATA ポートにつないだ5本目のディスクが見えるではありませんか。なるほど。

おそらく、AHCI が有効になっていないデバイスは、CentOS 8 からは見えないということかー。

ならば、やっぱり全 SATA ポートの AHCI を有効にする試みを行ったログを残しておきます。

尚、以降は、メーカー公式で公開されている BIOS ではない、有志が作成した Modified BIOS を適用することになるので、もし同じことをされる際は、自己責任でお願い致します

Modified BIOS の入手

あくまで私のケースですが、試行錯誤の末、行ったのは以下の2つの Modified BIOS をダウンロードして、順に適用しました。

  • Modified BIOS (SP54344.exe ベース)
  • Modified BIOS (SP64420.exe ベース)

おそらく SP64420.exe ベースのものだけで良いかもしれませんが、確認が難しいので、ログ的に行った事実を書き残しておきます。

上記の入手先は、以下に記しておきます。

Modified BIOS (SP54344.exe ベース) ダウンロード

Modified BIOS (SP64420.exe ベース) ダウンロード

Modified BIOS の適用

まずブートメディアが必要です。USBメモリが簡単でよろしいかと。

上記の入手先に適用の仕方は記載されていますが、簡単に書いておくと、Modified BIOS は基本的に、

  • HP 公式の BIOS アップデータ (SPxxxxx.exe)
  • 修正された ROM ファイル

で構成されています。


流れを簡単に書いておくと、

  • Windows マシンと USB メモリを用意しておく
  • Windows マシンで、Modified BIOS を入手(ダウンロード)して展開する
  • 中に含まれている "SPxxxxx.exe" を実行すると、アップデータ一式がローカルディスクに展開される
  • 上記で展開されたディレクトリ内にある公式の BIOS ROM ファイルを、修正された ROM ファイルに置換する
  • USB メモリを挿して、BIOS アップデートファイルを、USBメモリに展開するべく付属のプログラム (hpqusb.exe) を実行する
  • 上記で作成した USB メモリを、HP Microserver に挿して、USB ブートを行うと、BIOS アップデータが適用されるので、終了したら再起動する

といった感じです。

Modified BIOS での設定

このリンク先の説明がかなり詳しくて参考になります。(英語ですが)

From the MAIN Screen I went to => Chipset Menu => Southbridge Configuration => SB SATA Configuration => and set the following:

OnChip SATA Channel [Enabled]
OnChip IDE Type [IDE or Legacy IDE](1)
SATA IDE Combined Mode [Disabled] -- sets Ports 4 & 5 to use AHCI
SATA EPS on all PORT [Enabled](2) -- sets all Ports to be external SATA Ports
SATA Power on all PORT [Enabled]

Notes: (1) OnChip IDE Type can be set to IDE or Legacy IDE – I have one MicroServer (WHS-2011) set to IDE (see Figure 9) and the other (S2012E) set to Legacy IDE (see Figure 10) and haven’t noticed a performance difference between the two, YMMV; (2) setting all Ports to be external SATA Ports will make all of your Ports to be Hot Swappable – this is something you would need later if you want to use the Port Multiplier functionality of the eSATA Port (Port #4) – there are registry hacks that will remove the hot swap functionality from specific Ports but I didn’t bother, again YMMV.

https://homeservershow.com/blog/byob-hardware/hp-proliant-n40l-microserver-build-and-bios-modification-revisited/

掻い摘むと、このあたりです。

673不明なデバイスさん2017/11/18(土) 22:41:22.48id:x89iRBEe
怖かったけどとりあえずModBiosで増設分もSATA2になってCommand Queueingも有効になりました

ここ参照にやった
http://www.dev-crowd.com/2016/10/13/bios-updates-fuer-den-hp-n54l-microserver/
改造元は最新Bios

Bios設定
・Chipset Menu => Southbridge Configuration => SATA Configuration:
OnChip SATA Chanel: Enabed
OnChip IDE Type: IDE
SATA IDE Combined Mode: Disabled
SATA EPS on all PORT: Enabled
SATA Power on all PORT: Enabled

・Advanced => IDE Configuration:
SATA Controller Mode: AHCI
Embedded SATA Link Rate: Auto
Drive Write Cache: Enable

https://mevius.5ch.net/test/read.cgi/hard/1468533309/670-n

5ちゃんねるでも同じような記載のスレ。


・・・というわけで、具体的にこんな感じになりました、という画面キャプチャを貼っておきます。

HP Microserver の電源をONして、F10 キーを押していると、BIOS 画面が表示され、こんな感じになっています。
ベースは ID: 041、2013/10/01 バージョンですね。


最初に、"Load Optimal Defaults" を実行します。


[Chipset] => [South Bridge Configuration] から、、、


[SB SATA Configuration] を選択して、、、


上記で紹介した設定値の通りですが、こんな感じで設定します。
これで、一度、設定内容を保存して再起動します。


もう一度 BIOS 画面を起動させて、[Advanced] => [AHCI Configuration] から、、、


こんな感じで、"Port 5" ( ODD 用の SATA ポート) でハードディスクが認識されていることが確認できました。


もし、うまくいかない場合は、[Advanced] => [IDE Configuration] あたりから、

  • SATA Controller Mode
  • Embedded SATA Link Rate

あたりの設定も確認してみてください。


こんな感じで、Cent OS 8 のインストーラで確認したところ、無事 ODD 用の SATA ポート のハードディスクも認識されていました!

これで、OS インストールできそうなので、その3に続きます。

それでは! =͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́

あわせて読みたい

その3を書きました。


HP Microserver N54L セットアップ日記 その1 - メモリ・ディスク・NICの取り付け

久しぶりに家の NAS をリプレースしています。

我が家には複数台のファイルサーバがあり、最古のものは Pentium 3 を積んだほぼ引退しているものなのですが、2番目に古いもの (HP ML115 G1) が現役で動いており、もう2度ほど電源は交換したのですが、まだ現役で動いています。

その2番目に古いファイルサーバ (HP ML115 G1) は、この時に買ったうちの1台で、高かった方 (Opteron 積んでるやつ) ですね。もう12年前とかw

で、10年以上使っていて、すでに電源が2回ほど壊れている事を受けて、そのうちリプレースしようと、随分前に、たたき売り (1万円くらいだったと思います) されていた、同じく HP 製の Microserver N54L を買っていたのですが、随分眠らせてしまっていました・・・。

で、とうとう ML115 G1 のファイルサーバの容量が厳しくなってきたので、一部のファイルを移行すべく、HP Microserver N54L の出番と相成りました。

開梱・開封

HP Microserver N54L

この通り、届いたままの状態で眠っておりました・・・w
まるで冬眠から目覚めるかのような開梱です。尚、冬眠からの目覚めといっても、開けたのは2019年末で冬ですが・・・w


HP Microserver N54L

この通り、新品です。新品の機械の匂い。かをり。


HP Microserver N54L

本体はこんな感じです。Microserver なのでこじんまりとした筐体になっています。

カスタマイズのため中身を取り出す

HP Microserver N54L

正面のパネルは付属している鍵で開けます。


HP Microserver N54L

上のパネルを取り外すと、5インチベイが出現。ここにもディスクを入れる。


HP Microserver N54L

下部の留め具を回して外し、傷つけないように気をつけながら、各種ケーブルをゆっくり抜いていきます。


HP Microserver N54L

(元に戻せるように注意しながら)ケーブルを外せたら、マザーボードの基盤部分がスライドして取り出せるようになります。

メモリとNICを取り付け

HP Microserver N54L

転がっていた Hynix 製のメモリ2枚と Intel 製の NIC を取り付けました。


HP Microserver N54L

5インチベイにもディスクを取り付けるつもりなので、マザーボードの ODD 用の SATA ポートに SATA ケーブルを取り付け、筐体内を這わせます。
ODD 用の電源が4ピンのものがあるので、SATA 用電源の変換ケーブルをあわせて取り付け。

マザーボードから抜いたケーブルを再度つけて、元に戻して完了です。

ハードディスクと USB メモリの取り付け

HP Microserver N54L + Disk x5

ハードディスクを5本取り付けるので、準備しました。
4本はマウンタをかぶせて、所定の場所に取り付け。


3.5" HDD => 5.25" 変換ブラケット

5インチベイへの取り付けは、こういう3.5インチ -> 5.25インチの変換ブラケットを使います。


HP Microserver N54L

最後に、マザーボードから生えている USB ソケットに、USB メモリを刺しました。ここに OS をインストールして、ブート用のデバイスにするつもりです。(5本のハードディスクはデータ置き場に専念)

追記その1

HP USB Flash Drive 64GB

↑で取り付けた、余り物の USB メモリの容量が心許なかったところ、Amazon のタイムセールで HP の USB メモリ (64GB) がお安くなっていたので購入。


HP Microserver N54L with USB Flash Drive

割とコンパクト目なサイズで取り付けたところこんな感じでした。実際に OS インストールの際など、それなりの書き込みが繰り返された後でも、全然熱くならず問題なさそう。エアフローも良いのかもしれません。

追記その2

上記で取り付けた、HP の USB メモリですが、Write が遅くてルートファイルシステム用としては使い物にならなかったため、元の USB メモリ (Transcend製) に戻しました・・・。


・・・こんな感じで、物理作業はおしまいです。

本当は背面の eSATA ポートも使って、6本構成にしてみようかとも思ったのですが、シンプルに5本でいくことにします。


そんなこんなで、さあ OS インストール!といきたいところでしたが、実はまだ問題が残っていたので、その2に続きます・・・。

それでは! =͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́

あわせて読みたい

その2を書きました。

Amazon Echo で "GOING 2 DANCE" を再生する (認識してもらう)

何の変哲もないタイトルでそれがどうした?というネタかもしれませんが、再生するために少し変化球を投げたという話。

TRF の GOING 2 DANCE という曲をご存知ですかね。
TRF のデビュー曲なので、要は懐メロなんですが、こういう曲です。


さて、この前久しぶりに聴きたくなったので、我が家の Amazon Echo Plus に向かって、「アレクサ、TRF の GOING 2 DANCE をかけて」とお願いしたのですが、私の滑舌が悪いのか、なかなかご理解いただけず、再生できるまでに4〜5回繰り返し話しかけることになりました。

私は「ゴーイング・トゥー・ダンス」と発音している (つもり) なのですが、なかなか Alexa 様が認識してくれません。「トゥー」のところを「ツー」と言ってみたり、色々発音のバリエーションを試してみましたが、全然改善しなく、相変わらず、認識してもらえる成功率は 20〜30% くらいで、なんて滑舌が悪いのかw


で、、、試しに発想をかえてヤケクソで「ゴーイング・・ダンス」と言ってみたら、一発で認識してもらえましたwww
Amazon Echo からは「ゴーイング・トゥー・ダンスを再生します」と返ってきて曲が流れ出すので、きちんと認識してくれています。
この言い方に変えることで、百発百中で再生できるようになりました。


ということで、リクエストしたいタイトル (曲名) に、英語読みの "数字" が入っている場合などは、思い切って、そこだけ日本語読みしてみると良いかもしれませんよ、というだけの話でした。

それでは! =͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́


TRF 20TH Anniversary COMPLETE SINGLE BEST (AL3枚組+DVD)

TRF 20TH Anniversary COMPLETE SINGLE BEST (AL3枚組+DVD)

  • アーティスト:TRF
  • 出版社/メーカー: avex trax
  • 発売日: 2012/11/21
  • メディア: CD

先頭がハイフン ("-") のメールアドレスを Postfix で扱う

※ このエントリは、はてなグループ終了に伴う、サブブログからの引越エントリ(2016/04)です。
※ 情報が古い可能性もありますので、ご留意ください。



Postfix のデフォルト設定では、下記の理由でメールアドレスの先頭がハイフンのメールを送信することが認められていない。

ので、送信しようとすると以下のエラーがログに出力される。

warning: Illegal address syntax from hostname[10.xx.xx.xx] in RCPT command: <-xxxxxx@example.com>


許容する場合は、以下の設定を main.cf に入れる。そしてプロセスを reload して完了。

allow_min_user = yes

allow_min_user (デフォルト: no)

受信者アドレスが最初の文字として `-' を持つことを許可します。コマンドラインでEメールアドレスを渡すソフトウェアでの事故を避けるため、デフォルトではこれを認めません。そのようなソフトウェアは悪意のあるアドレスと正しいコマンドラインオプションを区別できないでしょう。これは "--" オプションターミネータをコマンドラインに入れることで防げますが、一貫して全体に強制するのは困難です。

Postfix設定パラメータ

allow_min_user (default: no)

Allow a sender or recipient address to have `-' as the first character. By default, this is not allowed, to avoid accidents with software that passes email addresses via the command line. Such software would not be able to distinguish a malicious address from a bona fide command-line option. Although this can be prevented by inserting a "--" option terminator into the command line, this is difficult to enforce consistently and globally.

As of Postfix version 2.5, this feature is implemented by trivial-rewrite(8). With earlier versions this feature was implemented by qmgr(8) and was limited to recipient addresses only.

Postfix Configuration Parameters

デブサミ2020「グランブルーファンタジーを支えるサーバーサイドの技術」講演メモ #devsumi

この界隈から大分離れてしまっているので、話を聞いてきました。

所感としては、徹底して計測からの改善をやっていて、当たり前のことを当たり前にやることを実行していて、素直に凄いと思いました。

登壇者

  • 小松 美穂 氏
    • Cygames サーバサイドエンジニア サブマネージャ
  • 大橋 庸 氏
    • Cygames サーバサイドエンジニア

グランブルーファンタジー

  • 高いアップデート頻度が特長
    • 仲間キャラは590人
    • 武器は2000種以上
    • 多くのイベント開催

サーバの現状

  • LAMP環境
    • Linux/Apache/MySQL/PHP
  • ユーザ数2500万人突破
  • リクエスト数15億/日
    • Yahooのトップページ級のアクセス(そうでしたっけ・・・?)
  • アクセスが多い理由
    • ブラウザゲーム=ユーザの操作ごとに通信している
  • アクセスが特に増える日がある
    • 平常時:15億/日
    • 「古戦場」時:40億/日
    • ピーク時は、28万リクエスト/秒

「決戦!星の古戦場」とは

  • 定期開催のゲームイベント
  • 開始後からリクエストが急増
    • 秒間28万リクエストに達する
  • トラブル事例
    • LB(BIG-IP)のCPU使用率が100%に到達
      • 急遽L7=>L4に切り戻し
    • MyQLのbuffer poolが枯渇しそうになる
      • メンテナンスでパラメータ変更

少しでも早く気がつき、ボトルネックを取り除くことが必要

古戦場を乗り切る運用体制

サーバ運用の3本柱

  • 1. 万全の準備
  • 2. 見守り
  • 3. トラブル対応

1. 万全の準備

  • 変化を予想し備えることが大切
    • 前回観測された各種情報(ユーザ数変化、遊び方変化など)から、必要な対応を決めていく
    • 計測 <-> 修正を繰り返す
  • 前回開催のリクエスト数・ユーザ数と比較し、現在のユーザ数・ユーザ層の差異・イベントの差異など

2. 見守り

  • 機能の見守り
    • 不具合に気づく
  • 負荷の見守り
    • 瞬間的な事象
    • トレンド
  • 課題を見落とさないために
    • 複数のツールを活用
    • デブサミ2017の発表資料を見ればわかるよ!

  • 実際に活躍しているツール
    • Mackrel
    • kibana
    • Newrelic
    • Percona Management Monitor
    • Xhprof
    • BigQuery
    • Datadog
    • 自動監視

3. トラブル対応

  • Cygamesでは「CS最優先」
    • 障害発生時であっても、ユーザへの影響を最小にしたい
  • 迅速に障害を取り除く
    • 事象・ユーザ影響の把握
    • チーム内での情報の共有
    • 問題の切り分け
    • 作業の分担

当たり前のことを当たり前に徹底的にやっていくのが大切

古戦場の2つの技術的改善

  • 短期的
    • 発生したトラブルを解消し、ユーザに迷惑をかけない
  • 中長期の改善
    • その場限りではなく未来を見せた改善
    • ユーザに快適に遊んでもらい、最高のコンテンツを提供する
  • 中長期の改善を大事にする
    • よりよいプレー環境の実現
      • 軽快なレスポンスのために継続的にチューニング
    • トラブルを未然に防ぐ
      • レスポンス悪化によって、DBは障害リスクが高まるため、継続的にチューニング

チューニングの考え方

チューニングはざっくり以下の種類がある

  • DBクエリ
  • 各種サーバ設定
  • Webサーバ
  • プログラム

今日はプログラムにフォーカスして話をする
その上で、5つのポイントを紹介

1. 聖域を作らない

  • チューニング対象に壁を作らない
    • フレームワークやライブラリも対象
    • HWやMWも関係各所と連携

2. 現象と原因

  • 発見した現象を深く追求し原因を特定する
    • MWのソースコードまで必要であれば追求することも

3. 変化に追従する

  • ユーザ行動による変化
    • イベント中、バトル・終了直後にアイテム・プレゼントに負荷が集中

4. 手段の選択

  • 目的を踏まえた上で選択
    • 基本はデータ構造とロジックの調整
    • スケールアウトは選択肢の1つ
  • 長期運用のメリット
    • 「性能を引き出すことができ」「限界を知っている」から、適切に選択することが可能

5. チューニングの落とし穴

  • 銀の弾丸はない
    • 新しい技術でも、その性能を引き出せなければ解決策にはならない
  • チューニングしたら終わりではない
    • 新たなボトルネックが出現し、新たな戦いが始まる

チューニングの事例

  • フレームワークの変更
    • ハイリスク:影響範囲が広い
    • 改善の意識が希薄になり見落としがち
    • ハイリターン:影響範囲が広い
  • 古戦場系APIのフレームワークのwalltimeを観察すると、ORM参照で 84,713μsec
    • ここが重いと判断(ただし重いという基準を作るのが難しい
  • ORMクラスの生成処理では、オブジェクト関係マッピングも9,206μsec
  • ORMまわり
    • 厳密な型チェックと変換ロジック
    • Compositeパターン(FK参照先まで)
    • 上記を実現するための複雑なデータ構造
    • それらが要因となり必須になっているメソッド呼び出し
  • MySQLの性能を引き出すために以下を意識している
    • 外部キーを利用しない
    • サブクエリや結合を利用しない
    • テーブル数(データ数)が非常に多い
    • 参照回数が数百から数千に上ることも
    • これらのグランブルファンタジーの特性に、ORMが適していない
  • ORMのチューニング
    • 目標を明確にする
      • グラブル特性に最適なORMの作成
  • 作りたいORMの要件定義
    • 最速であること、シンプルであること
    • ORMとしての扱いやすさを変えない
      • ゲームプログラミングになるべく影響を出さない
      • 内部構造は変えてもインターフェースは変えない
    • 概要設計
      • ORM内部データ構造の再設計
      • 照をインスタンス変数アクセスに変更
      • 利用しない機能を捨てる
      • ORM Generator で実装社の負担低減
  • ORM作ってみた
    • walltimeの前後比較
      • 前を100とすると、、、
      • 後は、データ参照は0.3、オブジェクト関係マッピングは2.5
    • かなりよくなった
  • 新しいORMの成果
    • メリット
      • データ参照が最速に
      • オブジェクト関係マッピングも最速に
      • 古戦場以外のAPIでも良い結果に
    • デメリット
      • カプセル化の観点でベストではない
        • アプリケーションレイヤーでカバー

紹介したようなチューニングをイテレーションしているから成果が出る

皆様に「最高のコンテンツ」お届けするために...

  • 怯まずにチューニングする
  • コア技術は自分たちで実装する

参考: Developers Summit 2017 でのグランブルファンタジー関連の講演

あわせて読みたい




デブサミ2020「レガシーコードからの脱却」講演メモ #devsumi

登壇者

  • 吉羽 龍太郎 氏
  • アトラクタ
    • 取締役CTO

レガシーコードからの脱却

レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス

レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス

  • 作者:David Scott Bernstein
  • 出版社/メーカー: オライリージャパン
  • 発売日: 2019/09/19
  • メディア: 単行本(ソフトカバー)

  • ITエンジニア本大賞2020(技術書部門)で受賞!
  • 「レガシーコード」というワードをタイトルにつけると書籍は売れるらしいw

レガシーコードとは

  • レガシーコードとは?
    • 綺麗なコードは有用だが、テストがなければレガシーだ
    • 保守または拡張が困難なコード
    • 定義は様々
      • 議論の時はまず共通認識をとるのが大事
    • 理由は問わず、修正・拡張が難しいコード
  • 使われるソフトウェアには変更が必要になる
    • ほぼ80%の開発コストを障害の特定や修正のために使われている
    • 原因は急ぎすぎている、たくさん作ろうとしている、読みやすさより書きやすさを優先している
      • つまり品質を犠牲にしている
      • 品質は検査ではよくならない、最後にテストしても仕方ない
  • やるべきことは問題を作り込まないこと、つまりレガシーコードを作らない
  • ではどうしたらいいか -> 開発プロセスに着目する
  • ソフトウェアを生み出す成果を決める要素
    • 問題設定力
    • 開発力
    • チーム力(組織力)
  • コードだけ綺麗に書いたり、開発プロセスだけちゃんとやっていればよいわけではない
  • レガシーコードを最初から作らないようにするには、具体的にはどうすれば?
  • レガシーコードを作らない9つのプラクティス
    • やり方より先に目的・理由・誰のためかを伝える
    • 小さなバッチ(単位)で作る
    • 継続的に統合する
    • お互い協力し合う
    • CLEANコードを作る
    • まずテストを書く
    • テストでふるまいを例示する
    • 設計は最後に行う
    • レガシーコードをリファクタリングする

ScrumとXPからプラクティスが抽出されている。

やり方より先に目的・理由・誰のためかを伝える

  • 役割の違い
    • プロダクトオーナーの責任
    • 開発チームの責任
  • WhatとHowを分断する
    • 何を欲しいか、なぜ欲しいか(What)は顧客やPOの領域
    • やり方(How)は開発チームの役割
      • 物事のやり方は1つではなく、やり方ごとにトレードオフがある
      • やり方を命じされると代替案が出せなくなる
      • 結果として手続き的なコードになりがち(結果的にオブジェクト指向にならない)
    • 双方が創造的に協調することで無駄が減る
    • 作る上で重要なのはコンテキストを共有すること
  • ユーザーストーリー
    • 何が・何のために・誰のために存在するかを1文で示したもの
    • 機能について会話できるくらいの辛うじて十分なドキュメント(仕様書じゃない
    • 知識はドキィメントではなく、コード(テストも含)にまとめるべき
    • ストーリーが限定的でテスト可能になる(受け入れ基準と自動化)
    • シンプルにまとめて追加はあとで行う
      • ちょっとずつ進めることで良い設計が浮かび上がってくる

小さなバッチで作る

  • 鉄の三角形(Quality, Cost, Deliverly, Scope)
    • 同時に守れるのは2つまでと言われる
    • Qは落とすべきではない
  • QCDSの何を調整するか
    • Q(品質)を下げると、あとで何倍もの時間を使うことがある
    • C(コスト)を調整するとは、すなわち人を増やすことにつながる
      • ただし人を増やしても、オーバーヘッドがあるのでリニアにスケールしない
    • D(時間)を調整してもよいが、多くのビジネスは時間が重要
    • つまり一番調整すべきなのは「スコープ」
      • およそ半分の機能はほとんど使われていない
      • スコープを調整して価値(大事)のあるものが順に進める
  • タイムボックスによるアプローチ
    • 固定の期間の中でタスクに取り組む
      • ex.) 1 week
    • タスクの分割になれるまでは機能しやすい
    • ScrumやXPのやり方
  • 長い期間で大きなウソをつくのではなく、短いイテレーションで小さなウソをつく
  • 同じリズムを刻むことで負担を少なくして、異常に気づく
    • 日々の仕事も同じ
  • リソース効率とプロセス効率
    • 1サイクルのリズムが長くなると、リソース効率化を目指しやすい
      • 並行タスク・役割分担・フェーズが増える
    • 1サイクルのリズムを短くすると、プロセス効率が上がる
      • モブプロ=究極の1個流し
      • いくら人を働かせても、完成しているものが0なら、ビジネス価値はない
      • 難しそうなバックログはモブで、など結構モブを使っている現場は増えている
  • ソフトウェアの評価
    • ソフトウェアの評価は顧客にとっての価値
      • 価値は完成してはじめて価値になる
      • 部分最適化を避ける
    • 効率より効果を重視
  • フィードバックサイクル
    • 小さなバッチの方がフィードバックの回数は増える
      • スプリントレビュー、レトロスペクティブ...
      • 顧客やPOと同席することでフィードバックの回数を増やす
      • そのためにビルドの高速化も大事
    • フィードバックへの対応をサポートする文化が必要
      • 価値やリスクに応じて取捨選択する

フィードバックによって価値を高めていく

CLEANコードを作る

  • 品質は検査では上がらない
  • よくないコードの特徴
    • 重複コード、長すぎるコード、巨大なクラス、長すぎるパラメーターリスト...
  • よくない例をあげるとキリがないので、模範になるパターンを覚える
  • CLEANコードとは?
    • Cohesive (凝集性)
      • それぞれの部品は1つのことだけ扱い、1つに集中する
      • 理解もバグも見つけるのが簡単
    • Loosely Coupled (疎結合)
      • オブジェクト間の関係を明確な意図を持った状態に保つ
      • テストや再利用、拡張が簡単
    • Encapsulated (カプセル化)
      • 何をやっているかに名前をつけて、どう動くかは隠す
      • あとから変更するのが簡単
    • Assertive (断定的)
      • 好奇心旺盛を避ける
    • Non redundant (非冗長)
      • 同じことを繰り返さない(DRY原則)
      • バグ修正・変更は1箇所で1回だけすればよい
  • よいソフトウェアの土台となる5つのこと
  • これらを意識するとテストしやすくなる
  • CLEANとテストでバグ発見の時期をシフトレフトする
    • 設計の段階でバグを見つければ5分で修正できる
    • テストの段階だと修正に1日、、、本番リリース後だと数日、、、
    • そうならないようになるべく早期からテスト可能な状態にする
  • 明日のベロシティのために、今日品質を上げる
    • 速度は日々の積み重ねでしか早くならない
    • CLEANコードは理解しやすく取り組みやすい
    • 結果として総所有コストが下がる、逆の状態が技術的負債
  • すばやく働くということは「きれいに働く」ということ
  • これって"5S"だった
    • 整理、整頓、清掃、清潔、躾

レガシーコードからの脱却まとめ

  • 使われるソフトウェアは変更が必要になるので、コードは変更可能になるように書くべき
  • プロダクトオーナーは、目的、必要な理由、誰のためのものかが伝わるようにする
  • 要求は意味のある小さな単位にして重要なものから作る
  • 開発チームは小さなバッチで作っていく、作るときはPOと協力する
  • コードはTDDで書く、テストはふるまいを例示、テストも含めてCLEANを満たすように作る
  • できあがったものは1つずつ統合していき、常にデプロイ可能な状態にする
  • 1度作ったら終わりではなく、必要に応じて設計やコードを見直す、良い設計は創発する、子のときテストがあることが重要

今日伝えたかった最重要なこと

「他にも本には色々書いてあるので買ってね」

レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス

レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス

  • 作者:David Scott Bernstein
  • 出版社/メーカー: オライリージャパン
  • 発売日: 2019/09/19
  • メディア: 単行本(ソフトカバー)

あわせて読みたい




デブサミ2020「エンジニアと人事がともに考えるエンジニア採用」講演メモ #devsumi

登壇された方

  • 【モデレーター】金山 貴泰 氏
    • うるる
    • 転職透明化らぼ コアスタッフ
  • てぃーびー(田部井 勝彦) 氏
    • スタディスト Recruit Operations
  • 伊藤 哲弥 氏
    • LAPRAS 事業開発マネージャー / PR
  • 安立 沙耶佳 氏
    • ヌーラボ 人事
    • a.k.a アンジェラ
  • 梶原 成親 氏
    • ヤプリ

市場背景について(伊藤さん)

エンジニア側から見た採用市場

  • 超売り手市場
    • 技術系(IT・通信)の求人倍率、昨年8月には11倍に。
      • 11社が1人を奪い合う状況。他職種と比べて異常事態。
    • 今後十数年は変わらない
  • IT人材需給
    • 2018年は22万人不足
    • 2030年は45万人が不足すると言われている
  • エンジニアの質
    • 課題解決型から価値創造型へ
    • 先端技術(クラウド、IoT、AI等)の活用ができるエンジニアのニーズ高
  • 一極集中の構図
    • 満遍なくスカウトがいっているわけではなく、一部に集中している
  • n数の企業から1候補者に送られたスカウトメール数は?
    • 1企業: 22% (3,321通)
    • 2〜5企業:50% (7,445通)
    • 6〜10企業: 18% (2,719通)
    • 11〜20企業: 8% (1,130通)
  • LAPRASのエンジニアDBの中で、スカウトを受け取っている人は約1%
  • 企業の採用要件も特定の技術領域に集中している

エンジニアが採用に関わるべき背景

  • 最終的な意思決定はエンジニアにある。
  • エンジニアが「選びたくなる認知」を得るのが採用の全て
  • ディスコースの階層
    • 我々の認知は階層化されたディスコースが相互に影響を及ぼしながら作られる
      • 社会文化的、コミュニティ(組織)、対人間およびグループ、個人、個人の内面

要は、エンジニアコミュニティと良い関係を築いて、自社の採用ターゲットに良いイメージを持たれないといけない。

  • カジュアル面談に誰と会いたいですか?のアンケート
    • 「人事担当者」と答えたのは6%
    • 技術がわかる人と会話したいというのが前提

ジョブディスクリプションについて(梶原さん)

  • ジョブ・ディスクリプション
    • 技術が細分化されていることもあり、最近は具体的な食内容が記載されている
    • 欧米では社員の評価などにも用いられる
    • 企業側の情報開示のひとつ
    • 業務の内容や進め方についてイメージできたら良い
  • 書いておきたいポイント
    • やっていただきたい職務
    • 採用している言語、技術
    • 応募資格
    • 歓迎要件
    • 採用にプラスされる要件
    • 人物像
    • ・・・等々(よくあるものはしっかり書く)
  • 書いてあるとなお良いもの
    • 仕事の進め方
    • 仕事で関わる人
    • 働き方、働く環境
    • 現在、直面している課題
    • 採用している背景など

やってほしいこととやりたいことのマッチング

  • 他社企業のJDをチェック
    • 30社くらいチェックすると良し悪しがみえてくる
    • 言葉の使い方
    • 転職後の業務がみえてくるかが、1つのポイント
  • 採用職種リーダーと会話する
    • どんなチームにしたいのか
    • どんな人物像の人と一緒に仕事したいのか
    • どういう仕事の進め方だと嬉しいのか
    • 一緒にスキルマップ作ってみるとか
    • 現在のチームの課題についてヒアリング
    • 足りないピースは何か?は欲しい人物像
  • これからチャレンジしたい・解決したいことを書き出す
  • チームの状態と理想の状態を定義することができる
  • リーダーとしてもチームのあり方がクリアになる
  • 採用チームとペアワークで仕上げる

作ったら終わりではない。ベストは常に変わるので都度見直すことは必要。

カジュアル面談について(安立さん)

  • nulabさんの昨年の内定決定率100%
  • エンジニアの需給バランスがおかしい!
    • 情報系の学生が市場に出てくるのは、年間4000人程度(ソースは安立さんw)

こちらから声をかけていく流れ -> そこで生まれた「カジュアル面談」

  • カジュアル面談の起源
    • Wantedly社が最初?
    • エージェント会社のオペレーションミス防止?
      • 面談か面接か、字面が一緒なので
  • カジュアル面談に行ったら「志望動機は?」と聞かれる事件
  • 実は逆パターンもある
    • 「なんで僕を採用しようと思ったんですか?」と求職者が聞くケースも
  • nulabの選考フロー
    • 80%以上の候補者が面談からスタート
    • 面談は応募前
      • カジュアル面談をすることでお見送りになることはないことを徹底

ヌーラボ式選考フローのマスト項目

  • 自社なりの面談の定義を決めて候補者に伝える
    • 面談の実施意図を定義
    • 面談で必ず候補者に伝えることをセリフレベルまで落とし込む
    • 候補者がヌーラボを理解することが大事
  • 選考フローを設計し、車内に共有する場を設ける
    • 技術面接120分、面接官3〜5名
    • 面接の事前と事後にそれぞれ30分共有する場のMTGがある
    • 誰でも参加できる採用定例MTGを実施
      • 採用に関わるメンバーの認識合わせ
    • 採用フロー・担当者・選考の役割を社内Wikiとかで共有

パネルディスカッション

採用はなぜ重要なのか?

  • プロダクト開発に直結、変な人が入ってもチームが壊れるし、採用=経営を左右するもの
  • エンジニア採用が経営課題となっている会社も多く、CEOやCTOが採用のフロントに立っていることも多い

エンジニアが採用に関わったことによる効果は?

  • 選考フローの中で、この人たちと働くことをイメージしてコミュニケーションすることで採用の確度をあげていくことができる、エンジニアとしても一緒に働く人を選ぶことができる
  • 人事だけだと良くない、人事だけのエンジニア採用はあてずっぽうみたいなもの、エンジニアが関わることがスタートライン
  • JD、スカウトメール、カジュアル面談、すべてにおいて精度が変わってくる
    • 人事がずーっとフルスタックエンジニアみたいなことを言っているとか...

活躍し続けてもらうには、入社後にどんなフォローをすべきと感じるか?

  • 活躍するところも見据えてオンボーディングする必要がある、細かい手法についてはググるとたくさん出てくる
  • ヌーラボは採用担当ではなく人事なので、精度設計や評価も含めてやっているので、入社後もあらゆる面でサポートしていくことになる

ヌーラボ120分面接を伝えた時点で辞退されないのか?

  • 辞退されることはほとんどない、面接では情報提供する場としても活用してもらっている、短くすると内定承諾率が下がってしまうのではないかと考えている

現場のエンジニアの工数が割かれているが、どういうモチベーションでやっているか?

  • 全員で採用する方針なので、そういうマインドができあがっている、皆同じフローで入ってきているので選考の時点で受け継がれている

求職者側のスキルを確認するために有効な手段は?

  • 課題解決のためのディスカッションをする、実際に課題を提示して一緒に考えてもらう、短期インターンみたいな感じ
  • 考え方のロジックを問う質問をする、なぜそれをやろうとしたか、何を考えてそうしたのか、とか課題完結能力を等質問をすることが多い
  • ハードスキル、ソフトスキル、カルチャーでわける、構造化面接を試そうとしている、誰がやってもその人を引き出せるような面接、ただし難しい

内定者の希望年収と自社内相場でアンマッチした場合どうしているか?

  • 候補者の方にあわせて、提示額を動かすことは基本しない、どちらかというと相場を上げていこうという動き方をする
  • LAPRASは、ベース給与があって、事業目標を達成すると全員が100万円上がる、みたいな設計になっている、それ以外昇給はなく、それに合う人しかとっていない

参考: 昨年のデブサミのエンジニア採用関連の講演

あわせて読みたい




デブサミ2020「なぜ技術力評価会の評価者はペアなのか?ー 8年半で378組の評価者ペアが835回評価した事例からみるペアの効果」講演メモ #devsumi

登壇された方

  • 小賀 昌法 氏
  • VOYAGE GROUP
    • 取締役CTO (2010〜)
  • 日本CTO協会
    • 理事

技術力評価会

  • 2011年まで上長だけが評価する制度だった
    • 技術力評価・事業貢献
  • 現在は「ともにつくる」評価制度
    • 色々な人が色々な他の部署の人たちを評価する風に変えていった
    • 毎回、評価する対象者を変えていく

エンジニアの技術力評価

  • 難しいと思いますか?
  • 何が原因なのでしょうか?

原因1: バイアス

  • エンジニアに限らず、一般的にバイアスが働く
    • ハロー効果
    • 論理的誤差
    • 寛大化効果
    • 対比誤差
    • 中心化傾向
      • 対人関係を気にして、みんな無難に評価してしまおうとすること
    • イメージ考課
    • 極端化傾向

原因2: 技術の多様化

  • 技術が多様化しており、技術マネージャーは全ての技術においてメンバーより詳しいわけではない
    • フロントエンド、クラウド、データサイエンス、プライバシー・・・等々

原因3: 評価スキル向上機会の不足

1on1を実施している企業は多い

しかし、、、

  • 考え方を引き出すスキルを成長させる機会
  • よりよいフィードバックのための成長する機会

の仕組みかに取り組んでいる会社は少ない

原因4: 同じ人が長く評価することでの偏り

  • 優秀なマネージャーほど同じ部署に長く在籍していることが多い
  • その場合、ある側面からだけ詳細に見えているリスクはないでしょうか?

よって、各部門の責任者や各チームのマネージャだけで全てを理解することは難しい。
様々な側面からの情報を集めていくアプローチをしていくことに。

評価と人事制度

等級制度(グレード制度)

  • 経営戦略を実現するために必要な人材の定義
  • 高い等級の人が増えれば戦略を実現できる可能性が高まるように設計
  • 戦略に応じて制度を見直していく
  • エンジニア職のグレードは4段階
  • 誰がどのグレード何かは社内に公開されている
  • 軸は、事業貢献、能力、CREED (VOYAGE GROUP の価値観的なやつ)

評価制度

  • 「その人がどの等級なのか」
  • 「上の等級に上がるには何が必要か」
  • 評価を通じて成長を促す

評価制度の例 (VOYAGE GROUP)

  • 半年に1回
  • 事業貢献 x 能力 x CCFB(VG用語、360度評価のこと)

報酬制度

  • 従業員にいくら給与+賞与+αを支払うかの基準を決めておく
  • 等級制度および評価制度と密接に


報酬制度の一例

  • 年功序列
  • 均等割

技術力評価会の概要

  • エンジニアによるチームを越えた能力(技術力)評価の仕組み
  • 評価結果は昇格に大きく影響する
  • 半年に1度実施
  • 2011年から継続

コアコンセプト

チームを越えた技術力評価

評価の流れ

  • 評価者は2人
  • 他チームから評価者が選定される
    • 評価委員とCTOで
  • 被評価者には、評価委員とサポーターがつく
  • 事前準備 -> 当日 -> 後日

事前準備

  • 被評価者はサポーターに評価してもらう内容を相談
  • 必要があれば同僚にすぶりをする

評価当日

  • 被評価者のプレゼンが30分
  • 評価者との質疑応答が60分

後日

  • 評価者は結果を提出
  • 評価結果を、CTO+評価委員ですり合わせ
  • 評価者2人が対面でフィードバック
  • 結果レポートは事前に読めるようになっている

全体の流れ

  • 全体準備、ガイダンス
  • 事前準備
  • 評価当日
  • 後日フィードバック
  • 全体フィードバック
  • 全体振り返り

評価軸(2013年)

  • 実現力
    • スコープ定義
    • システム構築・運用
    • プロジェクトマネジメント
  • 改善力
    • システム的な改善
    • ビジネス的な改善

その他

  • 2年間で、8人以上から評価されることとなる
  • 2015年から点数を廃止し、文章をしっかり書くスタイルに
  • githubで評価結果を社内公開
    • 2020/2時点で、1050以上の結果レポートが社内公開されている
    • 新しいマネージャーなどもメンバーの過去の評価結果を参考にできる

社外評価者

  • 社外から強い人を招聘
  • 社内評価者2人+社外評価者の3名で評価
  • 新しい視点や気づきを得られる機会を増やす
  • 自分たちでは気づけないバイアスを知りたい
  • (社外評価者はこんな方に見てもらっているよ〜、という参考情報が出たが、SNS公開はNGとのこと)

ペアで評価すること、組み合わせを毎回変えることの効果

バイアスの対策

  • 評価者の変更
  • 複数による評価
    • アンケートもとってバイアスが減ったと感じた方が多かった

技術の多様化の対策

  • 被評価者の強みに合わせて評価者をアサイン
    • 被評価者の強みに合わせて、その技術に強い人をアサイン
    • 上記の人の弱みを保管できる人とペアを組む
    • 社内にいない場合は社外から招聘

評価スキル向上機会の不足の対策

  • 複数の立場で評価結果をすりあわせ
    • 評価者ペアは結果をすり合わせる
    • さらにCTO+評価委員の4人ですりあわせを行う

評価者の声 - ペアによる評価スキル向上

  • 他の評価者の考え方がわかるような場
  • 自分が効かない角度の質問が出ると学びになる
  • 着眼点の違いに気づくことができた
  • 地震の評価が客観的で論理的であるか、評価の軸がずれていないかなど、確認するようになった

同じ人が長く評価することによる偏りの対策

  • 技術力評価会の評価者は毎回異なる

評価者の声 - 良かった点

  • 関わりの少ない人と接する機会
  • 伝え方が良くなったり、具体的になったりする
  • 一緒に評価した人と価値観のやりとりをするので仲良くなることが多そう
  • 他部署のエンジニアと接点が増える
  • 上長以外の視点を入れられる
  • 責任を適度に分散できるので、自分を棚上げしていろいろということができる

評価者の声 - 悪い点

  • 日程調整コスト
  • ペア評価者の価値観に引っ張られる懸念
  • 一方の評価者の質疑応答が長くなって、他方の質疑応答が十分にできない
  • 評価者ペアの考えがばらけていると、被評価者が混乱する可能性

まとめ

評価者をペアにし、組み合わせを毎回変更し、「ともにつくる」ことは大きな効果がありました。

宣伝

  • ajito.fm っていうPodcastやってるよー!
  • VOYAGE GROUP TECH TALK Vol.2 やりますよー!

あわせて読みたい