こんにちは！セーフィー株式会社のサービス開発部 モバイルチームの北本です。 主にSafie ViewerのiOSアプリの開発を担当しています。 今回は、リーダブルコードを読んで、プルリクレビュー改善に活用する話をしたいと思います。 なぜリーダブルコードを読むのか リーダブルコードとは？ リーダブルコードに書かれていたこと 理解しやすいコードとは？ 表面上の改善（第Ⅰ部） 命名規則について コメントについて ループとロジックの単純化（第Ⅱ部） 関数から早く返す、ネストを浅くする 変数を用いて分割する 変数のスコープと変更 コードの再編成（第Ⅲ部） 無関係な下位問題を抽出する 一度にひとつのことを ロジックを明確に説明できるか？ 短いコードを書く さいごに なぜリーダブルコードを読むのか セーフィーモバイルチームは現在、チームビルディングを積極的に進めています。 ある日のミーティング時に、コードレビューに関して、以下のやりとりがありました。 シニアエンジニアが若手エンジニアのプルリクエスト（以下PR）にどの範囲まで指摘すればいいかわからない 若手エンジニアがシニアエンジニアのPRに何をレビューすればいいかわからない そこで、チーム開発において良いコードの書き方の基準を定めようということになり、 モバイルチーム全体でコードの理想状態を議論した結果、チームの生産性を高めるコード≒可読性の高いコードとして理想状態を定義し、リーダブルコードをPRのレビュー指針のベースとして取り入れようということを決めました。 今回の記事ではリーダブルコード（第22版）を「チームに取り入れられるレビュー指針はあるか」といった目線で読み返し、議論の叩きとして、レビュー観点をチェック項目形式でまとめた物を共有します！ www.oreilly.co.jp リーダブルコードとは？ 「エンジニアが読むべき本」「エンジニアが影響を受けた本」と検索すると必ずといっていいほどトップに出てくるのがこの本『リーダブルコード ――より良いコードを書くためのシンプルで実践的なテクニック』です。副題の通りより良いコード、読みやすいコードを書くための実践的なテクニックが変数の命名からロジック、テストまで章ごとに体系的に説明されています。皆さんのチームでも、エンジニア同士が可読性の高いコードを説明する上で共通言語として会話に登場することもあるのではないのでしょうか？ この記事では、現場での活用例の共有として、役立てていただければと思います。「なぜこのルールが読みやすいコードに繋がるのだろう？」と気になった方はぜひこの記事をきっかけにリーダブルコードをお読みいただければと思います。 リーダブルコードに書かれていたこと セーフィーのチーム開発で取り入れることができそうな記述を抜粋し、「 どういった観点でレビューすれば良いか 」といった視点でまとめます。この記事はあくまで「チームのカルチャーにフィットさせるための議論の叩き」という立場なので現実的なルールの粒度かどうかの観点は考慮していないことにご注意ください。 理解しやすいコードとは？ （1章 理解しやすいコード） リーダブルコードでは以下を著書の目的として定義しています。 （引用 まえがき） 本書の目的は、読みやすいコードを書くことである。その中心となるのは、コードは理解しやすくなければいけないという考えだ。具体的に言えば、誰かが君のコードを読んで理解する時間を最短にするということだ。 また、コーディングには、コードの効率化、設計、テスタブルといった様々な側面がありますが、この章では「コードを読みやすくするという視点はその他の目標と競合しない、高度に最適化されたコードであってももっと理解しやすくできる」といった点も言及されています。iOSの開発では、用いられているSwiftでは高機能なコンパイラによる最適化も施されるため、コードの可読性の追求という点においてトレードオフになる要素はゼロといって良さそうです。 ひとまずセーフィーモバイルチームでも、「レビュワーが理解しやすくするには？」といった視点に立ち、メンバーのコードを理解するまでにかかる時間を最短にすることで、チームの生産性の向上を目指していきたいと思います。 次章以降で具体的なテクニックに関して説明されています。 表面上の改善（第Ⅰ部） 命名規則について （2章 名前に情報を詰め込む、3章 誤解されない名前） （引用 p.10） 明確な単語を選ぶ 「名前に情報を詰め込む」には、明確な単語を選ばなければいけない。 getやsizeなどの汎用的な単語を変数名、関数名で避け、明確な単語を選ぶべき理由が説明されています。 変数名、関数名に汎用的な単語が使われてないか？明確な単語に置き換えることはできないか？ 役割が理解できない変数名はなかったか？ （引用 p.19） 名前に情報を追加する 名前は短いコメントのようなものだ。変数名に詰め込める情報はあまり多くない。だけど、名前につけた情報は変数を見るたびに目に入ってくる。 また、時間、サイズといった値の単位や、危険や注意喚起のための情報を変数名に追加するためのテクニックが説明されています。また、「変数のスコープが小さい場合は短い名前でも良いが、エディタには単語補完があるので避ける理由にはならない」といったことにも 触れています。 命名に利用されている単語は曖昧すぎないか？情報は十分か？ ここでは「命名のフォーマット規約」についても触れられていますが、iOSの開発に関して言えば、Swiftの公式ドキュメントにある API Design Guideline や、Apple公式のフレームワークがあるので、こちらに寄せていくことでより明瞭な命名ができそうです。 プログラミング言語の規約や、公式ライブラリの命名規則に乗っ取った命名ができているか？ コメントについて （5章 コメントすべきことを知る、6章 コメントは正確で簡潔に） （引用 p.69〜70） コメントすべきでは「ない」こと： ・コードからすぐに抽出できること。 ・ひどいコード（例えば、ひどい名前の関数）を補う「補助的なコメント」。 コメントを書くのではなくコードを修正する。 記録すべき自分の考え： ・なぜコードが他のやり方ではなくこうなっているのか（「監督コメンタリー」）。 ・コードの欠陥をTODO: やXXX: などの記法を使って示す。 ・定数の値にまつわる「背景」。 読み手の立場になって考える： ・コードを読んだ人が「えっ？」と思うところを予想してコメントをつける。 ・平均的な読み手が驚くような動作は文書化しておく。 ・ファイルやクラスには「全体像」のコメントを書く。 ・読み手が細部に捕われないように、コードブロックにコメントをつけて概要をまとめる。 この章で「価値のあるコメント」と呼ばれていた、「実装の背景、ToDo」を書く文化は既にあるので守っていきたいです。 ただ、複雑な処理を行う実装でも、レビュアーがコメントを読んでいて実装内容が明確にわかるか、びっくりしたことがないか、を意識する必要がありそうです。 また、読み手の立場になって考えることの重要性が書かれていましたが、コードレビューにおいては、明確に読み手視点でコメントの改善を促すことができます。本人では気付きづらい点をレビュワーが「コメントの内容が理解できたか」の観点で改善を促していくのは効果的だと感じました。 コードからすぐに抽出できること、命名で補えることをコメントしていないか？ コメント内容をコードの修正で補えないか？ なぜ他のやり方ではなくこうなっているのかわからない箇所はあるか？ TODO: やFIXME: , HACK: などの記法を使って示す箇所はあるか？ 「背景」がわからない、動かすことのできない定数の値はないか？ レビュワーが「びっくりしたこと」がなかったか？ 自明でない挙動、動作について記述したコードはないか？ ファイルやクラスに「全体像」に関するコメントが書かれているか？ コードブロックに概要がコメントによって整理されているか？ ループとロジックの単純化（第Ⅱ部） 関数から早く返す、ネストを浅くする （７章 制御フローを読みやすくする） （引用 p.97〜98 一部省略） 比較（while (bytes_expected > bytes_received)）を書くときには、変化する値を左に、より安定した値を右に配置する（while (bytes_received < bytes_expected)）。 if/else文のブロックは適切に並べ替える。一般的には、肯定系・単純・目立つものを先に処理する。 〔中略〕 ネストしているとコードを追うのに集中力が必要になる。ネストが増えるたびに「スタックにプッシュ」することが増える。深いネストを避けるには「直接的」なコードを選択する。 早めに返してあげると、ネストを削除したりコードをクリーンにしたりできる。特に「ガード節」（関数の上部で単純な条件を先に処理するもの）が便利だ。 私が普段使っているSwiftでは非同期な処理をクロージャを使ってネストして書くことが多いので、なるべくネストを浅くする工夫が必要になってくると感じました。 また、推奨されていたガード節に関して、言語仕様によってはguard文があり、returnを強制することができるので積極的に使っていく方針が取れそうです。 比較条件では、変化する値が左に来ているか？ if/else文のブロックは肯定系・単純・目立つものを先に処理されているか？ クロージャ、if文等のネストを浅くする手段はないか？ guard文を利用して改善できる箇所はないか？ 変数を用いて分割する （8章 巨大な式を分割する） （引用 p.108 一部省略） 最も簡単な方法は「説明変数」を導入することだ。大きな式の値を保持する説明変数には、３つの利点がある。 ・巨大な式を分割できる。 ・簡潔な名前で式を説明することで、コードを文書化できる。 ・コードの主要な「概念」を読み手が認識しやすくなる。 その他には、ド・モルガンの法則を使ってロジックを操作する手法がある。 〔中略〕 本章で取り上げた全ての改善コードには、if文の中身が２行以上含まれていない。これは理想的な状況だ。同じことが常にできるとは限らない。そんなときは、問題を「否定」したり、反対のことを考えてみたりすることが必要になる。 レビューにおいては、レビュワーが直感的に複雑な条件や、わからなかった計算があった場合にそれを指摘し、指摘があったレビュイーが「説明変数」、「要約変数」の概念を使って解決するといった方針が取れそうです。 「改善コードのif文の中身が２行以上含まれていない」といった状況を理想的と書かれていましたが、Swiftでは変数のオプショナルラップに利用されており、言語仕様によっては難しい場合もありそうです。 わからなかった計算はなかったか？ 複雑な式を説明変数を用いて分割できないか？ ド・モルガンの法則を利用して多重括弧を削ることができないか？ 複雑な文の条件を否定、「反対を考える」といった手法で単純化できないか？ 変数のスコープと変更 （ 9章 変数と読みやすさ） （引用 p.126） 変数を減らして、できるだけ「軽量」にすれば、コードは読みやすくなる。具体的には、 ・邪魔な変数を削除する。ーー本章では、結果をすぐに使って、「中間状態」の変数を削除する例を示した。 ・変数のスコープをできるだけ小さくする。ーー変数を数行のコードからしか見えない位置に移動する。 ・一度だけ書き込む変数を使う。ーー変数に一度だけ値を設定すれば（あるいは、constやfinalなどのイミュータブルにする方法を使えば）、コードが理解しやすくなる。 Swiftで利用するXcodeでは、利用されていない変数や、値の再代入のないvarの変数宣言などは警告をしてくれるのでありがたいです。 また、本書の例のようにロジックを整理することで変数そのものを消したり、varの宣言をletに変えられることもありそうです。 さらに「変数のスコープを小さくするために、コード行数をできるだけ減らす」という観点は比較的指摘がしやすく、実際のPRでも使っていきたいです。 外部から参照されていない変数、関数はprivateになっているか？ 継承されていないclassはfinalになっているか？ 宣言をイミュータブル（let）に変更できる変数はないか？ 変数は利用する直前で宣言され、利用できる範囲が最小化されているか？ コードの再編成（第Ⅲ部） 無関係な下位問題を抽出する （10章 無関係の下位問題を抽出する） （引用 p.130） 本性のアドバイスは、無関係の下位問題を積極的に見つけて抽出することだ。ぼくたちは以下のことを考えている。 1. 関数やコードブロックを見て「このコードの高レベルの目標は何か？」と自問する。 2. コードの各行に対して「高レベルの目標に直接的に効果があるのか？　あるいは、無関係の下位問題を解決しているのか？」と自問する。 3. 無関係の下位問題を解決しているコードが相当量あれば、それらを抽出して別の関数にする。 （引用 p.141） 本章を簡単にまとめると、プロジェクト固有のコードから汎用コードを分離するということだ。ほとんどのコードは汎用化できる。一般的な問題を解決するライブラリやヘルパー関数を作っていけば、プログラムに固有の小さな核だけが残る。 この章では、「プログラムに固有の小さな核」＝その関数、コードブロックの関心事のみを残し、それ以外は別の関数やクラスに切り出して汎用化すべきだということが書かれていました。 関数、コードブロックの核は明確化されているか？別の下位問題を扱ってないか？ 汎用コードとして切り出せるロジックはないか？ また、既存のインターフェース部分の「汎用コード」を自前のextensionを作って簡潔にすることも意識していきたいです。 ライブラリのインターフェースが複雑な部分から汎用的コードは作れないか？ 一度にひとつのことを （11章 一度にひとつのことを） （引用 p.155） 読みにくいコードがあれば、そこで行われているタスクを全て列挙する。そこは別の関数（やクラス）に分割できるタスクがあるだろう。それ以外は、関数の論理的な「段落」になる。タスクをどのように分割するかよりも、分割するということが大切なのだ。 この章を読んでPR内の実装が読みにくい場合、一度に複数のことを並行して行っている可能性が高いと感じました。 その場合、読みにくいことをレビュワーが伝え、レビュイーにタスクを全て列挙してもらう、別のクラス・関数に処理への分割を提案するといったアクションが取れそうです。 読みづらい関数やロジックがあった場合、別のクラス・関数に、分割できないか？ ロジックを明確に説明できるか？ （12章 コードに思いをこめる） （引用 p.165 一部省略） 本章では、プログラムのことを簡単な言葉で説明する技法について説明した。説明することでコードがより自然になっていく。この技法は思っているよりも簡単だが非常に強力だ。説明で使っている単語やフレーズをよく見れば、分割する下位問題がどこにあるかがわかる。 〔中略〕 問題や設計をうまく言葉で説明できないのであれば、何かを見落としているか、詳細が明確になってないということだ。 複雑な考えを伝える時に、自分よりも知識が少ない人に簡単な言葉で説明する能力が大事といった内容でした。 PRにおいては、概要や、解決する問題、解決手段をレビュアーに説明する必要があるため、「ロジックを明確に説明できるか？」という観点はそのまま利用できそうだと感じました。PRの内容を概要で説明できること、コミットメッセージが簡潔にまとまっていることへの意識は重要そうです。 PRの内容が概要に簡潔に説明されていて、レビュアーは意図がわかるか？ また、一度に複数の修正を含んでしまったPRは簡潔な説明にならないはずなので、レビュイーの意識として - PRのコミットを細かい目的ごとに分割する - リファクタリングと不具合修正のPRを分ける ということも必要になってくるはずです。 コミットの単位は適切か？ 一つのPRに関して目的が一つに定まっているか？ 短いコードを書く （13章 短いコードを書く） （引用 p.175） 本章では、できるだけコードを書かないことについて説明した。新しいコードには、テストや文書や保守が必要になる。また、コードが増えると「重く」なるし、開発も難しくなる。 新しいコードを書かないようにするには、 ・不必要な機能をプロダクトから削除する。過剰な機能は持たせない。 ・最も簡単に問題を解決できるような要求を考える。 ・定期的にすべてのAPIを読んで、標準ライブラリに慣れ親しんでおく。 短いコードを書くためのテクニック、意識が紹介されていました。 基本的に同意できる内容だったのでチェック項目だけまとめました。 必要のない、利用されていない過剰なロジック、コードがないか？ 変更・修正の方針が正しいか？ 問題をもっと簡単に解決できないか？ 今回使われなくなったコードはちゃんと削除しているか？ ライブラリ、既にあるロジックを使って解決できないか？（処理が重複してないか？） さいごに 本書の「読みやすさ」はチームにおいて、コードを分割すべきかどうかの判断基準としては良い共通言語になると思います。私自身も、この記事を書きつつ日々のコードの質や、レビューの観点、コーディングにおける価値観にどんどん影響を受けていくのを感じています。 また、この本の初版は2012年です。10年近く経っているにもかかわらず、現代のエンジニアからも変わらない評価を得続けていることからも「コードは理解しやすくなければならない」という価値観の正しさと汎用性を感じます。私たちセーフィーモバイルチームのように方針や、共通言語として本書を利用するという手法もぜひお勧めです。 一方で、チェック項目全てをPRのレビュー観点として運用することが適切だとは考えていません。記事にする都合上、チームやプロジェクトのカルチャーや温度感、既存のルールに合っているか？という観点を今回は考慮していないからです。既存のプロジェクト内でルールを統一、浸透させるコストや競合する文化などを鑑みて、項目数を増減させたり、表現を修正する必要があるでしょう。セーフィーモバイルチームでも、この運用は議論の叩きの段階なので、今後チームにフィットさせるために議論を重ねていきます。 また、リーダブルコードに書かれていた観点がレビューにおいて見るべき箇所を網羅できてはいません。本書の説明していたロジックの修正の観点に加え、関数の関心がどこに向いているべきなのか、どのクラスで処理すべきなのか、どのパターンを適応すべきなのかといった純粋な技術力に基づく判断は必要でしょう。今後、 SOLID原則 など基礎となる実装パターンも学んで力を付けたいと思います。 チーム開発において、チームメンバーでレビュー観点に共通認識があり、プロジェクトが読みやすいコードで記述されていることで、レビューの時間が短くなり、コードの理解が早くなり、実装方針に悩む時間が減り、コードメンテナンスがしやすくなります。 皆さんも名著から学んだ知識を現場でどう活用できるか、どんな課題を解決できそうかを考えることで、チームの生産性を大きく上げるきっかけを作れるかもしれません。また新しい発見や学びがあれば、ブログに投稿したいと思います。 セーフィーでは、チームで切磋琢磨し成長していける方を募集しています。ご興味のある方のご連絡をお待ちしています。 open.talentio.com

