業務改善のアイデアは、置き場所があると実行される｜散らばった社内ツールを1つの土台に集約した5ヶ月

業務改善のアイデアは、たいてい「新しく何かを作る」という形で語られます。ですが私たちの実感は少し違います。アイデアが形になり始めたのは、新しく作るのをやめて、すでに作ってあったものを1か所に集めてからでした。

Web制作会社であるGrowGroup株式会社には、社内向けの小さなツール群があります。社内では「便利ツール」と呼んでいます。日程調整メールの下書き、空き時間の抽出、会議録画の保管場所への転送、SEOまわりの点検、AIによる文字校閲——といった、日々の細かい作業を肩代わりする画面が並んでいます。

この便利ツールを作った理由は、大きく3つでした。

• 道具が散らばっていた。個々に作ったものがあちこちにあって、探すのが大変だった
• 共通の土台が欲しかった。認証や画面を毎回作るのが無駄なので、一回土台を作って、後は足すだけにしたかった
• 「小さいけどあれば便利」を集約したかった。単体では作る価値を説明しづらいものを、置く場所を用意することで成立させたかった

本記事は、この3つがその後どうなったかの記録です。5ヶ月で道具は11個に増え、変更履歴は113件になり、日常的に使っている社員は8名前後になりました。ただし、後述するとおり数字での効果測定はしていませんし、作った理由を書き残した文書もほとんどありません。都合のいい話も悪い話も、記録に残っている分だけを書きます。そのうえで、変わったことが2つあります。道具を探さなくなったことと、作るのが速くなったことです。

課題：道具は作れていた。散らばっていた

業務改善が進まない会社の話として、よく「アイデアが出ない」「作れる人がいない」が挙げられます。私たちの課題は、そこではありませんでした。作れてはいたのです。作ったものが、あちこちに散らばっていました。

Web制作会社の日常業務には、細かい定型作業が無数にあります。日程を調整するメールを書く。自分たちの空き時間を洗い出す。会議の録画を所定の場所に移す。公開前に文字を読み直す。そのひとつひとつに対して、誰かが「これは自動化できるな」と気づき、実際に手元で小さなものを作ります。ここまでは、たぶん多くの会社で起きていることです。

問題はその次に起きます。作ったものの置き場所が、そのつどバラバラになるのです。ある道具はある人の手元にあり、別の道具は別の場所にあり、その両方を知っているのは作った本人だけ、という状態になります。こうなると、次の3つが同時に起きます。

• 探すのが大変になる。「あれ、便利だったやつ、どこだっけ」から毎回始まる
• 知っている人しか使えない。存在を知られていない道具は、無いのと同じ扱いになる
• 作るたびに同じ手間が発生する。ログインの仕組み、画面の枠、置き場所の準備を、毎回ゼロから用意し直す

3つ目が、いちばん厄介でした。「本当にやりたいこと」は数十行で書けるのに、その周辺の準備のほうが手間として大きいという逆転が起きるからです。日程調整メールの下書きを作るという中身の部分より、「誰がログインできるようにするか」「どこに置くか」「どの画面から開くか」のほうが、時間を食う。

そしてこの逆転が続くと、「小さいけどあれば便利」が全部見送られます。効果が5分の作業の削減しかないのに、準備に半日かかるなら、誰も作りません。作る価値が無いのではなく、準備の重さが、作る価値を食い潰していたわけです。散らばっていることの本当のコストは、探す手間よりも、ここにありました。

目的：一回土台を作って、後は足すだけにする

そこで決めたのが、便利ツールの方針でした。言葉にすると、極めて素朴です。

認証や画面を毎回作るのは無駄だから、一回だけ土台を作る。あとはそこに足すだけにする。

この方針が効くのは、先ほどの「準備の重さが作る価値を食い潰す」構造を、正面から壊しにいくからです。ログインの仕組みも、画面の枠も、データの置き場所も、最初の1回で用意してしまう。2つ目以降の道具は、その上に中身だけ書けば動く。つまり、2個目からの1個あたりのコストを、意図的に下げにいったということです。

ここが、業務改善のアイデアの実現しやすさを決めていた分岐点だったと考えています。アイデアの数が足りないのではなく、1個あたりの実現コストが高すぎると、アイデアは実行されずに消えていきます。「あれば便利なんだけどね」で終わる会話は、アイデアが弱いのではなく、そのアイデアを試すのが高すぎるだけ、ということが少なくありません。

