﻿<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
    <title>リックソフトブログ</title>
    <link rel="alternate" type="text/html" href="https://www.ricksoft.jp/" />
    <link rel="self" type="application/atom+xml" href="https://www.ricksoft.jp/blog/atom.xml" />
    <id>tag:www.ricksoft.jp,2019-12-24:1</id>
    <updated>2026-06-10T02:30:05Z</updated>
    
    <generator uri="http://www.sixapart.com/movabletype/">Movable Type</generator>


<entry>
    <title>【Agileノウハウでレガシーシステムの強化を実現 】ベトナムの通信会社 Viettel社のアプローチ - リックソフトブログ</title>

    <!-- 記事URLを絶対パスに修正 -->
    <link rel="alternate" type="text/html" href="https://www.ricksoft.jp/blog/articles/001742.html" />

    <id>https://www.ricksoft.jp/blog/articles/001742.html</id>

    <published>2026-06-10T00:37:47Z</published>
    <updated>2026-06-10T02:30:05Z</updated>

    <summary>ベトナム通信最大手Viettel社の基幹システム刷新をアジャイルで実現したBiPlus社の事例紹介</summary>
    <author>
        
		<name>
		
			
			
				
				
				甲斐 博(Hiroshi Kai)
    		
		
		</name>
        
    </author>

    <!-- カテゴリー情報 -->
    
        <category term="エンタープライズIT事情inベトナム" scheme="http://www.sixapart.com/ns/types#category" />
    

    <!-- タグ情報 -->
    

    <!-- 記事のコンテンツ -->
    <content type="html" xml:lang="ja">
        リックソフトの海外事業部の甲斐です。「ベトナム企業と協業」というと、IT業界では「人件費の安い国でのオフショア開発提携先」という文脈で語られることが多いのですが、まったくその印象が覆される日々を送っています。
ベトナムの IT企業の中には、アジャイルや AIなどの先進的な技術・フレームワークを取り入れ、解決難易度の高い課題をクリアしている組織もあるのです。
今回は、リックソフトと資本提携関係にあるベトナムの Atlassian Platinum Solution Partnerである BiPlus社が Viettel（ベトテル）社で実現した、巨大レガシーシステムの拡張・安定稼働実現、および運用コスト削減の事例を紹介します。（＊本記事は、BiPlus社の事例 How BiPlus enhanced viettel&apos;s BCCS system to boost growth in 10 nations をもとに作成しています）

10カ国に展開する通信会社の心臓システムが技術的負債に...どうすれば？

ベトナム国防省が所有・運営する「Viettel（ベトテル）」は、ベトナム国内の携帯電話市場で50％のシェアを誇る、同国最大手の通信会社です。世界で最も急成長している電気通信企業トップ15にも数えられており、2000年代後半からミャンマー、ラオス、東ティモール、ハイチ、ペルー、モザンビークなど、通信インフラが未発達だった国々へ積極的に進出し、成功を収めてきました。
 
こうしたグローバル展開に伴い、複数国における膨大な課金・契約情報と顧客データを一元管理するため、Viettel社は自社で「課金・顧客ケアシステム（BCCS：Billing and Customer Care System）」を開発しました。BCCSは、同社がトップシェアを誇る海外事業の請求・顧客管理を根底から支える、極めて重要な基幹システムです。
しかし、稼働開始から8年が経過し、このシステムは徐々に深刻な「技術的負債」となりました。維持・管理には膨大な労力とコストがかかり、結果として、Viettel社のさらなる事業拡大（高いビジネス目標）に向けて、システムを効率的かつコストを効果的にサポートすることが困難な状況に陥っていたのです。
この差し迫った課題を解決するため、Viettel社はビジネスパートナーとして BiPlus社を指名。システムの拡張性を向上させ、新機能の実装を可能にするシステム強化プロジェクトを共同で始動しました。

8年が経過した基幹システムを強化する上での課題
運用効率の低下、ユーザー体験の悪化、およびメンテナンスコストの増大に直面していた Viettelは、包括的かつ迅速なシステム刷新（アップグレード）を緊急に必要としていました。しかし、これほど大規模で膨大なデータを扱う基幹システムを、極めて限られたスケジュールの中で強化することには、多くの困難が伴いました。
多様なステークホルダーの関与: それぞれ異なるニーズ、優先順位、視点を持つ多くの関係者が深く関わっていたこと。厳しいタイムライン: ビジネス目標を達成するため、迅速な実装と厳しい納期が求められていたこと。膨大なデータ量: さまざまなソースから集約・分析・変換しなければならないデータが極めて大量であったこと。
Viettel社が求めていたのは、「自社のビジネスを停滞させず、日々の業務に支障をきたすことなく、安全にシステムをアップグレードできる解決策」でした。
そこで、レガシーシステムの近代化やアジャイル移行で豊富な実績を持つ BiPlus社がパートナーとして選ばれました。同社は、これら複雑な課題に同時に対処するには「アジャイル（Agile）」アプローチが最適であると判断し、システム改革に着手しました。

効果的なソリューションによるシステムアップグレードの実践
BiPlus社はアジャイル手法を採用し、継続的かつ効率的なデリバリーを実現する最先端テクノロジーを活用して、包括的なシステムアップグレードを実施しました。

1. 期待に応える品質を保証する「アジャイル手法」の採用

BiPlus社は、50名以上の優秀な開発者からなる8つの専任開発チームを編成し、アジャイル手法を導入しました。Viettel社と BiPlus社間の緊密なコミュニケーションを重視し、フィードバックサイクルを高速化することで、進化し続けるビジネスニーズに確実に対応できるシステムを作り上げました。
スクラム（Scrum）フレームワークを実装することで、開発チームは複雑な課題をより小さく管理しやすいタスクへと分解。これにより、開発チームが問題に簡単かつ効率的に対処できるようになっただけでなく、高品質なプロダクトを迅速にデリバリーすることが可能になりました。さらに、過去のプロジェクトにおけるベストプラクティスを応用したことで、開発プロセスをさらに加速させました。

2. スケーラビリティと柔軟性を備えた「最適化された技術スタック」の活用
膨大なデータ量を効率的に処理するため、以下のような信頼性が高く成熟した技術を導入しました。
NoSQL: 多様なデータソースをシームレスに統合。Kafka: リアルタイム統合を合理化し、スムーズなデータフローを実現。Redis: 一時データおよびリアルタイムデータの保存と取得を最適化。
上記技術スタックにより、システムのパフォーマンスに影響を与えることなく継続的なアップグレードや改善が可能となり、高いスケーラビリティ、柔軟性、処理速度を実現しました。

3. スムーズなコミュニケーションを実現する「プロジェクト管理ツール」の活用
BiPlus社の Atlassian Platinum Solution Partnerとしての豊富な実績を活かし、プロジェクト管理ツール（Jira/Confluence等）をフルに活用しました。すべてのチームがリアルタイムでタスクの確認、コメント、進捗管理を行える環境を構築。プロジェクト期間中、ステークホルダーへのタイムリーな情報共有とエンゲージメント維持にも大きく貢献しました。

4. タイムリーなアップデートのための「定期的なアライメント・ミーティング」の実施
定期的なアライメントセッション（同期会議）を設けることで、関係者全員が常に最新情報を共有し、迅速な情報伝達を可能にしました。この協調的なアプローチにより、マイルストーンを予定通りに達成することができました。

新しい柔軟なシステムが、10カ国におけるシームレスなビジネス運営を支援

この取り組みにより、Viettel社は以下の成果を達成しました。
システムの安定維持: Viettelが展開する10カ国すべてにおいて、従来の「BCCS 1.0」システムの安定維持に成功。次世代システムへの移行: 最大1万人規模の従業員と約5,000万人の契約顧客のニーズに対応できる、スケーラブルなアーキテクチャを持つ「BCCS 3.0」へのアップグレードを完了。スムーズな大規模データ移行: 約5,000万人の加入者データ、5,000〜1万人規模の従業員ユーザーデータ、および1日あたり平均1億〜2億件にのぼるデータアクセスボリュームを伴うデータ移行を無事完了。極めて高い稼働率: 年間ダウンタイム「5分未満」という高い安定性を誇る、24時間365日の継続的な安定稼働を実現。圧倒的なスピード感: この基幹システムの刷新・移行プロジェクトは、2025年2月に始まり、同年10月にリリースを完了しました。日本のエンタープライズ開発の常識（数年規模のロードマップ）を覆し、わずか8ヶ月で完遂。これを可能にしたのは、BiPlus社の徹底したアジャイル体制です。
拡張性の高いアーキテクチャ設計と複雑なデータ移行プロジェクトにおける BiPlus社の豊富な経験を活かし、Viettel社の BCCSをより柔軟なシステムへと移行させることに成功しました。このコラボレーションの成功は、Viettel社のような先進的なグローバル企業に対し、カスタマイズされたソリューションを提供する BiPlus社の高度な技術力を証明するものです。

巨大ビジネスの持続的な成長を支える、信頼できるパートナー選び
BiPlus社の専門知識は、国境を越えたシームレスなユーザー体験を提供しつつ、Viettel社の注文管理と顧客データ処理を最適化しました。
BiPlus社は単にシステムをリリースして終わりではなく、現在も引き続き日々のメンテナンス（保守・運用）を主導し、年間ダウンタイム5分未満という極めて高い信頼性を裏側から支え続けています。
リックソフトとしても、資本提携パートナーである BiPlus社が、同社のグローバルな成長戦略に「開発から運用フェーズまで」大きく貢献できていることを誇りに思います。
急速に変化する現代において、テクノロジーはビジネス成長に不可欠です。時代遅れのシステムが「技術的負債」となり競争力を失い、ビジネスの足を引っ張る状況は避けるべきです。
インフラのアップグレード、業務効率化、Atlassianツールやアジャイル導入による開発プロセス改善をお求めの際は、ぜひリックソフトにご相談ください。BiPlus社と密に連携し、お客様のビジネス成長を全力でサポートします。
        
    </content>
</entry>

<entry>
    <title>【Team &apos;26】「使うAI」から「作るAI」へ - Atlassian Studioで組織の&quot;AI民主化&quot;が加速する - リックソフトブログ</title>

    <!-- 記事URLを絶対パスに修正 -->
    <link rel="alternate" type="text/html" href="https://www.ricksoft.jp/blog/articles/001741.html" />

    <id>https://www.ricksoft.jp/blog/articles/001741.html</id>

    <published>2026-06-05T00:08:04Z</published>
    <updated>2026-06-05T06:12:15Z</updated>

    <summary>2026年5月上旬に、米国カリフォルニア州の「アナハイム・コンベンションセンター...</summary>
    <author>
        
		<name>
		
			
			
				
				
				濵田 翔（プロダクト＆サービス開発部）(hamada.sho)
    		
		
		</name>
        
    </author>

    <!-- カテゴリー情報 -->
    
        <category term="Rovo" scheme="http://www.sixapart.com/ns/types#category" />
    
        <category term="イベント" scheme="http://www.sixapart.com/ns/types#category" />
    

    <!-- タグ情報 -->
    

    <!-- 記事のコンテンツ -->
    <content type="html" xml:lang="ja">
        2026年5月上旬に、米国カリフォルニア州の「アナハイム・コンベンションセンター（Anaheim Convention Center）」にて開催された、Atlassianの公式カンファレンス「Team &apos;26」に、リックソフトのメンバーが現地参加しました。

Team &apos;26 Main Stage（Anaheim Convention Center）
会場には世界中から数千人規模のAtlassianユーザーやパートナー、開発者が集まり、Keynoteが行われる朝から、夜のディナー会場まで、話題はほぼAI一色でした。その中でも、私が最も「知りたい、使ってみたい」と感じたのが、Rovo Studio（以下、Studio）です。
https://www.atlassian.com/ja/blog/team26-rovo-studio
本記事では、Team &apos;26における最新情報と、リックソフト社内で進めている検証を踏まえて、Studioの概要と、簡単な利用方法をお届けします。


1.「誰でも使えるAI」から「誰でも作れるAI」の時代へ
ここ数年、AIの話題を耳にしない日はないほど、すさまじいペースで進化してきました。しかしながら、Team &apos;26のスクリーンには、次のような数字が映し出されました。
AI投資から ROIが出ていると確信できている経営層は6%にすぎない知識労働者の 85%が「AIツールはある」と回答する一方、実際に日々のワークフローに組み込めているのは29%AIを「チームメイト」と見なせている人はわずか15%こうした AI投資の断片化のコストは Fortune500全体で1,610億ドル規模に達する（Atlassian調査）
AI投資を成果に結びつけているのは、最新モデルを使っている企業ではない。自社のワークフローに合わせてAIを組み合わせ、エンドツーエンドで業務を回している企業だ、というものです。
Team &apos;26の Keynoteでも、メルセデス・ベンツ社が Rovoエージェントを使ってテスト・欠陥管理担当者の時間の85%を効率化し、品質を90%向上させた事例や、インターメディア社がわずか6つの Rovoエージェントだけで月50時間以上の作業を削減した事例が立て続けに紹介されました。
これらに共通しているのは、汎用の AIチャットを「使った」のではなく、自社のワークフローに溶け込むエージェントや自動化の仕組みを「作った」という点です。
「使うAI」から「作るAI」への転換。これは、コードを書ける一部のエンジニアだけでなく、それぞれの部門の業務を一番理解している人たちの手に取り戻そうとする試みであり、その象徴となるのが、この Studioです。

2.Studioとは何か

Studioスタート画面
[Studioとは、Atlassianプラットフォーム上で AIエージェント、自動化ルール、カスタムアプリを作れる、統合AI開発環境です。]
Atlassian公式ページでは、このように定義されています。
「Rovo スタジオは、あらゆるチームが AI を構築、デプロイ、管理できる統合されたプラットフォームです。エージェントから複雑な自動化まで、コードは不要です」
要点は次の3つです。

(1) 統合された「制作スペース」
これまでの仕組みでは、エージェントを作る Agent Builder、自動化を行う Automation、カスタム拡張を作るForgeという、別々の入口にわかれていました。Studioは、それらを一つの入口（studio.atlassian.com）にまとめ直したものです。

(2) コードを書かない「ノーコード」起点
スクリーンショットの中央にある「What are we building?（何を作りますか？）」というプロンプト欄に、自然言語で課題の内容を書くだけで動き始めます。いわゆる開発環境、ターミナルや webインフラなどの準備は不要です。

(3) Forgeへの展開も容易
ノーコードで作ったアプリをアップデートする際には、そのまま Forge SDKによって本格的なコーディングに移行できます。プロトタイプの作成から本格的な開発が分断せず、シームレスに移行できる設計です。
前提として押さえておきたいのが、Studioは Rovoがベースとなっているという点です。Rovoが有効化されている Atlassian Cloudをご利用の組織であれば、Studioもそのまま利用可能です。

3.Rovo全体における Studioの位置づけ
Studioについての疑問として「Rovoそのものと何が違うのか」「Rovo Devとは別物なのか」といったものがあります。これらを整理すると、Rovoと呼ばれるものの実態は、以下の4つで構成される AIプラットフォームであるということです。


コンポーネント役割

Rovo Search
Jira／Confluence／JSM＋50以上のサードパーティツールを横断するセマンティック検索システム。


Rovo Chat
会話形式での検索・分析・アクションが可能で、150以上の推論ステップと120以上のスキルを持つ。


Rovo Agents
業務プロセスを自動化するエージェント。組織固有の業務をベースに作成可能。


Rovo Studio
上記のエージェント、自動化、アプリ自体を構築するための統合開発環境。



すなわち、Studioは、Rovo全体の中で「使う」側ではなく「作る」側にあたります。Rovo Chatや Rovo Searchは誰でもすぐに使える AI体験ですが、それらを自社の業務に合わせて拡張・カスタマイズする入口となるのが Studioです。

