宮城県仙台市を拠点に、システム開発とRFIDソリューション販売を展開する株式会社東北システムズ・サポート。2024年にDTSグループ*へ参入したことを機に、グループ水準の管理会計構築が急務でした。
また、今後の成長のためには、分断されたExcel管理から脱却し、事業部ごとやプロジェクトごとの営業利益を正確に把握できる経営管理基盤の構築を行う必要がありました。
そこで同社は、利益の最小単位である「プロジェクト別収支」可視化を視野に入れ、「Loglass 経営管理」と「Loglass 人員計画」の同時導入を決定。年間100件超のプロジェクト別収支を積み上げ、事業部別の利益を正確に算出できる「攻めの経営管理基盤」を構築しました。その導入経緯と活用方法についてお話を伺いました（2026年3月取材）。
*株式会社 ＤＴＳのグループ会社の総称。
代表取締役社長 下川様
取締役 由良様（写真右）
取締役 兼 第一事業本部長 星野様
管理本部 経営企画部長 兼 執行役員 菅原様（写真左）
下川様：弊社は仙台を拠点に50年の歴史を持ち、システム開発とRFIDソリューション販売という二つの軸で事業を展開してきました。主力のシステム開発はプロジェクト型のビジネスで、エンジニアが複数のプロジェクトに並行してアサインされ、年間100を超えるプロジェクトが動いています。
菅原様：以前の管理体制は、各事業部が独自のExcelで受注・売上・原価・入金を管理し、経営会議に直接報告する仕組みでした。横断的に事業を分析するブレイン機能は存在せず、経営企画部が設立されたのも2024年7月のことです。もともとSEとして事業部門に携わってきた私が経営企画の立ち上げを担うことになり、立ち上がったばかりの部署でDTSグループ水準の管理会計を構築していくことになりました。
下川様：2024年のDTSグループ参入が、経営管理を抜本的に変えるきっかけになりました。それ以前は、「全社として最終的にこの数字をクリアすれば良い」という考えのもと管理会計を行っていました。そのため、それぞれの事業がどれだけのパフォーマンスを出しているかを問い続ける文化は、それまでの弊社にはなかった訳です。つまり、どの事業にどんな課題があるのかという観点で定量的に分析することができず、これがスピード感をもって持続的に成長を実現していくうえでの阻害要因になっていることは明白でした。このギャップを埋めることが、グループ参入後の最初のミッションでした。
菅原様：部門ごとにExcelファイルを管理していたのですが、部門をまたがる案件では「受注はこちらで計上し、売上は別部門」という分担が発生します。その整合を取るためにブックを横断する参照が常態化し、片方を修正してももう片方に反映されていないことで数字が異なっているというミスが散見されていました。よくあったのはSUM関数のセル範囲が一か所ずれているというミスですね。
星野様：関数のミスは気づきにくいので、「数字が違う気がする」という勘と経験に頼りながらチェックをしていました。さらに、ミスを防ぐために副部長・部長・事業部長という複数の確認ステップを設けていたため、経営会議直前まで集計作業に追われ、分析に時間を割けない状況でした。
下川様：営業利益の可視化にも課題がありました。事業本部は直接原価だけを管理していたため、売上総利益はプロジェクト単位まで把握できていました。しかし、販管費の部門配賦が行われていなかったため、営業利益は正しく見ることができませんでした。「どこに問題があって、何を伸ばすべきか、何をやめるべきか」を問えない状態では、私たちの掲げる事業目標を達成する経営戦略は描けません。
下川様：選定の軸は二つです。まず1点目は、複数の分析軸を自由に設定でき、さまざまな切り口で数字を見られること。2点目は、現場の業務フローを大きく変えずに導入できること——この二軸で進めました。
一時期は「Excelを完全に捨てて別システムに完全移行する」方向も検討しました。しかし、あるサービスのデモを事業部担当者たちと見たときの反応は厳しいものでした。ブラウザベースの入力に変わることへの抵抗感、作業フローが一変することへの懸念から「負荷が増すなら今の方がいい」という声が上がりました。現場からのフィードバックをもとに「今のExcelを活かしながら、集計・分析のアウトプット側を変える」というソフトランディングの方向に軸足を移すことに決めました。
展示会で「Loglass 経営管理」のブースを見つけたのはそのタイミングです。担当者にその場でデモをしてもらい、分析軸の設定を操作しているのを見た時に「これがやりたかったことだ」と確信しました。現場のExcelはそのままで、集計・分析だけをシステム上で行えるシステムはまさに私たちが求めていたものでした。
由良様：選定の過程ではERPも検討候補に上がっていました。ただERPは、プロジェクト管理系のシステムとしての色が強く、ExcelからERPへの移行は「ジャンプする距離が長い」という感覚がありました。そのタイミングで提案をいただき、下川と星野にデモを見せたその場で決断が下りました。「今のExcelを活かしたまま、業務フローを変えずに進められる」という方向性に最も合致していたのが「Loglass」だったのです。
下川様：最初は「Loglass 経営管理」のみでの導入を想定していました。しかし弊社のビジネスはプロジェクト型で、エンジニアがどのプロジェクトにどれだけ稼働しているかが収益管理の核です。人件費コストを正確に把握できなければ、プロジェクト単位の営業利益は算出できません。「人員計画との連携なしに、経営管理だけを入れても根本的な課題は解決しない」という判断から、「Loglass 人員計画」の同時導入に踏み切りました。
菅原様：一人当たりの生産性を経営指標として追うためにも、バイネームでの人員管理基盤は不可欠でした。採用・退職・アサインの状況を一元管理できる体制は、人が主要なコストであるプロジェクト型ビジネス全般に必要な仕組みだと思います。「Loglass 経営管理」でプロジェクトの収益を、「Loglass 人員計画」で人員コストの実態を見渡せる体制を最初から設計したことが、プロジェクト別収支を一人当たりの生産性にまで即座に分解できる、経営管理基盤の基礎になっています。
菅原様：最も時間をかけたのは分析軸の設計です。「どの切り口で数字を見たいか」が固まらなければ、データをいくら入力しても活用できない体制になってしまいます。弊社の最終目標はプロジェクト単位の営業利益の把握なので、プロジェクト・顧客・本部という収益構造の階層を正確に設計する必要がありました。
私自身がSEのバックグラウンドを持っているため、RDB*のデータ構造を意識しながら設計を進めました。どのデータをどう組み合わせれば求める切り口が出せるか、という観点から整合性のある軸を作り込んでいく作業です。最初は3階層だった設計を6階層に拡張するなど何度か入れ直しもありましたが、「Loglass」のCS担当者から導入の最初に「一番重要な設計判断は分析軸だ」と明確に伝えていただいたことが、大きな助けになりました。
由良様：データをどんどん入れて成長させていく過程は、見ていて驚くものがありました。点々としか見えなかったデータが、1週間、2週間と経つにつれて線になり、分析として活用できる状態になっていく。「これもできるようになった、あれも入れました」という形でデータが日々積み上がり、目に見えてシステムが育っていくプロセスを目の当たりにしていました。
菅原様：両プロダクトの目的が根本的に異なるからです。「Loglass 経営管理」の分析軸は、プロジェクト・顧客・本部という事業の収益構造を捉えるもの。「Loglass 人員計画」の分析軸は、職位・雇用形態・年齢といった人員の属性を捉えるものです。共通している項目もありますが、基本は完全に分けて設計しています。
「Loglass 経営管理」の分析軸を先に固めたことで、「Loglass 人員計画」で何をすべきかが自然に定まっていきました。現在の運用では、事業部門が各自の業績データを締め処理後に提出し、経営企画がその整合性を確認した上で全社のデータ基盤として完成させる構造になっています。入力の責任と整合性確認の役割を分けて設計したことで、年間100を超えるプロジェクトの経営管理基盤を、精度を保ちながら運用できています。
下川様：以前は、数字を確認したい時には、複数のExcelブックを同時に開かなければ管理できない状態でした。今は気になった時にLoglassを開けば、正確な数字がそこにある。「当たり前の経営管理が日常になった」という感覚が最も大きな変化です。使うたびに「いいよね、Loglass」という話になるのは、劇的な一瞬ではなく、使い続けることで積み上がっていく価値があるからだと思っています。
星野様：経営会議では菅原が「Loglass 経営管理」のレポートをモニターに投影しながら報告します。「前年度比でいうとどうか」「クオーターで見るとどうか」「このままの伸びだとどうなるか」という問いがその場で次々と出てくる。顧客別の数字を見ていて「どこに差が出ているのか、その差はなぜなのか」という粒度の細かい問いが出た時も、分析軸を切り替えながらその場でスパンと出せます。以前なら次の会議に持ち越しになっていた議論が、その場で完結するようになりました。
由良様：投資判断のタイミングで「キャッシュがどうなっているか、いくらまでいけるか」という問いが出ても、その場で「Loglass 経営管理」を開いて確認しながら議論を進められます。数字を知りたい時にすぐ知れる環境が整ったことで、意思決定のスピード自体が変わりました。いろいろな判断が格段に早くなったと思います。
菅原様：最も大きな変化は、全員が同じ数字を参照できることです。「Loglass」はシステム上で数値を編集することができないため、誰が参照しても同じデータしか出てきません。以前は集計式のセル範囲を一か所間違えただけで数字が変わり、「この数字はどうなっているのか」という確認が発生していました。今はその不安がなくなり、自信を持って正確な数字を経営層に提示できます。報告資料の作成も、以前は5日かけていたものが今は1日以内に完了しており、工数でいうと80％の削減になりました。
菅原様：「Loglass 人員計画」単体では、社員約230名と業務委託約150名をバイネームで管理し、職位レベル別・雇用形態別・年齢別の人員分布を確認しています。「会社全体がどういう構成になっているか」を経営層が数字で議論できる土台が初めて整った、という状況ですね。
下川様：「Loglass 人員計画」で人件費を管理することで、業績と人員を連動して見られるようになりました。数字の上では計画通りに推移しているように見えても、人員構成の変化が想定と乖離していれば「中身は大丈夫か」という問いを立てることができる。PLと人員計画の数字を一緒に見ることで、数字の背後にある実態に気づきやすくなることが同時導入の本質的な価値だと思います。
菅原様：「アウトプットから逆算して設計する」ことだと思います。何のために何を見たいのか。その目的が明確でなければ、分析軸の設計もデータ投入の優先順位も定まりません。私たちは「プロジェクト単位の営業利益を把握する」という最終目標が明確だったので、そこから逆算してデータ構造の設計を進めることができました。
下川様：経営管理の高度化は、それ自体がゴールではありません。分析軸を多角化し、成長領域や注力すべき顧客を数字で判断できる状態を確立します。そして、各事業部門長が多角化した分析軸とプロジェクト単位の営業利益を意識し、これらを向上させるために現場から自発的な提案が次々と生まれる文化を醸成していく。その進化を支える経営インフラこそが「Loglass」です。単なる数字の管理に留まらず、データの深掘りから次の事業の芽を見出し、利益を創出するための挑戦を加速させていきます。
* リレーショナルデータベースの略。表形式でデータを管理するデータベースシステムのこと。
下川様：弊社は仙台を拠点に50年の歴史を持ち、システム開発とRFIDソリューション販売という二つの軸で事業を展開してきました。主力のシステム開発はプロジェクト型のビジネスで、エンジニアが複数のプロジェクトに並行してアサインされ、年間100を超えるプロジェクトが動いています。
菅原様：以前の管理体制は、各事業部が独自のExcelで受注・売上・原価・入金を管理し、経営会議に直接報告する仕組みでした。横断的に事業を分析するブレイン機能は存在せず、経営企画部が設立されたのも2024年7月のことです。もともとSEとして事業部門に携わってきた私が経営企画の立ち上げを担うことになり、立ち上がったばかりの部署でDTSグループ水準の管理会計を構築していくことになりました。
下川様：2024年のDTSグループ参入が、経営管理を抜本的に変えるきっかけになりました。それ以前は、「全社として最終的にこの数字をクリアすれば良い」という考えのもと管理会計を行っていました。そのため、それぞれの事業がどれだけのパフォーマンスを出しているかを問い続ける文化は、それまでの弊社にはなかった訳です。つまり、どの事業にどんな課題があるのかという観点で定量的に分析することができず、これがスピード感をもって持続的に成長を実現していくうえでの阻害要因になっていることは明白でした。このギャップを埋めることが、グループ参入後の最初のミッションでした。
菅原様：部門ごとにExcelファイルを管理していたのですが、部門をまたがる案件では「受注はこちらで計上し、売上は別部門」という分担が発生します。その整合を取るためにブックを横断する参照が常態化し、片方を修正してももう片方に反映されていないことで数字が異なっているというミスが散見されていました。よくあったのはSUM関数のセル範囲が一か所ずれているというミスですね。
星野様：関数のミスは気づきにくいので、「数字が違う気がする」という勘と経験に頼りながらチェックをしていました。さらに、ミスを防ぐために副部長・部長・事業部長という複数の確認ステップを設けていたため、経営会議直前まで集計作業に追われ、分析に時間を割けない状況でした。
下川様：営業利益の可視化にも課題がありました。事業本部は直接原価だけを管理していたため、売上総利益はプロジェクト単位まで把握できていました。しかし、販管費の部門配賦が行われていなかったため、営業利益は正しく見ることができませんでした。「どこに問題があって、何を伸ばすべきか、何をやめるべきか」を問えない状態では、私たちの掲げる事業目標を達成する経営戦略は描けません。
下川様：選定の軸は二つです。まず1点目は、複数の分析軸を自由に設定でき、さまざまな切り口で数字を見られること。2点目は、現場の業務フローを大きく変えずに導入できること——この二軸で進めました。
一時期は「Excelを完全に捨てて別システムに完全移行する」方向も検討しました。しかし、あるサービスのデモを事業部担当者たちと見たときの反応は厳しいものでした。ブラウザベースの入力に変わることへの抵抗感、作業フローが一変することへの懸念から「負荷が増すなら今の方がいい」という声が上がりました。現場からのフィードバックをもとに「今のExcelを活かしながら、集計・分析のアウトプット側を変える」というソフトランディングの方向に軸足を移すことに決めました。
展示会で「Loglass 経営管理」のブースを見つけたのはそのタイミングです。担当者にその場でデモをしてもらい、分析軸の設定を操作しているのを見た時に「これがやりたかったことだ」と確信しました。現場のExcelはそのままで、集計・分析だけをシステム上で行えるシステムはまさに私たちが求めていたものでした。
由良様：選定の過程ではERPも検討候補に上がっていました。ただERPは、プロジェクト管理系のシステムとしての色が強く、ExcelからERPへの移行は「ジャンプする距離が長い」という感覚がありました。そのタイミングで提案をいただき、下川と星野にデモを見せたその場で決断が下りました。「今のExcelを活かしたまま、業務フローを変えずに進められる」という方向性に最も合致していたのが「Loglass」だったのです。
下川様：最初は「Loglass 経営管理」のみでの導入を想定していました。しかし弊社のビジネスはプロジェクト型で、エンジニアがどのプロジェクトにどれだけ稼働しているかが収益管理の核です。人件費コストを正確に把握できなければ、プロジェクト単位の営業利益は算出できません。「人員計画との連携なしに、経営管理だけを入れても根本的な課題は解決しない」という判断から、「Loglass 人員計画」の同時導入に踏み切りました。
菅原様：一人当たりの生産性を経営指標として追うためにも、バイネームでの人員管理基盤は不可欠でした。採用・退職・アサインの状況を一元管理できる体制は、人が主要なコストであるプロジェクト型ビジネス全般に必要な仕組みだと思います。「Loglass 経営管理」でプロジェクトの収益を、「Loglass 人員計画」で人員コストの実態を見渡せる体制を最初から設計したことが、プロジェクト別収支を一人当たりの生産性にまで即座に分解できる、経営管理基盤の基礎になっています。
菅原様：最も時間をかけたのは分析軸の設計です。「どの切り口で数字を見たいか」が固まらなければ、データをいくら入力しても活用できない体制になってしまいます。弊社の最終目標はプロジェクト単位の営業利益の把握なので、プロジェクト・顧客・本部という収益構造の階層を正確に設計する必要がありました。
私自身がSEのバックグラウンドを持っているため、RDB*のデータ構造を意識しながら設計を進めました。どのデータをどう組み合わせれば求める切り口が出せるか、という観点から整合性のある軸を作り込んでいく作業です。最初は3階層だった設計を6階層に拡張するなど何度か入れ直しもありましたが、「Loglass」のCS担当者から導入の最初に「一番重要な設計判断は分析軸だ」と明確に伝えていただいたことが、大きな助けになりました。
由良様：データをどんどん入れて成長させていく過程は、見ていて驚くものがありました。点々としか見えなかったデータが、1週間、2週間と経つにつれて線になり、分析として活用できる状態になっていく。「これもできるようになった、あれも入れました」という形でデータが日々積み上がり、目に見えてシステムが育っていくプロセスを目の当たりにしていました。
菅原様：両プロダクトの目的が根本的に異なるからです。「Loglass 経営管理」の分析軸は、プロジェクト・顧客・本部という事業の収益構造を捉えるもの。「Loglass 人員計画」の分析軸は、職位・雇用形態・年齢といった人員の属性を捉えるものです。共通している項目もありますが、基本は完全に分けて設計しています。
「Loglass 経営管理」の分析軸を先に固めたことで、「Loglass 人員計画」で何をすべきかが自然に定まっていきました。現在の運用では、事業部門が各自の業績データを締め処理後に提出し、経営企画がその整合性を確認した上で全社のデータ基盤として完成させる構造になっています。入力の責任と整合性確認の役割を分けて設計したことで、年間100を超えるプロジェクトの経営管理基盤を、精度を保ちながら運用できています。
下川様：以前は、数字を確認したい時には、複数のExcelブックを同時に開かなければ管理できない状態でした。今は気になった時にLoglassを開けば、正確な数字がそこにある。「当たり前の経営管理が日常になった」という感覚が最も大きな変化です。使うたびに「いいよね、Loglass」という話になるのは、劇的な一瞬ではなく、使い続けることで積み上がっていく価値があるからだと思っています。
星野様：経営会議では菅原が「Loglass 経営管理」のレポートをモニターに投影しながら報告します。「前年度比でいうとどうか」「クオーターで見るとどうか」「このままの伸びだとどうなるか」という問いがその場で次々と出てくる。顧客別の数字を見ていて「どこに差が出ているのか、その差はなぜなのか」という粒度の細かい問いが出た時も、分析軸を切り替えながらその場でスパンと出せます。以前なら次の会議に持ち越しになっていた議論が、その場で完結するようになりました。
由良様：投資判断のタイミングで「キャッシュがどうなっているか、いくらまでいけるか」という問いが出ても、その場で「Loglass 経営管理」を開いて確認しながら議論を進められます。数字を知りたい時にすぐ知れる環境が整ったことで、意思決定のスピード自体が変わりました。いろいろな判断が格段に早くなったと思います。
菅原様：最も大きな変化は、全員が同じ数字を参照できることです。「Loglass」はシステム上で数値を編集することができないため、誰が参照しても同じデータしか出てきません。以前は集計式のセル範囲を一か所間違えただけで数字が変わり、「この数字はどうなっているのか」という確認が発生していました。今はその不安がなくなり、自信を持って正確な数字を経営層に提示できます。報告資料の作成も、以前は5日かけていたものが今は1日以内に完了しており、工数でいうと80％の削減になりました。
菅原様：「Loglass 人員計画」単体では、社員約230名と業務委託約150名をバイネームで管理し、職位レベル別・雇用形態別・年齢別の人員分布を確認しています。「会社全体がどういう構成になっているか」を経営層が数字で議論できる土台が初めて整った、という状況ですね。
下川様：「Loglass 人員計画」で人件費を管理することで、業績と人員を連動して見られるようになりました。数字の上では計画通りに推移しているように見えても、人員構成の変化が想定と乖離していれば「中身は大丈夫か」という問いを立てることができる。PLと人員計画の数字を一緒に見ることで、数字の背後にある実態に気づきやすくなることが同時導入の本質的な価値だと思います。
菅原様：「アウトプットから逆算して設計する」ことだと思います。何のために何を見たいのか。その目的が明確でなければ、分析軸の設計もデータ投入の優先順位も定まりません。私たちは「プロジェクト単位の営業利益を把握する」という最終目標が明確だったので、そこから逆算してデータ構造の設計を進めることができました。
下川様：経営管理の高度化は、それ自体がゴールではありません。分析軸を多角化し、成長領域や注力すべき顧客を数字で判断できる状態を確立します。そして、各事業部門長が多角化した分析軸とプロジェクト単位の営業利益を意識し、これらを向上させるために現場から自発的な提案が次々と生まれる文化を醸成していく。その進化を支える経営インフラこそが「Loglass」です。単なる数字の管理に留まらず、データの深掘りから次の事業の芽を見出し、利益を創出するための挑戦を加速させていきます。
* リレーショナルデータベースの略。表形式でデータを管理するデータベースシステムのこと。