セーフィー株式会社 プラットフォーム開発部のソフトウェアエンジニア 斎藤です。 Safie サービスの安定運用に寄与するべく、インフラ周りの構築・運用を主に担当しています。 今回は複数人で開発していると起こりがちの不便さを GitHub Actions を活用し解消したお話です。 例えばこんな不便なことありませんか？ 不便をどのように解消したか 概要図 処理フロー 処理の詳細 GitHub Actions Python (boto3) 作った環境の自動廃棄 残課題 おわりに 例えばこんな不便なことありませんか？ ブランチを固定しておきたいとき 動作確認のために、とあるブランチをしばらく取り込んでおきたいとき テスト環境へブランチを適用したいが、ブランチ適用待ち渋滞の発生 (複数人で一つの環境を共有している場合に発生しがち) 不便をどのように解消したか 複数人で一つの環境を共有しているのが問題になっています。 ブランチ毎に確認環境があれば良さそうということで、事前確認出来る環境を自動構築 && 不要になったら自動破棄する仕組みを作りました。 概要図 今回作った仕組みの概要図になります。 GitHub Actions AWS SDK for Python (Boto3) を利用しています。 処理フロー ユーザーが git push します Pull Request 作成 && ラベル (deploy) 付与します ※ラベル名は何でも良いです ラベル付与方式にした理由は、事前確認するまでもない場合に発火させない為 ※ 例えば typo / ドキュメント修正など明らかに動作に影響しない修正とか ラベル付与イベントを検知して GitHub Actions が発火し、環境自動構築します docker build && ECR に push Python (boto3) kick タスク定義の登録 target group と forward rule 新規追加 タスク定義と target group を紐付けた service を新規追加 最後に CNAME のレコード登録をして完了 https://prXXX.example.com XXX はプルリク番号が入ります https://pr82.example.com みたいにプルリク毎に環境が出来ます 処理の詳細 GitHub Actions と Python (boto3) の処理をそれぞれコードベースでかいつまんで説明します。 GitHub Actions Python (boto3) 作った環境の自動廃棄 作った環境の自動廃棄については、以下の条件で行っています。 プルリクエストがマージされた時 destroy する GitHub Actions 発火 ↓ python kick python destroy_dev.py ${{ github.event.pull_request.number }} route 53) DELETE resource_record_sets ECS) タスク停止 && deregister_task_definition ECS) delete_service ALB) delete_rule && delete_target_group 残課題 一度確認した後、再修正が必要で再 push したときの待ち時間(約1分)をもう少し短く出来れば良いなと思っています。 おわりに 以上、複数人で開発していると起こりがちの不便さを GitHub Actions を活用し解消したというお話でした。 日々の開発業務を進めていく上で、小さな不便を自ら拾いに行き、自分ごととして改善するチャンスが沢山あります。 改善を繰り返すことで自分自身の成長、やがてはチーム、組織へも貢献出来るかと思います。 セーフィーでは、迷った時はやってみて成長機会を求める意識の高い方を歓迎します。 ご興味のある方のご連絡をお待ちしています。 open.talentio.com