押さえておきたい「3つの違い」
他にも、よく混乱されがちなポイントを整理します。
Rovoと Rovo Dev
Rovoは全社向けの AI検索・チャット・エージェントプラットフォームで、全有償エディションに同梱。一方の Rovo Devは開発者向けのコーディング特化型エージェントで、個別の料金体系を持っています（別プロダクト扱い）。Rovo Devは Atlassian製品と連携し、Bitbucket／GitHubのコードレビューや、トラブルシューティングといった開発支援に特化しています。
■参考（RovoとRovo Devの料金体系）
Rovo usage allowance | Rovo | Atlassian SupportHow billing works for Rovo Dev | Atlassian Support

Studioと Forge


Studioはノーコード／ローコードでの「制作スペース」で、Forgeは開発者向けのインフラ・コーディング基盤（Atlassianクラウド専用のフルマネージド拡張プラットフォーム）です。Studioで作ったアプリはForge上で動作するアプリとしてデプロイされるため、開発者へバトンタッチして機能の拡張を行うこともできます。Studio（自然言語）から Forge（コードベース）への流れは基本的に一方通行ですが、Studio上での繰り返し修正は可能です。
なお、現在、Forgeは使用量ベースの価格モデル（無料枠あり）に移行しています。
▷参考（Forgeの詳細）About Forge 
Studioと既存のAutomation
Jira / Confluenceの機能としての Automationは健在ですが、新たに Studio上で「対話的に自動化ルールを組む」こともできるようになりました。Studioが生成した自動化ルールは、Atlassian Automationの上で動きます。

4.Studioでできること：3つの柱
Studioで作れるものは、大きくAIエージェント／自動化ルール／Forgeアプリの3つに整理されます。Team &apos;26で発表された最新版では、ユーザーは「どれを作るか」を意識する必要すらありませんが、これら3つの柱を見ていきます。

4-1.AIエージェントの作成
例えば、Studioのプロンプト欄に「毎朝8時に Googleカレンダーを確認して、今日やるべきタスクを Jira作業項目として登録したい」と書くだけで、以下を含むカレンダータスク作成エージェントが生成されます。
エージェント名と概要使用するスキル（例：Get Google calendar events、Create work item）動作のステップ会話のきっかけ
日本語のプロンプトをそのまま入力しても、Rovoが自動的に解釈し、必要なドキュメントを検索しながら設計を完了します。手動でゼロから組み立てる手間がなくなり、これまでかかっていた工数が圧倒的に削減されます。

4-2.自動化ルールの作成

Studio Agents一覧（現地撮影）
エージェントを作成すると、それを呼び出すスケジュール自動化ルールもセットで自動生成されます。
上記の例であれば、
ルール名：GoogleカレンダーイベントをJira作業項目として登録トリガー：スケジュール実行（毎週月〜金、8:00AM）アクション1：エージェントを使用（上記のカレンダータスク作成エージェント）アクション2：監査ログに追加（エージェントの動作を記録
といった構成で、ユーザーがレビュー可能な形で出来上がります。エージェント単体ではなく、エージェントと自動化ルールが想定されるフローに沿って設計される点が、Studioの大きな特徴です。
現在はベータ版のため、実行可能な機能に制限があったり、接続できる外部ツールが限られていたりしますが、このあたりは今後拡張される見込みです。

4-3.Forgeアプリの開発（ローコード）

3つ目の柱が、自然言語（プロンプト）で Forgeアプリそのものを作れることです。たとえば「Jiraの依存関係とリスクを可視化するダッシュボードがほしい」と書くと、Studioは次の3フェーズで処理を進めます。
Define（定義）フェーズStudioがドキュメントを自動検索し、アプリのプラン（アプリ名、概要、モジュール、主要機能）を提示します。まずは機能要件・技術要件が自動生成され、これらは、自然言語で何度でも修正できます。
Build（構築）フェーズ「Build app」をクリックすると、Studioが Forgeアプリのコードを生成します。プレビューで UIを確認しながら進めることができ、ビルド時間は通常10分ほど。眺めているだけで、アプリが徐々に構築されていきます。
Publish（公開）フェーズ「Publish」をクリックすれば、Forgeプラットフォーム上へデプロイされ、指定したサイトへインストールできます。

5.Team &apos;26で発表された Studio
ここまでが「これまでのStudio」です。Team &apos;26では、さらにブラッシュアップされた内容が展開され、2026年5月6日に GAとして公開（一般提供開始）されました。

Rovo Agentアーキテクチャ図（現地撮影）

「何を作るか」を意識しなくていい
これまでは、ユーザー自身が「エージェントを作るのか、自動化を組むのか、アプリを作るのか」を決めてから入る設計でした。現在のバージョンでは、目的に応じて、その区別を Studioが自動で行います。
Keynoteで紹介されていたオンボーディング自動化を例にとると、
「新メンバーがチームに入ったら、役割に応じた個別オンボーディング計画をテンプレートとコンテンツから作って、面談時間を確保して、質問に答えて、進捗を追跡してほしい」
このプロンプト1行から、Studioは次の3つを組み合わせて構築してくれます。
自動化ルール：Jiraチケット作成をトリガーに、歓迎動画や業務資料、割当プロジェクト、今後90日の計画を MicrosoftTeamsに投下エージェント：新メンバーからの質問に随時応答ダッシュボードアプリ：マネージャーに対して上記の進捗を可視化
ユーザーが書いたのは「課題」のみ。ここから「何を作るか」は Studio自体が判断するという体験が、新バージョンのポイントです。

あわせて発表された関連機能
MCP（Model Context Protocol）対応：数千の外部スキル・ツールを Rovoエージェントから利用可能Rovo makes AI-native teamwork real for the enterprise - Inside AtlassianTeamwork Graph MCP/CLIの公開：Cursor、Codex、Claude Codeなど任意の AIから同じコンテキストを参照可能https://www.atlassian.com/blog/company-news/teamwork-graph-team-26Agent Permissions in Studio：エージェントの作成者と利用者を、管理者が分離して制御Rovo agent permissions and governance | Rovo | Atlassian SupportMax Mode（より複雑な推論）、Rovo Desktop App、Rovo CLIなど、Rovoそのものの拡張Get started with Rovo Desktop | Rovo | Atlassian Support

6.Studioで&quot;成果&quot;を出している企業／チーム
Team &apos;26の各セッションと公式発表で紹介された、Studio／Rovoエージェントで成果を出している代表的な事例を一覧で整理します。


企業業種成果（1行サマリ）出典

Mercedes-Benz
自動車製造
テスト・欠陥管理で担当者時間の85%を削減、品質指標90%向上
Atlassian社ブログ


Intermedia
クラウド通信
Rovoエージェントで製品リリース支援を効率化、月50時間以上を削減
Atlassian社ブログ


HarperCollins
出版
会議・プロジェクト・ドキュメント間の調整を自動化し、手作業を4分の1に圧縮
Atlassian社ブログ


Cisco
IT／ネットワーク
プログラムマネージャの10時間タスクを15分に短縮
Studio製品ページ


ServiceRocket
ITサービス
Loom議事録からRovoがクリエイティブブリーフを自動生成、マーケティングキャンペーンの立ち上げ生産性が12倍に
Team &apos;26 セッション内


DocuSign
電子契約
リリースノート・テスト・ドキュメント作成の各業務を効率化、ドキュメント／チケット作成時間平均75%短縮
Team &apos;26 セッション内



業種、組織規模、業務カテゴリがいずれも分散している点が注目に値します。製造業から出版・通信・ITまで、業務を問わず具体的な成果が出ています。

7.利用の流れ：5ステップで見る Studio
最後に、実際にどう操作するのかを、5ステップで簡単にご紹介します。

Step0：Studioを開く
Atlassianのアプリスイッチャー（左上の格子アイコン）から「その他（...）」を展開すると、Studioへのリンクがあります。（ハンズオンでは、Studioは別タブで開いて、操作画面と説明資料を左右に並べる方法が推奨されていました）

Step1：スタート画面

Studio起動時エントリ画面「What are we building?」
中央のプロンプト欄に、ユーザーの課題や作りたいものを自然言語で記述します。左のナビには For you（ユーザー専用）／Browse（参照）→ Skills（スキル）／Build（ビルド）→ Apps（アプリ）／Agents（エージェント）／Automation（自動化）などが並びます。
なお、スタート画面では、入力欄の下部に、アプリのアイデアとなるサンプルプロンプトがいくつか提示されます。ゼロから書き出すのが難しいときは、これらをベースにしてみるのもいいかもしれません。

Studioのモーダル版ページ
また、Rovo Chatの中からモーダルで開く形態もあり、資料やチケットを参照中に浮かんだアイデアから対話を始められます。

Step2：対話的ヒアリング

日本語での対話ヒアリング
例えば「アプリを構築したい」とだけ送ると、Studioは3つの観点で深掘りしてくれます。「AIに何を頼めばいいかわからない」「プロンプトを書くのが苦手」という方でも、Studio側から必要な情報を引き出してくれるので、誰でも簡単に始められます。

Step3：App Specification（アプリ仕様書）の自動生成

App Specificationの自動生成画面
対話を通じて要件が固まると、Studioは App Specification（アプリ仕様書）を自動生成します。生成される項目は次のとおりです。
Summary：アプリの概要Modules：使用するモジュール（例：Jira project page、Function(resolver)）CoreCapabilities：主要機能の説明UI：UIコンポーネントと実装方針API・エンドポイント：呼び出すJira Cloud REST APIDatastore：スキーマ、バリデーション、マイグレーション要件
ここが Studioの最も重要なポイントです。ブラックボックスではなく、人間が読める仕様書として中間成果物が提示されるので、アプリのビルド前にレビューや修正を実施できます。この修正もプロンプトで行えるので、「JQLに critical優先度の条件を追加して」「グラフは縦棒ではなく横棒にして」といった形で対話を重ねるだけで、仕様がどんどん洗練されていきます。

Step4：Build app（およそ10分程度）
仕様を承諾して「Build app（ビルド）」をクリックすると、Studioが裏で Forgeアプリのコードを生成し、テストを実行します。通常10分ほどかかり、非同期で処理が実行されます。コードの生成に失敗した場合でも、プロンプトでデバッグ依頼ができます。
Forgeの枠内で構築されるため、出来上がったアプリは Atlassian Cloudの標準的なセキュリティ・ガバナンスに沿って動作します。インフラも含めて自動管理されるので、安心して使い始めることができます。

Step5：アプリ一覧で運用管理

Studioのアプリ一覧画面（実画面のため要確認）
構築済みのアプリは Studioの「すべてのアプリを表示」から一覧で管理できます。各アプリには「アプリを編集」「アプリ詳細を表示」のリンクが用意され、この画面にも「Rovoでアプリを作成」ボタンが設置されています。
上部に「アクセス権のあるアプリがここに表示されます」と記載されているように、アプリ作成者自身だけでなく権限を付与されたメンバーにも表示されるため、組織内での共有・管理も容易です。
ここまで、アプリのコードは一行も書いていません。「課題を伝える → Studioが仕様を整理する→ビルドする」という流れが、Studioの標準的な使い方です。

おわりに：リックソフトとして
Studioはベータ／GAを組み合わせた段階的なリリース中ですが、リックソフトの社内ではすでに具体的なユースケースの検証と社内ナレッジ化を進めています。
「自社で Studioを試したいが、どこから始めるべきか」「ガバナンス面の検討が先に必要なのではないか」「既存の Atlassian構成にどう乗せるか」──こうしたご相談は、ぜひお問い合わせフォームからお問い合わせください。
Rovo Studioにより、技術的な制約を受けることなく、どなたでもアプリを作ることができるようになりました。「使うAI」から「作るAI」への転換は、単にツールを導入するということではなく、組織としての能力を新たに獲得することに他なりません。私たちも、これからの時代へ向けて、お客様とともに歩んでいきたいと考えています。
        
    </content>
</entry>

<entry>
    <title>情報系学部卒じゃない新卒エンジニアがAI・DX室で1年間もがいて気づいたこと - リックソフトブログ</title>

    <!-- 記事URLを絶対パスに修正 -->
    <link rel="alternate" type="text/html" href="https://www.ricksoft.jp/blog/articles/001740.html" />

    <id>https://www.ricksoft.jp/blog/articles/001740.html</id>

    <published>2026-06-02T00:18:42Z</published>
    <updated>2026-06-02T01:25:04Z</updated>

    <summary>AI・DX室の須藤です。2025年に大学を卒業してエンジニアとして新卒でリックソ...</summary>
    <author>
        
		<name>
		
			
			
				
				
				AI・DX室(dx)
    		
		
		</name>
        
    </author>

    <!-- カテゴリー情報 -->
    
        <category term="AI活⽤・業務改善事例" scheme="http://www.sixapart.com/ns/types#category" />
    

    <!-- タグ情報 -->
    

    <!-- 記事のコンテンツ -->
    <content type="html" xml:lang="ja">
        AI・DX室の須藤です。2025年に大学を卒業してエンジニアとして新卒でリックソフトに入社しました。
AI・DX室は、リックソフトの社内課題の特定・改善や AI活用による業務改革を通じて生産性向上を推進する部署です。データを活用した意思決定支援や各部署との連携を通じて、会社全体の DXをリードしています。
情報系の学部出身でない私が、AI・DX室に配属されてもうすぐ1年が経とうとしています。そんな私がこの1年間でどんなことをして、何につまずき、何を学んだのかについて振り返ってみます。


入社から1年間で取り組んだこと
リックソフトの新卒社員は、入社後約3ヶ月の研修が課されます。7月に配属され、実務がスタートします。
配属された AI・DX室では「課題を見つける → 検証する → 実装する → リリースする」という流れで業務を進めていきます。私もこのサイクルを繰り返しながら仕事を覚えていきました。
2025年７月から2026年５月現在まで、約1年間で携わった業務は、主に以下の通りです。
残業申請チェック業務の自動化◦ 勤怠情報と残業申請の相違が無いかというチェック業務を、iPaaSツールの「Workato」を使って自動化しました。　▷ その時のブログ【月6時間削減】人事総務の残業申請チェック業務をノーコードで自動化｜ジョブカン×Workato取引先企業の与信・反社チェックの自動化◦ 取引先企業の与信能力や反社関係の問題を、Workatoと AIで自動的にチェックする業務を実現しました。◦ 依頼者・担当者合わせて、１か月あたり約5時間の工数を削減しました（約10件/月）。　▷ その時のブログAIエージェント×Workato Goで劇的変化！申請業務を効率化するDX最新事例人の反社チェック業務の自動化◦ 協力会社の方や採用候補者に対して反社会的勢力団体との関りが無いかをチェックする業務をこれまで Workato、AIを用いて自動化しました。◦ 1か月あたり約3時間の工数を削減しました（約100件/月）。社内向け Jiraプロジェクトの設定◦ 要件定義を元に、Jiraのワークフロー、カスタムフィールド、画面の設定を行いました。◦ Jiraの設定は自由度が高く複雑なため、苦労しました。他、さまざまな AI・Atlassian製品・Workatoに関わる検証
また、現在は社内システムの API認証方法の変更や、社内に蓄積されたナレッジへのアクセスをより効率化するための手段の検討も進めています。
これらの業務を通じて多くのことを学びましたが、同時にいくつかの壁にもぶつかりました。

ひとつめの課題：完璧主義ゆえ、自分で抱え込みがち
特に苦労したのは、社内Confluenceや Slackに溜まっている経験・判断・情報へ簡単にアクセスできるようなシステムの検討・検証に取り組んでいた時期です。
私は、業務プロセスが具体的になっている課題の解決策発見・解決には手応えを感じ、「得意な業務だな」と自信を持てていました。一方、「どの分野を対象としたほうがいいのか」、「どんな手法があるのか」といった、答えのない問いを扱う調査業務は抽象度が高く、苦手意識がありました。
あるとき、成果物がほとんど作れなくなり、進捗ゼロの日が続いてしまいました。しかし、自分の完璧主義な性格で「全部自分でやらないと」「上司の時間を奪うのは申し訳ない」と考えてしまい、上司に相談できない状況でした。
そんな時、上司から『個人の工数ではなく、組織全体の工数で考えてほしい。新卒一人で抱え込むより、うまく周りを使った方が、時間も質も結果として良くなる』という言葉をもらいました。
この言葉をきっかけに、迷ったり困ったりしたタイミングで、すぐに上司の意見をもらうように徐々に意識を変えていきました。コミュニケーションが増えたことで、現在は調査の方向性も定まり、少しずつ前に進めています。

