本連載では、CG映像制作におけるテクニカル系スタッフの仕事の現状と課題を、パイプライン開発の専門家である痴山紘史氏（日本CGサービス（JCGS）代表）が探っていく。第11回では、イラスト・マンガ・Webtoon・アニメーション制作アプリ「CLIP STUDIO PAINT」の開発・販売で知られるセルシスを取材。同社のテクニカル系スタッフの仕事を前後編にわたって深掘りする。

Objective-Cと共に歩んだ、アプリ開発者の原点と現在

稲葉 遼氏（以下、稲葉）：セルシスでCTOを務めている稲葉です。私は中学生の頃から趣味でプログラムを書いていて、芝浦工業大学のシステム工学部 電子情報システム学科を卒業後、2012年に新卒でセルシスに入社しました。

稲葉：当社は、創業以来ずっと「クリエイター向けの制作環境を支えること」を軸に事業を展開してきました。代表的な製品であるペイントアプリ「CLIP STUDIO PAINT」をはじめ、創作活動を支援する各種サービスを提供しています。設立から約30年を迎え、コーポレートアイデンティティの再整理も行い、「クリエーションで夢中を広げよう」というミッションを掲げました。

稲葉：私自身は、高校時代からmacOS向けのプログラミングに夢中になっていて、とりわけObjective-Cという言語が大好きでした。むしろObjective-Cを触りたくてMacを買ったほどです。当時はまだiPhoneも存在しておらず、日本語の資料も少ないマイナーな言語でしたが、知識を定着させる目的もあってブログで情報発信を続けていました。やがてiPhoneが登場し、Objective-Cの注目度が一気に高まったことで、私のブログも参照されることが増え、自然とiPhoneアプリ開発にも早期から取り組めたのは良い経験だったと思います。

こうして積み重ねたmacOS／Objective-C／iPhone開発の知識と経験は、後にCLIP STUDIO PAINTのiPad版を立ち上げる際、私がリーダーを務める上でも大きな土台になりました。

就職活動では「アプリ開発を仕事にしたい」という思いが明確にありましたが、当時も今も、国内でtoC向けのアプリケーションを長期的に開発している企業は決して多くはありません。そんな中でセルシスは、当時、国内のアニメ制作現場で広く使われていたRETAS STUDIOや、マンガ制作ソフトとして高いシェアを誇っていたCOMIC STUDIOなど、現場で使われるツールをきちんとつくっている印象が強く、自分の志向に合っていると感じて入社を決めました。

入社したのは2012年で、ちょうどCLIP STUDIO PAINTがリリースされたタイミングでした。以来ずっとアプリ開発部に所属し、最初の10年ほどはエンジニアとして、機能開発やiPadをはじめとする新しいプラットフォームへの対応などに取り組んできました。その後、課長や部長といったマネジメントの役割を経て、現在はCTOとして、取締役の立場から開発全体を統括しています。

機能の方向性を定め、体験の整合性を担保する役割

稲葉：CTOになってからは、開発全体を俯瞰する役割が多くなりました。主な業務は、CLIP STUDIO PAINTの機能ロードマップの策定と、開発成果物に対する仕様レビューです。各機能には仕様書が用意されていて、それに基づいて実装されたものが、意図したユーザー体験にちゃんとつながっているか、技術的に妥当な問題解決アプローチであるかなどをチェックしています。

一方で、ある程度の規模感がある機能や、これまでにない新しい機能に関しては、私自身が仕様策定から関わることもあります。例えば、リリースにおいて特に重要な意味をもつ機能や、判断が難しい仕様を含む機能については、初期の企画段階から深く関与することが多いです。

最近の事例で言うと、iPad / iPhone / Android向け「シンプルモード」へ、新たに搭載したアニメーション制作機能については、初期提案の段階から参加し、どのような仕様で提供するか、どこまでの範囲を機能として含めるかといった基本的な仕様の提案を行なっています。

