属人化した開発・運用を、
止まらない仕組みに変える。
手作業が増え、費用が上がり、担当者が辞めたら止まる。その状態を、要件定義から実装・運用・内製化まで現場に入って立て直します。1994年から現場に立つエンジニアが担当します。
手作業が増え、費用が上がり、担当者が辞めたら止まる。その状態を、現場に入って立て直します。
運用リスク診断を受け取る →Symptoms
こういう状態になっていませんか
- 毎月、この作業にだれかが半日かかっている
- AWSの請求が上がり続け、何が効いているか説明できない
- インフラ担当が辞めたら、正直どうなるか分からない
- 障害のとき、どこを見ればいいかが決まっていない
- 古いシステムを触れる人がおらず、止まったまま
- リリースのたびに緊張する。戻せる自信がない
- 外注はしているが、社内には何も残らない
Before / After
変えるのは、技術ではなく状態です
改修前
担当者しか分からない
改修後
手順、コード、監視、履歴が残る
改修前
手作業が多い
改修後
自動化され、同じ結果を再現できる
改修前
障害が起きてから調べる
改修後
状態を観測し、早く気づける
改修前
変更が怖い
改修後
テストとCI/CDで安全に変更できる
改修前
外注先に依存している
改修後
社内で判断と運用ができる
改修前
AI利用が個人技
改修後
チームの開発手順として定着する
証拠：2人がかりで半日かかる依頼対応が月10〜20回発生していた案件で、自動化により年間約4,000万円相当(概算試算)の運用コストを削減しています。
事例を見るServices
3つの入口があります
直せる人がいないシステムを、直せる状態に戻します。
仕様書が残っていない、作った人がいない、外注先が対応できなくなった。そういうシステムを読み解いて、仕様を書き起こし、テストを整えてから、段階的に置き換えます。一度に全部を作り直す方法は取りません。
- よくある相談
- 古いシステムを触れる人がいない
- リプレイスの見積もりが妥当か分からない
手作業と勘の運用を、コードと数値の運用に変えます。
手順書に頼った作業をコードにして、同じ結果を再現できるようにします。システムの状態を観測できるようにして、障害が起きる前に気づける形にします。費用の内訳が説明できる状態にします。
- よくある相談
- AWSの費用が上がり続けている
- インフラ担当者の退職が決まった
AIの利用を、個人技からチームの手順にします。
一部の人が速くなるだけの状態から、チーム全体の開発手順として定着させます。品質をどう担保するか、人がどこまで責任を持つか、要件定義をどう進めるかまで含めて設計します。導入して終わりにしません。
- よくある相談
- AIを使い始めたが品質が安定しない
- どこまで任せてよいか判断できない
Case Study
5年以上放置されたAWS運用管理システムを、作り直した話
課題
5年以上メンテナンスされていなかったAWSリソース管理システムが社内に残っていました。フレームワークは使われておらず、PHP 4とVanilla JS、シェルスクリプトの組み合わせで動いている代物です。作った担当者はすでに不在でドキュメントもなく、画面が真っ白になる、動かないといった問い合わせが毎日のように何度も届く状態でした。
制約
業務は止められないため、既存システムを動かしたまま移行する必要がありました。仕様書はなく、正しい挙動の根拠は「いま動いているもの」だけでした。
判断
それ以前に、この改修は海外の開発会社に委託され、1年半かけても使える形になっていませんでした。部分的な改修を重ねる道はここで見切り、全面的に作り直す判断をしました。着手して最初にやったのは、2週間かけて要求を洗い出しきることです。コードを直す前に、このシステムが何をすべきかを固め直しました。
実装
洗い出した要求をもとに、PHP 7.2・Laravel 6・Vue 2で再設計しました。データベースはPostgreSQLとし、スキーマ設計もER設計もすべて手で起こしています。既存の挙動を根拠に仕様を確かめながら進め、移行期間中は新旧のシステムを並行して動かし、検証を重ねたうえで切り替えました。
結果
月に10〜20回発生していた依頼対応(1回につき2人がかりで半日)を、自動化でなくしました。単価にもよりますが、概算では年間およそ4,000万円の運用コストにあたる試算です。障害対応も、読める人を探す作業から、手順に沿った作業に変わりました。
再現条件
仕様書がなくても、動いているシステムと運用担当者への聞き取りから仕様を復元できること。移行中に業務を止めないための並行稼働の期間を確保できること。この2つが揃う案件であれば、同じ進め方が使えます。
↓ 全面刷新
構成図
Small Team. Real Experience.
作る人と、運用まで見る人が同じです
1994年、コピー機の修理技術者としてキャリアを始めました。ソフトウェア開発の経験はありませんでした。独学で積み上げ、Web・メールホスティングの構築と運用を長く担当し、その後は業務委託として50件以上のプロジェクトで、技術負債の解消と運用の自動化に取り組んできました。いまはAI駆動開発を、現場で使える手順として実装しています。
1994年にコピー機の修理からキャリアを始め、業務委託として50件以上のプロジェクトで技術負債の解消と運用の自動化に取り組んできました。いまはAI駆動開発を、現場で使える手順として実装しています。
代表について詳しく見る →Process
相談してから、社内で回せるようになるまで
01
初回相談
こちら：現状の聞き取りと論点の整理
御社：いま困っていることを話す（資料は不要）
成果物：論点と次の一手のメモ
しないこと：その場での売り込み・見積提示
02
現状と制約の把握
こちら：システム・運用・体制の調査と聞き取り
御社：資料の共有と、担当者との時間の確保
成果物：構成・運用・リスクの見取り図
しないこと：この段階での改修着手
03
診断と優先順位の提示
こちら：課題の診断と、直す順番の提案
御社：優先順位のすり合わせと判断
成果物：診断結果と優先順位の一覧
しないこと：全部やる前提の提案
04
概算・計画の提示
こちら：概算費用・計画・体制の提示
御社：予算と期間の確認、社内への説明
成果物：概算見積と実行計画
しないこと：着手を急がせること
05
実装と検証
こちら：実装、テスト、検証、進捗の共有
御社：仕様の確認と受け入れの判断
成果物：動くシステム、検証結果、変更履歴
しないこと：検証を省いた切り替え
06
運用・内製化・引き継ぎ
こちら：運用手順の整備、文書化、引き継ぎ
御社：引き継ぎ先メンバーの参加
成果物：運用手順書、コード、監視、教育の記録
しないこと：依存が続く形で終わらせること
どこから話しても構いません
現状を聞いて、優先順位と、次に何をすべきかをお伝えします。その場での売り込みはしません。
20項目のチェックリストです。自社の運用がどこで止まるかが分かります。メールアドレスだけで受け取れます。
どんな症状の会社をお手伝いできるかをまとめた1枚があります。