OSの仕組みまで深く読み解く。アイキューブドシステムズのMDM（モバイルデバイス管理）サービス開発の醍醐味とは
企業や学校、医療機関などで使われるスマートフォンやタブレット、モバイルPCなどのモバイルデバイスを安全に運用するには、アプリ配布や利用制限、セキュリティ設定などを一元的に管理する仕組みが欠かせません。その領域を担うのが、MDM（Mobile Device Management：モバイルデバイス管理）サービスです。
福岡・東京に本社を置く株式会社アイキューブドシステムズ（以下、アイキューブドシステムズ）が提供する「CLOMO（クロモ）」は、国内MDM市場において15年連続のシェアNo.1（※）を達成。接客や鉄道の運転支援、倉庫の検品、学校のICT教育など、国内のあらゆる現場でデジタル化（DX）が進んでいます。MDMは、それらの現場で使われる多様なデバイスの管理やセキュリティ対策を担い、業務変革を足元から支える重要な役割を果たしています。
「私自身、入社した7年前は、MDMの知識はゼロでした」と話すのは、「CLOMO」の開発組織で部長を務める岩木 祐輔さん。今回は岩木さんに、MDM開発の面白さや組織づくり、AI活用についてざっくばらんに聞きました。
※出典: デロイト トーマツ ミック経済研究所「コラボレーション/コンテンツ・モバイル管理パッケージソフトの市場展望（https://mic-r.co.jp/mr/00755/）」2011〜2013年度出荷金額、「MDM自社ブランド市場（ミックITリポート12月号: https://mic-r.co.jp/micit/2025/）」2014～2024年度出荷金額・2025年度出荷金額予測
目次
プロフィール
CLOMO事業本部 製品開発部 部長
関東ではなく福岡へ、場所を先に決めてから出会った会社
―― まずは岩木さんの、これまでのご経歴を教えてください。
岩木：新卒では総合電機メーカーに入社し、携帯電話やスマートフォンのOS側のカスタマイズに関わっていました。当時はAndroidスマートフォンが出はじめたころで、電池の持ちを改善するためにOSまわりを見たり、端末の中を上から下まで触ったりする仕事をしていました。
そこで5年ほど勤務した後、クラウドソーシングサービスの運営会社へ入社しました。最初はAndroidアプリの立ち上げ担当でしたが、最終的にはWebアプリケーション開発も担当しました。そこで現在につながるWebエンジニアとしての土台ができていき、次第に、より上流のマネージャーの仕事をしたいと考えるようになりました。
―― アイキューブドシステムズには、どのようなきっかけで出会ったのでしょうか？
岩木：移住先の福岡でたまたま見つけました。
―― 移住先、ですか。
岩木：当時関東に住んでいたのですが、ずっと首都圏で働きつづけるのは、自分にとって少ししんどい感覚がありました。関東で働くことは成長のためだと割り切っていましたが、近い将来、別の地域に移りたいなと考えていました。
札幌や大阪などいくつか候補はあったのですが、中でも福岡はスタートアップやベンチャー企業が多く、マネージャーの仕事に就ける環境が複数あるだろうと考え、思い切って移住しました。実際に滞在してみて、住みやすさも感じました。
―― 先に移住して、そこから会社を探されたのですね。数ある企業の中から、アイキューブドシステムズに入社した決め手は何だったのでしょうか？
岩木：福岡に本社機能があり、自分たちの意思決定がプロダクトに反映される環境だったことが大きかったです。加えて、扱っているのがBtoBのプロダクトということで技術的にも興味がありましたし、組織のフェーズも拡大期で面白いタイミングだと思いました。MDMについては、実はほとんど知らなかったんですけどね。
―― 入社当時からMDMを担当されていたのですか？
岩木：はい、サーバーサイドエンジニアとして入社し、最初の1年ほどはパフォーマンス改善や、長年の運用で蓄積された課題に向き合う仕事が多かったです。その後2020年に課長、2022年に部長になって、当初から思い描いていたマネジメントの役割にシフトして活動しています。
GoogleやAppleとも密に連携。OSの中身に作用する領域であることが、面白さのひとつ
―― MDMや「CLOMO」について、教えてください。
岩木：MDMは、ざっくりとお伝えすると、企業や学校などで配布されるスマートフォンやタブレット、モバイルPCなどのモバイルデバイスを管理するための仕組みです。個人用途ではないモバイルデバイスでは「業務に不要なアプリを使わせたくない」「必要なアプリを自動で配布したい」「設定を一括で揃えたい」といったニーズがあります。MDMは、業務に関係のないアプリのインストールを制限したり、業務アプリを自動で入れたり、セキュリティポリシーを配布したりといった、各社における「モバイルデバイスのあるべき状態」を、数百台、数千台、時には数万台規模で一括管理します。
岩木：「CLOMO」では、デバイス管理が楽になるようなUIをめざしつつ、デバイスロックや遠隔制御など、デバイスが盗難されたり紛失したりしても、中身のデータを強固に守るセキュリティ機能を備えています。
―― 「CLOMO」が選ばれる理由として、どのような点が評価されているのでしょうか。
岩木：よく言われるのは「サポート体制の良さ」です。MDMは設定すれば誰でもすぐ使いこなせるものではありません。iOSやAndroidのデバイス管理仕様を理解していないと、往々にして使うべき設定の箇所や内容が分からなくなるため、ただ機能を増やして全体を複雑にするのは避けなければなりません。そういう意味でも、開発としてはデバイスの管理者をサポートしやすいようにプロダクトを作ることも重要だと捉えています。
―― 岩木さんが感じる、MDM開発の面白さややりがいについて教えてください。
岩木：まず、関わる人が多いところが面白いですね。MDMの直接の利用者は、学校の先生や企業の情報システム部門のような「管理者」ですが、一方で、実際にデバイスを使う「エンドユーザー」もいます。
管理者にとってはデバイスを適切な状態に保つことが価値ですが、エンドユーザーにとって、MDMはウィルスセキュリティ対策ソフトと同じように、普段は存在が意識されない状態が理想です。主体によって重視すべきポイントが異なるので、考えるべきことが多く、難易度が高くてやりがいを感じます。
また、OSの中身に作用する領域である点も、面白さのひとつだと感じています。Androidであれば、「DevicePolicyManager」や「UserManager」のような普通のアプリ開発ではあまり触れないようなシステムサービスを相手にします。iOSでは、MDMの仕組みを持っているOSそのものを活用する形で実装していきます。GoogleやAppleのメンバーとも密にコミュニケーションさせていただくことが多く、OSやプラットフォームの仕組みに興味がある人には、非常に面白い領域だと思います。
―― 社内では、その面白さをどう伝えているのでしょうか？
岩木：なるべくまっさらな状態でMDMと向き合ってもらうようにしています。というのも、既存の「CLOMO」に機能を継ぎ足すだけだと、MDMの面白さは見えづらいんです。私自身、2023年頃に「もしもゼロからMDMを作るならどうなるのか」を考えて、Appleのプロトコルを読み、自分で構築してみたことで、MDMの仕組みの深さや面白さを強く感じることができました。
その経験をもとに、社内で勉強会を開くようになりました。最初から全員が興味を持つわけではありませんが、2〜3人でも共感してくれる人がいてそこから広まっていけば万々歳ですね。2024年からは新卒研修にも「Androidの簡易的なMDMを作る内容」を取り入れて、一次情報を読み、自分で手を動かす文化の醸成にも取り組みました。
―― 研修によって、組織にはどのような変化がありましたか？
岩木：設計に関する議論が楽しくなってきたと感じます。例えば、設定値をどこで変換すべきかを考えるときに、単なるWebアプリケーションの観点だけでなく、デバイス側の事情やMDMプロトコルの観点も踏まえて議論できるようになってきました。
MDMは正解が1つではない場面が多く、フロント側で処理すれば簡単に見えることでも、100台、1,000台のデバイスへ配布する時には効率が悪くなることがあります。そのような裏側を知ったうえで議論できるメンバーが増えると、設計の質が変わると実感しています。
「技術的負債」という言葉は使わない
―― 開発体制についても教えてください。
岩木：プロジェクト単位では4〜7人くらいの少人数で動くことが多いです。PdM、開発、QAなどのメンバーが連携しながら、1〜2週間ごとにスプリントレビューのような場を設けて進捗・認識を確認するという、アジャイルに近い形で進めています。ただしプロダクトの性質上、最終的な検証はウォーターフォールに近い形で進めていますね。
―― なぜ、最終検証はウォーターフォールに近くなるのでしょうか？
岩木：MDMは、実際のデバイスが関わるからです。デバイスにコマンドを届ける、再起動する、初期化する、OSの挙動を見るなどの検証は、CI/CDや自動試験だけで担保するのが難しく、現物で確認する必要があります。
もちろん、自動化を進められるところは進めています。管理コンソール側は単体テストで基本的な問題を潰せるように少しずつ改善していますし、QAチームでもPlaywrightなどを活用して繰り返しの試験を自動化しています。また、修正範囲に応じてどこを検証すべきかをQAと開発で議論するテスト設計も重視しています。もしも現在の規模でフルテストを実施すると3、4ヵ月かかるのですが、実際に実施するテストの影響範囲の絞り込みや自動化によって相当効率化できています。
ただ、すべてを効率化するだけでなく、ウォーターフォールのように最後に現物のデバイスと向き合って、1つひとつの挙動を確認していく工程も欠かせません。自動化を進める一方で、使い勝手や細かな違和感など、実際に触るからこそ気づけることもあります。地道な工程ではありますが、数か月かけて仕込んだプロダクトが実機上で期待どおりに動くことを確認できたときは、大きな達成感があります。デバイスを相手にしたモノづくりならではの面白さを感じる瞬間ですね。
―― 入社後、特に印象に残っている開発エピソードを教えてください。
岩木：管理コンソールのパフォーマンス改善ですね。入社当時、管理するデバイスの台数が100台を超えたあたりで、画面の表示や検索の処理速度が低下してしまう課題を抱えていました。「CLOMO」ではRuby on Railsを使っており、よくあるN+1問題を解けば済むと思っていたのですが、実際にはもっと根が深く、画面表示のためにどのデータベースからどんな情報を取り、どの処理を経て表示しているのかを丁寧に追う必要がありました。数ヵ月ほどかけて改善し、結果的に1,000台、1万台のデバイスがあってもすぐ表示できるようになりました。検索も2〜3秒で返るようになりました。
―― 劇的な変化ですね！具体的には何を変えたのでしょうか？
岩木：検索については、インデックス構造を変えました。数年前はインデックスを利用していない検索処理があり、台数が増えれば負荷が上がりやすくなるのは当然でした。やったこと自体はオーソドックスなアプローチですが、それでも大規模なシステムにおいては大きな価値を生むのだと実感しました。
そして、この経験から「技術的負債」という言葉をあまり使わなくなりました。負債と言うとネガティブに聞こえますし、負債のある会社は悪い会社だと思われがちですが、見方を変えれば、そこには改善・活躍の場が大いに残された会社だと捉えることもできます。一概に悪いものとして扱うのではなく、どう価値につなげるかが大事だと感じるようになりました。
―― なるほど、面白い視点ですね。今のお話の一方で、うまくいかなかった取り組みもあればお願いします。
岩木：大小様々ですが、マイクロサービス化は教訓として非常に大きかったと感じています。数年前にマイクロサービスがトレンドとなり、弊社でも「大きなサービスを分離すればメンテナンスしやすくなるのではないか」と考えて進めました。最初は、1から作れるしテストも書きやすいため良く見えたのですが、規模が大きくなるにつれて、元々1つだった時代の方がテストを書きやすかったのではないかという問題が出てきました。
振り返ると、マイクロサービス化そのものが目的になっていたのが良くなかったなと思います。ドメイン駆動設計で言う「境界づけられたコンテキスト」を十分に考えず、画面単位で分離してしまったんです。MDMには「あるべき状態を定めるフェーズ」と「その状態をデバイスへ適用するフェーズ」があり、そこを適切に分けるべきでした。
―― たしかに、マイクロサービス化については、結果として課題が大きくなったという声もしばしば耳にします。
岩木：今後は、再統合も視野に入れています。ただ元に戻すのではなく、管理側とデバイス側など、あるべき境界で整理し直した上で、開発スピードを上げていくことがテーマです。
MDM開発では「しぶとく仮説検証する力」が大事になる
―― MDM開発を楽しめる人を採用するのは難しそうと感じますが、採用ではどのような点を見ていますか？
岩木：前提として、MDM開発の経験者はほぼいないので、経験そのものよりもマインドセットを見ています。特に、上手くいかなかった経験をどう捉えているかはよく聞きますね。組織で自分がやりたいことを達成できなかった時に、ただ「上手くいかなかった」で終わらせるのか、それとも自分なりに分析して改善しようとしたのか。
MDMは、言われた通りにやれば上手くいく領域ではありません。GoogleやAppleの仕様を読み、実際に試し、上手くいかなければドキュメントやフォーラムを追いながら原因を探る。しぶとく仮説検証する力が必要です。「先輩が言ったからやってみました」ではなく、自分なりに仮説を立てて自律的に進められるかを重視しています。
―― 技術面では何を重視していますか？
岩木：サーバーサイドでは、やはりRuby on Railsの経験を重視しています。既存サービスをどう改善していくかをチームで議論する文化があるので、実務未経験であっても、Railsの基礎をキャッチアップされている方や、ベースとなる開発スキルのある方だと心強いですね。ただ、それ以外の技術経験については、特定領域の経験が必須だとは考えていません。
ちなみに、Railsは学習パスが比較的シンプルです。Active Recordなどの考え方も共通言語として浸透しており、新しく入った人がWebアプリケーション開発でつまずきにくいです。そもそもMDMは学ぶことが多いので、Web開発の基本部分で学習コストが高すぎるのはもったいなく、その意味でもRailsは相性が良いと感じています。
―― 開発現場での生成AI活用についても教えてください。
岩木：全社的なAI活用の動きも相まって、開発現場でも積極的に使うようにしています。最初に本格的に使ったのはRailsのバージョンアップで、人間がやる意味の薄い作業からAIを使おうと考えました。活用の幅を広げていく中で、特に効果が出ているのは不具合解析です。
―― どのような形で使っているのでしょう？
岩木：「CLOMO」では複数のRailsサービスが関係しており、不具合の原因を人間が追うと、ロジックの所在を調べるだけで2、3日かかることがありました。そこで、AI向けの説明書、いわゆるCLAUDE.mdのようなものを整備し、Claude CodeやOpenAI Codexを使って原因を調べられるようにしました。今では早いものだと1分、遅くても15分ほどで原因解析まで進むことがあります。
―― テストや品質保証にも応用できそうですね！
岩木：そうですね、影響範囲の特定には可能性を感じています。人間が見るだけだと波及範囲を見誤る可能性があるので、ソースコードの差分をAIに読ませ、どこに影響がありそうかを特定するような使い方です。ただし、AIエージェントが自社サービスを見てテストできるようにするには、画面やデータの作り方も変える必要があると考えています。AIにとっても判断しやすいUIや状態表現に改善していくことは、今まさに取り組んでいるテーマですね。
―― AI活用は往々にして個人の裁量や熱量によって偏りが出てくるので、組織的な動きにできていないケースも少なくないと感じますが。そのあたりはいかがでしょうか？
岩木：実は、全員に「使いましょう」と強制しているわけではなく、便利さを伝えているだけなんです。そこから、効率化に興味があるメンバーが2〜3人出てきて、その人たちがCLAUDE.mdを整備したり、利用シナリオを作ったりしてくれました。今は、共感ベースで広がっています。
例えば、Confluenceの設計書と接続してドキュメント反映をしやすくするメンバーもいれば、コードを読ませて見積もり作業に活用するメンバーもいます。ちなみに、私自身は組織の目標管理にもAIを使うようにしています。会社としてもAI活用を大いに推進しているため、まずは試して、効果があれば実用化する流れがあります。
エンジニアが開発に集中でき、挑戦する人には機会がある
―― 開発組織や会社全体のカルチャーについても聞かせてください。
岩木：エンジニアに限らず、「自分のやりたいこと」と「会社のビジネス成長」を同時に考えられる人が活躍しやすいと思います。例えばMDMは、何も考えずに作るとグローバルベンダー含む他社製品と似たようなものができあがってしまうのですが、国内の学校や企業で使ってもらうには、現場に合った使いやすさやサポートも重要な要素です。エンジニアからの視点だけでは「複雑になるから不要」と思う機能でも、ビジネス上は必要な場合があり、逆に、要望を何でも取り込めば良いわけでもありません。プロダクトとしてどうあるべきか、ビジネスとしてどう価値を届けるかを、両面で考えることが大事です。
―― エンジニアにとって働きやすい制度や環境としてはいかがでしょうか？
岩木：代表が元エンジニアということもあって、開発に集中しやすい環境が整っていると感じます。お客さま対応については、営業やカスタマーサポートなど各部門がそれぞれの専門性を生かして担当しており、開発メンバーも必要に応じて連携しています。役割分担が明確なので、エンジニアはプロダクトの品質向上や機能開発にしっかり時間を使うことができています。
あと、カンファレンス参加にも比較的前向きです。「Kaigi on Rails」も、私が個人で参加して面白いと感じたことがきっかけで、会社としてブース出展するようになりました。現場のエンジニアがやりたいことに理由があれば、採用や技術広報にもつながる取り組みとして進めやすいと感じます。ちなみに、働き方としてはリモートと出社のハイブリッドです。議論を深めるために出社は大切にしていますが、長時間拘束するような形ではありませんね。
―― 評価面では、どのような特徴がありますか？
岩木：年齢や勤続年数に関係なく、実力があれば評価されるようになってきています。新卒入社から間もないメンバーでも、高い学習意欲と実装力があり、10年目のエンジニアと同じような議論ができる人がいます。そういう人は、段階を1つずつ上げるのではなく、実力に応じて一気に評価されるケースも出てきました。社内に「出る杭は引っこ抜く」という言葉があり、挑戦する人には機会が与えられます。自己成長を事業成長につなげたい人には可能性がある会社だと思います。
根っこの仕組みを知ることは、長く効く力になる
―― 今後、強化していきたい技術的なテーマは何でしょうか？
岩木：開発スピードの向上です。先ほどお伝えしたマイクロサービスの再統合もその一環で、ドメイン駆動設計の観点を学びながら、サービスを適切な粒度で分け、それぞれのチームが責任を持って開発できる状態をめざしています。現状はシステム全体の関連性を深く意識しながら慎重に開発を進めていますが、今後は各チームが担当領域に集中し、より迅速かつ安全に機能改善を回せる構造へと進化させていきたいと考えています。
―― 岩木さん個人のエンジニアとしての行動哲学も教えてください。
岩木：「仕組みを知ろう」ですね。AIやフレームワークなど、流行りの技術は次々と出てきますが、それらを表面的に使うだけでは上手くいかない理由が分かりません。AIであれば、その特性をある程度理解していれば「この使い方は向いていないのではないか」という勘所が養われていきます。
ブラウザテストでも同じです。テストが落ちた時に、ブラウザテストがどのような仕組みで動いているかを知らないと、なぜ落ちるのかへの仮説が立てられません。逆に仕組みが分かれば、サービス側をどう変えればテストしやすくなるかを考えられます。Androidも、アプリの作り方は数年ごとに変わりますが、Androidフレームワークの根本は大きく変わっていません。根っこの仕組みを知ることは、長く効く力になると考えています。
―― ありがとうございます。それでは最後に、これから入社する方への期待を教えてください。
岩木：ぜひ、エンタープライズ領域を楽しんでほしいです。エンタープライズやセキュリティというと堅そうに見えるかもしれませんが、「CLOMO」の開発にはかなり自由度があります。
フィンテック領域のような非常に高い信頼性やセキュリティの基準を持ちつつ、コンシューマ向けサービスのようなユーザーに寄り添った使いやすさやスピード感も大切にしている、その中間に位置する絶妙なバランスの開発環境だと思います。多くのユーザーに影響する開発を、適度な緊張感の中で進められる領域です。特にMDMは知られていないことが多いですが、やってみると面白い部分がたくさんあります。OSの仕組みを読み解き、管理者とエンドユーザーの両方を考え、ビジネス価値にも向き合う。簡単ではありませんが、知的好奇心を持って深掘りできる人にはとても楽しいはずです。
仕組みを知りたい、複雑なものを整理したい、影響範囲の大きいプロダクトに関わりたいという人と一緒に、「CLOMO」をさらに良いプロダクトにしていきたいです。
編集後記
今回の取材で印象的だったのは、「CLOMO」の開発が単なるWebサービスにとどまらず、OSやプラットフォームの仕組みに深く関わる領域であることです。AppleやGoogleが提供するOSの仕様を読み解き、実機で検証しながら価値に変えていく仕事は、エンジニアにとって大きなやりがいがあると感じました。実際に福岡の本社オフィスを訪問してみても、社内には穏やかで前向きな空気があり、一人ひとりの個性や挑戦を尊重する姿勢が伝わってきました。innovationを表す「i」のドットを中心に「アイデアの原石」の形をしたエレメントが「Cubed」を囲むデザインというコーポレートロゴの姿勢が、実際の空気感にも現れていると感じます。（エレメントにはバリエーションがあり、社員が名刺を作る際には複数の可変エレメントから選択できたり、自らエレメントをデザインできたりと、ユニークな運用ルールもあるそうです！）
技術の深さと人を大切にするカルチャー、その両方が「CLOMO」、ひいては同社の強さなのだと感じました。
取材／文：長岡 武司
撮影：竹原 健介
提供：株式会社アイキューブドシステムズ