rocky

【剣盾S17シングル】保険カイオーガもやれるはず-最終1953位/レート1756

LAPRAS夏の自由研究リレー - 8/24枠の記事です。自由研究リレーとはその名の通り、LAPRASのメンバーが自由研究したことを次々にアウトプットしていくというもので、すでに沢山の記事が公開されています。ぜひご覧ください。ちなみに当エントリは自由研究と言いつつも「趣味で作った作品の開発ログ + 申し訳程度の技術Tips」という構成になっています。小学生や中学生の自由研究においても、特に何かを研究をするわけでもなくただ単に工作だけしてお茶を濁すというのはよくある話です。あなたのお友達にもいたはずです。このエントリもそんな工作枠として受け入れられることを祈っています。それでは本編です。背景2019.11.15にポケモン最新作「ソード&シールド」が発売された。自分は金銀以降まったくプレイしていなかったのだが、弊社CTOの @showwin がこの日のために休みをとっていたのを見て試しに買ってみたら、見事に対戦沼にはまってしまった。やるからには当然勝ちたいという欲望が湧いてくるのだが、ここ20年でポケモンは数もシステムも様変わりしており、もう自分の知っているポケモンではなくなっていた。このギャップを埋めるためにはとにかく多く対戦経験を積む必要があった。Switchよりも手軽に、コッソリとポケモンバトルができる状態を作る対戦経験を積むといっても時間は無限にあるわけではない。仕事もあれば子供もいる。隙間時間でササッとポケモンができれば、ながら対戦ができれば、もっと効率よく場数を踏めると考えた。そのために以下の課題を解決する必要があった。スマホは余裕でいじれるがSwitch本体の操作は無理というシチュエーションが多い最近の子供の寝かしつけはほぼ隣で横たわっているだけで、光さえ枕で遮断すればスマホは問題ないSwitchをやっていると完全にゲームをやっているとバレて無邪気な攻撃をうけるSwitchをやっていないときでも、無秩序に攻撃が飛んでくることがある攻撃をうけると一時的に画面を見られない状態になる子供のオムツ関連事故が発生したときにも、一時的に画面を見られない時間が生じるながらでやったとしても、選出や立ち回り、ダメージ感覚はあとから振り返りたい30過ぎたおじさんが満員電車でSwitchでポケモンをやっていたら物理的にも精神的にも迷惑をかけそうだった （これは通勤自体が消滅したので解決した電車の中で電波が不安定になった時に対戦切断扱いになるのが怖かった （これは通勤自体が消滅したので解決したSwitchよりも手軽に、コッソリとポケモンバトルができる状態を作ることでこれを解決していくことにする。作ったものというわけで出来上がったのが「ポケモン剣盾のランクマッチにスマホで潜れる装置」だ。これを使えば子供の寝かしつけ時や、キッズランド等での付き添い時、電車での移動中、駐車場で買い物待機をしている間にもコッソリとポケモンの修行ができる。普通にポケモン対戦をすることができる機能に加え、テキスト読み上げやメッセージログ表示など、ながら作業をしていても情報を逃すことがないようなアシスト機能を備えている。AirPods等のイヤホンをつけて使うことを想定している。特徴手軽スマホのサイズと操作性操作手順の削減ずっと集中していなくても重要な情報を落とさない情報表示コッソリスマホは多用途なのでバレないイヤホンをつけて戦況を音声読み上げで把握するなども可能その他あとで振り返ることができるための、選出、使用した技、入ったダメージ等のロギング仕組み仕組みを簡単に説明すると以下のようになる。詳しいやり方は「作り方」を見ていただきたい。スマホで操作をするとインターネット経由でPCに繋げているSwitchにコマンドが送られ、実行されるSwitchの映像をキャプチャボードを使ってPC側で読み取り、しかるべき解析をしたのちに要所の画像をスマホに送って表示する基本機能基本的な画面構成は、選出、行動選択、その他の３つ。順に紹介していく。選出「画面上で選出したいポケモンにチェックを入れる」->「確定」の操作をすると、あとはそのとおりにSwitchにコマンドを送ってくれる。初めはSwitchの各種ボタンを一つ一つ押す操作をすれば問題ないだろうと考えていたが、操作に時間がかかり過ぎて選出を時間内に完了できないケースが多発したため、このような形になった。動きはこのGIFアニメのようなイメージ(右側にあるのがスマホの録画)右下のスマホ画面で「確定」を選んだ後にSwitch側で選出操作が行われているのがわかる。このときアイコンの画像認識で相手のポケモンの一覧も画像から判定しており、対戦中の動画解析結果と合わせることで自分と相手それぞれの選出のログを残せるようになっている。行動選択こちらもSwitchの操作一つ一つを入力する方式ではなく、利用できる技や入れ替えたいポケモンを直接選択できるようにしている。ダイマックスもできる。その他非戦闘中における操作は特別なUIを設けず、Switchのボタンを一つ一つWeb上に用意することにした。行動選択や選出のUIで不備がでた場合のバックアップとしても使っている(それから「降参」のための操作も実装していないので、降参したい場合はこれを使う)。以下の画像で一瞬でイメージは湧くと思う。対戦ログ自分の選出、相手の選出、使った技、誰にダイマックスを切ったかなどをログに残しくれて、あとから振り返ることができる。正直これは開発をしていたら面白くなってしまって、あれもできるならこれも...とやっていった中で出来上がったものなので、解決したい課題に対して特にクリティカルには効いていない。(PC向けのバトルアシストツールを作っているのでそちらには応用する気満々)## 自分- ドラパルト[先発]  - ドラゴンアロー,ゴーストダイブ- ドリュウズ[dymax]  - ダイスチル- バンギラス  - ステルスロック,でんじは,がんせきふうじ,## 相手- ドリュウズ[先発]  - じしん,- カバルドン  - ステルスロック,ほえる,あくび,- ラプラス[dymax]  - キョダイセンリツ,ダイストリーム,なみのり,ダメージログ2ターン目-[自分の] ドラパルトがカバルドンにドラゴンアロー - 57% のダメージ3ターン目-[相手の] カバルドンがバンギラスにステルスロック -4ターン目-[自分の] バンギラスがカバルドンにステルスロック --[相手の] カバルドンがバンギラスにほえる -5ターン目-[自分の] ドラパルトがカバルドンにゴーストダイブ --[相手の] カバルドンがドラパルトにあくび -6ターン目-[自分の] ドラパルトがカバルドンにゴーストダイブ - 8%(以上) のダメージ7ターン目-[自分の] ドラパルトがラプラスにゴーストダイブ --[相手の] ラプラスがドラパルトにキョダイセンリツ -8ターン目-[自分の] ドラパルトがラプラスにゴーストダイブ - 35% のダメージ-[相手の] ラプラスがドラパルトにキョダイセンリツ - 88%(以上) のダメージ9ターン目-[自分の] バンギラスがラプラスにでんじは --[相手の] ラプラスがバンギラスにダイストリーム - 59% のダメージ10ターン目(9)-[自分の] バンギラスがラプラスにがんせきふうじ - 26% のダメージ-[相手の] ラプラスがパ のンギラスになみのり - 24%(以上) のダメージながら対戦アシスト機能操作可能時サウンドアラート操作する必要があるシチュエーションになったら「ピコ!」と音を鳴らしてくれる。具体的には、対戦相手がみつかって選出画面に遷移したとき、新しいターンに入って行動を選択できるようになったとき、ポケモンが倒されてポケモンを変えなければならないとき、の３つのシチュエーションで音がなる。ながらでやっているので必須。そもそも普通に公式にも実装して欲しい機能でもある。ちなみに ON/OFFが可能。バトルメッセージログ表示公式に実装して欲しい機能その2。戦闘中に表示されたメッセージのログを見ることができる。ながらで対戦をしているので、画面をずっと見ているわけにはいかない。見ていない間に何が起こったのかが分からないと行動を選択することができないので必須(そもそも普通に対戦していても相手の特性を見逃していて焦ったりする)テキスト読み上げバトルメッセージをText2Speechで音声読み上げしてくれる機能。ON/OFFが可能(流石に)いかにバトルメッセージのログを見られるとはいえ、行動決定に許された時間はわずか45秒。できればターンが回ってきたそのときには現状を把握している状態が望ましい。ながら対戦では画面をずっと見ておくことはできないので、音声読み上げでこれを補う。子供の寝かしつけのとき、公園で遊んでいるときなどなど、非常に重宝した。作り方 / 開発記録ここからは全体の構造や利用している技術、開発時に課題となり工夫を要した箇所などについて触れていく。PCでSwitchを操作できるようにする多くのサイトで紹介されているように Arduino LEONARDでSwitchを操作できるようにするとともに、ＦＴ２３２ＲＬ　ＵＳＢシリアル変換モジュールを組み合わせて、そのArduinoに対してPCからUSBシリアル通信で命令を送れるようにしている。Switchの映像をPCに取り込む普通にキャプチャボードを使ってHDMI経由で映像をPCに取り込む。ちなみにキャプチャボードはこれを買った。今回は下心としてWebで画像解析の真似事などをしてみたいという欲求もあったので、Webで実装した。以下のように、Webカメラの映像を取り込む時となんら変わりない方法で映像を取得できる。全体構成これらに、サーバサイド画像解析等々を加えるとこんな感じになる。CLOUDAppサーバ (Node.js / Socket.io)Arduino LEONARDO + USBシリアルモジュールシリアル通信で受け取った命令をSwitchにバイパスするPCSwitch操作アプリ(Node.js)Socket.ioメッセージ <=> USBシリアル通信変換app動画解析機(Webフロント)画像解析 / OCR等踏み台 サーバ(Node.js)スマホスマホコントローラ(Webフロント)各プレイヤーのやり取りは、動画解析機と画像解析サーバ間を除いて全てSocket.ioで行なっている。書く前から感じていたが、これは図にしないとだめ。戦況解析先に紹介したUIを実現するには、どの画面が表示されているか、技やポケモンの選択肢、ダイマックス可否などを映像から判定する必要がある。これらの大半はフロントエンドで判定をしている。OpenCV.js等を使うと重さに耐えられなかった(バトルメッセージの表示速度を鑑みると解析頻度は10FPSは欲しい)のと、興味もあったので生のCanvas、特にUint8ClampedArrayなどのナマモノををかなり触った。開発方法 - 機械学習の中の人を人力でやる最初に一気にテストコードを書いて、期待の判定になるようにルールを書いていった。テストデータは何戦か録画をして、そこから判定したいシチュエーションの画像を抽出して得た。こんな画像を用意してこんなテストコードを書いてdescribe("getHp", () => {  it("画面から相手と自分のポケモンのHPを読み取る(%)", () => {    testCases.forEach((testCase) => {      const ctx = getDrawedCanvas(testCase.file);      const result = getHp(ctx);      expect(result.myHp).toEqual(30)      expect(result.opposingHp).toEqual(74)    });  });});あとはひたすらにロジックの中身を書き続ける。ちなみにHPの判定はHPバーにしめる緑色/黄色/赤色ではない色の割合でパーセンテージを出している。辛いところいくら直接HDMIから取り込んでいるからといっても、リアルタイムにエンコードしている関係上、画像の数値は同じ画面でも、同じメッセージ表示でも完全にピクセルの数値が一致することはない。黒い部分でも白い部分との境界近くではグレーに近づいたりなどもする。画面の判定(本当はもっとあるが）画面の種類としては主に以下のどれが表示されているかを判定する必要があった。これに関しても各画面で特徴的な部分のルールを書いて対処している（例えばバトルメッセージ表示中の判定は、適当に2値下して、下の方は黒だが、全体は黒ではなく、メッセージが表示される領域がxx%以上黒ドットではない、のような泥臭いロジックを書いている）。これもあらかじめ全ケースをテストコードを書いておくことで、精度を上げるために他の画面と誤検知した〜などの事故を起こさずに実装することができた。（そろそろ限界だけど）戦闘待機画面選出画面(相手側表示/非相手側表示)行動選択画面技選択ポケモン選択バトルメッセージ表示中か否かポケモンのステータスやHPの変化を取得してもよい画面か否かOCRポケモンの名前、技の名前など、文字の検出にはGoogle Cloud VisionのOCRを使っている。お金がかかるので、少しでもリクエスト回数を減らすためにローカルの画像処理で可能な限り重複リクエストを避けるようにしたり、複数の言語が混じっている場合(相手のポケモンが海外産だと名前も英語になる)でも精度を下げないような前処理を入れたりするなどの工夫をしている。今はおおよそ1マッチ100リクエスト程度(多分10円以下)。この辺りについては機会があればまとめておきたい。複数の言語が混じっている場合への対処だけに触れるとこういうのを...このように、スペースが空いているところを改行に見えるように画像を加工してからAPIを叩いてあげると飛躍的に精度が向上したりする。こうすることで、戦況ログを保存するにあたっては十分な制度が得られた（逆にうまくいかなければおそらく作れなかった）その他機能音/テキスト読み上げ音声の再生はWeb Audio API、テキスト読み上げはChromeのWeb Speech APIを使っている。特筆することは特にないが、iOSではテキスト読み上げ機能はChromeのみで使用できる。ゆえにHome画面にショートカットを置いて起動した場合などには使えない。本編終了おしまいおわりに以上でスマホでSwitchを操作してポケモンランクマッチに潜るための装置の紹介を一旦終わります。読んでいただいた方、ありがとうございました。予告した通り、開発記録+申し訳程度の開発Tipsだったとは思いますが、割と興味本位で無茶に無駄に工数をかけてしまっていることだけは分かっていただけると思います。ちなみにこいつ自体は結構重宝して動いてくれてはしましたが、まだポケモンの方に結果がでていないので効果のほどはなんとも言えません。(明確な開発成果といえば、過去2度試みて失敗しているVim->VSCodeの移行に成功したということくらい)とりあえずこの先、ゲームをやるべきかツールをつくるべきかの天秤で悩んだりしつつあれもやりたいこれもやりたい試したいととっちらかってきているので、もし使ってみたかったり、一緒に作ってみたいという方がいらっしゃればTwitter DMででも連絡をいただければ幸いです。おまけ - これから新しいポケモンもさらに増えて困ったことになりそうな11月に向けて、次は直接的に戦闘をアシストしてくれるようなツールを作ってみようと思っています（作っている）。戦況を自動で判別しつつ、相手の育成パターンによってこちらの技がどの程度入るのかをざっくりみられたり、逆にこちらが打った技がn%はいったのでおそらく耐久に振っている、、など、経験が浅くてダメージ感覚のない人でも初見ポケモンに殺されないようなものができると嬉しいです。戦況解析からのダメージ計算の実現はとても複雑なドメインで、モデリングの勉強にとてもなることがわかりました。そのあたりを考えるのが楽しくてここ最近まったく進捗がでていないのですが、完成したらモデリング文脈でもなにかアウトプットできるといいなと思っています。(あとすばやさ関係もいい感じのUIで表現したい)ポケモンの選出画面をキャプチャして、相手のパーティとの素早さ関係や、相手のポケモンそれぞれに対する有効打点とダメージ計算結果を表示するやつができつつある pic.twitter.com/gHRgMfcZhE— rocky=興梠@エンジニアリング (@rocky_manobi) May 2, 2020  それでは、次の自由研究に乞うご期待です。

スマホでSwitchを操作できるようにして、隙間時間でポケモンマスターを目指す

