内製開発の現場で起きるUIデザインの課題

東影：NRIネットコムはシステム開発、クラウド・基盤、デザイン、デジタルマーケティングという4つの柱を持ち、Web開発に関わる領域を一気通貫で手掛けることができる会社です。本セッションでは、その中からデザインとクラウドインフラの専門家がそれぞれの立場から内製開発についてお話しします。

私は普段、UI/UXデザイナーとしてクライアント企業の開発チームに入り込み、業務システムのUI設計やデザインガイドラインの策定を行っています。これまで大小合わせて約30以上のプロジェクトに関わり、SaaS開発から大企業の社内基幹システムまで、あらゆる業務画面に携わってきました。見た目を良くすることはもちろんですが、それだけではありません。複雑なデータをどう整理すればミスなく入力できるか、ユーザーが迷わない導線をどう作るかといった情報設計を行い、開発メンバーと密に連携を取りながらシステムのあるべき姿を画面に落とし込んでいく仕事をしています。

内製開発の現場では、次のようなUIに関する悩みが頻繁に発生しています。1つ目は、機能要件は満たしているはずなのに現場から「使いにくい」と言われてしまうこと。2つ目は、エンジニアが画面を考えるとデータベースの構造がそのまま画面に反映され、仕様イコール画面になりがちなこと。3つ目は、開発の終盤になって「この画面はおかしい」とひっくり返され、大きな手戻りが発生することです。



これらの課題は体制やプロセスに原因があり、私たちはデザイナーが開発チームに「伴走」する体制を作ることで解決しています。従来の仕様書をもらってデザインデータを納品するという形ではなく、開発チームの一員としてプロジェクトに参加するスタイルです。アプリ開発の定例ミーティングに毎週出席し、Slackなどのチャットツールでエンジニアからの質問に即レスし、Figmaなどのデザインツール上でリアルタイムに画面を修正していきます。外部に依頼する際にありがちな「依頼して納品」の関係ではなく、チームのメンバーとして一緒に悩む時間を共有するところが特徴です。

すでに社内にデザイナーを抱えているチームであればこの有用性をご理解いただけると思いますが、デザイナーが開発チームに参加してうまく調和しているケースは全国的に見てもまだまだ少ないのではないかと感じています。

エンジニアとデザイナーの「視点の違い」が品質を左右する

東影：では、なぜわざわざデザイナーがチームの中に入っていく必要があるのでしょうか。多くの開発現場では当然、画面設計という工程自体は行われています。エンジニアの皆さんも画面設計図をたくさん書いているはずです。しかし、そこには視点の違いがあります。エンジニアが画面設計をすると、どうしてもDBのカラムや機能の有無が最優先になります。これはシステムとして正しい姿ですが、ユーザーにとっては情報の羅列に見えてしまいます。エンジニアもUIを良くしたいと思っていますが、機能に漏れがないかを優先する必要があり、情報設計やデザインにかけるリソースが足りないという状況に陥りがちです。

一方、デザイナーが参画すると業務フローや人間の認知特性を最優先に考えます。「この作業の次はこれを見るはずだ」「ここの情報とここの情報はグルーピングしないと伝わりにくい」といった観点から情報の整理整頓を行うことで、ミスが起きにくい使いやすい画面が出来上がります。その結果、問い合わせ対応の件数を月20%削減したり、新入社員の操作教育コストを半分にしたりといった、具体的な運用改善につながっていきます。



デザイナーが伴走することの最大のビジネスメリットは、後工程の手戻りの削減です。開発やテストの段階で画面の項目変更や動線の修正が入ると、修正コストは跳ね上がります。リリース後にクリティカルなUI変更が必要になった場合、DBの定義からやり直しになって数百万円単位の損失が出ることも珍しくありません。画面設計フェーズへの投資はプロジェクト全体予算の10〜15%程度ですが、最初にこのコストをかけてデザイナーを入れ「使い勝手のバグ」を出し切ることで、後半のリスクを回避できます。

デザイナーの具体的な動きとエンジニアとの協業

