はじめまして！ブログ初投稿です、プロダクトマネージャーの田嶋と申します。
ユニファへ6/16に入社して、約3週間が経ちました。前職から目まぐるしく環境は変わりましたが、とても刺激的で毎日楽しく仕事をしています！
今回の投稿では、スタートアップ企業のプロダクトマネージャーの仕事ぶりについてご紹介します。 面白そうー！と興味を持っていただけたら、まだまだプロダクトマネージャー採用もやってますので、ぜひよろしくです！笑
続きを読むBUSINESS PERSON'S GUIDE TO DESIGN DRIVEN MGMT.
デザインチーム所属の三好です。
コロナの影響でほとんど外出することがなくなり、本を買い漁って家に籠っていたらいつの間にかこの生活が心地良くなってきました。
最近はデザイン関連のものの他に、写真集や政治に関する書籍、聖典「ヴェーダーンダ」の指南書などを読んでいます。
半分は個人の趣向ですが、この先ずっと創作に携わるのなら専門外の世界もなるべく取り込んでおけば、最終的にアウトプットする段階でそれは必ず糧となるはずです。（たぶんヴェーダーンダでさえも…なるはず…なればいいな）
そのための膨大な節操のないインプットが今回の引き籠り生活で多少は実行できたと思います。
ビジネスパーソンのための"デザイン経営"ハンドブック
これは特許庁から無料で発行し公開している色んな意味で衝撃的な資料です。
若林恵さんという尖った感性を持つ著名な編集者が携わっていて、それが国から出ているということに驚きますし、ビジュアル同様に内容も素晴らしいのですがなんとなく目を通すにはあまりにも濃密でやや骨が折れる内容ではあるので、ここでは特にたくさんの人の目に触れてもらいたいと感じた2つの章のみ添付します。
これはデザイナーのための資料ではなく、デザインに関わる人に向けた資料です。 全てのビジネスパーソンに関わる内容と言っていいと思います。
普段から悶々と感じてはいても中々自分自身のスキルでは言語化が難しい部分を、高い次元で表現してくれているので原文をそのまま共有させていただきます。
興味のある方はこちらから全ページPDFで無料ダウンロードできます（全16頁） https://www.meti.go.jp/press/2019/03/20200323002/20200323002-1.pdf
考察
この数年間でデザインの多様化は猛スピードで進んでいて、もはやデザイナー自身でさえ一体何がどこまでできればデザイナーと言えるのか、わからなくなっている人もいると思います。少なくとも私はそうですし、個人的な経験の浅さもありますが自分自身がデザイナーと言われることには違和感しかありません。
ただ曲がりなりにもインハウスデザイナーとして仕事に携わっていたら、今世の中に求められているものは論理的思考力であるということには気がつきました。
例えば今とても重要視されているUI（ユーザーインターフェース）デザインですが、それには必ずしっかりとしたガイドラインが存在していて、そのルールに沿って作成していけばなんとなくそれらしいデザインが完成します。
しかしそこに留まってしまうとデザイナーとしての自力はおそらく育まれない。その先へ進むには高い思考力と、また作業時間も大幅に必要となります。
なによりインハウスデザインにそれが求められているか、追求できる環境にあるかという大前提の問題がありますが、デザイナーという種族は同じ場所に立ち止まることが許されず、常に個人としての行き先を見据えて行動しなければならないと考えると、今置かれている状況だけを基準に判断することはとても危険です。
ただこれを実行するのは本当に難しくて、そもそも自分の身に置きかえてみるとなんとなくのデザインを作ることさえ四苦八苦していますが。
ところでインハウスデザインの仕事は多岐に渡ります。
WEB、アプリの他にもバナー、チラシ、パンフレット、広告や名刺、必要であれば写真撮影やイラスト、そしてコードも書きます。 その中で紙媒体、グラフィックデザインと呼ばれる分野にはUIデザインのようなガイドラインは存在していない為、自ら情報を整理して最善の方法を探りながら要素を組み立てていきます。それは考える力、個としてのデザイン力が身につきます。
デジタルファーストの現代ではどうしてもグラフィックデザインの重要性は低く見られがちですが、思考力を引き上げるためにはそれを極端に軽視するべきではないと個人的には感じています。
まとめ
その論理的思考力というのが上の資料で語られているデザイン思考（デザインシンキング）ということになると思います。
6章ではデザイン思考の重要性、それは常にオープンエンドであり続けること、予想外の発見を柔軟に受け入れられる思考回路を持つことなどがこれからは必要であると書かれています。”解のない世界に、勇気を持って飛び込む”という言葉が印象的です。
7章では企業の文化性を表現することの重要性、ビジネス上の意味の発想からの脱却についてなどかなり大胆な話を展開しています。そしてインハウスデザイナーとしての価値や使命についても触れてあります。
デザイン思考という言葉のとおり、それはデザイナーが常に普段から意識して仕事に臨んでいる思考回路のことであって、その道のプロフェッショナルでもあります。
未熟な自分自身のことは棚に上げちゃいますが、弊社のデザインチームには基本的にその思考力が備わっていますので、このチームからデザイン思考がもっと広いフィールドへ浸透していくための足がかりになればいいと思いますし、また直接的な数値が見えにくいなどの様々な理由で過小評価されやすい現状が少しずつでも改善されていくことを願っています。
機械学習による時系列データの分類
こんにちは、研究開発部の浅野です。あるプロダクトで、得られる時系列データが正常か異常かを判定しているところがあります。現在はシンプルなルールベースの手法で判断をしており、その精度は約80％と改善が必要です。今回はこれを向上していきたいと思います。幸い正常例も異常例もデータが比較的多くあるため、機械学習の手法を用いることにします。
使用データ
正常例と異常例を約1,000例ずつ手作業で集めました（データ収集, クレンジング, ラベリングは辛いときもありますが大事なタスクの一つです）。そのうち80％を学習用データ、20％をテスト用データとしました。下記の例を見るとすぐに規則性を見出すのは難しそうですが、異常例の方が全体的に値が高めに出る傾向にはありそうですね。
手法
決定木ベースのアンサンブル学習手法で、汎化性能が高く動作も高速なランダムフォレストを使用します(コードはscikit-learnを使えば自明なので特に示していません)。とかくブラックボックス(判断根拠がわかりにくい)と言われがちな機械学習ですが、決定木ベースの手法を用いるとそのあたりはかなり軽減することができます。
データをざっと眺めてみると、最大の値とばらつき具合が判断に大きく寄与しているように感じたので、まずは最大値と標準偏差の値を特徴量として分類器を作成してみます。2つしか特徴量がないので木の深さの最大値は2、決定木の数は3として学習を行いました。
特徴量を増やす
もっと精度を高めるため、関連しそうな特徴量を追加していきます。具体的には、最小値、平均値、中央値、歪度(skewness)、尖度(kurtosis)といったデータの分布に関わる統計指標です。特徴量が増えるので決定木の深さを最大3，数を10として学習したところ次のような結果になりました。
さらに、「最大値ー平均値」や「平均値ー最小値」などのようにより直接的に分布の歪みを捉えることができるような特徴量を追加したり、汎化性能を高めるために不要な特徴量を削除することで混同行列が左のようになり、最終的に異常なデータの検出においてprecision: 94%, recall:97%, f1-score: 96%まで精度を改善することができました。このあたりの特徴量エンジニアリングは機械学習に携わる者として腕の見せ所の一つです。
決定木の可視化
ちなみに、決定木を可視化するためにdtreevizという素晴らしいライブラリがあります。最大値と標準偏差のみで分類を行った際に学習した決定木の一つを可視化した例が下記です。標準偏差が0.09未満かどうかで分類した後に最大値によってさらに分類を行い、それぞれの分岐で正常例や異常例がどんな割合で含まれるかがよく分かります。学習したモデルの妥当性の確認や、推論結果の根拠を説明する際にとても役に立つと思います。
まとめ
ランダムフォレストを用いて時系列データの分類精度を80%から96%まで高めることができました。実はこの後にXGBoostなどのブースティング手法や、深層学習であるLSTMを用いてさらなる精度改善を図る予定でしたが、ブログの執筆期限がすぎているのでランダムフォレストで十分な精度が達成できたのでこれで終わりにします。難しい問題をいかに簡単に解くかが大事。
Google Home Miniで子供のうんちを記録する
みなさんこんにちは。サーバーサイドエンジニアの柿本です。
前回のエントリーにて、リモートシャッターで子供のうんち記録を残すことに成功しました！
しかし、冷静に考えると、
- おむつを交換した手でリモートシャッターを触るのは不衛生
- 私が不在の時に妻が node コマンドを打つのはムリ
- 連絡帳にはうんちの状態（「普/硬/軟/下痢」の４段階）の記入も必要
などなど、実運用に耐えられないことが判明しました。 泣
そこでこれらの問題をまとめて解決するために、 Google Home Mini に記録を残してもらうことにします。
普段は私がカップ麺を作るときのタイマーとして使うのみですが、今こそ家族の役にたってもらうのです！
TL;DR
※音が出ます。音量にお気をつけください。
動画が見れない場合はこちら
目次
構想
IFTTT でつなげることもできますが、会話の柔軟性の点で劣るので、 Actions on Google （ Google Assistant のアプリ開発プラットフォーム）を使うことにします。
親としては子供の「うんちの量」も気になりますので、うんちの「状態」と「量」の両方を記録できるようにします。
Google スプレッドシートへは Google Apps Script で WEB API を公開して追記することにします。ついでにSlackに通知を送ります。
会話の流れはこんな感じでしょうか。
『こんにちは。今日はどんなうんちでしたか？』 =>「今日はかためでした。」 『量はどれくらいですか？』 =>「たくさん出ました。」 『わかりました。かためのうんちがたくさんですね。』
素晴らしい！！これならうんちシャッターの全ての問題が解決されます！
それでは早速作っていきます。
前提
以下はすでに作成済であることを前提とします。
① Google アカウント
② ①に紐づいた Google Home
③ ①に紐づいた Actions on Google のプロジェクト
④ Google スプレッドシート
⑤ Slack のチャンネルと Webhook URL
実装
Actions on Google
Google Assistant アプリを開発する時は、 Actions on Google という開発プラットフォームを利用します。
公式に勝るチュートリアルなし！ということで、以下をざっとこなすと Actions on Google で Dialogflow を使ったアプリ開発の流れが理解できます。
codelabs.developers.google.com
作成した Google Assistant アプリを Google Home とつなげるためにアプリ名を設定する必要がありますので、 Invocation メニューからアプリ名を登録します。
うんちをリポートしてくれるので「うんちリポーター」と命名します。
Dialogflow
それでは Google Assistant アプリの肝となる Actions を Dialogflow を使って実装していきます。
Entity
Entity とは、つまり変数です。
今回の場合、
- うんちの状態
- うんちの量
の２つが Entity になります。
Dialogflow の Entity メニューで、各 Entity が取りうる値とその値を表す単語（複数可）を登録します。
Entity 名をそれぞれ condition amount とし、以下の通りに設定します。
Intent
Intent とは、「ユーザーが○と言ったら×と返す」という会話の１ターンを設定し、ユーザーの発話から情報を抽出します。
最初に「今日はどんなうんちでしたか？」と質問をしたいので、アプリ起動時に呼び出される「Default Welcome Intent」の Responses でその文言を設定します。
どんなうんちだったか、をユーザーが回答した時に、その情報を抽出するために「poop condition」 intent を追加します。
Training phrases にユーザーが言うであろう言い回しをいくつか登録します。
Add user expression に追加をしていくと、事前に Entity で登録した値を検出して自動で condition の値としてハイライトしてくれます。
うんちの量も教えてもらう必要があるので Action and parameters で REQUIRED 項目として amount も登録します。
うんちの量を質問する時の文言を PROMPTS として登録します。これは複数パターンを設定でき、ランダムに選択されるようです。
この Intent が呼ばれた時に Google Apps Script を呼び出したいので、ページ一番下の Fulfillment セクションで Enable webhook call for this intent を On にします。
Fulfillment
Fulfillment では、 Intent では設定できないような動的な返答を作成したり、外部の webhook を呼び出したりできます。
この Fulfillment の実態は Google Cloud Functions のようですが、左のナビゲーションの Fulfillment メニューで Inline Editor を On にすることで、 Dialogflow のコンソールから手軽に実装できます。
エディタに以下を記述します。
// index.js
'use strict';
// Import the Dialogflow module from the Actions on Google client library.
const {dialogflow} = require('actions-on-google');
// Import the firebase-functions package for deployment.
const functions = require('firebase-functions');
// Instantiate the Dialogflow client.
const app = dialogflow({debug: true});
// Import request module to call POST request to the Google Apps Script API.
const request = require('request');
// Handle the Dialogflow intent named 'poop condition' with parameters.
app.intent('poop condition', (conv, {condition, amount}) => {
// Google Apps Script API's URL.
const uri = "https://script.google.com/macros/s/<API endpoint>";
let options = {
uri: uri,
headers: {
"Content-type": "application/json",
},
json: {
"condition": condition,
"amount": amount
}
};
return new Promise((resolve, reject) => {
request.post(options, (err, res, body) => {
if (err) {
// Respond with an error message and end the conversation.
conv.close('エラーが発生しました。');
console.log("error: " + err);
resolve();
} else {
// Respond with the message and end the conversation.
conv.close(`わかりました。 ${condition}のうんちが${amount}ですね。`);
resolve();
}
});
});
});
// Set the DialogflowApp object to handle the HTTPS POST request.
exports.dialogflowFirebaseFulfillment = functions.https.onRequest(app);
前半はおまじないです。中盤の
app.intent('poop condition', (conv, {condition, amount}) => {...});
が poop condition の intent から呼び出される処理です。
後述する Google Apps Script の WEB API に condition と amount の値を POST しています。
処理が正常に完了したら「わかりました。〇〇のうんちが××ですね。」と言って会話を終了します。
Googleスプレッドシート
次は Google スプレッドシートへの記録と Slack に通知を送るための処理を Google Apps Script で実装します。
doGet() 関数や doPost() 関数を定義することで、 Google Apps Script を Web サーバーのように実行することができます。
今回はデータを受け取って Google スプレッドシートに記録するので、 doPost() 関数を以下のように定義します。
function doPost(e) {
// Parse JSON object
if (e == null || e.postData == null || e.postData.contents == null) {
return;
}
let requestJSON = e.postData.contents;
let requestObj = JSON.parse(requestJSON);
// Get Spreadsheet object
let ss = SpreadsheetApp.getActive()
let sheet = ss.getActiveSheet();
// Append "date", "condition" and "amount"
sheet.appendRow([new Date(), "💩", requestObj["condition"], requestObj["amount"]]);
// Call slack webhook to post "condition" and "amount"
slackPoopieReport(requestObj["condition"], requestObj["amount"]);
let output = ContentService.createTextOutput();
output.setMimeType(ContentService.MimeType.JSON);
output.setContent(JSON.stringify({ message: "Successfully saved." }));
return output;
}
function slackPoopieReport(condition, amount) {
const postUrl = "https://hooks.slack.com/services/<Webhook URL>";
let jsonData =
{
"text" : "こんにちは。うんちリポーターです :poop: " + condition + "のうんちが" + amount + "出ました。"
};
let payload = JSON.stringify(jsonData);
let options =
{
"method" : "post",
"contentType" : "application/json",
"payload" : payload
};
UrlFetchApp.fetch(postUrl, options);
}
事前に準備しておいた Slack の webhook を呼び出して Slack に通知も送れるようにします。
実装完了！！
冒頭の動画ではうんちの「状態」と「量」を分けて会話しましたが、１つの Intent で両方を扱うようにしたので、実は以下のように１回の会話で両方を登録することも可能です。
※音が出ます。音量にお気をつけください。
動画が見れない場合はこちら
最後に
Dialogflow は設定項目も多いので所々で迷子になりますが、全体としては少しのコーディング量で Google Assistant アプリが作れることがわかりました。
Fulfillment を使うことで会話の可能性が無限大に広がりますね！
弊社サービスのキッズリーではうんち以外にもいろいろな連絡帳の項目を扱うことができます。
保育士さんたちが手ぶらで連絡帳を記入出来る日も近いでしょう！
ユニファでは うんち 保育をハックするエンジニアを募集中です。
一緒にスマート保育園を実現しましょう！
自分に合う英語の勉強法を探してみました
こんにちは、プロダクト開発部のちょうです。最近実は技術関連のものを勉強してなくて、ネタに困っていました。では何をしているというと、地味に英語を勉強しています。たぶん暇のとき英語を勉強している人もいると思って、すこし自分いまの勉強法を共有したいと思います。
勉強はまず目標があります。具体的な目標もあり、ちょっと評価しにくい英語を話したいという目標があります。大人になって、英語の会話は一番人気ではないかと自分が思いました。それで、いろんなオンライン英会話のサービスがあって、フリートークをしたり、真面目な勉強をしたりします。
自分は今年に入って、同じく英語を話そうと思いました。TOEICで800台の点数をとったとはいえ、一つも話せない気がします。何足りたいと見つけ出すために、本を見て、記事を見て、いろいろ試して、ようやく4月のごろ自分の勉強法を大体できた感じです。
多分自分に合う勉強法を探すのは一番たいへんだと思います。多くの人はオンライン英会話を選んで、オンライン英会話で英語を話せるように期待していたではないでしょうか。英語を話したいなら英語を話そうというのは直接で、よさそうに見えますが、どの段階の人にも適するとは言えないでしょう。
社会人になって、10年以上英語を勉強していた人に合う方法はどんな方法というと、そんな人ぞれぞれな方法ではなく、ちゃんとした科学的な方法論があるはずです。自分最近すごく同感するEnglish Clubの英語勉強術まさにそれです。
どんな勉強法は科学的というと、第二言語を勉強する時間を意識する、つまり短期的で終わるとは言わないです。そして、子供がどんな形で言語を勉強しようと、大人、とくに第二言語を勉強するひとにとってはそのまま活用できないはずです。英語を話したくて最初から英語で話すようなことはあまりおすすめしない、なぜなら、英語の発音は正しくない前提でやるとすると、後で直すのはかなり難しいらしいです。
TOP 英語を話す ↓ ↑ BOTTOM 英語の知識
ではどうなことをやるべきだというと、BOTTOM-TOPとTOP-BOTTOMです。BOTTOMはいままで勉強してきた英語の知識、TOPは英会話です。BOTTOM-TOPは自分の英語知識をフル活用して、話せるようにします。TOP-BOTTOMはよく使われる英語のパターンを学んで、話します。ここで注意すべきのは、TOP-BOTTOMはメインではないです。よく使うパターンだけでは自分は話したいを伝えない可能性があります。
BOTTOM-TOPはいままでみなさんやってきた英語の勉強とほぼ同じです。文法、語彙、表現など無限で英作文作れるはずです。とはいえ、受験のため勉強した内容をほぼ忘れたと思います。ゼロから勉強し直すまではないですが、最低限の知識を持つために勉強するのです。
自分はいま「English Grammar in Use」をすこしずつやっています。世界ベストセラーらしいです。文法1ページに練習1ページ、難しくないが本当に普段に使えるものです。
ある程度勉強したら、第二言語を勉強する人にとって一番の問題：母語を挟んで考えるのをすこしずつ改善します。自分の思考をそのまま英語にするのです。自分はまだこの段階に入ってないので、何も言えないのですが、科学的には第二言語を勉強する人には必要な段階です。
多分どの段階にも注意する必要があるのはやはり発音です。思い込んで発音するのではなく、ちゃんと調べてから話します。発音を直すは正直時間かかります。過去10年以上で間違った発音を直します。
自分も最初から母音と子音を勉強して、すこしずつ単語の発音を直します。おかげて、いまAnki（フラッシュカードで暗記するアプリ）2500カードの中で1/4は発音を直すためのカードです（試しに、southernを発音してみてください。そして発音を調べてください）。
この2つの段階と発音はできたら、そこそこ話せるかもしれません。そしてどんな時間を要するのかはその人いま持ってる英語の知識、発音などによるのです。とにかく焦らずに、1年を目処に勉強しましょう。
いい英語の勉強法を知ったものの、なかなか時間がなくて、文法と語彙を覚えないのも辛いですよね。時間がないのはGTDなど自分の時間を管理する方法と、朝、お昼、夜30分/15分とか確保し、一日2~3時間を勉強する方法もあります。覚えないことのは大人が子供より一番劣るところかもしれません。なので、フラッシュカードで英語のすべての覚えましょう。
（Ankiのパソコンソフトは無料、アプリは3000円）
例えば、フラッシュカードの表でpensionを書いて、裏側年金と書きます。逆に表に年金を書いて、裏側にpensionを書くのです。語彙だけではなく、発音や文法もカードにしましょう。文法は自分が「English Grammar in Use」で間違った問題をそのままにします。あとはTOP-BOTTOMのカードです。例えば、表面に「あなたはレストランに食べ終わって店員さんにレシートをもらいたいときどう話す。」裏側に「Can I have the bill？」、一瞬で思い出すようにこのようにカードにします。
ここでポイントになるのは、自分でフラッシュカードをつくることです。人ぞれぞれに知識が違うので、最初からほかの人のカード一気にインポートして、すこしずつ勉強するのは自分のペースを崩しやすいかつまったくどこからの語彙という情報もないし、逆に勉強の効果は落ちるかもしれません。ある程度自分の知識をためて、自信を持ってたら、Oxford 3000などほかの単語帳を勉強します。
いかがでしょうか。英語の勉強法もいろいろありますが、社会人にとっていい英語勉強法を見つけ出すには難しいかもしれません。そこでぜひオンライン英会話よりもっと科学的な方法ですこしずつ自分の英語力を上げるような方法を試しましょう。
DeepLearning画像分類モデルの処理速度計測
こんにちは、R&Dチームの宮崎です。 DeepLearningの有名どころの画像分類モデルを用いて、CPU環境での推論時の処理速度を計測しましたので、共有したいと思います。
背景
DeepLearningモデルをサービスに適用する際、精度と同様に推論時の処理速度も重要になってきます。AWSなど時間課金の基盤上でモデルを動かす場合、処理速度が2倍になると運用にかかるコストは1/2になるためです。 しかし、論文などでは精度やパラメータ数、FLOPSなどについては言及されているものの、処理速度についてはあまり記述がありません。あったとしてもGPU上での値だったりします。これらの値はCPUで動かした際の処理速度と比例しないため、モデル開発後にデプロイして評価してみると、想定より遅く、こんなはずじゃなかったとなったりします。
一方で、DeepLearningのモデルは、同じネットワーク構造と実行環境であれば、推論するラベルや重みが異なっても処理速度はほぼ変わらないことが期待されます。そこで今回、よく使われる画像分類モデルについて、CPU環境での処理速度を計測しました。皆様のモデル選択のご参考にしていただけると幸いです。
続きを読むAmazon SQSとShoryukenを使ったバックグラウンド処理を検討してみる
Webエンジニアのほんまです。
弊社ではインフラの管理コストを極力減らすため、AWSのマネージドサービスへの利用を推奨しています。（例：RDS -> Aurora)
その中の一つに「バックグラウンドジョブに使うキューストアに Amazon SQS を使う」というものがあります。 SQSを使うことで急な負荷増減やデータ消失への対応といった悩ましい問題から解放されます。
Ruby on Rails で Amazon SQSをストアとするバックグラウンドジョブフレームワークだと Shoryuken がよく使われている印象です。 今回、Amazon SQS と Shoryuken でバッググラウンド処理を動かす方法、そして本番運用を見据えて検討が必要な事項を調査したのでシェアしたいと思います。
続きを読む