読者です 読者をやめる 読者になる 読者になる

Android Akkaの話

はじめまして、BONX Androidエンジニアの麻植です。

さて、BONX Android版は6月にリニューアルをしまして、その前後でUIだけでなく内部の設計も変更しています。 まだまだ機種依存バグへの対策などは継続中で、一部端末をお使いの方にはご不便をおかけしていて申し訳ありませんが、βの頃から比べると通話品質などについて大きく改善しています。

具体的には内部設計をEvent Driven APIと、Thread / lockによる明示的な排他制御から、Akkaによるメッセージ駆動の設計に変更しました。

AndroidでAkka?

Androidエンジニアは、Akkaの名前を初めて聞かれる方も多いかもしれません。 Scalaエンジニアにはお馴染みのAkkaでも、Androidで使うとなると、どうやっていいのかわからず二の足を踏まれるかもしれません。

しかし、ユースケースによってはAndroidでもAkkaが有力な選択肢になりえますし、おそらく使用方法もご想像されてるより簡単です。

Akkaとメッセージ駆動

Lightbend社CTOのJonas Bonér氏が開発した、メッセージ駆動による並行・分散処理のtoolkitです。 Actorと呼ばれる並行処理の基礎単位と、Actor間のメッセージによる相互作用を基に設計します。

まずは雰囲気を掴んでいただくために、VoIPのクライアントアプリにおける、最も単純な再生側のActorの構成を見てみましょう。

TCP接続を管理するTCPActor、プロトコルに基づき解釈をするReceiveActor、音声バイト列のデコード処理を担うDecodeActor、音声PCMデータの再生を担うPlayActorから構成されます。 各々のアクターは、!関数を利用して、他のActorへメッセージを送ることができます。

※ ここでは解説しやすいようにTCPを使っていますが、一般的なVoIPではUDPが採用されることが多いでしょう。なお、akka.ioはUDPに対応しています。

class TCPActor(inetAddress: InetSocketAddress, receiveActor: ActorRef) extends Actor {
  override def preStart = {
    IO(Tcp) ! Connect(inetAddress, timeout = Option(5000 millis))
  }

  def receive: Receive = {
    case c: Connected =>
      sender ! Register(self)
      context become receiveAfterConnection(sender)
    /* 実際にはその他のエラーハンドリングなどが色々 */
  }

  def receiveAfterConnection(conn: ActorRef): Receive = {
    case Received(bytes) => receiveActor ! bytes
    case bs: ByteString => conn ! Write(bs)
    /* 実際にはその他のエラーハンドリングなどが色々 */
  }
}
class ReceiveActor() extends Actor {
  lazy val decodeTag = "decode"

  override def preStart = {
    context.actorOf(Props(classOf[DecodeActor]), decodeTag)
  }

  def receive = {
    case bytes: ByteString =>
      for {
        decodeActor <- context.child(decodeTag)
        byteArray <- checkProtocol(bytes)
      } decodeActor ! AudioPacket(byteArray)
  }

  //受信バイト列のparse
  private def checkProtocol(bytes: ByteString): Seq[Array[Byte]] = ???
}
class DecodeActor() extends Actor {
  private var decoder: Option[Decoder] = None
  lazy val playTag = "play"

  override def preStart = {
    decoder = Option(new Decoder())
    context.actorOf(Props(classOf[PlayActor], YOUR_SAMPLE_RATE, YOUR_BUFFER_SIZE), playTag)
  }

  def receive = {
    case AudioPacket(bytes) =>
      for {
        playActor <- context.child(playTag)
        dec <- decoder
      } playActor ! PCM(dec.decode(bytes))
  }

  override def postStop = {
    decoder.foreach(_.release())
    decoder = None
  }
}
class PlayActor(samplingRate: Int, trackBufSize: Int) extends Actor {
  private var track: Option[AudioTrack] = None

  override def preStart = {
    track = Option(new AudioTrack(android.media.AudioManager.STREAM_VOICE_CALL, samplingRate, AudioFormat.CHANNEL_OUT_MONO, AudioFormat.ENCODING_PCM_16BIT, trackBufSize, AudioTrack.MODE_STREAM, AudioManager.AUDIO_SESSION_ID_GENERATE))
    track.foreach(_.play)
  }