セーフィー株式会社 プラットフォーム開発部のソフトウェアエンジニア 鈴木敦志です。 セーフィーでは動画データの利活用を進めるため 顔認識来店分析サービス Safie Visitors などAI技術を活用したサービスの開発を行っております。 画像認識AI応用サービスを開発するには、一般的な用途 (顔認識や物体検知など) に対応する学習済みのAIモデルを使用するか、あるいは特定の用途 (不良品検知など) のために自前でAIモデルの構築・運用を行う必要があります。 一方で、「ドアが開いているか知りたい」「商品が陳列されているかを知りたい」などの簡単なタスクについては、既存の学習済みディープラーニングモデルを利用した転移学習とk近傍法などの単純な分類アルゴリズムを用いることで、数枚の教師画像を選択するだけで非常に簡単にAIによる画像分析を利用することができます。 参考: 20190928 M5StickVではじめる軽量モデルの実世界への応用 #TFUG - ミクミンP (@ksasao) 様 本記事ではSafieカメラのライブストリーミング映像を用いてAIモデル作成、リアルタイム画像分類を行うWebアプリケーションを実装しました。 Safie AI画像分類 [alpha] について 使い方 システム構成 推論アルゴリズム 今後の展望 Safie AI画像分類 [alpha] について 使い方 Webブラウザで「Safie AI画像分類 [alpha]」にアクセスし、Safieのユーザーアカウントでログインします。 一覧からカメラを選択、 画像のクラス（「ドアが合いている」「閉じている」等）を作成し、「例を追加」ボタンで現在のカメラ画像を教師データとして追加します。 現在のカメラ画像がどのクラスに分類されるかをAIがリアルタイムで判定し、該当するクラスがハイライト表示されます。 システム構成 Safie AI画像分類 [alpha] は Nuxt.js で実装されたWebアプリケーションです。 Safieクラウド に接続されたカメラ映像をHLSでストリーミング再生し、 TensorFlow.js で各フレームの推論をWebGL経由でGPUを駆動して行います。 分類アルゴリズムにk近傍法を用いており、教師データの学習は指定されたフレームの画像データを追加するだけで完了します。今回は人がいる場合といない場合の3枚ずつ、計6枚を使用したのみとなっています。 推論アルゴリズム 推論アルゴリズムには画像からの特徴抽出にMobileNetV1を使用し、特徴量からの分類をk近傍法を使用します。 MobileNetはディープラーニングによる画像の分類・オブジェクト検出などに使用されるモデルで、モバイル端末などでの用途のため計算負荷が小さいのが特徴です。 今回は転移学習を用い、1,000クラスの分類タスクを行う学習済みMobileNet V1モデルの畳み込み層を特徴抽出器として利用し、得られた特徴ベクトルをk近傍法の入力とします。 k近傍法は基本的な機械学習アルゴリズムで、入力ベクトルに最も近い (ユークリッド距離) k個の教師データを探索し、そのうち最も数が多いクラスに入力を分類します。 k近傍法ではより複雑なアルゴリズムに比べ精度は劣りますが、少ない教師データで動作し (k=1のとき各クラスごと画像一枚から) 教師データの追加が簡単になります。 参考: 画像分類器の転移学習 | TensorFlow.js 今後の展望   今回は技術デモとして、ブラウザ上でのみ動作する非常に単純な構成で実装を行いました。 この構成は簡単な認識タスクを行うことを前提にしているためブラウザ上だけの実行のみでは実用的ではないのですが、Safieクラウド上でのモデルの共有・認識のスケジュール実行・通知などを組み合わせることで非常に簡単にAIシステムを構築することができるようになるのではないかと思います。 セーフィーでは先述の顔認識来店分析サービスなどのほかにもいくつかのAI関連のサービスを開発しており、カメラの接続および動画の収集・保管といったAI画像解析系サービスの開発時に手間のかかる部分にSafieクラウドのインフラを使用することができます。 また、外部の開発者がSafieクラウド上にこういった分析サービス等を開発できるような仕組みを整備していく予定です。 弊社ではこれらの技術に関心があり、新しいサービスを一緒につくっていただけるエンジニアを募集しています。 open.talentio.com