また、Ver.4.2で大きく刷新したカラーマネージメントまわりの挙動には、最終的な仕様の落としどころまでしっかり関わりました。色に関する処理はユーザー体験への影響が非常に大きいため、慎重な調整が求められます。

開発・検証・UX評価までを内製化する、社内三層の体制

稲葉：CLIP STUDIO PAINTの開発体制についてもお話しします。当社では、アプリの開発からテスト、UXの評価まで、全て社内で一貫して行なっています。その中核を担っているのが、アプリ開発部、プロダクト・サポート部、UX課の3つのチームです。

まず「アプリ開発部」には、現在およそ50名が在籍しています。CLIP STUDIO PAINTの仕様作成から実装までを担当しているチームですね。メンバーの多くは理系の大学出身者で、最近では大学院まで進学された方が増えている印象です。ただし経歴にはこだわっておらず、専門学校出身の方もいます。特に高専出身者は意外と多くて、即戦力として活躍してくれています。

採用の際には、学歴よりも「今どんなスキルをもっているか」、「どんな開発がしたいか・してきたか」、「セルシスと志向が合っているか」という観点を重視しています。チームとしても、あまり経歴にとらわれない柔軟な構成だと思います。

次に「プロダクト・サポート部」は、CLIP STUDIO PAINTのテストを担当する部門で、こちらは約15名体制です。ここで行うテストは、自動化された処理ではなく、手動でアプリを触って確認する人力テストがメインです。というのも、絵を描くアプリケーションでは「操作感」や「描き心地」といった感覚的な部分がそのまま品質に直結するため、実際に使って確かめる必要もあるからです。

プロダクト・サポート部には、「CLIP STUDIO PAINTを実際に使ってきたユーザー」のような、非エンジニアのメンバーが在籍しています。アプリケーション開発の現場では、テストもエンジニアが担当するケースも多いと思うのですが、当社ではあえて非エンジニアの視点を取り入れています。例えば「これは仕様通りだけど、なんとなく違和感がある」といった感覚的な指摘が出てくるのは、ユーザー目線をもったテスターがいるからこそです。

開発側から見ても、「この機能、実際どうだった？」と率直にフィードバックを求められる相手が社内にいるのは非常にありがたいです。「思ったより刺さらなかった」、「逆に、想定外に評価が高かった」といったリアルな手応えがすぐ得られるので、それらの声が機能のブラッシュアップにつながることも多いです。

そして3つめのチームが「UX課」です。こちらはプロダクト推進部の中の1ユニットという位置づけで、比較的新しい組織です。もともとはプロダクト・サポート部の中で「使用感の検証」まで一緒に担っていたのですが、よりUXを重視していきたいということで、UXに特化したチームとして切り出されました。現在は5名程度のメンバーが在籍しています。

UX課では、例えば「このUIや新機能の操作感がしっくりこない」といった開発側の相談を受けて、どうすればもっと直感的に操作できるかを一緒に検討したり、重要な新機能の体験設計を事前に評価したりしています。テストの一環として見ていた「使用感」を、よりUXという観点で明確に扱うことが目的です。また、UX課からの発案でUXを変えていくというプロジェクトも最近ではスタートしています。

感覚的な違和感にこそ、大きな意味がある

稲葉：テストのフィードバックをもらう中で、たまに「いま何が問題として指摘されているのか」がぱっと掴めないことがあります。開発側から見ると「これは仕様通りに動いている」と思ってしまうことでも、テスト側からは「いや、でもこれはちがう」と感じられる場合があるんですね。

そういうときは、開発側で勝手に判断をくださずに、ちゃんと注意深く話を聞くようにしています。やり取り自体は、基本的には課題ベースで進めています。「この観点でチェックしてほしい」とこちらから依頼して、それに対する結果をスプレッドシートなどでまとめてもらう。表形式の情報から全体の傾向や異常値はある程度読み取れるんですが、それだけだとフィードバックの意図まで汲み取りきれないこともあるんです。