  def receive = {
    case PCM(pcms) => track.foreach(_.write(pcms, 0, pcms.length))
  }

  override def postStop = {
    track.foreach {
      tr =>
        tr.flush()
        tr.stop()
        tr.release()
    }
    track = None
  }
}
//何かしらのcodecのDecoder
class Decoder {
  def decode(bytes: Array[Byte]): Array[Short] = ???

  def release(): Unit = ???
}

case class AudioPacket(byte: Array[Byte])

case class PCM(data: Array[Short])
val system = ActorSystem("bonx")
val receiveActor = system.actorOf(Props(classOf[ReceiveActor]))
val tcpActor = system.actorOf(Props(classOf[TCPActor], yourInetAddress, receiveActor))

TCPActorでは、akka.ioパッケージを利用してサーバーとTCP接続し、byte列の送受信を管理します。実際のプロダクトではreceive関数ではエラー処理など他にも様々なことが必要なりますが、簡単のために端折っています。

ReceiveActorは送られてきたパケットを解釈し、後続のDecode、そして再生へ回します。 また、このActorは後述のDecodeActorとPlayActorの親Actorにしており、それぞれの子Actor内でエラーが起きた場合のハンドリングも行います。

DecodeActorでは、Actor内部でDecoderオブジェクトを初期化し、かつ隠蔽しています。 ここで重要なのが、Actorの実行モデルとして、基本的に1Actorインスタンスは1スレッドで逐次処理をするということです。 このため、DecoderがThreadセーフでなくても、明示的な排他制御が不要となります。

PlayActorでも、Actor内部でAudioTrackオブジェクトを初期化し、かつ隠蔽しています。 AudioTrackもDecoder同様にThreadセーフである必要がありません。

各々のActorが担う処理を終えた後、次のアクターへメッセージを送信します。このメッセージの後続処理に成功するかどうかは、基本的には送り手のActorは気にする必要がありません(Fire and Forget)。代わりにエラーが発生した場合などには親ActorのsupervisorStrategyに応じて自動的にRestartをさせたり、必要な場合にはTimeoutを設定することができます。

Actor間の通信も直接Actorインスタンスの扱ったメソッド呼び出しではなく、Actorへの参照を表すActorRefに対しメッセージを送信し、受信側のActorもメールボックスから逐次取り出すため、結合が疎に保つことができます。

これらのメッセージ駆動特徴により、複雑な並行処理になりがちな音声ストリーム処理でも、Actorの実行モデルが別途toolkitにて適切に管理されており、かつ不変なメッセージオブジェクトを利用しActorの内部構造を露出させない限りにおいて、明示的な排他制御から開放された見通しの良いコードを実現できます。

Why Akka?

Actorはメッセージに反応するReceive関数やライフサイクル管理のための関数のほか、重要なコンポーネントとしてmailboxを持ちます。

Akkaにおいては、Receive関数は当然ながら、mailboxもカスタマイズ可能です。 また、Actorの実行モデルであるdispatcherの設定を変更できます。

Androidでは端末スペックの向上により、オクタコアCPU、3GB RAMを積んだ端末も珍しくなくなりました。 しかしながら、まだまだサーバーに比べCPUリソースもメモリ量も少ない実行環境に配慮したmailboxと実行モデルの採用が必須です。

その点、Akkaは柔軟なカスタマイズが可能である点が優れています。

Androidで使う上での制限

Akkaのversion

Android SDKJava 6相当のJava bytecodeをdex(Dalvik Executable)に変換します。 そのため、Akkaは(Java 8向けである)最新版2.4系ではなく、2.3系を使う必要が有ります。

Proguard

AndroidScalaを扱う上では、Proguardは(少なくともプロダクションにおいては)必須です。 Akkaは application.conf や、Propsとリフレクションによるインスタンス化ししばしば行うため、Proguardと相性が悪いです。

実際のProguardの設定は、MacroidのAkka integrationの項目が詳しいでしょう。

それでは。

AWSのリージョン間でconsulを使用

インフラ

チケイ株式会社改め株式会社BONXのスケーター齊藤です。
(社名が株式会社BONXに変わりました)
バックサイドディザスターはメイク出来てませんが、猛暑とゲリラ豪雨の隙を突いてスケート業務に勤しんでおります。