もう一点、意図的に選ばなかったことも書いておきます。この便利ツールは「1つのシステムで社内業務全部をカバーする」ことを目指していません。目指したのは、置き場所を1つにすることだけです。何を置くかは、その時々の困りごとに任せています。だから中身に一貫したテーマはありません。日程調整の隣に、文字校閲が並んでいます。それでいい、という設計です。

どうなったか：5ヶ月で4個から11個へ

方針が正しかったかどうかは、その後に何が足されたかで判断できます。以下は、変更履歴から機械的に取り出した実測の時系列です。設計文書の側には時系列の情報が一切なく、この表は履歴を掘り返して初めて作れたものである点は、先に断っておきます。

読み取れることは、2つあります。

1つ目。初回に土台を作った翌日に、もう2つ目が足されています。2月10日に土台とダッシュボードと最初の道具ができ、2月11日には空きスケジュールの抽出が乗っています。3日目には3つ目。「後は足すだけ」という方針は、少なくとも足す速度としては、そのとおりに機能しました。

2つ目。足すペースは、5ヶ月にわたってまばらに続いています。2月に集中したあと、3月に4つ、4月に1つ、6月に1つ。これは「プロジェクトとして一気に作った」のではなく、困りごとが発生した時に、その都度足している形です。3月20日から25日のように、足して5日で消したものもあります。まさに「随時、小さいけどあれば便利を集約する」という当初の狙いどおりの使われ方でした。

構造としても、これは「独立した小さな道具が11個ある」のではありません。1つのアプリケーションの中に11の画面があり、共通のログイン、共通のダッシュボード、共通のデータ置き場を共有している——つまり、一体型に近い作りです。バラバラの道具を集めた道具箱ではなく、1枚の土台に穴を開けて機能を挿していったと表現するほうが実態に近い。「集約したかった」という当初の狙いが、そのまま構造に出ています。

足された側の実例：どんな困りごとが道具になったか

土台の話だけでは抽象的なので、実際に何が足されたのかを2つだけ具体的に書きます。この2つは、作ることになった最初のきっかけが記録として残っていたものです。

AI文字校閲：「基本的には文字の校閲ですね」

当社がWebサイトを開発するとき、設計工程（ワイヤーフレーム）とデザイン工程はデザインツール上で行い、コーディング工程は自社のテストサーバーで確認します。この各工程の校閲をAIで対応できるようアプリケーション化して、業務を効率化したい——これが起点でした。

注目すべきは、その直後です。「各工程の校閲をAIで」という広い構想は、その場ですぐに「基本的には文字の校閲」へと自ら絞り込まれています。デザインの良し悪しも、コードの品質も、対象から外れました。

これは、業務改善のアイデアを実装まで持っていくうえで、おそらく最も効く動作です。広い構想のままでは、いつまで経っても作り始められません。「文字だけ」まで絞ったから、作る対象がその場で決まりました。

同じ姿勢は、設計文書にも残っています。この校閲まわりの文書には「やらないこと」が明記されていました。ある形式のファイルは最初のバージョンでは分割の対象にしない。処理を分けるかどうかの判定も、最初のバージョンではフレーム数だけで行う（＝簡素に済ませる）。絞り込みが、思いつきではなく設計に組み込まれているのが分かります。

アクセス解析アカウントの逆引き：「どのアカウントか分からない」

もう1つの起点は、もっと地味です。当社は所有しているアクセス解析ツール・検索管理ツールのアカウントが複数あり、どのクライアントのURLがどのアカウントに紐づいているのかが分からなくなっていました。これが直接の動機で、URLからアカウントを逆に引く画面が足されました。

Web制作会社は、納品したサイトの解析アカウントを積み上げていきます。数が増えると、「このURLは、どのアカウントで見ればいいのか」が毎回分からなくなる。誰かが激怒するような障害ではありません。ただ、毎回わずかに手が止まる。

この規模の困りごとは、普通なら道具になりません。単体で企画すれば、準備コストのほうが上回るからです。土台が先にあったからこそ、この程度の困りごとが道具として成立しました。「小さいけどあれば便利」を集約したかった、という当初の狙いが、いちばん素直に効いた例だと思っています。