ふたつめの壁：AIに頼りすぎた失敗と気づき
この1年間での最大の失敗は、社内システムの API認証方式を変更する際の設計業務での出来事です。
本来、私が仕様を深く理解した上で設計を固め、開発担当者に渡すべきでしたが、仕様をあまり理解していない状態で、AIに生成させた設計書をそのまま提出してしまいました。その結果、作った設計書に対して説明も十分にできず、自力で修正もできない事態を招いてしまいました。
その後、改めて OAuthのフローを地道に学習し、自分の言葉で設計書を作り直したところ、プロジェクトはスムーズに進行しました。
この経験から、「わからないことをAI任せにすると、かえって遠回りになる」という教訓を得ました。
一見遠回りに見えても、まずは自分の頭で構造を理解することがとても大切で、AIはあくまで道具であり、理解した上で使ってこそ力を発揮するということを身をもって学ぶことができました。

2年目に向けて
この1年間は、本当に多くのことを経験し、学びました。
技術面での知識や実装スキルも確かに身についたのですが、振り返ってみると社会人としての成長の方が自分の中では大きかったように感じています。
具体的には、「一人で抱え込まず、早めに周りを頼ること」、そしてミスをしたときに「なぜそうなったのか」「どうすればよかったのか」を考える姿勢です。実際、指摘を受けることも何度もありましたが、そのたびに振り返ることで少しずつ改善できてきたと感じています。今も完璧にできているわけではありませんが、こうした考え方を持てるようになったこと自体が、1年前と比べた大きな変化だと思っています。
こうした経験を踏まえて、1年前の自分に伝えたいのは「とりあえず動いてみること」です。
何かアイデアが浮かんだときや考えがまとまらないとき、頭の中で抱え込んでしまいがちですが、それでは何も進まないということを学びました。
こういう時は今どういう状態なのか頭の中を言語化し、誰かに共有することで自分以外の視点の意見が入り、解像度が上がっていきます。
 
リックソフトは AIをさらに活用していくフェーズにあり、AI・DX室の役割も今後ますます大きくなっていきます。その一員として、できることの幅を広げながら、より活躍できるよう努めていきたいと思います。
        
    </content>
</entry>

<entry>
    <title>【Team &apos;26】AtlassianとDropbox 2社の事例から読み解くAI活用のヒント - リックソフトブログ</title>

    <!-- 記事URLを絶対パスに修正 -->
    <link rel="alternate" type="text/html" href="https://www.ricksoft.jp/blog/articles/001739.html" />

    <id>https://www.ricksoft.jp/blog/articles/001739.html</id>

    <published>2026-05-25T00:30:20Z</published>
    <updated>2026-05-27T09:01:45Z</updated>

    <summary>私は Atlassian製品のセールスエンジニアという立場上、お客様から「Rov...</summary>
    <author>
        
		<name>
		
			
			
				
				
				やました(yamashita)
    		
		
		</name>
        
    </author>

    <!-- カテゴリー情報 -->
    
        <category term="AI活⽤・業務改善事例" scheme="http://www.sixapart.com/ns/types#category" />
    
        <category term="イベント" scheme="http://www.sixapart.com/ns/types#category" />
    

    <!-- タグ情報 -->
    

    <!-- 記事のコンテンツ -->
    <content type="html" xml:lang="ja">
        <![CDATA[私は Atlassian製品のセールスエンジニアという立場上、お客様から「Rovoをどう活用していったらいいのか？」という相談をいただきます。本記事では、年次カンファレンス「Atlassian Team '26」で聴講した事例セッションから、Atlassian Cloudと AIの活用ヒントを考察したいと思います。


AIが働き方を再定義するなか、コラボレーションのあり方の重要性はかつてないほど高まっています。 「How Dropbox is designing intentional work in the AI era with Loom （DropboxがLoomと共に AI時代に"意図的な働き方"をデザインする方法）」というタイトルで行われたセッションでは、Atlassian社の Avani Prabhakar氏が、DropboxのAllison Vendt氏と対談し、Dropboxが Loomを軸に AI時代の「意図的な働き方 (intentional work) 」をどう設計しているかを議論しました。

 Loomとは?
Atlassianが提供する非同期録画コミュニケーションツールです。https://www.ricksoft.jp/atlassian/loom/
Jira, Confluence, Atlassian Guard , Rovo のアプリセット「Teamwork Collection」にも内包されています。


Atlassian社　AI利用は「Superuserの定義に達しているか」が指標
まず Atlassian自体が AI利用に対してどのようなアプローチを取っているかという点が議論され、私やリックソフト社内のAI活用においても非常に参考となる話が聞けました。
Rovoを始めとする AIサービス提供側としての Atlassianは、「Customer Zero」アプローチを掲げています。顧客に製品を届ける前に、自社社員が日常的に AIを使い倒すことで、製品リリース前に本物の知見を得る体制を取っているそうです。Atlassian社員の 99% が AIを日常業務で利用 しており、評価軸は「AIを使っているか」から「Superuserの定義に達しているか (高頻度+高度機能の連鎖利用)」へ変更したという説明がありました。もはや AIは「利用するかどうか」ではなく「いかに使いこなしているか」の時代にとっくに突入しているんだ、という、私が日々感じていることの裏付けがとれた印象でした。


一方で、Atlassianが業界全体を対象に実施した調査では「84%のエグゼクティブは AIを依然として個人生産性向上のために投資しており、チームレベルでの AI活用に注力していると答えたのはたった 24%のみ」という結果が明らかになりました。
要は、AIを個人レベルで場当たり的に使用しているのが現状であり、チーム生産性の向上に貢献できるような使い方ができていない、ということではないでしょうか。これは多くの組織の肌感覚とも合致する点だと思います。この、「チーム生産性の向上」が基本思想として設計されているのがまさに今回の Team '26でフォーカスされていた「Teamwork Graph」なのかなと感じました。

フレームワークと AI Ready
AI活用におけるフレームワークを「タスク/スキル/ロール」の 3層で構成した場合、まずは「タスク (=ワークフロー)」から始めて記録・計測し、スキル定義へつなげ、ロールは実験で見極めましょう、というメッセージがありました。ワークフローを視覚化し、その中で AIが活用できるポイントを探っていく。ここから始めるフレームワークは 2025年のイベントでも Atlassianが提唱していた手法であり、リックソフトでも実践しています。
このフレームワークを実践するための前提条件として、「AI Ready」の体制を整えること。これが重要だとも説いていました。AIの利用にはコンテキスト (文脈) がすごく重要なので、具体的には非同期・ドキュメント文化・コンテキスト層を整えましょうということになります。
既に Atlassian Cloudをご利用になっている皆様でしたらここで「ああ、LoomとConfluence/JiraとTeamwork Graphのこと言ってるな」という風にピンとくると思います。

Dropbox社「Loom活用で 13,000以上のミーティング時間削減」
前述の非同期コミュニケーションの事例として、Atlassianと Dropboxの Loom活用事例が紹介されました。Loomは Teamwork Collectionのいち製品として組み込まれていますので、「Teamwork Collectionを契約したから Loomがついてきちゃったけど、イマイチ使いこなせてない」という方にも是非参考にしていただきたい内容です。
Atlassianでは、Loomは単なる動画ツールではなく、ミーティングを置き換える「非同期インフラ」ととらえ、会議の 30%相当を非同期化しています。Loomの自動文字起こし → Confluenceページ自動生成 → Jiraチケット自動起票という連鎖ワークフローを実例として紹介していました。ちなみにここの「自動文字起こし」については Loomが持つ AI機能がやってくれます。
Dropboxでは、全社員の約半数が Loomで能動的にコンテンツを作成し、「13,000以上のミーティング相当の時間を削減」を実現したということです。また、ファイナンス部門では当初、SOP (標準業務手順書) 自動生成のために新たなツールの導入を検討していたが、Loomで SOP自動生成のための条件を満たせるということがわかったためツールの採用を見送ったということです。この Loomによる SOP自動生成機能も、Loomの AI機能として提供されているものです。私もこの機能を最初に見たときはその品質の高さに結構驚きました（もちろん、Confluenceと連携します）。
もうひとつ面白い視点だなと思ったのは、リーダーが「軽い社内コミュニケーション」をLoomで投げかけることで、リモート環境特有の「経営層と現場の距離」を埋める効果があったという点です。
この点についてはAtlassianも同意しており、リアル会議では発言が少なく静かなメンバーから、Loomを通じて価値ある示唆が出てきやすくなる、という構造が生まれるという効果もあるそうです。リモートより対面の方が距離が縮まるという論旨で、出社回帰がグローバルレベルで進んでいますが、「こういった側面もあるんだな」と気付かされたポイントではありました。

AI Working Agreementと AI Retroという「明文化された運用ルール」
前段でフレームワークの話をしましたが、いざ実践する時には AIと人間の役割分担を「書き出して合意する」プロセスをチーム単位で行いましょう、という説明がありました。
AI Working Agreement: 基本的な運用ルールです。例えば採用チームに対し、「候補者対応のどこで AIを使うか」「データをどこに保存しないか」「コピー&amp;ペーストで持ち込んではいけないデータ範囲」など、利用を推奨する場面・利用してはいけない場面を詳細に明文化します。AI Retro: スプリント/機能リリース後に「どこで AIを使えばよかったか」「どこではAIが機能しなかったか」を振り返り、次のサイクル前に記録する。効果としては、両プラクティスとも適用チームで 20%程度の効率向上が観測されている。
この明文化については Confluenceが最適かなと思いますが、どちらかというと運用の話なので、それぞれの組織でベストな方法を模索する必要があると思います。

セッションのまとめ
最後に、本セッションの要点をまとめます。
Customer Zeroアプローチ：AIは「使うかどうか」ではなく「いかに使いこなすか」のフェーズ。Atlassian社員の 99%が日常利用し、評価軸も Superuser基準へ移行。ただし、チームレベルでの活用に注力している組織は 24%にとどまり、個人→チームへの昇華が課題。フレームワークとAI Ready：「タスク → スキル → ロール」の順で着手し、非同期・ドキュメント文化・コンテキスト層を前提整備。Atlassian Cloudでは、Loom ＋ Confluence/Jira ＋ Teamwork Graphが基盤。Loomによる非同期化：会議の30%を非同期化し、文字起こし → Confluence → Jira の連鎖ワークフローを実現。SOP自動生成やリーダーの社内発信など用途が拡大。AI Working Agreement &amp; AI Retro：チーム単位で AI役割分担・利用箇所を明文化し、サイクルごとに振り返る。適用チームで約20%の効率向上。
総括すると、AIの効果を最大化するには個人の生産性向上にとどまらず、チーム単位での運用設計と文化づくりが不可欠です。本記事が皆様の AI活用のヒントとなり、組織改善やビジネス向上のきっかけとなれば幸いです。]]>
        
    </content>
</entry>

<entry>
    <title>【Team &apos;26】マツダ株式会社が登壇！Teamwork Graphで実現する「ツールではなく仕事に焦点を当てる」AXの姿 - リックソフトブログ</title>

    <!-- 記事URLを絶対パスに修正 -->
    <link rel="alternate" type="text/html" href="https://www.ricksoft.jp/blog/articles/001738.html" />

    <id>https://www.ricksoft.jp/blog/articles/001738.html</id>

    <published>2026-05-18T01:05:19Z</published>
    <updated>2026-06-10T02:26:16Z</updated>

    <summary>Team &apos;26でマツダが発表したTeamwork Graphによる不具合管理改革の取り組みをご紹介</summary>
    <author>
        
		<name>
		
			
			
				
				
				やました(yamashita)
    		
		
		</name>
        
    </author>

    <!-- カテゴリー情報 -->
    
        <category term="AI活⽤・業務改善事例" scheme="http://www.sixapart.com/ns/types#category" />
    
        <category term="Jira" scheme="http://www.sixapart.com/ns/types#category" />
    
        <category term="イベント" scheme="http://www.sixapart.com/ns/types#category" />
    

    <!-- タグ情報 -->
    

    <!-- 記事のコンテンツ -->
    <content type="html" xml:lang="ja">
        --本ブログはAtlassianの&quot;Teamwork Graph&quot;活用方法を知りたい方向けの内容となっています--

Atlassian 社主催のグローバル年次イベント「Team &apos;26 Anaheim」は「Teamwork Graph」一色でした。Teamwork Graph は、Atlassianの統一AIデータ基盤で、クラウド版製品のユーザ同士の関係性をデータ化し、AI機能の背骨ともいえる機能です。イベント期間中は、Atlassian の強い思いを感じた 1 週間でした。
今回の発表で、Teamwork Graph がチームと AI をつなぐ層となり、その層がプラットフォームとして解放されることで、Atlassian のデータ基盤の上にユーザー独自のエクスペリエンスを構築できるようになったと明らかになりました。まさに、Atlassianが提唱する哲学としての System of Work（仕事のつなぎ方）が具現化されたアーキテクチャと言えます。
日本の自動車メーカーであるマツダは、早くもこの Teamwork Graph の社内活用に取り組んでおられます。その取り組みの様子を Team &apos;26 のシアターセッションで共有していただきました。
本ブログではその内容をご紹介したいと思います。


セッション概要


項目内容

セッション名（原題）
Streamline defect management: How Mazda leverages Teamwork Graph to drive out defects


登壇者
マツダ株式会社 MAXプロジェクト室主幹　 茨木 浩司 氏*(MAX: Mazda AI Transformationの略)


ファシリテーター
Atlassian社 Razia Khan 氏


日時
2026年5月6日(水) 16:30〜16:45（現地時間）


会場
Expo Theater C


セッション形式
シアターセッション（15分）


共同開発
Ricksoft




ツールではなく、仕事に焦点を当てる
今回ご登壇されたマツダの茨木様は、全社のAI活用推進組織&quot;MAXプロジェクト室&quot;全社AX推進統括責任者 という役割を担っておられます。
「現在マツダが置かれている状況・課題をどのように AX していったのか」「その根底にある原則は何なのか」といった点について、全体を通して「ツールではなく、仕事に焦点を当てる」という視点でお話しされていました。

マツダの現状と課題
マツダが今置かれている状況として、主に以下の 4 点を挙げられていました。
自動車開発のSDV （ソフトウェア定義車両）化により、制御が車両全体に及ぶマルチソリューション戦略（複数の技術経路を並行追求）130 を超える市場ごとの要件・規制を管理する必要がある→ エンジニアの仕事は 「断片化・動的化」している
では、この課題に対して、マツダはどのように対応されたのでしょうか。

着手したのは「不具合管理」
最初にターゲットにしたのは「不具合管理」でした。その理由としては次の 3 つです。
&quot;search work&quot; の削減：要件・証跡探しに時間がかかりすぎていた&quot;miss risk&quot; の削減：関連要件を見落とすと誤った判断につながる&quot;person dependency&quot; の削減：コンテキストが特定の人の頭の中にある状態を解消したい
ひとつの不具合が要件→設計→コード→テスト→サービスまで波及する複雑さを持つにもかかわらず、現実のツールチェーンはサイロ化しています（Codebeamer / Confluence / Bitbucket / Jira）。したがって、整合・影響分析するには、ツール切り替えと手作業のコピペが必要でした。
まずはここから改善を始める、という構想で今回のプロジェクトがスタートしました。

 Codebeamer とは？
Codebeamer は、PTC 社が提供する ALM（Application Lifecycle Management）ツールで、ISO 26262 や Automotive SPICE といった厳格な規格対応が求められる自動車・医療機器などの開発現場で広く採用されています。


解決策として選んだ Teamwork Graph