フロントエンドエンジニアの近藤です。 Web版のカメラ録画映像ビューアー（Safie Viewer）開発 を主に担当しています。 セーフィーにはエンジニアの成長機会について、希望すれば柔軟に対応できる体制があります。その一つとして今年1月から部署内で ソフトウェアアーキテクト勉強会 を隔週ペースで開催しています。今回はこの取組みについての紹介です。 勉強会発足の経緯 ソフトウェアアーキテクト（アーキテクチャ）とは ソフトウェアアーキテクトになるためには 勉強会の様子 ステークホルダーマップ作成 品質特性ウェブ リモート勉強会 参加者の声 まとめ 勉強会発足の経緯 以前のセーフィーの開発部門は、フロントやサーバー、インフラなどの職能ごとに部署が別れていました。長らく続いていたこの体制ですが、部署の組み替えによる最適な組織構成を模索する中で、昨年末にクライアントとサーバーの両担当エンジニアが所属する新しい部署が誕生しました。これまで個々のサービス開発でコミュニケーションを取っていたエンジニアが一同に介したこの機会に、現状ソフトウェアの課題点を洗い出すブレインストーミングを開催したのが背景にあります。 ▲ KJ法を用いたブレインストーミングを実施（ビール🍻を飲みながら、最後は参加者でピザ🍕を食べました） ブレインストーミングで出てきた課題は、弊社のビジネスの複雑さ、開発部門外とのコミュニケーション、属人化やドキュメント不足と様々です。結果としては、参加者それぞれがこれらの課題を自分ごと化し、自分に出来る改善に取り組むことになりました。私はこれらの課題の長期的な解決策として、 ソフトウェアアーキテクト技術の学習 を挙げ、これが勉強会発足の経緯となります。 ソフトウェアアーキテクト（アーキテクチャ）とは ソフトウェアアーキテクチャと聞いて何を思い浮かべるでしょうか。弊社でヒアリングしたところ、マイクロサービスやUML、ドメイン駆動設計、クリーンアーキテクチャ、CQRSなどを提示した方が多くいました。これはまさしくソフトウェアアーキテクチャで、ソフトウェアを構成する重要な要素です。ではソフトウェアアーキテクチャを設計する ソフトウェアアーキテクトとは、どのような職能なのでしょうか 。 これは私の考えですが、ソフトウェアには「解決したい課題」があり、その課題を「解決する手段」がソフトウェアアーキテクチャだと考えています。ソフトウェアアーキテクトは 「解決したい課題」に向き合い、適切なソフトウェアアーキテクチャを選定して「課題を解決する」職能を持った人物 です。 「解決したい課題」に向き合うためには、考慮すべきことが数多くあります。ソフトウェアに関わるステークホルダーへの理解、ステークホルダーごとのビジネス目標の分析、リスクや技術負債の管理などです。開発した後も継続した改善が必要になるため、教育も含めた開発チームの運営も必要になってきます。 ソフトウェアアーキテクトになるためには ではソフトウェアアーキテクトのスキルを高めるにはどうすれば良いのでしょうか。このスキルの経験値を上げるには、ソフトウェアアーキテクチャを設計する立場として開発に携わることが重要です。さらに、そこから改善を繰り返した「良いソフトウェア開発」を継続することで育まれるものだと考えます。 この勉強会では「課題を解決する、良いソフトウェア開発」について深堀りすることにしました 。 勉強会では、昨年11月にO'Reilly社から出版された「Design It!」を教科書として使用しています。 Design It! ―プログラマーのためのアーキテクティング入門 作者: Michael Keeling オライリージャパン Amazon ▲ 実際に勉強会で利用したスライド この本では、ソフトウェアアーキテクトが行うこととして以下があると説明しています。 エンジニアリングの観点から 問題（品質特性）を定義する システムを分割し、 責務を割り当てる 品質特性間の トレードオフを決定する 技術的負債を管理する チームのアーキテクチャスキルを高める ▲ 実際に勉強会で利用したスライド、いらすとやを多用しています。 上記の内容について工学的なアプローチを行い、「良いソフトウェア開発」を達成する方法が説明されているのがこの本です。ソフトウェア工学の論文を引用し、ソフトウェア開発のベストプラクティスが数多く掲載されています。加えて、このベストプラクティスを実践するための「アクティビティ」と呼ばれる多数のワークショップが紹介されているのがとても良いです。 勉強会では、まずは本の内容を理解することを目指しています。その後、自身がソフトウェアアーキテクトとなり、業務に活かすことが最終的な目標です。 勉強会の様子 では、具体的にどのような勉強会を運営しているかについて少し説明します。勉強会では座学だけでは無く、教科書で紹介されているアクティビティを実践しています。「 ステークホルダーマップ作成 」や、「 品質特性ウェブ 」などを実践し、自らが開発に関わっているサービスについて深堀りしていきました。 ▲ すべての勉強会の様子は録画していて、弊社のサービス上でアーカイブされています。 ステークホルダーマップ作成 「ステークホルダー」は利害関係者と訳されます。このアクティビティの目的はソフトウェアに関わる人物を分析し、その関心事を理解することです。いざワークショップを行ってみると実に様々な関心事を持った関係者がいることがわかります。社内だけでも我々開発を行うエンジニアの他に、営業やカスタマーサポート、工事調整部署などがあり、それぞれ別の関心事を持っています。また、社外におけるステークホルダーはサービスを利用しているエンドユーザーだけではありません。弊社は出資関係にある企業がサービスの代理店である場合もあり、その他にも複数のカメラベンダーとの関係があります。エンドユーザーに関しても、大企業や中小で防犯カメラを導入する目的は変わってきます。 ステークホルダーの関心事を整理することはソフトウェア開発おける非常に重要な要素です 。参加者の中にはエンドユーザーのことしか意識に無かった方もいて、新たな視点を持つことが出来たのではと思いました。 ▲ ステークホルダーマップ作成の様子 品質特性ウェブ ステークホルダーの関心事を分析した後は、品質特性の重要度を可視化する「品質特性ウェブ（Quality Attribute Web）」のアクティビティを行いました。関心事やそこから想定した品質特性シナリオを付箋に書き出し、品質特性のレーダーチャート上に貼っていきます。このアクティビティは、作成したチャートを使って ステークホルダーの関心事から品質特性の中でも何が重要なのかを考えることが目的です 。 ▲ 品質特性ウェブのアクティビティの様子 リモート勉強会 新型コロナウィルス感染拡大の影響でリモートワークとなったため暫くの間勉強会を休止していましたが、先日リモート開催しました。社内勉強会のリモート開催に課題は多いですが、意識高いエンジニアのスキルアップの機会を減らすことの無いよう工夫をして継続していきたいと考えています。 ▲ リモート開催の様子、新規の勉強会参加者のためにこれまでの振り返りを実施 参加者の声 勉強会では、実際に自分たちで開発運用しているサービスを用いてアクティビティを実施しています。「 どのようなステークホルダーが存在するか 」といった話題や、「 紹介されているソフトウェアアーキテクチャが既存のシステムのどこで利用されているか 」などの話題になることもあり、入社から日が浅い参加者にとってはサービスの全体像を理解するのに一役買っています。 また、セーフィーには経験豊富なエンジニアも多く、この教科書で紹介されている内容を感覚的に実践している方もいます。ただ、そういった方々からも、体系的にまとめられ、手法として実践的に学ぶことには価値があると評価を得ています。 まとめ ソフトウェアアーキテクト勉強会の紹介でした。この他にもいくつかの勉強会が開催されています。ネットワークカメラのプラットフォームサービスは、IoT、AI、動画配信など多数の技術に触れることができ、エンジニアリングとしても高い品質を要求されるサービスです。このようなサービスの特性上、弊社のエンジニアは多様な専門性と興味関心を持っている方が多い気がしていて、日常の業務でも勉強になることが多い職場です。 弊社ではこれらの技術に関心があり、成長機会を求める意識の高い方を歓迎します。ご興味のある方のご連絡をお待ちしてます。 open.talentio.com