東影：ある在庫管理システムのリニューアルプロジェクトを例に、デザイナーの動き方を紹介します。期間は約6ヶ月、10名程度の体制で、対象となる画面数は約40画面というプロジェクトです。体制としてはPMと開発チームの中間にデザイナーが位置し、PMが出すビジネス要件を噛み砕いて、ユーザーが使いやすい形に整えつつ、エンジニアが実装可能な形に落とし込みます。デザイナーが不在の場合、画面の仕様決めやボタンの配置といった検討をPMやエンジニアが行うことになりますが、デザイナーがそこを巻き取ることで、PMとエンジニアは本来の設計・実装業務に集中できるようになります。

デザインチーム内にはデザインディレクター、デザイナー、マークアップエンジニアという役割が分かれています。デザインディレクターとデザイナーが画面設計・情報設計を担当し、マークアップエンジニアがCSSの専門家としてアプリ開発チームとコミュニケーションを取りながら高品質なデザイン実装を可能にしています。



具体的には、デザイナーがPMの要件を聞いて画面を検討する際、「この機能は頻繁に使うからナビゲーションの先頭に配置して目立たせよう」「管理メニューは一部の権限の人しか使わないからナビゲーションの下に移動してアコーディオンで閉じられるようにしよう」「一覧の操作ボタンはドロップダウンメニューに格納して画面をすっきりさせよう」「削除ボタンは赤色にして誤操作を防ごう」といった判断を全画面に対して行っていきます。

ここで重要なのが、エンジニアとのコミュニケーションです。デザイナーが作った画面をエンジニアに相談した際に「このUIを実現するには標準のライブラリが使えないから工数が増えます」と言われることがあります。その場合、標準のライブラリでどこまでできそうかをエンジニアと一緒に探り、工数と品質のバランスを取った落としどころを見つけていきます。このようにビジネス観点で総合的に判断し、エンジニアと合意形成できるデザイナーがいると、プロジェクトは格段に進めやすくなります。デザインに理想を求めすぎず、実装の制約も踏まえた現実的な判断ができることが、開発チームに伴走するデザイナーに求められる重要なスキルです。

デザインシステムの構築とAI時代のデザイナーの役割

東影：デザインシステムやガイドラインを作ることもデザイナーの重要な仕事です。ボタンの種類や色の定義、余白やレイアウトの基本ルールをソースコードと一緒にドキュメント化しています。たとえばプライマリボタン、セカンダリボタン、キャンセル用ボタン、アイコンボタンなどの種類を整理し、オンマウス時や非活性時の見た目もすべて定義します。カラーパレットを用意してソースコード上で変数化し、実装に使いやすくすることも行っています。



このガイドラインがあることで、エンジニアとデザイナーのコミュニケーションはガイドラインをベースに行われるようになり、「ボタンの色はどうしますか？」「余白は何ピクセルですか？」といった細かい確認がなくなります。UIコンポーネントの再利用により実装スピードが上がり、デザイナー不在時でも80点の画面を作成できるようになります。デザインシステムは将来のコスト削減に直結するチームの資産です。

AIの活用についても触れておきます。AIのコーディング能力や画面生成能力は飛躍的に向上しており、この半年だけでも大きく変わったと感じています。業務フローが変わる可能性はかなり高いですが、品質維持のためにデザイナーはより必要になると考えています。Figmaをマスターとする場合、Figma Makeで自然言語から画面を作成してHTMLも同時に生成できますが、より良い指示を出すにはデザイナーの知見が不可欠です。最終的にはFigmaのデータを直接修正する場面も出てきますので、オートレイアウトやコンポーネントバリアントといった機能を理解し、それがHTMLにどう反映されるかまで把握できる高度なFigma操作スキルが求められます。ソースコードをマスターとする場合も、完成度の高いデザインシステムを最初に構築する必要があり、そこにデザイナーの力が必要です。