f:id:bonx:20160818193729g:plain

前回から大分時間が空いてますが、今回はconsulをAWSのリージョン間で繋いだ話を書きます。
弊社でのconsulの使いどころに関しては前回の記事を参照して下さい。

背景

  • BONXのUSでのサービス展開に備えてVoIPサーバを遅延対策の一つとしてUSリージョンにも構築することにしました。
  • APIサーバからVoIPサーバの検出にconsulを使用しておりVoIPサーバとconsulサーバ間で通信が必要なため、そこだけVPC間の接続が必要となり通信方法を検討。
  • リージョン間のVPCピア接続がオフィシャルでは未だサポートされてなくVPN接続で対応をすることにしました。

USのリージョン選定

VPN接続をするルーターの選定

  • 最初オフィスのルーターを使おうかとか冗談で話していたのですが、AWSで動かしている実績があるソフトウェアルータのVyOSを採用することにしました。

VyOS

  • 詳細はこちらを参照して頂くとして、設定などはログインしてゴリゴリとコマンドで実施する感じです。
  • AWS マーケットプレイスのものを使用してインスタンス起動をしましたが、v1.1.0には不具合がありv1.1.6にupgradeして使っております。
  • バージョンアップは以下の方法で実施しました。
vyos@VyOS-AMI:~$ add system image http://packages.vyos.net/iso/release/1.1.6/vyos-1.1.6-amd64.iso
vyos@VyOS-AMI:~$ reboot

その他EIPの付与やsource dest checkの無効化などを実施して準備は完了です。

構成

  • USリージョン以外にもリージョンを増やす可能性があり、その都度リージョンにVyOSを構築するのは運用が煩雑になるためTokyoリージョンをシステム構成的にはカスタマーゲートウェイとしてVyOSを構築することにしました(TokyoをRootにしたツリー型)。
  • 障害等でVPNが切断された場合はTokyoリージョンのVoIPサーバのみ検出するようにしているのでVPN切断してもサービス停止とは成らない仕組みとなっております。

構築時に気を付けたポイントなど

  • ap-northeast-1とus-west-2のVPCを繋ぐのに同一のCIDRは指定出来ないので、ap-northeast-1は172.16.0.0/16としus-west-2は172.17.0.0/16VPCを構築。
  • us-west-2のセキュリティグループで8301(TCP/UDP)を172.16.0.0/16から許可する
    consulが通信で使用するポートでこれだけ開けておけば要件を満たせる(満たせた)
  • VyOSにVPNの設定を反映するのに、vyos_config.pyスクリプトを使用することで手作業の負荷を軽減させました。

雑感

  • たまにVPNが落ちるので(BGPで冗長化しているのに同時に落ちたりする)クリティカルなサービスやトラフィックがあるサービスには使いたくないが、consulでのサーバ検出程度であれば十分に役立っております。
  • VyOSを冗長化する方法を検討しておりますが、今現在は手動対応可能な範囲なので当面はアラートが飛ぶ仕組みだけ作り運用をする様にしております。
    VyOSのtask-schedulerにダウン検知したらrestart vpnコマンドを走らせる簡単なスクリプトを仕込んでみたが、上手く起動しないことがあり時間を見て対応したいと考えております。
  • AWSが早くリージョン間のVPCピア接続を対応してくれればなーー

最後に

現在、世界的クラウドファンディングサイト「Indiegogo」で実施中のBONXのキャンペーンに、たくさんのご支援をいただき、ありがとうございます。
キャンペーンは引き続き進行中です!!
https://www.indiegogo.com/projects/bonx-outdoor-sports-group-talk-technology/x/14601326#/

DIYで風洞試験装置を作っている話

どうも皆様、CTOの楢崎です。前回の更新から少し時間が立ってしまいましたが、いかがお過ごしでしょうか。僕はついに念願のドロップイン→インターフェイキーの一連の動きが出来るようになりました。次回更新までにテールロックを練習しようと思います。

 

さてさて、今回はハードウェアスタートアップならではの取り組みについてご紹介できればと思います。

 