企画本部の下崎です。 セーフィーはカメラというイメージを持つ方が多いかもしれませんが、カメラ以外にもいろいろなサービスを作って提供しています。本記事では、商品・サービスの紹介もかねて、これまでの商品開発の歴史を書きたいと思います。 クラウドカメラ1号 初めてのカメラ開発 「どこでも簡単」とはいかないビューアー開発 サービス開発 みる、をもっと便利に ユーザーの課題を解決する「Safie Apps」 コンシューマーからエンタープライズへ 1台から数万台まで より多くのカメラを より多くの販路を どこでも簡単 モバイルカメラとの出会い モバイルカメラの商品化 エコシステム 最後に   クラウドカメラ1号 初めてのカメラ開発 2015年5月、クラウドファンディングMakuakeを利用して最初に販売したカメラが、書画カメラで有名なELMO社と共同開発した、QBiC Cloud CC-1です。 このカメラは、ハードウェアおよびOSなどのシステム周りの開発と製造をELMO社、カメラ制御や通信まわりのソフトウェア（デバイスSDK）をセーフィーが提供して作りました。2014年11月に本格的な開発が開始してから約6カ月でサービスインするという大急ぎのスケジュールです。それまでにカメラだけではなく、映像を見るためのアプリやサーバーシステムも準備しなければなりません。 ELMO社との共同開発が決まるまでには、いくつかのカメラメーカーだけではなく、自社ブランドで設計と製造ができるODM企業とも話をしましたが、通常のIoTベンチャーとは異なり、カメラ自体の自社開発・ブランドにはそれほどこだわりませんでした。セーフィーではユーザーの不を解消するサービスの提供を第一に考えているからです。ネットで探せば安いものは数千円の「ハイスペック」なカメラが山のように見つかりますし、メールやテレカンでやり取りをして開発費さえ支払えばカメラを作ってくれる海外のODMメーカーも数多くあります。ただし、自分も電機メーカーにいたから言えるのですが、単にスペックを満たしたものを作ることと高品質な優れた製品を作ることは同じではありません。ソフトウェア開発はできるという（根拠のない）自信がありましたが、当時の私たちにはハードウェアを設計する技術も生産管理のノウハウも無かったので、それらを補い共に製品を作り上げてくれるパートナーを必要としていました。 クラウド技術を求めていたELMO社さんとは、お互いの技術を提供しあう対等な関係で開発をしていただきました。今考えれば社員3人の会社と、2014年の夏に最初に会った時にはまだ会社すらなかったのに、良く共同開発に踏み切ってくれたものです。この幸運に恵まれた出会いがなければセーフィーという会社は無かったかもしれません。 「どこでも簡単」とはいかないビューアー開発 カメラは作る当てがつきましたが、撮影した映像を見るためのビューアーも必要です。「どこでも簡単」を追求したサービスを作ろうと考えていましたので、選択肢はウェブかスマホアプリ。外出中でも簡単にみたいのでスマホの中でもシェアの大きいiOS用アプリをまずは作ることにしました。「どこでも簡単」のこだわりは今でも続いていて、カメラ映像の視聴や設定・操作を始め、画像解析サービスまで、ブラウザもしくはスマホアプリから煩雑なセットアップ無しで利用することができるようにしています。 現在はビジネス用途の割合が多くなりましたが、サービス開始時にはいわゆる見守り系でコンシューマー市場をターゲットにしていたので、マニュアル無しでも直感的に操作できるUIを目指して設計を行いました。そのUIを5年ほど引き継いで機能追加するにつれ、徐々に改良したい点がUI的にも内部実装的にも出てきました。そこで、操作性をさらに高めた新モバイルビューアーの開発に踏み切り、間もなく2020年5月に提供開始する予定です。 当時はエンジニアが3人しかいなかったので、機能仕様と主な画面のワイヤーフレームを作成したらアプリの実装はツテのあった開発会社さんの力も借りました。ただどうしても上手くいかなかったのがBluetoothの実装でした。BLEのアドバタイズメントを利用してカメラを検索して接続、アプリから設定するという設計はできたのに、肝心のデータのやり取りがどうしてもできない。あるのはBluetoothチップの仕様書だけ。しかもあまりメジャーなものでは無かったので、カメラメーカー含めて実際に使ったことのある人が誰もいないのには困りました。ネットのサンプルを参考にしても上手くいかないので、Bluetoothの電波をキャプチャして通信内容を表示できるプロトコルアナライザーまで使い、メーカーの人といろいろやってみるのですが、全然データのやり取りができないのです。CC-1はWi-Fiしか通信インターフェイスが無いので、その設定をしないと何もできません。最初はそのうちできるだろうと考えていたのですが、そうこうしているうちにデモを見せるプレス発表が翌週になってしまいました。そのギリギリの時に、同じBluetoothチップを使っている会社を何とか見つけ、頼み込んで使い方を教えてもらうことができました（ちなみにそういう時に限って新幹線を乗り過ごし、さらに乗ったタクシーが道を間違えて打ち合わせに遅刻しました...）。 トラブルもありましたが、クラウドファンディングではCC-1を500台以上を販売することができ、何とか満足のいくスタートを切ることができました。 サービス開発 みる、をもっと便利に iOSアプリが完成したので、直ぐにその設計を元にAndroidとウェブアプリに横展開しました。これで撮る、みる、ためるという基本的な機能は実現できましたが、「賢くなるカメラ」と銘打ってサービスを提供していることもあって、ユーザーからは様々な要望が寄せられて来ます。その中の一つが、映像を公開して大勢の人に見せたいというものでした。そこでカメラで撮影したライブ映像とYouTube Liveの連携サービスが生れました。最初はYouTubeやFacebookなどいくつかのライブ配信サービスとの連携を試してみて、技術的には実現可能なことが分かっていましたが、どれぐらいのビジネスになるかはっきりしないこともあって正式なサービス提供にまでは至っていませんでした。 そんな状況の転機になったのが、2016年8月に九州朝日放送と組んで実施した、KBCオーガスタゴルフトーナメントの定点カメラ映像のライブ配信でした。石川遼選手などが参戦するメジャーな大会なので当然テレビ中継されるですが、打撃練習場や選手がティーショットをするまでの準備など、ゴルフをやっている方にとってはテレビ放送されないシーンでも面白いところがいっぱいあるそうです。たまたまセーフィーのカメラでライブ配信もできるんですよ、と紹介したことがきっかけで、大きなイベントで利用していただき、その後はイベント配信だけではなく、河川監視など公共での利用にまで活用の幅が広がってきています。 Safie Culture の一つに「迷った時はやってみる」があるのですが、ユーザーの声に耳を傾けて技術の可能性にかけたエンジニアと、それを素早くかつタイムリーに届けて形にした営業の、まさにやってみたことでつかんだ成功例でした。この開発の姿勢は今でも大切にしていることの一つで、人数カウントやPOSレジ連携、Safie Visitorsなど顔認識サービス、といった新サービスを生み出す原動力にもなっています。 ユーザーの課題を解決する「Safie Apps」 セーフィーは多くの飲食・小売店でご利用いただいていますが、トラブルや不正が発生しやすいレジを撮影していることが多いです。カメラの設置が抑止力となって何も起きないのが一番ですが、トラブル発生時には映像を探して確認するために、店長さんは貴重な時間を使うことになります。セーフィーでは過去の映像を簡単に再生してみることができますが、正確な時間が分からない場合には特定のシーンを探すのは結構大変です。そのようなお悩みを解決するために生まれたのが「 POSレジ連携 」です。 POSレジの売上データ（ジャーナルと呼ばれます）と映像を結び付けることで、映像の検索性が飛躍的に高まります。POSシステムのインターフェースやジャーナルの仕様は規格化されていないため、連携させるためにどうしてもある程度の個別対応が発生してしまうのですが、対応するPOSシステムの数を少しづつ増やしていっています。 また、POSレジ連携以外にも、顔認識を利用した「 Safie Visitors 」のようなAIや画像解析の技術を活用し、映像の検索性を高めるサービスの開発を積極的に行っています。 サービスそのものではないのですが、ユーザーの細かいニーズにも応えると同時に、新サービスをより早く開発できるようにしたいという思いで開発したのが「ダッシュボード」です。法人向けのサービスを行っていて、ありがたいことに日常業務に組み込んでご利用いただいていると、業務に合わせてカスタマイズしたいという要望をお聞きすることがあります。例えば、エリアマネージャーが自分の担当店舗ごとに映像と人数カウントの入出店者数を確認するような場合です。もちろん、カメラ映像をひとつずつ確認することはできますが、それでは日常業務として作業効率がよくありません。「ダッシュボード」によって、ユーザー自身で店舗ごとの映像と人数カウントグラフをまとめた画面を作成する、といったことが可能になりました。 最初は映像をみる機能の拡張から始まったサービス開発ですが、現在ではもう一歩進んでユーザーの課題そのものを解決するソリューションを開発し「Safie Apps」として提供しています。 コンシューマーからエンタープライズへ 1台から数万台まで 2017年にCC-1の後継機種CC-2の提供開始に合わせて、自社ECサイトをオープンしました。それまでもAmazonなどでカメラを購入することはできたのですが、カメラが到着したら設定作業を行う必要がありました。自社ECサイト経由で購入していただくことで、出荷時に必要な設定を行ったうえでお届けすることができるようになり、さらに置くだけ簡単度合いが高くなりました。 このころになると、数十台～数百台以上のカメラを導入する所謂エンタープライズ領域のユーザーが出てきました。各ビューアーアプリはカメラが1台でも数百、数千台でも利用していただけますが、カメラだけではなく利用するユーザーや設置拠点数も多くなるため、どうしても管理の手間がかかります。例えば、カメラを新しい拠点に導入したら、アカウントの追加が必要になりますし、異動や退職が発生したらアカウントの変更をしなければなりません。このような管理作業をより便利にしていただくために開発したのが「Enterprise Tool」です。 最初はカメラ数が少なかったユーザーも、追加していくうちに気が付くと結構な数をお使いいただいていることがあります。エンタープライズと呼ばれるような大企業のみならず、より多くの方にお使いいただくためにも、エンタープライズツールを「Safie Manager」としてリニューアルし、更に使いやすくしています。 より多くのカメラを ユーザーが増えると、それに伴ってカメラの利用用途や設置環境も様々になります。Wi-Fi接続のCC-1カメラの後には有線LAN接続で屋外対応のCP-1を開発しましたが、全ての用途に対応するにはまだまだ機種が足りません。カメラといっても形状や機能で、ドーム型、バレット型、PTZ、パノラマなど様々な種類があるのですが、全部開発するほどのリソースはありません。そこで、既に販売されている汎用ネットワークカメラをセーフィーのサービスで使えるようにするために「ゲートウェイ」を作りました。ネットワークカメラは映像を取得したり制御したりするためにRTSPやONVIFといった規格化されたインターフェースを持っていることが多いです。通常はカメラと一緒に設置したレコーダーやサーバーがこのインターフェースを使って映像を取得して保存するのですが、ゲートウェイは取得映像をセーフィーのサーバーに暗号化して転送します。セーフィーカメラと同様にサーバーから制御することもできるので、ユーザーからみると同じように使うことができます。これによって、カメラの種類が増えたのみならず、既に設置してあるカメラを利用することもできるようになりました。 このゲートウェイですが、最初は製造委託するほどのボリュームが無かったので、自分たちで作っていました。 シングルボードコンピュータを仕入れてファームウェアを焼き込みます。丁度いいケースがなかったので、町工場の板金屋さんに手書きの図面を持ち込んで作ってもらい、その中にボードを組み込みました。販売数が増えて、性能向上もかねた新モデルを製造を委託するようになるまでは、大口の発注が入ると、嬉しい反面で納期に間に合わせるための製造作業が忙しくなっていました。 より多くの販路を ゲートウェイで利用できるカメラは増えたのですが、汎用のインターフェースを使うので、設定の簡単さや機能の追加には限界があることも分かってきました。その時に見つけたのが、ネットワークカメラメーカーの Axis Communications 社のACAPやVivotek社のVADPといったアプリケーションプラットフォーム機能でした。それらを利用すると様々なモデルのカメラに自分で開発したアプリケーションをインストールして動かすことができるので、対応機種を大幅に増やすことができそうです。狙いは当たり、現在ではセーフィーに対応したカメラは数百機種にまで増えました。 実は Axis Communications 社のカメラに対応したのにはもう一つの理由がありました。販路を増やしたかったのです。新規創業からしばらくは知名度も自社の販売力も低く、カメラを作って一緒にビジネスをやろうというメーカーも、知らないスタートアップが作ったカメラを扱おうという販売会社もほとんどありませんでした。その点、カメラのアプリケーションプラットフォームを利用すると市販のカメラが使えるのでスモールスタートが可能です。またマーケットシェアもあるのですでに販売している会社も多いです。最初はカメラを仕入れるためのアカウントをディストリビューターに作ることができず、出資を受けていたソネット（現在のソニーネットワークコミュニケーションズ）さんに紹介をお願いして何とかなったぐらいでしたが、現在では Axis Communications と同じグループ会社（2015年に当時世界最大手だった Axis Communications をキヤノンが買収しました）のキヤノンマーケティングジャパンさんを含め、100社以上の販売パートナーにセーフィーを扱っていただけるようになりました。 どこでも簡単 モバイルカメラとの出会い 「どこでも簡単」を商品開発ではひとつのキーワードにしています。スマホやタブレットを使えばどこでも見るのは簡単ですが、撮影はやはり固定したカメラで行うしかありませんでした。そんな時に偶然出会ったのが、お客さんが自作したモバイルカメラ、「 ボックス型CC-1カメラ 」です。 きっかけはCC-1の映像が途切れるという問い合わせでした。場所は工事現場だということなのできっとWi-Fi環境が良くないのだろうと行ってみると、小さな箱にカメラとモバイルWi-Fiか何かのルーターが詰め込んであります。お客さん自らがこんなソリューションを作っていたということは大きな衝撃でした。不具合の原因は通信容量の上限に達して帯域制限がかかったことだとすぐに分かったのですが、帯域制限という問題自体の解決は簡単ではありません。映像撮影時のビットレートは通信状況に合わせて自動制御されるので、通信状態が悪くても映像を視聴することはできるのですが、どうしても画質はいまいちになります。根本原因そのものを解決するしかありません。代表の佐渡島はインターネットプロバイダーの ソニーネットワークコミュニケーションズ出身だったこともあって、カメラが主に使うインターネットのアップストリーム帯域には空きがありそうだと思っていました。そこでソニーネットワークコミュニケーションズと交渉し、アップストリームだけを帯域制限なく利用できるカメラ専用のLTE通信契約を作ってもらったのです。 モバイルカメラの商品化 通信帯域の問題が解決したので、「ボックス型CC-1カメラ」を組み立てているところを紹介してもらい、セーフィーでも商品として扱うことにしました。インターネット回線のない工事現場や駐車場を始め、災害発生時には電源にさすだけで動作するという特徴を活かし、状況を素早くかつ継続的に把握するために利用されました。ただ、使っていたカメラのCC-1は屋外向けではないうえに、小さな箱に詰め込んであるので、夏場に温度が高くなると動かなくなることがあるという悩みがあったのです。 そんな時に、夜間でも撮影したものが欲しいという依頼が来ました。丁度 Axis Communications 製カメラ向けファームウェアのプロトタイプが出来上がっていたので、屋外用で暗所撮影に強いモデルを選び、LTEルーターと組み合わせたものを使ってもらうことにしました。稼働直後に発生した不具合をリモートから解析してソフトウェアアップデートすると、安定して動きます。晴れた日もこれで怖くなくなりましたw。画質についても評判は上々で、追加発注ももらったので、これを新ボックス型カメラにすることを考え始めていました。そんなところにあったのが、サカキコーポレーションさんからのお声がけでした。お話を聞くと、太陽光発電所向けにセンサーとそのデータをモバイル回線経由で収集する機材を売っているとのこと。カメラも設置したいという要望が多いので、ボックス型CC-1カメラみたいなものを何か一緒に作れないか、というご相談でした。 新ボックス型カメラにもルーターのリモート制御ができないという課題がありました。セーフィー対応のデバイスはリモートから状態の取得や制御、ソフトウェアアップデートを行うことができるようになっています。それによって、安定した運用や機能追加による「賢くなるカメラ」を実現しているのですが、それが市販のルーターではできません。それらの機能に加えて、屋外対応やPoE(Power over Ethernet)といったカメラ設置のための機能も兼ね備えたものがサカキコーポレーションの全天候型防水カメラルーター「SCR1800」とそれを利用したLTE搭載クラウド型防犯カメラ「 Safie Go 」シリーズです。 固定インターネット回線がないところでも電源さえあれば簡単に設置してセーフィーを利用できることによって、工事現場など数多くの場所に設置いただき、防犯や現場を遠隔地から確認することによる業務効率化などに活用いただいています。Safie Goに続いては、小型化とバッテリー駆動により身につけて持ち歩くことができ、見る・聞くに加えてWebRTCによる双方向のコミュニケーションも兼ね備えた「 Safie Pocket 」シリーズへと、さらなるどこでも簡単を追求をした開発を続けています。 また最近では、業務効率化に加えて、 新型コロナウィルス対策のために現場での対面検査を避ける必要がでてきました 。リモートから映像を用いてリアルタイムに工事の状況確認と承認を行う「遠隔臨場」が要請されるにつれて、「Safie Go」「Safie Pocket」共に改めて注目されています。 エコシステム セーフィーでは「映像から未来をつくる」をビジョンに掲げ、ユーザーの課題を解決する商品を作り続けて来ました。カメラの映像を見るという基本的なサービスから始まって、ユーザーが見る必要を無くす画像解析やAIの技術を取り入れたサービス、時間と場所の制約を超えたコミュニケーションを可能にするサービスへと幅を広げています。我々は最新の技術を取り入れたサービスを開発して提供するのはもちろんのこと、映像のプラットフォーマーとして自分たちの技術をさらに活用してもらう方法を提供していきたいと考えています。ご紹介したカメラの共同開発に加えて、テックパートナーへのAPI公開やアプリケーションSDKの提供により、セーフィーの映像プラットフォームとテックパートナーの技術の相乗効果による新サービスが生み出され、より多くのユーザーの課題を解決する。それによって強化されたプラットフォームがさらなる新サービス開発の原動力になる。そのようなセーフィーを中心としたエコシステムを構築していくための活動も開始しています。 もっと手軽で便利に防犯カメラを使えるようにしたい、という小さな思いから3人で始めたセーフィーのサービスは、ユーザー様やパートナー企業様を始めとした多くの方々に支えられて、プラットフォームに発展し、さらに多くの人や技術を巻き込んで成長しています。 これからも歩みを止めることなく新しい商品をどんどん提供していきますので、お楽しみに！ 最後に セーフィーでは新しい商品を一緒につくっていただけるエンジニアを募集しています！   open.talentio.com  