そんなときは、やはり直接ミーティングを開いて話し合うようにしています。「仕様として問題はないけど、なんかちがう」みたいな違和感こそ、ユーザー体験を損ねる大きな要因になり得るので、そこは見逃さないように努めています。

4プラットフォーム展開を支えるアーキテクチャ

稲葉：開発面についても少し詳しくお話しすると、CLIP STUDIO PAINTはいま、Windows／Mac／iOS（iPadOS）／Androidの4つのプラットフォームで展開しています。一番下のレイヤーでは、それぞれのネイティブAPIを使っています。例えばWindowsならWin32 API、MacやiOSはObjective-C++ベースでAppKitなどを使っています。最近はSwiftでしか提供されないAPIも増えてきたので、一部はSwiftも入れています。

Androidに関しては、基本的にNDKを使ってC++で実装していますが、一部JavaしかないAPIはJavaでの実装もしており、そこはC++とJavaをブリッジさせる必要があります。この部分は、かなりテクニカルな領域ですね。

ただし、アプリをそのままネイティブAPIでガチガチに書いているわけではなくて、各プラットフォームのAPIの上に、自社で開発した共通フレームワークを挟んでいます。社内では「Triglavフレームワーク」と呼んでいて、通常のアプリ開発者はこのTriglavのAPIを使って機能を実装していきます。C++で書かれており、各プラットフォームごとに同じAPIを実装していて、どのプラットフォームでも同じAPIを利用してアプリケーションを開発できます。

このフレームワークによって、複数プラットフォームにまたがる開発を効率よく行えるようにしているわけです。もちろん、OSごとに振る舞いがちがう部分はあるので、そこはTriglav側で吸収するようにしています。

外部ライブラリは「最小限かつ枯れたもの」を選定

稲葉：ライブラリの依存については、Boostなどの基本的なC++ライブラリは使っていますが、外部のサードパーティ製ライブラリの採用は、かなり慎重に行なっています。というのも、4つの異なるプラットフォームで展開している以上、「全ての環境で安定して動くか」、「OSのアップデートで壊れないか」といった観点が非常に重要なんです。

特に、iOS／iPadOS／Androidのような頻繁に仕様変更やSDKアップデートが要求されるプラットフォームでは、ちょっとしたことでビルドできなくなるリスクがある。ですので、基本的には「枯れていて安定している」、「頻繁なバージョン追随が不要」といった条件を満たすものだけを採用しています。libpngやlibjpegのような定番ライブラリはもちろん使っていますが、それ以外はかなり絞っています。

ただ、完全にゼロというわけではありません。ライセンス情報はアプリ内のバージョンダイアログで確認できるようになっていて、必要最小限ながら、いくつかのライブラリは利用しています。

推奨IDE × メタビルドシステムで支える開発環境

稲葉：開発環境（IDE）は、各プラットフォームで公式に推奨されているものをそのまま使っています。WindowsならVisual Studio、MacならXcode、AndroidならAndroid Studioですね。というのも、推奨環境を外すと、ある日突然サポートが終了したり、動かなくなったりするリスクがあって。なるべく、第三者が開発した非公式なツールに依存しないようにしています。

とはいえ、4つのプラットフォームで開発を進めていると、それぞれのIDEのプロジェクトファイルを手作業で保守するのは現実的ではありません。Visual Studioのソリューション、Xcodeのワークスペース、Android Studioのプロジェクト……全部を個別にメンテナンスし、設定しきるのは現実的ではありません。

そこで私たちは、Premakeというメタビルドシステムを導入しています。Luaでプロジェクト設定を書いておけば、そこから複数のIDE向けに必要なファイルをまとめて生成できるようになります。CMakeと似たしくみですが、Premakeは出力されるファイルに絶対パスが入らない点や、スクリプトが柔軟に書ける点が自分たちに合っていました。

