内製化推進支援／業務改善支援を通じて、市民開発に伴走
―― まずは、MSOL Digitalの事業内容について教えてください。
S・H：MSOL Digitalは、PMO（Project Management Office）支援を強みとしてきた親会社、株式会社マネジメントソリューションズのDigital事業部門にエンジニア紹介事業を含めた形で、2024年1月に子会社化される形で誕生した、まだ創業3年目の会社です。
私たちが最も大切にしているのは、ブランドパーパスである「デジタル∞マネジメントの変革力で未来をつくる」です。親会社で培われてきたプロジェクトマネジメントのDNAを基盤に、デジタルの専門性を無限大（∞）に掛け合わせることで、お客さまに継続的な価値を提供する考え方を示しています。
事業内容は、レガシートランスフォーメーション（LX）、ノーコード・ローコードソリューション、ビジネスアジャイル、そしてHR領域に特化したHRXという4本柱で展開しています。
―― おふたりが所属する部署についても教えてください。
S・H：私たちは「Internal to External Dept.」、通称「ITED（アイテッド）」に所属しています。メンバーの多くがDXや情報システム部門の経歴を持っていて、そこで培ってきた知見を部門として一つに束ね、お客さまに価値として還元しています。部門横断の難易度の高い社内プロジェクトを実行する中で蓄積した知見を、外部のお客さまへ提供するという意味で、「Internal to External」と名付けています。
―― 具体的な支援内容も教えてください。
S・H：ノーコード・ローコードソリューションとして、大きく2つの柱で進めています。1つが「内製化推進支援」。お客さまのDX推進部門や現場部門に伴走し、研修やQA対応、ワークショップなどを通じて、お客さま自身がPower PlatformやCopilot Studioなどのツールを活用して内製化に踏み出せるようご支援します。
もう1つは「業務改善支援」です。これは私が主に担当している領域で、MSOL Digitalのコーポレート部門、例えば人財部、経理、総務などが抱える課題を、ノーコード・ローコードで解決するテンプレートとして企画・開発しています。まず社内・グループ内で使い、フィードバックを受けて品質を高める。その上で汎用化し、社外のお客さまにも提供できる形にしていく流れになります。
以前は「開発者」というとプログラマーのような職業に紐づいていましたが、現在はノーコードやローコードツールの普及もあって、現場の業務を担う担当者が自らアプリケーションを作れるようになってきています。そうした方々は「市民開発者」、その営み自体は「市民開発」と呼ばれているかと思いますが、私たちはこの市民開発に伴走する存在です。
MSOL Digitalのノーコード・ローコードソリューション
―― 他社にも業務改善のソリューションは数多くありますが、差別化のポイントはどこにあるとお考えですか？
S・H：やはり母体であるPMOとしてのDNA、「デジタル∞マネジメント」のマネジメントの部分ですね。私たちは技術導入そのものをゴールにせず、導入後もお客さまが継続的に価値を生み出せるよう、マネジメントの観点からプロジェクトを計画・運用しています。
―― たしかに、システムが完成して渡されても、すぐに内製化につながるわけではありませんよね。
S・H：業務のAs-Isを分析し、どこに課題があるのかを整理して、セキュリティやガバナンスも考慮しながら環境を整える必要があります。その上で研修やワークショップを行い、開発後も改善を重ね、使われなくなったアプリやフローを整理していく。導入して終わりではなく、クライアントが自走できるように支援することが重要だと捉えています。
ノーコード・ローコードは目的ではなく、あくまで手段
―― H・Yさんが担当されている内製化の相談は、どのようなフェーズでいただくことが多いのでしょうか？ 課題が具体化している段階なのか、それとも「何が問題か分からない」という段階なのでしょうか。
H・Y：後者の場合が多いですね。「DXという言葉をよく聞くので、自社でも何か取り入れたいが、何を改善すべきかはまだ分からない」という段階から始まることが多い印象です。その場合、まずは現在の業務で何に時間がかかっているのか、何に困っているのかを一緒に洗い出していきます。問題に見えていることが、実は他システムとの連携不足なのか、データの持ち方の問題なのか、そもそも業務フロー自体に無理があるのかなどを整理します。根本原因を見つけることが重要です。
―― 問題の所在を見つけるところから伴走するのですね。
H・Y：Power Platformを使った改善は、私たちが提供できる手段の1つであって、それ自体が目的ではありません。業務フローを見直すだけで改善できるのであれば、その方が良い場合もあります。Power Platformありきで業務を合わせにいくのではなく、まず「本来どうあるべきか」を考え、その上で使える場面で使うというスタンスです。
―― スクラッチ開発の方が適している場合もあると思います。その場合はどう判断されるのでしょうか？
H・Y：お客さまにとって最適な方法を選びます。私たちのチームで入口を担当したとしても、スクラッチ開発や他のソリューションの方が良い場合は、LXチームなど別チームと連携することもあります。ノーコード・ローコードに閉じるのではなく、広い視点で課題解決を考えています。
―― ノーコード・ローコードツールは、一般的にどれくらい活用されているものなのでしょうか？
S・H：多くの企業が導入に踏み出している一方で、活用や定着に苦戦しているケースも少なくありません。ノーコード・ローコードツールは、スクラッチ開発とは異なる形で論理的構成力が試されるため、アーキテクト的な視点がないとなかなか活用しきれないと感じています。
―― 「スクラッチ開発とは異なる形で論理的構成力が試される」というのは、具体的にどういうことでしょうか？
S・H：スクラッチであれば、言語的な制約はあっても、かなり広い自由度の中で部品を足したり改修したりしながら作れますよね。ところがノーコード・ローコードでは、実現したいことを実現できない場面が少なくありません。
例えばPower Platformには、Power Platformならではの制約があります。そこで一度迂回的な手段を取ったり、別のソリューションに置き換えたりして、本質的な実現につなげなければいけません。作りたいものをそのまま作れる環境とは違い、制約の中で目的を実現するためのノウハウや折り合いをつける力が必要です。
―― たしかにパッケージシステムに業務を最適化するような側面はありそうですね。ただ、制約がある一方で、現場にいる人が自分たちで構築できるというメリットは、やはり大きいですよね。
H・Y：はい。誰でも触りやすく、修正しやすいことは大きなメリットです。もちろん、制約を考慮してもPower Platformを使うべきなのか、他のツールや業務フロー変更の方が良いのかは見極めます。ですが長期的なコストや運用を考えると、社内で使える人が増えることには価値があると思います。
―― 現場にいる人が自由に触れると、ロジックが複雑化したり、メンテナンスしづらくなったりする懸念もあると思いますが、そこはどのように防いでいるのでしょうか？
H・Y：現場の方に自由に触っていただく一方で、完全に自由放任にはしていません。仕組みを作る前段階の業務整理を徹底することで、ロジックが複雑になり過ぎないようにしています。例えば、ロジックの構築を「保存する」「転送する」といった大きな手順だけで終わらせるのではなく、「どの画面のどこを押すのか」「どのメールアカウントを使うのか」など、より具体的な部分まで落とし込むようにしています。
その過程でお客さまに業務をロジックに落とし込む考え方を実践的に理解していただきます。ロジックや業務に必要な処理が整理されるため、不要に複雑な仕組みを作ってしまうリスクを減らせるのです。私たちが抜けた後も、お客さま自身が、保守しやすく継続的に改善できる組み方を考えられるようになることが、内製化支援の大きな価値だと考えています。
―― スクラッチ経験がある方にとっても、ノーコード・ローコードは戦える領域なのでしょうか。
S・H：むしろ、かなり戦力になると思います。どう分解し、どう構成し、どう運用まで考えるか。そこはスクラッチでもノーコード・ローコードでも変わりません。
「楽しかった」「またやりたい」と思ってもらうことが大切
―― スクラッチ開発と、ノーコード・ローコードを使った内製化支援では、プロジェクトの進め方やマイルストーン設定に違いはありますか？
H・Y：スクラッチ開発の場合、成果物としてのシステムやアプリが完成することが、ひとまずのゴールになります。一方で内製化支援では完成物だけではなく、その後お客さまが身につけたスキルをどう活かしていくかが重要になります。そのため、完了条件は成果物の完成だけでなく、お客さまが自ら次の改善に取り組める状態になったかまで含めて設定します。
マイルストーンも、成果物そのものではなく「スキル」に着眼して設定します。例えば「業務整理が完了した」ではなく、「業務整理をするためのスキルが身についているか」を見ます。私たちが必要な情報を一方的に集めるのではなく、目指すべき改善に向けて「まずどの情報を確認すべきか」をお客さまと一緒に定義するそのプロセス自体が内製化の一部になります。
―― 実際に、お客さまの変化を感じた事例を教えてください。
H・Y：開発経験がまったくないお客さまに対して業務整理の進め方から支援した際に、最初は「何をもって業務改善になるのか分からない」という状態でしたが、整理を進めるうちに、「これまで問題だと思っていたことは、大きな困りごとを漠然と捉えていただけだった」と気づいていただけました。
例えば他部署とのやり取りで情報が散らばっている、時間がかかっていることは分かっている。でも、なぜそうなっているのかは分からない。そこで、なぜなぜ分析のように原因を掘り下げていくと、根本的な問題が見えてきます。その方法が今後の改善にも役立つと言っていただけたのは、大きな手応えでした。あとは大規模な取り組みとして、パートナー会社に協力したハッカソンの支援も印象的でした。
―― ハッカソンですか。そういうことも対応されているんですね。
H・Y：はい。その時は数百名規模の参加者になりました。Power Platformを使って業務を自動化・改善することを目的に、社内の方々に5〜6名ほどのチームを組んでいただき、最終発表に向けて成果物を作る企画です。1〜2ヵ月ほどの短期間で、それぞれのチームが自分たちの業務課題に向き合いました。最終日に「大変だったけれど、実際に使えるスキルが身について楽しかった」と言っていただけたことが印象に残っています。内製化では、スキルが身につくだけでなく、「楽しかった」「またやりたい」と思ってもらうことが大切です。その感覚が、次の改善につながりますからね。
―― おふたりの仕事で、特に難しいと感じる点を教えてください。
S・H：問題がどこにあるのかを特定することですね。私たちは生産性向上を支援していますが、何が生産性を阻害しているのかを、お客さま自身がまだ特定できていないことが非常に多いです。ああでもない、こうでもないと一緒に確認しながら、ようやく真因に近づいていきます。逆に、真の要因が見つかれば、解決策を作ること自体はそこまで難しくない場合もあります。だからこそ、潜在的な要因を見つける力、問題を発見する力が重要だと感じています。社内向けの業務改善でも、日々のルーティンとして当たり前になっている作業に対して「ここは手作業でなくても良いのでは」と、伝えて初めて気づいてもらえることがあります。
H・Y：私の場合は、開発やシステムに詳しくない方にどう伝えるかが難しいですね。こちらが当たり前だと思って使った言葉が、まったく伝わらないことがあります。だからこそ、開発用語は不用意に使わず、「それはどういう意味なのか」「どの場面でどういう状態を指すのか」まで細かく説明するようにしています。そもそも、お客さまは通常業務の合間に取り組むことが多く、ハードルを上げすぎると続きません。初心者の方がまず押さえるべき点を伝え、高度な考え方は必要に応じて後から追加する。そのバランスを意識しています。
Copilot Studioで、AIを業務に実装する力を磨く
―― 最近は生成AIの進化も目覚ましいですが、Copilot Studioを使う仕事では、具体的にどのような経験を積めるのでしょうか？
H・Y：Copilot Studioは、単に生成AIへのプロンプトを作るためのツールではありません。AIエージェントにどのような指示を与えるか、どの社内情報を参照させるか、どのシステムと接続して何を実行させるかを組み合わせ、業務の中で安全に使える形に設計していきます。実際の支援では、社内情報を参照して問い合わせに回答するエージェントや、必要な情報を聞き取って後続業務につなげる仕組みなどを検討・構築しています。
例えば、問い合わせに回答するだけなのか、必要な情報を聞き取って担当部署へ引き継ぐのか、あるいは申請や通知などの後続処理まで実行するのかによって、設計は大きく変わります。AIに何を任せ、どこから人が判断するのかを決めることも重要です。業務フロー、データ、システム、人の役割を横断して考える点が、Copilot Studioを扱う面白さだと思います。
―― ツールの操作以外には、どのようなスキルが身につきますか？
S・H：まず身につくのは、曖昧な業務課題を整理し、AIが扱える単位まで分解する力です。その上で、AIへの指示、参照させるナレッジ、外部システムとつなぐアクション、期待する回答や動作の評価基準を設計します。実際の業務では、一度作って終わりではありません。想定外の質問に対してどのように動くのか、誤った回答を返す可能性はないか、権限のない情報へアクセスする恐れはないかなどを確認し、テストと改善を繰り返します。Copilot Studioの操作スキルだけでなく、業務分析、会話設計、データ連携、品質保証、ガバナンスまでを一連のものとして経験できるところに価値があります。
―― 従来の開発経験や業務経験は、AIエージェントの設計にどのように活かせますか？
S・H：開発経験がある方は、処理の分解、データ構造、例外処理、テストといった経験をAIエージェントの設計に活かせます。一方、業務部門や情報システム部門の経験がある方は、「現場ではどこで判断に迷うのか」「どの情報があれば次の行動に移れるのか」といった業務知識が強みになります。
大切なのは、AIの回答を作ること自体をゴールにしないことです。業務に組み込み、現場で継続的に使われるところまで考える。その経験を通じて、AIを利用する側から、業務に実装して価値を生み出す側へとスキルを広げられると考えています。
めざしたいものがある人にとっては、チャレンジしやすい環境
―― MSOL Digitalでのキャリア形成について、制度や特徴、良いと感じるところなどを教えてください。
S・H：当社では、キャリアバンドごとに期待される役割が示され、期初に設定した目標を定期的にレビューします。現在の役割にとどまらず、次のバンドで求められる行動を目標として宣言できるため、AIやノーコード・ローコードなど、新しい領域への挑戦も自身のキャリア形成に結びつけやすい仕組みです。
H・Y：評価制度に加えて、上司やメンターと話す機会があるのも良いところですね。自分がめざしたい方向と、今の業務が合っているのかを相談できますし、必要に応じて部署異動も検討してもらえます。入ってみて「思っていた業務と違う」と感じた場合でも、調整しながらキャリアを作っていける環境だと思います。
また、社内の人間関係がフラットで、めざしたいスキルを持っている人に話を聞きやすいことも魅力です。私自身、経験豊富な方に相談することもありますが、同じ立場でリアルタイムに似た課題に向き合っている人の意見から学ぶことも多いです。周囲を頼りながら、自分でも動き、経験を積み重ねることが大事だと感じています。
―― どのようなバックグラウンドの方が活躍されていますか？ エンジニア経験は必須なのでしょうか？
H・Y：私のチームでは、開発経験がある方もいますし、まったく別業界から来た方もいます。中には飲食業界の経験を持つ方がいて、人と接する力や関係構築の力が高く、学べることも多いです。入社時点で技術に関する知識や経験がゼロでも、「分からないからできません」ではなく「分からないけれどやっていきます」という姿勢があれば、入社後に大きく伸びる人もいます。
S・H：私のチームでは、完全に知識・経験がゼロだと難しい場面もありますが、Power Platformをユーザーとして触ったことがある、情報システム部門で関連する業務を経験したことがある、という方であれば十分に可能性があります。いずれにしても、お客さまの課題をきちんと聞き取り、価値を提供したいと思えることがコアになります。
―― 最後に、今後どのような方と一緒に働きたいか、メッセージをお願いします。
H・Y：相手の立場に立って、コミュニケーションを取れる方と一緒に働きたいです。私たちが接するお客さまは、情報システムや開発に詳しい方ばかりではありません。だからこそ、相手の考え方を受け入れ、同じ目線に立って整理できることが大切です。自分の知識を押しつけるのではなく、相手にとって何が分かりやすいか、どうすれば一緒に前に進めるかを考えられる方が合っていると思います。
S・H：有形でも無形でも、何かを作ることが好きな方、そして、作ったものをお客さまに届け、相手に喜んでもらうことを自分の喜びにできる方がいいですね。ノーコード・ローコードは簡単に見えるかもしれませんが、業務を理解し、制約を乗り越え、継続して使われる形に整える必要があります。その先に、お客さまの仕事が少し楽になり、前向きに変わる瞬間がある。そこにやりがいを感じられる方と、ぜひ一緒に働きたいです。
編集後記
私自身、「ノーコード・ローコード＝簡易ツール」という漠然としたイメージを持っていましたが、取材を通じて大きく覆されました。制約があるからこそ論理的な構成力が問われ、AIが開発の一部を担う時代だからこそ、業務全体を見渡し、データやシステムのつながりを設計し、お客さま自身もまだ言語化できていない課題を引き出す力が重要になる。ノーコード・ローコードとAIエージェントの領域には、技術だけに閉じない、新しい課題解決の可能性があると感じました。
取材／文：長岡 武司
撮影：平舘 平
提供：株式会社MSOL Digital
今回出演いただいたS・Hさん／H・Yさんとお話しされたい方は、お申し込みページの「その他メッセージ欄」に、面談を希望される方のお名前をご記載ください。