AWS IoT@Loftイベントでセーフィー の動画制御システムについて登壇しました。 ※セーフィーはクラウド録画サービス「Safie（セーフィー）」を運営しています。   セーフィーでCTOをさせて頂いている森本です。   先日、AWSさん主催の IoT@Loftイベント第9回 にて登壇させて頂きました。 イベントテーマが「IoTにおけるカメラ・動画の扱い方」だったので、まさに弊社サービスにピッタリのテーマという事でありがたく参加いたしました。     当日は残念ながら昨今の情勢を踏まえオンライン配信での開催でしたが、150名を超える方々にご参加頂き、IoT@Loftイベントでも最大規模になったいう事でありがたい限りでした。 尚、イベントで配信に利用されたシステムはもちろんAmazon Chimeでした。利用させて頂くのは初めてだったのですが、特に問題なくスムーズに利用する事が出来たとの所感です。   当日のスピーカーは私含め計2名で、ソラコムさん、セーフィーと登壇させて頂いた後、AWSさんよりIoTシステムを容易に構築可能なマネージドサービスについてのご紹介がありました。 AWSさんが当日のレポートを以下のブログにて公開されていますので、こちらをご覧頂ければそれぞれの発表内容が良く分かります（AWSさん、ありがとうございます）。 https://aws.amazon.com/jp/blogs/news/event-report-iot-at-loft-9/   上記ブログでもご紹介頂いていますが、セーフィーの発表では実際にSafieサービスで利用されている動画制御システムについてお話いたしました。   今でこそAWSさんのAmazon Kinesis Video Streamsがリリースされていますが、6年程以前にそういったサービスが存在しないなか、どういったビジネス要求がありそれに対応するためにどのようなシステムを作り上げてきたかについて記載しています。ご興味がある方は是非目を通して頂けますと幸いです。   Safie動画制御システム全体構成 尚、上記が弊社の動画制御システムの全体構成図となります。 以下のような柔軟な機能をサポートする事により、Amazon Kinesis Video Streamsと比べても遜色ないシステムを構築し、それを実サービスに利用できていると自負しております。 HLS/WebRTCのハイブリッドサーバー配信により1秒以内の遅延を実現すると共に、環境要因などでWebRTCが利用できない場合はHLSでの自動フォールバック配信をサポート YouTube Liveと言った大規模配信システムへのRTMPパブリッシング、画像解析系サービスへのRTP/JPEGでの送信など、柔軟な配信制御が可能 上記全てをできる限りトランスコードを行わず、低コンピューティングリソースで実現   2020年3月時点で8万台を超えるカメラが出荷されており、上記動画制御システムを通して約6PB（ペタバイト）のデータが弊社システム上に保管され、配信や解析に利用されています。   最後に 今回はAWSイベント登壇レポートを公開させて頂きました。 尚、弊社としては今後画像解析システムとの連携を更に強化していくべく開発業務に取り組んでいますが、まだまだエンジニアさんが足りていない状況です。ご興味がある方はお気軽にご連絡頂けますと幸いです。   open.talentio.com