LAPRAS アウトプットリレー の...何日目だっけ？3/25の記事です！こんにちは！LAPRAS エンジニアの @rockymanobi です！最近Node.jsでCLIを作る機会があり、その時に触ったEnquirerというライブラリが便利だったので、軽く紹介してみようというものです。ツールそのものについて軽くふれつつ、制作過程で出てきた「こんなことしたいけど、どう実現すれば良いんだろう」と試行錯誤して分かった使い方などを共有できればなと思います。EnquirerとはEnquirerは CLIアプリケーションにおける対話的インターフェイスの実装を楽にしてくれるライブラリです。単純なテキスト入力の受付はもちろん、リストからの選択、チェックボックス、パスワード、入力補完、など、様々な入力方式を手軽に組み込むことができます。Node.js製です。JavaScript(TypeScript)万歳！公式サイトによるとこんなのもできるそうです（凄い！！ いつ使うんだろう）類似のツールとしては先発の Inquirer.js などがあります。公式サイトに「Inquirerより速いぜ！」とあったり、Inquirerとほぼ同じような記述方式をサポートしていることから、かなり意識して作っているように見えます。どちらも利用者が多く、メンテも続いているのでどちらを使っても良いでしょう。あえて比較をするならば、Enquirerの方が多少全体や中身を把握しやすかったのと、少し凝ったことをやろうとしたときに素直そうな印象でした（個人の感想です）。基本的な使い方例えばこんなものを作りたい場合は...const Enquirer = require('enquirer');(async ()=> {  const question = {    type: 'select',    name: 'favorite',    message: '好きな乗り物は？',    choices: ['パトカー', '救急車', '消防車'],  };  const answer = await Enquirer.prompt(question);  console.log(`僕も${answer.favorite}が好きだよ`);})();このようにpromptメソッドにオプションを渡してやると、それに応じた方式で入力を受け付ける描画をしたのち、ユーザの入力が完了したときにPromiseをresolveしてくれます。結果はオプションnameに指定したキーにぶら下がってきます。この要領で公式ドキュメントを見ながら使えば、大抵のことは実現できると思います（少し違う使い方もありますが後で触れます）少し複雑なケースの実装ここからは少しだけ複雑な要件に対応してみます。複雑な入力と言われて最初に思い浮かぶのはポケモンバトルの選出画面です。故にここからは「ポケモンバトルの選出画面をCLIで実装するとしたら」をテーマに少しづつ進めていきたいと思います。リストから要素を複数選択（これは単純ポケモンの対戦は、基本的に以下のような流れで進行します。1. ポケモン6匹でパーティを構築する2. 対戦前にお互いにパーティを見せ合う3. 6匹のうち3匹を選出し、3vs3で対戦今回の対応範囲である「選出」というのはこの3番めにある「6匹のうち3匹を選ぶ」作業のことを指します。以上を踏まえると、選出画面のCLI版は以下のようなものになりそうです。実装は以下のようになります。const Enquirer = require('enquirer');const myPokemonNames = [  'フシギバナ',  'リザードン',  'カメックス',  'ゴリランダー',  'エースバーン',  'インテレオン',];(async ()=> {  const question = {    name: 'selections',    type: 'select',    multiple: true,    message: '誰を出す？',    choices: myPokemonNames,    validate: (selectedItems) => {      if(selectedItems.length === 3){        // true/falseを返すとOK/NGのみを表現        return true;      }      // 文字列を返すとエラーメッセージになる      return '3匹選んでください';    },  };  const answer = await Enquirer.prompt(question);  console.log(`${answer.selections.join(',')} を選出しました`);})();オプションmultiple: trueを渡すことで、複数選択可能なチェックボックス式の入力を受け付けます。また、validateにバリデーション用の関数を渡すことで、ユーザ入力を検証して、不適合な入力を弾き、入力画面をキープすることができます。エラーメッセージを独自のものにしたい場合は、true/falseではなく文字列を返すようにすることで、判定をNGとしたうえで、関数が返した文字列をエラーメッセージとして表示してくれます（errorMessageってオプションあったほうがわかりやすいきがしますが）。タイマーで入力をキャンセルするここまでは公式Readmeにもしっかり書いてあるので難なく対応できました。が、要件を一つ忘れていたのでここで追加します。ポケモンの対戦では遅延行為を防ぐため、あらゆる行動に制限時間が設けられています。もちろん選出も例外ではなく、すべてのプレイヤーは1分30秒（記事執筆時点）以内で3匹のポケモンを選び出す必要があります。これに間に合わない場合は、強制的に上から順に3匹のポケモンが選出されます。この要件をCLIに反映させてみます。const Enquirer = require('enquirer');// (信じられないことに)配列 myPokemonNamesをchoicesオプションとして渡すと破壊的に配列が変更されるので、// 違うArrayインスタンスを返すようにFunctionに包んでいるconst myPokemonNames = () =>{  return [    'フシギバナ',    'リザードン',    'カメックス',    'ゴリランダー',    'エースバーン',    'インテレオン',  ];};(async ()=> {  const prompt = new Enquirer.MultiSelect({    name: 'selections',    message: '誰を出す？',    choices: myPokemonNames(),    validate: (selectedItems) => {      if(selectedItems.length === 3){        return true;      }      return '3匹選んでください';    },  })  let timer;  prompt.once('run', ()=>{    timer = setTimeout(()=>{      prompt.cancel()    }, 5000)  })  prompt.once('close', ()=>{ clearTimeout(timer); });  const answer = await prompt.run().catch(() => {    // 時間切れです    return myPokemonNames().slice(0,3);  });  console.log(`${answer.join(',')} を選出しました`);})();これまでとは少し実装方法を変えています。これまではInquirer.js風の実装をしていましたが、ここではコチラのように、ライブラリにビルトインで入っているPromptの子クラスを用いた実装にしています。コンストラクタの形式はこれまでpromptメソッドに渡していたものに似ていますが、各クラスごとに自明なものMultipleSelectクラスにおけるtypeやmultiple:trueなど）が不要になっています（TypeScriptなら型チェックも効いて快適）。この方式ではPromptクラスのrun()メソッドを実行したときにユーザの入力を受け付けるようになり、同cansel()メソッドを呼んでやることで、強制的に入力を終了させることが可能です。PromptクラスはEventEmitterを継承しており、上記コードでは入力受付開始時のrunイベントに反応してタイマーを作動させ、一定時間経過後にキャンセルするようにしています。入力終了時（キャンセル/タイムアウト含む）に発生するcloseイベントが発生したタイミングでは、タイマーを止める処理を実行するようにしています。最後に、プロンプトをキャンセルしたときにはPromiseがrejectされるので、catch節でエラーを拾って、「時間切れの場合は先頭の3匹強制選出」を示す結果を返すようにしています（ちなみにcatch節のコールバックには何も引数が入って来ません）カウントダウンを表示する制限時間を超過すると時間切れになるようにはできましたが、選出中に「後何秒？」が分からないのは辛いものがあります。これも対応しましょう。(async ()=> {  let timeRemaining = 10;  const prompt = new Enquirer.MultiSelect({    name: 'selections',    message: () => { return `誰を出す？ 残り ${timeRemaining} 秒` },    choices: myPokemonNames(),    validate: (selectedItems) => {      if(selectedItems.length === 3){        return true;      }      return '3匹選んでください';    },  })  let interval;  prompt.once('run', ()=>{    interval = setInterval(()=>{      timeRemaining -= 1;      if(timeRemaining <= 0){        prompt.cancel()      } else {        prompt.render()      }    }, 1000)  })  prompt.once('close', ()=>{ clearInterval(interval); });  const answer = await prompt.run().catch(()=>{    console.log('時間切れです');    return myPokemonNames().slice(0,3);  });  console.log(`${answer.join(',')} を選出しました`);})();タイマー処理をsetTimeoutをsetIntervalに変えて、1秒毎にカウントダウンするように変更しつつ、メッセージに「残り n 秒」を表示させるために、以下の修正を施しています。messageオプションに残り秒数を表示する文字列を返す関数を渡す1秒毎に prompt.render()メソッドを実行するこれにより、プロンプトの内容が毎秒再描画され、残り時間がカウントダウンされていく様子を表示することができました。カウントダウン部分のみを他のライブラリや独自実装などで代替しようとすると、カーソルの状態が衝突して表示がおかしくなったりするので、このあたりをサポートしてくれているのは有り難い限りです。複数の質問をする & 前の回答を考慮して選択肢を変更するこれで完成かと思いましたが、そうはいきません。確かに選出は6匹から3匹を選び出す作業ですが、同時に「誰を先発させるか」を決める作業でもあることを忘れていました。最初に選択する要素には特別な意味をもたせる必要がありそうなので、最初に先発を聞いて選んでもらった後に、控えの二匹を選出してもらうようにしてみます。公式ドキュメント によると、Enquirerは複数の質問を連続して表示することに対応しているようですが、Enquirer.promptメソッドにオプションの配列を渡してあげる形式にする必要があります。このままだとタイマー処理によってキャンセルすることができないので、どうにかしてPromptクラスのインスタンスを参照する必要があります。ということをやろうとしているのが上の方にあるこの処理です。  // Enquirerインスタンスの参照が欲しいのでstaticメソッドのpromptではなく  // new Enquirer()して、そいつのpromptメソッドを呼ぶようにする  const enquirer = new Enquirer();  enquirer.on('prompt', (prompt) => {Enquirerクラスは内部的に保持しているPromptインスタンスを処理するタイミングでpromptイベントを発火しつつPromptインスタンスを渡してくれるので、そこでこれまでのケースと同じようにイベントハンドルを仕掛けています。先発で選んだポケモンを控えの選択肢に出さないmessageオプションなどと同様にchoicesオプションにも関数を指定することが可能です。そして、この関数内部でthis.state.answersを参照することで前の質問に対する入力の値を得ることができます。コレを利用して、控えポケモンの選択肢から、先発に選んだポケモンを除外しています。      choices() {        return myPokemonNames().filter((name) => {          return this.state.answers.starter !== name;        })      },その他今回の例ではchoicesにはString配列を渡していましたが、{ name: '興梠', value: 'rocky' }のようなオブジェクトの配列を渡すことで、見た目上はnameに指定した値を表示しつつ、実際にanswerで得られるのはvalueに指定した値にする、ということも可能です（多分大体そうする）。加えて、このようにオブジェクトを渡す方式にしている場合は、最後の例を実現するにあたってchoicesをフィルタする代わりに、各choiceのオブジェクトにdisabled: trueなどを渡すことで選択不能な状態にすることができるみたいです。（というか複数聞きたいなら複数回prompt呼んでしまえばいいじゃないのって思ったけど違うのかな）まとめ無事、ポケモン選出画面の要件を満たすことができました。技術的には以下のあたりがリポジトリ検索したり調べたりコード見てみたりしないと見えてこなかった印象があるので、実現したい方は参考にしてみると良いでしょう。(PullRequestチャンスでもある）タイマーでプロンプトを終了させるためにはPrompt#cancelPromptクラスの参照は、最初からPromptクラスを直接使った方法で実装するか、Enquirerクラスのpromptイベントをリスニングして降ってくるのを拾う最後にこの謎チュートリアルはノンフィクションです（実際に勢いでポケモン対戦できるCLIを書いているときの展開をほぼそのまま再現しました）

JavaScriptでちょっと複雑なcliを作るのに便利なEnquirer

この記事はLAPRAS Advent Calendar 2019の13日目の記事です自分も最近体験したということもあり、LAPRASのWebAppチームのオンボーディングについて紹介しようと思ったが、最近自社推しが過ぎる気もしたので、視点をオンボーディングを受ける側に移し「こんな風に立ち回ろう！」というスタンスで書くことにしました。v0.1.0 ということで走り書きの勢いでそのままお届け致します。オンボーディングとはオンボーディングとは、新たにサービスを導入した人や新たに組織に参加した人などに対して早く慣れることができるようにサポートすることです。この記事の文脈は後者。注意することやTIPSを書いていきたい。自分にも多少刺さりまくることがあるが、過去はもっと酷かったところが若干改善したと思っているので、勇気を持って書くことにする。いきなり目立った成果を出そうとして消耗しないまずは危険性を認識する新しいチームに入ってまず最初に戦わないといけないのは「自分、役に立ってるの？必要なの？」「自分は何者なの？」という不安感どのような人でも、環境が変わればまずは学びのフェーズから始まる（エンジニアで、ある程度システムが大きくなっている場合は特に）チームに入りたての学びのフェーズでは貢献は愚か、自己認識としてはマイナスの存在とも感じてしまう以前の職場でのパフォーマンスが高かったり、重要なポジションを担っていたりするほどギャップが激しく、精神的負荷が高い早くその状態を脱出しようとして焦り、目に付くインパクトの大きそうな課題やできそうなことを片っ端からやろうとするが、成果が出ずに自己肯定感が下がって消耗するこの過程に耐えられず、特に（想像上の）他者の認識から身を守ろうとして、他責的な振る舞いになって信頼を失う。これは危ない。地に足をつけて着実に積み上げていく方が長期的にチームにも貢献できるはず以下、この危険性に対処するための方法を紹介する目標とスケジュールを設定して共有する理想と現状のギャップに対して焦らないようにするためには、目標とスケジュールを決めるのが効果的スケジュールがあれば「まだゴールには遠いけど、オンスケだから今日休める！寝るぞー」と思うことができるこの認識をチームと共有することで、自分も今の所大丈夫だと思えるし、周囲にもそう思ってもらえていると安心できるちなみにLAPRASでは入社前から以下のような期待値を提示されていた（内容はエンジニア向け、とは少しズレるが参考までに。純えんじにあ職ならばより技術的な貢献ができるような内容が並ぶはずだ）* 1ヶ月  * スクラムの開発チームに馴染んで(技術・内部仕様理解以外の点で)普段の業務に障害がなくなること（=普通に仕事がお願いできる状態）* 3ヶ月 :   * 開発チームをまとめ、リードしていくことができる* 6ヶ月  * 予測不能（全社的に変化が激しいので、いまは明確にはできない入社直後に上記目標について改めて合意をし、合わせて必要なサポート（後述）についても認識を合わせる機会があった一開発者としてだけではなく、チーム全体への貢献を求められるポジション枠で入社していたということもあり、「まずは普通の開発者として一人分の仕事ができるようになることにフォーカス」と思えたことは学習フェーズの不安との戦いに大きく貢献した。（仮に僕が開発サイドオンリーで戦える強者であるならばとにかく開発集中でよいと思うが、残念ながら自分の技術レベルはそのレベルには達していない）このような機会が無い場合はリクエストしよう進捗を共有して必要であればスケジュールを変更する達成できない目標は精神衛生上悪影響があり過ぎるし、達成できたと思っているのが自分だけだというのもまた悲しいフィードバックをもらって現状を正しく認識する自己認識でうまくいっていると思っていても、他者からはそう見えていないこともある。チームに貢献するという文脈において、このギャップは解消すべきだ。逆に、自分ではダメだと思っていても、他者からはよく見えているところもある。これは本来なら無用な悩みになるので、このギャップも解消すべきだ「●●の目標に対して、自分としてはこの点とこの点はできていると思っている。ここは足りないのでこうしようと思っている。認識はあっていますか？」という質問ができると良い。ギャップがあれば解消する方法を考える世の中うまくいかないこともあるどうすれば修正できるのか、どのようなサポートが必要なのかを改めて対策を考えたり、助言を求めたりする目標やスケジュールの達成見込みが絶望的ならば、期待値かスケジュールを調整するLAPRASでは主に毎週(慣れてきたら隔週)の1on1と、月一の振り返りで上記のような作業を行なった。同じく、このような機会がなければリクエストしよう。（おまけ）結果今は入社4ヶ月になるが、概ねギリギリ大丈夫と言えるレベルだと思っている。次のステップに向けて新しい課題に四苦八苦しながら対処しているところでもある。受ける側の話とはずれるが、先輩社員に「焦って結果出そうとして苦しんで潰れていく人が多いから焦らないで一つずつやっていった方がよいですよ」と言葉をかけてもらったことをすごく覚えている。いくら自分がそのつもりで、目標を共有していたとしても、焦る気持ちはゼロにはならないので、言葉にしてもらえるて死ぬほど楽になったのを覚えている。現状の仕組みを作り上げたことに対する敬意と感謝を忘れない改めて言語化しようと思ったらTweetがあった。連投しているので気になる方にはみてもらえると嬉しい。大事なのは「味方感」。本当の意味で味方になることだ。逆に新しく入る側としては● 理想状態を語ることと実現することは全然違う● 全てをいい感じにするのは無理ゲー● ここまで作り上げたことに敬意を払うこの三つを忘れず、その上で全てをいい感じに近づける為に出来る方をしたり言ったりするのが大事 https://t.co/gfUYhuAO3t— rocky=興梠@エンジニアリング (@rocky_manobi) 2019年8月12日  課題があるのは当たり前、むしろ課題が無いなら自分がいる意味がない。自分は被害者ではない。そもそも自分で今の状態を一から作れるかかんがえる（多分NOだから起業せずに入社したんだろう）まずはそのすごさを認めて敬意を表し、チーム全体を自分にとって善の存在として認識するその意識を忘れなければ細かい表現は気にしなくていいはず味方として一緒に解決に取り組めば良いちなみに受け入れ側として注意したいのは以下のような力学（そしてLAPRASのチームは信じられないくらいこの手のネガな部分が無くて好きだ）新しく強い人をチームに迎えられたとして、その人の強みを活かせるかどうかは、これまで自分のやってきたことが自分以外の人の手で改善される事を良しとできるかがとても大きい。無意識に自己の評価を下げる事象と（誤）認識して、口出したりマウントとったりして手放せないとかの負の影響はかなりある— rocky=興梠@エンジニアリング (@rocky_manobi) 2019年8月11日  実務上のサポートエンジニア向けと書いたので、実務についての工夫も書いておく。先ほど書いた「必要なサポート」の具体的な内容はおもにこちらにリンクする。ガンガンリクエストしていこう。システムを触る自分たちが何を作っているのか理解せずに物を作るのはまずい。機会がなければ確実にリクエストしよう。システム全体像のインプット最初に全体像を説明をしないところはないと思うが、されなかったらリクエストしようDB定義、依存ライブラリ/サービス、全体の設計思想、インフラの大まかな構成 などを中心に聞く一度に理解する必要はない。実務をやりながら理解を深めていくイメージで良い。ペアプロコード理解において「（目的もなく）コード読んでおいて」はワークしないので、「とりあえずコード読んでおきます！」という宣言はしない任せるタスクが無い、余裕が無いのであればとりあえずペアプロをした方が効率が良い触っている箇所だけではなく、実装の背景など、気になったところは質問してドキュメントに落としきれていない知識を吸収することに務めるLAPRASでは最初の2週間の開発タスクは全てペアプロで実施、3週目からは自己申告で「これはソロ狩りしたい」といったものだけソロで対処するスタイルをとった1ヶ月で開発タスクをこなせるようになる、をクリアすることに大きく貢献したもし現場でペアプロがあまり推奨されていない場合は、せめて対面でのコードレビューを求めよう（コードをみながらの会話は必ず必要だ）ペアOpsもといペアワーク現場で実務をこなす際に必要なのはコードを書くことだけでは無い障害対応や、システム面の質問に答えるための調査をしたり、データ周りの調査などもそれに含まれるこれらの作業はやってみないと振られないので、自分からリクエストしにいくとはいえいきなりは任せられないので「自分のやったことのない仕事やるときは声かけてください隣でみさせてください」と宣言するshellの設定や使っている便利ツール、システム運用時に利用しているサービス、などなど、入社後の説明では得られなかった情報を発見することがある周囲のエンジニアのレベル感もわかる（この点自分は大いに焦りを覚えたのだけど）自分の関わっていないPullRequestを見る最初はどうしても自分のタスクだけを追いがちになるが、最低限チームが何をやっているのかは把握したいところIssueは「これからすること」が書いてあるが、PRはその結果までついているので、初期はPRから見る方が効率が良い文字通り直近書かれたコードを見ることができるので「昔はこういう書き方をしていたけど今は...」のような事故が防げるレビュー指摘の傾向などからチームの「大事にしているところ」や「雰囲気」も感じ取ることができるはず(スクラムをやっているならば、計画MTGの設計で話していた内容が、どうコードに落としこまれるのかを意識して読むと良い）みてはダメだと言われることはないが、時間をとれないようであればリクエストしてみようスプリント計画をちゃんとやるスクラムチームはEasyモード本筋とは少しずれるもし新たに入るチームがスクラムを採用している場合、事前にスプリント計画の様子を聞くと良いスプリント計画ミーティングにおいて、作るものと設計について詳細に議論して合意しているチームは、当然ながら新しく入った人のキャッチアップも早いまとめざっとみると、チームに入る側としては周囲に労力をかけてもらうようなリクエストが多いように見えるとはいえ新しくきた人をワークさせるのに労力がかかるのは当然なのでためらってはいけないためらって、結果としてパフォーマンスが下がればその方が損失が大きい多少ずうずうしく、学ぶために周りを巻き込んでいく姿勢が大事組織としては、その辺に気を配れるかが大事その他こまかいメンタル的なところなどはキャラ的に敏感ではないので書かなかった最後に偉そうに書いたが完全に自分の出来栄えは棚に上げた理想論だと思って読んでほしい。多少の貢献はできているかもしれないが、まだまだチームの力になるにはどうすれば良いか割と必死だ。気を抜いたらただのお荷物やで自分！という感覚とは普通に戦っている。チームの皆様にはその辺は生暖かく見守りつつ、サポートも頂いているのでそれに救われている。徐々にやれる範囲を広げてきたのもあって抱えているものが増えてきたので、次は仕組みにして手放していき、パフォーマンスをスケールさせたい。このように全然余裕な雰囲気はない。やっていきしかない。というわけで、v0.1.0よろしくプロットのような描きっぷりになってしまったが、少しは有益だと思うのでその辺は容赦してほしい。（万が一）リライトしたらTwitterに書くので、とりあえずその時までみんな頑張ろう。

新しいチームに加わるエンジニアのための "被" オンボーディングガイド v0.1.0

この記事はLAPRAS Advent Calendar 2019の9日目の記事です概要LAPRASに入る前、業務の内容をDMでたくさん受け取って辛いという課題があったDMを受け取るとパブリックチャネルに優しく誘導してくれるDM警察というBOTを作ったがLAPRASに入ったら需要がなかったなんでや？じゃあLAPRAS関係ないやろ！？まとめ課題 - 業務の内容をDMでたくさん受け取るのは辛いこのような内容をDMで受け取ると少し困ります。パブリックチャネルの発言であれば、僕がこの質問に答えられない場合でも「@知っていそうな人 さん、わかりますか？」とメンションするだけで事が足ります。たまたま会話を見ていて知っている人が能動的に答えてくれる事もあるでしょう。また、後々一連の会話をシェアしたくなったときでも、この会話へのリンクを貼れば経緯を伝えることができます。DMではいずれも叶いません。本当に秘匿したい情報のやりとりを除いた殆ど全ての場合において、情報はパブリックでやりとりする方が良いはずです。良いはずですが、この手のやりとりをDMで行う人の割合は決して少なくありません。以前の僕も、そういったDMを受け取るたびに上記の説明をしつつ、なるべくパブリックチャネルにポストしてもらうよう促していました。そして、これはおそらく日本のあちこちで行われている事でしょう。DMを送る方には悪意がない一方でDMを送る方としては、単純にパブリックチャネルに発言するメリットを理解していなかったり、使い方を知らなかったり、オープンな場所に投稿することをためらってしまうような空気があったりと、必ずしも悪意があるわけではありません。そこが悩ましいところです。丁寧に啓蒙していくしかないのですが、やはり続くと辛い。そして言い続けているうちに、段々と「うるさいやつ認定」されていくのもまたつらい。DM禁止は筋悪（だと思っている一律禁止はしたくない、というスタンスです。有用なシチュエーションでは普通に使うべきだと思います。なにより、大事なのはDMをしない事ではなく、パブリックに情報をやりとりすることです。その大切さを伝える方向で解決したいところです。DM警察を作って公開しましたというわけで、諸問題を解決するBOTを作りました。ざっと特徴は以下の通りです。DMを受け取ると、BOTがパブリックチャネルに誘導してくれるコミュニケーションは職質風。パブリックチャネルに投稿する意義を啓蒙してくれるゴネれば10分黙ってくれる簡単に使えるSlackワークスペースに公式サイト からインストールできるBotにメンションする事で、DMの監視を依頼できる（監視してほしい人だけが使うことができる）権限が気になる人は、Herokuボタンで独自環境を構築することができるDMを受け取ると、BOTがパブリックチャネルに誘導DMを受け取ると、DM警察が現れてDM送信者に職質をかけてくれます。無視をしてもDMを受け取るたびに起動するので、あまりのウザさに流石に無視はされません。拒否すると、パブリックチャネルに投稿する意義などを教えてくれます。「我々も仕事でやっているのですみません」という感じで、とてもウザい感じに仕上がっています。ゴネ続けると、最後には諦めて許してくれます。10分離脱してくれるので、その間に会話を済ませることもできます。Slackワークスペースに公式サイトからインストールできるこちらが公式サイト です。動画やマニュアル、注意事項などが書いてあります。「dm警察をslackにインストールする」ボタンを押すとSlack Appがインストールされます。インストール時にAppのWebhookを送るチャネルを聞いてくるので、あらかじめ「#DM警察」などを作っておくと良いでしょう。また、誤ったワークスペースにインストールしないようにご注意ください。Botにメンションする事で、DMの監視を依頼できる（監視してほしい人だけが使うことができる）こんなふうに「パトロールよろしく」とメンションすると、パトロールしてくれます。Herokuボタンで独自環境を構築することができるDM警察のサーバはDMの内容を記録していませんが、DMを読めるという強めの権限を渡すこと自体がネックになるという方もいらっしゃると思い、ソースコードを公開してHerokuボタンも設置しました。コチラを参考に独自の環境を構築する事ができると思います。やってみてね。あと、リポジトリにスターつけて頂けるとメンテ続ける意欲が強化されるので、気に入った方は是非ぜひ。github.com運用TIPS: 口うるさいのは人ではなくDM警察DM警察がきたからには、もう口うるさく啓蒙する必要はありません。警察を呼んだのです。任せましょう。たまにBOTを無視して会話する猛者も現れますが、そのときは「BOTがうるさいので、パブリックチャネルいきましょうよ」「DMめちゃ送ってくる人がいて（あなたなのだけど）、その人対策でDM警察いれたんです。すみません警察がうるさくて」などといって、DM警察という共通の敵を作りながら、パブリックチャネルに誘導してしまいましょう。言いにくいことは機械に言わせる。社会性フィルタを通した言い回しも、一度考えればそれで終わりです。繰り返していいんです。DM警察は機械ですから。と、このように運用をした結果、以前よりDMを受け取ることが減りました。なんでや？LAPRAS関係ないやろ！？そうおっしゃらずに、まずはこちらをご覧ください。ご覧の通り、弊社LAPRAS株式会社のSlackは発言の殆どがパブリックチャネルにポストされており、全社的に非常にオープンな状態であるといえます。業務をしていてDMを受け取ることは稀で、その内容もパスワードなどの秘匿すべき情報や、休日の遊び関係の会話（子供どうしで遊ばせる会のために集合場所を決めたりetc）などであり、なんら違和感を覚えることはありません。もうお気づきかと思いますが、このような環境ではDM警察に活躍の場はありません。オープンな組織では、DM警察は生きていけないのです。4ヶ月前にLAPRASに入社した僕はそのことに気づき、そして...DM警察のDynoを「0」に設定しました。当時のDM警察は僕だげが使えるレベルにしか整備がされていなかったため、その日がDM警察の命日となりました。それから...DM警察を止めてから数ヶ月が経ったある日、平和なSlack生活を送っていた僕はTwitterであるものを目にしました。それは「Slackで業務連絡がDMで送られてきて辛い」というツイートでした。多くの共感を集めたそのツイートは拡散され、議論の火種となり、一定の周期で僕のTLに「Slack DM辛いネタ」を届けるようになりました。「僕は解放されたけど、世の中にはまだまだ苦しんでいる人がいるんだ。解決策を持っているのに、自分が救われたからといって電源を落として満足している、こんなことで良いのか？DM警察にも申し訳ないのでは？」TLをみるたびにそんな気持ちになりました。そしてこの「うしろめたさ」こそがDM警察を公開した動機です。もしLAPRASに入らず、あのままDM警察が稼働していたら、きっと僕はある程度の満足感を持って過ごしていて、DM警察を公開することはなかったでしょう。DM警察を一度はリストラしたという後ろめたい気持ちが、制作の原動力になったのです。その意味で、DM警察を公開するにあたってLAPRASは大いに関係していると言えるでしょう。まとめかくして、色々なところで運用しながら育ててきたDM警察でしたが、LAPRAS入社と同時に晴れてお役御免となりました。これからは僕のためにではなく、世の中の同じ悩みを持つ人のため、組織のために働き、LAPRASのようなオープンな文化の組織が増えていくことに貢献してほしいと願っています（若干自社を褒めすぎたかとも思いましたが、そこはまだ入社4ヶ月で、作り出したものよりも既存の枠組みに乗っている割合の方が多い今だからまだ許されることでしょう。とはいえそろそろ「これは俺がやったったで！ドヤァ」という成果を出したいものですね）。それでは、快適なSlack Public Channel ライフを！そして最後に最後に  「それから...」の下りは全くの嘘です 。DM警察を公開したのは、MushupAwardsもといヒーローズリーグ2019に応募するネタを考えていたら「そういえばDM警察があったやん！あれでいこう！もったいないから公開しよう！」と思ったからです。嘘をついた上にLAPRAS本当に関係なく、誠に申し訳ありませんでした。つまるところ「オープンな文化はいいですよね。LAPRASのそういうところが僕は好きです」というエントリだったと受け取って頂ければと思います。はい。申し訳ありませんでした。それでは、快適なSlack Public Channel ライフを！宣伝反響いただいたのと、ちょくちょくご利用いただいているっぽいので、少しは役得を...ということで、宣伝を！させてください！LAPRAS株式会社は現在 WebAppエンジニアを絶賛募集中でございます。DM警察は稼働していませんが、ご興味ありましたらこちらをご覧ください。t.coこういったものを作っていますlapras.comこんな組織を目指していますwww.wantedly.com

SlackでDMを受け取るとパブリックチャネルに優しく誘導してくれるDM警察というBOTを作って公開しました

私ごとですが、2019年8月にLAPRAS株式会社に入社しました。転職エントリ的なものを書くつもりはありませんでしたが、転職以後も以前の立場としてのお仕事のお話を頂いたり、何よりしれっと立場だけが変わっていると「何があった！！！！？」となってしまうよなとも思い、ここでも告知をさせていただきます。事実中心エモ成分少なめで書いていきます。（あと、一旦バチっと所属を明らかにしないと記事シェアとかしたくてもステマになってしまうという心のブレーキが辛かったというのもあります）以前の所属/立場との変更点自分を知っている方としては「入社した？ってことはNextremerは？」というのが当然の流れだと思いますので、まずは変更点から。主要なものは以下の通りで、いずれも2019.04 ~ 2019.09の間の変化です。(注:改めて字面だけを見ると衝撃的な内容ですが、Nextremerとしてのお仕事も引き続き継続しています)株式会社dataremer代表取締役を辞任しました (株式会社Nextremerの100%子会社)フリーランスエンジニアとしてのお仕事を開始しました株式会社Nextremerを退職しました株式会社Nextremerとアドバイザリー契約を締結しましたLAPRAS株式会社に入社しました(生活拠点を関東に移しました(埼玉です))変更理由事実成分重めと言っても、背景ゼロで辞任や退職をお伝えするのは少々重すぎるので、簡単に記述しますと...会社全体のフェーズや方向性の変化に伴って、以前とは異なるスキルや性質が求められるようになったという背景があり、対処方法を検討した結果、Nextremer/dataremerの事業や組織運営についてはより今のフェーズにおいて必要な能力のある方に担っていただき、自身は強みを活かせる領域に集中することが、お互いにとってプラスになると判断した、というのが主な経緯です。この路線をベースに、必要な関わり方や稼働の量、僕自身の嗜好性、制度や運用など諸々を相談した結果、正社員という立場とは異なる形で業務に携わることになりました。もちろん、厳密にはもっと複雑で細かいお話や、葛藤、お気持ちなどたくさんありますが、文章として公開するつもりはありませんので、興味のある方はご飯でも食べに行きましょう。現状のお仕事状況ここからは、前述の変化の結果どうなったのか、いま何をやっているのかについて書いていきます。LAPRAS株式会社corp.lapras.com改めて、2019年8月にLAPRAS株式会社に入社しました。稼働割合としてはもっとも大きなもの(80%以上)となるので、bioなどもこちらを主として更新しています。動機などについてはまたの機会に書きますが、意気込みとしては「喜んでもらえるサービスを作ることに貢献しつつ、みんなで勝ちたい！」という気持ちでいっぱいです。VPoEという肩書きをつけていますが、2019.11.01時点ではスクラムチームの開発者の一員として、必死でコードを書きつつプロダクトの技術的/ビジネス的/文化的な歴史等諸々を追いかけています。プロセスの改善や組織を強くすることなどなどについては、色々と思案していたものをそろそろ動かしていくぞ、という段階です。成果が出せた暁には何かしら新しいセオリー的なものを生み出せるような予感がしているので、まずはそちらを乞うご期待といった具合です。WebAppチームのエンジニアの募集もしていますので、興味ある方はぜひ！採用要件はどこに書くべきか迷ったんですけど、報酬についても書きたかったのでesaで書いてみることにしました。どこから応募するんや…って困ると思うのですが、とりあえずぼくにDMください！外でランチでもオフィスでカジュアル面談でも設定します！https://t.co/geRAJ1ygHU— Shogo ITO@LAPRAS (@showwin) October 24, 2019株式会社Nextremer/dataremer立場的には株式会社Nextremerの社員ではなくなりますが、前述の通り引き続きお仕事をさせていただいています。アドバイザリー契約という高尚な響きのする契約ではありますが、実際の業務としては引き合い案件の技術的な要素検討、プロトタイプの実開発、SaaSプロダクトの内部情報提供やドキュメント化など、稼働は減りこそするものの、実務レベルでは業務の形はさほど変わりません。高知AIラボについても、私自身は高知AIラボ代表という立場ではなくなりますが、引き続き運営を継続しています。現状の体制等については会社Webサイトをご覧ください。また、個人としても高知でのお仕事はさせていただいており、時々足を運んでいますので、高知関係で僕の貢献できそうな事であればお声かけいただければと思います。株式会社エナーバンクtwitter.com電力のリバースオークションサービス「エネオク」を中心に、電力領域で事業を展開しているスタートアップです。開発マネジメントや技術的意思決定、優先順位の決定、組織づくりなどのサポートを目的として、知見提供や壁打ちやハンズオンをしたり、たまに手を動かしてコードを書く...などなどもしています。事業分野も非常にホットで、絶賛立ち上げフェーズで勢いもあります。興味のある方は連絡いただくか、CEOの@enetech5 の発信をチェックしたりすると良いと思います（直接絡んでもいいかも?）フリーランス開発者フリーランスエンジニアとして開発案件やアドバイザ業/コンサルティングなどを請け負っています。現在はNode.js(TypeScript)製のIot関連プロダクトの立ち上げ開発をメインに進めており、アーキテクチャ設計~機能実装を担当しています。おわりに業務は完全に途切れていないとはいえ、2015年5月の入社以来ずっと全力でやってきたNextremer/dataremerのお仕事がメインではなくなるというのは、やはり一区切りした感があります。本当に多くの方に助けて頂いたおかげで、得難い経験をさせていただき、かつ一定の貢献をすることができたと考えています。関わってくださった皆様、本当にありがとうございました。これまでと少し形は変わりますが、恩が返せるよう頑張って参りますので、引き続きよろしくお願いします。

LAPRAS株式会社に入社しました

組織の人数が20~30人あたりになったタイミングで、制度とかルールを整備しようと社内が動きだしていたときに「こういう考えで進められたらいいよね！」と社内に向けて書いたエントリをpublicにしました。エンジニアのリーダーという立場から、制度設計等をメインで進めるチームと、ステークホルダーであるメンバーに向けて書いたものです（改めて見直すと全然社内限定の話ではない）最近、本業以外で色々なチームのお話を聞いたり壁打ち相手になったりしていることや、最近こういう記事がよく目につくので、自分も考えをアウトプットして置こうと思ったのが主な動機です。 2年前(2017年2月) に書いた記事のため、今よりも幼稚な思考ではあるものの、芯として大事にしたい部分は変わっていません。これを書いた時期は研究開発受託が事業の主軸であったことと、その時の立場、精神年齢などに起因して、少々偏って要ることを念頭においていただけると助かります。 特に エンジニア => 社員orメンバー と読み替えていただいた方が良いと思います【本編】社内制度や規則について思ったこと2017.02.21社内制度や規則を整備するにあたって、なんとなくこれ大事なんじゃないかな〜と思うことをつらつらと描いていきます。歴史についても少し。人々はシステムの末端を通して システムを認識し、理解する。システムの信頼性とは、 いかに末端が厳格に機能しているかで判断される  (アニメ PSYCO-PASSより)いきなりアニメからの引用で痛々しい限りですが、核心をついていると思うのでここから始めます。例えば僕たち一般人は、某携帯会社さんを「携帯端末」「代理店」「契約内容」などの末端のインターフェイスを通して認識し、その質をもって全体を評価します。その評価対象に、創業者の人柄や想いは通常含まれません。某飲食チェーン店なら、「店」「料理」、強いて言えば「店員」のみが認識/評価対象となるでしょう。社員に対する会社の想いや価値観もこれと同様です。働いている社員をユーザとするならば、会社の「想い」や「価値観」は何を通してユーザに認識、評価されるでしょうか。それは、トップの人柄でもメッセージでもなく、運用されている「しくみ」「制度」「規則」、もう少しぼかして言えば、「具体的な行動」です。これまでのお話Nextremerにジョインする半年前、つまり、高知AIラボが立ち上がる半年ほど前、向井(CEO)さんから「エンジニアが働きやすいためにはなにすればいいの？」と仕切りに聞かれました。ジョインしたあと、そのときに答えたこと+@ がなんらかの形で実行されていて、とても驚いたのを覚えています。技術書買える。マシンは希望SPECのものを買える。技術的な実験に必要なものは購入できる。経営者がエンジニアを信じ、エンジニアが正しいと思うことをできるように動く。ノリのサイドプロジェクトやエンジニアの意思による開発を推奨する。 ぱっと見クールを重視する。技術的にイケてるを大事にする。利用ツールを先端（エンジニア）に合わせる。などなど、アドホックではあっても「エンジニアが働きやすい場所を作る」という想いにそった「具体的な行動」がそこにあり、「この会社は本当にエンジニアのことを考えている」と感じたのを覚えています。これからのお話2015年7月から、ご存知の通り急激に社員が増えて行くことになります。人数が増えれば当然、創業者、経営陣と社員が触れ合う時間も減っていきます。社員の視点からは、これまで行われていたアドホックなアクションが見えにくくなり、代わりに制度や規則が視界に入るようになっていきます。この段階に入ると、制度や規則は会社のメッセージの代弁者となり、そのフィルターをとおして社員は会社の想いや価値観を認識し、評価するようになります。だからこそ、制度や規則は、会社や創業者の想いや価値観、文化が正しく反映されている必要があります。現在、これまでアドホックに行われていたアクションを具体的な制度や規則に落とし込んでいる段階ですが、「イケてる会社で働いている」（ワードチョイス自体がオッさんかもしれませんが）という感覚を持ち続けられるかどうかは、この作業の質に強く依存します。技術でお客様に価値を提供し続けることができる組織であるために、検討できることは全て検討し、進められたらと思います。大きくなるとNextremerは次のステージに向かおうとしています（内部情報過ぎたので表現ぼかしてます）。必然的に外部による監査や助言、指摘、口出しなどを受けるシーンも増えるわけですが、やはり、スタートアップとしていかに効率よく働けるかを意識し、一般的な価値観とぶつかってでも譲れないところは譲らない姿勢を貫きたいと思います。少なくとも、現段階では「攻めすぎ」くらいにはいきたいですね。「そもそもなんでリスクなのそれが」は常に問い続けたいものです。制度にはストーリーを 新しい制度、新しい福利厚生を始める時、必ずストーリーや想いをお伝えしたいと思っています。どうして、何を狙ってこれをやるのか。その大義名分を説明することは、発表内容のポジティブ/ネガティブに関わらず常に重要です。このことは完全ガイドに描かれていても良いかもしれません。ネガティブな場合は「協力/理解を得るため」ポジティブな場合は「当たり前ではなく、努力の結果勝ち得た権利だということを共有し、忘れないため」反対に、以下の二つは望ましくないアプローチといえます。本当の理由を隠し、破綻した論理であたかも「正しいこと」かのように取り繕う演出の意図が透けて見える演出をするNextremerの社員はとても優秀です。エンジニアとして自信を失うくらい優秀な人がたくさんいます。だからこそ、小手先の言葉では騙されません。正直に情報を開示し、協力を求めるべきところは求める姿勢が大切だと考えています。自分の環境は自分で作る。空気は読まずに一緒に作る。制度や規則についての提案や制定は、限られた人の権利ではありません。働く人全員がユーザであり、ステークホルダーです。思うことはどんどん声をあげ、会社を働きやすい環境にHackしていくのが健全だと思います。幸いなことに現時点ではそれが許される、むしろ推奨される環境です（続いていくことを望みます）。無関心に流れに身を任せて他にうつるよりも、流れを変えることが比較的容易な社内を変えてみるのも良いのではないでしょうか。それでもコンサバに倒すこともある「いつも攻めまくって限界を探してるウチがコンサバな制度をつくったのだから、きっとよっぽどの理由があるに違いない。」こんな風に思える状態ができると良いと思います。様々な理由で、攻めの制度を作れない場合はいくらでもあります。そんなとき、普段から信頼を勝ち得ている組織であれば、正確な説明さえすれば納得してもらえる可能性が高いです。　逆に普段から攻める姿勢を持てていなければ「本当にこの可能性は検討したの？」「そもそも大丈夫なの？」という状態になり、進行が難しくなってしまいます。この点、とても大事です。制度設計の想いを外部に発信したり、LT大会などで発表してみるのも良いでしょう。こういう話ではない言葉に意味がないということを言っているわけではありません。理念やビジョンはとても大事で、言語化できていないのは課題です。ただし、言葉だけでは不十分です。経営を立て直そうと外部コンサルに頼んで理念とビジョンを、会社全体、各部署にも設置して、、、というテコ入れの現場をなんども見てきましたが、実際の行動の伴わない動きには誰もついてきません。おわりに理想論ばかりで現実を見ていないと批判をうけそうですが、最初から理想を諦めるのと、追求した先に落とし所を見つけるのは違います。ただ落としやすいところに落とすのはもったいないと思うので、エンジニア個人としての見解をつらつら書いて見ました。本編終わり改めて今読むと..こういうものは「合議」で決めるのが正しいとは限らない、ということに言及すべきだった気がする「エンジニアが働きやすい」というよりも「メンバーが働きやすい」だ「働きやすい」というより「パフォーマンス高く...」の文脈の方が労働者発信だとよかったかも言葉も大事だよ（言葉ばっかりで話が終わりそうな空気があったので言葉だけじゃダメだよって強めに描き過ぎてたのかな）割と今も同じ様な考えに近いですが、追記したいことも山ほどあるので後日2019年verとしてリライトすることにします！あと、PSYCHO-PASSというアニメはめちゃくちゃに金言が詰め込まれているので10週以上見てもまだ新鮮に見られる素晴らしいアニメですので、dアニメとかで見てみると良いと思います。

社内制度や規則を整備しなきゃ！というフェーズで考えていたこと - アニメ SYCHO-PASSと制度設計

なんとこの記事はNextremerアドベントカレンダー 2018の 16日目 の記事です！本当に申し訳ございません。qiita.com要旨Twitterで見かけた「タスク完了したら抜けて良いSlackチャネル」を作る的なHackが凄くよかったので真似してみたとてもよかった。でもそれだけだとアドベントカレンダーを埋めるためのエントリにならない気がした「チャネルを抜けちゃうからお礼が言いにくい！」という謎課題をでっち上げたそれを解決する「チャネルを抜けるとお礼を言ってくれるBot」を作った一度記事を書いたが限りなく無価値なことに気づいた。焦った。よく考えたら、チャネルを抜けたときの 完了時のインタラクションが改善された気がする と気づいた。ゆえに、とりあえず課題をでっち上げて何か作って動かしてみると学びがあること、その学びも実はちゃんと考えるモードに脳がなっていないと気づかないんだな、アンテナ大事なんだな、ということに改めて気づきつつ、そんなことなかったかのように「完了時のインタラクションの強化」を目的として導入した程で書いた文章がコチラです。タスク完了した人から抜けて良いSlackチャネル運用とは以下の様な素敵なHackです。感化されて運用をしてみました。社における「全員が済まさなきゃいけない」系のやつ、それ用の Slack チャンネルに人間たちをガッと放り込んで「完了した人から抜けてよい」という方式で進めるの、けっこう効果的でよさそうに見えている。そのチャンネルで呼びかける分には、すでに済ませている人のアテンションを奪わないのがよい。— { 大和田: 純 } (@june29) December 20, 2018june29.jp試してみてとても素晴らしい。リマインドするのが楽（@channelぶっぱなし）誰が残っているのかを確認するのが楽（/who）目的別にチャネルを作るので関係ない会話が始まらない特に２つ目が素敵です。この手の話は「誰がやってくれていて、誰がやっていないのか」を管理するのがとても面倒くさいのですが、そこが見事に解決されています。以下のスクリーンショットでも、誰がまだタスクを終えていないのかが、自動で管理されていく様子がわかります。飲み会やらイベントやらの調整さんによる日程調整にも使えそうですね。完了時のインタラクションを強化するため「お礼を言ってくれるBOT」を投入すごく便利だ！と思い運用していた一方で、細かいですが改善の余地を見つけました。この仕組み、実際にタスクを行う側として使うと、チャネルを抜けた後に「本当にこれでよかったのか？」感が残ります。Slackをお使いの方は実際に/leaveコマンドを打ってみると体験できます。チャネルを抜けると何のインタラクションも無しに直前までみていたチャネルが表示されます。（余談ですが、この感覚は結構不思議です。たとえば「Google SpreadSheetなどに入力してね！」、という運用においても、入力した後に画面を閉じるシーンは当然あり、画面を閉じた瞬間には何のインタラクションもありません。それでもなぜか違和感を感じない。でもこのオペレーションだとなぜか不安になります。この違いはまた今度掘ってみようと思っています）BOT投入ということで、チャネルを抜けた人に あなたの直前の行動は運営のお願い通りですという というメッセージを感謝の心と共に伝えるためのBotを作成しました。使い方は「タスクを完了したら抜けて良いSlackチャネル」にBotを招待するだけ。あとは参加者がタスクを完了させて /leave したらBotから「ありがとうございました！」というメッセージが飛びます。コードはこちら。Slack AppのCreate BotのPermissionを持ったTokenを環境変数に渡してやればすぐに動くはずです。github.com使ってみてチャネルを抜けた後にDMでお礼がくるので、狙い通り「自分は正しい行動をした」という安心感を強化できたと思います。また、運用初期で慣れておらず、終わってないのに抜けちゃった人へのガイドにもなる という予期せぬ効果も発揮してくれました。Botのこれからこの手のチャネルを運用するときにBotが備えていて欲しい様な機能があれば追加していこうかなと思います。単なるリマインダは/remindで済んでしまうし、正直あるのかないのかわからんところですが、とりあえずは以下のようなところでしょうか。使い方やこの手のチャネルの運用TIPSを指南誰でも運用ができるように、チャネルを作ってBotを招待したら、やり方がわかるような発言をするようにした方が良さそう。「このチャネルは、チャネル作成者が指定したタスクを終わらせた人から抜けていけるチャネルだよ！ /leave で抜けられるよ！ まだ残って要る人は /who で一目瞭然だよ！ タスク担当でないけど確認のために入ってもらっている人はミュートしておくと良いよ！」ミュートした人を見つける脅迫的な機能。できるのかな？リマインダ改このボットに「みんなに呼びかけてよ」って言うと、面白おかしくPUSHしてくれる。運営サイドがネタを考えなくていい。全員が抜ける/アーカイブされたら randomとかにお礼チャネルメンバーがいなくなったり、アーカイブされたら【#aaaaaaaでのタスクを全員が完了しました。ご協力ありがとうございました！】的なメッセージを`#random'あたりに打つとか（人がやった方がいい気もしてきた）まとめこのBOTはともかく「タスク完了した人から抜けて良いSlackチャネル」はとても良いので是非試してみては！

【タスク完了した人から抜けてよいSlackチャネル】がとてもよかったので【お礼を言ってくれるBot】を添えて運用してみました

MashupAwardsヒーローズ・リーグ Advent Calendar 2018 の16日目の記事です。すみません。qiita.comMA2018に参加された皆様、お疲れ様でした！2015年にはじめて2nd Stageを経験して以来虜になり、2016,2017,2018と今回で4回目の参戦となりましたが、今回ついにVUI賞およびHackEverything賞(freeeさん) という大変名誉な賞を頂きました。この記事はその参戦記であると共に、MA参戦で学んだこと、そして、MA良いよ！という思いのアウトプットとなります。作ったものこんな感じの だらしないマネージャを救うVUIアプリ - けいこさん(仮) というものを作りました。漫画を読みながら勤怠承認、Twitterをみながら購買りん議の承認、筋トレしながら休暇申請承認！的なことができます。「一覧」「承認」「却下」の5つのアクションのAPIさえ用意すれば、どんなサービスとも連携が可能だったりします。www.youtube.com戦果以下二つの賞を受賞し、2nd Stageでのプレゼン, FESTA2018でのプレゼンの機会を頂きました。数ある素晴らしい作品の中から選出いただき、感謝の気持ちでいっぱいです。副賞を原資に、サービスローンチに向けて引きつづき開発を進めております。VUIヒーロー賞 : VUIのプロの方々に審査で選出される部門賞的なもの(副賞10万円)Hack Everything賞 : freee さんによる 売上を伸ばす/業務コストを減らすの両面で経営者/業務担当者の生産性をハックする作品に送られる賞(副賞5万円)作品紹介スライドはこちら（発表時より少しアップデート）    VUIアプリ - けいこさん / MA2018応募作品  from Takanori Kouroki www.slideshare.netMAに参加している強い人たちからのフィードバックは尊いさて本題です。「何かアイディアを思いついたり、何かを作ったら、色々な人に見てフィードバックをもらうと良いよ」とはよく言いますが、MAに参加することはフィードバックをもらうのに非常に適した場所だと思っています。理由は主に以下の通りです。2nd Stage以降のレベル感を見ればわかる様に、みなさん化け物揃い多様な評価軸が用意されているため、独自の視点をおもちの変態な方々が多い名刺は作品、という価値観で行われる懇親会や個人賞など、作品に対して出場者同士で話をすることを推奨する空気と仕掛けがある（そしてアルコールが入った状態で会話する様にデザインされている）作り手同士の会話になるので、フィードバックが濃くて深い（言語化上手な人が本当に多い）僕としても、今回は2nd StageやFESTA2018で発表できたことにより、よりたくさんの方々と作品について良い点疑問点悪い点、色々なフィードバックをいただくことができました。特に、GameControllerizerでみんなで選ぶヒーロー賞を２位受賞された 消極性研究会 SIGSHY の栗原先生よりいただいたフィードバックからは、僕自身も気づいていなかった今回の作品の性質や、ひいては僕自身の物を創りたいと思う理由などを言語化するヒントを頂きました。#MA_2018 #個人賞 消極性デザイン賞を「けいこさん」の興梠さんにお送りしました！ やる気が出ない勤怠管理に誠実に向き合った実用性の高いVUIソリューションです。 #SHYHACK pic.twitter.com/4qp8gkTTZi— Kazutaka Kurihara 栗原一貴 (@qurihara) December 2, 2018教えていただいた著書-消極性デザイン宣言 はこちら。必読です。消極性デザイン宣言-消極的な人よ、声を上げよ。……いや、上げなくてよい。作者: 消極性研究会出版社/メーカー: ビー・エヌ・エヌ新社発売日: 2016/10/27メディア: Kindle版この商品を含むブログを見るVUI - けいこさんの設計思想ということで、制作当初にはなかった考え方を盛り込みつつ、改めてVUI「けいこさん」の設計について、少しだけ触れてみたいとおもいます。本当は別記事でもっと詳しく、丁寧にまとめようと思っていたのですが、そんなことをすると一生アウトプットされないので、勢いでそのままいくこととします。課題を「やる気」で解決しない人間は基本的に消極的な生き物であり、やる気というのは人間の心、つまり最もマネジメントし難いものの一つです。「やる気を無理に出させるのではなく、やる気がない状態でも使えるようなシステムとインターフェイスを提供する」というのが消極性デザインの基本的な考え方です。勤怠承認や購買りん議の承認作業は、それ自体の重要性は分からないでもありませんし、毎日やれれば数分で終わるものです。それでも巷には、僕の様に勤怠承認を月末まで溜め込んでしまう人がたくさんいます。毎日少しづつ捌けば楽になることもわかっているし、業務としてやらないといけないにも関わらずです。これを「やる気の問題」と片付けていては解決しないことは、歴史が証明しています。「けいこさん」はそんなやる気のない利用者でも、毎日承認作業ができるような仕組みを作ることを目的として設計した結果、VUIをインターフェイスとして選択しました。ちなみに、ターゲットユーザとしては究極的に消極的な「僕」を想定しています。「たとえ2分のタスクでも、なんやかんやでやり始めるのに２時間かかる」という特徴を持っています。使おうとしやすさ over 使いやすさ のためのVUI前述の通り、承認を滞納してしまう最大の原因は毎日コツコツやれないことです。この課題を解決するために必要なのは、アプリの「使いやすさ」よりも「使おうとしやすさ」です。書籍では「アプローチャビリティ」と解説されている概念です。実際、何かの課題を達成するためのツールとしてみた時、VUIは従来のUIよりも使いやすさの面では劣っています。入力が音声に限定されるため、音声の誤認識や言い回しによる言葉の解釈ミスなど、意図通りに動作させるには使う側にも慣れを必要とするインターフェイスです。一方で「使おうとしやすさ」について言えば、常に待機状態でいて一声かけるだけで目的を達成できるという点で、VUIが有利となる局面はたくさんあります。実際、スマホのみの時代には天気をチェックしなかった僕も、スマートスピーカを導入してからは出かける前に天気情報を収集するようになりました。「使おうとしやすさ」には人の行動を変える力があります。他の行動よりも選択されやすくするためのVUIいかに使い始めやすいインターフェイスを備えていたとしても、ユーザに他の行動よりも優先して選択してもらわなければ、利用されることはありません。単に承認作業をサクサク完結させるのであれば、例えば Tinder のようなアプリでも良いのです（実は今作っていますが）。アプリを開くと承認タスクが一つずつ表示され、OKなら右に、NGなら左に、保留したいなら下にスワイプしていき、承認等のAPIコールを裏で非同期に行うようにしてしまえばかなりサクサク作業ができそうです。使っている間の体験は間違いなくこちらの方が良いでしょう。しかしそれでも、承認作業のインターフェイスはVUIの方が優秀であると考えます。上記のアプリを利用するには、前提条件として「スマホを手にしていて、画面を目で確認できる状態であること」が成立している必要があります。この条件自体を成立させることは難しいことではありませんが、一つ致命的な問題があります。それは「 色々なことができすぎる状態であること」です。「スマホを手にしていて、画面を目で確認できる状態であること」というのは、承認アプリを起動することも可能であると同時に、Twitter などのSNSやKindleでの読書、ゲームをすることも可能です。ちょっとした隙間時間ができたとして、それらの楽しい行動を抑えて承認アプリを起動することを選択するには、やはり「やる気」に頼らざるを得ません。ユーザの行動選択には優先順位があり、ユーザはその時々において一番目と判定されたものを行動として選択します。日常的に使われるツールにおいては、この「一番目」になりやすいような設計が重要です。VUIの利用可能条件はスマートフォンの利用可能条件とは重ならず、かつVUIの利用可能条件のみが成立している状態もそれなりに多いため、一番目を取りに行くにはVUIの方が適していると言えます。他のスマホアプリと競い、常時三番、四番にいることよりも、一瞬だけでも一番に確実になれることが重要です。書籍 : 消極性デザイン宣言 にて「二番目のデザイン」として解説されていることを「けいこさん」に当てはめていますながら利用で他の行動と同時に一番になれるVUI先述の一番になりやすいという特徴に関連して、VUI / けいこさん にはもう一つ特徴があります。それは他の行動と同時に一番になれることです。洗濯物を畳みながら、運転をしながら、筋トレをしながら、走りながら、漫画を読みながら、Twitterをしながら、料理をしながらでも利用することができます（本質的に言っていることは前項と同じですが）。また、この特徴は同時に「ついでの原理（こちらも書籍より）」という、他の行動で駆動したモチベーションに便乗する手法にのっとり、利用を開始することを可能にします。例えば家で筋トレをするなら、その近くにスマートスピーカを置いておくことで、「筋トレをしよう！」というモチベーションで筋トレを開始したのち、その勢いを利用して承認作業を始めることができます。「せっかく筋トレ開始したんだかから勤怠承認もしておくか」という具合です。このように、何かのついでに利用することができるという点でも、けいこさんはVUIである必要がありました。共通のインターフェイスで捌ける範囲に機能を限定アプリでできることを「承認」「却下」「保留」「詳細確認」の４つのアクションに限定することで、勤怠承認、休暇申請承認、購買りん議承認など「何かを確認して承認する」という括りができるものは何でも対応できるように設計しました。これにより「とりあえずコイツに頼めばOK」という体験を提供することができると同時に、先述のVUIの「使いにくさ」をある程度補うことが可能です。とりあえずコイツに頼めばOKという体験を提供それが何であれ「あなたが確認して承認しなけれればならないタスク」はこのアプリに聞けば良い、とすることで、ユーザは何も考えずにアプリを使い始めることができるようにしています。これがもし、勤怠承認と購買りん議を異なるアプリで操作する必要がある設計をしてしまうと、ユーザにはどちらのアプリを起動するのか選択を強いることになり、使い始めるコストが増加します。最悪の場合、勤怠承認は０件、購買りん議が2件ある状態で勤怠承認アプリを起動するような事態も発生し得ます。動作をシンプルにして VUIの使いにくさを軽減このアプリを起動した後にアクションは、いくつかの隠しコマンドを除けば「承認」「却下」「保留」「詳細確認」および「もう一度聞く」「アプリを終了する」の6つです。シンプルなアクションのみをサポートとすることにより、音声の誤認識や、言い回しによる言語理解のミスの影響を最小限に抑え、意図した通りにアプリを利用できるようにしています。また、VUIのもう一つの使いにくさの要因である「ソフトウェアの状態をユーザが記憶する必要がある」という点を軽減するため、アプリ内部でどの種類の承認を処理するのかを尋ねる機能も削っています。とにかく何も考えず、読み上げられたことがAcceptableなのかどうかだけを判断し、承認、却下、保留の操作を粛々と繰り返せるようにしました。理想は紙ベースの承認作業+秘書さん実は「けいこさん」の目指すところは、紙ベースの承認作業と秘書さんのハイブリッドです。保育園に持っていくオムツ一つ一つにおなまえスタンプを押すという家庭内業務をしていて気づいたのですが、紙ベースの承認フローというのは、承認印を押す人にとってはなかなかに優秀なインターフェイスであると言え........このあたりはまた書きます。その他の学び - 作品でそもそも論を引き摺り出したい（かも）このアプリを見て「そもそもそんな承認作業要る？」と突っ込みたくなったアナタ。ありがとうございます。懇親会などで話していて、自分はもしかして「馬鹿馬鹿しいルールを守るためにあえて真面目にシステム化して、そもそもそれ必要？という話が出てくるのを狙って開発しているのか？」ということを考えるようになりました。人間のやっている作業を、ITを使ってこれまでとは異なる形、あるいは完全自動に変換することで、それまで見えていた「人間が作業することによる仕事してる感」が削ぎ落とされ、そもそもやろうとしていることが正しいのかどうかに焦点が当たりやすくなるのでは、という仮説です。作品自体は真面目に課題を解決することを目的として制作しつつも、実は既存のルールに対する風刺になっている。思えばこれまで作ったり、アイディアとして浮かんだものはそんな発想を元に生まれてきたものが多い気がします（公私ともに）。もう少し掘り下げる必要はありますが、今回のMA参戦で自分の創作活動のジャンルのようなもののヒントを得た気がしています。おまけ : マントの功罪余談ですが、今回、FESTA2018のヒーロー任命式（授賞式てきなもの）にて、真っ赤でテカテカな生地に「I AM A HERO」とプリントされたマントが配られ、帰るまでそれを着用し続けるという罰ゲーム的な仕掛けがあったのですが、こちらについて。https://protopedia.net/prototype/84c6494d30851c63a55cdb8cb047fadd正直いって非常に恥ずかしく、運営の方々に見つかり怒られるまでは一度外していたのですが、なんだかんだでこれ、あって非常に良かったです。色々考えてしまいネットワーキングが苦手な僕 でも、懇親会の時に「どんな作品で受賞したんですか？」と声をかけていただき、たくさんの方とお話できたのはおそらくこのマントのおかげでしょう。あのマントは「こいつ、自分から誰かに話しかける勇気はないけれど、作品出して、それなりに面白いものを作ったやつだから、話しかけてやりなよ」という運営からのメッセージだった、というおそらく設計されていないであろう、ある意味のSHYHACK効果を実感したことをここに記しておきます。MA2019に向けて(開催されることを信じつつも)来年は身近な課題を、みんなが使える形で、できればソフトウェア領域のみで解決する、的なものを作って出したいと思っています。完全に今年の優勝作品である「Facelot」の影響です。facelotのアイディア、知ってしまえば単純な話なのに、知った瞬間に「うぉぉぉあ」てなる典型的な素晴らしいやつ感。アイディア（それも、純粋にソフトウェアだけのやつ）はまだまだ出尽くしてなどいないと勇気を頂く。 #MA_2018— rocky / ko-rocky (@rocky_manobi) December 1, 2018FESTAの懇親会でお話させていただいたのですが、ものすごくよく考えられていて、最近の若者は優秀すぎる説を強烈に感じた次第です。特に、課題認識における視点がとても鋭く、常に何かないかと考えていらっしゃる様でした。僕もこのような「すごい！けどくやしい！なんで気がつかなかったんだ！」的なものを作れたら良いなと思っています。まとめ今回、精神的/金銭的/労働時間的にもかなりリソースをつぎ込んで作ったので、報われたといいますか、とにかく楽しかったです！ありがとうございました！

MA2018に参戦したおかげで少し語れる様になった - VUI「けいこさん」の設計思想

Nextremer Advent Calendar 2018 - Qiitaの8日目の記事です。qiita.com仕事柄 音声認識関係のDemoアプリを作ることが多く、自然とWebSpeechAPIに対する知見が溜まります。というわけで、今回は社内外で「たまに動かなくなるケースがある」という声を多く聞く「聞きっぱなし」を実装するにあたって必要なイベント発火周りの挙動についてお送りいたします。公式Docsにもあんまり書いていないことを、と思ったらこんな角度になってしまいました。よろしくお願いいたします。注意 : Badノウハウてきな対処を含みます。要旨画面を開いている間、ユーザの音声入力を受付し続ける機能、いわゆる「聞きっぱなし」を実装したいWebSpeechAPIは一定時間無音状態が続くと終了してしまうため、適切にイベントをハンドリングして、リスタートしてやる必要があるイベントの挙動が直感に反するのでその挙動とリスタート処理実装のポイントについてまとめるChromeのSpeech Recognition のイベント挙動それぞれのシチュエーションにおけるイベント発火有無は下記のとおりです（僕調べ）。「騒音」のケースで onerror が発火しないのはどう考えても直感に反し、注意が必要であることがわかります。正常 : 音声が入力され、音声認識が成功した場合無音 : 一定期間、音声が入力されなかった場合騒音 : 音声は入力されたが、言語として認識されなかった場合（キーボードのタイプ音等々）Chrome WebSpeechRecognitionのイベント周りの挙動「聞きっぱなし」実装のポイント先述の挙動を踏まえると「聞きっぱなし」を実装する上でのポイントは以下の２点といえます。無音ケースへの対処無音ケースに対処するため、onerrorイベントを利用します。onerrorイベントの引数にはエラー原因が文字列で渡されるので、それを評価して音声認識をリスタートするのが良いでしょう。const recognizer = new webkitSpeechRecognizer();recognizer.onerror = (e) => {  if (e.error === 'no-speech') {    // 無音状態で一定時間が経過した、ということなので再度音声認識をスタート    recognizer.start();  }};騒音ケースへの対処残念ながら僕の調べた限りでは、騒音ケースに対処するためにはBadノウハウ的な対処が必要であり、完全な動作を保証することもできません。しかしそれでも「たまーに動かない」の「たまーに」の発生率を大幅に下げることは可能です。騒音ケースに対処するためonspeechendイベントを利用します。 onaudioend、onsoundendも発火しますが、無音、騒音ケースにおいて onerrorと排他的に発火するonspeechendをハンドリングする方が(比較的)シンプルで良いでしょう。下準備下準備として、SpeechRecognizerをWrapしたクラスを用意し、音声認識の成否の状態を保持するフラグを持たせます。（なお、recognizer.start()をWrapしたメソッドは Promise 形式にしています。）onstartとonresultのイベントハンドリング処理を記述するところがバラバラなのが気になりますが、一旦おいておきましょう（というか、codeはイメージです）onspeechendのハンドリングonspeechendイベントをトリガーとした音声認識のリスタート処理を実装します。先ほど用意した音声認識成否のフラグを参照し、成功していない場合はリスタートします。また、setTimeoutを用いて一定時間(下記例では500msec) 待つことで、onresultよりも前にrestartがなされてしまうことを防ぎます。  constructor(){    this.recognizer.onspeechend = ()=>{      setTimeout(()=>{        if( this.recognized ){ return; }        this.recognizer.start();      },500);    };  }おまけ : Already Started を無視するすでに音声認識が走っている状態でrecognizer.start()を実行するとエラーが発生します。ほとんどの場合、start()を実行するからには音声認識が起動している状態を期待するはずなので、エラー内容が already started である場合は無視して問題ないと考えます。補足recognizedなんてフラグを利用するならば、騒音でも無音でも発火するonaudioendに対してonsoundendでやったような処理を実装して、onerrorを見ずにすれば一箇所にかけるのに... という考え方もあると思いますが、今回実装したのはあくまでsetTimeoutを用いた実行時間に依存する綱渡りな処理であるため、やはり、公式に提供されて要るエラーケースでハンドリングできる「無音」のケースにおいては、公式のエラーをハンドリングする方が得策であると考えました。おわりに聞きっぱなし 実装する人（などという人が居るのだろうか。MA向けに何か作るとか、そういうネタアプリ作るときなんかにこの手の処理実装の需要はあるかもしれないなとは思っているのだけど、改めて考えるとやっぱり「聞きっぱなし」って現実的に周りの人の会話とかも拾ってワークしにくいからボタン式とかそういうのにしておいた方がよいのだよね...でも、例えば擬似的にVoiceTrigger的なものを実装したいとか、そういうときには必要になるんじゃないかな！）の参考になればと。

Chrome - SpeechRecognition API  :「聞きっぱなし」実装のためのイベント周りの挙動まとめ

登壇すれば、自己紹介が完了した状態を作れる。ただし、そこには「貢献」の心が伴うことComunity Leaders Summit in 高知 Returns というイベントでLTした内容です。スライドが超絶言葉補足前提のものだったので記事で補うものです。「コミュニティ活動を通して得たビジネスやキャリアに関係する良い影響」がお題だったのですが、僕としてはその「良い影響」を得る過程で得たある気づきがとても大きかったと思い、そんなお話をしました。コミュニケーション能力強者が多いコミュニティリーダーの方々、僕のような奴を見かけた時にアドバイスしてやっていただければ幸いです。eventregist.com    コミュニティ活動で得た学び - コミュ障でも新しく友達を作る方法  from Takanori Kouroki www.slideshare.netコミュニティイベントで登壇すればコミュ障でも新しく友達を作れるコミュニティ活動に参加することの大きなメリットに「人との繋がり」があります。コミュニティで知り合った人から仕事の依頼をもらえた、知り合った人の会社に転職した、社内では相談しづらい悩みを相談できた、などなど、人と繋がると良いことがたくさんあります（コミュニティ活動で得られる良い事についてはイベントで色々な方々が語られておりますしたので割愛）。しかしながら、その「人と繋がること」自体が僕らコミュ障にとっては難しい。同じような興味関心を持つ人たちのあつまるコミュニティの中とはいえ、新たな関係を自分から構築すると言うのはとてもハードルの高い事なのです。ということでこの記事では、僕のようにコミュニケーション能力に自身がない人でも実践できる「コミュニティにおける勉強会やイベントで新しく友達を作る方法」についてお伝えしたいと思います。勉強会でのネットワーキングが苦手な人こそ登壇しよう。登壇すると、会場全体に自己紹介が完了した状態が作れるから、話しかけてもらえる確率があがるよ登壇の敷居が高い！と言う人はコミュ力以外で役に立てることを見つけてやってみよう（些細なことでも良いから続けてみよう）。きっと誰かがみていてくれるよ「貢献する」って思いがなければ何をやってもダメ！絶対にダメ勉強会でのネットワーキングが苦手な人こそ登壇しよう僕はいわゆるネットワーキングタイムというのが苦手です。初対面におけるコミュニケーションで色々考えてしまい、なかなか滑り出しで良い会話をする事ができません。昔の自分も、師匠の教えに忠実に外と繋がるべく、勉強会、懇親会に積極参加したものの、一向に成果は得られませんでした（技術的知識の蓄積にはなったのだけど、ここでいう成果とは、色々相談できるような人とか一緒に頑張ろうぜできる人との出会い）ネットワーキングが苦手な理由僕と同じような感じの人いるんじゃないかと期待して書いておきます。そして、こんな人にこそ 登壇 という手段がおすすめです。自分から話しかけるのが苦手話しかける人のことがわからないので、自分との会話や繋がりで価値を感じてもらえるかどうかが不安、そこからくる話しかけたけど微妙な反応をされることへの恐怖故に話しかけられない。話しかけるタイミングを伺うのも苦手、既に誰かと話をしているところに割り込んでいくのは上記の理由より問題外です。心の中(この方どう言う方なのかな。仮に自分が話しかけたとして、この人に何か有意義な時間を提供できるのだろうか。対話システムとかITとか興味あるのかな。またはめっちゃ知ってて僕なんかと話しても新しい情報一つも増えないような感じにならないかな。というかなんか疲れてしゃべりたくない気分だったりするんじゃないかな...あ、誰かと話し始めた。他に空いてる人いないかな〜。あ、とりあえずピザ美味しそうだからピザ食べておこう)こんなことを考えて、お腹だけ膨らませて帰るのが日常でした。自己紹介が苦手シンプルに「僕は〜〜で〜〜をやっています」というのに大きな心理障壁があります。具体的には例えば「興梠です。NextremerっていうAI Techベンチャーで働いています」って言うと同時に心の中（AIって言っちゃったけどこの方はどういう属性なんだろう。AIの定義とか気にする人なのかな。だとするとあとでウチが対話UIメインでやってるって知ったら「対話UI=AI」みたいに考えていると思われちゃうかもしれない。ちょっといやかも。事業としては対話UIが中心であるものの、深層学習/強化学習周りもやっているよと伝えるべきだろうか、対話にしてもDNN使った対話とかも取り組みの研究をしていることを共有すべきだろうか。あ〜いや、だけどそこまで反応ない人だと困るよな。そうだ、僕が前にSIerで働いていたり、IoTとか色々手を出しまくってた話もした方が良いのかな。というか、エンジニアですって言うとどう思うのかな。ちょっとエンジニアリングだけではなくて営業的な部分とか会社経営サイドちっくなお仕事もやっているって言った方が興味持っていただけるのかな、、あ、名刺に高知って書いてある。東京と高知両方あるって言った方が良いのかな。なんで高知でこういうことを〜とか語った方が良いのかな、、、あ〜〜とりあえずどうしようどうしようどうしよう） みたいなことを考えてしまってスムーズにわかりやすく自分を伝えられない事が多いです。せっかく会話が始まったのに、いまいち盛り上がらずにピザを食べて帰るのが日常でした。登壇すると「自己紹介が完了した状態」になるので、話しかけてもらいやすい話しかけるのが苦手なら、話しかけてもらう勉強会で登壇すると、発表中での自己紹介の内容、趣味嗜好、今取り組んでいること、考え方、レベル感、などなど、多くの情報を参加者に届けることができます。相手が自分のことをある程度知ってくれている状態、もっというと 何が共通の話題になるのかを知ってくれた状態を作れます。共通の話題が見いだせる相手には話しかけやすいものです。思い返してください。他の参加者の方には話しかけずらかったかもしれませんが、登壇者にはなぜか話しかけやすかったはずです（空いてれば）。発表での自己紹介は、一対一の自己紹介よりも難易度が下がる登壇は自己紹介の難易度自体を下げる効果もあります。1on1状態の自己紹介とは違い、長く喋っても大丈夫です。そして何より、スライドを使うことができます。登壇するなら場に貢献できる事を話そう【重要】発表するならば、まずは長時間の発表ではなく、尺の短いLT（ライトニングトーク）等が良いでしょう。勉強会によってはLT枠を募集しているものもあるので、そこにエントリーすることでチャンスを得ることができます。ただし、LTといえども舞台を私物化して好き勝手な話をしても状態は好転しないので要注意です。ギブから始まるのが世の常です。何を喋ったらみんなの役に立てるかを考えましょう。僕の人生初のLT登壇は、人生の中で最も思い出したくない瞬間の一つです。発表中は頭が真っ白になり、発表後はすぐにでも出て行きたい気分を必死でこらえ、懇親会的なものにも出ずに帰ったことを覚えています。敗因はもうわかっていて「全然凄くもないのに背伸びをしてすごい人っぽいことをしようとして無価値な発表をしていた」というものです。大抵のコミュニティは寛大です。すごい人たちも強い力を持つがゆえに寛大です。。。寛大な傾向があると思います。しかし、それはコミュニティに貢献しようとする姿勢があることが大前提です。場を私物化して好きなことをいって、それが有益でもないような奴に誰も興味は持ちません。具体的には?では具体的にどんな内容を喋るのが良いでしょうか。ここでは技術系イベントのLTを想定します。客観的に誇れる成果や知識がある場合は素直にそれをシェアすれば良いでしょう。しかし、なかなか見つかるものでもありません。そんなときは「自分の体験」を語るのがポイントです。もちろん、無理に深夜アニメのスライドを挟んでボケる必要はありません（できることをやりましょう）。コミュニティでフォローしている技術を現場に適用した！多様な現場に当該技術がFitする/しない という知見や、新たな適用方法、組み合わせのアイディア、その課題などを提供より良くするためのHowを考えるきっかけを提供普及活動に前向きに取り組む仲間がいるという勇気を提供コミュニティでフォローしている技術の習得に挑戦した！多様なレベル感の人のハマるポイントなど、学習における感じ方を提供（会社での教育に使えるかもしれない）他の人の以前の発表を実践した！発表者への勇気づけシェアした知識が色々な人によって磨かれていくというそれはもう美しい...ネガティブな内容でも全然ありですが、大事なのは身の丈にあった発表をすること。決してマスターではないのにマスターな振りはしない。挑戦のハードルは背伸びしても届かない程度の物が良いかもしれませんが、発表の姿勢は謙虚であることに越した事はありません。ドヤりたいなら発表の前に相応の血反吐を履きましょう。登壇するのはハードルが高い！というひとは、とにかくその場で役に立つと思ったことをやってみよう登壇が効果的であるとはいえ、それは崖から飛び降りるような行為でもあって、中には踏み切れない人もいるでしょう。僕自身は「やってやるぜ！」と息巻いて飛び出すことはできたものの、その後の人生初のLTで大失敗した心の傷はなかなか癒えず、なかなか2ndチャレンジをする事ができませんでした。初対面におけるコミュニケーション能力をあげる以外はいつかは超えなければならない壁ではあるものの、やはり、いきなり超えるのは厳しいものです。というわけで、そこに到るまでのステップ、ないし代替案としてのオススメの行動が 場に貢献する事 です。どんな些細な事でもいいから、以下のような役に立つ行動をしてみましょう。地味ですが、どれも喜んでもらえると思います。前の方の席に座るようにする会場の現状復帰を手伝ってみる（椅子並べ直し / ゴミ捨て）登壇者の言葉に積極的に反応して（うなづく等）登壇者を孤独にしないよう助けるイベントハッシュタグ付きで実況する / 登壇してくれた人を褒めるこれの何が良いかと言うと「話しかけられるきっかけになること」です。「ありがとうございます〜」「いえいえ〜」というやりとりから「普段何やられている方なんですか？」って話しかけられるパターンが期待できます。なんせコミュニティ活動です。コミュ力の高い人は必ずいます。頼りましょう。まず役に立って自らが敵でないことを証明しましょう。すぐに友達とはいかないかもしれませんが、この積み重ねが信頼を産むのです。コミュ力がない分は行動でカバーです。椅子を運ぶのにコミュ力は要りません。続けていけば「You次しゃべっちゃいなよ」みたいに機会を与えてくれたり、発表内容についてのアドバイスをくれるかもしれません。コミュニティのコントリビュータのサポートがあるのです。これなら恐怖の壁も超えられます。まとめコミュ障だけどコミュニティで新しく友達を作りたいと思ったら「コミュニティに貢献」しようそれは登壇でも些細なお手伝いでも良いはず登壇の場合は自分勝手な発表内容でないか注意しよう学習者は潔く学習者としての立場で！そこにいるだけで価値のあるスーパーマンとかは、確かに話しかけられるけど、そんな事は他者が決める事であって背伸びしてすごい人っぽいオーラとか出すとシラけるよ！（自身があるなら良いけど）終わりに発表の内容まとめるつもりだったのにリライトみたいになってしまいました。今回はLTで話した情報量を全部補う(+α)スタンスで書いてみましたが、かなりの文字数いくんですね。それでは追記 : コミュ障という言葉についてうんぬん考えたが一旦これで発表してしまっているのでこのまま公開する。議論が生まれればする。

コミュ障でもコミュニティで新しく友達を作れる ~ コニュニケーションが苦手な人ほど登壇しよう

Nextremerが主催する勉強会「Nextremer Tech Meetup@高知」の第二弾として、「Active Book Dialogueで"エンジニアリング組織論への招待"を読む」というやつをやりました。その際に「あ〜このイベントは場の心理的安全性の確保が大事っぽい」と思ったのでその話を書きます。nextremer.connpass.comイベントの様子はこちら！（本当にありがとうございます）ファシリテータをして頂いた 松浦春選さん によるレポート参加頂いた だいちゃん さん によるレポートABD - Active Book Dialogue とはABDはざっくり以下のような流れで進行するアクティビティです。みんなで集まる一冊の本を切り刻むみんなで分担して読み、要約する成果物を張り出し、順番に発表するみんなが興味を持った所について対話する（ダイアローグ！！）ねらい/効果等は以下、公式サイトより開発者様の言葉を引用します。アクティブ・ブック・ダイアローグ®は、読書が苦手な人も、本が大好きな人も、短時間で読みたい本を読むことができる全く新しい読書手法です。１冊の本を分担して読んでまとめる、発表・共有化する、気づきを深める対話をするというプロセスを通して、著者の伝えようとすることを深く理解でき、能動的な気づきや学びが得られます。またグループでの読書と対話によって、一人一人の能動的な読書体験を掛け合わせることで学びはさらに深まり、新たな関係性が育まれてくる可能性も広がります。アクティブ・ブック・ダイアローグ®という、一人一人が内発的動機に基づいた読書を通して、より良いステップを踏んでいくことを切に願っております。同サイトにてマニュアルも配布されていますので、やってみたいと思われる方はぜひ。また、タイトルにもありますが、今回はエンジニアリング組織論への招待 という本でABDしました。場の心理的安全性の確保が大事奇しくも対象とした本にも書かれているワードですが、このアクティビティを運営するにあたっては、場の心理的安全性を担保することが何より大事だと感じました。本の一部分のみから得た情報を要約するわけです。「完璧なものを出さなきゃ」「変なまとめしたらバカにされる」などという心理が働いていては手が動きません（きっと）。対話においても「いいこと言わなきゃ」「コレを言ったらバカにされるのか」なんて思っていたら発言なんてできません（きっと）。前提条件や目的を丁寧に共有する（した方がよさそう）参加者同士は学びを得るための仲間であり、競争相手ではないこと。対象の本を読んだことがある人も入れば読んだことの無い人もいること。対象の本を専門としている人もいればそうで無い人もいること。同一の事象/事実でも、重要だと感じる部分は人によって違うこと。要約や発表に慣れている人もいれば慣れていない人もいること。何より 目的は対話を通じて得られる能動的な気づきや学びであり、完璧な要約を分担して作ることでは無い ということを丁寧にインプットすることが、より質の高い場づくりに寄与するのだと感じました。もっと言うと、これは僕の所感ですが、多様なバックグラウンド、多様な受け取り方の人がいた方が、むしろその場の学びの総量は大きくなるのでは無いかと思いました（コレはあとで）現場ではどうしたのか...なにぶん作業している途中で気づいたので、超アドホックな対策であることを先に言い訳しておきます。一応僕なりの工夫としては「これ難しいです」「要約ってこんなに難しいんですね」「これ、完璧なのは無理ですよね..全体読んでいる訳では無いし（僕は読んでるけど）」「完璧じゃなくてもいい！ていう場の心理的安全性が大事ですよねコレ...」「時間足りないかもしれないです」のような発言を時折することで「そもそも難しいことをやっていること」「失敗が許容される場であること」を発信してみたりしました。効いたかどうかは分かりませんが、最後まで参加者全員で要約/発表./対話と、勧められたので良かったと思っています。その他感想/気づき/学びチームビルディングに使えそう 松浦春選さん によるレポートでも触れられている通り、これはチームビルディングに効果がありそうです。お互いについて知り、価値観を共有するのに有用なツールだと感じました。週一でチームで時間をとって、取り入れようとしている考え方、導入を検討しているプラクティスなどの書籍を対象に実施して見ると良いかもしれません。ある事柄について、担当個人がまとめたものをベースにディスカッションするのも良いですが、ABDのように一冊の本を分担し、そのなかで皆の関心の高い事柄について対話をすることで、皆で作り上げた解釈/価値観を共有することができるような気がしています。多様なバックグラウンドのある人でやると面白そう今回は参加者全員が「IT系」という属性を共有しつつ、「学生」「社会人」という属性に大きく別れていました。対話における発言の色にも「学生 vs 社会人」の差が出ていて、やはり同じものを見ても背景によって捉え方は違うのだと改めて認識しました。加えて、自分が発言するときにも「この例え方だと SE経験者にしか伝わらないからどう伝えようか」というトレーニングにもなったかと思います。受け手に合わせた情報発信の心ですね。というわけで、デザイナーさんの仕事の仕方について書かれた本をビジネス屋さんとエンジニアとデザイナーさんで読んでみるとか、アジャイル開発系のプラクティスをユーザ企業さんとエンジニアで読んでみるとか、特定の業務知識の本を同じくユーザ企業さんとエンジニアチームで読んでみるとか。やってみると面白そうですね。あ〜、それぞれの立場について主張したい本を一冊出して、それについてABDをやる、、ってすると本当に相互理解できそう。なるほどチームビルディングに使えそう（前項につながる）。皆さん認知の歪みに興味があった模様（というか学生さんでエンジニアリング組織論への招待を読んで何らかの感想がもてるなんてすごいな〜最近の学生さん本当に頭いいな〜）個人のトレーニングとしてもやはり良い本を読んで、要点を抽出して、視覚的に表現して、発表して、対話する、、とまぁ普段なかなかやらないというか、数が稼ぎにくい作業だと思いますので、単純にその手のことに取り組めるのは良いです。特に「発表」のトレーニングとして、とても有効なのではと感じました。発表が上手くなるには「発表することと、その時のフィードバックを得ること」の積み重ねが大事だと思っています。上達のためになるべく数をこなしたい一方で、毎回「発表すべきネタの採掘」という作業が発生し、これが中々時間をくいます。そう言う意味で、ABDに参加すると嫌が応にも発表するネタが降ってくるので、それは良いなと。また、必然的に似たようなトピックに対して皆が発表するので、「上手な人の発表を参考にする」という作業がやり易いというのも良いです。あとは、普通に読むよりも「深く読める」という効能も確実にあります。僕は以前に「エンジニアリング組織論への招待」を読んだことがありましたが、作業中には「こんなこと書いてあったっけ？」と思うことがなんども。やはり「要約して伝える」を前提にして読むときとは、読む深さが違うのだなと改めて感じました。ABD x エンジニアリング組織論への招待 をやったきっかけA. エンジニアリング組織論への招待めっちゃいい本だよ！みんな読んだ方が良いよ！ と言っていたら「じゃあ Active Book Dialogueやろうよ」と言われたからぼくは「エンジニアリング組織論への招待」とう本が大好きです。これはもう良書中の良書というか、凄い本です。どれくらいすごいかというと、読みながら「そうそうそうそう！！！」と叫ばずにはいられないくらいです。チームや組織で仕事をしている人皆が感じ、直面しているであろう課題感（もちろん解決策も）を見事に言語化していて、普段感じていたモヤモヤが一気に晴れるというか、そんな気分にさせられます。絶対みんな読んだ方がよい。チームを作る人も、チームに所属する人も、人類みんな読んだ方が良い。そうすればみんな少しだけでも優しくなれるというか、ちょっと幸せになるというか、不幸が減る。まぁ、めちゃくちゃ雑ですがとにかくそんな本です。と、そんなことをNextremer主催の勉強会@高知 の場で話していたら、その場にも参加頂いていた松浦さんに「Active Book Dialogueやりましょうよ」とお声かけ頂き、開催することになった次第です。追記: あまりにも雑すぎるので書評へのリンクを... （おんなじ感想感覚だと思っています）blog.shibayu36.orgnote.mushufo.github.io最後に企画/準備/ファシリテーションと、イベントのほぼ全てを取りまとめて頂いた松浦さん、ABD経験者としてアドバイス頂いた杉尾さん、参加頂いた参加者のみなさま、僕の「やりたいっす！」に協力頂いたNextremerスタッフのみなさんにこの場を借りてお礼を申し上げます。ありがとうございました！最後の最後にNextremerではエンジニアを募集しています:) ぜひ!!www.wantedly.com

Active Book Dialogue をやるときは「場の心理的安全性の確保」が重要だと思った話  - ABD x エンジニアリング組織論への招待 をやってみて

とある塾の課題です。急遽参加できなくなってしまったため、課題をWebに上げたものです。ふと生活していて気になったこと〜からの〜こういうことだったのか！という気づきについて纏めるものです。100均のフック(?)知人の自宅の壁に100均で買えそうなフックが貼り付けてありました。３つのうち１つが90度傾けて張ってあったのでなんだろうと効いてみたところ、、、こんなふうにタブレットを設置して、ベビーモニタを表示しているとのこと。（実は写真は撮り忘れていたためウチのものです。早速導入しました。タブレットの画面...90度傾いてますね）イオンスタイル豊田母校に講演に行った際に立ち寄った愛知県のイオン豊田で子供のオムツ替えをしていたところ、普段は大暴れするのにおとなしく上を向いて止まっていてくれました。渡したおもちゃに集中しているわけでもなく、おかしいなと思って上をみたら、天井にアニメが投影されていました。洗濯バサミこの手の一般的な製品は、洗濯ばさみの中心の金属部分に紐（といっていいのか）がついていることが多い気がしますが、わざわざ接合部を２箇所にしてあります。下方向の力が加わると洗濯ばさみが開く方向にも力が加わるようになっていて「片手で引っ張って取る」というのがやりやすいようになっているのでは、と考えました。Macの充電器恥ずかしながら、この羽をこう使えるとは、他の人が使っているのを見るまで気づきませんでした。余ったコードを巻き付ける（今更？？って言われそうですが）以上となります m( _ _ )m

とある課題について

最近HerokuでSocket.io依存のサービスを運用する機会があったので手順だけメモ。（日本語記事あまり見つからないので、もしかしたら socket.io-redisがこの問題をも解決してくれているのかな…）症状Heroku上でクラスタリングしたsocket.io(node.js)との接続が確立できない。エラーメッセージは下記2種類。ポーリングで接続成功した後に、websocketにupgradeしようとして失敗しているような感じ。最初に接続確立したときと違うサーバにつなぎに行こうとして怒られてしまっているみたい。Failed to load resource: the server responded with a status of 400 (Bad Request)WebSocket connection to ......... failed: WebSocket is closed before the connection is established.手順heroku側でhttp-session-affinity をONにするsocket.ioのfallback optionをwebsocket優先にする現時点ではChromeやFirefoxであれば1の対処だけでOK。Mac/iOS Safariやnode.jsのsocket.io-clientなどの場合は2の対処までしてやる必要があります。HerokuのHttp Session AffinityをONにする詳しくは コチラheroku features:enable http-session-affinityclient側のsocket.ioのfallback optionをwebsocket優先にするデフォルトではpollling 、websocket の順番で接続をしていくsocket.ioですが、クラスタリングされたサーバに接続する場合は順番を指定して、websocketから繋ぐようにする。付録socket系 x クラスタリングで発生する問題としては、セッションが各nodeで共有されないことくらいで、broadcastのときに困るくらいだろうとタカをくくっていました。Broadcastの問題に関しては別のソリューションで解決していたので、今回はたまたまsocket.io-redisを使っていませんでした。もしかしたらこの問題自体、socket.io-redisが一緒に解決しちゃってくれる可能性もあります。ちなみにsocket.io、以前はwebsocketから順番にfallbackしていっていたのを、どこかのバージョンで逆にするようにしています。そのほうがwebsocket非対応のオールドブラウザでの接続確立までの時間が短くなるという理由らしいです。

Herokuで複数Dynoにするとsocket.ioが繋がらなくなる問題への対処

友人から相談を受けたのでせっかくなので公開する。SIというか、「受託で硬いシステムを作っている会社に属していて、あまり１からのシステム構築とかやったことがない」という状態から、イケてる（と思われる）会社や開発現場に移るためにどんな準備をしたか、ということを書いていく。ちなみに現在はNextremerにてエンジニアをしつつ、高知AIラボのリーダーとして、イケてるエンジニアリング環境を作るため、色々と試行錯誤をしている。スーパーエンジニアではないけど、今は満足したエンジニアリング生活をしているので、誰かの参考になると良いな。注意2012年付近での経験をもとに書いています。時代の違いによる周辺環境の変化についてフォローできているかどうかは保証しかねます。SIがイケていないと言っているのではありません。僕のいた現場が(開発現場としては)イケていないだけです。何をもってイケているのか。よりお金が動いているのは当然SIじゃないか！という議論をここでするつもりはありません。割と僕、その考え方に共感しますが、相談内容にそって、エンジニア的視点から書きました。はじめにまずは前提条件から。抜け出さねば！！と思ったきっかけは以下のとおり。豊田高専情報工学卒 + 1年間米国留学 ののち、2009年にシステム開発会社（前々職）に入社（21歳）1年目,2年目と金融関連のプロジェクトに多数参画し、それなりにできるSE（自称）として勤務2011年暮れ、会社をやめてWeb系ベンチャーに行った同期組と１年ぶりに再開し、自分の技術力の無さ、及び周辺環境のヤバさに気づく2012年1月、レベルアップして環境を変えるための活動を開始最初はなんとなく「バリバリのプログラマ」を目指してスタートしたのだけど、途中からは「ビジネスレイヤと技術レイヤの中間でいい顔をできるポジショニング」に方向転換している。当時考えていたことと、今思えばということとが錯綜しているので、読みづらくなること必至。主にやったことは以下の３つアンテナとポートフォリオの整備技術力の向上（開発/設計/チームビルディング/スタートアップ）プレゼンスとコネクションの整備上の二つは2012年(当時24歳)に自分でやばいと思ってやったこと。エンジニア/ITビジネス屋としての基礎力をつけるためにやった。三つめは、2013年に出会った師匠的な人と一緒に仕事して感じてやった。最終的には「ビジネスと技術のハイブリッド」という方向性を目指すことにはなったけど、二つ目の技術力向上でやったことの蓄積がなければ、薄っぺらい奴になっていたと思うので今の所全部大事だと思っている。アンテナとポートフォリオの整備アンテナ : 情報収集能力とりあえず、業界でイケてそうな奴らは何を見ていて、何を考えているのかを知りたかったので、著名なエンジニア(のちにビジネス屋)をTwitterでフォローした。「XX使って見た」とか「このイベント面白そう」とか「良記事！！」の情報を垂れ流してくれるので、とりあえず情報INPUTはこれだけでもいいくらい。最初は100人くらい。ココみたいなページが割とたくさんあるので参考にした。特定のメディアとかをフォローする手ももちろんあるのだけど、自分で選ぶよりも、できる人たちがシェアしてるやつを掠め取った方が最初は効率が良い。その中でよく目にするようなメディアをピックアップしてフォローするのがオススメ。ポートフォリオ : アウトプットする場所即転職を意識、というよりも、必要あらばいつでも転職できるようにしておくため、自分が何者かを見てもらえる場所が必要だと考えた。内容はともかく、自ら情報発信をしているというマインドセットは加点になるはずだと考え、下記を始めた。ブログ運用をはじめたGithub上での活動を開始したブログ運用当時、自分はサーバ運用を全くしたこともなかったので、さくらVPSを契約してワードプレスを入れて、ついでに自分のプロジェクト管理用にRedmineを入れて運用してみた。今では不要だけど、コードも管理したかったのでSVNとGitの環境整備もしてみた。これらの作業を通じて、ポートやらサービスやらパッケージやらビルドやらSSHやらその辺りをなんとなく理解した。のちの技術書行脚に向けてはかなり役にたったと思っている。とはいえ、その辺りの技術習得の目的がなければ、はてなとかQiita等々、既にあるものに乗れば良いと。ブログの内容は、勉強のときにハマったことだったり、業務で「ORA-XXXXX」的なエラーにぶち当たってトラブルシュートしたり、「xxxxxの調べ方調べて見て」というオーダーに対して調べたことなどのまとめが中心。それなりにアクセスがつくとやる気が出る。（残念ながらさくらVPSのお金払い忘れて解約してしまい、もうブログは残っていない）。ただし、技術ブログは自分の底を晒すことにもなるので、ある程度のレベルに達するまでは見習い感が結構でる。その時はわからないのだけど、結構出る。事実、半年前に当時のエントリを読んだ時には悶絶というか、単純に消したくなった（全部消えたのはワザとではない）。書くことを繰り返すという訓練はとても良いことなのだけど、転職においては短期的な成果は得にくい。短期での転職を考えている場合は、とりあえず書き始めて、今回はそれをアピールせずにゆっくり準備をするなどしても良いと思う（転職先で転職したいと思うことだってあるでしょう？）。ちなみに こんなバカなこと もしてみたことがある。Github上での活動優先度と書く順番が逆になってしまうけど、Github上での活動の方が今は大事かも。まずは勉強の過程で作ったものなどはじゃんじゃんリポジトリにあげて公開してしまうのが良い。PCのdotfiles（設定ファイル）のgit管理とかをやってみるのも良い。現場では何らかの形でほぼ100%使うことになるので、使い方、UIなどに慣れておくという意味でも、きちんと使って見ることをお勧め。技術力向上（開発/設計/チームビルディング/スタートアップ）書籍を読んだ今は動画や質問系サービスも盛り上がっているので前ほどの重要性はないとの見方が強いけども、なんだかんだで基礎力と語れる厚みを身につけるために本は読んでおいた方が良いと思っている。本当は読んだ書籍を列挙していきたいのだけれど、今出先なので方向性だけ列挙する。注意 : 本当に時代の影響を強く受けるので注意。それから、相談してくれた人のことを考えながら書いているのでその辺りのバイアスはあるかな。デベロッパーでもSE的な感じでも、この辺りを知識として知っておいた方が良さそうだな〜と思うものをピックアップしたつもり言語/設計/開発マーティン先生のリファクタリングに始まり、名著と呼ばれるものを中心に読み進める言語としては当時の唯一の使用言語Javaと、個人的に暑いと思っていたRubyを中心に勉強今だとSI以外に行くとすれば言語はPython,Ruby,node.js,php,JVM系となる気がする。関数型に手を出しても良いけどまずは必須ではないと思う。結城先生のJavaのデザインパターン本を写経したのは記憶にある懐かしい（一応知識としては必要だと思っている）ビジネス / マネジメントアジャイル/スクラムの基本（的な考え方）CIとかCDとかLEAN STARTUP的なプロダクトを育てようレイヤの本お堅いマネジメント的な本（ビジネス書も入る）今だとインフラ/アーキテクチャ等々のトレンドとして、マイクロサービスアーキテクチャ/ docker / オーケストレーションツールあたりは知っておきたい今だとDDD流行っているけど,,それから、SIからの転職という意味では「チーム開発実践入門」は読んでみると良いかも。少し古いけど、このレベルでちゃんとやれてる開発現場はまだまだないし、SI現場だとなかなか想像つかないと思うので理想イメージ掴むためにも読んで見た方が良いかと。一次情報へアクセスする癖をつけた何か新しいツールや言語を試そうとする時、最初の方は日本語ドキュメントに頼ることになると思うけど、慣れてきたらインストールや環境構築は公式サイトに行って Get Started の項を参考に行うことをオススメする。一次情報にアクセスできるということは圧倒的なアドバンテージ、というか一次情報にアクセスできないのは圧倒的なディスアドバンテージになるので、英語文書へのアレルギーをなくしておくのはビジネス屋としての生存戦略上必須だと思っている。プレゼンスとコネクションの整備かっこよいサブタイトルだけど、要するにIT勉強会にでました、という話。目的は社外にエンジニアの仲間を作りたかったから。深い情報はやっぱりF2Fでの雑談に限るので。（だから運営を手伝ったりとかも積極的にやった）ジャンルは特定の技術だったり、アジャイルなんかの開発プロセスだったり、転職系、ワークスタイル系だったり、とにかく結構参加した。おすすめとしては、無理目でもなるべく頑張って発表者になること。自分が発表しない勉強会の後の懇親会は辛い。自分から話しかけないといけないので緊張する。一方で発表者であると自分が何者かを全員にあらかじめ効かせた後なので割と色々な人が話しかけてくれる。というわけで、こんな感じです。コミュ力に自信がある人 : IT勉強会に行くコミュ力に自信がない人 : IT勉強会で発表する（コミュ力だけではなく、勉強会に参加する人間で一番学びを得ているのは発表者でもあるのでここはおすすめ）付録 : 移ってから思ったこと準備としてやったことはとりあえず生きているとおもう。実際に移ってみて大事だと思ったのは「カルチャーギャップを埋める」ということ。仕事が降ってくる、というよりも社内で仕事をとりにいく、という考え方でないと振り回されることが多くて苦しいと思う。その代わり、割と自分で正しいと思うことができるし、何より周辺環境の変化に対応する力がついた。自分としては移ってよかったと思っている。（業態の違いと会社の規模が一緒に語られている感はあるけど、likely的な感じであっていると思う ）いま書きながら思ったことだけど、上記の３つの準備は「能動的に動く」という習慣をつけるのにも役に立ったのかなと思った。「自分のポートフォリオを作りたい」という意識でいろんなことを調べて色々なものを作って色々な人と話して色々な人と色々なものを作って、、大変だったけど「自分で何をするか決める」「自分でどうするか決める」という経験を積み重ねるのはすごく大事だと思う。周りを見て見ても、そういう活動をしている人の方が、環境変化にうまく適応できている気がする。それから、 SIer時代の経験は決して無駄ではない ということ。成果物や仕事のやりかたは大きく違うけど、知識として知っておいた方が良いことは本当に沢山ある。「堅くやるならこうだけど、この案件の場合はこの方がいいな」的な判断は、そもそも「堅いやり方」を知らないとできない。なんだかんだでどんな開発現場にも社内外にお客さんがいる。一般的なやり方を知らないことと、知っていて違う選択をすることは大きく違う。SIer時代の経験は確実に生きていると今でも思う（というか最近"特に"そう思う）。エンジニアとビジネス、Web系とSI系、時と場合によっていろんな帽子を組み合わせて戦える人材は、活躍の範囲がとても広くて重宝される。とはいえ反対に、過去やってきたやり方に執着しすぎると、ギャップに対応できずに辛い。大事なのは、今いる場所と過去に居た場所と自分の居たい場所の、環境の違いをしっかりと認識して、アクションを選ぶことなのではないかと書きながら思った。このあたりは改めてちゃんと整理してエントリにした方が良いな。おわりに上記のとおり準備をしつつ、働きつつとやっていたら、機会に恵まれてフラフラここまで、という感じ。道中で大きな借りを作ってしまった方々も居て、現状その借りを返すために今いるところでまずはビッグになろうと言うのが現在のステータス。これから転職を考えている方に少しでも参考になればと思いますです。とりあえず、早足だけどこんな感じ。Done is better than perfect なのでここで終わりにしよう。ちゃんと推敲した記事はまたリライトします。宣伝Nextremerではエンジニアを募集しています。スタートアップのカオス感はありますが、その中でちょっとでもイケてる開発現場になるよう、色々考えてやっています。www.wantedly.com

SI(お堅い/石器時代のシステム開発)業界から抜け出してイケてる開発がしたいと思ってやったこと

株式会社Nextremerアドベントカレンダーの22日目の記事です長年さくらのVPS上で運用してきたブログが、クレジットカード紛失による停止処理、からの支払い情報再設定の忘却により跡形もなくなくなってしまった関係で、またはてなに戻ってきました。というわけで一から再出発です。性懲りもなくJavaScript BoardNextremer高知AIラボ で働いているのでAIネタを書きたいなと思っていましたが、お世話になっている村岡氏とお寿司を食べていたらPuck.jsを託されてしまったので、2年前のコレのノリよろしくGordon Williams氏並びにEspruinoプロジェクトの援護射撃をしてみたいと思います。やることPuck.jsのボタンを押したらブラウザでAlertが出る！それだけだ。Puck.js とはPuck.js - the JavaScript Bluetooth Beaconさらっと紹介します。JavaScrpitで制御できる、いや、JavaScriptでしか制御できないIoT向けマイコンEspruinoシリーズの最新作（2016.12.22時点）。ボード本体だけでなく、BLE(Bluetooth 5.0)、NFCの通信機構や、光、温度、磁気などを測定するセンサー、そしてなんと耐水の筐体までが標準で装備された、脱DIYモデル（なのか？）。ボードの大きさは直径35mmでコイン電池(CR2032)で動作するというのもすぐに何かに使えそう感を醸し出している。開発もワイヤレスで行うことが前提で作られていて、初期から使っている身としては驚くばかり。もちろんGPIOも6個あるので、これまでのような開発も可能。Kickstarter価格は1個28ポンド（3000円くらい？）。ちなみに今は日本でも購入できますが、、、高い。Web BluetoothのためのMacとChromeの準備いつもながら丁寧な公式チュートリアルを参考にすれば迷うことなくセットアップができると思いますが、以下の二つだけは押さえておきましょう。MacでBLEが有効かどうかを確認するこのMacについて > システムレポート > ハードウェア > Bluetooth とたどって、BlueTooth Low Energyが有効になっていればOK2,3年以内に買ったMacならほぼ大丈夫でしょう。ChromeでWeb Bluetoothを有効にするアドレスバーにchrome://flags/#enable-web-bluetoothと打ち込めば、あとはお分かりいただけると思います。上記手順後、Chromeを再起動したのちに、Espruino Web IDEを起動します。最近ではchrome extension版ではなく、オンラインのやつもあるそうです。デバイス接続ボタンを押して、選択肢にWeb Bluetoothが表示されればPC側の設定はOKです。Espruino Web IDE がわからない方はこちら をどうぞ。接続ができたら、コンソールにLED1.write(true)とでも打ち込んでみましょう。赤色LEDが光ってくれるはずです。Puck.jsのボタンでブラウザを操作それではいよいよボタンでブラウザを操作してみます。実際に動くDEMOはgithubページ に置いてあるので、Puck.jsをお持ちの方は使ってみましょう。ソースコードはこちらです。github.comポイントWeb Bluetoothを用いて、といっても実際に直でAPIを叩くことはありません。デバイスとの通信の細かいところをWrapしてくれているpuck.jsを使います。ものすごくシンプルです。puck.jsを読み込む  <script src="https://www.puck-js.com/puck.js"></script>ボタンの状態をリスニングする処理**Listener的なやり方があればと思ったのですが、見つけられなかったので定期的にボタンの状態を読み込む処理を実行することで実現しています。UARTを直接触って、puck.js側もちゃんとプログラミングしてやればもちろん可能ですが、今回は手軽さ重視で。// 0.5 sec 毎にボタンの状態をチェックするfunction startListening(){    setInterval( function(){      Puck.eval("BTN.read()",function(x) {        console.log(x);        if( x ) {          // ボタンを押したらやってほしいことを書く          alert("ボタンを押したな！！！？")        }      });     },500);}ボタン情報取得を開始するボタンこのWeb Bluetooth、Chromeの実装ではセキュリティの関係で、ユーザ操作なしにBLE通信を開始することはできません。よって、制御開始ボタンを配置して、クリック時に制御処理が走るようにします。ボタンだらけですね。<button onclick="startListening()">ボタン制御を開始</button>おわりに日本で決してスケールすることなく、初期からのコアなファンだけが使い続けているEspruinoシリーズ。いよいよエンジニア向けDIYきっととしてではなく、何かの製品に紛れ込んできても良いのでは？という期待をせざるをえませんね！おまけ：せっかくなので音声認識STARTボタンとして何かのプロダクトに使われるかもしれない、と言いましたがその最初の一つは弊社の対話プロダクト、MINARAIかもしれません。試しにCEATEC JAPAN2016でも展示した、高知県の観光案内を音声対話でやってくれる「ザキオとぶらり」に組み込んでみました。ボタンを押したら音声認識をスタートさせる、の図www.youtube.com騒音ガヤガヤの中でも僕の質問を聞き取ってくれていますね。騒音のある環境下における音声認識の大きな課題は、実はノイズよりも「どこからどこまでが答えるべきユーザ発話なのか」をハンドリングするところにあります。例えば近くで人が雑談していたり、館内放送が流れていたりすると、その声を認識してしゃべり始めてしまうわけです。現状弊社は、タッチパネルでボタンを押してから音声認識を開始したり、音声認識は動きっぱなしにしておいて、ボタン付きマイクのボタンを押している間以外は音量が０になるように制御したりして、この問題を避けています（もちろん研究レベルでは正面から戦っていますが...）。ただ、タッチパネルは通常のディスプレイに比べて、現場に設置した場合の耐久性に難があることが、ボタン付きマイクは設置場所やマイクの形状などに制限が出てしまうことがデメリットになっています。と、いうわけで、こういった手軽に使えるIoTデバイスを用いたボタン&ソフト的アプローチは良い解決策になるかもしれません。もしかしたら今後の弊社の展示物にこんなボタンがついたものが出てくるかも。。。。

rocky

【剣盾S17シングル】保険カイオーガもやれるはず-最終1953位/レート1756

スマホでSwitchを操作できるようにして、隙間時間でポケモンマスターを目指す

JavaScriptでちょっと複雑なcliを作るのに便利なEnquirer

新しいチームに加わるエンジニアのための "被" オンボーディングガイド v0.1.0

SlackでDMを受け取るとパブリックチャネルに優しく誘導してくれるDM警察というBOTを作って公開しました

LAPRAS株式会社に入社しました

社内制度や規則を整備しなきゃ！というフェーズで考えていたこと - アニメ SYCHO-PASSと制度設計

【タスク完了した人から抜けてよいSlackチャネル】がとてもよかったので【お礼を言ってくれるBot】を添えて運用してみました

MA2018に参戦したおかげで少し語れる様になった - VUI「けいこさん」の設計思想

Chrome - SpeechRecognition API :「聞きっぱなし」実装のためのイベント周りの挙動まとめ

コミュ障でもコミュニティで新しく友達を作れる ~ コニュニケーションが苦手な人ほど登壇しよう

Active Book Dialogue をやるときは「場の心理的安全性の確保」が重要だと思った話 - ABD x エンジニアリング組織論への招待をやってみて

とある課題について

Herokuで複数Dynoにするとsocket.ioが繋がらなくなる問題への対処

SI(お堅い/石器時代のシステム開発)業界から抜け出してイケてる開発がしたいと思ってやったこと

Puck.js で遊ぶ - Web Bluetoothを使って、ボタンでブラウザを操作する

【剣盾S17シングル】保険カイオーガもやれるはず-最終1953位/レート1756

スマホでSwitchを操作できるようにして、隙間時間でポケモンマスターを目指す

JavaScriptでちょっと複雑なcliを作るのに便利なEnquirer

新しいチームに加わるエンジニアのための "被" オンボーディングガイド v0.1.0

SlackでDMを受け取るとパブリックチャネルに優しく誘導してくれるDM警察というBOTを作って公開しました

LAPRAS株式会社に入社しました

社内制度や規則を整備しなきゃ！というフェーズで考えていたこと - アニメ SYCHO-PASSと制度設計

【タスク完了した人から抜けてよいSlackチャネル】がとてもよかったので【お礼を言ってくれるBot】を添えて運用してみました

MA2018に参戦したおかげで少し語れる様になった - VUI「けいこさん」の設計思想

Chrome - SpeechRecognition API :「聞きっぱなし」実装のためのイベント周りの挙動まとめ

コミュ障でもコミュニティで新しく友達を作れる ~ コニュニケーションが苦手な人ほど登壇しよう

Active Book Dialogue をやるときは「場の心理的安全性の確保」が重要だと思った話 - ABD x エンジニアリング組織論への招待 をやってみて

とある課題について

Herokuで複数Dynoにするとsocket.ioが繋がらなくなる問題への対処

SI(お堅い/石器時代のシステム開発)業界から抜け出してイケてる開発がしたいと思ってやったこと

Puck.js で遊ぶ - Web Bluetoothを使って、ボタンでブラウザを操作する

Active Book Dialogue をやるときは「場の心理的安全性の確保」が重要だと思った話 - ABD x エンジニアリング組織論への招待をやってみて