BONXのハードウェア的なポイントのうち、大事な要素として「複合的な風切音対策」というものがあります。スキーやロードバイクなど、アクションスポーツは時速数十キロというスピードが出ることがザラです。これに対しBONXは、特殊なハードウェア構造、風切音を防ぐパーツの埋め込みなど、様々な工夫で風切音対策に取り組んでいます。

ただ、開発している中でぶつかった壁が「実際風速何mの時にどの程度の性能が出ているか」を定量的に検証することでした。これまでは気合でロードバイクで走って会話が成立するか検証するといったユースケースを軸にした検証がほとんどでしたが、一定のスピードで長時間走れるわけもなく、また向かい風の状況等も刻々と変わるため、定量的な実験には向きませんでした。なにより体力しんどいし。

 

というわけで、今回我々はお手製の風洞実験設備を開発し、体力のないエンジニアでも気軽に風洞試験をできる環境を構築しました!

 

f:id:bonx:20160619201653j:plain

どうですかこのDIY感。スタートアップならではですね。

かなりわかりづらいですが、簡単に仕組みを説明すると、緑色のブロワーから高速の風が灰色のパイプを通って透明なアクリルの中に送られます。で、パイプ経由で送られた風を受ける位置にBONXをセットしておきます。これによって、ブロワーから送られた風が細い管を通って加速し、かなりの風速でBONXを直撃するわけです。ちなみにブロワーとは、公園の落ち葉を風の力でふっとばすあいつです。

 

f:id:bonx:20160619201922j:plain

で透明なアクリルの内部には、BONXだけでなく風速計も一緒に仕込まれています。なので、実験装置内部にどの程度の風が吹いているかをリアルタイムに測定することが可能。風速の測定と同時に、内部に仕込んだBONXのマイクから直接音を拾って録音用のスマホに出力。さらにアクリルの実験ケースをモフモフした吸音材でぐるっと囲っておき、余計な音が実験室に入らないようにしておきます。

これらによって、ブロワーのモーター駆動音など余計なノイズを吸音材で排除しつつ、一定速の風を風速を測定しながら流し、その時にどんな音をBONXが拾うかをすべて録音することが可能に!見た目のチープさはともかく、かなりスバラシイ実験設備と言えるでしょう!

 


・・・とまあテンションあげつつ組み上げたわけですが、初めてテストしたところブロワーの風が強すぎて、最弱でも風速125km/hというモンスターマシンが出来上がってしまいました。BONXはモータースポーツ向けギアではないので、あまりにオーバースペック。というわけでもう少し風速を抑えられるように修正。

 

f:id:bonx:20160619203606j:plain

わかりづらくて恐縮ですが、3Dプリンターで作ったブロワーとパイプの接合部に穴を開け、風の一部が外に逃げるようにしました。またパイプ内部に綿を詰めて、風の通りを悪くしました。ここまでやって、ようやく風速40-50km/hを安定して出せるようになりました。

 

 

以上、とてもITスタートアップと思えない日曜大工感満載の写真ばかりでしたが、なんとかいちいち自転車を走らせなくても風洞試験ができる環境が整えられました。この実験器具を使った性能アップはまさに現在取り組んでいますが、なんとかいい結果に繋げられればなーと思っています。

 

 

・・・とはいえユースケースを考えると、ロードバイク走行中に風速測定が出来ることも大事なので、自分のロードバイクも実験ができるよう、簡単に改造しました。

 

f:id:bonx:20160619204342j:plain

 

ロードバイクのハンドルにセルフィー棒を括りつけ、その先端に風速計がついています。見た目のダサさはともかく、これさえあればいつでも向かい風込みの風速がわかるので、外を走りながらの実験にも最適。決して走行中の自分を自撮りしたいわけではありません。

 

以上、まだまだ試行錯誤中ではありますが、実験装置をDIYで作る話をお送りしました。日本全国で風洞試験がやりたかったけど出来なかった皆様の一助になれば幸いです。

 

 

さてさて、そんな実験装置の開発も含めて、BONXのハードウェア開発に関わっていただけるエンジニアの方を引き続き募集しています。興味ある方は気軽にポチッと!

 

メカニカルエンジニア | チケイ 株式会社 | IT/Web業界の求人・採用情報に強い転職サイトGreen(グリーン) | 2016/04/18 10:58:24更新 | id:39860

 

