LEGACY × AI × AWS

古いシステムほど、
まだ伸びしろがあります。

誰も中身が分からなくなったシステム。手をつけられないまま止まっている業務。
キートスは、そこをAIで読み解き、AWS上で動く形に作り替えて、 現場で効くところまでやり切ります。

WHAT YOU GET

ご一緒すると、こうなります。

私たちがお渡ししたいのはシステムそのものではなく、「作ってよかった」と言える状態です。具体的には、次の4つが手に入ります。

BENEFIT 01

中身の分からないシステムが、
説明できる状態になります。

既存のソースコードを私たちの側でAI解析し、いま何がどう動いているのか、要件と実装がどこでずれているのかを可視化してお渡しします。刷新するかどうかの判断は、それを見てからで構いません。作り替えないという結論も、判断材料があってはじめて出せます。

BENEFIT 02

止まっていた業務が、
月単位で動き出します。

全部を一度に作り替えず、いちばん効く業務をひとつ選んで先に出します。年単位のプロジェクトが終わるのを待たずに、次の月には現場で使える状態をつくります。合わなければ、その時点で引き返せます。

BENEFIT 03

かけた費用が、何にどう効いたかを
確かめられます。

出す前に「何がどうなれば成功か」を一緒に決めてから作ります。作ったあとはその数字を見て、次にどこまで広げるか・いくら使うかを、確かめてから判断できます。効いたかどうか分からないまま次の予算を決めずに済みます。

BENEFIT 04

私たちがいなくても、
続けられる形で残ります。

構成も、コードも、なぜそう判断したのかの理由も残してお渡しします。ご自身のチームで手を入れていきたい場合は、その土台づくりからご支援します。作った会社に縛られ続ける状態を、私たちはよいものだと思っていません。

MEASURABLE

効いたかどうかを、
確かめられる形でお渡しします。

システム投資でいちばん困るのは、うまくいったのかどうか分からないまま、次の判断を迫られることです。 金額は請求書に残るのに、効果のほうは誰も測っていない。だから二回目の投資判断ができない。

私たちは、作る前に「何がどうなれば成功と言えるか」をご一緒に決めます。 作業時間が何分縮まったのか、待ちがどれだけ減ったのか、入力の手間がどう変わったのか。 数字で確かめられる状態にしてからお渡しするので、次にいくら投じるかを根拠を持って決められます。

確かめられないものは、
二回目につながりません。

OUR FIELD

レガシー × AI × AWS。
この3つを同時にやり切ります。

どれか一つができる会社はたくさんあります。私たちが引き受けているのは、古い資産を読み解いたうえで、それを新しい基盤に載せ替えて動かし続けるところまでです。

LEGACY

古いシステムを読み解く

作った人がいない、資料がない、仕様が分からない。そこから始まる案件を数多く手がけてきました。ソースコードと実際の動きの両方から、いま何が起きているのかを整理します。まっさらな状態からより、こんがらがった状態から呼ばれることのほうが多い会社です。

AI

実務で回す生成AI

メンバー全員が生成AIを日常的に使っています。既存コードの解析、要件との差分の可視化、テストの自動生成まで、実際の案件で成果を出すために使っているのであって、話題として扱っているのではありません。自社で開発用のフレームワークも育てています。

AWS

構成とコストから入る

どんな基盤に載せるかで、その後の変更しやすさも、かかり続ける費用も決まります。決まったものを実装するだけの関わり方はせず、クラウドの構成とコストの考え方からご提案します。使っていない環境が課金され続けることのないように設計します。

ISSUES

心当たりは、ありませんか。

うまくいかない原因の多くは、技術ではなく「作り方」にあります。私たちがよくご相談をいただくのは、次のような場面です。

大きな費用をかけて作ったのに、現場でほとんど使われていない。

作った担当者も会社もいなくなり、中身が分かる人が誰もいない。

ベンダーに言われるまま決めてしまい、あとから直せない構成になっている。

AIを使いたいが、何から手をつければいいのか分からない。

納品されたきりで、そのあと誰も相談に乗ってくれない。

見積もりが一式で出てきて、何にいくら払っているのか分からない。

FOUR PROMISES

案件の形が変わっても、
この4つは降ろしません。