「サイロ化解消」というと、真っ先に思い浮かぶのは「ツールの統廃合」です（私も普段セールスエンジニアとしてお客様に真っ先に提案している解決策です）。しかしながら、マツダの運用において、Codebeamer / Confluence / Bitbucket / Jira それぞれのツールはすでに重要な運用を担っており、個々に存在意義を持っています。
そこで解決策として選択した方法は、ツールの統廃合ではなく、Teamwork Graph で Codebeamer と Atlassian Cloud をつなぐ というものでした。
実例の紹介として、Jira の中に『Defect Context Panel』という UI を構築してサイロ化を解消した様子を、デモを交えてご紹介されました。
実装したもの：
UI：Defect Context Panel中身：Custom Rovo Agent （自社の Teamwork Graph に根ざしたエージェント）
アーキテクチャのポイント：
双方向（Ingest / Extract）の拡張ポイントが顧客に開かれている上に乗せられるもの：Custom experience / Rovo / Automate
セッションで紹介されたデモ：
-Link from Jira：Jira から類似課題＋関連 Codebeamer 要件を自動推薦／ワンクリックで紐付け- Link from Codebeamer：逆方向のリンクも対応- Ask Rovo Agent：統合された文脈に対し自然言語で問い合わせ、関連タスクの担当者を即座に返す
このエクスペリエンスは、「常に最新の文脈を理解しているデジタルエキスパートが隣にいる」体験 とのことです。
リックソフトは、このマツダの取り組みに対して、ソリューションパートナーとしてお手伝いさせていただいております。

このセッションから得られた学び
「業務最適とツールの活用」という視点では、ワンプラットフォーム vs インテグレーションという構図が繰り返されてきていると思いますが、今回のマツダのセッションでは「Codebeamer を Jira に置き換えるのではなく、Teamwork Graph で &quot;文脈として&quot; つなぐ」という手法がとられたことを知りました。
とくに製造業においては、機能安全規格（ISO 26262・ASPICE）対応の ALM が既に運用されている現場が多いと思います。このような環境ではマツダの事例が最適解であると感じました。
また、AI の業務利用が当たり前になってきた今、Rovo が「自社の Teamwork Graph に根ざしたエージェント」という部分で他サービスと差別化される点について、改めて再認識することができました。

最後に
茨木様はセッションの最後に &quot;Mazda has a long history, but we are still learning&quot; というメッセージを伝えておられました。マツダには「飽くなき挑戦」という企業風土があると聞き及んでいます。この言葉をAI時代にも体現しているということがわかるメッセージでした。
このマツダのメッセージを、私も、私たち リックソフト も、今後の業務に活かしていきたいと思います。
        
    </content>
</entry>

<entry>
    <title>【Atlassian 年次イベント】Team &apos;26 Anaheim に参加しています！ - リックソフトブログ</title>

    <!-- 記事URLを絶対パスに修正 -->
    <link rel="alternate" type="text/html" href="https://www.ricksoft.jp/blog/articles/001737.html" />

    <id>https://www.ricksoft.jp/blog/articles/001737.html</id>

    <published>2026-05-07T01:42:24Z</published>
    <updated>2026-05-07T02:27:09Z</updated>

    <summary>リックソフトのセールスエンジニアの山下です。今年初めて Atlassian 社主...</summary>
    <author>
        
		<name>
		
			
			
				
				
				やました(yamashita)
    		
		
		</name>
        
    </author>

    <!-- カテゴリー情報 -->
    
        <category term="イベント" scheme="http://www.sixapart.com/ns/types#category" />
    

    <!-- タグ情報 -->
    

    <!-- 記事のコンテンツ -->
    <content type="html" xml:lang="ja">
        リックソフトのセールスエンジニアの山下です。今年初めて Atlassian 社主催のグローバル年次イベント「Team &apos;26 Anaheim」に参加しています。まずは、会場レポートを現地からお届けしたいと思います。
皆様の中で「まだ参加したことがないけれど、次回是非参加したい！」という方向けに、この記事で雰囲気が伝われば幸いです。

Atlassian Team &apos;26 Anaheim 会場の様子

今回 Team &apos;26 が開催されたのはアメリカの Anaheim、ディズニーの真裏に存在するコンベンションセンターです。カリフォルニアらしいパームツリーと Atlassian の看板がお出迎えしてくれます。

会場の中に入ると、カラフルな team モニュメントが。音楽もガンガンに流れており、気分が上がります。

入口付近に、フォトブースのコーナーがあり、結構な行列ができていました。素通りしちゃったので、具体的にどんなブースかは未調査です...

会場にはパートナーブースが軒を連ねているのですが、Atlassian 社も大々的にブース展示しています。私も後ほど、セッション内容を深堀りするために訪れようと思っています。

会場は結構広いので、Team 公式モバイルアプリのマップを使います。お目当てのブースがあればこちらで確認するのが便利です。このアプリには、自分がスケジューリングしたセッションのカレンダーや、セッションの日本語同時通訳機能があり、会期中は手放せない相棒となりそうです。

この記事は、現地時間の 5/5 16時頃（日本時間5月6日午前8時）書いていますが、Team &apos;26 はこのあとの 17:30 から行われる Opening Keynote からが本番です。
毎年この Team イベントでは、大きなリリースの発表があります。また、展示ブース会場内に設置されたシアターセッションやトレーニングセッションは現地に足を運ばないと体験できません。私もそれらを中心に、このリックソフトブログにて参加レポートをお届けする予定です。
今後の記事をお楽しみに！

        
    </content>
</entry>

<entry>
    <title>2026年春、ベトナムで感じた「AI熱」とBiplusの本気度 ――ベトナムITイベントレポ - リックソフトブログ</title>

    <!-- 記事URLを絶対パスに修正 -->
    <link rel="alternate" type="text/html" href="https://www.ricksoft.jp/blog/articles/001736.html" />

    <id>https://www.ricksoft.jp/blog/articles/001736.html</id>

    <published>2026-04-23T04:55:03Z</published>
    <updated>2026-04-23T06:10:43Z</updated>

    <summary>-- この記事は、ベトナムのIT企業事情・AI活用事情に関心がある方に向けた内容...</summary>
    <author>
        
		<name>
		
			
			
				
				
				甲斐 博(Hiroshi Kai)
    		
		
		</name>
        
    </author>

    <!-- カテゴリー情報 -->
    
        <category term="エンタープライズIT事情inベトナム" scheme="http://www.sixapart.com/ns/types#category" />
    

    <!-- タグ情報 -->
    

    <!-- 記事のコンテンツ -->
    <content type="html" xml:lang="ja">
        -- この記事は、ベトナムのIT企業事情・AI活用事情に関心がある方に向けた内容となっています。 ベトナムに事業所のある方、IT分野でベトナム企業と取引のある方はぜひ一読ください --
2026年3月26日にベトナムのホーチミン、4月2日にハノイで行われた、ベトナムのAtlassian Solution PartnerであるBiplus社主催のビジネスカンファレンス「AI in Action from Hype to Real Business Outcomes」に参加してきました。
このイベントは、&quot;最新のAI技術がいかにビジネスプロセスを変革するか&quot;をテーマにした、非常に熱量の高いビジネスイベントです。ベトナムのIT・ソフトウェア企業、ITコンサル・専門家、Atlassianツールの活用に関心があるビジネスマンやエンジニアが参加しました。会場では業界のリーダーによる基調講演をはじめ、具体的なAI活用事例のセッションや、参加者同士での活発な情報交換が行われました。
「ベトナム」「IT」という２つのキーワードからは、人件費を削減目的のオフショア開発先とイメージしていましたが、そのイメージが覆る体験となりました。本記事では、その様子をお伝えします。

 リックソフトはベトナムのAtlassian Platinum Solution Partner企業「BiPlus Software社」と業務提携をしています。
▷詳細：ニュースリリース：20251218 ベトナム企業のBiPlus Softwareとの資本業務提携のお知らせ


準備前から高い熱量
前日の設営に参加しまして、まず会場について感じたことは「お！ 派手だー」でした。まるでコンサート会場に来た気分になったのです。  それもそのはず、照明やミキサーもいて、準備中は EDM やテイラー・スウィフト、懐かしい Black Eyed Peasなどが流れていました。
ハコは中学の体育館サイズ、豊洲 PIT くらいの広さでした。その中で体を揺らしながら設営していると、思わず「いいねえ」「明日が楽しみだ〜」と感じたのは事実です。
イベント当日。
両会場とも、至るところにパネルや記念撮影スポットがあり、そこがわりと埋まるんです。  正直、びっくりしました。「なんで混んでいるのに並ぶの？」と聞くと、「楽しそうだから」とのこと。  たしかに、写真を撮るときは顔が緩むのは事実ですよね。  それが狙いだとしたら「やるなあ」と思いましたし、自分もその場で周りの方を写真に誘いました（笑）

イベントの世界観を切り取るフォトブース


ネットワーキングの時間には、デモブースで会話しているときの熱量がとても高いのが印象的でした。  ある方のセッションの質問に対して、第三者も自社の事例を会話に乗せて共有し、参加している顧客同士で情報交換が行われていたのが特に印象に残っています。  ホーチミン・ハノイ合わせて 485 名が参加してくれたそうです。


Keynote では、多くの方がスライドをスマホで記録していました。（中にはKeynoteを動画を撮っている人も......）

重要スライドは一斉にカメラが上がる瞬間

Keynote で特に撮影が多かったのが、こちらの AI Native Solution のブループリントです。

この１枚が、議論のベースになる設計図

※画像は和訳したものになります

「DATA が優先」はベトナムITコンサルでは共通認識
登壇者は、自分が思っていた以上に DATA について熱く語っていました。参加していたベトナムの IT コンサルの方数社に話を聞いてみたところ、  「まずは DATA を整理するのが優先だよ」  という声が多く聞かれました。
「何を AI 化するか」という議論が生じると同時に、データの整理・分析といったデータ戦略にしっかりフォーカスしているようです。  自分自身も正データ・ゴールデンデータ（信頼性の高いマスターデータ）の重要性はわかっていたつもりでしたが、どうしても AI で課題をどう解決するかという「方法」を優先して考えていました。  しかし、今回 AI の構造について調査した結果、長期的なビジネス価値という観点で言えば、データ戦略こそが大事だと学びました。
AI ソリューションは「手段」: 技術は日々進化し、ツールは後から入れ替え可能です。データ戦略は「資産の管理」: 自社にしかない独自のデータこそが競合優位性になります。
この戦略がしっかりしていれば、どんな新しい AI が登場しても柔軟に対応できるはずだと感じた次第です。
やはり、こちらの説明シーンも撮影している人が多かったです。

データこそが競争優位の源泉だと訴える一枚

今までベトナムのエンジニアに対しては、オフショア開発先として「コスト削減」の側面を優先して見ていましたが、  実際には AI を活用した高付加価値な取り組みへの意識がとても高いと感じました。  そんな彼らを、日本の皆さんのプロジェクトにも上手く巻き込める日が、もうすぐ来るだろうと実感しました。
雑談も含め、ベトナムについて興味がありましたら、ぜひ甲斐までご連絡ください。


        
    </content>
</entry>

<entry>
    <title>5,000名以上のエンタープライズで Jira / Confluenceを選ぶ理由 ― 情報ガバナンスとセキュリティを両立する Atlassian Guard活用術 - リックソフトブログ</title>

    <!-- 記事URLを絶対パスに修正 -->
    <link rel="alternate" type="text/html" href="https://www.ricksoft.jp/blog/articles/001735.html" />

    <id>https://www.ricksoft.jp/blog/articles/001735.html</id>

    <published>2026-04-15T00:46:20Z</published>
    <updated>2026-04-15T04:53:06Z</updated>

    <summary>「チーム内での情報共有はスムーズになったが、全社的なガバナンスが効かなくなってき...</summary>
    <author>
        
		<name>
		
			
			
				
				
				越谷 美奈(mina koshiya)
    		
		
		</name>
        
    </author>

    <!-- カテゴリー情報 -->
    
        <category term="Confluence" scheme="http://www.sixapart.com/ns/types#category" />
    
        <category term="Jira" scheme="http://www.sixapart.com/ns/types#category" />
    

    <!-- タグ情報 -->
    

    <!-- 記事のコンテンツ -->
    <content type="html" xml:lang="ja">
        「チーム内での情報共有はスムーズになったが、全社的なガバナンスが効かなくなってきた」「部署ごとにツールが乱立し、二重ログインや管理コストが増大している」
従業員数が 5,000名を超えるようなエンタープライズ企業において、ツール選定は単なる「使い勝手」の比較では済みません。個人の生産性を超えた先にある、「組織としての統制」と「セキュリティの統合」が成否を分けます。
本記事では、NTTドコモ様や LINEヤフー様など、国内屈指の巨大組織がなぜ Atlassian（Jira / Confluence）を採用し続けているのか、その選定条件を紹介します。

エンタープライズが求める「ガバナンスとセキュリティ」の統制
個人や小規模チーム向けのツールは、直感的な操作性に優れています。しかし、数千人規模の運用となると、個別の管理ではリスクが膨大になります。そこで不可欠なのが、Atlassianのエンタープライズ向けセキュリティとガバナンスの一元管理ツール「Atlassian Guard（アトラシアン・ガード）」です。





Atlassian Guard
Atlassian Guard｜Jira / Confluenceのセキュリティとガバナンスを一元管理
部門やチームごとにバラバラに使われているAtlassian Cloud製品の セキュリティとガバナンスを一元管理し、エンタープライズレベルに 引き上げるソリューションの詳細はこちら


Atlassian Guardを詳しく見る



