• このエントリーをはてなブックマークに追加
■インタビュー企業

株式会社onetap
2015年に会社を設立し、WEBサービスを中心に複数の事業をリリース・売却。
2019年末より多要素認証エンジンの「LOCKED」を開始。
新型コロナウィルス感染症によるテレワークの影響もあり、問い合わせは急増中。
LOCKEDを通じてゼロトラストネットワークを企業に実装することで、企業の働き方を変える事を目指している。
■インタビュイー
代表取締役 武田 義基 様

現在募集している職種と仕事内容について

現在エンジニアリングに関わるメンバーとしては、大きく分けて4つの職種を募集しています。フロントエンドエンジニア、バックエンドエンジニア、ネットワークエンジニア及びインフラエンジニアです。

最初の2つの職種については、弊社の運営している「LOCKED」のアプリケーション自体の開発が主な業務内容となります。

その他ネットワークエンジニアについては、お客様の社内ネットワークに対して、どのようにLOCKEDをインテグレーションしていくのかという構成を考えたり、実際にインテグレーションのお手伝いしたりと、LOCKEDを通じて生産性を高める準備をする部分が主な業務となります。また、その他にも今後開発していくネットワーク絡みの機能開発にも関わって頂く事になります。

そして最後にインフラエンジニアに関して言うと、弊社ではAWSを中心にインフラを構成しているのですが、それなりに人数の多い企業様にもご利用頂いているので、非常に大きな負荷がかかるアプリケーションになっています。そういったインフラ部分で、高負荷を適切に対処できるような環境を構築していく事、またDevOpsに関する生産性を高めていく事が主な業務になってきます。

4つ職種を募集している背景について

サーバー管理LOCKEDのアプリケーション自体はNuxt.jsやRailsなど、比較的モダンな構成で開発してはいるのですが、インテグレーション先のお客様の環境を考えると、必ずしもモダンなものであるとは限りません。なので、そのような比較的古い環境で構築されたソフトウェア・インフラ環境に対しても対応できるような知見を有する方を広く募集している所です。

また明らかに、新型コロナウイルスの影響がある以前よりもテレワークという文脈でのご相談は増えてきている状況で、特に緊急事態宣言が終わった辺りから「ゼロトラストネットワーク」に社内のネットワーク環境を移行するというような依頼が増えてきています。

そして、そのようなご依頼を頂いた企業様1社1社に対して、ニーズや背景を汲み取りながらそのご要望に答えられるよう、お取り組みさせていただいているという状況です。

テレワークを推進する事業ビジョン

サービスを提供する部分ですと、ゼロトラストネットワークをお客様の社内ネットワークに対して実現し、結果として「働き方改革」を目指せる環境を構築するお手伝いができればと考えています。

ご相談いただく企業様の特徴としては、20年前くらいの環境を前提として作られた社内ネットワークをベースとしていて、それを無理やり拡張させて業務を進めているような企業様がすごく多いです。世の中ではインターネットを使っての業務が当たり前になっていて、クラウドサービスが普及し、端末の種類もPCだけではなくスマートフォンを持っていたり、さらにはテレワークの要求が出てきたりと、変化の速度が加速度的に高まりながら複雑度もより一層増してきている状況です。

このような背景もあり社内ネットワークから働くのがベストではなくなっているケースも増えてきているので、そんな激しい変化にも対応できるゼロトラストネットワークへと移行するサポートをさせて頂いております。

他社とは違う柔軟性の高いサービス

他社との違いという点については、分かりやすい点でいくとざっくり2点あります。

一つは多要素認証の拡張性やカスタマイズ性が、他ソフトウェアとは異なり非常に柔軟になっている点です。他のID管理のサービスは、拠点以外からのアクセスがあった場合、ある程度画一的にアクセス制御をしているのですが、我々の場合はより細かく実務に沿った形で判定を行っています。

例えば部署や肩書であったり、アクセス元は海外の位置情報になっていないかなどは勿論ですが、その人が過去どのような端末からどのようにアクセスしたかの履歴を元に2段階認証を要求する「リスクベース認証」という認証方法も活用しています。これにより、使い勝手や業務効率を保ったままセキュリティの強化が出来るという事です。

そしてもう一つは、オンプレミスの業務用アプリケーションにも簡単に連携できるという事です。クラウドサービスに対してIDを統合するようなソリューションを提供されている企業様も一定数いらっしゃるのですが、全てがクラウドサービスだけで業務が回っている企業様というのはやはりすごく少ないです。

実態として、20年前とか30年前に作ったインフラをそのまま使っているような企業様もいるので、所謂社内ネットワークやオンプレミスのサーバー、アプリケーションの構成に対してインテグレーションでき、さらには一部利用しているクラウドサービス等にも跨ってIDを統合し、より柔軟性の高い環境でのセキュリティを保つことができるというところがもう一つの大きな特徴になります。

ゼロトラストとは?

元々ゼロトラストの対局に位置するものとして「境界型セキュリティ」(ペリメタモデル)といわれるセキュリティモデルがあります。これは社内ネットワークからのアクセスであれば「特権的に信頼できる」として扱うという考え方です。そして逆に言うと、社内のネットワークにさえアクセス出来てしまえば、誰でも業務用の情報などの機密情報にアクセス出来てしまうという事を意味します。

これは物理的なオフィス環境の外からアクセスすることが考慮されていない時代に考案されたモデルですし、内部犯行のように中にいる人が悪意を持ったときに対抗出来ません。そういった背景を踏まえ、ゼロトラストのモデルが考案されています。ゼロトラストは境界型セキュリティとは反対で「どんな環境にいても基本的に信頼できない」という前提で、アクセスが発生する度にその信頼性をきちんと検証しましょうというモデルになります。