AIはドラフト作成までは早い一方、詳細を詰めたり維持運用したりする段階では人の手が必要になります。また、AIは一般的な正解をすぐに出せますが、自社の業務フローに合わせた文脈理解や複雑な仕様の整合性判断は人が考えるべき領域です。AIを使いこなすためのパイロットとして、デザイナーの役割はより重要になっていくと考えています。今後はソースコードが書けて、Figmaも使いこなせるマルチな能力を持ったデザイナーの需要がますます高まっていくのではないかと思います。

前半のまとめとして、伴走型のデザイナーを開発チームに入れて「納品」ではなく「対話」で進めること、特に開発前の画面設計フェーズからデザイナーを投入して後工程の手戻りを防ぐことが重要です。デザインシステムを構築してチームの資産にすること、これはAIの時代になった今、より一層必要になると考えています。デザイナーの関わり方一つで、使いやすいUIは確実に作れますし、開発効率も上がります。

AWS環境の運用課題を「標準化・統一化」で解決する

大林：ここからはAWS環境での運用について、内製開発を加速させるという観点でお話しします。私は普段、AWSクラウドエンジニアとしてエンタープライズ企業のお客様向けにマルチアカウント環境の設計や運用支援を行っています。セキュリティ・ガバナンスの整備や運用の標準化、CCoEの立ち上げ支援など、組織全体の運用設計に関わる案件を多く担当してきました。書籍の執筆や技術登壇なども行っており、2025年にはJapan AWS Top Engineersに選出いただきました。

AWSの内製開発というと、サービスやアーキテクチャの技術選定に注目が集まりがちです。内製化の文脈でも開発力の強化という観点で語られることが多いと思います。しかし、実際の現場ではシステムを作った後の運用がボトルネックになり、開発スピードが落ちているケースが非常に多くあります。昨今急成長しているAIも一つの手段ですが、前提として運用設計が適切でなければAIの効果も効率的に発揮できません。運用負荷を下げることこそが内製開発のスピード向上につながるのです。

現場でよくある課題としては、アラートが多く日々の対応に追われること、障害対応の判断が特定の人に依存して属人化すること、夜間・休日の対応が多く運用担当者の負荷が大きいこと、セキュリティ設定の抜け漏れが発生すること、組織やベンダー間で連携がうまくいかないことが挙げられます。こうした状態が続くと、運用対応に時間を取られて、本来取り組むべきアーキテクチャの改善や新規サービスの開発になかなか手が回らなくなってしまいます。



こうした課題の背景として多いのが、システムごと・ベンダーごとに個別に運用設計を行っているパターンです。個別に運用設計を行ってしまうと、監視項目や閾値がバラバラになり、アラートの量にも大きなばらつきが出てしまいます。対応手順も統一されていないため、障害時の判断や対応に時間がかかります。運用の品質も安定せず、効率もなかなか上げにくい状況に陥ってしまうのです。組織として安定した運用を実現するためには、個別最適ではなく全体最適の考え方が重要になります。

そこで鍵になるのが、標準的な運用基準を作り組織全体で統一していくことです。ポイントは2つあります。1つ目は、監視基準、対応フロー、セキュリティ設定といった組織としての標準を定義すること。2つ目は、その標準をすべてのシステムに統一して適用することです。標準を作って終わりではなく、運用品質を統一するところまで行って初めて効率化の効果が出始めます。つまり、標準化と統一化はセットで考えることが重要です。

運用を統一する前の状態では、監視基準がバラバラなためアラートが多発して対応に追われていました。セキュリティ設定にもばらつきがあるために抜け漏れが生じ、障害対応の判断が担当者に依存して属人化していました。これに対して、監視やアラートの基準を定義し、セキュリティの共通基準を整備し、障害対応のフローを明確化することで運用の標準化を行います。その結果として、不要なアラートが削減されて対応工数が減少し、セキュリティレベルも組織として一定に保たれます。対応の判断も標準化されるため、属人性を排除でき、運用品質と運用効率を組織として安定させることができます。

横断的な監視基盤とセキュリティの仕組み化