.case-banner {
  display: block;
  max-width: 780px;              /* 全体の最大幅を適度に制限 */
  margin: 0px auto;             /* 上下マージン＋中央寄せ */
  text-decoration: none;
  color: #3b2f00;                /* 全体の文字色（濃いブラウン寄り） */
  font-family: inherit;
}
.case-banner a{text-decoration: none!important;}
.case-banner__inner {
  display: flex;
  align-items: center;
  gap: 18px;
  padding: 14px 16px;
  border-radius: 10px;
  /* イエロー〜オレンジ系グラデーション（Yahoo版と同じトーン） */
  background: linear-gradient(135deg, #fff7d6 0%, #ffe08a 45%, #ffb347 100%);
  box-shadow: 0 4px 12px rgba(0,0,0,0.10);
  box-sizing: border-box;
  transition: transform 0.15s ease, box-shadow 0.15s ease, opacity 0.15s ease;
}
.case-banner__inner a{text-decoration: none!important; line-height: 140%;}
/* Guard用ブルーグラデーション */
.case-banner__inner--guard {
  background: linear-gradient(135deg, #e5f0ff 0%, #7aa9ff 45%, #3056d3 100%)!important;
}
/* Guard用ラベル配色 */
.case-banner__label--guard {
  border: 1px solid rgba(15,23,42,0.25)!important;
  background: rgba(255,255,255,0.85)!important;
  color: #1e3a8a!important;
}
.case-banner__cta--guard {
  background: rgba(255,255,255,0.95)!important;
  color: #1d4ed8!important;
  border: 1px solid #1d4ed8!important;
}
/*
.case-banner:hover .case-banner__cta--guard {
  background: #1d4ed8!important;
  color: #ffffff!important;
}
*/
.case-banner__cta--guard:hover {
  background: #1d4ed8!important;
  color: #ffffff!important;
}

/* サムネイル画像（小さめ） */
.case-banner__thumb {
  flex: 0 0 140px;
  max-width: 140px;
  border-radius: 8px;
  overflow: hidden;
  background: rgba(255,255,255,0.6);
}

.case-banner__thumb img {
  width: 100%;
  height: auto;
  object-fit: cover;
  display: block;
}

/* テキスト部分 */
.case-banner__text {
  flex: 1;
  min-width: 0;
}

.case-banner__label {
  font-size: 11px;
  font-weight: 700;
  letter-spacing: 0.12em;
  text-transform: uppercase;
  padding: 4px 8px;
  border-radius: 999px;
  border: 1px solid rgba(120,72,0,0.5);
  background: rgba(255,255,255,0.7);
  color: #8b5e00;
  display: inline-block;
  margin-bottom: 4px;
 line-height: 140%;
}

.case-banner__title {
  font-size: 15px;
  font-weight: 700;
  color: #3b2f00;
  margin-bottom: 4px;
}

.case-banner__desc {
  font-size: 12px;
  line-height: 1.6;
  color: #5c4a10;
}

/* CTAボタン部分 */
.case-banner__cta {
  font-size: 13px;
  font-weight: 700;
  white-space: nowrap;
  padding: 8px 14px;
  border-radius: 999px;
  background: rgba(255,255,255,0.9);
  color: #8b5e00;
  border: 1px solid rgba(160,105,0,0.9);
  flex-shrink: 0;
line-height: 140%;
}

/* hover時の演出 */
.case-banner .case-banner__inner {
  transition: transform 0.2s ease, box-shadow 0.2s ease, opacity 0.2s ease;
  transform: translateY(0); /* 通常位置 */
}
a.case-banner:hover .case-banner__inner {
  transform: translateY(-4px) !important;
  box-shadow: 0 8px 20px rgba(0,0,0,0.2) !important;
  opacity: 1 !important;
}
.case-banner:hover .case-banner__cta {
  background: #fffcf2;
  color: #8b5e00;
}

/* スマホ対応 */
@media (max-width: 768px) {
  .case-banner {
    max-width: 100%;
    margin: 0px 0;
  }

  .case-banner__inner {
    flex-direction: column;
    align-items: flex-start;
    gap: 10px;
    padding: 12px 12px;
  }
.case-banner__inner a{text-decoration: none!important; line-height: 140%;}

  .case-banner__thumb {
    width: 100%;
    max-width: 260px;
  }

  .case-banner__cta {
    align-self: stretch;
    text-align: center;
line-height: 140%;
  }
}


数千人の従業員のアカウントを個別に管理するのは現実的ではありません。Atlassian製品は、既存の IDプロバイダー（Okta, Azure ADなど）と連携した SAML認証や SSOに対応。退職者のアクセス権限を即座に一括遮断できるなど、情報漏洩リスクを最小限に抑えます。
SAML認証・SSO（シングルサインオン）: 既存のIDプロバイダー（Okta, Azure AD, Google Cloud Identityなど）と連携。数万人単位のユーザーに対し、セキュアでシームレスなアクセスを提供します。高度なアイデンティティ管理: 組織全体のユーザーを一元管理し、退職時や異動時の権限変更を即座に反映。シャドーIT化を防ぎ、監査ログの追跡も容易にします。データ漏洩防止（DLP）: 組織外への機密情報の流出を監視・制御する機能を備え、大企業が求める厳格なセキュリティ基準をクリアします。【Atlassian Guard】

緻密な権限管理と「スケーラビリティ」
大組織では「誰に何を見せるか」のコントロールが極めて複雑です。
詳細な権限設計プロジェクトやスペース単位だけでなく、ページや課題（タスク）単位でのアクセス制限が可能です。「特定の部署には見せるが、協力会社には非表示にする」といった運用を、標準機能で安定して実行できます。10万ユーザーまで耐えうるスケーラビリティAtlassian Cloudは、現在 1サイトあたり最大10万ユーザーまでサポートしています。（※Jiraの場合。Confluence Cloudは、最大15万ユーザーまで）。ツールの導入後、ユーザーが増えるにつれて動作が重くなったり、管理画面が煩雑になったりすることは、大規模組織において致命的です。小規模なスタートアップから、数万人が同時にアクセスする超巨大企業まで、パフォーマンスを落とさずにスケールできる実績は、世界中のフォーチュン500企業の多くに採用されている理由の一つです。

国内有数の巨大組織による導入実績
言葉以上に説得力を持つのが、実際に「10,000ユーザー規模」で運用されている実績です。
株式会社NTTドコモ様:10,000ユーザーを超える規模で Jira/Confluenceを活用。複雑なシステム開発の進捗管理と、膨大な社内ナレッジの共有を支える基盤として機能しています。





導入事例
株式会社NTTドコモ様｜Jira／Confluence Enterpriseプランで ガバナンスと柔軟性を両立
約14,000ユーザーが利用する大規模環境で、 ガバナンス強化と柔軟な環境分割を実現した Jira／Confluence Enterpriseプラン活用事例はこちら


事例を詳しく見る



.case-banner {
  display: block;
  max-width: 780px;              /* 全体の最大幅を適度に制限 */
  margin: 0px auto;             /* 上下マージン＋中央寄せ */
  text-decoration: none;
  color: #3b2f00;                /* 全体の文字色（濃いブラウン寄り） */
  font-family: inherit;
}
.case-banner a{text-decoration: none!important;}

.case-banner__inner {
  display: flex;
  align-items: center;
  gap: 18px;
  padding: 14px 16px;
  border-radius: 10px;
  /* イエロー〜オレンジ系グラデーション（Yahoo版と同じトーン） */
  background: linear-gradient(135deg, #fff7d6 0%, #ffe08a 45%, #ffb347 100%);
  box-shadow: 0 4px 12px rgba(0,0,0,0.10);
  box-sizing: border-box;
  transition: transform 0.15s ease, box-shadow 0.15s ease, opacity 0.15s ease;
}
.case-banner__inner a{text-decoration: none!important; line-height: 140%;}

/* サムネイル画像（小さめ） */
.case-banner__thumb {
  flex: 0 0 140px;
  max-width: 140px;
  border-radius: 8px;
  overflow: hidden;
  background: rgba(255,255,255,0.6);
}

.case-banner__thumb img {
  width: 100%;
  height: auto;
  object-fit: cover;
  display: block;
}

/* テキスト部分 */
.case-banner__text {
  flex: 1;
  min-width: 0;
}

.case-banner__label {
  font-size: 11px;
  font-weight: 700;
  letter-spacing: 0.12em;
  text-transform: uppercase;
  padding: 4px 8px;
  border-radius: 999px;
  border: 1px solid rgba(120,72,0,0.5);
  background: rgba(255,255,255,0.7);
  color: #8b5e00;
  display: inline-block;
  margin-bottom: 4px;
line-height: 140%;
}

.case-banner__title {
  font-size: 15px;
  font-weight: 700;
  color: #3b2f00;
  margin-bottom: 4px;
}

.case-banner__desc {
  font-size: 12px;
  line-height: 1.6;
  color: #5c4a10;
}

/* CTAボタン部分 */
.case-banner__cta {
  font-size: 13px;
  font-weight: 700;
  white-space: nowrap;
  padding: 8px 14px;
  border-radius: 999px;
  background: rgba(255,255,255,0.9);
  color: #8b5e00;
  border: 1px solid rgba(160,105,0,0.9);
  flex-shrink: 0;
line-height: 140%;
}

/* hover時の演出 */
.case-banner:hover .case-banner__inner {
  transform: translateY(-1px);
  box-shadow: 0 6px 18px rgba(0,0,0,0.16);
  opacity: 0.98;
}

.case-banner:hover .case-banner__cta {
  background: #fffcf2;
  color: #8b5e00;
}

/* スマホ対応 */
@media (max-width: 768px) {
  .case-banner {
    max-width: 100%;
    margin: 0px 0;
  }

  .case-banner__inner {
    flex-direction: column;
    align-items: flex-start;
    gap: 10px;
    padding: 12px 12px;
  }
.case-banner__inner a{text-decoration: none!important; line-height: 140%;}
  .case-banner__thumb {
    width: 100%;
    max-width: 260px;
  }

  .case-banner__cta {
    align-self: stretch;
    text-align: center;
line-height: 140%;
  }
}


LINEヤフー株式会社様（旧ヤフー株式会社）:旧ヤフー時代より全社規模での利用実績があり、情報のサイロ化を防ぎ、オープンなコミュニケーションと厳格な管理を両立させています。





導入事例
LINEヤフー株式会社様｜Confluenceを全社標準の情報共有プラットフォームに
「知りたいことは、まずはConfluenceを検索する」文化を支える、 大規模エンタープライズでのConfluence活用事例はこちら


事例を詳しく見る



これらの企業は、単に「タスクを管理する」ためではなく、「全社の情報を資産化し、組織の機動力を最大化するインフラ」として Atlassianを選択しています。

ツールを使うか、インフラを築くか
Notionや Asanaは、特定のプロジェクトや小さなチームの「瞬発力」を高めるには最適なツールです。しかし、5,000名、10,000名という規模で、事業の「持続性」と「安全性」を担保するには、エンタープライズ基準を満たしたIT基盤が必要です。
Atlassian Guardによる統合的なアイデンティティ管理大規模組織の構造に耐える権限統制10万ユーザーを支える堅牢なプラットフォーム
この条件を満たし、かつ現場の生産性を損なわない選択肢。それが、Jiraと Confluenceです。

リックソフトは Atlassian製品の導入支援パートナーです
Atlassian製品の導入・展開を成功に導くパートナー
Jiraや Confluenceは極めて強力なツールですが、5,000名、10,000名規模での導入には、単なるライセンス契約以上の「緻密な設計」が求められます。
「権限体系をどう設計すれば、セキュリティと利便性を両立できるか？」
「既存の膨大なデータをどう移行するか？」
「数千人のユーザーにどうやって操作を浸透させるか？」
こうした課題に対し、導入時のコンサルティングから教育、運用開始後の高度なサポートまで、トータルで支援を提供できるのがリックソフトです。

なぜエンタープライズ企業はリックソフトを選ぶのか
リックソフトは、日本国内における Atlassian製品の導入・サポートにおいてトップクラスの実績を誇ります。
これまで、15年以上にわたり Atlassian製品を導入・運用支援している経験から、エンタープライズ特有の複雑な要件に最適な設計を提案します。

トレーニングメニュー
現場のユーザーがツールを使いこなし、業務効率を最大化できるよう、独自の研修プログラムを提供。スムーズな定着を支援します。

サポートメニュー
導入して終わりではなく、運用開始後の技術的な課題や、組織の変化に伴う拡張の相談まで、伴走型でサポートします。
Atlassian製品の導入・移行をご検討の際は、ぜひリックソフトにご相談ください。
【お問い合せ】
 Atlassian導入・移行のご相談はこちら
        
    </content>
</entry>

<entry>
    <title>モダン開発の落とし穴『認知負荷』の正体――。複雑なエンジニアリング環境を救うIDP （Compass）の価値を一般家庭に例える - リックソフトブログ</title>

    <!-- 記事URLを絶対パスに修正 -->
    <link rel="alternate" type="text/html" href="https://www.ricksoft.jp/blog/articles/001734.html" />

    <id>https://www.ricksoft.jp/blog/articles/001734.html</id>

    <published>2026-04-14T02:03:05Z</published>
    <updated>2026-05-11T05:11:21Z</updated>

    <summary>ここ２～３年、ソフトウェア開発の世界、とりわけSRE界隈でよく、「社内開発者プラ...</summary>
    <author>
        
		<name>
		
			
			
				
				
				堀田実希(hotta)
    		
		
		</name>
        
    </author>

    <!-- カテゴリー情報 -->
    

    <!-- タグ情報 -->
    

    <!-- 記事のコンテンツ -->
    <content type="html" xml:lang="ja">
        ここ２～３年、ソフトウェア開発の世界、とりわけSRE界隈でよく、「社内開発者プラットフォーム（Internal Developer Platform ）」「社内開発者ポータル（Internal Developer Portal / Portal」という言葉を聞くようになりました。どちらも略するとIDPなので紛らわしいですね、ちょっと整理してみます。
社内開発者プラットフォームアプリをビルド・テスト・デプロイして&quot;実際に動かすための基盤&quot;そのもの（クラウド、Kubernetes、CI/CD、IaC など）社内開発者ポータルその基盤の上で動くサービスやアプリを&quot;サービス図鑑&quot;のようにまとめて、「どんなサービスがあって、誰が面倒を見ていて、今どんな状態か」を見に行けるポータル
です。Atlassianが開発した Compass は後者、社内開発者ポータルあたり、複雑化したエンジニアリング環境を整理するためのツールです。

なぜエンジニアリング環境は複雑なのか？
エンジニアリング環境は複雑化した背景には、開発スピードと拡張性を求めて進められた「マイクロサービス化」と、それに伴う「開発ツールの爆発的増加」があります。
現代のエンジニアは、単にコードを書くだけではありません。Kubernetesによるコンテナ管理、複雑なCI/CDパイプラインの構築、セキュリティスキャン、クラウドコストの最適化など、把握すべき領域は広がる一方です。
この状況を「独身一人暮らし（モノリス時代）」から「子供＋夫婦の３人家族（マイクロサービス化）」にたとえてみましょう。
かつての一人暮らし（モノリス開発）の時代は、すべてがシンプルでした。ワンルームの部屋で、自分の食べたい時に食べ、洗濯機を回すタイミングも自分次第。どこに何があるか、次に何をすべきかは自分の頭の中だけで完結していました。
しかし、家族が増え、子供が生まれ（マイクロサービス化と拡張）、生活の規模が大きくなると状況は一変します。


ひとりぐらし時代（モノリス開発）家族持ち時代（モダン開発・マクロサービス化）

管理対象
１人分の着替えだけ管理すればよかった。出張や旅行も自分で管理。
自分の子供の学校の準備、習い事のスケジュール、離乳食の献立、さらにはNISAでの資産運用（クラウドコスト最適化）や防犯対策（セキュリティスキャン）まで範囲が広がる


高度な専門知識
ただの掃除（コードを書く）
全自動洗濯乾燥機やお掃除ロボットのメンテナンス（Kubernetes）、食洗機の洗剤選びや効率的な家事動線の構築（CI/CDパイプライン）など。最新家電（技術）を使いこなすための学習コストもバカになりません。


情報の分散と「探しもの」の発生
自分の分だけ管理すればＯＫ（お好みの管理方法でどうぞ）
「先週届いた子供の予防接種の書類ってどこ？」「明日の持ち物は何だっけ？」と、家族間で情報が分散し、常に誰かが何かの「探しもの」をしています。



常に誰かが何かの「探しもの」をしている状態ーーーこれがエンジニアの「認知負荷」の正体です。
本来楽しみたかった『家族との団らん（本質的な開発活動）』の時間が、膨大な『名もなき家事（技術的な負債や運用のオーバーヘッド）』に奪われてしまっているのです。システムの規模拡大（家族持ち）に対し、管理手法が一人暮らしのまま（属人化・整理不足）であることが、現代のエンジニアを苦しめる「認知負荷」の正体です。
一人暮らしなら適当で良かったことが、家族を持つとそうはいかない。開発現場も同じです。

「社内開発者プラットフォーム」と「社内開発者ポータル」の違いを家庭で例えてみた
ここから先は、「Internal Developer Platform」と「Internal Developer Portal」を、一般家庭にたとえて整理してみます。
毎日の生活を支えているのは、キッチンや冷蔵庫、洗濯機、水道・電気といった&quot;設備&quot;と、「朝はこう動く」「週末はこう動く」といった 生活のパターンなどのルーティンです。
これはまさに 社内開発者プラットフォーム（Platform） にあたります。AWS や Kubernetes、CI/CD など、「実際にサービスを動かすための土台と、その上での標準的な進め方」です。
家庭の中には「ごはんを用意する」「洗濯を回す」「学校の準備をする」「予防接種を打たせる」「ゴミ捨てをする」「段ボールを片付ける」といった&quot;家庭内サービス&quot;があります。
誰が担当なのか（お母さん？ お父さん？ 子ども？）どの設備やサービスに頼っているのか（キッチン？ 洗濯機？ 生協？ 配達サービス？学校の連絡アプリ？音楽サービス？）どんな手順で進めればスムーズか（チェックポイントやコツ）
が整理されていると、家族みんなが動きやすくなります。
この「家庭内サービスの一覧と、その周辺情報」をまとめて見せるのが、開発の世界では Compass ＝ 社内開発者ポータル（Portal） の役割です。
\\チョット整理//
家庭内サービス（例：朝ごはんを作る）を支えるためのプラットフォーム（キッチンや冷蔵庫、水道・電気、生協などのサービス）があります。そのうえで「誰が担当で、何を使って、どう進めるか」を&quot;サービス図鑑&quot;として見える化するのがポータルです。

『家族のルール』なき拡大の末路――。家庭（開発現場）がカオスに陥るとどうなるか
もしこの情報が、家族それぞれの頭の中と、その場しのぎの会話「洗濯たまってるから時間ある人やっといて」「今日のゴミ出し、やれたらやっとくわ（やらない）」「お米なくなりそうだから、ECサイトのポイント還元が高い日に注文しといて（具体的な注文量や期日を伝えない）」「暗くなってきたから誰かリビングのカーテン閉めといて（担当者指名しない）」ーーだけで回していると、家庭はすぐカオスになります。
＜カオスな家庭のシーン例＞
「今日の晩ごはん、誰が用意するんだっけ？」が決まっておらず、気づいたら夜遅くまで誰も何も食べていない子どもが体操服を出し忘れて、朝になってから洗濯開始。体育がある日なのに、持っていく体操服がない「この用事、あなたがやると思ってた」というすれ違いから、責任の擦り付け合いに
それでも一般家庭は、「人数もやることもそこまで多くない」ので、サービスがなんとなく属人化しており、最終的には &quot;誰かが頑張る&quot;ことで無理やり回せてしまう 場合がほとんどです。（健全ではないですが回せてしまいます）

ソフトウェア開発の現場ではどうでしょうか。サービスが数十〜数百、関わる人も数十〜数百人規模になると、
「このログイン機能ってどのサービスと紐づいているんだっけ？」
「このDBを止めたら、どのサービスとダッシュボードに影響？」
「この障害、どのチームが見るべき？」
を&quot;誰かの記憶&quot;と&quot;チャットの会話&quot;、そして目の前の Jiraだけで回すのは、ほぼ不可能です。属人化と伝達漏れが積み重なり、「なんとなくカオスだけど、日々の火消しでごまかしている」状態になりがちです。
最近は AI に聞けば何かしら答えを返してくれます。ただ、AI も結局は「どこかの情報源」をもとに推論しているだけなので、そもそも社内に サービス構成や責任の&quot;正しい地図&quot;がない状態 だと、AI の答えもあいまいになりがちです。むしろ Compass のようなポータルでサービス情報が整理されているからこそ、AIが明確な根拠を持って回答してくれるようになります。
この『ファミリーの混乱』を解決するために必要なのは、高性能な家電（Platform）ではありません。誰が何をすべきか、どこに何があるかを全員が共有できる『家族の掲示板や共有カレンダー（Portal）』なのです。

開発者ポータルの家庭版があったら、何がうれしいか
ここで、「開発者ポータルの家庭版」があったとしたらどうでしょう。
「ごはん」「洗濯」「学校準備」といった&quot;家庭内サービス&quot;が一覧で見えるそれぞれに担当者、使う設備、必要な準備、気をつけるポイントが書かれているうまくいかなかった出来事（宿題忘れ、体操服洗い忘れ）も&quot;トラブル履歴&quot;として残り、次に気をつけることも記録されている
すると、
子どもは「学校準備」のページを見れば、自分で持ち物をそろえやすくなる（＊ただしやれるかどうかはその子どもの素質による）お父さんは「冷蔵庫の中」と「夕食のリクエスト」を見比べれば、何をいつ作るか迷わずに済む家族みんなが「家全体の担当マップ」が見えるので、負担の偏りにも気づきやすい
これが、開発組織における Compass のイメージです。クラウドや Kubernetes、CI/CD などの 社内開発者プラットフォーム（Platform） の上で動く、サービスやアプリ、データパイプラインをカタログ化し、オーナー・ドキュメント・依存関係・メトリクス・ヘルス状態をひとまとめにする。その結果、「誰が何を持っていて、どこで問題が起きやすくて、どこを改善すべきか」がチーム全員に見えるようになります。
一般家庭には、&quot;人数の少なさと暗黙知&quot;のおかげで不要だった「家庭版ポータル」。しかし、エンジニアリング環境が複雑化した今の組織には、同じ役割を果たす Compass のような社内開発者ポータルが、もはや必須になりつつある──それが、チームが Compass を必要とする理由です。

【まとめ】４月、新生活、オンボーディング。負担がひとりによってませんか？
４月から新しい年度が始まり、お子さんの保育園入園や小学校進学で、生活リズムがガラッと変わったご家庭も多いと思います。
そんな中で、
「最近、家の中が前よりバタバタしている気がする」「気づくと、いつもお母さんばっかり段取りを決めている」
という感覚はありませんか？

もし心当たりがあるなら、それは 「家庭内サービスのポータル」がない状態で、暗黙知だけに頼っているサイン かもしれません。開発現場でも同じで、サービスやチームが増えたのに、相変わらず &quot;誰かの記憶とチャットのログ&quot; だけで回していると、遅かれ早かれカオスに飲み込まれます。
 
家庭内サービスが一人に偏らないように意識するのと同じように、開発組織でも、サービスと責任が見える化されたポータル ＝ Compass を用意しておくことが、チーム全体で健全にサービスを育てていくための第一歩になるはずです。
        
    </content>
</entry>

<entry>
    <title> SFA・Excel・データ整形の限界を突破！Workatoで予実管理を自動化する方法｜月末の「あの作業」がなくなる - リックソフトブログ</title>

    <!-- 記事URLを絶対パスに修正 -->
    <link rel="alternate" type="text/html" href="https://www.ricksoft.jp/blog/articles/001733.html" />

    <id>https://www.ricksoft.jp/blog/articles/001733.html</id>

    <published>2026-04-02T00:57:26Z</published>
    <updated>2026-04-02T02:22:15Z</updated>

    <summary>--この記事は、複数の SaaS・ITツールを導入している現場で、予実管理の際に...</summary>
    <author>
        
		<name>
		
			
			
				
				
				カワセミ　(kawasemi)
    		
		
		</name>
        
    </author>

    <!-- カテゴリー情報 -->
    
        <category term="Workato" scheme="http://www.sixapart.com/ns/types#category" />
    

    <!-- タグ情報 -->
    

    <!-- 記事のコンテンツ -->
    <content type="html" xml:lang="ja">
        --この記事は、複数の SaaS・ITツールを導入している現場で、予実管理の際に Excelでのデータ整形をしている方に向けてお届けします--

予実管理に何らかの課題を感じている管理職の方は、少なくないのではないでしょうか。
「データ収集・整形の手間が大きい」「見込みの精度が上がらない」「担当者しかわからない業務がある（業務の一部が属人化している）」こういったお悩みをお持ちの会社様も多いのではないでしょうか。特に Excelで管理されている場合、「入力・集計作業が手動で時間がかかる」というケースも珍しくありません。

予実管理の課題と手作業の現状
毎月・毎週、CSVダウンロード → Excelでデータ整形という作業が社内のどこかで繰り返されていませんか？
「SFAや基幹システムから CSVをエクスポートして、表計算ツールで月別・カテゴリ別に集計して、上長にメールを送る。」
慣れれば大きな負担ではないかもしれません。ただ、Excelマクロのエラー対応に思わぬ時間を取られたり、担当者が不在のときに誰も対応できなかったり....そういった経験をお持ちの方はいらっしゃいませんか。

手作業による予実管理の問題点：データ整形に毎週30分の工数
実は、私たちのリックソフトの Workatoチームも同じ課題を抱えていました。利用している SFAは売上管理には強い一方、予算管理の機能が限られており、どうしてもSFAだけでの完結が難しい状況でした。そのため、売上データと予算データの突合せ・集計作業に毎週30分を費やしていました。
しかし、Workatoでこの業務を一気通貫で自動化できてからは、その作業自体がなくなりました。



Workatoを活用した業務プロセス自動化のメリット
Workatoとは？特徴とできること
Workatoは、さまざまな SaaSやオンプレミスシステムをノーコードで連携・自動化できるクラウド型iPaaS（Integration Platform as a Service）です。Workatoは「SaaSとSaaS・オンプレミスツールをつなぐシステム連携ツール」と紹介されることが多いですが、Workatoの強みはデータ連携だけではありません。
1,000以上のコネクタを備え、プログラミング知識がなくても業務プロセスの自動化やデータ連携が簡単に実現できます。
データを取得して → 集計・変換して → 届ける
この一連の流れを、プログラミング知識なしで自動化できるプラットフォームです。1,000以上のコネクタを備えており、オンプレミス・クラウドを問わず、既存のシステム・ツールとすぐに連携できます。そして単にデータをつなぐだけでなく、取得したデータを加工・集計する機能も備えています。

Workatoを活用した予実管理業務の自動化事例
例として、以下の業務フローを考えてみます。
＜現状＞
SFA・基幹システムにログインしてCSVをエクスポートCSVを表計算ツールへインポートし、月別・カテゴリ別に集計上長に報告メールを送信
＜Workatoで自動化後＞


ステップWorkatoがやること

①
毎日AM9:00に自動起動（スケジューラートリガー）


②
SFA・基幹システムから商談・売上データを一括取得し、表計算ツールで管理している予実管理表に月別・カテゴリ別で自動反映


③
上長に報告メールを自動送信



手動作業はゼロになり、毎朝最新データが自動で反映されます。


Workatoの機能「SQL Collection」で実現するデータ集計の効率化
Workatoの強みは、データをつなぐことだけではありません。取得したデータを加工・集計する機能も備えています。その機能の１つが SQL Collectionです。
SQL Collectionは Workato内で完結するため、別途データベースを用意する必要がありません。SFAや CSVなど連携元システムのデータに対して、取得したそのままの状態でクエリを実行できます。
できることの例
月別の売上を合計する受注済みとオープン案件を分けて集計する　など
VBAでやっていたことが、Workato内で完結します。
「SQLなんて書けない」という方も心配不要です。普段お使いの生成AIに「こういう集計をしたい。SQLを書いて」とリクエストをすると、必要なクエリを生成してくれます。あとは Workatoに貼り付けるだけです。（画像参照）


予実管理自動化による業務改善の導入効果
手動によるデータ収集・集計作業がなくなり、Excelでの属人的な管理から脱却できます。複数部門にまたがるデータも自動で一元集約できるため、リアルタイムで数字を把握でき、「今月の数字は？」と聞いたらすぐ答えが返ってくる状態になります。

こちらの記事をご覧になって「Workatoがうちの業務にも使えるのか知りたい」と思われた方は、ぜひお気軽にご相談ください。

      Workato（ワーカート）導入・活用支援 | リックソフト   国内トップクラスの実績を持つリックソフトが、貴社の業務自動化・iPaaS導入を強力にサポートします。   workato.ricksoft.jp  公式サイトを見る    
        
    </content>
</entry>

<entry>
    <title>Jira通知の種類と設定を比較解説｜メール・Slack・Teams・フィルターのベストプラクティス - リックソフトブログ</title>

    <!-- 記事URLを絶対パスに修正 -->
    <link rel="alternate" type="text/html" href="https://www.ricksoft.jp/blog/articles/001732.html" />

    <id>https://www.ricksoft.jp/blog/articles/001732.html</id>

    <published>2026-03-27T07:34:32Z</published>
    <updated>2026-04-14T06:24:25Z</updated>

    <summary>はじめに Jiraの通知、きちんと機能していますか？きちんと必要な通知を拾えてい...</summary>
    <author>
        
		<name>
		
			
			
				
				
				AI・DX室(dx)
    		
		
		</name>
        
    </author>

    <!-- カテゴリー情報 -->
    
        <category term="Jira" scheme="http://www.sixapart.com/ns/types#category" />
    

    <!-- タグ情報 -->
    

    <!-- 記事のコンテンツ -->
    <content type="html" xml:lang="ja">
        <![CDATA[はじめに
Jiraの通知、きちんと機能していますか？きちんと必要な通知を拾えていますか？見落としていませんか？
「Jiraからのメールが多すぎて、重要なメールが埋もれてしまう」「通知を減らしたいが、設定が複雑で諦めた」----こういった経験がある方は少なくないと思います。
Atlassian製品歴約１年の私自身も、社内の業務フローを切り替えたタイミングでJiraの通知が正しく届いていなかったことがありました。
この記事では、Jiraの通知方法を「どの権限で・どこで設定するか」という観点で整理、比較しています。設定を見直したことがない方も、ぜひ参考にしてみてください。

サマリ
アプリ内通知・メール通知：Jiraのデフォルト通知。設定は「個人設定（自分だけ変える）」と「通知スキーム（管理者がスペース全体を変える）」の2か所に分かれているSlack通知：公式Slack連携（セットアップ簡単・Slackから操作可）とJira Automation経由（通知条件・メッセージを細かく制御可）の2種類があるTeams通知：Slack連携と同様の仕組みで、Teamsチャンネルに通知できるフィルターのサブスクリプション：JQLで絞り込んだ課題一覧を定期的にメールで受け取れる。週次レポートなどに便利



Jiraの通知設定はなぜ複雑に感じるのか
いざ通知設定を見直そうとすると、「そもそもどこで設定すればいいのかわからない」という壁にぶつかることがあります。Jiraには設定に必要な権限が複数あり、権限によって設定場所も異なるからです。
この記事では、Jiraの通知の種類ごとに「どの権限で・どこで設定するか」を整理していきます。

1. アプリ内通知 ＆ メール通知


項目内容

設定できる人
一般ユーザー（個人設定） / Jira管理者（通知スキーム）


設定場所
Atlassianアカウント設定 / Jiraスペース設定




アプリ（Atlassian Cloud）内通知
Jira画面右上のベルマーク（🔔）に届く通知です。コメントへのメンション、課題のアサイン、ステータス変更などのイベントで通知が届きます。

アプリ内通知画面

メール通知
アプリ内通知と連動して、登録メールアドレスに通知が届きます。

Gmailでのメール通知画面例
Jira Cloudではデフォルトで一括通知設定となっており、3分以内の更新をまとめて1通で送信されます。ただしメンションやアサインなど重要な更新は即時送信されます。
参考：Batched notifications in Jira Cloud | Atlassian Support

設定方法
① Atlassianアカウント設定（個人） 自分の受け取り方だけ変えたい場合。
設定場所：画面右上の歯車アイコン → [通知設定] → [メールと通知]

個人の通知設定画面

② Jiraスペース設定・通知スキーム（管理者のみ） スペース全体の通知ルールを変えたい場合。
スペース全体の通知ルールを定義する設定です。「どのイベントが発生したとき、誰に通知を送るか」を管理者が設定できます。通知が正しく届くには、通知スキーム（管理者設定）と個人設定の両方が「送信する」になっている必要があります。 どちらか一方でもオフになっていると、通知は届きません。
設定場所：[スペース設定] → [通知] → [設定]

スペースの通知設定画面
参考：通知スキームの設定 | アトラシアン サポート

よくある悩みとおすすめの対処法


悩み対処法

メールが多すぎる
Atlassianアカウント設定の個人通知設定で不要な通知の種類を絞る


自分の操作にも通知が来るようにしたい
個人設定で「あなたが作業項目に変更を加えた」をオンにする


特定スペースだけ通知を変えたい
個人設定の「スペース通知のカスタマイズ」から設定（最大50スペース）





⚠️ Freeプランの注意点：Jira Cloudのフリープランは1日最大100通のメール送信制限があります。チーム規模が大きい場合は上限に達することがあるため注意が必要です。



2. Slackへの通知


項目内容

設定できる人
全ユーザー / スペース管理者


設定場所
Jiraスペース設定 / Jira自動化



チームでSlackを使っている場合、メンバーの認知負荷を下げるためにも Jiraの通知を Slackに集約するのがおすすめです。

Slack通知の方法は大きく2つあります。

Slack通知の設定方法① Jira Cloud for Slack（Atlassian公式Slackアプリ連携）
Atlassianが Slack向けに提供している公式アプリです。スペースと Slackチャンネルや DMを紐付けて、課題の更新を Slackに通知できます。
通知だけではなく、課題のワークフローの操作やコメントの追加などを Slackから行えます。

Slackアプリの通知例
できること
課題の作成・更新・コメントを Slackに通知Slackからコメント追加やステータス遷移などの操作（Jiraに遷移せずとも、Slack上で操作を完結できるようになります！）

設定の流れ
1. Slackの App Directoryから Jira Cloudアプリをインストール
※インストール時、Atlassianアカウントでのログインを求められます。

2. Jiraと Slackを連携&amp;通知場所の指定
a. Jiraアプリとのチャット画面で「/jira connect」と送信します。接続したい Jiraのサイトドメイン、Jiraスペース、通知を受け取る Slackチャンネルまたは DMを指定することで、連携を行えます。

詳細はこちらの公式ドキュメントからご確認ください。Jira Cloud と Slack を連携させる | アトラシアン サポート
Jira側の設定はこちらで解説していますので、合わせてご確認ください。Slackと Jiraを連携させる｜リックソフトのブログ記事

Slack通知の設定方法② Jira Automation（カスタム通知）
こちらは Jiraの Jira Automation（自動化）機能を使った通知方法です。
通知条件、通知内容を細かく設定したい場合に有効です。Jira上でコーディング不要で設定できます。
通知条件例
期限切れの課題を毎朝9時にSlackへ一覧送信担当者が変わったら担当者本人のDMに通知
Jira Automationから Slackに送信するアクションは現在2種類あり、メッセージの送信者が異なります。

方法②-1 Send message（コネクション経由）
コネクションをあらかじめ確立し、チャンネル名・リンク・IDで送信先を指定する方法です。
メッセージはコネクションを設定した Atlassianアカウントのユーザーから送信されます。
Webhook URLの取得が不要なため、セットアップがシンプルです。

コネクション経由の通知画面

設定画面
方法②-2 Webhookを介して Slackメッセージを送信する
Slackで Incoming Webhook URLを取得し、自動化ルールに設定する従来の方法です。
メッセージは Webhook元の Slackアプリから送信されます。

Webhook経由の通知画面

Webhookの設定画面
どちらを選ぶかは、Slackでメッセージの送信者をどう見せたいかによって変わります。「誰が通知しているか」を Slack上で明確にしたい場合はコネクション経由、ボットやアプリからの通知として扱いたい場合は Webhook経由が向いています。
参考：自動化で Slack を使用する | アトラシアン サポート

どちらを選ぶべきか


公式Slack連携Jira Automation

設定の手軽さ
◎
△


通知条件の細かさ
△
◎


メッセージのカスタマイズ
△
◎


Slackから操作できる
◎
✕


費用
無料
無料（上限あり）




3. Microsoft Teamsへの通知


項目内容

設定できる人
Jira管理者 / スペース管理者


設定場所
Jiraスペース設定 / Jira自動化



Slackではなく Teamsを使っているチーム向けです。
Jira Cloud for Microsoft Teamsアプリを使うことで、Slack連携と同様にスペースと Teamsチャンネルを紐付けて通知を受け取ることができます。Jira Automationから Webhookで通知を送ることも可能です。
参考：
Jira Cloud と Microsoft Teams を統合する | Jira Cloud | アトラシアン サポートJiraとMicrosoft Teamsの連携について|リックソフトブログ

4. その他の通知方法
フィルターのサブスクリプション


項目内容

設定できる人
一般ユーザー


設定場所
Jiraのフィルター設定



JQLで絞り込んだ課題の一覧を、定期的にメールで受け取る機能です。「毎週月曜に自分が担当している未完了課題を一覧で受け取る」といった使い方ができます。

メール画面
設定場所：[フィルター] → フィルターを保存 → [サブスクリプション] から頻度を設定



Automation × 外部Webhook


項目内容

設定できる人
Jira管理者 または スペース管理者


設定場所
Jira自動化



Jira Automationの「Webリクエストを送信」アクションを使えば、Slack・Teams以外の外部サービスにもWebhookでデータを送れます。

まとめ
通知を設計するときに考えるべきことは次の3つです。
誰に通知するか（全員 / 担当者のみ / 特定ロール）どこで受け取るか（メール / Slack / アプリ内）どんなイベントで通知するか（すべて / 重要なものだけ）
この3つを整理したうえで、以下の表から自分のチームに合った方法を選んでみてください。


通知方法設定できる人設定場所向いているケース

アプリ内・メール通知
全ユーザー / Jira管理者
Atlassianアカウント設定 / Jiraスペース設定
基本の通知


Slack連携（公式）
全ユーザー / スペース管理者
Jiraスペース設定
通知をSlackに集約したい


Slack連携（Automation）
スペース管理者
Jira自動化
通知条件・内容を細かくカスタマイズしたい


Teams連携
Jira管理者 / スペース管理者
Jiraスペース設定
Teamsを使っているチーム


フィルターのサブスクリプション
全ユーザー
Jiraフィルター設定
定期的な一覧通知がほしい



一方で、通知は増やしすぎると本末転倒になりがちです。通知が多すぎて重要な更新が埋もれてしまったり、「通知が来ないと気づけない・動けない」運用になってしまうこともあります。新しい通知を追加するときは、「そもそもこれは通知で解決すべきか？」もセットで考えてみるとよいかもしれません。
この記事が、チームの通知設計を見直すきっかけになれば幸いです。]]>
        
    </content>
</entry>

<entry>
    <title>【プロンプトあり・POC手順つき】会議事録からJira課題を自動起票する方法｜Workato×VertexAI活用 - リックソフトブログ</title>

    <!-- 記事URLを絶対パスに修正 -->
    <link rel="alternate" type="text/html" href="https://www.ricksoft.jp/blog/articles/001731.html" />

    <id>https://www.ricksoft.jp/blog/articles/001731.html</id>

    <published>2026-03-06T00:15:33Z</published>
    <updated>2026-06-02T01:14:01Z</updated>

    <summary>  この記事でわかること 会議の Jira課題を、議事録から AIで自動起票する...</summary>
    <author>
        
		<name>
		
			
			
				
				
				AI・DX室(dx)
    		
		
		</name>
        
    </author>

    <!-- カテゴリー情報 -->
    
        <category term="AI活⽤・業務改善事例" scheme="http://www.sixapart.com/ns/types#category" />
    
        <category term="Workato" scheme="http://www.sixapart.com/ns/types#category" />
    

    <!-- タグ情報 -->
    

    <!-- 記事のコンテンツ -->
    <content type="html" xml:lang="ja">
        
 この記事でわかること
会議の Jira課題を、議事録から AIで自動起票するワークフロー不要なチケットを作らないための課題抽出条件（発散・不満の除外）実際に使っている プロンプト全文（JSON出力）PoCの手順 と評価指標

会議が終わったあと、「これ誰がやるんだっけ？」が曖昧なまま、宿題だけが増えていく----そんな場面は珍しくありません。
その結果、会議で合意した&quot;やること&quot;がところどころ消え、実行スピードが落ちます。
本記事では、企業の DX担当を任されているエンジニア向けに、オンライン会議の議事録（文字起こし）から生成AIで課題を抽出し、Jiraチケットを Workatoで自動作成する方法を紹介します。
ポイントは、AIに任せきりにしないこと。特に、会議が発散した場合や、個人の感想・不満が&quot;会社の課題&quot;として起票される事故を防ぐために、「厳格な抽出条件（プロンプト）」も公開します。


Jira起票の自動化で得られるメリット
リックソフトの AI・DX室は様々な部署から課題をヒアリングして、運用改善や社内のAI活用を推進しています。
一部の部署で、&quot;会議で出た課題を管理するために「Jiraを使いたいが、ミーティングのたびに会議内容を整理して議題チケットを作成、管理するのを運用にうまく乗せられない」&quot;という状態が続いていました。
「オンライン会議ツール(GoogleMeet、Zoom、Loom)を使えば、自動で MTGの文字起こし(Transcript)が実施されます。文字起こし全文を生成AIに投げて Jiraチケットの作成までできれば、以下のような効果があるのでは？」という仮説から検証を開始しました。

Jira自動起票のメリット1) 起票工数を減らし、実行への接続を速くする
会議後の「まとめ→整形→起票」は後回しになりがちです。自動起票で&quot;最初の一歩&quot;を軽くし、決まったことが実行へ流れやすくなります。

Jira自動起票のメリット2) &quot;課題認識のバイアス&quot;を薄める
会議では立場や心理的安全性により、同じ発言でも扱われ方が変わります。
特に部下が上司に対して「それは論点が曖昧です」と指摘しにくいことがあります。
AIに客観的な言葉で整理させることで、感情や力関係の影響を一段薄められます。

Jira自動起票のメリット3) ルールを磨くほど、会議参加者の視点が揃う（会議の質が上がる）
起票ルールを運用しながらブラッシュアップしていくと、参加者が「これは課題として成立するか？」という視点を持って会議に臨むようになります。結果として、会議の発散が減り、意思決定が前に進みやすくなります。