BONXはconsulを使ってます

インフラ

はじめまして、チケイのスケーター齊藤と申します。
昼食前に駒沢公園のスケートパークに滑りにくのが日課となっております。
今月は小さいクウォーターパイプでバックサイドディザスターを決めるのを目標に日々汗を流しております。

f:id:bonx:20160518103537g:plain

  

今日は雨のためスケートに繰り出せなかったのでBONXのインフラで使用しているconsulに関しての記事を書いてみることにしました。

consulとは、Service Discovery and Configuration made easy. (サービスの検出と設定を容易に行える仕組み) 

www.consul.io

 

以下、このconsulをBONXでどう活用しているかを書きたいと思います。

 

BONXのインフラ概要

AWSにどっぷり浸かっています。
AWSで稼働させているのは、主にサービスで使用しているAPIサーバ,VoIPサーバの2つとwebサイトのbonx.coです。
APIサーバはRoRVoIPサーバはGO言語でスクラッチビルド。
deploy環境を統一することで運用負荷を減らすためにAPIサーバVoIPサーバはElastic Beanstalkに乗せており、webサイトはS3にコンテンツを置いて素のEC2インスタンスから参照させています。
全体的な構成はRDS,Elasticacheなどを使用した一般的な感じとなっております。

APIサーバはユーザ情報やルーム情報といった会話に必要な機能を担い、VoIPサーバは通話部分の機能を担っております。

BONXでのconsulの使いどころ

  •  APIサーバからVoIPサーバを検出(抽出)する
    VoIPサーバのscoreを保持しておりルーム数が一番少ないVoIPサーバを検出し新規ルーム作成時に割当を行う
    マルチリージョンでVoIPサーバを稼働させるときは、これにGeoIPの判定が加わります
  •  VoIPサーバのダウンを検知してフェイルオーバーする
    バッチサーバからconsul watchを起動してVoIPサーバのダウンを検知したらフェイルオーバータスクが起動

consulの構成

  • serverは2台で1台は専用サーバでもう一台はバッチサーバに相乗りをさせている
    推奨サーバ数は3台ですが今現在は2台で稼働
  • APIサーバ、VoIPサーバがclientとなる
  • VoIPサーバの検出ができるように、VoIPサーバはサービス登録を行っている
    AWSのマルチリージョンにも対応させるためにtagsにリージョンを入れて割当時にフィルタリング出来るようにしている
    checksにはVoIPサーバの死活監視コンテンツを入れる

    gist5eb39c2d7f0a2813b2a286ae2838d383

 

所感

BONXの肝となる通話を担うVoIPサーバの検出と死活監視をconsulを使うことで比較的に簡単に行なえ、ダウン検知も素早く弊社のサービスを運用するには今現在最適なソリューションとなっております。

まだまだ使い倒してはおりませんが、今後はもう少し踏み込んでサービスに役立てていけると思っております。

 

最後に

チケイは開発チームにジョインしてくれる方を継続的に募集しております!興味がある方はぜひ一度話を聞くだけでもー!ソフトウェアエンジニアだけでなく、ハード側も含めて多数の職種を募集中です!

チケイ 株式会社の採用/求人 | 転職サイトGreen(グリーン)

jobs.forkwell.com

jobs.forkwell.com

テックブログ開始&初めての勉強会開催

はじめまして、ハードウェアスタートアップ、チケイのCTO楢崎と申します。

BONXというウェアラブルトランシーバーの開発をしています。

 
これまでCEO宮坂中心に、会社全体に関わる(遊んでるとしか思われなさそうな)情報発信をこちらのブログでやって来ましたが、BONXを支える技術的な内容だったりエンジニアチームについても発信したいと思い、テックブログを始めることにしました。

今後、技術ネタを中心にメンバーが入れ替わり記事を書いていきますので、ぜひチェックしていってください!

 

さてさて、それでは第一回目ということで、先日実施した「Akerun × BONX Tech Talk supported by さくらインターネットについて書いてみたいと思います。

sakura-kanto.doorkeeper.jp

 