この2つに共通しているのは、起点が「壮大な構想」ではなく「名前のついた具体的な困りごと」だったことです。「業務をDXする」から始まった道具は、11個の中に1つもありません。

土台を壊さない、という選び方——「9分の壁」の記録

「一回土台を作って、後は足すだけ」という方針には、当然ながら続きがあります。足していくうちに、土台のほうを壊したくなる場面が必ず来るということです。そのとき何を選ぶかで、この方針が生き残るかどうかが決まります。

その判断が、たった1件だけ、文書として残っていました。AI文字校閲の設計文書です。

背景はこうです。この道具が動いている実行環境には、1回の処理が9分（540秒）を超えられないというハード制限があります。ところが、デザインツール上の大きなファイルを校閲しようとすると17分かかると見積もられ、そもそも完走できない。9分の壁に、正面からぶつかりました。

採った解決策は、1つの大きな処理を「親」と「子」に分割し、子を並べて走らせるというものでした。ここまでは、よくある技術的な工夫です。重要なのは、その案を選んだ理由として挙げられていた5点の中身のほうです。

• 既存の起動トリガーを、そのまま使える
• アクセス権限のルールを、変更しなくてよい
• 画面のURL構成を、変更しなくてよい
• 既存ロジックの9割を、そのまま流用できる
• データの構造を、変更しなくてよい

5点すべてが「変更しなくて済むこと」で構成されています。「速いから」でも「きれいだから」でも「新しいから」でもない。選定基準はただ一つ、既存の構造を壊さないことでした。

これは、「一回土台を作って、後は足すだけにしたい」という当初の狙いと、まっすぐつながっています。土台を壊す案を選んだ瞬間に、「足すだけ」は成立しなくなります。権限のルールが変わり、URLが変わり、データの形が変われば、既にある10個の道具に影響が及ぶ。1個の都合で土台を触ると、残り全部の面倒を見る羽目になります。だから「変えなくていい案」に価値が置かれた。技術的な好みの話ではなく、方針そのものを守るための選択だったと読めます。

そしてこの文書には、採った案の欠点も明記されています。親と子が同じ場所に混在するため、一覧を出す処理に「子は除外する」という条件を1つ足す必要がある。ただしその処理は1箇所にまとまっているので影響は小さい——という書きぶりです。採用理由と欠点が、両方書いてある。9件の設計文書のうち、そうなっているのはこの1件だけでした。

ここには、業務改善に持ち帰れる原則が1つあります。共通の土台に乗せる方式を採るなら、「土台を変えずに済む案」を選ぶ基準を、最初に決めておいたほうがいい。個別の要望はいつでも土台を触りたがりますが、そのたびに触っていると、土台であることをやめてしまいます。

正直に書きます：残っていないもの、測っていないもの

ここまでは、狙いどおりに進んだ話です。狙いどおりにいかなかった側も、同じ分量で書きます。

説明書は、最初の4個で止まっている

便利ツールの説明書（README）に載っているのは、最初の4個だけです。実際に動いている画面は11あります。説明書は2026年2月10日前後の姿で凍結し、以降5ヶ月・7つの追加が一度も反映されていません。

これは「足すだけにした」ことの裏返しでもあります。足すコストが下がった分、足したことを説明するコストは下がらなかったからです。中身を書けば動いてしまうので、説明書を直さなくても誰も困らない。困らないことは、後回しになります。

しかも腐っていたのは説明書だけではありませんでした。文書が「詳しくはこちらを参照」として指し示している先の文書が、いくつも実在しません。文書の劣化は、1ファイルの問題ではなく全体に及んでいました。

5日で消した連携の理由は、どこにも残っていない

時系列表の中に、1行だけ性質が違うものがあります。ある外部サービスとの連携を足し、5日後に完全削除している行です。

正直に書きます。なぜ消したのか、記録が残っていません。設計文書にこの連携が存在した痕跡はなく、変更履歴のメッセージにも理由がありません。「試したがダメだった」のか「方針が変わった」のか「別の手段が見つかった」のか、判別できません。

本来これは、足した記録より価値のある記録のはずでした。うまくいった追加はコードを読めば分かりますが、やめた判断は、書き残さなければ完全に消えます。同じサービスをもう一度検討しようとした半年後の自分に「前に試して捨てた」と伝えられるのは、その記録だけです。

効果測定は、していません

この手の記事には、たいてい「年間◯◯時間を削減」という数字が載ります。本記事には載せられません。