議事録→AI→Jira起票自動化のフロー
会議を文字起こし（議事録化）する。どんなツールでもOK。文字起こしテキストを所定の場所にコピペする
a. Workatoでトリガーイベントをキャッチできるドキュメントツールであれば何でもOK。リックソフトでは Confluenceを利用しています。
b. Confluenceページには「起票する Jiraのプロジェクトと Issueタイプの指定」、「チケット作成後の通知先SlackチャンネルID」も一緒に記載して、Webhookで Workatoに情報を渡しています。
Workatoがトリガーを検知して処理を開始（Confluenceのページラベルを付与したことをトリガーにして Workatoで Webhookを受信している）生成AIが議事録から課題を抽出し、Jira起票用に整形（Workatoのレシピ内で VertexAIを利用）Jiraチケットを自動作成作成後に Slackチャンネルに通知

MTG議事録から Jira起票を行うフロー図

文字起こしを貼り付けている Confluenceページ

Jira課題が作成された時の Slack通知画面

最重要：会議が発散した時に「課題として起票しない」
自動起票の最大リスクは、次の2つが&quot;会社の課題&quot;としてチケット化されることです。
会議が発散した結果の&quot;論点メモ&quot;（結論が出ていない、スケジュールがない、理想論）個人の感想・不満（主観）が、あたかも組織課題のように見えてしまうもの
これを防ぐには、AIに「何をやるか」だけでなく、「何をやらないか」を明文化した&quot;ガードレール&quot;が必要です。そこで、実際の運用で使っているプロンプトをそのまま公開します。