いまやバズワードと化しているIoT、エンジニア向けの勉強会も多数おこなわれていますが、エンドプロダクトを実際に発売しているスタートアップ企業が内部の技術生ネタを公開する場はそこまでなく、前々から一度自分たち主催で勉強会をやってみたいと思っていました。
また、日々の開発に追われ、なかなかチーム内でもお互いの開発事項や技術内容を整理・消化できていなかったため、一度立ち止まって整理し直す機会が必要でした。

そんなわけで、日頃から仲良くしてもらっているAkerunで有名なフォトシンスさんにお声がけし、さくらインターネットさんにお手伝いいただいてなんとか実現に漕ぎ着けました。(ご両社とも、ご参画ありがとうございました!)

f:id:bonx:20160513134824j:plain

 

チケイからは、ずっとBONXの開発に関わってもらっているフリーランスエンジニア3名に、BONXのユーザー体験を支える3つの重要技術に関してお話していただきました。

 

1. 音声ガイダンスを導入した話 

speakerdeck.com

 

iOSエンジニアの森本さんからは、音声ガイダンスについて話してもらいました。

f:id:bonx:20160513135251j:plain

ウェアラブルやIoTは従来のPC/スマートフォンアプリケーションと異なり、音声が非常に重要なインターフェースとなります。特にBONXはスマホアプリなのに実際に使用しているシーンのほとんどでスマホの画面を見ないというかなり特殊な仕様なので、音声による情報提示・ナビゲーションが極めて重要です。

詳細については発表スライドを見てもらえればと思うので、少しブログだけの裏話を。音声ガイダンス機能の中で、「弱電波環境にいるユーザーを検知して各ユーザーに音声で通知する」という機能があります。この機能を実装した際、森本さんと二人で弱電波環境の再現について非常に困っていました。

iOSでは開発ツールとして電波を制限する機能もついていますが、雪山likeな「弱電波環境だったり圏外だったり電波が不安定な環境」には対応できません。

友人づてに色々調べたところ東京メトロ南北線某駅の北口付近は何故だか全くの圏外となっていると知り、喜々として二人でデバックに向かいました。2時間にわたり、延々と駅のエスカレーターを独り言を話しながら行ったり来たりするメガネと金髪。はたから見ると、かなりの不審者っぷりだったことでしょう。

2. Bluetoothを120%使い倒す方法

www.slideshare.net

 

Androidエンジニアの麻植さんからは、BONXアプリとBONXイヤフォンをつなぐBluetooth関連の技術について話してもらいました。

f:id:bonx:20160513134828j:plain

当たり前ですが、ウェアラブル端末の開発ではハードとソフトの連携がユーザー体験を支えるキモとなります。BONXは音声データをやり取りする必要があるため、Classic BluetoothBLE(Bluetooth Low Energy)の2つをハイブリッドで扱う仕様を採用しています。
加えて、登壇資料にあるとおり、AndroidはOSバージョン/BTチップセットなどBLEに関する仕様がスマホごとにバラバラになっているという鬼のような状況です。BONXではイヤフォン側のBLE機能をSPPで制御するというかなり特殊な仕様を組み合わせることで、Android端末ごとの違いを吸収しています。

こちらも裏話を軽く一つ。上記仕様をファームウェアの実装を委託している中国企業のエンジニアに何度伝えても、全く理解してもらえず、というよりはちゃんと理解しているかどうかすら理解できず、プロトタイプの検証に大変苦労しました。仕様通りの動きをしていないように見えるのは、ファームウェア側のバグなのか、アプリ側のバグなのか。
最終的に、業を煮やした麻植さんが夜7時に「俺中国に飛びます!」宣言。その日の夜11時には僕と二人、中国に向かう機上の人となっていたのでした。
かくして彼は、弊社内でGTO a.k.a God Taisuke Oeと呼ばれるようになりました。

 

3. 発話区間検出(VAD)の話

speakerdeck.com

 

サーバーサイドエンジニア兼音声スーパーバイザーの粟飯原さんからは、発話区間検出の話をしてもらいました。

f:id:bonx:20160513134836j:plain

 

BONXのUXを支えるコア機能の一つとして、「激しい運動中でもハンズフリーで音声を届ける」というモノがあります。

  • 音声データを流しっぱなしにすると、電池・通信量をむちゃくちゃ食う上にノイズばかりで会話が成立しない
  • 従来のトランシーバーのようにボタンを押してON/OFFを毎回やるのは、スポーツ中極めて煩わしい