明らかにゼロトラストの方が安全で合理的なセキュリティモデルですが、多くの企業の現状としては境界型セキュリティで構築された環境となっています。

しかし、これでは業務環境の柔軟性を保つことが出来ません。例えばテレワークの際などには、古くから構築した社内ネットワークを拡張するようにVPNを社内ネットワークから引いています。そして、VPNを経由している接続であれば安全なものとして特権的な信頼を付与する形で業務を行っている企業が非常に多いです。

ただ接続者が増えると回線が遅くなるのは当然問題として発生してきていますし、VPNは境界型セキュリティ故に一度社内ネットワーク内に入られてしまうと急激にリスクが高まってしまうという状況です。

このような背景を踏まえ、テレワークをトリガーにゼロトラストの注目度が高まっている状況です

プロダクトのチーム体制や組織体制について

現状はすごくスモールチームで、10名程度の規模感でやっています。私自身も元々エンジニアで、LOCKEDのα版くらいまではコードを書いて開発をしていたのですが、現状はマーケティングや営業などのビジネスサイドをメインに担当しています。

全体的なチームメンバーという視点で見ると、ソフトウェアの開発が業務の非常に大きな範囲を占めるのでエンジニアがほとんどです。具体的にはビジネスサイドが1人、デザイナー1人、それ以外は全員エンジニアという構成になっています。

現在働いているエンジニアの働き方について

thumbnail働き方という観点では、特に場所などは制限しておりません。成果や約束が守れるのであれば、柔軟な環境で生産性高く働いてもらう事を意識して日々業務を行っています。逆に言うと、お互いに対して信頼して仕事を任せたており、その分任されたお客様やチームへの約束は必ず守るという事を徹底しています。

例えばリリースサイクルを2週間ごとに決めたのであれば、2週間の間でもちろん進捗などの確認はしますけど、催促をするようなこと殆どありません。2週間できちんと終わることを信じ、信頼して任せています

勿論終わらなかった時のバックアッププラン等はありますが、それでもリリースサイクルが遅れたことは一度もありません。

より多くの人にLOCKEDを通じて生産性高く働いてもらうことを考えると、信頼を積み上げていく事が非常に重要だと考えています。お客様から機能や改善の要望があった場合、その要望に応える事が決まれば、具体的に期日を明言した上できちんとその期日を守っていく。当然といえば当然なのですが、お客様との約束を守る。期日を確実に守るというところは特徴や働き方として一つあると思います。

プロダクトに関わる開発体制

プラス記号の仮想を持っている手は、コピースペースで肯定的なもの(特典、個人的な開発、ソーシャルネットワーク、健康保険など)を提供することを意味しますプロダクトに関して言うと開発の過程で、エンジニアと自分の責務を明確に分けています。お客様先へ出向くのが私なので「現状の製品だとこの部分が機能として不足していそう」「このようなユースケースで使い勝手が悪そう」などといった、実際のお客様の声を元に改善案をざっくりエンジニアに投げ掛けています。

なので「その課題をどういう風にすれば解決できるのか?」という部分は、かなり粒度が荒い段階からエンジニアと相談し、実現方法を見つけながら開発を進めています。一応私も元々はエンジニアなので、ざっくりとした解決手段をオプションとして提示はしますが、完全にゼロベースで「どうやって実現するのか」というのは、私以外のメンバーの方が優れていますので、ある程度最初から任せています。

あともう一つ特徴としてあるのは、開発部分はローテーションのような形で回しています。「ここはこの人が良さそう」とか「ここは誰がやる」というのには、あまりこだわらずに開発を進めています。

現状、そこまでコードベースが多いわけではないのですが、内部のロジックが複雑になってきたり、設計自体が途中で大きく変わるケースもあります。実際にそういうことも以前ありました。

そんな時に、どうしても俗人化しがちな知見をローテーションで回すことで分散し、各々の理解度を高め、個々のエンジニアもより幅広い知見を得られるという意図があり、業務をローテーションする形で進めています。

勿論スキルセットや期日、最終的な要件によって毎回ローテーションするかは都度相談していますが、ソフトウェアの仕様や要求であるWhatに対して、Howに大きな責務を追って開発できる点はエンジニアにとって自由度高く開発が出来る環境になっているかなと思います。

社風や制度について

働く時間帯については、所謂フレックスを採用しています。コアタイムはありますが、その決まりの中で自由に開発してもらっています。場所や時間については、生産性が高まる事を前提にある程度柔軟にしています。

他にも関連する組織体制の面でいうと、2週間に1回を目安にKPT(Keep・Problem・Try)を行っています。リリースサイクルがだいたい2週間に1回なので、その後にKPTを行っていて、各々感じたことや開発体制の課題などがあればその時に顕在化させています。

また、2週間おきのKPTで見つかった中で「これは深掘った方が良いよね」という課題などがあれば、別途そのKPTの間の1週間で1時間ぐらい時間を取り、それに対しての施策を練るなどしています。

KPT自体については、比較的ゆるい話題でも挙げられるようにはなっているので、本当に些細なことや個人的なことからでも振り返るようにしています。深掘りの対象とした課題については、確実に開発体制の中でボトルネックになっているようなものを扱うので、かなりしっかりと話し合う場を設けて議論をしています。

今後一緒に働くエンジニアへメッセージ!

現状お客様やチームに対して、リリースサイクルを守るなど関わる人に対してきちんと約束を守るという点に関しては、明確に会社の文化としてあるかなと思います。

緩くやるところは緩くやりつつも、アウトプットに対してはかなりみんな責任強くて、真剣に取り組んでくれていますし、「仕事を真剣に頑張りたい」「課題に対して責任を持って開発をしたい」というスタンスの方が合うのかなと思います。

とはいえ話してみないとわからないと思いますので、まずはお気軽にご連絡頂ければと思います。