【プロンプト公開】実際に使っている指示（厳格条件＋起票ルール＋JSON出力）
以下が、「議事録からやるべきことを課題化して起票する」エージェントのプロンプトです。
（先ほどのフロー図で赤い点線で囲ってある部分の箇所にあたります）
ポイントは 「3条件すべてを満たすものだけ」「疑わしいなら除外」 です。
【重要：課題抽出の厳格な条件】
以下の3つすべてを満たすものだけを抽出してください。1つでも疑わしい場合は除外してください。
- 具体的かつ解決可能であること
 - 「何が決まっていないか」「何が業務を止めているか」を客観的に説明できる。
 - 【除外】：特定のツールや既存フローへの個人的な不満・愚痴、単なる「使いにくい」といった主観的な文句。
 - 【除外】：自社でコントロール不能な外部要因（プラットフォーム側の仕様変更の懸念など）に対する不安。

- 部署・チーム全体の組織課題であること
 - 特定の個人のスキル不足ではなく、仕組み、ルール、システム設定の欠如に起因するもの。
 - 名前を伏せても「組織のボトルネック」として成立する内容。

- 直近で意思決定・着手される前提があること
 - 「いつかやりたい」「本来こうあるべき」といった理想論や、議論が発散したまま結論が出ていないものは除外する。
 - 会議内で、マネージャーや担当者が「今後対応する」と明確に判断・合意したもののみを対象とする。

【起票ルール】
- 同じタイトルの課題を重複して作成しないこと。
- 解決策やToDoは書かない。 あくまで「解決すべき課題（状態）」を記述する。
- 1課題カテゴリーを「親Jiraチケット」1件と想定し、関連する具体的な課題を「サブ課題」として構造化する。
- 親Jiraチケットは大きな課題カテゴリーとして、起票件数が少なくなるように集約する。
- 条件を満たす課題が1件もない場合は、issues配列を空にする。

【出力形式】
- 以下のJSON形式のみで出力してください。JSON以外の文章・説明・補足は一切出力しないでください。

{
  &quot;issues&quot;: [
    {
      &quot;title&quot;: &quot;課題のタイトル（30文字以内）&quot;,
      &quot;current_problem&quot;: &quot;現在起きている課題を客観的・具体的に説明&quot;,
      &quot;business_impact&quot;: &quot;この課題を解決することで得られる組織的メリット（生産性、収益、品質など）&quot;,
      &quot;reason_for_ticket&quot;: &quot;起票理由の①具体性、②組織課題、③直近の意思決定の3点をそれぞれ明記&quot;,
      &quot;sub_issues&quot;: [
        {
          &quot;title&quot;: &quot;サブ課題のタイトル&quot;,
          &quot;current_problem&quot;: &quot;サブ課題の具体的な内容&quot;,
          &quot;business_impact&quot;: &quot;解決によるメリット&quot;,
          &quot;reason_for_ticket&quot;: &quot;起票理由の3点（簡潔に）&quot;
        }
      ]
    }
  ]
}


このプロンプトが&quot;効く&quot;理由（運用目線）
疑わしいなら除外：チケット乱造を防ぎ、Jiraの信頼を守る組織課題に限定：個人の不満が&quot;会社の課題&quot;に化けるのを防ぐ直近の意思決定・着手が前提：会議の発散ログを起票しない解決策を書かない：チケットが&quot;結論&quot;ではなく&quot;解くべき状態&quot;になる親＋サブ課題：Jira件数を増やさず、構造化して追える

AIに任せきりにしない：人がやるべき行動
自動化で起こり得る問題は、「記載情報が足りない」「自分の意図した内容になっていない」「そもそも記載されていない」です。
AIはあくまでMTG課題管理のサポートとして利用するため、以下の運用を事前に定義しておくことが重要です。
AIは下書き。最終判断と責任は人が担う。起票されたチケットの人チェック。（誤字脱字修正、表現調整、重複統合、担当者や関係者の設定）足りない課題があれば、次の定例で再度議題に上げる。その場の勢いで勝手に起票されることを防ぎ、条件を満たすものだけ課題化するルールを守る。

使ってみた結果：起票はラクになる。ただし&quot;メンテ前提&quot;が現実的
運用上の結論は次の通りです。運用が回り始めると改善点も見えてきました！
チケットのメンテは必要だが、ゼロから起票するより遥かに楽AIが客観的に抜け漏れなく課題を書いてくれるのは大きい出力が100%安定しないため、人のレビューは必須

展開のしかた：まずは一つの会議体でPoC
全社展開から始めるより、まずは ひとつ会議体 でPoCが安全です。
会議によっては毎回実施する必要がない場合もあります。

PoCの進め方（最短3ステップ）
Step1：対象会議を1つ決める
定例で、参加者が固定されている会議が向きます
Step2：起票ルール（プロンプト）を合意する
例:「発散は起票しない」「主観は除外」「スケジュールが明確なものだけ」
Step3：2〜4週間回して評価する
起票時間（Before/After）起票されたチケットのうち着手につながった割合不要・重複チケット率（＝ルールの精度）人のメンテ時間（現実の運用コスト）

まとめ：AIで起票を楽にし、ルールで会議を賢くする
議事録から Jiraへ自動起票することで、会議の宿題が&quot;消えにくく&quot;なります。ただし成功の鍵は、AIではなく運用です。
今後はチケット作成の重複防止、既存チケットを更新する改善を実施して、社内で活用を広げていく予定です。
        
    </content>
</entry>

<entry>
    <title>【イベントレポート】リックソフト株式会社20周年パーティー！ - リックソフトブログ</title>

    <!-- 記事URLを絶対パスに修正 -->
    <link rel="alternate" type="text/html" href="https://www.ricksoft.jp/blog/articles/001730.html" />

    <id>https://www.ricksoft.jp/blog/articles/001730.html</id>

    <published>2026-02-20T01:49:17Z</published>
    <updated>2026-03-05T02:08:42Z</updated>

    <summary>2025年1月4日、リックソフト株式会社は設立20周年を迎えました。 設立から支...</summary>
    <author>
        
		<name>
		
			
			
				
				
				りっくま(Rickma)
    		
		
		</name>
        
    </author>

    <!-- カテゴリー情報 -->
    
        <category term="イベント" scheme="http://www.sixapart.com/ns/types#category" />
    

    <!-- タグ情報 -->
    

    <!-- 記事のコンテンツ -->
    <content type="html" xml:lang="ja">
        2025年1月4日、リックソフト株式会社は設立20周年を迎えました。
