リモートワークで IoT 機器がなくてもスムーズに開発できるように簡素なエミュレータを作った話
この記事は Akerun Advent Calendar 2020 - Qiita の9日目の記事です。
はじめまして、 Web エンジニアの meriy100 です。
私は今年の3月に入社してすぐに10月にリリースされた Akerun Connect のAPI とフロントエンドの開発にアサインされました。
しかし、 コロナの影響ですぐにフルリモートとなり自宅で開発することになったのですが、 開発が進むととある問題に直面しました。
開発用の Akerun が自宅に無いので Akerun Connect から施錠解錠操作をしても結果が返って来ないのです (開発用の Akerun は セキュリティの都合上自宅で環境を整えるのが大変で、 ハードウェアチーム優先になっていました)。
結果が返って来ないと結果の表示を実装するためにいくつか手間な作業が入ってしまい、 開発効率が落ちてしまいます。 開発環境で使える Akerun がすぐに使えない状況では困るということで、 当時の Akerun Connect 開発チームで簡単なエミュレータを作ることにしました。
なにをつくるか
前提として、 Akerun Connect の開発チームは全員Webエンジニアで Akerun のハードウェアの仕様や実装は完全には把握していません。 また、 プロダクト開発の真っ只中なのであまり大きなものを開発する余裕もありませんでした。 なのでまずは壮大な構想は描かずに、 以下のような Akerun Connect の開発に必要な最低限のエミュレータを実装することとしました。
- 施錠解錠、 Akerun 状態取得等の Akerun Connect で行える Akerun の操作ができる。
- Akerun Connect と Akerun のやり取りの部分のみを模倣し、 Akerun ハードウェア群の処理は考えない。
- 最終的な Akerun とのつなぎ込みのテストは 開発用のAkerun がある会社でまとめて行う。
どうやったか
開発すると言っても、 Akerun Connect の開発もあるのでなるべく影響が出ないように毎日1時間だけエミュレータの開発に時間をさくようにしました。 また、 この手の開発を一人でやっていると気持ちが滅入ってしまいがち (私だけかも?) なので、 その1時間はペアプロで開発します。
具体的には、 1日目をAさんと Bさんでペアプロしたら2日目は BさんとCさん、 3日目は CさんとDさん といった感じに前回の実装者の内一人と新しい人一人のペアで回します。 特に前回やったことの詳細なレポートを書くのも大変なので、 前回やったことは簡単なメモと前回参加した実装者から共有する形とし、 開発以外の余計な作業が発生しないように調整しました。
結果
開発は10日ほどで終了し、 無事自宅の開発環境でも Akerun の施錠解錠操作等の結果が返って来るようになりました。 具体的には Akerun Connect の開発環境のサーバーからローカルで立ち上げた MQTT サーバーを経由し、Ruby で実装されたスクリプトで施錠解錠結果と同じ情報を開発環境サーバーに HTTP でリクエストするというものです。
実装してしまえば大したことはなかったのですが、 それまでは Akerun のエミュレータを作るならハードウェアの仕様、 実装を完全に模倣しないといけないからコストが掛かる、 と思われていました。実は必要なものはローカルの MQTT サーバーと総計600行程度の簡単なスクリプトのみでした。
できたもの以外の部分で良かったこと
持ち回りでペアプロしたことで、 普段のアプリケーション開発では使わないような Ruby の API や MQTT の仕様などをチームで手を動かしながら共有できたのがよかったですね。 あとは、 フルリーモートが続いて人と話す機会が減ったので1時間のペアプロは良い気分転換になりました。 コロナで息苦しい世の中になってしまいましたが、 誰かと一緒になにかやるのはいつでも楽しいですね!
株式会社フォトシンスでは、一緒にプロダクトを成長させる様々なレイヤのエンジニアを募集しています。 hrmos.co
Akerun Proの購入はこちらから akerun.com
E2E テスト CodeceptJS を日本語対応した Docker 環境でサクッと動かす
この記事は Akerun Advent Calendar 2020 - Qiita の 8 日目の記事です。
こんにちわ。わたくしは 2020 年 10 月にできたての SRE チームに入社しました。
私の座席の目の前には QA チームの皆様がいらっしゃいます。
WEB ブラウザのポチポチの日々から解放すべく
E2E テスト自動化の CodeceptJS の導入に至りました。
そのような CodeceptJS の導入をしてみようという皆様のお役に立てますと幸いです。
さて困った
本家のリポジトリの Dockerfile で起動し CodeceptJS を実行するや否や、日本語対応していませんでした。
日本語のフォントなどを導入する必要がありそうです。
そこで、日本語に対応した Dockerfile を作りました。
https://github.com/Photosynth-inc/CodeceptJS
実行手順
以下をローカル環境で実行するとテストが実施できます。
HOME ディレクトリ以下の work 配下で実施します。
$ cd mkdir ~/work && cd work
Docker 環境を構築します。
$ git clone git@github.com:Photosynth-inc/CodeceptJS.git $ cd CodeceptJS $ docker build --no-cache . -t codeceptjs
設定ファイルを作成します。
$ mkdir ~/work/e2e && cd ~/work/e2e
$ vi codecept.conf.js
exports.config = {
tests: './*_test.js',
output: './output',
helpers: {
Nightmare: {
}
},
plugins: {
allure: {
enabled: true
},
stepByStepReport: {
enabled: true,
deleteSuccessful: false,
fullPageScreenshots: true,
},
retryFailedStep: {
enabled: true
},
},
}
テストコードを作成します。
$ vi sample_test.js
Feature('サンプル');
Scenario('Akerun', ({ I }) => {
I.amOnPage('https://connect.akerun.com/');
I.click('利用規約');
I.see('あいうえお');
});
テストコードを実行します（失敗例）
$ docker run -v $PWD:/tests codeceptjs codeceptjs run --steps
CodeceptJS v3.0.2
Using test root "/tests"
サンプル --
Akerun
I am on page "https://connect.akerun.com/"
I click "利用規約"
I see "あいうえお"
✖ FAILED in 9026ms
失敗すると outputs ディレクトリに失敗したスクリーンショット画像が保存されます。
おまけ
さらに、allure を利用すればもっと可視化され便利になります。
allure によるレポートを生成します。
$ docker run -v $PWD:/tests codeceptjs allure generate /tests/output --clean --output allure-report Report successfully generated to allure-report
表示には WEB サーバが必要なので、ローカルで一時的に以下のようにサービスを立ち上げます。
$ cd allure-report/ $ sudo python -m SimpleHTTPServer 8000 Serving HTTP on 0.0.0.0 port 8000 ...
WEB ブラウザから http://localhost:8000 にアクセスすると以下のようなレポートを参照することができます。
いかがでしたでしょうか？
そんな、株式会社フォトシンスでは、一緒にプロダクトを成長させる様々なレイヤのエンジニアを募集しています。
またお会いましょう。
ベンチャー転職後 SRE で実施した３つの即効施策
この記事は Akerun Advent Calendar 2020 - Qiita の 7 日目の記事です。
はじめまして。わたくしは 2020 年 10 月にできたての SRE チームに入社しました。
ベンチャー企業に転職すると、自由とともに多くのやるべくことに溢れ、目先のことに翻弄されがちです。
そのような中でも、何とかしたいけど何からやればいいか困っているという皆様にお役に立てば幸いです。
この記事では、２ヶ月間で実施して効果があった３つの施策を紹介させていただきます。
当施策は、AWS クラウド環境を前提としていますのでご了承ください。
何からやるか？
困っていることをヒアリングし、課題・タスク・依頼に分類することです。
その上で、緊急度・重要度・解決の難易度を数値化し優先度を決定します。
あとは、優先度順にカンバン方式で上から順にこなしていくだけです。
この課題抽出によって、以下の３つの施策を実施しました。
１）コスト削減
改善施策には何かとお金が必要です。後者の施策を実施するためにも、お金を節約します。
AWS 環境で実施した施策は以下の通りです。
Cost Explorer によるコストの分類
Savings Plan と Reserved Instance の適用
CloudWatch Events による営業時間外のサーバ停止
サーバの棚卸しと削除
たったこれだけで、10 ％のコストを減らすことができました。
２）可視化
サーバは動いているのか？何が重いのか？クラウド環境は大丈夫なのか？というケースがありました。
お客様の方が、先にサービスの異常に気付くようでは機会損失になります。
そこで、以下のツールを導入しました。
Pingdom: Web サイトにヘルスチェックを実施しサービス監視します。
大手クラウドサービスあるようなサービス稼働率のポータルを誰でも参照可能な URL で自動的に生成することができます。
Pingdom PagetDuty: 監視システムなどのアラートを受けインシデント発生をエスカレーションに基づき電話通知するサービスです。
AWS Config: 自社の AWS の設定をセキュリティ分析し世にあるベストプラクティス（CIS や PCIDSS など）との差異がわかります
AWS Config NewRelic: アプリケーションのパフォーマンスやボトルネックを可視化します。
これら施策によって、機会損失の最小化と、問題を解く鍵が揃いました。
３）パフォーマンス改善
開発環境や本番環境のボトルネックを把握し、改善施策を実施します。
開発環境がよくなれば開発スピードが向上し売上にも貢献できます。
NewRelic を利用すれば、各分野の達人に頼らなくてもある程度のアタリがつきます。
WEB ブラウザ上から、どのレイヤーのどの処理が遅いのか分かります。遅いクエリーも分かります。
いかがでしたでしょうか？
指標の可視化による共通認識の醸成や、効果的な施策による信用貯金を得ましたね。
変革を起こす準備が整いました。
そんな、株式会社フォトシンスでは、一緒にプロダクトを成長させる様々なレイヤのエンジニアを募集しています。
またお会いしましょう。
組込み開発にスプリント開発を取り入れた話
この記事は Akerun Advent Calendar 2020 - Qiita の 6 日目の記事です。
はじめまして、AkiAbe - Qiita です。
(まさか、初記事を誕生日に合わせて書くことになるとは思いもしませんでした。)
私は、2020/9 から Photosynth にジョインした新参者です。
2020/11 から弊社の組込みエンジニアチームでは スプリント開発を取り入れています。
ということで「組込み x スプリント開発」の話を書きます。
導入のきっかけ、背景
入社して一ヶ月くらい状況をみて感じたことを一言でいうと
「みんな、自分の作業 (主担当のデバイス) 以外のことに興味なさそう。チームとして機能していないなぁ。」
という印象をうけました。 (二言になっちゃったw)
以下、それぞれ文字にするとこんな感じです。
おそらく、どこの開発現場でもあるような気はします。
スケジュール全体の期間が大きい (クォーター単位とかでの管理)
メンバー全員が、途中途中で「プロダクトのあるべき姿」を共有できていない。
スケジュール完了にむけて、1 ヶ月後にどうなっているべきか？ 2 週間後はどうか？の認識に差異がある属人性が高すぎる
デバイスごとに担当者が固定になっていて、リーダー以外はフォローできない。
このご時世なので誰かが長期休んだり、特定のデバイスに機能追加が集中したら
一気にボトルネックとなりそう。
しかもチケットは切っているが中身が何も書かれてないものがほとんど。。作業進捗の遅れの検知が遅い
リーダーと担当者しか作業の内容や方針を把握できていない。
そのため、デイリーなどで進捗報告を聞いても
「本当に大丈夫？」「こういうことは考慮しなくていい？」
などのツッコミが、リーダー以外からできない。
しかもチケットは切っているが中身が何も書かれてないものがほとんど。。(再掲)レビューのタイミングが遅い
設計レビューの明示的なタイミングがない。
コードレビューで設計内容をみるような形 になっていて
何か問題がおきると手戻りが大きくなりすぎる。機能品質と性能品質 (機能要件/非機能要件) がごっちゃになっている
機能を作りこむタスクで、性能面にベクトルが向いてしまうことがある。
一つのタスクの中でいろんな作業を混ぜ込んでしまい、完了時期がうやむやになってしまう。
改善したいこと
チームとして機能する状況をつくりたい。
全員が 1 ヶ月後、2 週間後、1 週間後、プロダクトがどうあるべきかを理解し
全員が 1 週間後のあるべき姿にもっていくために全力で取り組める環境にする
必要があると感じたため、スプリント開発を取り入れてみました。
決めたこと
スプリント開発に向けていくつか決め事をしました。
走りながら改善をする前提ですが、何もルールがないと始められないので
まずは以下のように定義しました。
スプリント期間
1 スプリント 1 週間 とします。
- 毎週木曜からはじまって、水曜の午前中までが一つの区切り
- 木、金の 2 日働いて、土、日でしっかり休んで、月、火の 2 日で終わらせる
というサイクルを目指します。
チームとして過去にもスプリント開発をしようとしたことがあるそうですが、当時はうまくいかなかったそう。
スプリント期間を短くして体に染み込ませられないかなぁと思い、短く設定しました。
定常的な会議の時間
以下の 3 つの会議を設定しました。
- デイリースクラム (月、火、木、金で 15min )
- 話す内容は以下の通り。込み入った話になりそうな時は、気づいた人が勇気をもって「別でやりましょう」という。
- 昨日やったこと、それにどのくらい時間をつかったか
- 本日やること
- 困っていること
- 話す内容は以下の通り。込み入った話になりそうな時は、気づいた人が勇気をもって「別でやりましょう」という。
- 次スプリントに向けたタスク分割 (火曜午後、各担当者 30min を目処)
- スプリントの振り返りと計画会議 (水曜午後、max 2h を目処)
ポイントの決め方
後述するようにタスク粒度をちょっと粗めに定義しているので 1pt を 4h とする。
1 人あたりの 1 スプリントの稼働時間が 4.5 日で、各自事務作業や割り込み時間があることを想定して 1 日 7.5h 稼働できる
という前提でポイントの計算をする。
また、次スプリントを計画する段階で目に見えた割り込み (例えば過去機種の障害調査の依頼がきている) なども考慮して
チームの総ポイントを決定します。
タスクの粒度
1 タスク、最長 2 日としています。
1 タスク、1 日 or 半日で終わる粒度にもっていけるのが今の自分の理想。
作業管理ツール
backlog を使います。
というのも、弊社は組込み開発チームと横並びで、ハードウェア開発チームも存在していて
私がジョインする前から、両チームのタスクをまとめて backlog で 1 つのプロジェクトとして管理しています。
ハード開発側は backlog で、組込み開発側は redmine で、とツールをばらけて管理すると
統括のマネージャーが発狂してしまいますw
ので、本プロジェクトでは backlog をそのまま使い続ける決断をしました。
backlog の運用方法
backlog の使い方もある程度ルール決めました。
- スプリント期間の進捗を管理するための、専用のマイルストーンを用意
- マイルストーンが一週間ですべて完了になるようにするのが目標
- 作業中に気づいたタスク (障害含む) はそのマイルストーンではチケット発行しない
- 要は、「計画されてない作業はやらない」というのが基本スタンス
- 作業中に発見した不具合などは、次スプリントに回す
- (ただし、他チームが関わるような内容の作業の割り込みは容認する)
- 振り返りが終わった時点で、完了になったタスクのマイルストーンから外す
- これにより、毎週マイルストーンが「1 週間でやるべきもの」でリフレッシュされる仕組み
管理の側面 (苦労話含む)
ここからは管理側の側面から。
まず言葉の定義
ストーリー、タスクなどの意味合いもチーム内でズレないように定義します。
今回は、一般的な定義をそのまま踏襲させてもらっています。
IoT デバイス開発にかかわらず、基本的な開発の流れってこんな感じですよね。
- A ということがしたい (ユーザストーリー : ステークホルダーの要望の単位)
- じゃあ B 、C、D みたいな振る舞いがいるね (ストーリー : プロダクトオーナーの考える分割できる機能の単位)
- B を実現するためには、X, Y , Z という手順でやらなきゃね (タスク : 開発者が作業する単位)
それをスプリント単位で考えると、GUI 系の開発を例とすると
- スプリント 1 では画面だけ作ってリリースしますね。
- スプリント 2 では、このボタンの動作をリリースしますね。
みたいな流れですね。
組込みで言うと
- スプリント 1 では LED やディスプレイ使えるようにします
- スプリント 2 では BLE 通信してその状態を LED の変色で通知します
みたいな感じで分割ですかね。
ストーリーの管理
弊社では、ハードウェア開発と組込み開発を並行して走らせており
ハード/組込みの開発スケジュールをミックスして管理しています。
そこで定義されてるソフトウェアの 1 機能を 1 ストーリーとしました。
また、上述のものは大枠のスケジュールとなるため実際にその機能を作るのに
どれくらい時間がかかるかは考慮されないことが多々あります。
( イメージしやすくするために少し乱暴に書くと 「X 月までにはこの機能できてないと困る」みたいな感じのスケジュール。)
そのため、一番最初に各ストーリーを、プロダクトオーナー、スクラムマスター、開発リーダーで粗めのタスクに分割して
「ざっくりと 1 スプリントでこのあたりまでやる必要がある」
というのを決める (ゴールを共有する) 作業をする必要がありました。
この作業を進めていくと
「ストーリー A は 3 スプリントくらいかかりそうだな。」
などが見えてきます。
こうやって、
・各ストーリーは実際のところどのくらいの期間をみればいいのか ・そもそも期間内に全部のストーリーの完遂が可能なのか
を具体化するところからはじめました。
このように洗い出しをした後に、プロダクトオーナーとステークホルダーとで
納期や優先度の調整をしなければなりません。
これができないと
「できない約束 (もしくはデスマーチをして作る約束) 」
を、してしまうことになります。
そのため、「規模感を改めて開発チーム内で見積もる」を丁寧にやることが
とても大事なことだと感じています。
「できないことをできない」と言うことは悪いことではなく
「やりきれないことをやります」という約束をするのが一番悪いこと
だと、私は思っています。
タスクの管理
スプレットシートでストーリーとそのタスク、さらにスプリントの状況をまとめています。
次の項目と同じシートをつかって
というような流れでやっています。
スプリント内で、見積もり超過しているような作業があれば、デイリースクラムで
backlog のチケットを開きながら、状況確認をするようにしています。
IoT 開発ならではの問題点
既出ですが、弊社はハードとファームを並行して開発しています。
そのため
- メカのこの部品を変えたいから、それに合わせた試作ファームを作って欲しい
- 回路のここがちょっと怪しいので、こういう評価できるようなファームを作って欲しい
などなど、ハード設計 FIX に向けて緊急で対応しなきゃいけないことを
お願いされることがしばしばあります。
製品開発上、必要な作業なので対応必須なのですが、そうすると当初の
スプリント計画が崩れて、スプリントの積み残しが増えてきます。
このあたりの割り込みを予想したうえでスプリント計画を立てるのに
なかなか難しさを感じています。
ベストプラクティスは見つかっておらず、余裕を持ったスプリント計画にして
対応をしていますが、そうすると、全ストーリーの完遂が難しくなるという
あっちを叩けばこっちが出てくるような状態。。
1 ヶ月たった現状はどうなったか
もう 12 月になるのでスプリント開発に取り組んで 1 ヶ月が経過しました。
状況的には 、このあたりは改善傾向にありそうです。
- メンバが自分の担当外の作業の状況も気にするようになった
- チケットへの記載も丁寧になってきたため、情報の蓄積も共有も進んだ
まだまだ改善すべきこともたくさんあるので、これからも改善を繰り返して
よりよい製品をつくるために、よりよいチームビルディングができればなと思っています。
株式会社フォトシンスでは、一緒にプロダクトを成長させる様々なレイヤのエンジニアを募集しています。 hrmos.co
Akerun Proの購入はこちらから akerun.com
エンジニア採用が成功した2020年振り返り
この記事は Akerun Advent Calendar 2020 - Qiita の5日目の記事です。
ishturk - Qiitaです。フォトシンスの開発部でハードウェアグループのGMやってます。
今日はエンジニア採用の話を書きます。
採用に関わり始めてからいつの間にか2年以上が経過していました。
担当しているのは
- 求人票作成
- エージェントへの要件説明、Q&A
- 書類審査
- 一次面接
です。
なんと今年度、ハードウェアエンジニア（組み込み・メカ・エレキのエンジニア）で8名の採用に成功しました！
入社した皆さんには早速大活躍いただいております。
実は、ベンチャー界隈でのハードウェアエンジニアの採用はとても難しいと言われています。 実際、過去はエージェントからも厳しめのフィードバック（条件を某業界よりも良くしないとなどなど）を受けていました。
そんな中で大成功に至ったわけですが、今年度特に注力していたコトを言語化してみたいと思います。 一般論・ベスプラはその道のプロの方々が発信していると思うので、私自身の想いが強いところをピックアップします。
1. 採用人事担当・エージェントとPDCAを回す
書類審査・面接結果を眺めながら人事・採用担当とブレストします。それまでも結果はもちろんお伝えしていたのですが、双方向の対話でマッチしたポイント・ズレのポイントを認識合わせしました。これを何度か繰り返しているうちに採用担当に理想形をより具体的に持ってもらうことができました。
次にエージェントですが、その業界（ハードウェアエンジニア）を得意としているエージェントでも、採用したい人材は企業によって違うし、同じ企業でもタイミングによって変化するもの。 今年は特に説明会を採用担当人事がアレンジしてくださり、直接対話する機会をとても増やすことができました。 なかでも、
必要なスキルをもっているのは、どんな業界で何の製品開発している人か
について仮説をたて、紹介してもらった結果をフィードバックするということを繰り返しました。 結果、エージェントと視座が合ってくるのを体感し、紹介の精度も確実にあがりました。これは成功体験です。
2. 書類でしっかり落とす
面接って、する側も受ける側も、とても（時間的・精神的）コスト払うんですよね。なので「とりあえず面接」は絶対にしない。 私も慣れないうちは、機会損失を恐れて沢山面接していたのですが、書類がイマイチで面接でマッチした人ってほぼいないです。
書類でロジカルかつ要点を説明するというのはエンジニアに必要なスキルセット。 かつ、「候補者が要点と考える点が我々とマッチしているか」が、カルチャーマッチのリファレンスになっていました。
皆さん書類はしっかり書きましょう。
3. どの候補者に対しても、良さを語る
これは自慢なんですけど、弊社は良さを語れるところがとても沢山ありまして。
とくに開発部だと、
- 製品の面白さ
- 働きやすさ
- チャレンジできる環境
- 守備範囲を拡げられる環境
などなど、何時間でも良さを語れるところがあります。 面接では、どの候補者に対してもしっかり語りました。 実際、面接開始5分で（ナンカチガウ）と結果が出る場合もありますが、それでもしっかり語ります。 それが自分自身のトレーニングにもなりますし、なにより、入社される方でなくても、弊社に良いイメージを持って帰ってくれたら嬉しい。
そして、選考に進んでもらえる方の多くが、そこから双方向の対話になる方でした。その対話が入社後のギャップを埋めているとも思います。
4. リファラル
コネ最強です。成功しているベンチャー初期はほぼこれです。どのステージでも揺るがないやつ。
以上です。
弊社は成長スピードがすごいので、各部署で難易度の高い採用に挑戦しています。そんな中で丁寧に向き合ってコミットしてもらえる人事採用の方々には大感謝。
自分自身の変化としては、採用とかキャリアに関わっている人のTwitterのフォロイーが無意識に増えてました（笑）
まだまだエンジニア募集しておりますので少しでも興味持たれた方、ぜひご連絡ください！
株式会社フォトシンスでは、一緒にプロダクトを成長させる様々なレイヤのエンジニアを募集しています。 hrmos.co
Akerun Proの購入はこちらから akerun.com
オフィスを改造してドッグフーディングしている話
この記事は Akerun Advent Calendar 2020 - Qiita の 3日目の記事です。
こんにちはyuyakmです。 今回はエンジニアがオフィスを改造しながらドッグフーディングしているという話をします。
タッチレスエントリーの紹介
2020年6月にリリースしたタッチレスエントリーというソリューションがあります。 akerun.com
リンク先の動画を見ていただくとわかりやすいのですが、普段使っているドアを自動ドア化して解錠と一緒にドアも開けるようにしてしまうという機能です。
コロナウィルスの感染拡大に対して、フォトシンスとして何かできないか？ということでドアノブに触れずに出入りができるタッチレスエントリーを急遽リリースしました。 新型コロナウイルスは飛沫感染と接触感染によりうつると言われており、ドアノブを触れずに通過することで接触感染リスクを下げることができます。 おかげさまでオフィスだけでなく不特定多数の人が出入りするシェアスペース等のお客様からもお問い合わせをいただいており、導入が進んでいます。
また、感染対策だけではなく、ICカードをかざすだけでドアが開く体験はとても快適です。慣れた状態でタッチレスエントリーが入っていないドアを通ると、「あ、ここは自分でドア開けるのか…」と残念な気持ちになってしまいます笑 システム利用料の増額なしで使えますのでぜひ。
プロダクトが生まれた背景
この機能はコロナ流行に合わせてタイムリーに提供開始したのですが、実はコロナよりも前にエンジニアの遊び心で生まれた機能でした。
こんなノリ
- 電動のドアクローザーを見つける→開閉体験センサーに引っかかる
- Akerunコントローラーでいい感じにできそう
- 開発部でドッグフーディング→ええやん
- コロナ対策で何か貢献できないか？→タッチレスエントリーとして製品化
- 全社でドッグフーディングしながら提供準備
社内テストの様子
まずはDIYで設置してみた
ドアクローザーとは無電圧 a接点で接続
ちなみに、ドアクローザーには
- ドアが開く側に設置するスタンダード型
- ドアが開く側と逆に設置するパラレル型
があり、このドアクローザーはパラレル型です。ドアクローザーが見える側（PhotoLabの外）に立つとドアが奥に開くことがわかります。 なぜこの製品がパラレル型なのかなと思ったのですが、自分の中では雨風を避けるためだという説が有力です。日本の住宅の玄関ドアは外開きの比率が高いので。
電動ドアクローザーの動作確認（Akerunがなくても押すと開く）
商品化の検討
その後、プロダクトマネジメント室やマーケ部門と製品化を検討することになり、 * 製品としての仕様の決定 * 執務室に設置して全社で使う * QA * 販売・導入フローの設計 * リリース準備 等を経て製品化になりました
製品化検討時には執務室のドアにも設置
執務室のドアにも設置し、全社で使い勝手の確認や不具合の洗い出しをするドッグフーディングを行っています。開発中の製品なので不具合が発生し迷惑をかけてしまうこともありますが、大人数で使うことでわかることも多いので感謝。
まとめ
ということで、社内でドッグフーディングしながら開発しているよという話でした。
フォトシンスには下記のような文化があり、大切にしていきたいです（まだまだ理想とは遠いのでもっとやれるはず！）
- それぞれのエンジニアがアンテナを張る
- テクノロジーを使って何ができるのかを見せる
- 最新のテクノロジーではなく、最適なテクノロジーを使う
- 幅広いレイヤーのエンジニアが集まってさくっとアイデアを形にする
- 顧客に提供する価値にこだわる
- 全社ドッグフーディングで改善する
補足すると、遊び心を発揮する時間をつくることはかなり難しいです。正直、決まっている開発ロードマップを実現するためのタスクに追われてそれどころではない感もあります。強い意思を持ってあらゆるアプローチでやらないとできないことだと思います。 また、実際にユーザーに届けて価値を感じてもらわなければ意味がないので、プロダクトの目指す方向性やそのための課題の認識が揃っていることが重要だと思います。
株式会社フォトシンスでは、一緒にプロダクトを成長させる様々なレイヤーのエンジニアを募集しています。 一緒に感動体験をつくっていきましょう！ hrmos.co
Akerunに関する情報はこちら。お気軽にお問い合わせください akerun.com
Web開発チームから組込み開発チームに移った話
この記事は Akerun Advent Calendar 2020 - Qiita の2日目の記事です。
どうも、1日目に続きdaikw - Qiitaです。
1日目に「いつの間にかハードウェア開発に参加していた」とか書いてましたが、僕個人のモチベーションや会社からの期待値について触れておくいい機会かなと思ったので、記事にまとめようかと思います。trailblazerたれ。
モチベーション
仕事を定義したり、何か情報を他人に伝える時は、モチベーションや契機についてのセクションを一番最初に持ってくるのが僕の最近のトレンドです。これが伝わらないとやる気も起きないし、細かい配慮などできないですよね。
さて、僕が Photosynth に入ろうと思ったのは、ハードウェアとソフトウェアのインターフェースをよりよく知るきっかけになると思ったからでした。ハードウェアもソフトウェアも両方開発しているイイ感じの企業、ないかな〜と思って偶然見つけたのがここ。最近気がついたのですが、パタヘネのサブタイがドンピシャです。
- 作者:ジョン・L. ヘネシー,デイビッド・A. パターソン
- 発売日: 2014/12/06
- メディア: 単行本
つまり、急に組込み開発にモチベーションを持ち始めたのではなく、初めから持っていたということになります。1年半くらいかかりましたが、Web開発も楽しめたのでそれは良かったかもしれません。おかげで面白い人たちにも巡り合えました。
キャリアについて聞かれるが
頻りに未来のことを気にされる方がいます。例えば、「ハードウェア開発をやってそのあとどうするの？」とか。ここではより良く稼ぐための方法を考えるのがキャリア戦略で、それについてどう考えているかを問われていると仮定します。
これを聞かれるとかなり回答に窮するのですが…というのも。
未来予測は元来難しいタスクであり、投資家の平均的パフォーマンスがインデックスに劣ったり [1]、
投資信託ファンドは、経験豊富なうえに猛烈に働くプロフェッショナルが運用しており、彼らは巧みな売り買いを通じて、顧客のために望みうる最高の結果を達成できると考えられている。にもかかわらず、五〇年間にわたる調査の結果には議論の余地がない ── 彼らの運用成績は、ポーカーよりもサイコロ投げに近いのである。少なくとも投信ファンド三件に二件は、どの年をとっても、市場全体のパフォーマンスを下回っていた。
さらに重要なのは、ファンドの運用成績は、どの年をとっても前年実績との相関性がきわめて小さく、ゼロをほんのわずか上回る程度だということである。つまり、ある年にうまくいったファンドは、ほとんど幸運のおかげなのだ。サイコロの目がよかったということである。
政治・経済の専門家が政治経済動向の予測を全くできなかったり [2] します。
Tetlock decided to put expert political and economic predictions to the test. With the Cold War in full swing, he collected forecasts from 284 highly educated experts who averaged more than 12 years of experience in their specialties. To ensure that the predictions were concrete, experts had to give specific probabilities of future events. Tetlock had to collect enough predictions that he could separate lucky and unlucky streaks from true skill. The project lasted 20 years, and comprised 82,361 probability estimates about the future.
The result: The experts were, by and large, horrific forecasters. Their areas of specialty, years of experience, and (for some) access to classified information made no difference. They were bad at short-term forecasting and bad at long-term forecasting. They were bad at forecasting in every domain. When experts declared that future events were impossible or nearly impossible, 15 percent of them occurred nonetheless. When they declared events to be a sure thing, more than one-quarter of them failed to transpire.
未来予測をしようとすることは良い投資とは言えないように見えます。大きな方向性だけ決めて、あとはその時々で面白そうだと思ったことに取り組むのが良いのかなと。
また、拝金駆動は一見わかりやすい動機ですが、燃料（欲望）をくべ続けること自体にエネルギーが要るなという印象があります。個人の欲望には上限があり、割となんでも揃ってしまう先進国に住んでいる人間がハングリー精神を持ち続けるのは難しい。
目の前で取り組んでいることそのものに対してモチベーションを持つことができる、好奇心に駆動されるのが、燃料供給が最も長続きする気がします。長期パフォーマンスが最も高い。
なので、細かいキャリアは考えていません。面白そうなことを一生懸命やります。
期待値
会社からの期待値は概ね「バックエンド・エッジ両者のインターフェースを知ることで、より見通し良く生産性の高いアーキテクチャを考案する」とかそんな感じです。サーバとエッジの両方の、特に開発者の気持ちがわかれば、みんなが幸せになるようなやり方を考えられるようになるはず…という思惑です。
「3D-CADもVerilogも電気電子物理もGitもOSもOOPも各種DBもコンテナオーケストレーションもセキュリティもwebAPIも少しずつわかります」みたいになれば、各分野のスペシャリストと協力しやすくなるかなぁと。器用貧乏になってしまうかもしれませんが。
個人と会社が両方得をする一つの例かなと感じています。誰かの参考になれば。
参考・引用
- [1] ダニエル カーネマン,村井 章子. ファスト＆スロー （上） (Japanese Edition) (Kindle Locations 5264-5265). 早川書房. Kindle Edition.
- [2] Why Is It So Hard to Predict the Future? - The Atlantic
未来予測の不可能性については、「カオス」「複雑系」とかの単語でひっかけると面白いです。
決定されているのに予測できない未来—世界観を覆した数学理論— | サイエンス＆テクノロジー | 研究・社会連携 | 京都産業大学
株式会社フォトシンスでは、一緒にプロダクトを成長させる様々なレイヤのエンジニアを募集しています。 hrmos.co
Akerun Proの購入はこちらから akerun.com
