僕はRxJS(+noble)を使ってスマートロックを開けたかったということに気づいた
ソースを載っけることはできないんですが、手元のラズパイ的なデバイスでRxJSとnobleというnodeからBLEを制御するためのライブラリをつかってAkerunの開閉に成功しました。
かねてよりリアクティブプログラミング自体には興味があって、ずっとこれを使ってAkerun開けてみたいなぁって思っていたんですが、ついに成功しました。 (というか別に昨日ちょっとやっただけですが)
なんの説明にもならない図なんですが、以下の通りAkerunは中間のゲートウェイデバイスにより間接的にインターネットにつながるデバイスです。 ゲートウェイデバイスとはライズパイ的なデバイスのことでBluetoothやらWi-Fi/3Gやら積んであって、ネットにつながっていないセンサーデバイスから情報を吸い出す役目をすることが多いです。最近ではラズパイ3も出て標準でBluetoothとWi-Fiが搭載されたことは記憶にあたらしいですね。
普通はスマフォアプリを使って開閉を行うんですが、Akerunにも専用のゲートウェイデバイスを用意しているので、今回はそれでやってみました。 単にLinuxなのでAkerunやスマフォ端末とは違い普通にLLが動きます。
今回はBLE搭載ゲートウェイ界隈では最も使われそうなnode製のBLE制御ライブラリであるnobleを使ってみました。
AkerunのIoTをかっこよく言うと
Akerunはよくあるセンサー情報吸い上げ型のIoTデバイスと違い、
「人間が行った操作によってインターネットを通して現実世界に物理的な現象を引き起こすデバイス」
です。
※BLEを使って間接的にネット通信し最終的に錠につながったモーターを回しているだけです
なぜRx?
APIを叩くだけなら単にPromise使っていても良い気がします。asyncでもいいと思います。
ただAkerunの場合は開閉までに数えてみたら10(!!)を越えるくらいの非同期処理があります。
主には以下です。
- MQTT系(Sub/Pub)
- BLE系(電源ON/スキャン/接続/GATTの探索/データの書き込み/データの受け取り)
- WebAPI系(ごにょごにょ)
これがそれぞれの括弧の項目含めて何度かやる必要があるのと、場合によってはリトライも必要です。
上記を実現するときにコールバック地獄になるのはゴメンです。
やってみてわかりましたが、すべての処理をストリームとして流した結果、ほぼ一本の綺麗な処理で記述することができました。 あっちにいったりこっちにきたりを全くせずに記述できるのが良かったです。
特に各ノード間で連続で複数回信号を送る必要があるのですが、それを束ねる操作がとてもうまく書けました。
またほとんど知らない状態でやってみましたので、いくつかベストプラクティスをスルーしてると思いますが、 EventEmitterで書かれたnobleのラップと独自のcreateの作成やflatMapを何個も重ねた非同期処理の一本化、filterやmapやreduceなどの基本的なリスト処理の操作など交えつつ最後まで書けたので一旦いいのかなと思っています。
まとめ
今回の僕の目的は、RxJSを使ってリアクティブプログラミング自体の習得と、今後がっつりスマフォアプリがRx化されてもいつでも即戦力としてヘルプできるようになることでしたが、下手にbacon.jsなど亜種のようなものを使わずに書いてみて正解でした。
ドキュメントを見に行くと他の言語の記述の方法もあるので、一つがわかっていると頭の中の概念を転用できて便利です。
実はAkerunスマホアプリはすでにRx化されています
Androidアプリは開発当初からRxJava/RxAndroidを使って開発されていました。 iOSも現在順次RxSwiftを使って作りなおされている段階です。
がんがんRxでUIやAPIとの通信、BLEの制御やってみたい人はご応募待ってます!
RedmineがIoT企業に異常にマッチしてしまった話
タスク管理してますか?(あいさつ)
みなさんは日頃どんなタスク・プロジェクト管理ツールを使っているでしょうか?
Backlog?Trello?Wunderlist?それともgithubのIssueで十分?カンバンほしいからZenhub?Waffle?変化球でProducteev?
僕も前職含めて上記含むすべてのツールを試してみました。
各タスク管理ツール所感
Trelloのガントない問題
ポンポンタスク登録できて便利。人のアサインも簡単だし。あ、でもこのタスクの粒度細かすぎない?依頼するときもされるときも細かすぎない?一つのリスト長すぎない?
あと標準でガントがないよね?全体見渡す側からすると不安(らしく)になっちゃうからやっぱりガントほしい。アサインできるの便利だけど、あぁでもこれボード6個くらいできちゃった。横断めんどい。どのボードもカードで溢れている。ガント追加してくれるサードパーティのプラグインがなんかイケてない。
Wunderlist
は、デザインかっこいい。でもなんか同期おかしい。でもデザインは一番かっこいい。
Backlogは好きです
前職の経験だとBacklogが良い線行ってる気がする。ガントも標準で引けるし、バーンダウンチャートも表示されて、タスクの消化頑張ると応援コメントくれるし、あぁでもなんか高くない?細かいところで融通利かないし。まぁでもデフォルトのユーザーアイコンが充実しているのよかったな。でもそれくらいかな?
githubはソフトウェアエンジニアためのもの過ぎる
Zenhub見つけたときは感動しましたよね。なにこれ普通にgithub表示しているのに、色々拡張が増えてる。カンバン最高。すごい管理している感じ。あ、でもgithubのリポジトリにCSの人入れたい。でもこのためにgithubのアカウントつくってもらうの微妙だなぁ。。。read権限だとソースコードみれちゃうよね?じゃあ横断的なリポジトリつくってソース無しIssues運用?あ、でもちょっと待ってこれ同じプロジェクトのリポジトリ二つ作るってこと?え?全体で一つでいい?それなんて神リポジトリ?
あとハードのチームはgithub使いませんから。どうやって統合的なタスクを設定する?まぁいいか、とりあえずソフトチームはIssue使って管理して、全体のタスクリストと二重管理するかぁ。
Excel方眼紙改めSpreadsheet方眼紙最強説
で、結局SpreadSheet方眼紙でつくったガントチャートが幅を利かせてきて、すぐ編集できるし柔軟性も高いしこれでいいじゃん。同時編集もできるしね。ってなるけど、あれ自分のタスクってどれくらいだっけ?誰がどれだけ大変になってる?一瞬だけフィルタ使っていい?あ、ごめん消したわけじゃないよ、今戻すね、みたいな。粒度も細かくすると定例伸びるし。あれ、このタスクこんなに簡単に伸びていいんだっけ?逆に編集し易す過ぎない?
課題の議論が流れるSlack
お疲れ様です。ちょっと相談していいですか?え、要件と一緒に書け?すいませんでした。
例の追加機能の件なのですが、これってどうなってます?あ、別の話題が投下された。それ別チャンネルじゃだめ?あ、でも確かにこのチャンネルの話題ではある。githubのIssueで議論しません?あ、アカウントないですよね。そうですよね。。。
そういえばこの前Slackで言っていた件なのですが(・・・)え、なんのこと?って感じです?ちょっと待ってください、今投稿したメッセージ検索するんで(・・・)あれ、なかなか出てこない。すいません、依頼しなおします。今度からスターつけてください(あ、でも自分も使いこなせてないなぁ)。
IoT企業特有の問題
1. タスクが複数の開発レイヤーにまたがりまくる
例えば「Akerunで鍵を解錠する」ってタスクの場合には、
- メカ: 鍵(正確にはドア内側サムターン)に取り付けるアタッチメントおよびメカ・筐体開発
- エレキ: モーターの制御および、指示をBluetoothで受け取るための電子回路開発
- ファームウェア: 電子回路操作とBluetoothの通信インターフェースを制御するためのファームウェア開発
- スマフォアプリ: Bluetooth通信機器とインターネットを中継するスマフォアプリ開発
- サーバーサイド: スマフォアプリから来た電子回路・ファームウェアの内部情報(バイナリデータ)の復号・解析、ユーザー操作のためのWebAPI開発
- デザイン: 他統合的なハードウェアおよびスマフォ・ブラウザのUX・UIデザイン
- CS: 出荷後のCSお問い合わせ案件対応
メカの形状によってデザインとスマフォアプリのフローが影響を受ける。ハードの出荷数がサーバーのパフォーマンスに影響する。 スケジュールや予算の関係でハード側で問題を収束できなかった場合に、ソフトウェアで解決する必要がある。他。
※全般的な部分だと追加でビジネス・ロジスティクス・工場での製造・・・
2. お問い合わせ対応も横断的
ファームウェアで起きた問題の原因がWebAPIにある可能性がある。電子回路の値の補正をWebAPIでやらないといけない。 などレイヤーまたがるのは当然として、レイヤーが一つ飛びで問題が起こっている可能性がある。 CSからの報告も複数レイヤーにまたがっていることが多い。担当が誰にアサインすればいいか迷う。大抵はユーザーとのインターフェースをもつ上のレイヤーのチームに集中するが、調べるうちに下のレイヤーに調査が移行していくことが多い。
3. ハードとソフトで開発サイクルが違い過ぎる
ハードはほぼ完全なウォーターフォール。ソフトはWeb側に行くほどほぼ完全なアジャイル。 ハードだとつくったらもうほぼ変更ができないので、一度出荷したあとは後戻りできない。 試作中は何度かサイクルを回すけど多くて3回できればいいくらい。一度の試作で1ヶ月から数ヶ月はかかる。 特にファームウェアは基板やパーツが変わるとドライバーや制御など書き直しになる。 Webに近いソフトは常に小出しで開発・改善を行っていくが、ハードが小出しじゃない場合には、できるまで待つ必要があるなどアジャイルっぽく動けないことがある。
そこでRedmineですよ!!
Redmineの良い点は色々ありますが、うちみたいなIoT企業だとRedmineのメリットは甚だ強力です。 以下にRedmineのメリットをまとめます。
1. 気軽に横断的なプロジェクトがつくれる、そこに小さいプロジェクトをネストできる
プロジェクトの作成が課金もなくゼロコストなので、心理的な障壁なくプロジェクトをつくれます。 また、子プロジェクトをつくれるので、一つのプロジェクトにごちゃごちゃにタスクが積まれることも、細分化されたプロジェクトを巡回する必要もないです。 見渡したいときは親プロジェクトを見て、単一レイヤーで独立しているタスクは子プロジェクトに追加すればいいのです。
また子プロジェクトなら親プロジェクトのルールやユーザーを継承できるので、作成のたびにわざわざ管理画面でポチポチする必要もありません。
ユーザーの追加も無限にやっても課金されないし、個人のメアドやSNSアカウントに紐付いてないクリーンなものをつくれるので管理しやすいし、情報セキュリティ的にも安心です。管理者側でアカウントをつくって、アクセス情報を渡してすぐに運用開始できます。
これで横断的なプロジェクトにそれに属する非エンジニアの人含めて気軽に追加・運用開始できます。
Slackでしていた議論も即Redmine化されるような風土ができつつあるので、特にファームウェアからWebAPI書いているチームまでは連携がかなり強いので重宝しているようです。
2. ガントチャートが標準でついている
複数人・複数レイヤーで開発しているとやっぱりガントが欲しくなります。 Redmineには標準でついてきます。しかも進捗と連動しているので、どこまで終わっているのか?順調なのかも見やすいです。
また簡単にマウスで期限を伸ばすなどもできないし、変更したら履歴も残りますので〆切を守るという緊張感も上がると思います(Spreadsheetよりは)。
3. カンバンのプラグインも充実している
昔は知りませんが今はTrelloみたいないい感じのUIのカンバンツールがRedmineのPluginとして提供されています。 Trello以上かも。カードのドラッグアンドドロップもできるのと、人のアサインもドラッグアンドドロップなのは他のツールにもないGood UIだと思います。 しかも全プロジェクトを横断したカンバンの表示にも対応してます。Trelloだとボードに階層の概念がないので、横断的に自分のタスクを知るのは大変だと思いますが、これなら各プロジェクトを舐める必要がないです。
正直かなり便利です。
これならZenhubやWaffleが好きっていうWebエンジニアも乗り換えるメリットを感じてくれるかもしれません。
4. 当然ソースをいじって自分たちなりのカスタマイズができる
最初導入したときは「注記」ってなぞの単語が気に食わなかったのですが、そういえば自分でいじって直せるなということで、ロケールのyamlいじって全部「コメント」に変更しちゃいました。
またチケット画面で「編集」をクリックすると、なぜか注記に飛ぶ仕様も気持ち悪かったので、チケットの説明の方にフォーカスが当たるようにしました。 また注記を編集するときは専用のボタンを追加しました。
これだけで結構便利ですがプラグインも充実していて、githubのIssueみたいに@でメンションできるようにしたり、Emoticonを使えるようにしたりと日々色々改造しながら使っています。
まとめ
導入するときは「えぇ、Redmine?どうせ使いづらいんでしょ?」みたいな感じでしたが、導入してから非エンジニアからも「これ、いいですね」と言われるようになり、複数レイヤーまたがるIssueも心理障壁少なく簡単に登録できるようになったので、大変満足しています。
ただここで大事なことを言っておくと、やはり導入にはRedmineエバンジェリストみたいな人が必要がだと思います。 正直いなかったらやってなかったですね。今は調整しつつめざせSpreadSheet撲滅という感じです。
お約束
フォトシンスではメカ・エレキ・ファームウェア・スマフォアプリ・サーバーサイドすべてを内製しています。 Webだけではつまらないと思い始めているエンジニアの人は是非弊社に見学に来ませんか? 応募お待ちしております。
非プログラマ社員向けに「Google Apps ScriptでつくるWebアプリケーション勉強会」を始めた話
どもども
インフルで絶賛謹慎中のkazuphです。
少し頭痛はしますが、熱も下がってただ寝てるのも暇なのでブログでも書こうと思います。
今日は先々週末くらいにやった非エンジニア向けのGAS勉強会の話です。
GASとは
Google Apps Scriptの略です。ExcelでVBAを知っている人へは「それのGoogle SpreadSheet版」と言えば通じるかなと思います。
要は一定以上複雑なことをやりたかったり、アプリケーションと呼べるレベルのことをやろうと思った時に、セルの関数の組合わせだけではやれないことをするときに活躍するプログラミング+その開発環境になります。
GoogleはそれをJavascriptにて提供しています。これをGoogle Apps Scriptと呼んでいます。
GASで何ができるか?
本来であればシートをプログラムから参照し、プログラム側で集計などし、結果をシートに反映するなどで閉じていてもいいはずなのですが、何を思ったのかGoogleはGASにWebアプリケーションを開発する力も与えました。
HTMLを出力することも、JSONでやりとりするAPIを作成することも可能です。唯一の欠点は、本来のアプリケーションでデータベースに相当する部分がSpreadSheetになっているためデータ数の上限が低いこと、また速度が遅いことです。遅いことについてはキャッシュが使えるため、工夫次第では一部高速化できますが、その分複雑になって行きますし、そこまでするならWebアプリをつくってしまう方が無駄なデメリットと戦わなくていいので楽でしょう。
その他にはメールの一斉送信や定期バッチの実行、アクセス権限管理など、なんだ普通にWebアプリじゃねーかって機能は揃ってます。
GASをなぜやるのか?
一つは、Webアプリをつくるのは楽しいってのを最短で知って欲しいから(初めから世界中に公開される状態でアプリをつくるので、つくったものを同僚や友達に送りつけて遊ぶとかも可能です)。
もう一つは、Spreadsheetを使う業務はかなり多いと思うので、その業務を効率化して、クリエイティブな時間に頭の多くのリソースを使ってほしいから。
あとは、現場のエンジニアがどういうことを考えながらプロダクトをつくっているか知ってほしいからです(僕自らその瞬間瞬間で何を考えながら何を実装するのかをしゃべりながら進めるので、思考の流れを追うことが可能です)。
人類総プログラマー化ではないですが、知りたい意欲のある人は挫折しない方法で知っておいても良いと思ってます。
GASに入門する
勉強会は基本的に集まったメンバーの様子を見つつ最適なカリキュラムを提供する形で行われています。
自分でガンガン進めるようになるまではある程度手取り足取りです。
それでは実際に入門していきましょう。
以下当日の流れです。
Hello World編
1. 実はRailsの勉強がやりたいって言って集まったので、Railsから「Webアプリ」の入門をしない方がいいですよとたぶらかし(!?)GASから入門した方がいい旨を伝える(これホント!)
2. まずはGASがなんなのかを説明する
3. Spreadsheetを適当な名前で作成してもらう
4. メニューのツール>スクリプトエディタより、GASの編集用のページを開く
5. ファイル名の編集とデフォルトで記入してあるプログラムを消す
6. 定番のHello Worldをする。以下をエディタ内に記入してもらう。
function doGet() { Logger.log("Hello World!!"); }
7. 実行は再生ボタン、ログの出力は表示>ログ。ちゃんと表示されましたか?
8. 今のはログでしたが、次はもうWebアプリケーション化しましょう。スクリプトを以下のように変更してもらう。
function doGet() { Logger.log("Hello World!!"); return ContentService.createTextOutput("Hello World!!"); }
9. Webアプリケーションの公開手順。メニュー>公開>ウェブアプリケーションとして導入を選択し、アプリケーションにアクセスできるユーザーを「全員(匿名ユーザーを含む)」とする
10. 導入をクリックするとURLが取得できるので、ブラウザの別タブでそこにアクセスしてみる
11. ここまでで特に詰まってなければ開始からものの10分程度でWebアプリケーションを開発し全世界に公開したことになります!おめでとう!
ここまで来ると参加者的にも一つ感動があると思います。別の文字にして楽しむだけでもこの段階では楽しみがあります。 そんな様子が、プログラマが始めてHello Worldしたときの感動を思い出させてくれます(センチメンタル)。
シート参照編
もちろんHello Worldだけで終わっても興醒めなので、次にデータベースと呼んでも過言ではないSpreadsheetをいじりに行きます。 まずは参照から。
1. 適当にシートを埋める。当日は参加者の名前の一覧にしました。
2. スクリプトを以下の様に変更する。
function doGet() { var sheetApp = SpreadsheetApp.openById("YOUR_SPREAD_SHEET_ID"); var sheet = sheetApp.getSheetByName("シート1"); var data = sheet.getDataRange().getValues(); Logger.log(data); // return ContentService.createTextOutput(); 一旦いらない }
3. YOUR_SPREAD_SHEET_IDの部分は開いているSpreadsheetのURL部分から抽出する(注: エディタの方ではない、弄りたいSpreadsheetのURL)
もしもSpreadsheetのURLが以下のようになっているなら https://docs.google.com/spreadsheets/d/111111111111-22222222222222222222222-3333333/edit#gid=0 111111111111-22222222222222222222222-3333333 の部分なので var sheetApp = SpreadsheetApp.openById("111111111111-22222222222222222222222-3333333"); となる
4. まずはログで出力を確認するために再生ボタンより実行する。その際に承認を求めらるので続行し、許可をする。
5. ログの出力が以下のようになっていれば成功
6. この辺で呪文率がいきなり90%を超えているので、丁寧に説明していく。変数も配列も一旦『箱』として説明しています。
- 変数という箱をつくっている
- 変数はあとで使いまわせる
- 箱の中に箱がある場合もある
- 箱の中に複数ものが入っていることもある
- SpreadsheetAppはSpreadsheet全体を取得している
- getSheetByNameで各シートをシート名から取得している
- getDataRange().getValues()で実際のセルの内容を配列として取得している
- など
7. 説明を一通り終えたら、次にdataを使ってWebアプリケーションっぽいことをしてみます。動的に変化するものがいいので、今回はシートのデータ数を表示することにしました。
function doGet() { var sheetApp = SpreadsheetApp.openById("YOUR_SPREAD_SHEET_ID"); var sheet = sheetApp.getSheetByName("シート1"); var data = sheet.getDataRange().getValues(); return ContentService.createTextOutput("このシートにはデータが" + data.length + "行ある。"); }
8. 書き換えが済んだらサイドWebアプリケーションとして導入します。一つ注意点としては、プロジェクトバージョン部分のプルダウンを選択して、かならず新規作成を選択してください。それをしない限り前のソースコードが公開され続けます。Webアプリケーションの方は保存体系が別ってことだけ覚えて置いて下さい。
9. 以下のように表示されていれば成功です。あとはSpreadsheetの行数を変更したあと、このWebアプリケーションのページを更新するとちゃんと数字が動的に変更されることを確認できると思います。
10. これができたら最後に値の参照もしてみましょう!列の最後の文字列が表示されていたら成功です!
function doGet() { var sheetApp = SpreadsheetApp.openById("YOUR_SPREAD_SHEET_ID"); var sheet = sheetApp.getSheetByName("シート1"); var data = sheet.getDataRange().getValues(); return ContentService.createTextOutput("このシートにはデータが" + data.length + "行ある。\n最後の人の名前は" + data[data.length -1][0] + "さんです。"); }
シート更新編
ということで、第1回の最後として、シートの更新もやってみましょう!
1. 一度シートの内容を消して0とだけ入力する
2. スクリプトを以下のように変更する
function doGet() { var sheetApp = SpreadsheetApp.openById("YOUR_SPREAD_SHEET_ID"); var sheet = sheetApp.getSheetByName("シート1"); var data = sheet.getDataRange().getValues(); data[0][0]++; sheet.getDataRange().setValues(data); var countStr = "あなたは" + data[0][0] + "回アクセスしました。"; return ContentService.createTextOutput(countStr);} }
3. Webアプリ側を更新して、ページをリロードしてみましょう!
4. リロードする度に数字が変更されていっていたら成功です。シートの0って数字もどんどんインクリメントされていると思います。
これで今回は終了!お疲れ様です!
補足
なぜ非Webエンジニアの人にRailsから教えないのでしょうか?
これは結構前ですが、以前書いていたので引用させていただきます。
反対に予期せぬ場所(プログラミングと関係ないところ、例えば環境構築、バージョン差…)などでハマることが多く、自分はたまたま短時間で回避出来ましたが、プログラミング初心者の人たちはこの辺でかなり時間を食うでしょう(最近10名弱にRailsを教えていましたが、ほぼ全員がプログラミングを始められる前の段階で多くの時間を費やしていました)。 プログラマーになるのであれば、当然通る道ですが、プログラマーではないけどWebサービスを作りたい人にとっては大変なYak Ratioですね。まあこれはRailsに限った話ではなく、他のどの言語にも言えることですが。。。
WEB+DB No.73の記事よりRails 4に入門する 〜最終回〜
環境構築を「しなくていい」GASはその辺でものすごくアドバンテージがあると思います。
良い時代になったなぁと思いました。
次回予告
今回のはまだまだテキストしかないアプリケーションなので、このあと見た目をよくするためにHTML・CSS・JSで色々加工していきます。 GASならその機能も内包しているので簡単です。見栄えのいいアンケートフォームなどこれで簡単につくれるようになります(単にフォームが欲しいだけならGoogleフォームで十分ですが)。
次回もお楽しみに!
まとめ
今回参加したのは、ビジネスやカスタマーサポートの面々でした。普段SpreadSheetやExcelである程度複雑な数式処理にはなれているものの、今回のWebアプリ開発ではところどころ感動してくれていたので、結構得るものは大きかったかなと感じています。講師冥利につきました。
ちなみに非エンジニアではなく、エンジニアだけど非Webエンジニア(ハード・スマホアプリ系)という人たちも弊社には多くいるので、そういう人向けには別ラインでもっと高度目のRails勉強会をやっています。こちらもひとまとまりしたら、ブログを書きたいと思っています。
ということで弊社に入社すれば非エンジニアの人でもCTOから直接Webプログラミングを学べるという特典があるよ★
学生の方もサポート業務をやりたいという方も是非ご応募ください〜!(業務にはもちろんプログラミングスキルは必要ないです)
2015年の物語と2016年の展望
2015年は色々あった。
色々ありすぎてもうまとめなくてもいいかって思ったけど、この現象は去年もあって、結局まとめを書いたような気もするので、今年は初めから長文を書く。
「あの頃の気持ち、忘れちゃだめだよね」
みたいな。
それだけ、起業しての最初の商品開発は20代後半に訪れた最後の青春みたいなそういう感覚だった。
最後にする気はないですが。
初めての起業、つくったのはハードウェア(2014/09〜2015/04)
まあこれは一昨年(2014年)の話だけど、自分の今後の人生に大きな影響を及ぼすような事柄だったと思う。
元々大手電機メーカーには縁のある大学だったので、正直推薦を使ってうんぬんみたいなこともできたということを考えると、当時の自分がまさか「大手電機メーカーの競合となる商品を開発」するなど露ほども思っていなかった。
そう思うと感慨深い。
「絶対に大手にはスピードで負けたくない」
って思ってとにかく時間と魂を使って開発していた。
できないことをできるようにして、わからないことをわかるようにして、成長しながらものづくりが出来たのはエンジニアとして最高の体験だったと思う。
その結果1人でたくさんのレイヤーを抱え込むことになって死ぬ思いもしたけど、それによってできたアーキテクチャというものもあると思う。
tmuxで何画面も開いて、ファームウェアとスマフォアプリとRailsを同時にいじっていたけど、あの無双感のようなものは多くの人に味わってほしい。
人の言葉を借りるならハイブリッドエンジニアがもっと社内に増えていいと思った。
これは独り占めしていいものではないので。
実は社内で下のレイヤーの人がRailsを勉強したり、上のレイヤーの人がCADをいじれるような施策はあったりする。
すでに勉強会は開催されていたり。
今年はそこにもっと力を入れたい。手始めに自分がRailsとGASの勉強会を非エンジニアも含めて始める予定。
みんなが"おいしい"部分の開発ができるようになったら御の字だなぁ。
販売からの新製品開発ラッシュ(2015/04〜2015/12)
4月に製品を発売してから、12月までの間に立て続けに4製品までを発表することになる。
よくこの人数でやり遂げたなと思っている。
ただこの辺については反省点が多い。
詳細は次回に譲るとして、主には選択と集中の話だけど、この辺のメリハリをちゃんとつけないとリソースのないベンチャーとしてはその後の伸びに影響があると思った。
今年はそれを気をつける年。
とにかくPMF目指して「良い」と言ってもらえる製品に高めていきたい。
YAPCでの発表
詳細はこちら。
はぁ、最後のYAPCで発表できたのは最高だった。50分の発表もやりきった感があった。
もっともっとこういう機会は増やしたいし、メンバーもどんどん発表に出て行ってほしい。
補助は出します。参加だけだとしても。
CTO就任
※Akerunと変な青いボタンを持っているのが自分。1位じゃなかったけど、限りなく1位だったと聞いた(?)のでずうずうしいポジションをゲットした。
実は就任直後にブログに書こうと思っていたらCTO Nightの方で先に出てしまった。
発表資料
「IoT」はものづくりを加速する | TechCrunch Tokyo 2015 CTO Night
結果
発表用に青いボタンをつくったんだけど、その詳細とかはQiitaに書きました。
外装とか社内の3Dプリンターでさくっとつくってくれたり、既存製品のプロト用基板があったりするから、それを使ってファーム調整すればすぐにIoTぽいものがつくれるのはうちならでは。
CTOの話に戻るけど、実は自分は最初は全然CTOになるつもりはなかったんだけど、組織の拡大による諸問題と信頼しているメンバーからの後押しで最後はCTOを立候補するくらいには心境が変化していた。
正直エンジニアリングはもう封印してもいいくらいに思っていたけど、CTOになって思ったのは「俺がエンジニアリングしてないのはなしだ」だった。
まあ最初からエンジニアリングを完全に捨てるつもりはなかったし、まわりへも1/3くらいはエンジニアリングするよってのは言っていたんだけど、自分がエンジニアリングをしなくなって失ったものは結構ありそう(自分の能力的な意味、組織機能的な意味で)。
#rebuidfm であったけど、いい兄貴問題ってやつ。いい兄貴は本当に解決しないといけない問題を解決できないってやつ。なので今後は自分にいい兄貴はそこまでは期待しないで(え
この辺も詳細はどこかで書きたい。
広がるコミュニティ
CTO Nightってイベントは本当に最高で、最高過ぎたのですが(主催のAWSさん最高!)、これによってすごい人脈も広がったと思うし、他の会社の有名なCTOの方もオフィスに見学に来てくれて、メンバーと交流してもらったりして、もうとにかく最高でした。Techcrunchの登壇後にそれを見たAWSの方がIVSの方でも発表してみませんかと声を掛けてもらったのも良かった。それによって更に人脈が広がって今後色々する予定です。本当にありがとうございます。
あとはハードウェアまわりのコミュニティも、これは創業時からだけど拡大していて、まさかこことここがつながっているの!?みたいな感じですごい楽しいです♪
自分が外に行っているときは、メンバーのこと見れないけどそこで広げた人脈を社内に還元するようなことは今後もやって行きたい。
技術選定
この辺は小さいベンチャーなので、大外れじゃなければどんどん技術を採用して使っていってほしいと思ってるし、開発メンバーも全然そのつもりでやってもらってるみたいです。
管理画面系とかつまらなそうな部分でも、例えばMithril.jsを選定して導入していたり、PubNub使って最小工数で通知実装していたり、HubでMQTT使っていたりとこの辺はその場その場で、エンジニアメンバーが考えて検討して導入しています。しかもいいなぁって思ったのはそれ以外の部分では、できるだけアーキテクチャが膨らまない用に実装していたり。それを実装するエンジニア自身が「あんまり増やすとあとあと大変だから」と言って自ら抑制してくれていた部分です。
なので、新しいからとか枯れていて定石だから色々取り入れているというよりも、今つくっているサービスのための最適で最高の技術はなんなのかを判断して選択してくれていて、最高ーという感じです。
(最高多い)
自分はどっちかって言うと技術選定ではアクセル踏んでしまうので、メンバーの中でブレーキも踏んでくれているのが嬉しいですね。
IoT感
別に最初はIoTだと思って製品開発してないわけなので、自分達のIoTはセンサー情報をかき集めてビックデータをAIで・・・みたいな感じになってないです。
逆にそれが良かったとも思っています。
その辺は社内メンバーがいい感じの表現をしてくれていたので、どこかでまとめてほしいかも。
意思決定と成長
ここは本当は書くことが多すぎるけど、この辺がベンチャーの醍醐味というか、2015年でかなりの"学習"が出来たと思っています。
創業者含め常に成長していって、大きな企業になれればと思いました。
2016年、これから
今年はとにかく多くの人に使ってもらえる製品を目指して機能や品質の向上を行っていきます。コアとなる機能もどんどん拡張していきたいです。 IoTベンチャーだからと甘えずに、常にWebの最新も取り入れながら、かつハード面でも大手ができない挑戦をどんどん推進できればなと思います。
ということで、株式会社Photosynthでは今後も採用に力を入れていきます!まずは話を聴いてみたいという方でもどしどしお声がけください!社内見学とあとランチをごちそうします!インターン希望の学生も歓迎です〜
自分の仲間を探すなら能力や性格よりも、自分と同じだけコストを払ってくれる人を選んだ方がいいという話
元後輩?から「どんな人を創業メンバーに選ぶべきですか?」質問をされたので、自分なりの回答をした。
正直今の会社の創業メンバーは、前職同期である社長の素晴らしすぎる人脈もあって、奇跡的な能力のゴールデンバランスと性格的相性の良さを兼ね備えた6人が手を上げ起業している。
なので、このこと自体は全然参考にならないよという前置きをおいたあとに、自分なりに思ったことを述べた。
コストを払わない人と一緒にやるとチームが自然解散する
起業前によくあったのは、エンジニア1人+企画2人とかのパターン。
大抵が本職がある状態でのプライベートプロジェクトで、土日のどちらかで1, 2週に一回集まって企画を考えてプロダクトに落として行くということをやっていた。
で、よくあるのが企画中はみんなでかなり盛り上がって笑い合って、じゃあこれで行こう!絶対いける!みたいになるんだけど、はいじゃあ実装開始ってなるとエンジニアが1人でモクモクやってるパターン。
一緒にやるメンバーが企画(そしてしゃべること)しかできない人だと、実装中はエンジニア一人だけで他のメンバーは何もやってない状態になる。
この状態がまだ2週間(集まりで言うと2回、工数で言うと2人日以下)とかだけなら、最低限自分も向こうも我慢できるんだけど、実装が難しいやつだったり、エンジニアも初めての技術を使っちゃってる場合は、2日動いたくらいじゃ全然プロトもできなくて、そうこうしていると期間としては1ヶ月くらい(作業は4,5人日以下)経っちゃって、そのうち企画だけしかできないメンバーの心が離れていく。
リリース当日に自分だけ作業していて、他の二人は新しく買ったクロスバイクで横浜までサイクリングに行っているって謎状態とか昔あった。
こんな状態になるとエンジニアの方は「なんで俺だけがんばってるんだよ、できないことがあってもそばにいるくらいしろよ」ってなって、製品やメンバーに対する愛着を失う。
「みんなが自分と同じだけ製品にコストを払ってくれる人じゃなかったら、多分今起業してないよ」
こういう経験を過去何回か繰り返してるうちに、逆に成功パターンもあって、どういうときに成功するかというと「チームのエンジニア・デザイナーの比率が過半数以上」の状態。
もしくは企画だけやってる人も、雑務や力仕事やユーザーインタビューなどを自分の時間を割いて、やってくれている状態。
つまり手を動かす人が多い、もしくはそういう人たちだけで構成されていると、割りと最後まで不満も出ずにプロダクトの完成まで行ったりする。
違いはなにかなぁって思ったんだけど、結局はタイトルにもある通り、
「製品に対して自分と同じくらい他の人もコストを払っていることがわかる状態にある」
ってことかなと。
週一の集まりとかも、自分だけが進捗を披露するみたいになると、エンジニアはモチベーション沸かないし、他の人もできてないときに白けてしまう。
でも集まれば必ず各々進捗があって、ああでもない、こうでもないってなっていると、自分以外の人も頑張っていることもわかるし、自分がやったことの還元もあるし、次回も自分がやらないわけにはいかない、頑張ろうみたいな心理になる。
チームの人数も重要
あと人数も重要で2, 3人だと、自分が休んでも影響少ないしいいかってなる。
でも例えば8人集まる会なら、自分がいないことで迷惑をかける人が7人いることになるので、流石にそれは申し訳ないってなってちゃんと遅刻しないで出席する気持ちになる。
(※もちろん仕事ならアポの相手が1人だろうと遅刻やすっぽかすなど論外ですが、プライベートプロジェクトの場合はこの気持がぐっと下がるのが常かなと思います)
コスト→愛着
こんな感じで、何週間かやっていると、全員がそれなりのコストを払い始めるので、他人に迷惑をかけたくないって気持ちもそうですが、自分がコストをかけたプロダクトに愛着が生まれてくるようになります。
この愛着が生まれてくると、リリース当日に集まらないとかありえない状況ができてくるわけでです。しかも能動的に。
人間はコストをかけたものの方が愛着を感じるものです。イケア効果ってやつですね。
まとめ
なので僕が言いたいのは、どんなに能力が高くて性格の相性が良くても、多分全員がコストを払って、製品に愛着を持つようになってないと、解散の危機があるということです。
しかも重要なのはコストを払わせることなので、最初めぐりあったときに性格的に相性が合うかわからなくても、向こうもエンジニアだったり、企画でもユーザーインタビューに奔走しているとかであれば、ある程度チームとしては続いていくことになるとは思います。
もちろん反例は認めるけど、最初に考えるべきチーム構成としては全員がコストを払う構造があることは必要条件だと思うんですよね。
☆株式会社フォトシンスでは、一緒に愛着を持ってプロダクト開発をしてくれるエンジニアを募集中です☆
ロングセッションでの効率的な資料の作り方
先日YAPCで50分の発表を行って来ました。
Twitterで「何十分もの発表は資料をつくるのが大変だから」という理由で、応募しなかったり落選してよかったと言っている人を過去も含めて何人か見かけたので、今回は自分が50分の資料をつくるためにやったことを話します。
スライドツールを使う前にアナログな方法で仮設計する
ここで仮設計とは、
- トーク時の風景を頭でイメージする
- シャワーを浴びているときや通勤時歩いているときなどに、何を言いたいか頭の中で考える
- 試しに何もスライドがない状態で、一体何分間喋れるか録音しながら話してみる
といったことです。
特に最後の「録音しながら話してみる」は、効果絶大で日々寝る前にとりあえず20〜40分くらい最初はだらだら、思考が固まるごとに、より正確に喋れるように訓練を重ねました。
スライドのない段階でトークを録音する効能は、
- 実は50分喋れないんじゃないかという不安をなくす
- 頭の中にあることを強制的にアウトプットする
- あまり順番は気にしないが、必要そうな分量については吐き出し切ることに注力する
- 人に話すようにしゃべることで、半分は当日のしゃべり方の練習にもなる
ここでもし半分の25分も喋れなかったら、「なんで俺応募したんだろう」ってことになるので、自信がない場合は本番一ヶ月以上前の段階で録音テストを行い、内容が足りなければ、1日数時間余分に時間を取ってスライドの内容をつくって行った方が良いでしょう。
自分は割りと”無意識時に勝手に頭が整理してくれる機能”の存在を信じているのですが、実際「考える」のあとに「全然関係ないことをしてインターバルをおく」は重要で、その間に発表の設計イメージが固まっていきました。
本設計は紙とペンだけで
ここでもまだスライドツールは使いません。
これが異常に捗ったのですが、上の写真のようにノートにスライドの枠を書いて、仮設計しながら頭の中で形成されていたイメージをどんどん書き出していきます。
発表はシリアルなものなので、スライドから次のスライドへの変遷時に言う繋ぎの言葉も考えながら書き出していきました。
これを最後まで出し切って、精読して問題がなさそうなら本設計終了です。
最初からスライドツールを使わない理由は、思考が一度詰まってしまったときに、どこが悪いかが俯瞰して見えなくなったり、時間を掛けてスライドをつくってしまったせいで、変更に対する心理的なコストが上がってしまうからです。
紙とペンでやってるだけなら、見渡すのも直すのも簡単です。
スライドを実装する
僕はMarkdownで書いたら自動でスライドにしてくれるツールを自分でつくって使っていたので、本設計の内容をMarkdownに書き出していきました。
前回のブログにも書いたのですが、スライドツールはTalkie.jsを使い、Markdown2Slideなツールは自分でスクリプトを書きました。
これは一旦は単純作業ですが、途中々々で図が出てきたときは、MacのKeynoteで作成して、作成した図をコピーしたら、ToyViewerを起動して⌘+Shift+Vで図を都度画像化して貼っつけて行きました。
実はKeynoteは今回初めて使ったのですが、パワポよりも使える図形の数が少ないものの、図の位置の調整が神がかっていて、スムーズに作成できました。
あとは発表練習をしながら改善していく
ここから真の発表練習を開始です。事前に録音を何度かやっていたならスムーズに行くはずです。やってないで前日とか迎えると、結構このタイミングではまずいです。
しゃべりながら変な部分がないか確認していき修正していきます。
合計として資料の精度だけでの直し3回、発表練習は5回しました。 あと絶対に前日に成功パターンの発表練習を終わらせておき、練習と発表時間との間に睡眠を挟んでから本番に望みましょう。
寝ている間に整理されるはずです。
僕の練習時の発表時間は、
20分(スライドを読み上げただけ)→60分(スライドちょっと増やして話し方も修正)→55分(微調整)までが前日
当日朝6時に置きて、追加でスライドの精読と何度か練習をして50分ほどに調整
本番もちょうど50分ちょいで発表を追えることができました。
まとめ
- 何もない状態から発表内容を録音するのは仮設計としゃべりの練習ができて一石二鳥
- スライドツールを最初に触るのではなく、紙とペンで本設計する
- エンジニアなら使い慣れたMarkdownで資料をつくるのもあり
- 発表練習は入念に
Enjoy Presentation!
YAPC::Asia 2015で「Web由来の組み込みエンジニア」について発表してきました!
YAPC::Asia 2015 一日目の11:10より、東京ビックサイトにて、「Web由来の組み込みエンジニアの半年間のすべて 〜WebとiOSとBLEとハードウェアデバイスのこと〜」というタイトルで登壇して来ました。
最後のYAPCということもあり、発表の選考に漏れてもいいように「個人スポンサー」も申し込むという万全の体制で待ち構えていましたが、運良く採択されたため、ピンクとオレンジのダブルストラップ体制という形でYAPCに発表に望めました。
Talkの概要
発表のスライドはこちらになります。
Web由来の組み込みエンジニアの半年間のすべて 〜WebとiOSとBLEとハードウェアデバイスのこと〜
なぜ発表したか?
最後のYAPCなので、絶対に発表しておきたかったというのはあります。また去年のYAPCで発表する内容やリソースが自分になくて歯がゆい経験をしたというのもあります。
ですが、一番は今の日本のベンチャーにおいてこんなにも「IoT」している企業が弊社以外にまだまだ少なく、またこういう場所で発表を行う企業もまだまだないだろうということです。「IoT」をやっている企業として「IoT」を実際にやって製品開発をしてみての経験がとても貴重なものであり、それを外に出したいと思いました。
今回の発表は個人的にはすごい「エモい」発表になっていると思っています。本当はもっとソースやデモやアーキテクチャの構造や開発ノウハウなのどを公開したかったですが、それには50分はあまりにも短すぎました。
今後たくさんブログを書く予定ですので、それによって徐々に公開していきたいと思います。
もし聞きたい話があればリクエストください。
スライドの作成方法について
スライドの作成には、id:ahomu さんのTalkie.jsというのを使わせていただきました。
僕は基本的にはREADME.mdでざっと草案をつくったあとに、それをslideに変換することが多いので、今回もmarkdown2talkiejsな簡単なコードを書いてスライドを作成していました。
こんな感じの書捨てスクリプトですが、これで十分満足することができます。guard + livereloadも追加していたので、リアルタイムに反映しながら作成していきました。
#!/usr/bin/env ruby # coding : utf-8 require 'erb' require 'pry' html = File.read('README.md') html.gsub!(/^(#|##|###) ([^\n]+?)\n<!-- image (.+?) -->$/m) { "</template>\n<template layout=\"cover\" invert type=\"text/x-markdown\" backface=\"#{$3}\" backface-filter=\"blur(0px) brightness(.3)\">\n#{$1} #{$2}\n"} html.gsub!(/\n\n(#|##|###) ([^\n]+?)$/m) { "</template>\n<template layout=\"bullets\" type=\"text/x-markdown\">\n#{$1} #{$2}\n"} html.sub!(/<\/template>/, "") html += "</template>" html = ERB.new(File.read('template.html.erb')).result binding open("index.html", "w") {|f| f.write html}
スライドの全体のソースはここを見るとわかります。
README.mdを変換するメリットとして、githubなどで見た時に構造化された文章として出力されることです。
最後に
一番最初の発表ということで半分あきらめてますが、ベストスピーカー賞を狙っているので、まだ投票していない方は投票の方をお願いします!!!