今回はSafie（セーフィー）サービスのシステム構成について概要説明させて頂きます。 ※セーフィーはクラウド録画サービス「Safie」を運営しています。 セーフィーでCTOをさせて頂いている森本です。 前回はSafieサービスのシステム構成について簡単に説明しましたが、今回はその構成要素である Safie対応カメラについて少し踏み込んで説明いたします。 Safie対応カメラ セーフィーは現時点では自社でカメラの開発は行なっていません。 理由は大きく2点あります。 ベンチャーにとってハードウェアを自前で開発する事は極めてハイリスクである。 私は過去複数のハードウェアプロダクト開発に関わってきました。 その中で何度も体験して来た事ですが、ソフトウェアであれば問題があった場合にはアップデートという手段が取れます（リモートアップデートに対応していなければ、ハードウェアが設置されている場所まで行かないといけないなど、対応状況により手間は大きく異なりますが）。 一方ハードウェアの場合は簡単に解決出来ず作り直しが必要になってしまう事も多々あります。 作り直しには時間も、お金もかかりますので体力がないベンチャーにとっては大きなダメージとなってしまう事もあり得ます。 高品質なIPカメラが既に数多く存在する。 世界中はもとより日本にも一定レベルの品質のハードウェアを開発している会社が多数存在します。 それらをSafieサービスで利用できるのであれば、わざわざリスクを犯す必要はありません。 以上よりセーフィーではできる限り自社でハードウェアを開発せず既存商品を使用するというスタンスを取っています。 ただし、一般的なIPカメラをそのまま使った場合以下のようなセキュリティ上の問題が存在する事がよく知られています。 パスワードがデフォルト設定のままとなっている事がある。 一般的なIPカメラは出荷時にデフォルトパスワードが設定されており、IDやパスワード変更がエンドユーザーの手に委ねられています。その為適切に設定されていない場合には誰でもアクセス可能となっている事があります。 実際に数年前には適切にパスワードが設定されていない世界中のカメラがインターネット上に晒されて誰でも見れる状態となっていました。 外部向けにポートが開放されており、攻撃される可能性がある。 一般的なIPカメラはエンドユーザーが直接アクセスするような仕組みとなっており、その為のポートが開放されています。 適切にパスワードが設定されていた場合でも開放されたポートは攻撃対象となり得、例えばIPカメラのソフトウェアに脆弱性が潜んでいた場合に、内部に侵入されるリスクへと繋がります。 前述の通りセーフィーではハードウェアの開発は行なっていませんが、一般的なIPカメラを自社サービスに対応させる為、専用のファームウェアを開発しハードウェアベンダーに公開しています。 専用ファームウェアには同時に上記の問題を解決する為、独自の仕組みを搭載しています。 Safie ファームウェア Safieファームウェアを組み込む事により一般的なIPカメラがSafieサービスで利用可能となります。 このカメラは一般的なIPカメラとは異なる以下のような特徴を有します。 ※Safieファームウェアを搭載したカメラを「Safie対応カメラ」と称します。   ネットワークのクライアントデバイスとして駆動する。 一般的なIPカメラと異なり、Safie対応カメラではユーザーからの直接アクセスは基本的に受け付けません。 ユーザーはクラウドサーバーを経由してアクセスする事のみが可能となります。 このため、Safie対応カメラでは外部に対しポートを開放してアクセスを受け入れる必要がありません。 エンドユーザーによる設定不要。 ID/パスワードもSafieファームウェアが独自に設定する為、デフォルト設定からの変更漏れも一切発生しません。 合わせて通信経路も確実に暗号化を実施する為、通信を傍受された場合にもデータを盗み見られる事はありません。 この為、Safie対応カメラは一般的なIPカメラと比較し、セキュリティ面のアドバンテージも大きくなっています。   また、Safieファームウェアはカメラメーカーが組み込みやすいよう共通レイヤとポーティングレイヤを分離して提供しています。異なるハードウェア上でもインターフェースを適切につなぎ合わせれば容易にSafie対応カメラを開発することができ、幅広いタイプのIPカメラで利用する事が可能となっています。 ※IPカメラによっては対応不可なものも存在いたします。   これにより、現状では数100種類を超えるIPカメラをSafieサービスで利用する事が出来ます。 現在広く使われるようになったSafieサービスですが、その広がりの 一端を担う 重要な構成要素となっています。 最後に 第3回目という事で、Safieサービスの構成要素について説明させて頂きました。 引き続きサーバーシステムなど他の要素についても説明していく予定ですので、よろしくお願いいたします。        セーフィーでは一緒に働いてくれるエンジニアを募集しています！   open.talentio.com