「効かせる」を掲げる以上、そこから外れる仕事の受け方はしない、と決めています。

01

構成の判断から、ご一緒します。

どんな仕組みの上に載せるかで、その後の変更しやすさも、かかり続ける費用も決まります。決まったものを実装するだけ、という関わり方はしません。クラウドの構成やコストの考え方から、一緒に決めさせてください。

02

言われたものを、そのままは作りません。

ご要望どおりに作ることが、いつも正しいとは限りません。前提に無理があると判断したときは、お見積りより先に技術的な見解をお出しします。ご期待と違うことを申し上げる場面もありますが、あとで手戻りになるよりはいい、と考えています。

03

小さく出して、効いてから次を決めます。

要件をすべて盛り込んだ大規模な一括導入は、想定外のことが起きたときに軌道修正がききません。優先度の高い業務から段階的にリリースし、現場で効果を確認しながら対象範囲を広げます。判断のやり直しがきく進め方です。

04

渡したあとも、やり切ります。

リリース後の改修や問い合わせ対応を「保守」として後から足すのではなく、はじめから費用に含めてご提示します。動くものをお渡ししたあと、業務の中で成果が出るところまでが一つの仕事だと考えているからです。同じ目線で、一緒に矢面に立ちます。

HOW WE WORK

小さく始めて、育てていく進め方。

最初からすべてを決めきらないので、途中で方針を変えられます。「作ってみたら思っていたのと違った」を、小さいうちに見つけます。

1

相談・現状の確認

いま何にお困りかを伺い、既存の仕組みがあれば中身を確認します。ソースコードは私たちの側で解析し、要件との食い違いを可視化してお渡しします。

2

優先順位づけと、成功の定義

すべてを一度に作らず、いちばん効く業務を一つ選びます。あわせて「何がどうなれば成功か」をここで決めます。あとから効果を確かめられるようにするためです。

3

小さく作って、出す

短いサイクルで動くものをお渡しします。ここまでを低リスクな範囲に収めることで、合わなければ引き返せる状態を保ちます。

4

現場で確かめる

実際に使っていただき、2で決めた指標がどう動いたかを見ます。この確認をしてから、次にどこまで広げるかを決めます。

5

直しながら、育てる

改修と運用を続けます。使われるほど直すべき点が見えてくるので、それを次の投資判断の材料にしていきます。

TEAM

判断できる人間だけで、
最初から最後まで見ます。

5名
少数精鋭の体制
2名
PM経験者
10年+
全員の業界経験
100%
生成AIを日常的に活用

やり切るには、その場で判断できる人間が必要です。キートスは全員が業界経験10年以上で、 要件定義から設計・開発・運用保守までを同じ顔ぶれで担当します。 担当が変わるたびに一から説明し直していただく、ということがありません。

WORKS

参画実績のご紹介

代表・メンバーが参画したプロジェクトの一例です。いずれも一から作った案件ではなく、途中から入って整理した案件です。

情報通信業(SaaS)

外国人従業員向け 勤怠管理・タレントマネジメントSaaS 開発支援

在留資格情報と勤怠実績を紐づけ、就労可能範囲・就労時間の上限管理から人材配置の可視化までを一元化。開発着手済みの引き継ぎ案件に対し、AIでソースコードを解析して要件との差分を可視化し、手戻りを抑えた開発を実現しました。

引き継ぎ案件AIコード解析
官公庁

セキュリティ監視ダッシュボード 構築・改善支援

SIEM基盤の可視化領域について、可視化要件の整理から設計・実装、既存画面の棚卸し・標準化までを3名体制で一貫して支援しました。

期間 1年以上3名体制
大手サプライチェーン

WMS(倉庫管理システム)導入

アプリアーキテクトとして要件定義フェーズから参画。生成AIを用いた設計・開発・テストを実施し、高難易度の機能向けにはコーディングエージェントを応用したテストフレームワークを自作して、デグレードなく追加要望に対応しました。

期間 1年要件定義から参画

「これ、うちでもできますか」から
お話しさせてください。

まだ要件が固まっていない段階でも構いません。何に困っているかを伺えれば、そもそも作るべきかどうかからご一緒に考えます。ご相談だけでも歓迎です。