設計文書9件を全部読みました。成果・効果・削減時間・利用状況・満足度に関する記述は、一切ありませんでした。定量も定性もゼロです。測定を実施した形跡がないだけでなく、「測定しよう」と述べた記述すら1行もありません。つまり私たちは、この11個の道具の効果を、数字としては測っていません。「測ったが公開できない」のではなく、測っていません。

この表は、業務改善を進めている会社にはたぶん見覚えのある形だと思います。「何を・どう」は残り、「なぜ・どれだけ」は残らない。そして「なぜ」を書き残す動機は、9分の壁のように追い詰められた時にしか発生しません。すんなり通った判断ほど、記録が残らない。それが5ヶ月分の履歴を掘り返して分かったことでした。

では、何が変わったのか——2つの背景が、2つとも閉じた

数字はありません。それでも、変わったことが2つあります。そしてその2つは、この器を作った理由と、そのまま1対1で対応しています。

1つ目。道具を探さなくなりました。「あれ、あの変換をやるやつ、どこにあったっけ」——散らばっていた頃に一番多かったのは、この一言です。作った本人でさえ探していました。いまは、行き先が1つしかありません。探す時間が何分減ったかは測っていませんが、「探す」という動作そのものが業務から消えました。これは、道具を11個に増やしたことの成果ではありません。11個を1か所に集めたことの成果です。

2つ目。作るのが速くなりました。土台には、ログインの仕組みも、画面の枠も、AIを呼ぶ配線も、すでに乗っています。だから新しい道具を1つ足すとき、考えるのは「その道具が何をするか」だけです。5ヶ月で7つが足されたのは、思いつきが7回あったからではありません。思いついてから形になるまでの距離が、短かったからです。この記事のタイトルは、そういう意味です。業務改善のアイデアは、置き場所があると実行される。

そして、この2つが効いていることの、いちばん静かな証拠が「日常的に使っているのは8名前後」という事実です。これが分かっているのは記録に残っていたからではなく、社内に聞いたからです。誰も使えと命じていません。役に立たない道具は、誰も文句を言わずに使われなくなります。使われ続けているのは、探さずに届いて、すぐ足せるからです。

御社に移せる形にすると

ここまでの話は、Web制作会社の内輪の事情に見えるかもしれません。ですが構造は、業種を問いません。「あれば便利なんだけどね」で終わる会話が社内にあるなら、同じ状態です。

私たちの5ヶ月から、そのまま持ち出せるものは4つです。

1. アイデアを増やす前に、置き場所を1つ決める。アイデアは足りていないのではなく、置く場所がないから消えています。散らばっている状態のままアイデアを出しても、出た端から行方不明になります
2. 2個目以降のコストを下げることに、最初の投資を全部使う。ログイン・画面の枠・データの置き場所。この3つを1回で終わらせると、「5分の削減のために半日かける」が「5分の削減のために30分」に変わります。ここが変わって初めて、小さな改善が採算に乗ります
3. 足すときは、土台を変えなくていい案を選ぶ。私たちの唯一のWHY記録がそう言っています。採用理由5点すべてが「変更しなくて済むこと」でした。1個の都合で土台を触ると、他の全部の面倒を見ることになります
4. やめたこと・捨てた案だけ、1行残す。採用したものは動いているので後から分かります。分からなくなるのは、やめたものだけです。私たちはここを残さなかったので、5日で消した連携の理由を永久に失いました

逆に、私たちがやらなくても回ったことも書いておきます。網羅的な要件定義。全社的な合意形成。効果測定の設計。どれもやっていません。やらなかったから始められた、という側面は確実にあります。ただしその代償として、説明書が5ヶ月古いままで、消した理由が分からなくなり、効果を数字で語れなくなりました。この取引をどう評価するかは、会社によって違っていいと思います。

よくある質問

Q. 業務改善のアイデアは、どこから探せばいいですか？

私たちの11個のうち、起点が記録に残っていた2つは、どちらも「毎回ちょっと詰まること」から始まっていました。「どのアカウントがどのクライアントか分からない」「校閲を人手でやっている」。激怒するほどの障害ではないが、毎回わずかに手が止まる作業です。逆に「DXしよう」という言葉から始まった道具は、1つもありません。アイデア出しの会議より、今日ちょっと詰まったことを1行メモするほうが、実際には機能していました。