今回はSafie（セーフィー）サービスのシステム構成について概要説明させて頂きます。 ※セーフィーはクラウド録画サービス「Safie」を運営しています。 セーフィーでCTOをさせて頂いている森本です。 前回は会社の説明などご挨拶的な内容で終わってしまいましたので、今回はSafie（セーフィー）サービスのシステム構成について少し説明をさせて頂きたいと思います。 Safieのサービスは、ざっくり言うとSafie対応カメラ、Safieクラウドサーバー、Safieアプリケーションから構成されています。 それぞれについては以降で少しだけ詳しく説明しますが、技術領域としてはハードウェア、サーバー、インフラ、アプリケーション、動画配信、データ解析といった要素を全て含みます。この為一般的なWebサービスに比べて関わる技術要素のレンジが極めて広くなっているのが大きな特徴だと思っています。 当然ですがそれらの開発、運用を行う為様々な技術バックグラウンドのエンジニアが在籍し、お互いに意見を交換しながら日々の開発活動を行なっています。 また、プラットフォームと称している理由にも繋がりますが、他社サービスとの連携も行う事を前提としてシステムの開発を行なっています。 セーフィー対応カメラ   Safieクラウドサーバーに接続可能なカメラの事を指します。 弊社では基本的には自社でカメラは開発をしていません。 その代わりカメラ内で駆動するソフトウェアモジュールを開発し、カメラベンダーに配布しています。 このソフトウェアモジュールはネットワーク制御、セキュリティ管理、動画制御、カメラ制御などSafieサービスに必要とされる全ての要素を備えており、当該モジュールを組み込むだけでSafieサービスにサービスインする事が可能となっています。 主としてC、C++が利用されており、一部Pythonなどが使用されることもあります。 セーフィークラウドサーバー   ここでは詳細は省きますが、PaaS上に構築され、全カメラの制御、ユーザー管理、動画配信、画像解析、データ連携などを行なっています。 一般的なメディア系ライブラリ、画像解析系ライブラリがネイティブである事が多いため、親和性も考慮し大部分にPythonを採用しています。 特性上24時間365日サービスを止める事は出来ないので、無停止でのメンテナンス、機能追加にも対応しています。   執筆時点で7万台を超えるカメラを出荷、500台を超えるサーバーが常時稼働しており、約6PB（ペタバイト）のデータが弊社プラットフォーム上に保管されています。 セーフィービューアー セーフィー デモ画面（PCのみ） iOS App Store Android Google Play Safieのサービスが利用できるエンドユーザー向けのアプリケーションです。 WebアプリケーションはAngularを、MobileアプリケーションはSwift、Kotlinを採用（開発中含めて）しています。 今の所、カメラの制御、閲覧などの基本機能が利用できる標準アプリケーションに加え、例えば顔認証サービス専用アプリケーションなどを提供しています。 今後は各種サービスの追加に合わせて専用アプリケーションやセーフィー 以外の開発者がアプリケーションを開発できるようなSDKも拡充して行きます。 最後に 第二回と言うことでSafieサービスの全体像について説明させて頂きました。 次回からは各要素の詳細なお話、個別の技術的なお話など中心にご紹介させて頂こうと考えていますので、引き続きよろしくお願いいたします。 セーフィーでは一緒に働いてくれるエンジニアを募集しています！ open.talentio.com

こんにちは、セーフィーでCTOをさせて頂いている森本です。 2014年に3人で創業したセーフィーもお陰様でビジネス的にも会社的にも成長が実感できるようになってきた今日この頃ですが、今更ながら技術ブログを始めていきたいと思っています。 何をやっている会社か？ 上記のように書き出しましたが、そもそもどういった事をやっている会社か説明が必要ですよね。 一言で言うと動画のクラウド録画、配信プラットフォームを開発・提供している会社です。 といってもよく分からないと思いますので、詳細情報は以下のリンクをご覧ください。 safie.link カメラの録画、配信だけでなく、動画とメタ情報の紐付けや、例えば人数カウント、顔認証など画像解析関連のサービスを展開しています。 何を目指しているのか？ 弊社は「映像から未来をつくる」をビジョンとして掲げています。 この「未来をつくる」には色々な意味を込めています。例えば分かり易いところでは多くの人が見たいことや知りたいことを簡単に分かるようにする事です。それによって多くの人が抱える課題を解決する事を目指しています。 我々は全社員一丸となって、ビジョンの実現に向けて日々活動を行なっています。 なぜ技術ブログを始めるか？ 繰り返しになりますが、我々は全社として上記に取り組んでおり、弊社の技術、エンジニアリングチームはその実現のための最重要要素の一つとなります。 そんな中、エンジニアさんの数が足りていない事、及びその要因の一つでもありますがセーフィーの知名度が低い事に課題を感じています。 弊社サービスは当然のことながら防犯用途でも広く使って頂いていており、ホームページにもその事は大々的に記載しています。 ただ、実態としてはそれ以外の用途でも幅広く使われており、関わる技術領域的にも極めて広いのですが、外部のエンジニアさん目線から見ると「防犯カメラサービスをやっている会社」と言うところで終わってしまっているのかな、と感じる事が多々あります。 ブログを書く目的は、広くみなさんに弊社がどういった事をやっているか知っていただく事と、あわよくばそれが先々の採用に繋がる事にあります。 最後に まずは初回という事もありますが、技術ブログと言う割には会社説明といった内容で終わってしまいましたので、次回からは各要素の詳細なお話、個別の技術的なお話など中心にご紹介させて頂こうと考えています。 引き続きよろしくお願いいたします。     セーフィーでは一緒に働いてくれるエンジニアを募集しています！   open.talentio.com