設立から支えてくださったお客様、パートナーの皆様、そしてたくさんの挑戦と、共に乗り越えてきた社員への感謝を伝えるために先日、パレスホテル東京にて20周年記念パーティーを開催いたしました！
本記事では当日の様子をダイジェストでレポートします！


パートナーの皆様と歩んだ20年






20周年パーティーの冒頭、代表・大貫からの挨拶に続き、役員自らが全テーブルを巡り、社員一人ひとりへ20年分の感謝を直接伝える場面も。
西日本支社のメンバーやリモートワーク中心の社員など、普段は画面越しでしか会えない社員ともコミュニケーションを取り、有意義な時間が流れました！



アトラシアン株式会社様


Workato株式会社様


ミロ・ジャパン合同会社様


そして、長年共に歩んできたパートナー企業である、アトラシアン株式会社様、Workato株式会社様、ミロ・ジャパン合同会社様からリックソフトへの期待が込められたエールを含む温かいお言葉をいただき、リックソフトはかかわるすべての皆様のおかげがあって創り上げてこれたということを改めて実感する時間となりました。

20年の歴史と感謝を語るスペシャルムービーの放映

パートナー様からのビデオメッセージの後は、リックソフト20年の歩みを辿るスペシャルムービーが放映されました。
代表・大貫が語る創業当時の秘話、そして経営層から社員へ「これからのリックソフトを共に創り上げよう」という熱く力強いメッセージ。
そして長年会社・現場を支えているベテラン社員の想いまで凝縮された素敵な動画でした。
なによりこの映像は若手社員を中心として作り上げたということが、会場を驚かせました...！

全員対抗！ビンゴ大会！




続いてはお楽しみの豪華景品が当たるビンゴ大会を行いました！
普段の疲れを癒せるヘッドスパチケット、コメ不足を解消するお米セットなど豪華景品をかけて、役職も部署も関係なく全員で参加しビンゴした瞬間は会場のあちこちで歓声が上がり熱気と笑顔に溢れました。
当選した社員の皆さん、おめでとうございます！

終わりに
本パーティはお祝いの場だけではなく、リックソフトで働くことへの誇りを再確認できた時間となりました。
20年を迎えれたのは、リックソフトを支えてくださったお客様、パートナーの皆様、そして日々情熱を持って邁進してくれる社員の存在があったからこそです。
これからも「イノベーションをおこしてあらゆる人の可能性を最大化」できるよう全社一丸となって挑戦を続けていきます。
今後のリックソフトのさらなる進化に、どうぞご期待ください！
        
    </content>
</entry>

<entry>
    <title>SmartDBの「API連携は難しい」を乗り越える！WorkatoのSMartDBコネクタのご紹介 - リックソフトブログ</title>

    <!-- 記事URLを絶対パスに修正 -->
    <link rel="alternate" type="text/html" href="https://www.ricksoft.jp/blog/articles/001729.html" />

    <id>https://www.ricksoft.jp/blog/articles/001729.html</id>

    <published>2026-02-06T00:17:17Z</published>
    <updated>2026-03-05T02:33:14Z</updated>

    <summary>SmartDBで業務アプリを作れるようになってくると、次に出てくるのが「他システ...</summary>
    <author>
        
		<name>
		
			
			
				
				
				カワセミ　(kawasemi)
    		
		
		</name>
        
    </author>

    <!-- カテゴリー情報 -->
    
        <category term="Workato" scheme="http://www.sixapart.com/ns/types#category" />
    

    <!-- タグ情報 -->
    

    <!-- 記事のコンテンツ -->
    <content type="html" xml:lang="ja">
        SmartDBで業務アプリを作れるようになってくると、次に出てくるのが「他システムともっと連携させたい」というニーズではないでしょうか。
いざAPI連携に踏み出そうとすると、「認証情報はどう持てばいいのか」「APIの仕様が難しい」などといった技術的なハードルに直面しがちです。
本記事では、Workato上で利用できる「SmartDBコネクタ」を活用し、SmartDBと外部システムをノーコードで連携する方法とメリットをご紹介します。


SmartDBとは？
SmartDBは、紙やExcelで行っていた複雑な業務プロセスをデジタル化し、企業のDXを加速させる大企業向けの業務デジタル化クラウドサービスです。
高度なワークフロー、柔軟なデータベース、Webフォーム機能を持ち、現場部門がノーコードで業務アプリを素早く開発できます。
この「早く・深く・柔軟に」業務を変革できる力こそが、SmartDBが多くの大企業で選ばれ続ける理由です。

やりたい連携を妨げる「APIの壁」
SmartDBの魅力の一つは、豊富な API群による高い拡張性です。基幹システムや SaaSとのデータ連携（同期）を実現することで、部門を横断した業務効率化が可能になります。
ただし、API連携でやりたいことはたくさんあるのに、いざ実装に取り掛かる際、次のような「壁」に直面し立ち止まってしまうケースが多くあります。
「認証情報（APIキーやトークン）を安全に、どこに保管し、どう管理すればいいのだろう？」「APIの『お作法』（リクエスト形式、データ構造）を理解し、適切にコーディングするのが難しい...」
これらの壁が、せっかくのシステム連携による業務改善のスピードを鈍らせてしまっている、という声を多く聞きます。

「SmartDBコネクタ」が解決！
リックソフトはこの「APIの壁」を打破するソリューションを提供します。
それが、世界中で利用されている自動化・統合プラットフォーム「Workato（ワーカート）」のコネクタとして、当社が開発・提供している「SmartDBコネクタ」です。
Workatoは、異なるシステム同士をノーコードでつなぐ「ハブ」のような役割を果たします。Workato上で SmartDBコネクタを利用することで、専門的な知識や APIの詳細な仕様を意識することなく、直感的な操作だけで SmartDBと外部システムをシームレスに連携させ、データ同期や業務自動化を実現できるようになります。




脱・レガシー運用。Workato×「SmartDB」でデジタル化
Workatoは、 SmartDBとクラウド・オンプレミス等のシステム間の連携を、ノーコード・ローコードで実現し、お客様のビジネスにおけるSmartDBの価値を最大化します
 SmartDB×Workatoのユースケースを知る



SmartDBコネクタで実装した連携処理：他システムの更新をきっかけに文書を作成
他システムとの連携も、SmartDBバインダ間の連携も、お好みの AIを利用した処理も簡単に実装できます。




SmartDBコネクタだからできる！３つの特長
特長１：APIの「お作法」は不要！直感的な「トリガー」と「アクション」
SmartDBコネクタを使えば、複雑な APIの仕様やデータ構造を理解する必要はありません。Workatoの画面上で、連携ロジックをノーコード・ローコードで構築できます。
トリガー（SmartDBのイベントを感知）： 「特定バインダの文書が作成されたら」など、Workatoで連携を開始する「きっかけ」をメニューから選択するだけで設定できます。アクション（SmartDBへの操作）： 「文書を作成する」「文書を更新する」など、実行したい処理をブロック形式で直感的に設定できます。他にも 40種類以上のアクションをご用意。
煩雑な JSON形式のリクエストや認証処理を意識することなく、「何をきっかけに」「何をするか」を設定するだけで、SmartDB連携が実現します。
  

SmartDBコネクタのトリガーを使った実装SmartDBコネクタのアクションを使った実装












特長２：部品への値のセットが驚くほど簡単
システム連携において最も手間がかかるのが、連携先のデータ構造に合わせてデータを変換する「マッピング」作業です。
SmartDBコネクタを使えば、連携元システムのデータを、SmartDBバインダの部品にドラッグ＆ドロップで手軽にマッピングできます。
これにより、データ型にとらわれず細かな変換ロジックをコーディングする手間から解放されます。


特長３：Workatoならではの認証情報のセキュアな一元管理
「APIキーをどこに置くか」というセキュリティと運用の悩みも解消します。
Workatoでは、連携システムの認証情報（APIキーなど）をコネクションに持たせます。
レシピ（連携ワークフロー）の編集画面で SmartDBコネクタを使用する際に、すでに作成したコネクションを紐づけます。
セキュアに一元管理できるため、セキュリティを担保しつつ、開発者は連携ロジックの構築に集中できます。


システム連携のハードルを下げ、本来の「業務改善」に集中できる環境へ
SmartDBコネクタを活用することで、これまで技術的な懸念点になりやすかった「APIの扱い」や「セキュリティ管理」の負担を軽減することができます。
こうしたハードルが下がることで、日々の業務に次のようなポジティブな変化が期待できます。

①改善のサイクルが早くなる
技術的な調査や開発に時間をかけすぎず、現場の「今すぐ連携したい」という声に素早く応えやすくなります。

②運用後の変更にも柔軟に対応できる
プログラムコードを直接書き換える必要がないため、組織の変更や業務ルールの見直しがあった際も、設定の変更でスムーズに対応可能です。

③本来の目的に集中できる
「どうやってシステムを繋ぐか」という手段に悩む時間を減らし、「どのデータを繋げば現場がもっと便利になるか」という、本来の目的である業務改善のアイデアを形にする時間を増やすことができます。

さいごに
SmartDBが持つ柔軟なプロセス管理能力と、Workatoによる多様な外部システムとの連携。 この2つを繋ぐ「SmartDBコネクタ」は、皆さまの「やりたい」を形にするための一助となれば幸いです。
「自社のシステムと SmartDBを上手く連携させたいけれど、どこから手をつければいいかな？」 「JiraやSalesforceとの同期をもっと手軽に実現したい」
もしそんなお悩みやご興味がありましたら、当社リックソフトへぜひお気軽にお声がけください。

        
    </content>
</entry>

<entry>
    <title>【イベントレポート】Jira Service Management徹底解剖！ - リックソフトブログ</title>

    <!-- 記事URLを絶対パスに修正 -->
    <link rel="alternate" type="text/html" href="https://www.ricksoft.jp/blog/articles/001728.html" />

    <id>https://www.ricksoft.jp/blog/articles/001728.html</id>

    <published>2026-02-02T01:13:44Z</published>
    <updated>2026-04-09T01:19:44Z</updated>

    <summary>リックソフトは、弊社を通じて製品をご導入いただいているお客様を対象に、定期的に「...</summary>
    <author>
        
		<name>
		
			
			
				
				
				りっくま(Rickma)
    		
		
		</name>
        
    </author>

    <!-- カテゴリー情報 -->
    
        <category term="Customer Service Management" scheme="http://www.sixapart.com/ns/types#category" />
    
        <category term="Jira Service Management" scheme="http://www.sixapart.com/ns/types#category" />
    
        <category term="イベント" scheme="http://www.sixapart.com/ns/types#category" />
    

    <!-- タグ情報 -->
    

    <!-- 記事のコンテンツ -->
    <content type="html" xml:lang="ja">
        リックソフトは、弊社を通じて製品をご導入いただいているお客様を対象に、定期的に「招待制イベント」を開催しています。 
今回は、「Jira Service Management徹底解剖 -成功企業に学ぶ JSM運用現場のリアル-」と題し、
今、注目されている ITサービスマネジメントツール「Jira Service Management」のアップデート情報や活用事例の紹介イベントを開催しました。
「他社のリアルな活用法を知りたい」「最新の ITILソリューションを自社にどう落とし込むべきか」といった悩みを持つお客様にご参加いただきました。
本記事では、当日の様子をダイジェストでお届けします！




Jira Service Management × Customer Service Management活用事例
本セッションでは、本セッションでは、システム運用をお客様ごとに最適化するサービスを運営する企業を共有いただきました。
顧客ごとの個別最適化が進んだ結果、「システムの高コスト」「非効率な労働集約モデル」「スキルのばらつき」に直面していました。
これらの課題をどう解決・実現したのか。またなぜ Jira Service Managementを選定したのか。その理由から具体的な運用方法をお話いただきました。
また、セッション終盤では、社内向けサービス管理「Jira Service Management」と社外向けサービス管理「Customer Service Management」を組み合わせた
統合サービスマネジメント基盤として、今後実現したいこと・Customer Service Managementに期待できる運用方法もご紹介いただきました。

あわせて読みたい！

Service Collection: CSM (Customer Service Management) のここがスゴイ！

情報通信業界A社の ITSM活用による大規模プロジェクト業務変革事例

ZendeskからJira Service Managementに移行で、自動化による顧客満足度向上・タスク削減を実現した事例


間接部門の Service Collection事例
IT部門や開発部門に比べ、後回しになりがちな「間接部門」の DX。
しかし間接部門は「定型問い合わせが多い」「人によって質問が少し違うためナレッジとして活用できない」などの課題があげられます。
また、間接部門に来る問い合わせはメールで、窓口はチャットツールを利用している状況のため悪循環から抜け出せなくなっているため、Service Collectionのようなツール導入が重要です。
本セッションでは、エンタープライズ企業 人事部門（採用関連）での Service Collectionの活用事例をご紹介しました。
採用人材の情報（新卒なのか中途なのか、選考ステータス状況や過去問い合わせ履歴など）1人ずつ調べるにはかなりの時間がかかっており、人事の工数1.2人分以上が「採用関連の問い合わせ」だけで消費されていました。
この課題を Service Collectionでどのように改善できたのか。
紹介企業様では採用情報のデータベースで Assetsを活用しており、採用関連の SaaSツールと iPaaSツールを活用してデータを連携したりなど間接部門ならでは活用事例を紹介しました。


サービスマネジメントの進化 -Service Collectionとは？-
「社内外で別々のツールをしようしているので、ライセンスや運用管理も異なっている」「ワークフローや情報管理が統一されていない」など課題を抱えていませんか？
アトラシアンのカバーしている領域の1つ「サービスマネジメント」は社内、社外を分けることではなく一気通貫できるプラットフォームが求められています。
本イベントのアトラシアン社からのセッションでは、製品のサービスマネジメント市場動向や進化したアトラシアン製品「Service Collection」のアップデート情報をご紹介させていただきました。
本記事では簡易的に紹介させていただきますが、詳細が知りたい方はぜひリックソフトへお問い合わせください！





Service Collection





製品名


Jira Service Management


Customer Service Management


Assets


Rovoエージェント




概要


主に社内からシステム部門への問い合わせで利用
開発・IT部門・ビジネスチームに卓越


主に外部顧客やエンドユーザーからヘルプデスク部門への問い合わせで利用
AI機能を掲載


資産管理のソリューション
JSMの中で参照する先のデータとして利用


AIエージェント
各製品に内包




Service Collectionについて：Atlassian Service Collection | Atlassian


AI時代における ITSM（ITサービスマネジメント）の重要性
AIが進化するほど自動化など業務効率が一気に加速し、ITSM（ITサービスマネジメント）は不要なのでは？と思っている方もいらっしゃるかもしれません。
しかしむしろ、AIが進化すればするほど重要になります。
AIで判断は早くなりますが、その「判断を組織として安全に使うための仕組み」を果たすのが ITSMだからです。
 
リックソフトは、アトラシアン社認定の ITSM専門パートナー資格を保有しており、社内にも豊富な経験を持つ ITSMスペシャリストが在籍しています。
お客様の現状分析から改善計画の策定、定着のご支援までフェーズごとに ITSMのプロがコンサルティング・ご支援します。
AI時代だからこそ、ITILプラクティスに沿った ITSMに取り組みませんか？ぜひご相談ください。

過去参加者の声
セッション後の交流会ではお客様同士で交流いただける場をご用意しております！
交流会では、登壇者や同業企業様とより密な情報交換ができ有意義な時間になったとのお声もいただいております
「自社と似たような状況だったところから改善されたというお話で、想像しやすく、自社に置き換えながら聞くことができた」「他社様の事例や同様の課題から、直近で自社がすべき優先順位が見えてきました」「事例の課題に共感できる部分が多かったこと、自社でも実現できそうと思える内容だったことで製品導入への意欲が湧きました」

リックソフトでは製品価値を最大化できるようサポートだけではなく、導入・活用拡大のヒントをお持ち帰りいただけるイベントを継続的に開催しております。
ご興味あるかたはぜひリックソフトへお問い合わせいただくか担当営業までご連絡ください！

リックソフトイベント情報：https://www.ricksoft.jp/event/

        
    </content>
</entry>

</feed>