Q. 土台を先に作ると、大掛かりになりませんか？

私たちの場合、土台とダッシュボードと最初の道具が、同じ日に出来ています（2026年2月10日）。翌日には2つ目が乗りました。つまり土台を作ることは、大掛かりなプロジェクトではありませんでした。ポイントは土台を立派にすることではなく、土台を「1回で終わらせて」その先を全部足すだけにすることです。土台の完成度を上げにいくと、そちらが目的化して足す作業が始まりません。

Q. 小さいツールが増えると、管理が大変になりませんか？

実際に大変になったのは「管理」ではなく「説明」でした。共通の土台に乗っているので、動かすこと自体は5ヶ月・113コミットで問題なく続いています。破綻したのは説明書が最初の4個で止まり、11個の全容を知る手段が失われたことです。新しく入った人が全体像を掴む方法が、実質ありません。集約する形を採るなら、入口の一覧を説明書代わりに使えるところまで作っておくのが対策になると考えています。

Q. 効果を測っていないのに、続けている理由は？

数字が出ていないのは事実ですが、変わったことははっきりしています。道具を探さなくなり、新しい道具を作るのが速くなりました。これは、器を作った理由（散らばっていた／土台が欲しかった）とそのまま対応しています。加えて、8名前後が日常的に使い続けているという事実そのものが、一種の投票結果です。役に立たない道具は、誰も文句を言わずに使われなくなります。削減時間として言えないだけで、効いていないわけではありません。

Q. 社内ツールは内製すべきですか、既製品を買うべきですか？

この11個については、既製品を比較検討した記録がありませんので、「内製が正解でした」とは言えません。言えるのは、「どのアカウントがどのクライアントのものか分からない」といった自社に固有すぎる困りごとには、そもそも既製品の売り場がないということだけです。汎用的な困りごとなら、買うほうが早い場面は当然あります。

Q. この便利ツールは購入できますか？

いいえ。便利ツールはGrowGroupの社内業務専用で、製品として販売しているものではありません。本記事は、自社の業務をどう改善したかという事例の公開です。同じ発想で御社の業務を改善するご相談は承っています。

まとめ：業務改善のアイデアは、置き場所があると実行される

本記事の事実を、もう一度整理します。

• 便利ツールを作った理由は3つ。道具が散らばっていた／共通の土台が欲しかった／小さいけどあれば便利を集約したかった
• 方針は「一回土台を作って、後は足すだけ」。土台と最初の道具は同じ日に出来て、翌日には2つ目が乗った
• 5ヶ月・113コミットで、道具は4個から11個へ。困りごとが出るたびに、随時足された
• 唯一WHYが残った設計文書（「9分の壁」）の採用理由5点は、すべて「変更しなくて済むこと」。土台を壊さない案が選ばれ、欠点も併記されていた
• 一方で、説明書は最初の4個で凍結し、5日で消した連携の理由は残っておらず、数字での効果測定は一度もしていない
• それでも、作った理由の2つは、2つとも閉じた。道具を探さなくなり、作るのが速くなった——数字ではなく、そう感じている
• そして8名前後が、誰に命じられるでもなく日常的に使い続けている

業務改善のアイデアそのものは、実は困りません。毎日の業務の中に、詰まっている場所はいくらでもあります。困るのは、そのアイデアを試すコストが高すぎて、口に出す前に諦められてしまうことです。「あれば便利なんだけどね」で会話が終わるのは、アイデアが弱いからではありません。置き場所がないからです。

ですから、これから業務改善を始める方に申し上げたいのは、この1点だけです。アイデアを集める前に、置き場所を1つ作ってください。散らばった道具を1つの土台にまとめると、その後のアイデアは、勝手に足されていきます。私たちの5ヶ月は、そういう5ヶ月でした。

御社の業務改善についても、ご相談を承っています

「毎回ちょっと詰まる作業がある」「大きなシステムを入れるほどではないが、放置もしたくない」「作ってはみたが、あちこちに散らばっている」——そうした具体的な状態が1つでもあれば、それが着手点です。何から手をつけるべきか、そもそも作るべきか買うべきかの判断も含めて、お気軽にご相談ください。

無料ダウンロード資料

GrowGroup株式会社の制作事例・料金がわかる資料を配布中

会社概要・制作実績・料金の目安をまとめた資料です ／ PDF

資料をダウンロード