というような課題を解決してくれるのが、このVADです。

 

粟飯原さんは元々バックエンドのVoIPサーバー構築をするGo-langのエンジニアとしてチケイに参画してもらいましたが、音声処理についてもスバラシイ知見をお持ちということで、VADの実装についても担当してもらっています。

発表資料を見ればわかりますが、わかりやすさも含めてまるで学会発表。勉強会で音声信号の波形が出てくるのを初めてみました笑。ちなみに、横で聞いていたCEO宮坂は発表を聞きながら「へぇ〜、こうなってたんだぁ〜」と(社外のひとのような)非常に素直なリアクション。
このように勉強会をやると、社員同士についても技術について理解が深まるという非常に良い点がありました。

 

4. フォトシンスさんの発表

フォトシンスさんからは、Webエンジニアの齊藤さん、アプリエンジニアの木下さんがご登壇されました。詳細については、さくらインターネットさんがまとめていただいたイベントレポートを御覧ください!

IoTスタートアップを支えるエンジニアたちの声を聞け!「Akerun & BONX Tech Talk」レポート - さくらのナレッジ

 

個人的に印象に残ったのは、齊藤さんの「プロダクトが初めて動いた時、最初のプログラムを作って"Hello World"が出た時以来の感動がある。理屈抜きに楽しい!」の一言。本当にそのとおりだと思いますし、どこの会社もそういうモチベーションで働いてるんだなーと深く共感できました。

 

5. CTOセッション

テクニカルセッションが終わった後、お酒を交えてCTOセッションと言う名の与太話が始まりました。ちなみに、乾杯は両社CEOの宮坂&河瀬さんコンビです。

f:id:bonx:20160513134840j:plain

f:id:bonx:20160513134815j:plain

 

色々とお話させていただきましたが、お伝えしたかったポイントは二点あって、ひとつは「フィジカルに触れるモノがあること自体の感動」です。ハードウェアスタートアップ以外のWeb系企業では、手触り・つけ心地・色や光り方(はては匂い?)みたいなところに踏み込んでユーザー体験を設計することはできません。ただ、プロダクト自体への愛着とかブランドイメージは、そういうプリミティブなところからこそ生まれるんだと思うんですよね。こういう体験ができて、かつ横串で全工程の開発に関われるというのは、ハードウェアスタートアップでしか味わえない経験かと思います。

 

二点目は、「様々な専門分野を複合したチーム開発ならではの楽しさ」です。今回の前半セッションでお伝え出来たかと思いますが、BONXの開発は極めて技術範囲が広いです。一人のエンジニアがすべての範囲をカバーすることなど、到底出来ません。
ただし、各メンバーがスペシャリストとして付加価値を出しつつ、足りないナレッジはお互いに補い合うというチーム開発がうまくできていることで、なんとかプロダクト・アウトに繋げられています。エンジニア視点で言えば、日々自分の知らない技術分野についてその道のプロから学び、かつ自分も何かを教えることが出来る環境という点も、ハードウェアスタートアップならではの楽しさかと思います。実際、うちに来ているメンバーは社員・フリーランスを問わず非常に楽しそうに喧々諤々の議論をしていますし。

こちらのセッションについても、本間さん・山口さんのお話ふくめ、さくらさんの記事に詳しく書いていただいているので、ぜひご一読を。

 

なお、お酒が入ったセッションだったからでしょうか、BONXメンバーがみんな僕らのセッションそっちのけでビールに夢中だったことは一生忘れません。記録写真もほぼ残ってないし、多分僕の話は記憶の彼方でしょう・・・

 

そんなこんなで、懇親会も含めて非常に学びの大きい・楽しいイベントとなりました!
皆様大変お疲れ様でしたー

 

f:id:bonx:20160513134819j:plain

 

 

さてさて、そんなチケイは開発チームにジョインしてくれる方を継続的に募集しております!興味がある方はぜひ一度話を聞くだけでもー!ソフトウェアエンジニアだけでなく、ハード側も含めて多数の職種を募集中です!

 

チケイ 株式会社の採用/求人 | 転職サイトGreen(グリーン)

jobs.forkwell.com

jobs.forkwell.com