大林：標準的な運用を実現するためには、基準を作るだけでなく全体の状況を把握する仕組みが必要です。AWSにはAmazon CloudWatchの「クロスアカウントオブザーバビリティ」という機能があり、複数のアカウントのログやメトリクスを一元的に集約して、システム全体の状況を1つの画面で確認できます。

具体的には、監視用のOpsアカウントを1つ用意し、そこに全アカウント・全システムのメトリクスとログを集約させる構成を取ります。これにより障害の影響範囲の把握やシステム間の相関分析、原因特定の迅速化が可能になります。



さらに、標準を守らせるための仕組みも重要です。ガイドラインだけでは時間の経過とともに運用品質にばらつきが出てきます。AWS Control Towerやサービスカタログを活用することで、ログ取得の設定やAWS Config、AWS Systems Managerなど組織として標準的なリソースを自動的にデプロイできます。たとえばAWS Control TowerからAWSアカウントを新規作成した際に、そのアカウント作成をトリガーとして標準的なリソースが自動でデプロイされる仕組みを構築できます。新しいアカウントが作成されても最初から同じ運用品質を確保でき、人の運用ではなく仕組みで標準を維持することが可能です。

セキュリティについても組織全体で統制する仕組みが必要です。AWS OrganizationsやAWS Firewall Managerを活用することで、AWS WAFやネットワークファイアウォールといったセキュリティ設定を中央から一括で管理し、全アカウントに適用できます。設定漏れの防止や運用のばらつきの排除、組織としてのセキュリティレベルの維持が実現でき、マルチアカウント環境では特に重要なポイントとなります。

外部監視サービスの活用で運用負荷を最小化する

大林：ここまでご説明したような取り組みによって、アラートの最適化や対応の標準化により日々の運用負荷は確実に下げることができます。しかし、現実的な問題として、アラートはゼロにはなりませんし、システムを運用する以上24時間365日の対応は必ず必要です。標準化によって運用は効率化できても、夜間・休日の対応など人的負荷そのものをなくすことはできません。

そこで次に必要になるのが、外部の力を活用した運用体制の構築です。従来はアラートの監視から一次対応、切り分け、通知までをすべて社内の運用担当者が担っていました。外部の監視サービスを活用すると、アラートの監視や一次対応、切り分けや状況確認といった定型的な運用業務を外部が担当し、社内の運用担当者はエスカレーション対応や影響の判断、恒久対策の検討、運用改善の設計といった判断・改善が必要な業務に集中できるようになります。



NRIネットコムでは24時間365日の監視、障害発生時の一次対応、必要に応じたエスカレーション、運用の標準化設計や改善支援までを担っています。これは内製を代替するサービスではなく、内製開発のスピードを落とさないための運用基盤として機能するものです。夜間・休日の一次対応や定型的な運用作業を外部に任せることで、社内のエンジニアはアーキテクチャの改善や自動化の推進、サービス品質の向上といった本来注力すべき領域に集中できるようになります。

後半のまとめとして、運用を標準化し組織全体で統一すること、すべてを内製で抱え込まず運用の一部を外部サービスで補完すること。この2つの仕組みを組み合わせることで、運用負荷を最小化し内製開発のスピードを落とさない持続可能な運用体制を実現できます。

本日お伝えしたかったポイントは、前半のデザインパートではデザイナーがプロジェクトに伴走することで手戻りを減らし、開発全体の効率を高めるということ。後半の運用パートでは、運用を標準化・統一化し、さらに一部を監視サービスで補完することで運用負荷を軽減し、開発や改善に集中する環境を作るということです。NRIネットコムはデザインからシステムまでワンストップで提供することができます。



デザインからシステムまで、それぞれにお悩みをお持ちの方がいらっしゃいましたら、ぜひご相談ください。
本日はご清聴いただきありがとうございました。

アーカイブ動画・発表資料

イベント本編は、アーカイブ動画を公開しています。また、当日の発表資料も掲載しています。あわせてご覧ください。

▼動画・資料はこちら
内製開発Summit 2026
※動画の視聴にはFindyへのログインが必要です。