この記事でわかること
-
スイムレーンで業務を可視化し、350の課題を特定する手法
-
現場との対話と信頼構築で、手動作業を40%削減した実績
-
SQL研修を通じ、非エンジニア主導の改善文化を作る方法
エンジニアと、事業を動かす非エンジニアのメンバー。両者の連携は、企業の成長に不可欠です。しかし、事業が急拡大する中で、両者の間には見えない壁が生まれ、オペレーションの非効率を招いてしまうケースは少なくありません。
産直通販サイト「食べチョク」を運営する株式会社ビビッドガーデンもまた、この課題と向き合った一社でした。この難題に、コーポレートエンジニアとして挑んだのが栗岡智己さんです。
栗岡さんは、非エンジニアのメンバーと対話を重ね、ときには彼らに新たな「スキル」を共有しながら、全社的な業務改善を推進しています。事業のボトルネックをいかにして特定し、組織を巻き込みながら解消していったのか。技術と組織への深い知見を土台に、単なる効率化に留まらない事業貢献を目指す栗岡さんのアプローチに迫ります。
栗岡 智己
株式会社ビビッドガーデン コーポレート部 コーポレートエンジニア
バックエンドエンジニア、エンジニア採用担当などを経て、2021年にビビッドガーデンへ一人目のコーポレートエンジニアとして入社。 PCのキッティングからヘルプデスク、情報セキュリティ、業務改善、AI活用推進まで幅広く担当し、事業成長を支えるIT基盤の構築に尽力している。
【SNS】：https://x.com/marroncorporate
株式会社ビビッドガーデン
株式会社ビビッドガーデンは「生産者の"こだわり"が正当に評価される世界」をつくることを目指し、生産者が食材を直接消費者に販売できる産直通販サイト「食べチョク」を運営。
野菜・果物をはじめ、米・⾁・⿂・飲料といった⾷材全般と花き類を取り扱っており、消費者が生産者に食べた感想を伝えるなど直接やりとりもできることが特徴。
2025年10月時点で登録生産者数は11,000軒、ユーザー数120万人を突破。5年連続で認知度や利用率など5つのNo.1を獲得している。
【参考】：株式会社ビビッドガーデン
目次
事業の急成長に伴う「成長痛」、その乗り越え方
まず、栗岡さんの現在の業務内容について教えてください。
現在は、社内で唯一のコーポレートエンジニアとして活動しています。業務内容は多岐にわたりますが、PCのセットアップやアカウント管理といった定常業務は自動化や仕組み化を進め、今では全業務の2割程度に抑えられています。 残りのリソースは、3割をセキュリティ強化、そして最も大きい5割を事業を前に進めるための業務改善に充てています。
半分のリソースを業務改善に割かれているのですね。どのような背景があったのでしょうか？
私が入社した当時、会社はまさに急成長の渦中にありました。事業が拡大していく中で、かつては機能していた手作業中心のアナログなオペレーションが、次第に事業の足かせとなり始めていたのです。いわば事業の「成長痛」ともいえる状況が生まれていたわけです。
事業成長にともなうオペレーションの課題は、多くの企業が抱える課題ですよね。具体的には、どのような業務に課題を感じていましたか？
はい。具体的には、各事業部と経理が連携する際のエクセル加工、マーケティング施策の効果測定のためのデータ抽出とVLOOKUP関数を駆使した集計作業など、様々な場面で人手に頼る業務が残っていました。
これらは事業規模の拡大に比例して作業時間が増大し、生産性を低下させるだけでなく、手作業ゆえの入力ミスや情報漏洩といったセキュリティリスクにも直結します。この状況を放置すれば、いずれ成長のスピードを鈍化させてしまう。そんな危機感がありました。
改善の第一歩は「解像度を上げること」。スイムレーンで見えた350の手動業務
山積する課題に対し、まず何から着手されたのですか？
いきなり個別の課題を潰しにかかるのではなく、まずは「社内の事業・組織理解の解像度を上げること」に徹しました。自分が課題だと思っていても、それは全体から見れば些末なことかもしれません。どこに本質的なボトルネックがあるのかを正確に把握する必要がありました。
そのために活用したのが「スイムレーン」という業務フローを可視化する手法です。これは、部署や担当者ごとの業務の流れを、まるで水泳のレーンのように並べて可視化する手法で、誰がどの作業を担っているかが一目でわかるようになります。
スイムレーンでの可視化は、どのように進められたのですか？
全ての業務を網羅するのはリソース的に現実的ではないので、まずはお客様に価値が届くまでのプロセスに関わる「主要オペレーション」に絞りました。そして、各部署で実際に業務を回している担当者、約10名に個別にヒアリングの時間を設定。「誰が」「いつ」「どのツールを使い」「どんなデータを」「どこに入出力しているか」を徹底的に洗い出していきました。
その結果を一枚の図にまとめ、人の手による作業が発生している箇所すべてに「手のマーク」を付けていきました。一見アナログな手法に思えるかもしれませんが、あえて誰にでも分かる表現を選んでいます。最も重要なのは、エンジニアも非エンジニアも含めた全社員が、一目で「ここに課題がある」と直感的に理解できることだと考えたからです。
なるほど。その可視化の元になる、現場の方へのヒアリングも重要ですね。
ここで重要なのは、現場が一番オペレーションとその目的を理解しているという前提に立つことです。ヒアリングではまず聞き役に徹し、現状の業務フローと、なぜその作業が必要なのかという背景を深く理解することに努めました。
課題を出すのはあくまで現場のメンバーであり、私ではありません。その課題と原因を一緒に考え、テクノロジーの観点から解決策を提案するのが私の役割だと考えていました。
現場主体で課題を洗い出していった結果、どのような発見がありましたか？
約7つの部署を対象に洗い出したところ、この「手のマーク」、つまり人の手による手作業が介在する工程が、約350箇所見つかりました。一つひとつの作業は小さくとも、会社全体で見れば膨大な工数になります。
この図を全社ミーティングで共有したときのインパクトは、今でもよく覚えています。現場のメンバーからは驚きの声が上がり、開発サイドのエンジニアからは「その作業、自動化できますよ」といった具体的な改善提案が自発的に出てきました。これまで分断されていた現場の課題とエンジニアの技術が、一枚の図を介して初めて繋がった瞬間でした。
可視化することで、部署間の連携も生まれたのですね。
他にも副次的な効果として、「そもそも、なぜこのオペレーションは存在するんだっけ？」という業務そのものへの問い直しが生まれました。急成長の過程で、今はもう必要ないのに惰性で続いていた報告業務や二重チェックなどが次々と見つかり、多くの不要な工程を廃止するきっかけにもなりました。
対話と技術普及で実現した、手動作業の大幅な削減
課題が可視化できた後、どのように改善を進めていったのですか？
当時、社内にはまだ「コーポレートエンジニア = 情シス＝ PCを管理をする人・セキュリティの人」というイメージが根強く、「オペレーション改善を相談する」という文化がありませんでした。そこで、まずは「情シスに相談すれば、業務が少し良くなるかもしれない」という小さな期待感を醸成することから始めました。
例えば、Slackのチャンネルを常に見ていて、「この作業、大変そうだな」と感じたら、「それ、自動化できますよ」とこちらから声をかける。どんなに小さな依頼でもスピード感をもって対応し、「やります」と伝えたことは必ずやり遂げる。この小さな成功体験の積み重ねが、少しずつ信頼に繋がっていったと感じています。
まさに「待ち」の姿勢ではなく、自ら課題を見つけにいく「攻め」のスタイルですね。
そうですね。コーポレートエンジニアは、単なるヘルプデスクではなく、事業推進を意識することが大切だと考えています。そのためには、事業部が何をしようとしているのか、どんなKPIを追っているのかを常にキャッチアップし、先回りして「こんなことで困っていませんか？」と提案することも必要です。この動きを続けることで、業務効率化に関する相談も自然と寄せられるようになります。
なるほど。そうした現場との対話の中から、実際にどのような改善が生まれてきたのでしょうか？
本当に多岐にわたりますが、例えば「申し込みフォームの回答をSlackへリアルタイム通知する」といった小さな“点”の改善から、「毎日手動で行っていたKPI進捗集計と共有の自動化」、さらには「業務オペレーションの再設計と、それに合わせた自動化」といった“線”の改善まで、幅広く対応してきました。
大切なのは、こうした改善一つひとつを確実に実行し、その成果を社内に共有していくことです。それが信頼となり、次のより大きな改善へと繋がっていきます。
そうした地道な信頼獲得の積み重ねが、最終的にどのような成果に結びついたのでしょうか？
地道なコミュニケーションの積み重ねと、後述するSQL研修のような技術普及の活動により、結果として「手動作業の大幅な削減」を実現することができました。
具体的には、スイムレーンを使った課題の可視化と共有が、非エンジニア職のメンバーに「これは改善できる業務だ」という当事者意識を持たせるきっかけとなりました。そして、彼らから「他にもこの作業を効率化したい」という具体的な相談が寄せられるようになったのです。
手動作業の削減という短期的な成果だけでなく、事業全体へのインパクトはどのように捉えていますか？
はい。事業への貢献度を測る長期的な指標として「1時間あたりの売上」も見ています。売上の伸び率との比較や前年比を確認しながら組織全体の生産性をモニタリングしています。
なるほど。短期的な改善と長期的な事業貢献、その両輪を回していくのですね。
その通りです。そして、その両輪をさらに加速させるため、次のステップとして「自分でできることは自分でやる」という自走文化を育てる方向にシフトしていきました。そのための鍵となったのが、非エンジニア向けのSQL研修です。
非エンジニアの「できる」を増やす。SQL研修で加速した現場主導の改善サイクル
数ある改善アプローチの中で、なぜSQL研修を選んだのでしょうか？
可視化した手動業務の多くが、データ抽出と加工作業だったからです。多くのメンバーが、社内システムの管理画面からCSVをダウンロードし、Excel上で何時間もかけて手作業でデータ作成やレポート作成していました。
しかし、基本的なSQLさえ書ければ、その作業はほんの数分で終わります。この非効率を解消することが、最もインパクトが大きいと考えました。
非エンジニアの方にSQLを教える上で、工夫した点はありますか？
最も工夫したのは、研修がそのまま実務に直結するように設計した点です。 例えば、SELECTやJOINといった構文をただ教えるのではなく、当時まさに会社が販促を強化していた旬の「果物」の売上データを実際に抽出してみるなど、受講者が「これは自分の仕事だ」と実感できるような題材を盛り込みました。
なるほど、研修のための研修で終わらせなかったのですね。受講者の選定はどのように行ったのですか？
全員をSQLマスターにすることが目的ではなかったので、まずは組織に変革を起こすための「最初の30%」を育てることを意識し、特にデータ活用が進めば大きな成果が見込める部署や、新しいツールへの学習意欲が高いメンバーをターゲットに設定しました。 受講は誰でも可能でしたが、ターゲットにしているメンバーには私から受講を打診したりしました。
SQLという「スキル」を手にしたことで、組織にどんな変化が生まれましたか？
変化は劇的でした。あるメンバーは、これまで毎週2時間かけていたレポート作成が10分で終わるようになり、空いた時間で新しい施策の分析や企画に取り組めるようになりました。
受講された方からの反響はいかがでしたか？
「もっと早く知りたかった」「これまでExcelで苦労していた時間は何だったんだろう」という声が多かったですね（笑）。成功体験を積んだメンバーが、自身のチームにその知識を共有してくれるようになり、そこから徐々に「自分たちでもできるんだ」という空気が広がっていきました。
技術を教えるだけでなく、その後の自発的なコミュニティ活動を支援することも、文化として定着させる上では重要だったと思います。
個人の成功体験がコミュニティを生み、文化の醸成に繋がっていったのですね。組織全体としては、どのような変化がありましたか？
個人レベルの生産性向上はもちろんですが、それ以上に大きかったのは組織文化の変化です。研修の受講者たちが自発的に「SQL勉強会」を立ち上げ、毎週朝会で集まっては1年以上も活動を続けてくれたんです。
これにより、「データはエンジニアに依頼するもの」から「まずは自分で見てみよう」という文化が組織全体に浸透していきました。エンジニアとのコミュニケーションも円滑になり、以前は曖昧だった依頼が具体的になったことで、エンジニア側の手戻りも大幅に削減されました。
事業成長に貢献するコーポレートエンジニアの未来像
一連の取り組みを経て、少人数でも組織全体に影響を与えるために重要なことは何だとお考えですか？
常に「事業や組織にとって、今最もインパクトのある改善は何か」という視点を持つことです。そのためには、依頼・相談内容をなんでも対応するのではなく、時には「やらないこと」を決める勇気も必要です。
コーポレートエンジニアのリソースは限られているからこそ、経営戦略や事業課題としっかり連動し、「今、会社がどこに向かっているのか」「そのためにはどの課題を解決すべきか」を常に見極め、最もレバレッジの効く領域に自分の時間を投下するようにしています。 冒頭でお話した「どんなに小さな依頼でもスピード感をもって対応する」と矛盾するようですが、当時はそのように対応することが最もレバレッジの効くと判断したためでした。現在はそのような判断はしていません。
今後の展望についてお聞かせください。
これまでは現場の課題を解決するボトムアップの改善が中心でしたが、今後はより上流から、事業のバリューチェーン全体を俯瞰し、大きなボトルネックを解消するような業務改善に取り組んでいます。目標は、テクノロジーを使い、経営戦略に沿って事業の成長を直接的に後押しできる存在になることです。
最後に、栗岡さんと同じように業務改善に取り組みたいと考えているエンジニアへアドバイスをお願いします。
これから業務改善に取り組む方へアドバイスするとしたら、ぜひ「社内で一番オペレーションとデータ構造を理解している人」になってください、ということです。弊社のような100人未満の組織だからできることかもしれませんが、誰がどんな業務をしていて、社内のデータがどこにどう流れているのか。その全体像を最も深く理解しているからこそ、本当に価値のある改善点を見つけ出すことができる。それが、コーポレートエンジニアとしての最大の価値だと私は信じています。
ライター