このしくみを入れたのは、まだ対応プラットフォームがWindowsとMacだけだった頃です。入社して数年が経った時点で、すでにVisual Studioのプロジェクトだけで50個近くになっていて、ビルド構成や設定の整合を取るだけでも大変でした。コンパイラオプションを1つ追加するにも、全プロジェクトを手で開いて揃えなければならず、それだけで2〜3日潰れることもあったくらいです。

そのとき、「これ以上手作業では無理だ」となって、いろいろ検討した末にPremakeにたどり着きました。正直、このときにメタビルドを入れていなかったら、後にiPadやAndroidまでプラットフォームを拡張することはできなかったと思います。

Premakeの良いところは、生成されたプロジェクトファイルがそのまま独立して動く点ですね。別の環境にもっていっても問題なくビルドできるし、Luaでビルド設定を記述するので、スクリプトによるカスタマイズもしやすい。私たちは「仮にPremakeが将来的に使えなくなっても、開発が止まらないようにしておく」ことを重視しているので、こうしたポータビリティの高さはとても重要なんです。

継続的開発を支えるインフラと運用

稲葉：バージョン管理にはGitを、CI/CDにはJenkinsを使っています。対応プラットフォームが多いので、リリースビルドを手作業で行うのは現実的ではなく、基本的にはJenkins上でビルドプロセスを自動化しています。

チケット管理にはBacklogを採用しています。既存機能の不具合や課題のトラッキングだけでなく、新機能の開発も含めたタスクの一元管理に使っていて、開発中に発見された不具合などもここに登録して消化していくながれです。

ユーザーサポートに寄せられる不具合報告や要望に関しても、開発用とは別にBacklogの環境を用意して、内容を取りまとめてチケット化をしていますが、開発者もその内容を閲覧できるようにしています。サポート担当から「これは修正が必要」と判断されたものについては、開発用Backlogに転記してチケット化し、通常の開発フローに乗せるようにしています。あるいは、開発側から修正が必要と判断する場合もあります。

Jenkins上でのビルドは、開発者がチケットを作成したあと、必要に応じて自分でビルドを起動するという運用です。ビルドの完了通知はSlackに飛ぶようにしていて、チケットとビルド、そしてSlackの通知が緩やかに連携したワークフローになっています。

ブランチ運用に関しては、マイルストーン単位のブランチを軸に、そこから各機能開発用のブランチを切るかたちを取っています。機能の実装と検証が終わったらマージして、マイルストーンの中心ブランチは毎晩自動でビルドが走るようにしています。

一方、個別ブランチのビルドは基本的に手動です。というのも、CLIP STUDIO PAINTのビルドには1時間ほどかかるため、全てのコミットで自動的に回すのは現実的ではないんです。そうした制約も含めて、現実的に回るかたちで運用を整えてきました。

Slack × 手順書で整える開発フロー

稲葉：チーム内のコミュニケーションはSlackを使っています。JenkinsやBacklogと連携して、チケットの更新やビルドの結果など、必要な情報が自動でながれてくるようにしていて、すぐに情報が届くしくみになっています。ユーザーからのフィードバックや、チーム内で気づいたことが自然と目に入る環境になっていると思います。

稲葉：また、私たちの開発フローはかなり明確に定義されています。ブランチを切るところから始まり、実装・コミット・レビュー、Pull Requestの作成、テスト項目の準備、チケットの登録……と、ひとつひとつの工程が細かく決まっていて、それを手順書としてまとめています。

この手順書は、「誰が何を、どのタイミングで行うか」という視点で書かれていて、全体で29ステップあります。少し多いようにも感じるかもしれませんが、これを順に追っていけば、ひと通りの開発を完結できるようになっています。新人メンバーでも、この手順書を見れば迷わず開発のながれに乗れるようなかたちですね。手順書を厳密に守って開発を進めていくというよりは、誰でもすぐに開発にジョインできるようにするための資料として作成をしています。

本記事の後編は、2026年2月公開予定です。